For the aims of this conversation, we use a sample application of an online retail bookstore. This application has pages of complete info, forms for comments, pages regarding our company and an online price-list and storefront with the help of which users can buy books and have them shipped to their houses.
The user scenario might be of such type:
- User navigates to the Web site of the company.
- User requests some info Web pages.
- User navigates to the price-list.
- User carries out 3 searches in the price-list.
- User places 1 book in shopping cart.
- User carries out 2 another searches, reads comments on the second book, and buys this book.
- User places 2 copies of this second book in shopping cart.
- User clicks Checkout to buy books.
- User buys all books.
Nevertheless, different user scenario might effect in the user forsake the shopping cart.
Each of these scenarios might be developed as a script and automated to test the software product.
Well, one of the most general causes that performance testing of an application is not successful is that the incorrect scenarios were tested.
Not every line of code or probable cooperation needs to be benchmarked on every build. You should identify the deciding areas, the most frequent code paths, and the most costly of them, the ones that are most significant to the user, and spend the precious test time on this.
If you have more time, you’d better spend it on any code paths that have been added since the last release. Software testing the incorrect thing is a deplorable bequest to have to work out. Using specifications and locating the actual piece of the system or application where the performance trouble lies are such approaches to planning performance testing that can help you escape testing the incorrect events.