Test

When configurations are made for an application, manual testing can be done or test cases can be written to verify whether they meet your expectations.

Besides, test cases that have been written, can also be used for the regression testing each time the configurations change,

or, coupled with the staging release function, for regression testing prior to the official release.

Here is a guide to how to add test cases.

First, the test name needs to be input to help distinguish different tests.

Descriptions mainly rely on small language like TestML: request information used for testing, and the expected output.

For instance, add a simple test (or may input multiple test cases, separated by three blank lines),

which means sending requests to the tested node: http://openresty.com/,

301 is returned as expected, and the request header contains the expected Location address and Server mark,

and the response body contains HTML title “301 Moved Permanently”.

Specifically, === segment represents the name of the test,

--- segment represents the specific contents tested, such as:

url: Used to specify the URL of the request,

host: Used to specify the Host of the request,

ssl: Used to specify whether the request is HTTPS request as HTTP is the default,

req_headers: Used to specify the request headers, with no request headers being the default and one line representing one pair of request headers,

status: Used to specify the expected response status code,

resp_headers: Used to specify the expected response headers, with one line representing one pair of request headers,

resp_header_pat: Used to specify the regex matching pattern of the expected response headers. It is similar to resp_headers, but the value part can be expressed by regex,

resp_body_pat: Used to specify the regex matching pattern of the expected response body.

Save successfully and jump to the test case list from which a test can be selected for execution.

First, we need to select which test to execute.

Then, specify the gateway nodes to be tested. The nodes can be tested in whole or in part.

Selecting one specific gateway node means the requests described in the test case will be sent from the admin node to this gateway node (via the extranet IP of the node),

with HTTP requests going to the port 80 and HTTPS requests going to the port 443 (specifying special ports is not yet supported),

then, the obtained response status code, response header, and response body will be compared with the expected values described in the test case one by one,

if the obtained value complies with the expected value, the testing point concerned passes, with a green tick to be put in the result column,

if not, the testing point concerned fails, with a red cross to be put in the result column.

So, one test case may end up with multiple testing result outputs (depending on the expected value written in the test).

Select execution for real-time output of the testing results.