Loadster is a tool designed for performance testing web apps and websites. It was created to be a median between the costlier tools that only big enterprises can afford, and free open source tools. Loadster is designed so that it is easy to create scripts for testing even if new to automation testing or having little coding experience. It treats everything in terms of concurrent users, which are simulated user going through the transactional flow of the website. These users can have different response times, slower connections and other changeable settings, and a report is generated at the end of testing.
Performance testing according to Andy Hawkes is anytime a system is tested to see how it behaves under load, typically with many concurrent users or requests. Instead of testing to see if a section of code does what its supposed to do, performance testing is about stress testing your app and going back to optimize your code so that the app runs more efficiently. It is important to test applications under load because it’s helpful to know how the app will perform when it is being used in a more realistic environment. It is also helpful to know if the application will have significant slowdowns or crashes and what is causing it, if the app can’t handle being under the tested load.
Andy says that tests are only as valuable as the assumptions that went into the test. This is some useful advice since you should be designing the application and tests around about how much traffic your site or application is designed for, rather than an unrelated or unrealistically high or low number. You also shouldn’t be spending too much time or resources preparing the app for traffic it will likely never encounter.
Andy also says that performance testing has diminishing returns, and doesn’t need to be done all the time for it to have valuable outcomes. Instead of doing performance testing all the time and needing to do even more testing when new things are added to an app, it could be done every so often and have similar results. This would leave more time for other parts of the app to be worked on. I’m sure there’s some exceptions to this, but it sounds like this approach would be useful, especially for smaller scale projects.