Performance - the (in) famous buzzword.
Focusing just on the design / implementation and Zero-functional-defect solutions are things of the past. With increasing maturity in technology and IT staff, the 'Non-functional' aspects of the system are fast becoming focus-areas.
Non-functional requirements (NFRs) tell the IT team, about the kinds of usage and load the application will be subjected to, and the expected response time. NFRs define the Service Level Agreements (SLAs) for the system and hence the overall Performance of the Enterprise Application. Managing and ensuring the NFRs (SLAs) for an Enterprise Application is called Performance Engineering. Performance is about risk management. You need to decide just how important performance is to the success of your project. The more important you consider performance to be, the greater the need to reduce the risk of failure and the more time you should spend addressing performance. There should always be a proactive approach to performance rather than reactive.
Engineering for performance is broken down into the following actionable categories and areas of responsibility:
To define the performance of any System (Software/hardware/abstract) following technical parameters should always be used in conjunction -
The next steps would be – Identifying the transactions to be tested, setting up the environment, identifying the test data, Designing Scenarios and validating Output.
(Read More about it at : https://msdn.microsoft.com/en-us/library/ff647781.aspx )
Here are some key graphs that should be created while executing Performance Testing and should be presented in a Performance Test Report.
This graph tells us whether the CPU utilization increases with increasing users. It also tells us about bottlenecks as well as what is the maximum number of users that can be supported.
This graph tells us if throughput increases with increasing number of users. This graph should have a similar shape as CPU Utilization graph.
The response time should be fairly constant with increasing throughput. If it is not, it is most likely a bottleneck.
The conventional approach to performance is to ignore it until deployment time. However, many, if not most, performance problems are introduced by specific architecture, design, and technology choices that you make very early in the development cycle. After the choices are made and the application is built, these problems are very difficult and expensive to fix. We need to promote a holistic, life cycle-based approach to performance where you engineer for performance from the early stages of the design phase throughout development, testing, and deployment.