There are 3 main ways to carry out performance testing:
Measured testing
Measured testing has the purpose of recognizing objective measurements rather than subjective ones. This means having the developers insert performance markers, watching the network packets and communications, or observing the performance with objective means.
Performance markers are little bits of code at the beginning and end of code blocks. Performance Monitor, Network Monitor, or other tools are used to receive measurements of the performance of the application and the user's interplay with it.
Observational testing
Observational testing uses some tools to recognize firmer numbers. Even simply using a stopwatch takes before one can interplay with the page gives a more perspicuous idea of how the application is carrying out.
Ad hoc performance testing
Software tester needs to be alert to whether the application is responding slowly. Software bugs should be logged on the users' sensation with follow-up from developers.
There are a lot of ways to spend the test effort and time in performance testing. Some software testing teams can rathole in any of these areas for the entirety of a release, waiting for their efforts to pay off. For the most part a small amount of checks in each area is the best use of the time and funds that is accessible and helps to cover 80 % of user scenarios with eases.
You should spend time trying to find the sense of the performance of the builds. Not every build needs to be profiled. It is much better to spend time in the areas that make the most sense for your company.
Places that should be tested are:
load
scalability
stress
memory leak testing
bytes over the wire
mean time to failure
user-perceived response time
Performance testing should not be done only on debug builds. Debug builds are more dilatory than ship builds as they need to resolve asserts and perhaps comprise code that was left in at compile time.
Debug builds will not be seen by the outside world, so the performance of it is not so significant. Running a stress pass or a mean time to failure pass on a build near shipping may turn up a very infrequent assert or other trouble, so there may be value if the software testing company has the time to do software testing at this point. Performance testing on a debug build will not precisely reflect the performance of the retail code of an application.