How does the interface automation test platform reduce the execution time of the whole process automation use case?

Like the title, this problem may not be encountered by everyone. But this is indeed the problem I encountered.

    The reasons for the problem are as follows:

    1. Sometimes to complete a full-process use case, more than a dozen associated interfaces may be required.

    2. The process involves timing tasks or file processing, and waiting time needs to be added.

    3. Some automation use cases cannot be executed concurrently because of the timed tasks involved in batch processing of data by the system.

    Because of the above reasons, the execution of use cases is very time-consuming.

    The method I currently use is to skip some time-consuming steps by constructing test data. For example, it is necessary to test the impact of data after a time-consuming scheduled task is executed on subsequent interfaces. At this time, the corresponding data can be directly constructed for testing.

    For automation, constructing data must at least meet the following requirements:

    1. To be able to retain traces of data execution. That is to say, the constructed data should be random to ensure that the data changes each time the use case is executed.

    2. The data in different libraries must be able to be associated. For a microservice system, there are many libraries.

    3. The data structure should be updated in time. Table structure update is inevitable

    4. Historical traces are easy to clean up.

    5. Constructing data should be fast and easy for automatic execution. Just to reduce execution time.

 Below is the function I designed

project data

table data

field configuration

Divided into three value modes: random, fixed, reference

Unified management of different database information in different environments, including synchronizing database table structures.

At present, automation use cases have started to use this function, saving a lot of execution time. But there is also a problem, that is, data construction is a bit difficult for ordinary testers. Now it is the backbone testers who are proficient in business to construct the data.

Summarize:

Thanks to everyone who read my article carefully! ! !

I personally sorted out some technical materials I have compiled in my software testing career in the past few years, including: e-books, resume modules, various job templates, interview books, self-study projects, etc. Welcome everyone to click on the business card below to get it for free, don't miss it.

 

Guess you like

Origin blog.csdn.net/MXB1220/article/details/131903827