This is the 30th day of my participation in the August Text Challenge.More challenges in August

What is use case layering?

In the field of automated testing, the maintainability of automated test cases is an extremely important factor, which is directly related to whether automated testing can be carried out in the project continuously and effectively.

Generally speaking, the core of the test case layering mechanism is to separate the interface definition, test steps, test cases, and test scenarios for separate description and maintenance, so as to reduce the maintenance cost of automated test cases as much as possible.

The logical diagram is as follows:

Image from Httprunner official website.

Several core concepts

  1. Test cases (testcase) should be complete and independent, and each test case should run independently
  2. Test cases are test steps (teststep)The orderlySet, one for each test stepAPIRequest description of
  3. Test Case Set (testsuite) is for test casesA disorderlySet, the test cases in the set should be independent of each other, there is no sequential dependence; If sequential dependencies do exist, they need to be handled in the test case

HttpRunner layered detailed solution

Layer 1: Interface definition

With the definition description of the interface, we can reference the interface definition directly when writing test scenarios.

In testStep, you can reference the interface definition through the API field. The reference method can be the absolute or relative path of the corresponding API file. A relative path is recommended. The path base is the root directory of the project, that is, the path of the debugtalk.py directory.

To better manage interface descriptions, you are advised to store interface descriptions in independent files, that is, each file corresponds to one interface description.

The main contents of the interface definition include name, variables, Request, base_URL, validate, etc., in the following forms:

name: get test
base_url: http://mock.cn
variables:
    expected_status_code: 200
request:
    url: /
    method: GET
validate:
    - eq: ["status_code".$expected_status_code]
    - eq: [content.headers.Host."mock.cn"]
Copy the code

The name and request sections are required, and request is described in exactly the same form as requests. Request (the Request method in Python’s Requests library).

In addition, the API description needs to be as complete as possible so that it can be run independently. If variable references exist in the interface description, you can define parameters in variables. In this way, debugging of a single interface is very well implemented.

Layer 2: Test steps in test cases

We can reference interface definitions and test cases directly in the test steps for testing purposes.

The API keyword is used for reference interface definitions and the TestCase keyword is used for reference test cases.

Reference interface definition

- config:
    name: "test_1"
    variables:
        user_agent: 'chrome 56.8'
        device_sn: "ddd"
        os_platform: 'chrome'
        app_version: '56.8'
    base_url: "http://127.0.0.1:5000"
    verify: False
    output:
        - session_token

- test:
    name: get token (setup)
    api: api/api_1.yml
    variables:
        user_agent: 'chrome 56.8'
        device_sn: $device_sn
        os_platform: 'chrome'
        app_version: '56.8'
    extract:
        - session_token: content.token
    validate:
        - eq: ["status_code".200]
        - len_eq: ["content.token".16]

- test:
    name: test_2
    api: api/api_2.yml
    variables:
        token: $session_token
Copy the code

If you need to control or change the values of parameters in the interface definition, you can override the variables implementation in the API by specifying variables parameters in the test step.

Similarly, after validate is defined in the test step, it will also be combined with parameterization. The variables in parameters will be combined by Cartesian product to form a parameter list, which will successively cover the parameters in variables and drive the operation of test cases. Override the validate merge in. Therefore, it is recommended that validate in the API definition only describe the most basic validations, such as status_code, and that more validations related to business logic be described in the validate of the test step.

Reference test cases

That is, referencing use cases within use cases.

- config:
    name: "config_1"
    id: config_1
    base_url: "http://127.0.0.1:5000"
    variables:
        uid: 8774
        device_sn: "xxx"
    output:
        - session_token

- test:
    name: test_1
    testcase: testcases/case_1.yml
    output:
        - session_token

- test:
    name: test_2
    variables:
        token: $session_token
    testcase: testcases/xxx/case_2.yml
Copy the code

Set of test cases

When the number of test cases is large, in order to facilitate management and achieve batch running, it is usually necessary to use test case sets to organize test cases.

Testsuite is an unordered collection of test cases in which dependencies are processed.

In each test case set file, there are two types of fields at the first level:

  • config: Indicates the overall configuration parameters of the test case set
  • testcases: value is dictionary structure (unordered),keyFor the name of the test case,valueIs the content of the test case; It can also be specified when referencing test casesvariablesTo implement the reference test casevariablesThe coverage.

Nonparametric scenarios

config:
    name: config_suite
    variables:
        device_sn: ${gen_random_string(15)}
        var_a: ${gen_random_string(5)}
        var_b: $var_a
    base_url: "http://127.0.0.1:5000"

testcases:
    case_1:
        testcase: testcases/case_1.yml
        variables:
            uid: 1000
            var_c: ${gen_random_string(5)}
            var_d: $var_c

    case_2:
        testcase: testcases/case_2.yml
        variables:
            uid: 1001
            var_c: ${gen_random_string(5)}
            var_d: $var_c
Copy the code

Parameterized scenario

For parameterized scenes, parameters can be used to achieve the description as follows

config:
    name: config_suite
    variables:
        device_sn: ${gen_random_string(15)}
    base_url: "http://127.0.0.1:5000"

testcases:
    case_1:
        testcase: testcases/case.yml
        variables:
            uid: 1000
            device_sn: xxx
        parameters:
            uid: [101.102.103]
            device_sn: [sn_1.sn_2]
Copy the code

After parameterization, variables in parameters will be combined by Cartesian product to form a parameter list, which successively covers the parameters in variables and drives the operation of test cases.

Thank you for reading, don’t forget to follow, like, comment, forward four consecutive yo!