JMeter High-Level Requirements
"must" and "should" are used in the following sense:
Functionality requirements:
Must be able to exercise the functionality of any HTTP/HTTPS site which respects common conventions (e.g. that GET requests don't have a body, that query-string parameters are URL-encoded and separated by & and =,...).\[This includes using different test data for each thread or for each test loop, reusing data extracted from previous responses, etc...\] |
Should show test results in both numerical and graphical form. The graphs and reports should be nice-looking enough to show them to a customer. \[Yes, I know it's pretty weak as a requirement, but that's the meaning of "high-level" after all, isn't it? :) \] \\ |
Portability:
Usability:
Ease of installation: should be able to set up a single load-generation workstation on any site in a few hours -- even in the presence of ugly firewall settings. \[This probably requires a command-line interface.\] |
Should be reasonably easy to set up and use a cluster of load-generation workstations, even in the presence of ugly firewall settings. \[This is probably one of the very weak aspects of JMeter right now.\] \\ |
Performance:
Should be able to drive an application server at 100% with one single similarly-powered load-generation machine -- assuming an average application is running on the server which doesn't require specially complex processing of responses. \[This one is pretty weak too... ideas for making it better?\] \\ |
Maintainability:
[JavaDoc] must be correct. \[Yes, this means a plain lie in a JavaDoc comment can't be considered a Minor bug. Also means we should always be careful to keep JavaDoc up-to-date when we touch at the code.\] |