Home
This is a test suite for Xceptance LoadTest (XLT) - http://www.xceptance-loadtest.com/.
- Name: testsuite-nocoding
- Version: 2.2.1
- License: Apache V2.0
- License URI: http://www.apache.org/licenses/LICENSE-2.0.txt
- Tags: load testing, performance testing, testing
- Contributors:
- Hartmut Arlt, Xceptance Software Technologies GmbH
- René Schwietzke, Xceptance Software Technologies GmbH
- Jörg Werner, Xceptance Software Technologies GmbH
- Matthias Mitterreiter, Xceptance Software Technologies GmbH
- Christoph Keiner, Xceptance Software Technologies GmbH
One is often faced with the requirement to just fire a couple of simple URLs, to verify the performance or functionality of a single feature, to create load in order to stress environments and monitor certain things, or simply to create load in addition to another load test.
Testsuite-nocoding is a test suite for XLT and delivers an easy way to define and fire HTTP requests and offers various tools to validate the responses. Additionally it is possible to filter, select and store data from the response in view of inserting it into the next request or its validation. This is a fast and likewise easy way to define test cases, since no programming is needed!
Since the source is open and licensed under the Apache License V2.0, feel free to extend and customize it.
See the wiki for a basic introduction in using and customizing the testsuite-nocoding.
Each test case is defined in its own file which describes the desired requests as well as information for validating the responses. So far, two file formats are supported: YAML and CSV. Each file format is handled by a separate parser. Hence, support for additional file formats can simply be added by implementing a proper parser. To learn how to build your own test cases, see the YAML and CSV sections.
Each test case is defined in a separate file.
A single test case consists of the following two steps:
- Read and parses the test definition(s).
- Execute the parsed input
The execution is either of the following ones:
- Create a HTTP request
- Send the HTTP request
- Validate the HTTP response
- Store a variable
- Store a default value
The following chart shows the flow of the process from the test case definition in a file to the final result:
As the chart depicts, test cases are defined in files. Therefore, for each test case, the file is parsed in an internal format. Then, for each action there must be information on how to create a request and optionally information on how to validate its response. Additionally, it is possible to store data in variables for later usage. These variables can be defined in properties or test case files as well as created dynamically during runtime from the information of the responses. In the latter case, you have to specify how the information will be gathered. Consequently, requests will be created dynamically during runtime, since they may need information of the previous response.
Test cases are configured by several properties files. See Configuration on how to configure a test case. Test cases must either be located in the configured directory or next to the class. Additionally, you can configure the handling of JavaScript and static content among others.
Moreover, it is possible to define global variables, for example the target host, authorization information or user agent.
You can execute the test suite as an XLT load test but it is also possible to execute it inside your IDE. Simply create a wrapper class for each of the test cases. This also makes them more configurable and easier to execute.
Read the Quickstart Guide to learn how to make your test suite run. After that, you can take a look in the example folder or read the Examples. It might also be helpful to read the FAQ to get quick answers to common questions.