How to design an interface automation testing framework based on YAML? After watching the second meeting!

When designing an automated testing framework, we often save test data in external files (such as Excel, YAML, CSV) or databases to decouple scripts from data and facilitate later maintenance. At present, many automated testing frameworks use Excel or YAML files to directly write test cases, and read them through scripts to drive the execution of automated test codes.

As for whether to use Excel or YAML format, everyone has different opinions. For example, using Excel is intuitive to maintain and convenient to modify data. The disadvantage is that it is not easy to compare historical version differences through version control tools such as Git (because it is in binary format); the advantage of YAML It supports complete data format and convenient version control management (text format). The disadvantage is that it is not as intuitive as Excel. Everyone is familiar with the Excel method. This article will take you to understand how to design an automated testing framework based on YAML.

YAML format test case design

Taking interface automation as an example, the basic functional requirements to be realized by writing test cases in YAML:
1. One YAML file can support the storage requirements of multiple use cases, otherwise thousands of use cases corresponding to thousands of YAML files cannot be managed.
2. Use cases It can support single-interface test cases and business scenario use cases (combination of multiple interface calls)
3. The use case needs to include information such as the module it belongs to, use case name, request information, assertion information, and extraction response (realize interface association)

Based on the above requirements, we design a version of the YAML format use case:
insert image description here

The casename and module fields are simple. Let's look at teststeps. Why is teststeps an array type?

Because a use case contains one/multiple interface request steps, that is, a TestCase contains multiple teststeps, and each teststep is an interface request.

Request specifies the interface request information, including the interface request method, request address, request header, and request parameters; among them, we need to distinguish between different request parameter types. The above is json parameter passing. If it is a form form and query parameter passing parameters, we all It can be agreed to a similar key-value structure, just change json to formparam and queryparam.

It should be noted that the parameters of the file upload interface will be quite special. Generally speaking, we only need to set the path of the file to be uploaded, so we can design it like this:
insert image description here

The extract field is the response data field to be extracted and passed to the subsequent interface for use. Generally, we need to support JsonPath expression or regular expression to extract, the corresponding key is the field name to be extracted, and the corresponding value is the field expression to be extracted.

The validate field is the assertion information, which is to verify whether the response result meets expectations. Here we need to support commonly used judgment methods including: equal to, greater than, less than, greater than or equal to, less than or equal to, and use the abbreviation eq instead of equals (equal to) to judge, others are similar: greater than or equal to (ge), less than or equal to (le), less than ( lt), greater than (gt).

The above is a single-interface test case. Let’s look at the style of multi-interface series (business scenario) use case writing: ModifyUserProfile.yaml
insert image description here

The most important thing in multi-interface testing is to be able to support parameter passing. Here we use extract to extract the response field of the interface in the previous interface, and use ${token} to reference it in the interface to be used later. Familiar with the Jmeter interface testing tool Students should be very familiar with this format.

Script to read YAML data

Before reading YAML file data, we first need to understand two concepts: serialization and deserialization

The process of converting an object into a byte sequence is called object serialization;

The process of restoring a sequence of bytes to an object is called deserialization of the object.

And our process of reading YAML can be called deserialization.

The mainstream programming language can realize the analysis of YAML, and then take the Java language as an example to explain how to read the content of the YAML file:

There are many libraries in Java that can implement YAML serialization and deserialization, including SnakeYaml, Jackson, jYaml, etc., which are similar in use. Take Jackson as an example:

Step 1: Add the coordinates of the library to the Maven POM file
insert image description here

Jackson-databind and jackson-dataformat-yaml are used here, where jackson-databind is the main library of Jackson, and jackson-dataformat-yaml is a library that supports the YAML data format. Lombok is also introduced here for later writing entity classes Simplify writing some code:

Lombok can help us simplify some necessary but bloated Java code tools (such as get/set methods). By using the corresponding annotations, the corresponding methods can be automatically generated when compiling the source code.

Step 2: Write the YAML entity class
Create a corresponding class to represent the information of the YAML file in Java by comparing the content of the YAML file, such as the field name (such as "name") and the data type of the field (such as a string). The purpose is to be able to save YAML files into Java objects (deserialization).

TestCase entity class:
insert image description here
Teststep entity class:
insert image description here

Validate entity class:
insert image description here

Read the content of the YAML file through Jackson and save it into the TestCase entity class object
insert image description here

Among them, new TypeReference<List>() {} is because there are multiple TestCase cases in the read YAML file, so we need to define it as a List collection type to receive.

Let's take a look at the effect after reading:

insert image description hereThen you can use the returned testCase to initiate interface requests (for example, through REST-assured), perform interface assertions, extract response fields, and other operations.


              [The following is the most complete software test engineer learning knowledge architecture system diagram in 2023 that I compiled]


1. From entry to mastery of Python programming

2. Interface automation project actual combat 

3. Actual Combat of Web Automation Project


4. Actual Combat of App Automation Project 

5. Resume of first-tier manufacturers


6. Test and develop DevOps system 

7. Commonly used automated testing tools

Eight, JMeter performance test 

9. Summary (little surprise at the end)

life is long so add oil. Every effort will not be let down, as long as you persevere, there will be rewards in the end. Cherish your time and pursue your dreams. Don't forget the original intention, forge ahead. Your future is in your hands!

Life is short, time is precious, we cannot predict what will happen in the future, but we can grasp the present moment. Cherish every day and work hard to make yourself stronger and better. Firm belief, persistent pursuit, success will eventually belong to you!

Only by constantly challenging yourself can you constantly surpass yourself. Persist in pursuing your dreams and move forward bravely, and you will find that the process of struggle is so beautiful and worthwhile. Believe in yourself, you can do it!           

Guess you like

Origin blog.csdn.net/nhb687095/article/details/132146507
Recommended