API interface automation part 3 automated testing of multiple interfaces in the same war package

Automated testing of multiple interfaces in the same war package

An interface uses a test class. Each test case is as follows. For example, the following are four test cases. Each detailed test case contains request input parameters and return body verification, so as to judge whether each test case passes

If a war package contains multiple interfaces, multiple test classes are added, and each test class corresponds to a test case

The question is:

1. If there are complex requirements, more input parameters and more test cases in the interface, the single test example will be very long and occupy a lot of space. For example, when registering an interface, I encounter 20 input parameters, and there are about 20 key value pairs;

There are hundreds of registered interfaces and test cases. I have thousands of lines of a java file. It's too long. I don't want to see it anymore....

And if more input parameters need to be added to the requirements in the later stage, the test cases of a single interface are equivalent to all rewriting and updating..

For such a complex interface, what I can think of is that the request body is stored in the DB as a string, then taken out from the DB, called the interface test, and checked the return value.

For the design of a single interface table, it is necessary to use sequence number, test name, request body, assertion and pass mark

Then the unified, such as URL and request method, are stored in the association table.

ALTER TABLE API_ TASK ADD PRIMARY KEY (ID)

ALTER TABLE API_ CASE ADD CONSTRAINT FK_ API_ ID FOREIGN KEY(API_ID) REFERENCES API_ TASK (ID)

SELECT API_ NAME,API_ HOST,API_ URL,API_ TYPE,CASEPIORITY,CASE_ NAME,CASE_ BODY,CASE_ ASSERT FROM API_ TASK JOIN API_ CASE ON Api_ id =id

The content of this article comes from the network collection of netizens. It is used as a learning reference. The copyright belongs to the original author.
THE END
分享
二维码
< <上一篇
下一篇>>