CN108959059A

CN108959059A - A kind of test method and test platform

Info

Publication number: CN108959059A
Application number: CN201710355686.XA
Authority: CN
Inventors: 赵丽娟; 谭春林; 胡娇; 汪花梅; 张威; 胥敏; 张迪
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2017-05-19
Filing date: 2017-05-19
Publication date: 2018-12-07
Anticipated expiration: 2037-05-19
Also published as: CN108959059B

Abstract

This application provides a kind of test methods, comprising: receives the first coverage rate file that test terminal is sent；Wherein, the first coverage rate file includes the line number of tested application name, version number and the code for being performed covering；According to received first coverage rate file version number and itself storage coverage rate file version number by received first coverage rate file and itself storage the second coverage rate file carry out Data Integration, update the second coverage rate file；And it is reported according to updated second coverage rate file generated coverage rate.Present invention also provides the test platforms for executing the above method.

Description

Test method and test platform

Technical Field

The present application relates to the field of information technologies, and in particular, to a test method and a test platform applied to code testing.

Background

Currently, with the rapid development of the mobile internet, the release pace of more and more mobile internet products is becoming faster and the requirement on quality is higher and higher, so how to quantitatively evaluate the release quality of the products becomes more and more important; and as code instrumentation becomes easier, code coverage is being cited by more and more test teams as one of the important assessment tools.

Disclosure of Invention

The examples of the present application propose a test method. The test method comprises the following steps: receiving a first coverage rate file sent by a test terminal; wherein the first coverage file comprises a name and a version number of the tested application program and a line number of the code covered by the execution; performing data integration on the received first coverage rate file and the second coverage rate file stored by the first coverage rate file according to the version number of the received first coverage rate file and the version number of the second coverage rate file stored by the first coverage rate file, and updating the second coverage rate file; and generating a coverage report according to the updated second coverage file.

The application also provides a test platform. This test platform includes:

the coverage rate file collection server is used for receiving the coverage rate file sent by the test terminal; the coverage rate file comprises a tested application program name, a version number and a line number of an executed coverage code; and

the coverage report generation server is used for integrating the received first coverage file and the second coverage file stored by the coverage report generation server according to the version number of the received first coverage file and the version number of the second coverage file stored by the coverage report generation server, and updating the second coverage file; and generating a coverage report according to the updated second coverage file.

Examples of the present application also propose a computer-readable storage medium having stored thereon computer instructions, wherein the computer instructions, when executed by a processor, implement the steps of the above-mentioned method.

By the test scheme and the test platform, testers can download the test packages at any time to test at any time, and can feed back the coverage rate files obtained by the testers to the test platform at any time to perform coverage rate data integration, and the versions of the test packages tested by the testers are not limited to be the same. The test flow is more suitable for the requirements of the application program on rapidness and test at the present stage, and allows a plurality of persons to simultaneously perform parallel test on different parts of the same application program, so that the rapid test is realized.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without creative efforts.

FIG. 1 is a schematic diagram of a system architecture according to an example of the present application;

FIG. 2 is a flow chart of a testing method according to an embodiment of the present application;

FIG. 3 is a flowchart illustrating a method for integrating data of a coverage file received from a test terminal with a coverage file stored in a test platform according to an embodiment of the present application;

FIG. 4 is a flow chart of a testing method according to another embodiment of the present application;

FIG. 5 is a flow chart of a testing method of another embodiment of the present application;

FIG. 6 is a schematic structural diagram of a test platform according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a server according to an example of the present application.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

For simplicity and clarity of description, the invention will be described below by describing several representative embodiments. The numerous details of the examples are merely provided to assist in understanding the inventive arrangements. It will be apparent, however, that the invention may be practiced without these specific details. Some embodiments are not described in detail, but rather are merely provided as frameworks, in order to avoid unnecessarily obscuring aspects of the invention. Hereinafter, "including" means "including but not limited to", "according to … …" means "at least according to … …, but not limited to … … only". When the number of one component is not particularly specified hereinafter, it means that the component may be one or more, or may be understood as at least one.

In the research process, the inventor of the present invention finds that the most common in the existing technical solutions is to peg the code of an application program and then generate a single test package, test the test package, and generate a corresponding coverage file, but this solution is only effective for a very small scale (such as 1 person) of a test team at present. Once the number of the test team reaches 2 or more than 2, the scheme lacks the capability of coping; and when the testing personnel need to change the test package, the timely test can not be realized, and the guiding significance to the actual production is not strong.

In order to solve the above problems, the present application provides a test platform, which can solve the problem of multi-user parallel test, adapt to a continuously updated continuous integrated test package code development environment, and prompt a tester to add a test case to perform a supplementary test according to a test coverage condition so as to make code coverage data reach the standard. On the other hand, the test platform can be attached to research and development processes in all directions, and is suitable for development environments of application programs with higher speed and larger scale.

In some examples of the application, the test platform may integrate data of a coverage file generated in a test process uploaded by each tester, and may determine a code coverage rate of the test process, for example, a differential code coverage rate, so that test work of application software may be monitored and managed. The differential code coverage rate corresponds to an incremental development mode based on a version, and the specific meaning of the differential code coverage rate is that after the differential code of the current version and the differential code of the last version are tested, the ratio of the number of rows of the covered code in the test to the total number of rows of the differential code is obtained. The code test condition of the updated part of the tested application program can be known through the differential code coverage rate.

Fig. 1 shows a schematic structural diagram of a system applied to a test platform according to some examples of the present application. As shown in fig. 1, the system of the present application includes at least: a research and development management server 11, a test platform 12, a test terminal 13, a network 14, and a code management tool (SVN, abbreviation for sub version) server 15.

In some examples of the present application, the SVN server 15 is configured to manage code files of various versions of an application. Specifically, the SVN server 15 may receive and store one or more code modification records (SVN logs) uploaded by developers via SVN clients. The code modification record may include a description of one or more modified codes (specifically, a description of functions implemented by the modified codes and/or a description of requirements to be solved) and a specific modified code file. In addition, the SVN server 15 may maintain the complete code files of a certain application program under different versions according to the code files uploaded by the developers through the SVN clients.

In some examples of the present application, the research and development management server 11 may be a persistent integration server, and may obtain a code file of a certain version of the application program to be tested from the SVN server 15, and generate a test package to be tested, which is identified by the name and version number of the application program to be tested, through an instrumentation operation. In some examples of the present application, the research and development management server 11 may generate the test package according to the code file acquired from the SVN server 15 at a predetermined frequency, for example, the research and development management server 11 may generate the test package according to the acquired code file every day or every half day.

In some examples of the present application, the test terminal 13 may include, but is not limited to, a smart phone, a PAD, a notebook computer, and a personal computer. These test terminals have operating systems installed thereon, including but not limited to: the Android operating system, the Symbian operating system, the Windows mobile operating system, and the apple iPhone OS operating system, among others. The test terminal 13 is mainly used for obtaining the test package from the research and development management server 11, installing and testing the test package, generating a coverage rate file, and sending the coverage rate file generated in the test process to the test platform 12. The coverage rate file may include a name and a version number of the application program to be tested, and a line number of a code covered by the current test execution in the application program to be tested. In some examples, the coverage file may further include a code segment of the current test.

In some examples of the present application, the test platform 12 may implement the following functions: and performing data integration on the coverage rate report received from the tester, and generating a code coverage rate report according to a data integration result. In some examples, the test platform 12 may include: a coverage file collection server 101 and a coverage report generation server 102. The coverage rate file collection server 101 may access an external network, may only be accessed by an authorized terminal, and is mainly used for collecting coverage rate files generated by different testing personnel through testing from the testing terminal 13. The coverage report generating server 102 may access an internal local area network, and may obtain a coverage file from the coverage file collecting server 101, perform data integration, and generate a coverage report according to a data integration result. The test platform 12 may pull a version of the code file of the application under test from the SVN server 15 at any time during the data integration process.

In addition, the test platform 12 may also implement a function of distributing test tasks, and in this case, the test platform 12 further includes a test management server 103. The test management server 103 may access an internal local area network, and may be configured to obtain a code modification record (SVN log) uploaded by a developer from the SVN server 15, and issue the code modification record as a test task. Meanwhile, the testing platform 12 will also provide a testing task claiming interface for the testers to claim their testing tasks, and after the testers claim the testing tasks, record their corresponding testers for code modification. In addition, the test management server 103 may further provide a test task allocation interface for the test principal, so that the test principal may perform secondary allocation on the code modification record that is not claimed.

The coverage file collection server 101, the coverage report generation server 102, and the test management server 103 included in the test platform 12 may be physically independent from each other, or may be integrated into one server, which is not limited herein.

The network 14 may include a wired network and a wireless network for implementing links and communications between the research and development management server 11, the test platform 12, and the test terminal 13. As shown in fig. 1, on the access network side, the test terminal 11 may access the network 14 in a wireless manner or in a wired manner; on the core network side, the test platform 12 and the r & d management server 11 are typically connected to the network 14 by wire. Of course, the test platform 12 and the research and development management server 11 may also be connected to the network 14 in a wireless manner.

Based on the system architecture and the architecture of the test platform 12 shown in fig. 1, the example of the present application provides a test method that can determine the code coverage of the test process. Fig. 2 shows a flow chart of a testing method provided in an example of the present application. As shown in fig. 2, the method may be performed by the test platform 12, including the steps of:

step 201: the coverage file sent by the test terminal 13 is received.

In the present example, the test platform 12 will receive one or more coverage files from one or more tests 13, respectively.

As mentioned above, the coverage file is generated by the test terminal 13 after testing a code modification record. The coverage file may include the name and version number of the application program to be tested, for example, the name and version number of the application program to be tested, and may further include the line number of the code covered by the execution of the test in the application program to be tested. In some examples of the present application, the coverage file may further include a code segment to be tested. In an example of the present application, a line number of a code covered by the execution of the current test in the application program to be tested included in the coverage file may be referred to as coverage data.

In general, a developer may modify one or more lines in the code file of the application under test in order to meet new requirements of the user of the application under test or to repair defects of the application under test. And after the code modification is completed, the research and development staff upload one or more modified code modification records and corresponding code files to the SVN server 15 through the SVN client. Wherein, each code modification record comprises the description of the one or more modified codes and the like.

After the test personnel claim or is allocated with the code modification record, the code modification record which is claimed or allocated is tested, and after the test is finished, a coverage rate file is generated according to the test result so as to identify the information such as the name and the version of the application program which is tested at this time, the line number of the code which is covered by the execution of the test at this time and the like. As mentioned above, the coverage file may be identified by the name and version number of the application program to be tested, and the file may further include the line number of the code covered by the execution of the test in the application program to be tested, and may further include the code segment to be tested.

In some examples, the assignment of code modification records to testers may also be performed by the testing platform 12, i.e., the testing platform 12 will receive the code modification records to be tested from the SVN server 15 and issue to one or more testers. To accomplish the assignment of test tasks, test platform 12 may provide a test task recognition interface for testers to recognize code modification records for conducting tests. Specifically, the test platform 12 may obtain a code modification record from a code management tool on the research and development management server 11, and generate a code modification record list; receiving keywords input by a tester, and searching and displaying code modification records related to the keywords from a code modification record list according to the keywords and the description of the code modification records; and responding to the claim operation of the tester, and adding the identity of the tester on the code modification record. And the operation of adding the identity of the tester to the code modification record indicates that the code modification record is claimed by the tester, and the tester tests the code modification record on the test terminal.

For example, a certain tester is responsible for testing the "play" module, and may search the keyword "play" on the Web page provided by the test platform, and after receiving the "play" keyword, the test platform 12 may search the code modification record related to "play" in the code modification record list according to the obtained description of the code modification record, and display the code modification record. The tester may click on the claim to claim the displayed code modification record associated with "play", and test platform 12, in response to the claim operation, adds the tester's identity to the claimed code modification record, identifying the code modification record as being claimed by the tester.

Furthermore, since some requirements to be solved by the code modification records can be distributed to different testers, some code modification records are missed, that is, the testers do not claim the code modification records, and secondary distribution of the test responsible persons is needed. To address this problem, the test platform 12 may further provide a test task allocation interface for the test responsible person to perform test task allocation. Specifically, the test platform 12 screens and displays the code modification record without adding the identity identifier of the tester in response to the query operation of the test responsible person; responding to the operation of adding the identity of the tester on a certain code modification record by the test responsible person, and adding the identity of the tester added by the test responsible person on the corresponding code modification record to complete the distribution of all the code modification records. Of course, the test responsible person can also check the distribution of all test tasks through the test task distribution interface, and the test platform 12 should also allow the test responsible person to change the tester who has a certain code modification record, so as to implement the macro deployment and management of the test tasks.

Step 202: and performing data integration on the received coverage rate file and the coverage rate file stored by the coverage rate file according to the version number of the received coverage rate file and the version number of the coverage rate file stored by the coverage rate file, and updating the coverage rate file stored by the coverage rate file.

In some examples of the present application, to integrate coverage files generated for different versions of test packages, the test platform will store a coverage file corresponding to the latest version code file, which may be identified by the name and version number of the application under test, for example, and include, for example, the line number of the code of the version code file that has been covered by the execution, and so on. In addition, the test platform 12 may also store a code file corresponding to the version number of the coverage file described above. According to the coverage rate file, the test platform 12 may classify codes of the code file stored by itself, and may specifically be: code that can be overridden by execution, code that cannot be overridden by execution, and code that has been overridden by execution. The coverage file may be generated and saved by the test platform 12 during the data integration process. For example, if the application program is tested before the first version of the new application program, the coverage file saved by the testing platform 12 may be empty, and the coverage file saved by the testing platform may be continuously updated to correspond to the first version of the new application program in the subsequent process of performing data integration on the coverage file of the application program. For another example, before the differential code test is performed, the coverage rate file stored by the test platform 12 may be a coverage rate file corresponding to a previous version, and the coverage rate file stored by the test platform 12 may be continuously updated in a subsequent process of performing data integration on a new version of the coverage rate file so as to correspond to a current version. The test platform 12 may acquire the corresponding code file from the SVN server 15 in real time according to the version number of the own storage coverage file, if necessary, without storing the code file corresponding to the version number of the own storage coverage file.

In some examples, the coverage file collection server 101 of the test platform 12 will collect and cache one or more coverage files from one or more test terminals 13 and then wait for the coverage generation server 102 to pull the one or more coverage files. It should be noted that, in the example of the present application, since a plurality of testers perform testing in parallel, and since the time of the test package downloaded from the research and development management server 11 by each tester may be different, the versions of the test packages downloaded by each tester may also be different. That is, versions of the test packages corresponding to the coverage files collected by the coverage file collection server 101 from the respective test terminals 13 may be the same or different. Therefore, the test platform 12 first needs to consider the version problem when performing data integration on the coverage file and the coverage file saved by itself. Specifically, the test platform 12 first performs data mapping according to the version of the coverage file, and maps the coverage data in the received coverage file or the coverage file saved by itself to the coverage data of the code of the latest version in the versions. This process of data mapping may be referred to as data cleansing. This data cleansing operation may be performed by the coverage generation server 102.

Specifically, in some examples of the present application, the coverage generating server 102 may pull one coverage file, called a first coverage file, from the coverage file collecting server 101 at a time, compare the version number of the first coverage file with the version number of a second coverage file stored in the coverage generating server, and if the version numbers of the first coverage file and the second coverage file are the same, merge the first coverage file and the second coverage file, and store the merged coverage file as the second coverage file; if the version number of the first coverage rate file is smaller than the version number of the second coverage rate file, mapping the coverage rate data in the first coverage rate file to the version of the second coverage rate file, merging the first coverage rate file and the second coverage rate file, and storing the merged coverage rate file as the second coverage rate file; and if the version number of the first coverage rate file is greater than the version number of the second coverage rate file, mapping the coverage rate data in the second coverage rate file to the version of the first coverage rate file, merging the first coverage rate file and the second coverage rate file, and storing the merged coverage rate file as the second coverage rate file. The coverage generation server 102 may loop through the above process until all the coverage files collected by the coverage file collection server 101 are integrated with its own coverage file. Thereafter, the coverage generation server 102 can generate a coverage report from the integrated coverage data. The whole data integration process can also be executed circularly, so that the coverage rate report is generated periodically, and the execution frequency can be set arbitrarily according to the requirement, such as integration once every 5 minutes, and the like.

The above data integration process will be described in detail below with reference to specific examples and the accompanying drawings. Fig. 3 shows a flowchart of a method for integrating the coverage files received from the test terminal 13 and the coverage files stored in the test platform 12 itself according to an example of the present application. It should be noted that, in this example, the test platform 12 performs data integration on one or more coverage files received from the test terminal 13 and the coverage file stored therein one by one. For convenience of description, the coverage file received from the test terminal 13 is referred to as a first coverage file; the coverage file stored by itself is referred to as a second coverage file. In addition, in this example, for simplicity of description, the version number of the code file corresponding to the coverage file is also simply referred to as the version number of the coverage file. In this example, it is assumed that the test platform 12 stores a code file corresponding to the version number of the second coverage file. As shown in fig. 3, the method may include the steps of:

step 301: comparing the version number of the first coverage rate file with the version number of the second coverage rate file, and if the version number of the first coverage rate file is greater than the version number of the second coverage rate file, executing step 302; if the version number of the first coverage file is less than the version number of the second coverage file, performing step 303; if the version number of the first coverage file is equal to the version number of the second coverage file, step 304 is performed.

Step 302: according to the code file corresponding to the first coverage rate file and the code file corresponding to the second coverage rate file, the line number of the code recorded in the second coverage rate file and subjected to the coverage execution is updated to the line number of the corresponding code in the code file corresponding to the first coverage rate file, and then step 304 is performed.

In some examples, when the version number of the first coverage file is greater than the version number of the second coverage file, it indicates that the code file stored by the test platform 12 itself is not the latest version, and therefore, the code file needs to be updated, and therefore, in this case, the test platform 12 may obtain the code file corresponding to the version number of the first coverage file from the SVN server 15 according to the version number of the first coverage file.

In some examples of the present application, the test platform 12 will find a code segment corresponding to the function in the obtained code file according to the function of the code that has been covered in the second coverage file, and establish a mapping relationship between the corresponding code segments in the code files of the new and old versions. Next, the test platform 12 establishes a mapping relationship between the line numbers of the corresponding code segments in the code files of the new and old versions according to the mapping relationship between the corresponding code segments in the code files of the new and old versions. Thus, according to the mapping relationship between the line numbers established above, the test platform 12 may update the line number of the code that has been executed and covered and recorded in the second coverage rate file to the line number of the corresponding code in the obtained code file. Through the replacement operation, the coverage data in the second coverage file corresponds to the version of the first coverage file, that is, the first coverage file and the updated second coverage file both correspond to the newer version of the first coverage file and the updated second coverage file.

For example, in the case where the version number of the first coverage file is greater than the version number of the second coverage file, i.e. the version of the first coverage file is higher than the version of the second coverage file, the line numbers of the code implementing the "play" function recorded in the first coverage file for which the coverage has been performed are 10, 11, 12, and the number of lines of code implementing the "play" function recorded in the second coverage file for which an override has been performed is 21, 22, 23, the test platform 12 may establish a mapping relationship between a code segment implementing the "play" function in the code file corresponding to the first coverage file and a code segment implementing the "play" function in the code file recorded by itself through the above steps 302 and 303, thereby establishing a mapping between the two code file package line numbers 10, 11, 12 and 21, 22, 23. After the mapping relationship is established, the test platform 12 may replace the line numbers 21, 22, and 23 of the code recorded in the second coverage rate file and having been subjected to coverage by 10, 11, and 12.

Through the above process, the test platform 12 may implement mapping the coverage data in the second coverage file to the version of the first coverage file.

Step 303, updating the line number of the code which is recorded in the first coverage rate file and has been executed to the line number of the corresponding code in the code file corresponding to the second coverage rate file according to the code file corresponding to the second coverage rate file and the code file corresponding to the first coverage rate file, and then executing step 304.

The specific process of the above replacement operation may refer to the description of step 303. That is, the test platform 12 finds the code segment with the corresponding function in the code file stored in itself according to the function of the code recorded in the first coverage rate file, and establishes the mapping relationship between the corresponding code segments in the code files of the new and old versions. Next, the test platform 12 establishes a mapping relationship between the line numbers of the corresponding code segments in the code files of the new and old versions according to the mapping relationship between the corresponding code segments in the code files of the new and old versions. Therefore, according to the mapping relationship between the line numbers established above, the test platform 12 may update the line number of the code recorded in the first coverage rate file and subjected to coverage to the line number of the corresponding code in the code file stored in itself. Through the replacement operation, the coverage data in the first coverage file corresponds to the version of the second coverage file, that is, the first coverage file and the second coverage file both correspond to the newer version of the two.

For example, in the case that the version number of the first coverage file is smaller than the version number of the second coverage file, that is, the version of the first coverage file is lower than the version of the second coverage file, if the number of lines of the code implementing the "play" function, which has been overwritten, recorded in the first coverage file is 10, 11, 12, and the number of lines of the code implementing the "play" function in the code file stored in the code file is 21, 22, 23, the correspondence relationship between the number of lines 10, 11, 12 of the code implementing the "play" function in the code file corresponding to the first coverage file and the number of lines 21, 22, 23 of the code implementing the "play" function in the code file stored in the code file is established through the above step 304, so that the number of lines 10, 11, 12 of the code implementing the overwriting, recorded in the first coverage file is replaced with the number of lines 21, 22, 21, 23.

Through the above process, the test platform 12 may implement mapping the coverage data in the first coverage file to a version of the second coverage file.

Step 304: and merging the line number of the code which has been executed and covered in the first coverage rate file with the line number of the code which has been executed and covered in the second coverage rate file to obtain a merged code line number set which has been executed and covered.

In some examples of the present application, the merging may be embodied as a union operation, that is, a union operation is performed on the line number of the code that has been covered in the first coverage file and the line number of the code that has been covered in the second coverage file. For example, the line numbers of the code in the first coverage file for which coverage has been performed are 10, 11, and 12; the line numbers of the codes with coverage executed in the second coverage rate file are 21, 22 and 23, and the line numbers of the codes with coverage executed after combination are 10, 11, 12, 21, 22 and 23.

Step 305: and replacing the line number of the code which is recorded in the second coverage rate file and has been subjected to the coverage execution by the combined set of the line numbers of the code which has been subjected to the coverage execution so as to update the second coverage rate file.

Through the operations of the above steps, the test platform 12 may integrate the coverage data of the pulled first coverage file into the second coverage file, so that on one hand, the version of the coverage file stored by the test platform 12 is the latest of the two, and on the other hand, the coverage file stored by the test platform 12 includes the coverage data in the first coverage file.

Further, by repeatedly executing the above steps, the test platform 12 can integrate all coverage files received by the test platform 12 from the test terminal 13 into the coverage file stored in the test platform 12 one by one, and can ensure that the coverage file stored on the test platform 12 corresponds to the latest version of the code file. Next, the test platform 12 can obtain the coverage report corresponding to the latest version according to the coverage file.

It should be noted that the method shown in fig. 3 is also applicable to the case that the test platform 12 does not store the code file corresponding to the version number of the second coverage file, that is, if the code file corresponding to the version number of the second coverage file needs to be used in the method shown in fig. 3, the corresponding code file may be directly obtained from the SVN server 15 according to the version number. Moreover, the method of fig. 3 does not limit whether the first coverage file contains the code to be tested. In practical application, if the first coverage rate file contains the code to be tested, the subsequent data cleaning process can be directly carried out according to the code; if the first coverage rate file does not contain the code to be tested, the test platform 12 may obtain the code file of the version from the SVN server 15 at any time according to the version number of the first coverage rate file, so as to perform the subsequent data cleaning process.

The test method described in fig. 2 will be described further below, returning to fig. 2.

Step 203: and generating a coverage rate report according to the coverage rate file stored by the user.

As described above, the coverage file contains the line number of the code for which the coverage has been executed, and therefore, the coverage report can be obtained according to the number of the line numbers. The coverage report may include the code coverage of each code modification record, the differentiated code coverage, the code coverage of a certain functional module and/or the overall code coverage of the entire application software under test, and so on. The code coverage rates can indicate the coverage condition of the code test under different partition granularities of the code, for example, the code coverage rate of the code modification record represents the condition that one code modification record is covered by execution in the test; the code coverage rate of the functional module represents the condition that a certain functional module is covered by execution in the test; the differential code coverage rate represents the condition that the differential part in the code is covered in the test after the code of the current version and the code of the previous version are compared; and the whole code coverage rate refers to the execution coverage condition of the whole tested application program code in the test. These coverage rates reflect the test coverage of the same version of code from different levels.

In some examples, the code coverage rate of the code modification record may be a quotient of a number of lines of code covered by execution in a code segment corresponding to the code modification record and a total number of lines of the code segment corresponding to the code modification record. The differential code coverage rate is the quotient of the number of lines of the code covered by execution in the differential code of the two different versions of the application program to be tested and the total number of lines of the differential code. The code coverage rate of the functional module is the quotient of the row number of the code covered by execution in the code segment corresponding to a certain functional module of the tested application program and the total row number of the code segment corresponding to the functional module. The overall code coverage data is the quotient of the number of lines of the code covered by the execution in the application program to be tested and the total number of lines of the application program to be tested. And determining the code coverage rates according to the coverage rate file obtained through the data integration process so as to obtain a code coverage rate report.

In some examples of the present application, in order to perform the overall test of the application program, so that the test result reaches the standard, the test task may be further adjusted according to the code coverage report. Specifically, the test platform 12 may preset a code modification record code coverage qualification threshold, a module code coverage qualification threshold, a differentiated code coverage qualification threshold, and/or an overall code coverage qualification threshold. The size of the threshold can be set according to actual conditions or experience, and can be dynamically adjusted according to test requirements, such as setting the threshold to be 70% or the like. In this manner, after the test platform 12 generates the code coverage reports, each code coverage in the reports is compared with its corresponding coverage pass threshold, and if the code coverage in the reports is greater than or equal to its corresponding coverage pass threshold, the test is passed. And if the coverage rate is less than the corresponding coverage rate qualified threshold value, the test is not passed. At this time, the relevant tester needs to be prompted to increase the coverage rate of the test case for testing again. In some examples, the relevant tester may be determined based on the identity of the tester added to the code modification record during test task claiming and/or test task assignment. For example, if the code coverage of some code modification records is found to be smaller than the coverage qualification rate threshold of the code modification records through the comparison process, it is indicated that the test work of the code modification records does not meet the standard, and the testers corresponding to the code modification records need to be notified to perform retest or supplementary test. If the code coverage of some functional modules is found to be smaller than the coverage qualification rate threshold of the functional modules through the comparison process, the test work of the functional modules is unqualified, testers corresponding to the functional modules need to be informed that the functional modules do not reach the standard in the test, code modification records with low coverage can be displayed to the testers according to the code coverage of each code modification record, and the testers are prompted to add test cases according to the code modification records with low coverage and execute the test to regenerate the coverage until the overall test reaches the standard. Similarly, if the differentiated code coverage rate is smaller than the differentiated code coverage rate qualified threshold or the overall code coverage rate is smaller than the overall code coverage rate qualified threshold, all testers are prompted that the test does not reach the standard, code modification records with low coverage rate can be displayed to the testers according to the code coverage rate of each code modification record, the testers are prompted to add test cases aiming at the code modification records with low coverage rate, and the test is executed to regenerate the coverage rate until the overall test reaches the standard. It should be noted that, in the above test and inspection method according to the code coverage rate, the differentiated code coverage rate, the overall coverage rate and the functional module code coverage rate recorded by the code modification, in the whole test process, the inspection can be performed alternately, or the inspection can be performed with emphasis according to the habits and the emphasis of different testers, so that the coverage rates of various codes reach the standard at the same time, that is, when the coverage rates are all greater than the corresponding coverage rate threshold values, the whole test can be considered to pass. Moreover, the low coverage code modification record may be a relative concept or an absolute concept. For example, the test platform 12 may sort the coverage of each code modification record, obtain N code modification records with the lowest coverage, and prompt the tester corresponding to the code modification records. In this case, low coverage is a relative concept. For another example, the testing platform 12 may compare the coverage of each code modification record with a predetermined threshold (which may be the same as or different from the previously set pass threshold of the code modification record), obtain M code modification records below the threshold, and prompt the testers corresponding to the code modification records. In this case, low coverage is an absolute concept.

Fig. 4 shows a flowchart of a testing method provided in the present application example. As shown in fig. 4, the method may be performed by the test terminal 13, comprising the steps of:

step 401: the test package to be tested is acquired from the research and development management server 11.

In some examples, the research and development management server 11 obtains the code file uploaded by the research and development personnel through the code management tool thereon, and generates the test package to be tested with the name and version number of the application to be tested as the identifier. Therefore, in this example, the test terminal 13 may download the test package to be tested from the research and development management server 11 and install the test package into its own system, so that the tester may perform subsequent tests.

Step 402: and responding to the test operation of a tester, mapping the test operation to the specific code of the test packet, namely covering the specific code, and generating a coverage rate file.

In some examples, the tester may perform a test operation on the test terminal 13 according to a pre-designed test case, and the test terminal 13 may map the test operation to a specific code through an instrumentation code, that is, overlay the test operation on the specific code, generate a coverage rate file according to the specific code overlaid by the test operation, and record a line number of the code overlaid by the execution in the test.

For example, a certain tester is responsible for a "home page" module, and the tester may perform a corresponding test operation on a "home page" page displayed on the test terminal according to a pre-designed test case, such as clicking a login button of the "home page" and the like, in response to the operation of clicking the login button, the test terminal 13 may execute a code related to the clicked login to test whether the code has a defect, and meanwhile, the operation of clicking the login button by the user may be mapped to a code segment associated with the clicked login in the tested code through the instrumentation code, and a row number of the code covered by the execution in the operation is determined and recorded in the generated coverage rate file.

Step 403: the coverage file is sent to the test platform 12.

After the tester completes the test of the modification record or a function for a certain code, the test terminal 13 will submit the coverage file generated in the test process to the test platform 12.

By the method, the test terminal 13 can download the test package from the research and development management server 11 at any time, test at any time, and feed back the coverage rate file obtained by the test to the test platform 12 at any time for coverage rate data integration, and the versions of the test packages tested by a plurality of parallel testers are not limited to be the same. The test flow is more suitable for the requirements of rapid development and rapid test of the application program at the present stage, and allows a plurality of persons to simultaneously perform parallel test on different parts of the same application program, thereby realizing rapid test.

Furthermore, since the testing platform 12 provides a testing task claiming interface for the tester, the testing terminal 13 may further respond to the testing task query operation of the tester to display to the tester a code modification record to be tested that meets the query condition of the tester (for example, by keyword query), for the tester to claim; and responding to the claim operation of the tester, feeding back the identification of the code modification record and the identity identification of the tester to the test platform, and recording the tester of the code modification record by the test platform.

Through the establishment and distribution process of the test tasks, the tasks of the code test can be conveniently managed, and the test efficiency is improved, so that the requirements of rapid development and rapid test of application programs at the current stage are better met.

The operation of the test platform will be further described with reference to the accompanying drawings and a specific example. FIG. 5 shows an example of a code testing process. As shown in fig. 5, the code testing process mainly includes the following steps:

step 501: the test platform 12 acquires the code modification record from the research and development management server 11, and generates a code modification record list.

Step 502: receiving a test task query request which is input by a tester on a test task claim interface and contains keywords, searching a code modification record list according to the keywords, and displaying code modification records related to the keywords.

Step 503: and in response to the claiming operation of the tester, adding the identity of the tester on the code modification record to indicate that the code modification record is claimed by the tester.

Step 504: and responding to the test task query operation input by the test responsible person on the test task allocation interface, and displaying the code modification record without adding the identity identification of the test person.

Step 505: responding to the operation of the identity of the testing personnel added by the code modification record by the testing responsible person, and adding the identity of the testing personnel on the code modification record to complete the distribution of all the code modification records.

Step 506: and receiving one or more first coverage rate files sent by one or more test terminals 13 after the code modification records are tested.

Step 507: respectively comparing the version numbers of the one or more first coverage files with the version number of a second coverage file stored by the test platform 12, and if the version number of the first coverage file is greater than the version number of the second coverage file, executing step 508; if the version number of the first coverage file is less than the version number of the second coverage file, go to step 509; if the version number of the first coverage file is equal to the version number of the second coverage file, step 510 is performed.

Step 508: a code file corresponding to the version number of the first coverage file is acquired from the SVN server 15, the line number of the code for which coverage has been performed recorded in the second coverage file is updated to the line number of the corresponding code in the acquired code file according to the acquired code file and the code file corresponding to the second coverage file stored in the SVN server, and then step 510 is performed.

Step 509, updating the line number of the code which is recorded in the first coverage rate file and has been executed and covered to the line number of the corresponding code in the code file corresponding to the second coverage rate file, and then executing step 510.

Step 510: and merging the line number of the code which has been executed and covered in the first coverage rate file with the line number of the code which has been executed and covered in the second coverage rate file to obtain a merged code line number set which has been executed and covered, and replacing the line number of the code which has been executed and covered and recorded in the second coverage rate file with the merged code line number set which has been executed and covered.

Step 511: and generating a coverage rate report according to the second coverage rate file.

The coverage report may include one or a combination of code coverage of each code modification record, code coverage of each functional module, differential code coverage, and overall code coverage.

Step 512: according to a code coverage rate qualified threshold value of a preset code modification record, comparing the code coverage rate of the code modification record in the coverage rate report with the code coverage rate qualified threshold value of the code modification record, and if the code coverage rate of the code modification record is greater than or equal to the code coverage rate qualified threshold value of the code modification record, marking the corresponding code modification record as passing the test; if the code coverage of the code modification record is less than the code coverage qualification threshold of the code modification record, go to step 513.

Step 513: and prompting a tester of the code modification record that the coverage rate of the code modification record is unqualified so as to supplement the coverage rate test case.

Step 514: according to a preset functional module/differentiation/whole code coverage rate qualified threshold; comparing the functional module/differentiation/whole code coverage rate in the coverage rate report with the functional module/differentiation/whole code coverage rate qualified threshold value, and prompting a tester that the whole test reaches the standard if the functional module/differentiation/whole code coverage rate is greater than or equal to the whole code coverage rate qualified threshold value; if the functional module/differential/overall code coverage is less than the overall code coverage pass threshold, then step 515 is performed.

Step 515: prompting a tester that the functional module/the differential/the overall test does not reach the standard, listing a code modification record with low coverage rate for the tester, prompting the tester corresponding to the code modification record with low coverage rate to add a test case and test to regenerate the coverage rate until the functional module/the differential/the overall test reaches the standard.

In some examples of the present application, the test platform 12 may sort the code coverage rate corresponding to each code modification record, list the first N code modification records with the lowest code coverage rate for the tester, and prompt the tester of the code modification records to perform the supplementary test. Or, the testing platform 12 displays M code modification records with the code coverage rate smaller than the code coverage rate qualified threshold of the preset code modification records, and prompts relevant testers of the code modification records to perform supplementary testing.

Corresponding to the above test method, the present application also provides a test platform 600 for implementing the above method.

In some examples of the present application, the implementation test platform 600 may be implemented by a structure diagram shown in fig. 6, and includes a coverage file collection server 601 and a coverage report generation server 602, where functions of the servers are as follows:

the coverage rate file collection server 601 is configured to receive a first coverage rate file sent by the test terminal 13;

the coverage report generating server 602 is configured to perform data integration on the first coverage file and the second coverage file stored in the coverage report generating server according to the received version number of the first coverage file and the version number of the second coverage file stored in the coverage report generating server, update the second coverage file, and generate a coverage report according to the second coverage file.

In some examples, the test platform 600 may further implement a function of distributing test tasks, in which case the test platform 600 may further include a test management server 603 configured to modify a record of a code to be tested from the research and development management server 11 and issue the record to one or more testers.

In some examples, the test management server 603 will also provide a test task claim interface for testers to claim code modification records that need to be tested. Specifically, the test management server 603 obtains the code modification record from the research and development management server 11, and generates a code modification record list; receiving a test task query request which is input by a tester on a test task claim interface and contains keywords, searching a code modification record list according to the keywords, and displaying code modification records related to the keywords; and in response to the claiming operation of the tester, adding the identity of the tester to the code modification record to indicate that the code modification record is claimed by the tester.

In some examples, the test management server 603 further provides a test task allocation interface for the test principal to perform test task allocation. Specifically, the test platform 12 screens and displays the code modification record without adding the identity identifier of the tester in response to the query operation of the test responsible person; responding to the operation of the identity of the testing personnel added by the testing responsible person on a certain code modification record to complete the distribution of all code modification records.

In some examples, coverage report generating server 602 may include a data cleansing module and a data consolidation module; the data cleaning module is used for pulling a first coverage rate file from the coverage rate file collection server, comparing the version number of the first coverage rate file with the version number of a second coverage rate file stored in the data cleaning module, and if the version numbers of the first coverage rate file and the second coverage rate file are the same, submitting the first coverage rate file and the second coverage rate file to the data merging module for data merging; if the version number of the first coverage rate file is smaller than the version number of the second coverage rate file, mapping the coverage rate data in the first coverage rate file to the version of the second coverage rate file, and submitting the mapped first coverage rate file and the mapped second coverage rate file to a data merging module for data merging; and if the version number of the first coverage rate file is greater than that of the second coverage rate file, mapping the coverage rate data in the second coverage rate file to the version of the first coverage rate file, and submitting the first coverage rate file and the mapped second coverage rate file to a data merging module for data merging. And the data merging module is used for merging the first coverage rate file and the second coverage rate file and saving the merged coverage rate file as the second coverage rate file.

In some examples, the coverage report generating server 602 may obtain the coverage report according to the number of the row numbers recorded in the coverage file for which coverage is performed. The coverage report may include the code coverage of each code modification record, the differentiated code coverage, the code coverage of a certain functional module, and/or the overall code coverage of the entire application software under test.

In some examples, the coverage report generating server 602 may further include a feedback module for setting a code coverage qualification threshold for the code modification record; comparing the code coverage rate in the code coverage rate report with the code coverage rate qualified threshold, and prompting a tester that the code test is passed if the code coverage rate is greater than or equal to the code coverage rate qualified threshold; and if the code coverage rate is less than the code coverage rate qualified threshold value, prompting the tester that the code test does not pass.

It should be noted that the coverage file collection server 601, the coverage report generation server 602, and the test management server 603 included in the test platform 600 may exist independently physically, or may be integrated into one server, which is not limited herein.

Fig. 7 is a schematic structural diagram of a server according to an embodiment of the present invention. The server may be a server in the test platform 600. Specifically, the method comprises the following steps:

the server 700 includes a Central Processing Unit (CPU)701, a system memory 704 including a Random Access Memory (RAM)702 and a Read Only Memory (ROM)703, and a system bus 705 connecting the system memory 704 and the central processing unit 701. The server 700 also includes a basic input/output system (I/O system) 706, which facilitates transfer of information between devices within the computer, and a mass storage device 707 for storing an operating system 713, application programs 714, and other program modules 715.

The basic input/output system 706 includes a display 708 for displaying information and an input device 709, such as a mouse, keyboard, etc., for a user to input information. Wherein the display 708 and the input device 709 are connected to the central processing unit 701 through an input output controller 710 connected to the system bus 705. The basic input/output system 706 may also include an input/output controller 710 for receiving and processing input from a number of other devices, such as a keyboard, mouse, or electronic stylus. Similarly, input-output controller 710 may also provide output to a display screen, a printer, or other type of output device.

The mass storage device 707 is connected to the central processing unit 701 through a mass storage controller (not shown) connected to the system bus 705. The mass storage device 707 and its associated computer-readable media provide non-volatile storage for the server 700. That is, the mass storage device 707 may include a computer-readable medium (not shown), such as a hard disk or CD-ROM drive.

Without loss of generality, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. Of course, those skilled in the art will appreciate that computer storage media is not limited to the foregoing. The system memory 704 and mass storage device 707 described above may be collectively referred to as memory.

According to various embodiments of the invention, server 700 may also operate as a remote computer connected to a network through a network, such as the Internet. That is, the server 700 may be connected to the network 712 through a network interface unit 711 connected to the system bus 705, or the network interface unit 711 may be used to connect to other types of networks or remote computer systems (not shown).

The memory further includes one or more programs, and the one or more programs are stored in the memory and configured to be executed by the CPU.

In addition, each of the embodiments of the present invention can be realized by a data processing program executed by a data processing apparatus such as a computer. It is clear that the data processing program constitutes the invention. Further, the data processing program, which is generally stored in one storage medium, is executed by directly reading the program out of the storage medium or by installing or copying the program into a storage device (such as a hard disk and/or a memory) of the data processing device. Such a storage medium therefore also constitutes the present invention. The storage medium may use any type of recording means, such as a paper storage medium (e.g., paper tape, etc.), a magnetic storage medium (e.g., a flexible disk, a hard disk, a flash memory, etc.), an optical storage medium (e.g., a CD-ROM, etc.), a magneto-optical storage medium (e.g., an MO, etc.), and the like.

The invention therefore also provides a storage medium in which a data processing program is stored which is designed to carry out any one of the embodiments of the method according to the invention described above.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. A differentiated code coverage resolution method, wherein the method comprises:

receiving a first coverage rate file sent by a test terminal; wherein the first coverage file comprises: the name and the version number of the tested application program and the line number of the code covered by execution in the tested application program;

performing data integration on the received first coverage rate file and the second coverage rate file stored by the first coverage rate file according to the version number of the received first coverage rate file and the version number of the second coverage rate file stored by the first coverage rate file, and updating the second coverage rate file; and

and generating a coverage rate report according to the updated second coverage rate file.

2. The method of claim 1, wherein the data consolidating the received first coverage file and the self-stored second coverage file according to the version number of the received first coverage file and the version number of the self-stored second coverage file comprises: executing the following processes for the received first coverage files one by one:

A. comparing the version number of the first coverage file to the version number of the second coverage file,

if the version number of the first coverage rate file is larger than that of the second coverage rate file, executing B;

if the version number of the first coverage rate file is smaller than the version number of the second coverage rate file, executing step C;

if the version number of the first coverage file is equal to the version number of the second coverage file, executing step D;

B. mapping the coverage data in the second coverage file to the version of the first coverage file, and then executing D;

C. mapping the coverage data in the first coverage file to a version of a second coverage file, and then executing D; and

D. and merging the first coverage rate file and the second coverage rate file, and saving the merged coverage rate file as a second coverage rate file.

3. The method of claim 2, wherein,

the mapping coverage data in the second coverage file to the version of the first coverage file comprises: updating the line number of the code which is recorded in the second coverage rate file and has been subjected to coverage into the line number of the corresponding code in the code file corresponding to the first coverage rate file according to the code file corresponding to the first coverage rate file and the code file corresponding to the second coverage rate file;

the mapping coverage data in the first coverage file to a version of the second coverage file comprises: updating the line number of the code which is recorded in the first coverage rate file and has been subjected to coverage into the line number of the corresponding code in the code file corresponding to the second coverage rate file according to the code file corresponding to the first coverage rate file and the code file corresponding to the second coverage rate file; and

the merging the first coverage rate file and the second coverage rate file includes: and merging the line number of the code which has been subjected to the coverage execution in the first coverage rate file with the line number of the code which has been subjected to the coverage execution in the second coverage rate file, and taking the merged line number set as the line number of the code which has been subjected to the coverage execution in the second coverage rate file.

4. The method of claim 3, wherein the updating the line number of the code recorded in the second coverage file and subjected to coverage to the line number of the corresponding code in the code file corresponding to the first coverage file comprises:

acquiring a code file corresponding to the first coverage rate file according to the version number of the first coverage rate file;

finding out code segments corresponding to the functions in the obtained code file according to the functions of the executed covered codes recorded in the second coverage rate file, and establishing a mapping relation between the corresponding code segments in the code files of the two versions of the first coverage rate file and the second coverage rate file;

establishing a mapping relation between the line numbers of the corresponding code segments in the two version code files according to the established mapping relation between the two corresponding code segments; and

and updating the line number of the code which is recorded in the second coverage rate file and is subjected to the coverage execution into the line number of the corresponding code in the acquired code file according to the established mapping relation between the line numbers of the corresponding code segments in the two version code files.

5. The method of claim 3, wherein the updating the line number of the code recorded in the first coverage file for which coverage has been performed to the line number of the corresponding code in the code file corresponding to the second coverage file comprises:

finding code segments corresponding to functions in code files corresponding to second coverage rate files stored in the code files according to the functions of the codes which are recorded in the first coverage rate files and executed with coverage, and establishing a mapping relation between the corresponding code segments in the code files of the two versions of the first coverage rate files and the second coverage rate files;

and updating the line number of the code which is recorded in the first coverage rate file and has been subjected to coverage into the line number of the corresponding code in the code file corresponding to the version number of the second coverage rate file according to the established mapping relation between the line numbers of the corresponding code segments in the two version code files.

6. The method of claim 3, wherein merging the line number of the code in the first coverage file for which coverage has been performed with the line number of the code in the second coverage file for which coverage has been performed comprises: and merging the line number of the code which has been subjected to the coverage in the first coverage rate file with the line number of the code which has been subjected to the coverage in the second coverage rate file.

7. The method of claim 1, wherein the method further comprises:

acquiring a code modification record, and generating a code modification record list;

receiving keywords input by a tester on a test task allocation interface, searching the code modification record list according to the keywords, and displaying code modification records related to the keywords; and

and in response to the claiming operation of the tester for a certain code modification record, adding the identity of the tester on the code modification record.

8. The method of claim 7, wherein the method further comprises:

responding to the query operation input by a test responsible person on a test task allocation interface, and querying and displaying a code modification record without adding a test person identity; and

and receiving the identity of the tester added by the test responsible person aiming at a certain code modification record, and adding the identity of the tester on the code modification record.

9. The method of claim 1, wherein the method further comprises:

setting a code coverage rate qualified threshold;

comparing the code coverage in the code coverage report with the code coverage qualification threshold, and prompting a tester that the code test passes if the code coverage is greater than or equal to the code coverage qualification threshold; and if the code coverage rate is less than the code coverage rate qualified threshold value, prompting the tester that the code test does not pass.

10. A test platform, wherein the test platform comprises:

the coverage report generation server is used for integrating the received first coverage file and the second coverage file stored by the coverage report generation server according to the version number of the received first coverage file and the version number of the second coverage file, and updating the second coverage file; and generating a coverage report according to the updated second coverage file.

11. The test platform of claim 10, wherein the coverage report generating server comprises a data cleansing module and a data consolidation module; wherein,

the data cleaning module is used for pulling a first coverage rate file from the coverage rate file collection server, comparing the version number of the first coverage rate file with the version number of a second coverage rate file stored in the data cleaning module, and if the version numbers of the first coverage rate file and the second coverage rate file are the same, submitting the first coverage rate file and the second coverage rate file to the data merging module for data merging; if the version number of the first coverage rate file is smaller than the version number of the second coverage rate file, mapping the coverage rate data in the first coverage rate file to the version of the second coverage rate file, and submitting the mapped first coverage rate file and the mapped second coverage rate file to a data merging module for data merging; if the version number of the first coverage rate file is larger than that of the second coverage rate file, mapping the coverage rate data in the second coverage rate file to the version of the first coverage rate file, and submitting the first coverage rate file and the mapped second coverage rate file to a data merging module for data merging;

and the data merging module is used for merging the first coverage rate file and the second coverage rate file and saving the merged coverage rate file as the second coverage rate file.

12. The test platform of claim 10, wherein said test platform further comprises:

the test management server is used for acquiring the code modification record to be tested and issuing the acquired code modification record to a tester; and providing a test task claiming interface for a tester to claim the code modification record for testing.

13. The test platform of claim 12, wherein the test management server is further configured to provide a test task allocation interface for a test principal to perform test task allocation.

14. The test platform of claim 10, wherein the coverage report generating server further comprises a feedback module to set a code coverage qualification threshold for code modification records; comparing the code coverage rate in the code coverage rate report with the code coverage rate qualified threshold, and prompting a tester that the code test is passed if the code coverage rate is greater than or equal to the code coverage rate qualified threshold; and if the code coverage rate is less than the code coverage rate qualified threshold value, prompting the tester that the code test does not pass.

15. A computer readable storage medium having computer instructions stored thereon, wherein the computer instructions, when executed by a processor, implement the steps of the method of any one of claims 1 to 10.