You're talking about two different things. There's burn-in, which is needed to shake out hardware (and possibly, OS) issues before placing the system into production. Then there's performance testing. Comparing the system to a baseline. Understanding how the hardware works with your specific application. You need to be able to answer questions like:
- Will SAS disks be good enough?
- What RAID solution should I use?
- Do I need SSDs? Will slow disks be enough?
- Does adding more RAM have an appreciable effect on application performance?
For burn-in, I'll PXE boot the system into a memory or stress loop test (memtest works). If I do burn in after OS installation, I'll use the stress utility for some period of time to shake out any hardware issues. That tool can be set to stress the CPU, virtual memory, disk and other subsystems...
Some manufacturers (like HP) include a maintenance CD that can also run automated test loops on the installed hardware components.
For performance testing, I'll build the servers up and run something like the WHT UnixBench variant to obtain a composite relative score to compare other systems deployed in the environment. Make sure you receive similar results across the fleet of servers.
Specific testing of the networking and storage subsystems can be accomplished with the actual production application (simulated workload) or by using the normal suite of benchmarking tools (i.e. iperf for networking, iozone or bonnie++ for storage).
Really specific platform testing in a CPU speed or latency-sensitive environment can be accomplished using tuning tools like oscilloscope and cyclictest. This is also helpful for seeing how external loads impact the system. But that's probably too much for most server deployments...
The best performance tests will always come from the intended application and a realistic workload, though.