CN109783358B - A regression test-driven software version management method, system and storage medium - Google Patents

Abstract

The invention discloses a regression test-driven software version management method, system and storage medium. The method includes the use of available test cases in the test program corresponding to the previous version of the software source program to perform a first-stage verification on a newly submitted source program , to obtain the first coverage result; according to the first coverage result, automatically generate test cases for the newly submitted source program; use the generated test cases to perform the second-stage verification of the newly submitted source program, and obtain the second coverage result; According to the results of the second coverage, write new test cases and generate the test program of the newly submitted source program; calculate the verification file and version number of the test program, and combine the verification file and version number of the newly submitted source program to generate a new version of the software. The present invention can effectively solve the problems that the current SVM tool cannot effectively support the management of test codes and the regression test information cannot be fully utilized, thereby helping the research and development personnel to improve the quality of software version management and improve the research and development efficiency of software products.

Description

A regression test-driven software version management method, system and storage medium

technical field

The invention relates to a regression test-driven software version management method, system and storage medium, and belongs to the technical field of software evolution analysis.

Background technique

The traditional software development process stipulates a fixed mode of software development. For example, the waterfall model divides the software development process into six basic stages, including plan formulation, requirements analysis, software design, program writing, software testing, and operation and maintenance. . However, with the rapid development of the software industry, the scale of software is getting larger and the complexity of the program is getting higher and higher, and the problem of software development cycle and development cost out of control is becoming more and more serious. At this time, the agile development model, which emphasizes iterative development, incremental delivery, continuous integration, and feedback-driven development, came into being, and has been widely recognized by the industry for its rapid R&D, rapid delivery, and rapid response capabilities. In the process of agile development, a large project may be decomposed into multiple sub-projects that are interconnected and can run independently. During development, when requirements change, developers will be required to actively embrace the changes, which will result in many different form of the software version. At this time, it is necessary to apply the software version management tool SVM (Software Version Management, software version management) to record and manage, to help the R&D personnel to better understand the functions and performance of the software in different periods.

At present, software version management has become an important part of the current software development process. Academia and industry have also proposed a variety of software version management methods, and developed a variety of mature SVM tools (such as CVS, SVN, Git, etc. ). Through the SVM tool, developers can store the modification history of directories and files, support software configuration management activities, track the development and maintenance activities of multiple versions, and release software-related information. These functions play an important role in improving the development efficiency of software products. important role. However, although the current SVM tools have provided good support for the management of software source programs, they have not yet provided effective support for the management of the test codes contained in the software. Most of the traditional SVM tools regard the test code as part of the software source program, and developers need to maintain the test code of each software version; The test cases of the test cases may be unavailable, insufficient, etc., which need to be corrected and supplemented manually, which is time-consuming and labor-intensive.

SUMMARY OF THE INVENTION

The purpose of the present invention is to overcome the deficiencies in the prior art, and to provide a regression test-driven software version management method, system and storage medium, which can effectively solve the problem that current SVM tools cannot effectively support the management of test codes, and regression test information cannot be fully utilized. It can help R&D personnel to improve the quality of software version management and improve the efficiency of software product development.

To achieve the above object, the present invention adopts the following technical solutions to realize:

In a first aspect, the present invention provides a regression test-driven software version management method, the method comprising the following steps:

Use the available test cases in the test program corresponding to the previous version of the software source program to perform the first-stage verification of the newly submitted source program, and obtain the first coverage result;

According to the first coverage results, automatically generate test cases for the newly submitted source program;

Use the generated test case to perform the second-stage verification on the newly submitted source program, and obtain the second coverage result;

According to the second coverage results, write new test cases and generate test programs for newly submitted source programs;

Calculate the verification file and version number of the test program, and generate a new version of the software in combination with the verification file and version number of the newly submitted source program.

With reference to the first aspect, further, the method for obtaining the available test cases includes:

Find the test case of the previous software version according to the given software repository and the source program of the current software version;

The usability analysis is performed on the test cases of the previous software version, and the available test cases obtained by the analysis are used as the available test cases for the source program of the new version software.

In conjunction with the first aspect, further, the method for the second stage verification includes:

Given the source program of the current software version, the first coverage result and the maximum window width, the width is used to limit the maximum number of results automatically generated by the test, and the statement other than the first coverage result is used as the test target. Exception error test cases for strategies;

The abnormal error test case is used to detect the abnormal error contained in the newly submitted source program.

With reference to the first aspect, further, if the newly submitted source program fails to pass the first-stage verification or the second-stage verification, return to modify the new version of the software source program.

In conjunction with the first aspect, further, the method for generating the new version software includes:

The Checksum algorithm is used to calculate the total checksum of the binary version of the test program and the total checksum of the binary version of the new version of the software source program, and thereby generate the checksum file of the test program and the checksum file of the new version of the software source program;

Generate the new version software verification file according to the verification file of the test program and the verification file of the new version software source program;

Use GNU or Windows or .Net Framework style to formulate the version number of the test program and the version number of the new version software source program;

Combine the version number of the test program and the version number of the new version software source program to generate the new version software version number;

Generate a new version of the software according to the new version of the software verification file and the new version of the software version number.

With reference to the first aspect, further, the check file includes parity check code, XOR check code, CRC check code, LRC check code, Gray code check code, and MD5 check code.

In a second aspect, an embodiment of the present invention provides a regression test-driven software version management system, wherein the system includes:

The first verification module is used to perform the first-stage verification on the newly submitted source program by using the available test cases in the test program corresponding to the software source program of the previous version, and obtain the first coverage result;

Test case generation module: It is used to automatically generate test cases for newly submitted source programs according to the first coverage results;

The second verification module: used to use the generated test case to perform the second-stage verification on the newly submitted source program, and obtain the second coverage result;

Writing module: It is used to write new test cases and generate test programs for newly submitted source programs according to the results of the second coverage;

Calculation module: used to calculate the verification file and version number of the test program;

New version software generation module: used to generate new version software according to the verification file and version number of the test program, and the verification file and version number of the newly submitted source program.

In a third aspect, an embodiment of the present invention further provides a regression test-driven software version management system, including a processor and a storage medium;

the storage medium is used for storing instructions;

The processor is adapted to operate in accordance with the instructions to perform steps in accordance with the aforementioned method.

In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium on which a computer program is stored, characterized in that, when the program is executed by a processor, the steps of the foregoing method are implemented.

To sum up, the regression test-driven software version management method, system, and storage medium provided by the embodiments of the present invention can effectively solve the problems that current SVM tools cannot effectively support the management of test codes and regression test information cannot be fully utilized, thereby helping R&D personnel Improve the quality of software version management and improve the efficiency of software product development.

Description of drawings

1 is a flowchart of a regression test-driven software version management method provided by the implementation of the present invention;

Fig. 2 is the flow chart of software version automatic verification method among Fig. 1;

Fig. 3 is the flow chart of the test case automatic generation method in Fig. 1;

Fig. 4 is the flow chart of test version automatic management method among Fig. 1;

FIG. 5 is a flowchart of the method for automatic management of software versions in FIG. 1 .

Detailed ways

The present invention will be further described below in conjunction with the accompanying drawings. The following examples are only used to illustrate the technical solutions of the present invention more clearly, and cannot be used to limit the protection scope of the present invention.

1 is a flowchart of a regression test-driven software version management method provided by the implementation of the present invention, comprising the following steps:

Step1 Automatic verification of software version: For the source program version newly submitted by the user, analyze the available test cases in the test program corresponding to the source program of the previous version of this version, and use it to detect the defects in the newly submitted source program: if there is a defect, it indicates that If there is a problem with the source program, it needs to be modified and resubmitted; otherwise, it means that the source program has passed the first-stage verification, and the available test cases and their coverage information are output at this time to guide the automatic generation of the next-stage test.

Step2 Automatic generation of test cases: The non-covered statement in the previous step is the test target to automatically generate tests for the newly submitted source program, and continuously execute the newly generated test cases while generating to observe whether an abnormal error occurs in the newly submitted source program: if it occurs If it is abnormal, it indicates that there is a problem with the source program and needs to be modified and resubmitted; otherwise, it indicates that the source program has passed the second-stage verification, and the newly generated test case and coverage information are output to guide the next stage of test case writing. During automatic test generation, the satisfaction of results not covered by the previous stage builds stopping criteria.

Step3: Automatic management of test versions: The non-covered statements in the previous two steps are used as test targets to write test cases for the newly submitted source program, and the newly generated test cases are continuously executed while writing to detect defects in the newly submitted source program: if there is any Defects, it indicates that there is a problem with the source program and needs to be modified and resubmitted; otherwise, it indicates that the source program has passed the third-stage verification. At this time, a new test program is generated based on the test cases generated in the first two steps, and the check code of the test program is calculated and output. Checkout file for the test program.

Step4 Automatic management of software version: Calculate and generate the version number of the newly submitted source program, and cooperate with the test program version number to generate the software version number; analyze and generate the verification file of the newly submitted source program, and cooperate with the verification file of the test program to generate the software version number. Verification file: After the software version number and verification file are generated, they are saved in the software warehouse together with the newly submitted source program and its corresponding test program to complete the generation and registration of the new version of the software.

Fig. 2 is a flow chart of automatic verification of software version. For the newly submitted source program version, identify the test cases available for the newly submitted source program by analyzing the test program corresponding to the previous version, execute them to automatically verify the newly submitted source program, and generate coverage information to provide guidance for automatic test generation. . Specific steps are as follows:

Step 1: initial state;

Step 2: Enter the software repository SR and the current version Pi of the source program;

Step 3: determine whether Pi is the initial version P0, if so, go to step 4, otherwise go to step 6;

Step 4: Initialize the test case set Toldi as NULL;

Step 5: Initialize the coverage information cov(Toldi) of Toldi to NULL, and execute Step 10;

Step 6: Take out the software version Vi-1 of the previous version of Pi from the SR = <IDVi-1, Pi-1, Ti-1, CC_FILE_Vi-1>, IDVi-1, Pi-1, Ti-1, CC_FILE_Vi- 1 represents the version number, source program, test program and verification file of Vi-1 respectively;

Step 7: Identify all Pi available test cases in Ti-1 to form Toldi;

Step 8: Apply Pi to execute Toldi, further divide Toldi into successful test case set Told_passedi and failed test case set Told_failedi according to the execution result, and record the coverage information of Toldi;

Step 9: Determine whether the content in Told_failedi is NULL, if so, go to Step 10, otherwise go to Step 11;

Step 10: Pi passes the first stage verification, outputs Toldi and cov(Toldi), and executes Step 12;

Step 11: Pi fails Phase 1 verification, output Told_failedi;

Step 12: End state.

Figure 3 is a flow chart of automatic generation of test cases. The code area not covered by the previous version of the test program is used as the test target to carry out automatic test generation, and at the same time, the new generation program is used to carry out abnormal error detection of the source program of the new version, and the coverage information of the automatically generated test case is recorded. Build stopping criteria with code coverage at test generation time. Specific steps are as follows:

Step 1: initial state;

Step 2: Input the current version Pi of the source program, the coverage information cov(Toldi) of Pi on Toldi and the window width window;

Step 3: Calculate the uncovered code area uncov(Toldi) in Pi;

Step 4: Initialize the test case set Tnew_autoi to be NULL, and initialize the value of each element in the coverage sequence listcov=<cov1,cov2,...,covwindow> to be empty;

Step 5: Randomly generate a test case t for Pi;

Step 6: Execute t and calculate the coverage information cov(t);

Step 7: judge whether an abnormality occurs when executing t, if so, go to step 14, otherwise go to step 8;

Step 8: Add t to Tnew_autoi, namely: Tnew_autoi=Tnew_autoi∪{t};

Step 9: Update coverage sequence listcov;

Step 10: Determine whether cov(Tnew_autoi) contains all the statements in uncov(Toldi), if so, go to step 13, otherwise go to step 11;

Step 11: Determine whether the number of test cases in Tnew_autoi is greater than window, if so, go to Step 12, otherwise go to Step 5;

Step 12: Determine whether the values of each element in the listcov are the same, if so, go to step 13, otherwise go to step 5;

Step 13: Pi passes the second stage verification, outputs Tnew_autoi and cov(Tnew_autoi), and executes Step 15;

Step 14: Pi fails the phase 2 verification, output the test case t that causes Pi exception; Step 15: End state.

Figure 4 is a flow chart of automatic management of test versions. The code areas not covered by the previous version of the test program and automatically generated test cases are used as test targets to write test cases, and use this to detect defects in the newly submitted source program. After the verification of the source program is passed, the test program corresponding to the newly submitted source program, its version number and the verification file are generated in combination. Specific steps are as follows:

Step 1: initial state;

Step 2: Input the current version Pi of the source program, the test case Toldi available in the previous version, the coverage information cov (Toldi), and the automatically generated test case Tnew_autoi and the coverage information cov (Tnew_autoi);

Step 3: Calculate the uncovered code area uncov(Toldi∪Tnew_autoi) in Pi;

Step 4: Write a new test case Tnew_manuali for Pi with uncov(Toldi∪Tnew_autoi) as the test target;

Step 5: Apply Pi to execute Tnew_manuali, and further divide Tnew_manuali into a successful test case set Tnew_manual_passedi and a failed test case set Tnew_manual_failedi according to the execution result;

Step 6: Determine whether Tnew_manual_failedi is NULL, if so, go to Step 7, otherwise go to Step 12;

Step 7: Combine Toldi, Tnew_autoi and Tnew_manuali to generate the test program Ti corresponding to Pi;

Step 8: Use GNU, Windows, .Net Framework and other styles to formulate the version number IDTi of the test program Ti;

Step 9: Generate check codes of files such as Toldi, Tnew_autoi, Tnew_manuali, etc. by means of parity check, XOR check, CRC check, LRC check, Gray code check, MD5 check, etc.;

Step 10: adopt the Checksum algorithm to calculate the total checksum of the binary version of Ti, and thus generate a check file CC_FILE_Ti of Ti, the content of which includes the check codes of files such as Toldi, Tnew_autoi, Tnew_manuali, and Ti;

Step 11: Pi passes the third stage verification, outputs Ti, IDTi and CC_FILE_Ti, and executes step 13;

Step 12: Pi fails the third stage verification, output Tnew_manual_failedi; Step 13: End state.

FIG. 5 is a flowchart of automatic management of software versions. Analyze and generate the version number of the newly submitted source program, and cooperate with the version number of the test program to generate the version number of the new version software; analyze and generate the verification file of the newly submitted source program, and cooperate with the verification file of the test program to generate the verification file of the new version software. Verify files; add new versions to the software repository, and complete the registration and release of new software versions. Specific steps are as follows:

Step 1: initial state;

Step 2: Input the current version Pi of the source program and the corresponding test program Ti, the test program version number IDTi and the verification file CC_FILE_Ti;

Step 3: Use GNU, Windows, .Net Framework and other styles to formulate the version number IDPi of the source program;

Step 4: combine the source program version number and the test program version number to generate the software version number IDVi=<IDPi, IDTi>;

Step 5: adopt the Checksum algorithm to calculate the total checksum of the Pi binary version, and thereby generate the check file CC_FILE_Pi of the Pi, and its content includes the check codes of files such as CC_FILE_Pi;

Step 6: Combine the contents in CC_FILE_Pi and CC_FILE_Ti to generate the verification file CC_FILE_Vi of the software version Vi, and its contents include the verification codes of Pi, Toldi, Tnew_autoi, Tnew_manuali, Ti and other files;

Step 7: Add the software version Vi=<IDPi, Pi, Ti, CC_FILE_Vi> to the software repository SR;

Step 8: Output the current software repository SR and software version Vi;

Step 9: End state.

To sum up, the present invention solves the problems that the current SVM tool cannot effectively support the management of test codes and the regression test information is not fully utilized, thereby enhancing the function of the SVM tool software product, helping the R&D personnel to improve the quality of software version management, and finally playing the role of The purpose of improving the research and development efficiency of software products and ensuring the quality of software products.

An embodiment of the present invention further provides a regression test-driven software version management system, the system can be used to execute the foregoing regression test-driven software version management method, including:

The first verification module is used to perform the first-stage verification on the newly submitted source program by using the available test cases in the test program corresponding to the software source program of the previous version, and obtain the first coverage result;

Test case generation module: It is used to automatically generate test cases for newly submitted source programs according to the first coverage results;

The second verification module: used to use the generated test case to perform the second-stage verification on the newly submitted source program, and obtain the second coverage result;

Writing module: It is used to write new test cases and generate test programs for newly submitted source programs according to the results of the second coverage;

Calculation module: used to calculate the verification file and version number of the test program;

New version software generation module: used to generate new version software according to the verification file and version number of the test program, and the verification file and version number of the newly submitted source program.

The embodiment of the present invention also provides a regression test-driven software version management system, which can also be used to execute the foregoing regression test-driven software version management method, including a processor and a storage medium;

the storage medium is used for storing instructions;

The processor is adapted to operate in accordance with the instructions to perform steps in accordance with the aforementioned method.

Embodiments of the present invention further provide a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, implements the steps of the foregoing method.

The above are only the preferred embodiments of the present invention. It should be pointed out that for those skilled in the art, without departing from the technical principle of the present invention, several improvements and modifications can be made. These improvements and modifications It should also be regarded as the protection scope of the present invention.

Claims (8)

1. a software version management method driven by regression test, is characterized in that, described method comprises the steps: Use the available test cases in the test program corresponding to the previous version of the software source program to perform the first-stage verification of the newly submitted source program, and obtain the first coverage result; According to the first coverage results, automatically generate test cases for the newly submitted source program; Use the generated test case to perform the second-stage verification on the newly submitted source program, and obtain the second coverage result; According to the second coverage results, write new test cases and generate test programs for newly submitted source programs; Calculate the verification file and version number of the test program, and generate a new version of the software in combination with the verification file and version number of the newly submitted source program; The method for the second stage verification includes: Given the source program of the current software version, the first coverage result and the maximum window width, the width is used to limit the maximum number of automatically generated results for the test, and the statement other than the first coverage result is used as the test target. Exception error test cases for strategies; The abnormal error test case is used to detect the abnormal error contained in the newly submitted source program. 2. The regression test-driven software version management method according to claim 1, wherein the method for obtaining the available test case comprises: Find the test case of the previous software version according to the given software repository and the source program of the current software version; The usability analysis is performed on the test cases of the previous software version, and the available test cases obtained by the analysis are used as the available test cases of the new version software source program. 3. The software version management method driven by regression testing according to claim 1, characterized in that, if the new submitted source program fails to pass the first stage verification or the second stage verification, then return to modify the new version software source program. 4. The software version management method driven by regression testing according to claim 1, wherein the method for generating the new version software comprises: The Checksum algorithm is used to calculate the total checksum of the binary version of the test program and the total checksum of the binary version of the new version of the software source program, and thereby generate the checksum file of the test program and the checksum file of the new version of the software source program; Generate the new version software verification file according to the verification file of the test program and the verification file of the new version software source program; Use GNU or Windows or .Net Framework style to formulate the version number of the test program and the version number of the new version software source program; Combine the version number of the test program and the version number of the new version software source program to generate the new version software version number; Generate a new version of the software according to the new version of the software verification file and the new version of the software version number. 5. the software version management method driven by regression test according to claim 4, is characterized in that, in described check file, comprises parity check code, XOR check code, CRC check code, LRC check code, Gray code check code, MD5 check code. 6. A software version management system driven by regression testing, wherein the system comprises: The first verification module is used to perform the first-stage verification on the newly submitted source program by using the available test cases in the test program corresponding to the software source program of the previous version, and obtain the first coverage result; Test case generation module: It is used to automatically generate test cases for newly submitted source programs according to the first coverage results; The second verification module: used to use the generated test case to perform the second-stage verification on the newly submitted source program, and obtain the second coverage result; Writing module: It is used to write new test cases and generate test programs for newly submitted source programs according to the results of the second coverage; Calculation module: used to calculate the verification file and version number of the test program; New version software generation module: used to generate new version software according to the verification file and version number of the test program, and the verification file and version number of the newly submitted source program; The method for the second stage verification includes: Given the source program of the current software version, the first coverage result and the maximum window width, the width is used to limit the maximum number of automatically generated results for the test, and the statement other than the first coverage result is used as the test target. Exception error test cases for strategies; The abnormal error test case is used to detect the abnormal error contained in the newly submitted source program. 7. A software version management system driven by regression testing, comprising a processor and a storage medium; the storage medium is used for storing instructions; The processor is configured to operate according to the instructions to perform the steps of the method according to any one of claims 1-5. 8. A computer-readable storage medium on which a computer program is stored, characterized in that, when the program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images