CN112181812A - Version testing method and device - Google Patents
Version testing method and device Download PDFInfo
- Publication number
- CN112181812A CN112181812A CN202010974108.6A CN202010974108A CN112181812A CN 112181812 A CN112181812 A CN 112181812A CN 202010974108 A CN202010974108 A CN 202010974108A CN 112181812 A CN112181812 A CN 112181812A
- Authority
- CN
- China
- Prior art keywords
- version
- code
- tested
- coverage information
- subprogram
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 223
- 238000000034 method Methods 0.000 claims abstract description 61
- 230000008569 process Effects 0.000 claims description 21
- 238000004590 computer program Methods 0.000 claims description 16
- 230000006870 function Effects 0.000 description 35
- 238000010586 diagram Methods 0.000 description 12
- 230000006872 improvement Effects 0.000 description 9
- 238000012545 processing Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 3
- 238000013522 software testing Methods 0.000 description 3
- 238000010998 test method Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 229920001296 polysiloxane Polymers 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3676—Test management for coverage analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/368—Test management for test version control, e.g. updating test cases to a new software version
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The specification discloses a method and a device for testing a version, wherein a testing platform can determine a version to be tested, test the version to be tested and determine code coverage information of the version to be tested. And then, acquiring each historical version corresponding to the version to be tested and the code coverage information of each historical version, determining the unchanged subprogram which is the same as the code of the version to be tested from the subprograms contained in the historical version aiming at each historical version, and determining the code coverage information corresponding to the unchanged subprogram from the code coverage information of the historical version to be used as the compensation coverage information corresponding to the historical version. And then, compensating the compensation coverage information corresponding to the historical version to the code coverage information of the version to be tested to obtain the compensated coverage information, determining the code test coverage rate corresponding to the version to be tested, and further executing a test task aiming at the version to be tested, thereby ensuring the accuracy when testing the version to be tested.
Description
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a method and an apparatus for version testing.
Background
In order to ensure that the developed software can normally run, the developed software needs to be tested in practical application. In software testing, the code testing coverage rate can be generally used to represent the completeness of software testing, and the higher the code testing coverage rate is, the more complete the software testing is represented, so that a tester can determine whether to perform more complete testing on the software according to the code testing coverage rate.
In practical application, the code test coverage rate can be represented by the ratio of the number of lines of the code line which has run after the test is completed to the number of lines of all code lines which need to be tested, if the code test coverage rate is small, a tester can determine the code lines which have not run in the test process, and test the code lines by reformulating the test task, so that the test integrity is ensured as much as possible, and the test efficiency of the codes is effectively improved.
Disclosure of Invention
The present specification provides a method and an apparatus for version testing, so as to determine a code testing coverage rate corresponding to a version to be tested.
The technical scheme adopted by the specification is as follows:
the present specification provides a method of version testing, comprising:
determining a code version to be tested as a version to be tested;
testing the version to be tested, and determining code coverage information of the tested version, wherein the code coverage information is used for representing a code which runs in the testing process of the version to be tested;
acquiring each historical version corresponding to the version to be tested and code coverage information of each historical version;
for each historical version, determining a subprogram which is the same as the code of the version to be tested from subprograms contained in the historical version to serve as an unchanged subprogram, and determining code coverage information corresponding to the unchanged subprogram from the code coverage information of the historical version to serve as compensation coverage information corresponding to the historical version;
compensating the compensation coverage information corresponding to the historical version to the code coverage information of the version to be tested to obtain compensated coverage information of the version to be tested under the historical version;
and determining the code test coverage rate corresponding to the version to be tested according to the compensated coverage information of the version to be tested under each historical version, and executing the test task aiming at the version to be tested according to the code test coverage rate.
Optionally, determining a subprogram that is the same as the code of the version to be tested from the subprograms included in the historical version, as an unchanged subprogram, specifically including:
determining a code line which is changed in the version to be tested compared with the historical version as a changed code line;
and regarding each subprogram in the historical version, if the subprogram is determined not to contain the changed code line, taking the subprogram as an unchanged subprogram.
Optionally, determining that the changed code line is not included in the subroutine specifically includes:
determining the line number of an initial code line and the line number of an end code line corresponding to the subprogram according to the code coverage information corresponding to the version to be tested, wherein the end code line is the last line of codes to be tested contained in the subprogram;
and if the line number corresponding to the changed code line is determined not to fall into the range of the line numbers from the initial code line to the termination code line, determining that the changed code line is not contained in the subprogram.
Optionally, the compensating coverage information corresponding to the historical version is compensated to the code coverage information of the version to be tested, so as to obtain compensated coverage information of the version to be tested under the historical version, and the method specifically includes:
determining a subprogram matched with the unchanged subprogram in the version to be tested as a target subprogram for each unchanged subprogram corresponding to the historical version;
determining code coverage information corresponding to the unchanged subprogram from compensation coverage information corresponding to the historical version;
and compensating the code coverage information of the version to be tested according to the code coverage information corresponding to the unchanged subprogram to obtain compensated coverage information of the version to be tested under the historical version, wherein the compensated coverage information comprises the compensated code coverage information corresponding to the target subprogram.
Optionally, the compensating coverage information corresponding to the historical version is compensated to the code coverage information of the version to be tested, so as to obtain compensated coverage information of the version to be tested under the historical version, and the method specifically includes:
determining a subprogram matched with the unchanged subprogram in the version to be tested as a target subprogram for each unchanged subprogram corresponding to the historical version;
determining the number of times that each code line contained in the target subprogram is operated during testing as a first number according to the code coverage information corresponding to the version to be tested, and determining the number of times that each code line in the unchanged subprogram is operated during testing as a second number according to the compensation coverage information corresponding to the historical version;
compensating the first times through the second times to obtain compensated coverage information of the target subprogram under the historical version;
and obtaining the compensated coverage information of the version to be tested under the historical version according to the compensated coverage information of each subprogram under the historical version included in the version to be tested.
Optionally, executing a test task for the version to be tested according to the code test coverage, specifically including:
and if the code testing coverage rate is not lower than the set coverage rate, determining the sub-programs which are not tested in the version to be tested according to the compensated coverage information of the version to be tested under each historical version, and executing the testing tasks aiming at the sub-programs which are not tested.
Optionally, the method further comprises:
and generating and displaying a test result page aiming at the version to be tested according to the code test coverage rate corresponding to the version to be tested, wherein the test result page is used for displaying the code test coverage rate corresponding to the version to be tested.
This specification provides an apparatus for version testing, comprising:
the version determining module is used for determining the code version to be tested as the version to be tested;
the information determining module is used for testing the version to be tested and determining code coverage information of the tested version, wherein the code coverage information is used for representing a code which runs in the testing process of the version to be tested;
the acquisition module is used for acquiring each historical version corresponding to the version to be tested and the code coverage information of each historical version;
a subprogram determining module, configured to determine, for each history version, a subprogram that is the same as the code of the version to be tested from the subprograms included in the history version, as an unchanged subprogram, and determine, from the code coverage information of the history version, code coverage information corresponding to the unchanged subprogram, as compensation coverage information corresponding to the history version;
the compensation module is used for compensating the compensation coverage information corresponding to the historical version to the code coverage information of the version to be tested to obtain compensated coverage information of the version to be tested under the historical version;
and the execution module is used for determining the code test coverage rate corresponding to the version to be tested according to the compensated coverage information of the version to be tested under each historical version, and executing the test task aiming at the version to be tested according to the code test coverage rate.
The present specification provides a computer-readable storage medium storing a computer program which, when executed by a processor, implements the above-described method of versioning.
The present specification provides an electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the above-mentioned versioning test method when executing the program.
The technical scheme adopted by the specification can achieve the following beneficial effects:
in the version testing method provided by the present specification, a testing platform may determine a code version to be tested as a to-be-tested version, test the to-be-tested version, and determine code coverage information of the to-be-tested version after testing, where the code coverage information is used to indicate a code that has been run by the to-be-tested version in a testing process. And then, acquiring each historical version corresponding to the version to be tested and the code coverage information of each historical version, determining a subprogram which is the same as the code of the version to be tested from the subprograms contained in the historical version as an unchanged subprogram for each historical version, and determining the code coverage information corresponding to the unchanged subprogram from the code coverage information of the historical version as compensation coverage information corresponding to the historical version. And then compensating the compensation coverage information corresponding to the historical version to the code coverage information of the version to be tested to obtain the compensated coverage information of the version to be tested under the historical version, determining the code test coverage rate corresponding to the version to be tested according to the compensated coverage information of the version to be tested under each historical version, and executing the test task aiming at the version to be tested according to the code test coverage rate.
It can be seen from the above method that the code test coverage rate of the version to be tested is not determined according to the code coverage information of the subroutine in which the code is changed, which ensures the rationality of the code coverage information determined based on the historical version to a certain extent, thereby further ensuring the accuracy when testing the version to be tested.
Drawings
The accompanying drawings, which are included to provide a further understanding of the specification and are incorporated in and constitute a part of this specification, illustrate embodiments of the specification and together with the description serve to explain the specification and not to limit the specification in a non-limiting sense. In the drawings:
FIG. 1 is a flow chart of a method for version testing in the present specification;
fig. 2 is a schematic flowchart of compensating code coverage information corresponding to a version to be tested, provided in this specification;
FIG. 3 is a schematic diagram of a version testing apparatus provided herein;
fig. 4 is a schematic diagram of an electronic device corresponding to fig. 1 provided in the present specification.
Detailed Description
In order to make the objects, technical solutions and advantages of the present disclosure more clear, the technical solutions of the present disclosure will be clearly and completely described below with reference to the specific embodiments of the present disclosure and the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present disclosure, and not all embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without any creative effort belong to the protection scope of the present specification.
In the actual software development process, in order to improve the functions of the software, the software code needs to be updated continuously, that is, the version of the software needs to be updated. Once a new version of software is developed, the new version needs to be tested to ensure that the software can be used by the user normally after the new version comes online. And the code test coverage rate obtained after the new version is tested can indicate the integrity degree of the new version.
In the prior art, the code test coverage rate corresponding to the new version may be determined by the code lines that have been run by the new version during the test process, the code lines that have been run by the new version during the history test in the unchanged code lines (the code lines that have not been changed compared with the new version) included in the history version (i.e., the history version corresponding to the new version), and all the code lines that need to be tested in the new version.
For example, assuming that the version a is a new version, and the version B is a historical version corresponding to the version a, if the line 2, 3, 4, 5, and 6 codes in the version a need to be tested, the line 5 and 6 codes are run during actual testing, which is equivalent to only 2/5 codes being covered during testing of the version a. Version a adds line 6 code and modifies line 4 code relative to version B, where line 2, 3, 4, 5 code in version B historically needs to be tested, where code that has run in the historical test on version B behaves as line 2, 3, 4 code. Since the 4 th line of code is changed, only 2 and 3 lines of code in the code run by the version B history test can be reflected in the code test coverage rate of the version a, that is, the code test coverage rate of the version a is 4/5.
The prior art determines the code test coverage rate in such a way that the historical test coverage condition of a code line (i.e., the condition that is executed in the test of the historical version) is ignored only when the code line is changed. However, in practical applications, if only one line of code in a function of a new version is changed, the function of the whole function may be greatly changed. In such a case, the function needs to be tested again in its entirety, and the code test coverage of the function in the historical version should not be considered in the code test coverage of the new version.
In order to solve the above problem, the present specification provides a version testing method, in which after a testing platform determines code coverage information of a version to be tested, according to the code coverage information of a historical version corresponding to the version to be tested, code coverage information corresponding to a subroutine in which a code in the historical version is not changed is determined, and the code coverage information of the version to be tested is supplemented according to the code coverage information, so as to determine a code testing coverage rate of the version to be tested. Compared with the prior art, the method has the advantages that the code test coverage rate of the version to be tested is not determined according to the code coverage information of the subprogram of which the code is changed, so that the rationality of the code coverage information determined based on the historical version is ensured to a certain extent, and the accuracy in testing the version to be tested is further ensured.
The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.
Fig. 1 is a schematic flow chart of a version testing method in this specification, which specifically includes the following steps:
s101: and determining the code version needing to be tested as the version to be tested.
In practical applications, in order to perfect the functions of the code, a developer needs to test the software version. Based on the method, the test platform can determine the code version needing to be tested as the version to be tested. The version to be tested mentioned here may refer to a new version to be tested obtained after the current developer updates the code, or may refer to an existing version to be tested according to actual needs.
The version test method provided in this specification may be specifically executed by a server or a terminal device such as a computer in a test platform, and for convenience of description, the version test method provided in this specification will be described below with only the test platform as an execution subject.
S102: and testing the version to be tested, and determining code coverage information of the tested version, wherein the code coverage information is used for representing a code which runs in the testing process of the version to be tested.
After the test platform tests the version to be tested, the code coverage information of the tested version to be tested can be determined. The code coverage information may include: the line number of each code line to be tested in the version to be tested and the running times of the code lines during testing, therefore, the code coverage information can represent the code lines which have run in the testing for the version to be tested.
For example, the code coverage information may be information in the form of:
FN:15,isURLEncoded
FN:24,throttle
DA:16,0
DA:21,1
DA:22,1
DA:25,0
the FN is used to indicate a line number of an initial code line corresponding to a subroutine and a subroutine identifier (i.e., a function name), where isURLEncoded in the first FN is the subroutine identifier, and 15 refers to the line number of the initial code line corresponding to the subroutine having the subroutine identifier isURLEncoded. The DA comprises the line number of the code line to be tested and the number of times the code line is run during testing, 16 in the first DA indicates that the 16 th line code needs to be tested, 0 behind 16 indicates that the 16 th line code is not run during testing, the second DA indicates that the 22 nd line code needs to be tested, and the 22 nd line code is run once during testing.
In practical application, the test platform may determine an info file including the code coverage information of the version to be tested by means of Icov and the like, and extract the code coverage information of the version to be tested by using the info file. Of course, besides the above-mentioned Icov, there may be other ways of determining the code coverage information, such as istanbul, and the like, which are not illustrated herein.
S103: and acquiring each historical version corresponding to the version to be tested and the code coverage information of each historical version.
After the testing platform determines the code coverage information corresponding to the version to be tested, in order to combine the testing result of each historical version corresponding to the version to be tested into the test of the version to be tested, it is necessary to obtain each historical version and the code coverage information of each historical version. The code coverage information of the historical version is consistent with the code coverage information of the version to be tested in form, and the code coverage information of the historical version can represent the code lines which have run in the test of the historical version.
S104: and for each historical version, determining a subprogram which is the same as the code of the version to be tested from subprograms contained in the historical version to be used as an unchanged subprogram, and determining code coverage information corresponding to the unchanged subprogram from the code coverage information of the historical version to be used as compensation coverage information corresponding to the historical version.
After the testing platform obtains the historical versions corresponding to the versions to be tested and the code coverage information corresponding to the historical versions, for each historical version, a subprogram which is the same as the code of the version to be tested is determined from the subprograms contained in the historical version and is used as an unchanged subprogram. The subroutine referred to herein is composed of a function, i.e., the lines of code referred to from the beginning of a function to the end of the function constitute a subroutine, and the function is used to implement the function corresponding to the subroutine. The subprogram whose codes are the same here refers to a subprogram whose codes are identical to those of each line of codes of the version to be tested in each subprogram included in the historical version, or refers to a subprogram whose codes are identical to those of each line of codes included in the historical version and the version to be tested if the codes of each line of codes included in the subprograms, which can have a large influence on functions of the subprogram, are identical.
Specifically, the subprogram that is the same as the code of the version to be tested is determined from the subprograms included in the history version, and there are various ways of determining the subprogram as an unchanged subprogram. For example, the test platform may determine, as a changed code line, a code line in the version to be tested that is changed from the historical version, and for each subroutine in the historical version, if it is determined that the determined changed code line is not included in the subroutine, take the subroutine as an unchanged subroutine.
For another example, the test platform may also determine, for each subprogram of the historical version, a subprogram in the version to be tested that is the same as the subprogram identifier of the subprogram, compare the codes of each line included in the two subprograms line by line, and if the codes of each line corresponding to the two subprograms are the same, take the subprogram in the historical version as an unchanged subprogram. The subroutine identification referred to herein may refer to a function name.
It should be noted that, the above-mentioned determination that the subroutine does not include the changed code line may be determined by the number of lines of the code line corresponding to the subroutine, and if the number of lines of the code line included in the subroutine is not consistent with the number of lines of the code line included in the subroutine having the same subroutine identifier as the subroutine in the version to be tested, the test platform may directly determine that the subroutine includes the changed code line, that is, the subroutine is the changed subroutine.
When the number of lines is consistent, the test platform may also determine, according to the code coverage information corresponding to the version to be tested, a line number of an initial code line and a line number of an end code line corresponding to the subroutine, and if it is determined that the line number corresponding to the changed code line does not fall within a range from the initial code line to the end code line, determine that the subroutine does not include the changed code line, where the end code line is a last line of codes to be tested included in the subroutine.
It should be noted that the code coverage information contained in the info file mentioned above may have various information, and in addition to the line number of each code line to be tested in the version to be tested mentioned above and the number of times these code lines are run during testing, the code coverage information may further include: the number of subprograms contained in the version to be tested, the subprogram identification of each subprogram, the line number of the initial code line corresponding to the subprogram, and the like.
Therefore, it is mentioned above that the line number of the initial code line corresponding to the subroutine may be directly obtained from the code coverage information corresponding to the version to be tested, and the line number of the termination code line corresponding to the subroutine may be determined from the line numbers of each code line to be tested included in the code coverage information corresponding to the version to be tested, where the line number of the termination code line corresponding to the subroutine is not less than the line number of the initial code line of the subroutine and is less than the maximum line number of the initial code line of the next subroutine, and if the subroutine is the last subroutine, the line number of the termination code line corresponding to the subroutine is the line number of the last code line to be tested.
Continuing with the previous example, the line number of the initial code line corresponding to the subroutine with subroutine id isURLEncoded is 15, the next subroutine of this subroutine is the subroutine with subroutine id throttle, and the line number of the initial code line of this subroutine is 24. The line number of the initial code line of the subroutine of isURLEncoded in the DA is not less than that of the subroutine of isURLEncoded, and the line numbers of the code lines of the initial code line of the subroutine of which is less than that of the triple are 16, 21 and 22, and since 22 is the maximum line number therein, 22 is the line number of the termination code line corresponding to the subroutine of isURLEncoded. the subroutine of the subroutine is the last subroutine, so the line number of the termination code line of the subroutine is 25.
After the testing platform determines each unmodified subprogram included in the historical version, the testing platform may determine, from the code coverage information of the historical version, the code coverage information corresponding to the unmodified subprograms as compensation coverage information corresponding to the historical version. The code coverage information corresponding to the unchanged subprogram mentioned here may represent the run code lines included in the unchanged subprogram in the history version test process. The compensation overlay information mentioned here is used to compensate the code overlay information of the version to be tested.
S105: and compensating the compensation coverage information corresponding to the historical version to the code coverage information of the version to be tested to obtain compensated coverage information of the version to be tested under the historical version.
After determining the compensation coverage information corresponding to each historical version, the test platform can compensate the compensation coverage information corresponding to the historical version into the code coverage information of the version to be tested, so as to obtain the compensated coverage information of the version to be tested under the historical version.
In the process that the test platform compensates the code coverage information of the version to be tested, the test passed by the subprogram which is not changed in the historical version can be included in the test in the version to be tested, so that the code which is historically tested in the subprogram which is not changed in the version to be tested does not need to be tested repeatedly, and the test efficiency is improved to a certain extent.
In this specification, the test platform compensates the compensation coverage information corresponding to the historical version into the code coverage information of the version to be tested, and specifically, for each unmodified subprogram corresponding to the historical version, a subprogram in the version to be tested that matches the unmodified subprogram is determined as a target subprogram, where matching refers to the same subprogram identifier. And then, determining code coverage information corresponding to the unchanged subprogram from the compensation coverage information corresponding to the historical version, and compensating the code coverage information of the version to be tested according to the code coverage information corresponding to the unchanged subprogram to obtain compensated coverage information of the version to be tested under the historical version. The compensated overlay information includes code overlay information corresponding to the compensated target subroutine. That is, the code coverage information corresponding to the unchanged subprogram is compensated to the code coverage information of the version to be tested, and the target subprogram corresponds to the part of the code coverage information, so as to obtain the compensated coverage information.
The compensation mentioned here may be to compensate the record of the tested code line included in the unchanged subprogram to the code coverage information corresponding to the target subprogram according to the code coverage information corresponding to the unchanged subprogram. If the unchanged subroutine is the A subroutine with the function name "isURLEncoded", the target subroutine is the B subroutine with the function name "isURLEncoded" in the version to be tested. Assuming that 1 indicates that the code line is tested and 0 indicates that the code line is not tested, the line numbers of the code lines required to be tested in the a subroutine in the history test are 2, 3 and 4, and the line numbers of the code lines required to be tested in the B subroutine in the test are also 2, 3 and 4. And only the 2 nd and 3 rd lines of the code lines contained in the A subprogram are run during the history test, the tested records corresponding to the 2 nd line code and the 3 rd line code in the code coverage information corresponding to the A subprogram are both 1, and the tested record corresponding to the 3 rd line code is 0. And only the 3 rd and 4 th codes in the code lines contained in the sub program B are run during testing, the tested record corresponding to the 2 nd code line in the code coverage information corresponding to the sub program B is 0, and the tested records corresponding to the 3 rd and 4 th codes are both 1. The result of compensating the code coverage information of the B subroutine by the code coverage information corresponding to the a subroutine is that the records tested corresponding to the 2, 3, and 4 lines of codes included in the B subroutine are all 1 (in this way, the code coverage information does not include the number of times the code line is tested but includes the record (i.e., 1 or 0) that the code line is tested).
The testing platform can determine the subprogram matched with the unchanged subprogram in the version to be tested as the target subprogram for each unchanged subprogram corresponding to the historical version. And then, according to the code coverage information corresponding to the version to be tested, determining the number of times that each code line contained in the target subprogram is operated during testing as a first number, and according to the compensation coverage information corresponding to the historical version, determining the number of times that each code line in the unchanged subprogram is operated during testing as a second number.
The test platform can compensate the first times by the second times to obtain compensated coverage information of the target subprogram under the historical version, and obtain compensated coverage information of the version to be tested under the historical version according to the compensated coverage information of each subprogram under the historical version included in the version to be tested. That is, the number of times each code line in the unchanged subprogram is run at the time of testing is added to the number of times the corresponding code line in the target subprogram is run at the time of testing, so as to compensate the code coverage information corresponding to the target subprogram.
For example, assume that the unchanged subroutine is the C subroutine in the historical version, the target subroutine in the version to be tested that matches the C subroutine is the D subroutine, and the codes to be tested in the C subroutine and the D subroutine are both the 2 nd and 4 th codes. And, the line 2 code of the D subroutine is run 0 times and the line 4 code is run 1 time at the time of testing under the version to be tested. When history testing is performed on the history version, the 2 nd line code of the C subprogram is executed 1 time, and the 4 th line code is also executed 1 time. Then, the code coverage information corresponding to the final D subroutine is compensated such that the 2 nd line code is run 1 time and the 4 th line code is run 2 times.
S106: and determining the code test coverage rate corresponding to the version to be tested according to the compensated coverage information of the version to be tested under each historical version, and executing the test task aiming at the version to be tested according to the code test coverage rate.
After the test platform determines the compensated coverage information of the version to be tested under each historical version, the code test coverage rate corresponding to the version to be tested can be determined. The code test coverage rate is determined according to the compensated coverage information, and not only can the code test coverage rate show the test condition of the version to be tested, but also the historical test based on the historical version can test the unchanged subprogram in the version to be tested.
For example, assume that the version to be tested includes a subroutine a and a subroutine b, where the code to be tested in the subroutine a is lines 1, 2 and 3, the code to be tested in the subroutine b is lines 4 and 5, the code tested in the subroutine a is line 1, and the code tested in the subroutine b is line 5. If the historical version is not considered, the code test coverage rate corresponding to the version to be tested is 2/5. The version to be tested corresponds to a historical version, the code of the historical version changed from the version to be tested is line 2, under the historical version, the subprogram matched with the subprogram a is the subprogram c, the subprogram matched with the subprogram b is the subprogram d, and the code lines which historically need to test the historical version are also the codes of lines 1, 2 and 3 in the subprogram c and the codes of lines 4 and 5 in the subprogram d. When history testing is performed on the history version, the code tested in the c subroutine is line 3, and the code tested in the d subroutine is line 4. Since the 2 nd line is changed, the code coverage information corresponding to the c subprogram is not compensated into the code coverage information corresponding to the a subprogram, and the tested situation of the 4 th line in the d subprogram can be compensated into the code coverage information corresponding to the b subprogram in the version to be tested, so that the code test coverage rate corresponding to the version to be tested, which is determined according to the compensated coverage information, is 3/5.
If the code test coverage rate determined by the test platform is lower than the set coverage rate, it can be determined that the test on the version to be tested is incomplete at this time, so that a tester can adjust the test task aiming at the version to be tested and execute the adjusted test task through the test platform, so as to improve the code test coverage rate of the version to be tested.
It should be noted that the subroutines involved in each testing task pre-made by the tester may not be identical, and if the testing task only involves a part of subroutines, and the determined code testing coverage is not lower than the set coverage, the subroutines not tested in the version to be tested may be determined according to the post-compensation coverage information of the version to be tested in each historical version, and the testing tasks for the subroutines not tested may be executed. The test platform can determine a test task corresponding to the untested subprogram from the pre-made test tasks and execute the test task.
In this specification, the test platform may generate and display a test result page for the version to be tested according to the code test coverage corresponding to the version to be tested, where the test result page may only display the code test coverage corresponding to the version to be tested, or may display the code test coverage and the operating conditions of each code line for testing the version to be tested together, and in practical application, the display content in the test result service may be determined according to practical requirements.
It should be noted that the test platform may convert each version of the info file into data in a set format to obtain the code coverage information included in the info file. That is, for each version of the info file, after the test platform performs data conversion on the version of the info file, the code coverage information of the version is data in a set format. The setting format mentioned here can be set according to actual conditions. For example, the formatted data may be set as data of a Map type, that is, a version of the info file may be converted into data of a Map < String, List < CovereData > > type, where a String field may be used to indicate a version identifier of the version, and List < CovereData > indicates code coverage information corresponding to each subprogram in the version.
The CovereData class is used to represent the code coverage information of the subprogram, and List < CoveregeData > is a List composed of the code coverage information corresponding to each subprogram. The CovereData class may include variables such as funtionancame (i.e., a subroutine id), beginnnumber (i.e., a line number of an initial code line corresponding to a subroutine), endNumber (i.e., a line number of a termination code line corresponding to a subroutine), and lineList (i.e., code coverage information corresponding to a subroutine). The lineList mentioned here may be set in the form of List < CoveregeLine >, the CoveregeLine class is code coverage information of a code line, the CoveregeLine class may contain lineNumber (i.e. line number of the code line), count (i.e. number of times the code line is covered), and other variables, and the service platform may convert the info files of the respective versions into the above-mentioned Map < String, List < CovereData > > type data.
And compensating the code coverage information of the version to be tested, namely compensating the data with the set format corresponding to the version to be tested. Finally, the test platform can convert the compensated data with the set format corresponding to the version to be tested into the form of an info file, and the info file is converted into a test result page for display by using a genhtml mode. Of course, the test platform may also directly extract the code coverage information included in the info file without converting the info file into data in a set format, and execute a process of compensating the code coverage information corresponding to the version to be tested.
The method of version testing provided in this specification is described below in a complete example, as shown in fig. 2.
Fig. 2 is a schematic flowchart of a process for compensating code coverage information corresponding to a version to be tested provided in this specification.
Firstly, after a test platform tests a version to be tested, an info file containing code coverage information corresponding to the version to be tested can be obtained through an Icov tool, and the info file can be converted into data in a set format by the test platform so as to compensate the code coverage information corresponding to the version to be tested. Then, the test platform may obtain an info file including code coverage information of each history version corresponding to the version to be tested, and convert the info file of the history version into data in a set format according to the info file of each history version. The test platform can acquire the historical version and determine the line number of the code line of which the historical version is changed relative to the version to be tested. Specifically, the test platform may determine, by using a code management tool, a line number of a code line of which the historical version is changed with respect to the version to be tested, for example, the line number may be determined by a gitdiff, and of course, the test platform may also be determined by using other code management tools, which is not limited herein.
Further, the test platform may determine, for each function in the historical version, whether the line number of the code line in which the change has occurred is included in the range of the line numbers of the code lines included in the function. Taking the data with the set format in the above example as an example, if in CovereData corresponding to a certain function: the test platform determines that the beginnnumber < ═ the line number of the code line that has been changed < ═ the end number, and can determine that the line number of the code line that has been changed is included in the range of the line numbers of the code lines included in the function. If the line number range of the code line included in the function contains the line number of the changed code line, the code coverage information corresponding to the function should not be compensated into the code coverage information corresponding to the version to be tested, and if the line number of the changed code line is not contained, the code coverage information corresponding to the function can be compensated into the code coverage information corresponding to the version to be tested.
The test platform compensates the code coverage information corresponding to each unchanged function in each historical version into the code coverage information corresponding to the version to be tested, and obtains compensated coverage information (the compensated coverage information is data in a set format), and the test platform can convert the compensated coverage information into an info file and convert the info file into a test result page for the version to be tested by using a genhtml tool.
After the test platform determines the code coverage information of the version to be tested, the test platform determines the code coverage information corresponding to the subprogram of which the code in the historical version is not changed according to the code coverage information of the historical version corresponding to the version to be tested, and supplements the code coverage information of the version to be tested according to the code coverage information to determine the code test coverage rate of the version to be tested. Compared with the prior art, the method has the advantages that the code test coverage rate of the version to be tested is not determined according to the code coverage information of the subprogram of which the code is changed, so that the rationality of the code coverage information determined based on the historical version is ensured to a certain extent, and the accuracy in testing the version to be tested is further ensured.
It should also be noted that, in this specification, each subroutine is not strictly continuous, that is, several code lines may be included between two adjacent subroutines. Since the plurality of code lines included between the adjacent subprograms do not belong to the code lines included in the subprograms, if the code lines included between the two adjacent subprograms in the version to be tested have code lines which are not changed compared with the historical version, the code coverage information of the historical version for the code lines which are not changed can be compensated into the code coverage information corresponding to the version to be tested.
Based on the same idea, the present specification further provides a corresponding version test apparatus, as shown in fig. 3, for the method for version test provided above for one or more embodiments of the present specification.
Fig. 3 is a schematic diagram of a version test apparatus provided in this specification, which specifically includes:
a version determining module 301, configured to determine a code version to be tested as a version to be tested;
an information determining module 302, configured to test the version to be tested, and determine code coverage information of the tested version, where the code coverage information is used to indicate a code that has been run in a testing process of the version to be tested;
an obtaining module 303, configured to obtain each history version corresponding to the version to be tested and code coverage information of each history version;
a subprogram determining module 304, configured to determine, for each history version, a subprogram that is the same as the code of the version to be tested from the subprograms included in the history version, as an unchanged subprogram, and determine, from the code coverage information of the history version, code coverage information corresponding to the unchanged subprogram, as compensation coverage information corresponding to the history version;
a compensation module 305, configured to compensate the compensation coverage information corresponding to the historical version to the code coverage information of the version to be tested, so as to obtain compensated coverage information of the version to be tested in the historical version;
the execution module 306 is configured to determine a code test coverage rate corresponding to the version to be tested according to the compensated coverage information of the version to be tested in each historical version, and execute a test task for the version to be tested according to the code test coverage rate.
Optionally, the subroutine determining module 304 is specifically configured to determine, as a changed code line, a code line in the version to be tested that is changed compared to the historical version; and regarding each subprogram in the historical version, if the subprogram is determined not to contain the changed code line, taking the subprogram as an unchanged subprogram.
Optionally, the subroutine determining module 304 is specifically configured to determine, according to the code coverage information corresponding to the version to be tested, a line number of an initial code line and a line number of an end code line corresponding to the subroutine, where the end code line is a last line of codes to be tested included in the subroutine; and if the line number corresponding to the changed code line is determined not to fall into the range of the line numbers from the initial code line to the termination code line, determining that the changed code line is not contained in the subprogram.
Optionally, the compensation module 305 is specifically configured to, for each unchanged subprogram corresponding to the historical version, determine a subprogram in the version to be tested, which is matched with the unchanged subprogram, as a target subprogram; determining code coverage information corresponding to the unchanged subprogram from compensation coverage information corresponding to the historical version; and compensating the code coverage information of the version to be tested according to the code coverage information corresponding to the unchanged subprogram to obtain compensated coverage information of the version to be tested under the historical version, wherein the compensated coverage information comprises the compensated code coverage information corresponding to the target subprogram.
Optionally, the compensation module 305 is specifically configured to, for each unchanged subprogram corresponding to the historical version, determine a subprogram in the version to be tested, which is matched with the unchanged subprogram, as a target subprogram; determining the number of times that each code line contained in the target subprogram is operated during testing as a first number according to the code coverage information corresponding to the version to be tested, and determining the number of times that each code line in the unchanged subprogram is operated during testing as a second number according to the compensation coverage information corresponding to the historical version; compensating the first times through the second times to obtain compensated coverage information of the target subprogram under the historical version; and obtaining the compensated coverage information of the version to be tested under the historical version according to the compensated coverage information of each subprogram under the historical version included in the version to be tested.
Optionally, the execution module 306 is specifically configured to, if it is determined that the code test coverage is not lower than the set coverage, determine, according to the compensated coverage information of the version to be tested in each historical version, a subprogram that is not tested in the version to be tested, and execute a test task for the subprogram that is not tested.
Optionally, the apparatus further comprises:
the displaying module 307 is configured to generate and display a test result page for the version to be tested according to the code test coverage rate corresponding to the version to be tested, where the test result page is used to display the code test coverage rate corresponding to the version to be tested.
The present specification also provides a computer-readable storage medium storing a computer program, which is operable to execute the method of version testing shown in fig. 1 described above.
This specification also provides a schematic block diagram of the electronic device shown in fig. 4. As shown in fig. 4, at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include hardware required for other services. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs the computer program to implement the version testing method described in fig. 1. Of course, besides the software implementation, the present specification does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may be hardware or logic devices.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only an example of the present specification, and is not intended to limit the present specification. Various modifications and alterations to this description will become apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present specification should be included in the scope of the claims of the present specification.
Claims (10)
1. A method of version testing, comprising:
determining a code version to be tested as a version to be tested;
testing the version to be tested, and determining code coverage information of the tested version, wherein the code coverage information is used for representing a code which runs in the testing process of the version to be tested;
acquiring each historical version corresponding to the version to be tested and code coverage information of each historical version;
for each historical version, determining a subprogram which is the same as the code of the version to be tested from subprograms contained in the historical version to serve as an unchanged subprogram, and determining code coverage information corresponding to the unchanged subprogram from the code coverage information of the historical version to serve as compensation coverage information corresponding to the historical version;
compensating the compensation coverage information corresponding to the historical version to the code coverage information of the version to be tested to obtain compensated coverage information of the version to be tested under the historical version;
and determining the code test coverage rate corresponding to the version to be tested according to the compensated coverage information of the version to be tested under each historical version, and executing the test task aiming at the version to be tested according to the code test coverage rate.
2. The method of claim 1, wherein determining a subprogram that is the same as the code of the version to be tested from the subprograms included in the historical version as an unchanged subprogram specifically comprises:
determining a code line which is changed in the version to be tested compared with the historical version as a changed code line;
and regarding each subprogram in the historical version, if the subprogram is determined not to contain the changed code line, taking the subprogram as an unchanged subprogram.
3. The method of claim 2, wherein determining that the changed code line is not included in the subroutine comprises:
determining the line number of an initial code line and the line number of an end code line corresponding to the subprogram according to the code coverage information corresponding to the version to be tested, wherein the end code line is the last line of codes to be tested contained in the subprogram;
and if the line number corresponding to the changed code line is determined not to fall into the range of the line numbers from the initial code line to the termination code line, determining that the changed code line is not contained in the subprogram.
4. The method of claim 1, wherein compensating the compensation coverage information corresponding to the historical version to the code coverage information of the version to be tested to obtain compensated coverage information of the version to be tested under the historical version includes:
determining a subprogram matched with the unchanged subprogram in the version to be tested as a target subprogram for each unchanged subprogram corresponding to the historical version;
determining code coverage information corresponding to the unchanged subprogram from compensation coverage information corresponding to the historical version;
and compensating the code coverage information of the version to be tested according to the code coverage information corresponding to the unchanged subprogram to obtain compensated coverage information of the version to be tested under the historical version, wherein the compensated coverage information comprises the compensated code coverage information corresponding to the target subprogram.
5. The method of claim 1 or 4, wherein the compensating coverage information corresponding to the historical version is compensated to the code coverage information of the version to be tested, so as to obtain compensated coverage information of the version to be tested under the historical version, and specifically comprises:
determining a subprogram matched with the unchanged subprogram in the version to be tested as a target subprogram for each unchanged subprogram corresponding to the historical version;
determining the number of times that each code line contained in the target subprogram is operated during testing as a first number according to the code coverage information corresponding to the version to be tested, and determining the number of times that each code line in the unchanged subprogram is operated during testing as a second number according to the compensation coverage information corresponding to the historical version;
compensating the first times through the second times to obtain compensated coverage information of the target subprogram under the historical version;
and obtaining the compensated coverage information of the version to be tested under the historical version according to the compensated coverage information of each subprogram under the historical version included in the version to be tested.
6. The method of claim 1, wherein executing a test task for the version to be tested according to the code test coverage comprises:
and if the code testing coverage rate is not lower than the set coverage rate, determining the sub-programs which are not tested in the version to be tested according to the compensated coverage information of the version to be tested under each historical version, and executing the testing tasks aiming at the sub-programs which are not tested.
7. The method of claim 1, wherein the method further comprises:
and generating and displaying a test result page aiming at the version to be tested according to the code test coverage rate corresponding to the version to be tested, wherein the test result page is used for displaying the code test coverage rate corresponding to the version to be tested.
8. An apparatus for version testing, comprising:
the version determining module is used for determining the code version to be tested as the version to be tested;
the information determining module is used for testing the version to be tested and determining code coverage information of the tested version, wherein the code coverage information is used for representing a code which runs in the testing process of the version to be tested;
the acquisition module is used for acquiring each historical version corresponding to the version to be tested and the code coverage information of each historical version;
a subprogram determining module, configured to determine, for each history version, a subprogram that is the same as the code of the version to be tested from the subprograms included in the history version, as an unchanged subprogram, and determine, from the code coverage information of the history version, code coverage information corresponding to the unchanged subprogram, as compensation coverage information corresponding to the history version;
the compensation module is used for compensating the compensation coverage information corresponding to the historical version to the code coverage information of the version to be tested to obtain compensated coverage information of the version to be tested under the historical version;
and the execution module is used for determining the code test coverage rate corresponding to the version to be tested according to the compensated coverage information of the version to be tested under each historical version, and executing the test task aiming at the version to be tested according to the code test coverage rate.
9. A computer-readable storage medium, characterized in that the storage medium stores a computer program which, when executed by a processor, implements the method of any of the preceding claims 1 to 7.
10. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 1 to 7 when executing the program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010974108.6A CN112181812A (en) | 2020-09-16 | 2020-09-16 | Version testing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010974108.6A CN112181812A (en) | 2020-09-16 | 2020-09-16 | Version testing method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112181812A true CN112181812A (en) | 2021-01-05 |
Family
ID=73921332
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010974108.6A Pending CN112181812A (en) | 2020-09-16 | 2020-09-16 | Version testing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112181812A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114003513A (en) * | 2021-12-30 | 2022-02-01 | 云账户技术(天津)有限公司 | Code coverage rate processing method and device, electronic equipment and readable storage medium |
| CN114116480A (en) * | 2021-11-26 | 2022-03-01 | 北京字节跳动网络技术有限公司 | Method, device, medium and equipment for determining application program test coverage rate |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105988926A (en) * | 2015-02-13 | 2016-10-05 | 腾讯科技（深圳）有限公司 | Method and device for processing multi-version test data |
| US20170132109A1 (en) * | 2015-11-11 | 2017-05-11 | International Business Machines Corporation | Automatic collection and presentation of runtime data semantics |
| CN108519945A (en) * | 2018-03-21 | 2018-09-11 | 腾讯科技（深圳）有限公司 | Coverage rate test method, apparatus and storage device |
-
2020
- 2020-09-16 CN CN202010974108.6A patent/CN112181812A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105988926A (en) * | 2015-02-13 | 2016-10-05 | 腾讯科技（深圳）有限公司 | Method and device for processing multi-version test data |
| US20170132109A1 (en) * | 2015-11-11 | 2017-05-11 | International Business Machines Corporation | Automatic collection and presentation of runtime data semantics |
| CN108519945A (en) * | 2018-03-21 | 2018-09-11 | 腾讯科技（深圳）有限公司 | Coverage rate test method, apparatus and storage device |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114116480A (en) * | 2021-11-26 | 2022-03-01 | 北京字节跳动网络技术有限公司 | Method, device, medium and equipment for determining application program test coverage rate |
| CN114003513A (en) * | 2021-12-30 | 2022-02-01 | 云账户技术(天津)有限公司 | Code coverage rate processing method and device, electronic equipment and readable storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9317401B2 (en) | Prioritizing test cases using multiple variables | |
| CN108334515B (en) | Method, device and system for processing stack address in crash file | |
| CN111881019B (en) | User interface testing method and device | |
| CN109241026B (en) | Data management method, device and system | |
| CN108320071B (en) | Business risk management method, device and equipment | |
| CN112181812A (en) | Version testing method and device | |
| CN109284222B (en) | Software unit, project testing method, device and equipment in data processing system | |
| CN116610568A (en) | Method, device, equipment and medium for identifying dependency relationship of codes | |
| CN114840427A (en) | Code testing and test case generating method and device | |
| CN114064114A (en) | Dynamic library generation method and device | |
| CN111240987B (en) | Method and device for detecting migration program, electronic equipment and computer readable storage medium | |
| CN111399849B (en) | Method and system for determining application program installation package | |
| CN111367512B (en) | Method and device for creating Android library module dependency relationship in application development | |
| CN110688320B (en) | Global variable detection method and device and terminal equipment | |
| CN112035117A (en) | Page display system, method and device | |
| CN111967269A (en) | Business risk identification method and device and electronic equipment | |
| CN109409037B (en) | Method, device and equipment for generating data confusion rule | |
| CN113626342B (en) | Model online testing method and device | |
| CN110704742B (en) | Feature extraction method and device | |
| CN114840426A (en) | Code testing method and device | |
| CN114817047A (en) | Compiler test method, case generation method and device and instruction storage structure | |
| CN108733564B (en) | Browser performance testing method, device and equipment | |
| CN112286572A (en) | Configuration method and device of business process | |
| CN110688430A (en) | Method and device for obtaining data bypass and electronic equipment | |
| CN112363945A (en) | Version testing method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |