background

• At present, there are many api testing tools on the market

  jmeter,postman. When JMeter needs to add a PreProcessor, it supports java and JavaScript languages to write code on it, does not support python, and data parameterization is not convenient. Postman is used for interface debugging, which is not convenient for automatic testing, and parameterized behavior.

• Test framework

  Unit test frameworks in different languages, Junit, unittest, pytest. Including some TDD related tools. In fact, these are for function level unit testing. Of course, it can also be used as a framework for interface testing or UI. Using it to write interface automation or UI automation, it is not easy to test all interfaces comprehensively.

• About demand

  For the addition, deletion and modification of requirements, I believe most companies do not have such a standardized process. A developer who modifies some small details of api documents may not (of course, it may not be intentional) notify the requirements or testers. Moreover, the document may not be comprehensive, such as incomplete response parameters, insufficient parameter description of the request, and so on

• About testers

  Testers may not want to request that the parameterization is very comprehensive and saved. Testers or product managers who provide api documents may organize a document in the form of a file. These situations mentioned above will produce a lot of communication between various technicians, and behind the communication is more useless work. How to solve it?

Some thoughts on interface automation

• Step 1: what is the basis of api testing

  It's obviously an interface document. As a document is a normative document, its normative writing method must be formulated. Like restful style, it can not be a mandatory code rule, but an agreed specification. DELETE requests can also POST, but this is not recommended.

• The first step is to solve the problem

  Unified api documents are platform managed by development + test + product / project managers, and different technicians edit and maintain different parts. For example, developers edit the basic elements of api documents, such as request paths, methods, parameters, responses, etc. testing mainly maintains and writes some use case generation rules. It is ok for products to export api documents directly

• Step 2: think about how to define the interface document (this step is directly about how to define api#u JSON)

  Root elements: version, interface name, path, method, setup, request header, request parameters, request expectation, additional Case addition, teardown

  Detailed elements in the request field parameters: parameter name, parameter type, parameter location, required, empty, unique, description, pre acquisition, additional failure

  For example:

{
    "name": "Login interface",
    "code": "login_api",
    "versions": ['v1.0', 'v2.0'],
    "route": "/user/login",
    "method": "POST",
    "setup": [
    ],
    "headers": {
        "Content-Type": "application/json",
    },
    "fields": [
        {
            "name": "account",
            "require": {
                "default": True,
                "unexpected_result": {"$.code": "40001", "$.msg": "Account number is required"}
            },
            "null": {
                "default": False,
                "unexpected_result": {"$.code": "40001", "$.msg": "Account number is required"}
            },
            "data_type": "str",
            "location": 1,
            "pre_get": {
                "true": "{{ config.get('$.localhost.account') }}",
                "false": "xxxxxxxx",
                "unexpected_result": {"$.msg": "Account does not exist"}
            },
            "failures": [("admin1234", {"$.msg": "This user is not assigned a role"})],
            "desc": "account number",
        },
        {
            "name": "password",
            "require": {
                "default": True,
                "unexpected_result": {"$.code": "40002", "$.msg": "Password is required"}
            },
            "null": {
                "default": False,
                "unexpected_result": {"$.code": "40002", "$.msg": "Password is required"}
            },
            "data_type": "str",
            "location": 1,
            "pre_get": {
                "true": "{{ config.get('$.localhost.password') }}",
                "false": "xxxxxxxx",
                "unexpected_result": {"$.msg": "Password verification failed"}
            },
            "desc": "password",
        },
    ],
    "teardown": [
    ],
    "extra_case": [
    ],
    "response": {
        "expected_result": {
            "$.code": "200",
            "$.data.token": "\\w+",
        }
    }
}

• Step 2:

  Once you know how to define it, you can think about how to generate and run use cases through this structured json. At present, we have written such a framework, which is inconvenient to disclose too much.

• Step 3: think about how to write some non pure string content,

  For example, how to write in setup, pre acquired field parameters, teardown, etc., and how to parse and execute custom syntax. Of course, it is not necessary to master the ast syntax tree skills. There are other ways to solve it.

• Step 3: it can be parsed through the template string

• Part IV: parametric generation of use cases

• Step 5:

More ideas about interface automation

Weighted interface, load test, performance test, etc

Interested in adding v or qq, 838863149. Also ask you if there is such a platform. If so, I won't continue to write. I'm going to change my career to collect junk.