At present, automated testing cannot completely replace manual testing. Whether automated testing can be carried out effectively depends on the stability of the system. For systems that have a short production cycle, frequent demand changes, high version update frequency, and even the possibility of system architecture reconstruction, cases recorded with automated testing tools, after the system is iteratively updated, frequent modification and debugging of automated scripts are required, and the cost is Therefore, this type of system is not suitable for automated testing; for some optimized and upgraded systems, the system architecture tends to be stable, and the program version is stable, especially if the production cycle is long, the test cases need to be repeated frequently, and the use of automated testing tools can improve effectiveness. The architecture optimization project described in this article belongs to this type of project.
1. Project background
This project is to optimize and upgrade the architecture of the system A that has been put into production. This transformation mainly involves the following: one is the transformation of log sub-database, modification of the way of recording transactions, and the log sub-database according to the sharding rules; the second is transaction routing Method changes; third is to access the monitoring platform; fourth is to optimize log configuration and increase the output of operation and maintenance logs.
Through the analysis of the transformation needs, the optimization and upgrading content of the project involves less optimization and transformation at the transaction level, and mainly optimizes the system configuration, operation and maintenance parameters, and data architecture. The system architecture tends to be stable and involves multiple production windows. Frequent repeated execution of test cases is suitable for the introduction of automated testing.
Two, automated testing tools
This automated test chooses a self-developed automated testing tool, which is a software platform that integrates automated test case management, test data management, test execution management, and result analysis to support automated testing. The tool supports interface testing (host side/open platform side), interface testing (non-mobile side), and realizes the integration of test case design, test execution, and result analysis. This regression test belongs to the category of interface-based automated test applications.
Three, automated test asset library
To perform automated regression testing, a highly available automated test case library needs to be prepared in advance. When system A was put into production, an automated test case library based on the new distributed architecture was built, a system-level automated regression test asset library was realized, and the main transactions of system A were fully covered by automated cases. At the same time, according to the system data source The structure of the sub-database has designed automation cases for different data sources, which can facilitate the verification of different sub-database data by transactions. The automated regression test case library has been applied to some test projects in the early stage, and maintenance and debugging are carried out in a timely manner according to changes in transaction interfaces and requirements. At present, a total of 221 automation cases corresponding to 180 transactions have been established for system A. The coverage rate of transaction automation cases is 100%, and the execution pass rate is about 90%.
Fourth, automated testing strategy analysis
In this project, based on the testing and analysis of the transformation requirements, different automated testing schemes were formulated for different transformation content: the tests were carried out by means of full-volume trading regression testing, high-frequency trading regression testing, and automated delivery testing.
The full regression test mainly verifies the correctness of the transaction functions of the 108 transactions that were originally put into production in the second stage under the sub-database structure. For the cases that failed the full regression test, manual tests were added to further verify.
The automated regression test of high-frequency trading is mainly aimed at the needs of optimization and transformation of log recording methods. According to the transaction complexity, importance and daily average trading volume, it is screened according to the 28 principle, and 35 high-frequency trading is screened out for log sub-database. 4 different log record configuration methods for query transactions in the 4 rounds of regression testing, and manually query the automatically executed transaction log in the log record query link to verify the correctness of the modified log query mode.
Automated iteration is used to verify the correctness of the log sharding data source. Through the analysis of the transformation requirements, it is found that the system log sharding transformation uses the organization number as the sharding key value, the database is numbered, and the first two provinces and cities of the organization number are used. Number as the algorithm basis for sub-library. Therefore, the institutional teller input value of the transaction automation case is parameterized, the data resource pool is set, and the transaction is executed iteratively. Each time the teller data of different institutions in the resource pool is called, the transaction log is divided according to the database after the users of different institutions execute the transaction. The rules are correctly recorded in different shard data sources.
Five, automated testing practice
A total of 6 production batches were set up for this architecture optimization project. The regression test based on full trading was executed 3 times, involving 108 transactions, more than 300 automated cases were executed, and the test pass rate was about 95%; the high-frequency trading regression test was executed in total Four rounds, involving 35 transactions, a total of about 150 automation cases, and the execution pass rate was 100%. Automated iterative testing executed about 50 automated cases in total, with a pass rate of 100%. Through the application of automated testing in this project, work efficiency has been improved. In the case of a short test cycle for a single production window and fewer test human resources, the production test tasks can be completed as required.
Six, summary
The architecture optimization project has many production rounds, the test time of each production cycle is tight, and human resources are insufficient. According to the analysis of the optimization and transformation needs, suitable automated testing tools are introduced, which greatly liberates the implementation of automated testing. Manpower, cost savings, and completion of the test tasks for each production window on time.
At the same time, by citing automated regression testing in this project, testers are further familiar with the use process and methods of automated testing tools, and the ability to analyze and solve common problems in script debugging in automated testing is improved, so that they can be better used in similar projects in the future. Automated testing tools have laid a solid foundation.
END
Official account: Programmer Erhei, get software testing resources (interview questions, PDF documents, video tutorials)
Good things should be shared with friends