-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
Please feel free to ask any question regarding HTTPLoadTest-baseline below (if the question is not asked and answered already)
HTTPLoadTest-Baseline is simple starting point for building LoadTests to be used for continuous deploy/continuous production QA pipelines. Baseline projects are meant to be a git clone starting point for for software which are expected to grow and flourish in different ways which are not easy to parameterize in early stages. It should be usable for quite a few settings, but is expected to grow in different directions. We would love to receive pull-request for enhancements both on current code base and extensibility features.
The main goal for this code base is to simplify Companies efforts in ensuring that an agile or continuous investment into software development does not compromise the quality assurance processes on non-functional requirements, we have tried to focus on making the load-test QA process easily embedable to a Company's continuous CI/CD processes.
The first thing you should know, is that variables are organized as inheritance where the most detailed scope might overwrite variables inherited. The hierarchy begin with the property-file defined variables at the top. The next level is LoadTest global variables which are shared between the Read TestSpecification and write TestSpecification. The lowest level is command-specific variables which are defined for the command in the TestSpecification. Request-response (result)-generated variables from the previous command is added to the next command variable-map.
Resolving is (as of now) a simplified two-step process, where "normal" variables are resolved before "functions". An example on a function is the #fizzle-keyword, which is a function which allow you to randomize values or option from a set/list.
For typical testing of REST-API flows, you should be able to run 10-30 concurrent threads with no deviations. If you try large number of threads, like 100 to 1000 concurrent threads you should expect some deviation from environment and infrastructure. If running a very many concurrent threads, be aware that the /health endpoint might be unstable which may have the container manager try to restart your container.