Disclosure of Invention
The application aims to solve the technical problem of inaccurate code coverage rate data calculation aiming at a mobile phone system in the prior art, and provides a code coverage rate calculation and analysis method, a device, equipment and a storage medium.
The application solves the technical problems by the following technical scheme:
a code coverage rate calculation and analysis method comprises the following steps:
s1, acquiring a code of a current version and a commit id corresponding to the code from a code library through a git command;
s2, packaging the codes to generate corresponding test packages, compiling the codes to generate compiled files, and storing the test packages and the compiled files into folders named with the commit ids corresponding to the codes;
s3, receiving a coverage rate file named by a commit id of a code, which is generated after a test packet uploaded by a tester is tested, and storing the coverage rate file into a folder named by the commit id;
s4, calculating the file in the commit id file through a code coverage rate tool to generate a test coverage rate report of the current code;
s5, combining the test coverage rate report of the current version code with the test coverage rate report of the previous version code through a combination algorithm to generate a full coverage rate report;
s6, obtaining codes of a change part of the current version code compared with the previous version code through a gitdiff command, and extracting code coverage corresponding to the codes of the change part from the total coverage report to generate an incremental coverage report.
Preferably, the method further comprises the steps of:
and S7, sending the incremental coverage rate report and the full coverage rate report to a tester for testing the current version code.
Preferably, the code includes an installer applied to the IOS side and an installer applied to An Zhuoduan.
Preferably, when the code is an installer applied to the IOS end, the compiled file is a gcno file, and the coverage rate file is a gcda file.
Preferably, when the code is an installer applied to An Zhuoduan, the compiled file includes a class file and a source file, and the coverage file is an ec file.
Preferably, the generation process of the full coverage report is as follows:
s51, obtaining codes of a part of the current version code, which is changed compared with the previous version code, through a gitdiff command, so as to calculate the offset of the codes;
s52, merging the code coverage rate in the test coverage rate report of the previous version code into the test coverage rate report of the current version code according to the offset of the code.
Preferably, the coverage rate file is automatically generated after a tester installs a test packet on the mobile phone terminal for testing.
An electronic device having stored thereon a code coverage calculation analysis system, the code coverage calculation analysis system comprising:
the code acquisition module is used for acquiring a code of a current version and a commit id corresponding to the code from a code library through a git command;
the packaging and compiling module packages the codes to generate corresponding test packages, compiles the codes to generate compiled files at the same time, and then stores the test packages and the compiled files into folders named with the commit ids corresponding to the codes;
the coverage rate file receiving module is used for receiving coverage rate files named by the commit id of the codes generated after the test package uploaded by the tester is tested, and storing the coverage rate files into folders named by the commit id;
the current report generation module is used for calculating the files in the commit id file through the code coverage rate tool so as to generate a test coverage rate report of the current code;
the full-coverage report generation module is used for combining the test coverage report of the current version code with the test coverage report of the previous version code through a combination algorithm to generate a full-coverage report;
and the increment report generation module is used for obtaining the code of the change part of the current version code compared with the previous version code through the gitdiff command, extracting the code coverage corresponding to the code of the change part from the total coverage report and generating an increment coverage report.
A computer device comprising a memory and a processor, the memory having stored thereon a code coverage calculation analysis system executable by the processor, the system when executed by the processor implementing the steps of the code coverage calculation analysis method of any of the preceding claims.
A computer readable storage medium having stored therein a code coverage calculation analysis system executable by at least one processor to cause the at least one processor to perform the steps of the code coverage calculation analysis method of any one of the preceding claims.
The application has the positive progress effects that: collecting coverage rate under the condition that service test is not perceived; after the support codes are frequently changed, combining coverage rate conditions among different codes, so that an accurate coverage rate file of a certain version can be obtained; and automatically analyzing uncovered test points in the test stage according to the current coverage rate report, automatically notifying a tester, and ensuring the coverage rate of the test.
Detailed Description
The application is further illustrated by means of the following examples, which are not intended to limit the scope of the application.
Firstly, the application provides a code coverage rate calculation and analysis method.
In a first embodiment, as shown in fig. 1, the method for calculating and analyzing the code coverage rate for the installer on the IOS side includes the following steps:
s1, acquiring a code of a current version and a commit id corresponding to the code from a code library through a git command.
Typically, after a programmer writes a program, the program is uploaded to a specific code base (such as a sandbox), where the uploaded program includes a corresponding commit id.
The id in the commit id refers to a hash value, which is a numeric value obtained by logical operation according to data of the content of the file, and the hash values obtained by different files (even the same file name) are different, so that the hash value can be used as an identification card for identifying each file.
When the code needs to be tested, the latest code (namely, the code of the current version) is pulled from the code library through the git command, because the installation program of the same version can be subjected to multiple modifications in the development process, each modification can generate a new code, the current version does not refer to the version number of the code, but refers to the hash value of the code, and the current version and the previous version are distinguished through the hash value.
In particular, the Jenkins tool may be used to obtain codes from a code library. The Jenkins is an open-source Continuous Integration (CI) tool that provides a friendly operation interface, originating from Hudson (Hudson is commercially available), and is mainly used for continuous, automatic construction/test software projects and monitoring of external tasks. For specific operation of the Jenkins tool, reference is made to the specification.
S2, packaging the codes to generate corresponding test packages, compiling the codes to generate compiled gcno files, and storing the test packages and the compiled gcno files into folders named with the commit ids corresponding to the codes.
For the installation program applied to the IOS end, the packaging of the test packet can adopt an Apple recommended mode, namely, an archive function of xcode (xcode is an integrated development tool running on an operating system Mac OS X) is used for packaging (applicable to personal development), and then an iTunes (iTunes is a professional Apple device management tool) dragging-in mode can be adopted, and a full-automatic compiling script can be compiled to realize the compiling of codes.
The first two of which use the existing tools xcode and iTunes, the specific packaging process is seen in the specification. The following description will be made with respect to code compilation by writing a fully automatic compilation script:
the first step: a new folder, named "distribution", a new distribution. Sh script file, references the following (where the appName is the name of the code, such as a name of an app used on an IOS):
rm-rf appName
mkdir appName
mkdir appName/Payload
cp-r appName.app appName/Payload/appName.app
cp Icon.png appName/iTunesArtwork
cd appName
zip-r appName.ipa Payload iTunesArtworkexit 0
the above code completes the following steps:
deleting the file appName;
creating a folder appName;
creating a subfolder payload under the folder appName;
copying the file appName.app into a subfolder payload under the folder appName;
copying the icon into a subfolder iTunesArtwork under the folder appName;
switching to a folder appName;
compressing two subfolders of payoad and itunesartworks under the folder appName into a file, and changing the suffix of the compressed file into ipa;
and normally exiting.
And a second step of: the app files to be converted are placed under the distribution/folder, referenced below:
distribute/distribute.sh
distribute/appName.app
and a third step of: and running a distribution. Opening Terminal, cd to distribution folder, and pulling distribution. If hint permission denied, then execute once again distribution. Sh after giving rights with the "chmod 777 distribution. Sh" command.
Fourth step: after a few seconds of running, an appName/folder is generated under the distribution/folder, and the appName. Ipa inside is the test package that we want.
The compiled gcno file is obtained by instrumentation of the original code, which is called program instrumentation, and the program instrumentation is a method for achieving the purpose of testing by inserting operations into the tested program, i.e. inserting probes (also called "probes") into the program on the basis of ensuring the original logic integrity of the tested program. These probes are essentially code segments that perform information gathering, which may be assignment statements or function calls that gather overlay information. And executing the probe and outputting the running characteristic data of the program. Based on an analysis of these feature data, the internal behavior and features of the program are revealed.
And S3, receiving a coverage gcda file named by a commit id of the code, which is generated after the test packet uploaded by the tester is tested, and storing the coverage gcda file into a folder named by the commit id.
The gcda file refers to a file with a suffix gcda, and is obtained through a gcov command tool, wherein the gcov command is a tool for testing the code coverage rate of a program. After the code is tested by the tool, a coverage rate file with the suffix gcda is finally obtained, and the name of the file is named as the commit id of the tested code.
After the coverage gcda file is generated, the tester also needs to upload the coverage gcda file to the specific code base and save the coverage gcda file to a folder named by the commit id.
The coverage gcda file is the basis for the latter generation of coverage reports.
S4, calculating the file in the commit id file through a code coverage rate tool to generate a test coverage rate report of the current code;
the code coverage tool can still adopt the gcov command tool, and by executing the command gcov, cpp can print out the coverage of the test on the screen and simultaneously generate a file ". Cpp.gcov", and then vi is opened to see which row is covered, i.e. see which codes are tested and which are not tested.
And S5, combining the test coverage report of the current version code with the test coverage report of the previous version code through a combination algorithm to generate a full coverage report.
The step S5 may specifically include the following steps:
s51, obtaining codes of a part of the current version code, which is changed compared with the previous version code, through a gitdiff command, so as to calculate the offset of the codes;
s52, merging the code coverage rate in the test coverage rate report of the previous version code into the test coverage rate report of the current version code according to the offset of the code.
By adopting the merging method, the test coverage rate reports can be gradually merged in pairs, and then the full coverage rate report is finally generated.
S6, obtaining codes of a change part of the current version code compared with the previous version code through a gitdiff command, and extracting code coverage corresponding to the codes of the change part from the total coverage report to generate an incremental coverage report.
The test coverage report in this embodiment is a report that presents the coverage file obtained previously. Including but not limited to the following: class coverage, method coverage, statement block coverage, and branch coverage.
In this embodiment, the test packet may be obtained by the tester in a code scanning manner, and the step of automatically generating the two-dimensional code or the bar code may be added after the package of the test packet is completed.
In a second embodiment, as shown in fig. 2, for an installer applied to an IOS end, the code coverage rate calculation and analysis method includes the following steps:
s1, acquiring a code of a current version and a commit id corresponding to the code from a code library through a git command.
Step S1 is the same as the first embodiment, and will not be described again here.
S2, packaging the codes to generate corresponding test packages, compiling the codes to generate compiled class files and source files, and storing the test packages and the compiled class files and source files into folders named with the commit ids corresponding to the codes.
The test package of the code applied to the android system specifically refers to an installation program after the code used for generating coverage rate data is inserted, and after the installation program is installed and operated by a tester, a corresponding code test rate ec file (file with the suffix of. Ec) is automatically generated.
The packaging of the test packet is usually completed by a self-contained packaging tool of a code writing tool, such as Eclipse self-contained packaging tool Ant, and some code writing tools have specific packaging commands, and the test packet is automatically generated by inputting the specific packaging commands.
The full name of the class file is Java class file, and a source file (code) written in Java language is compiled to be changed into a corresponding class file. The compiling is generally implemented by a compiling function of a development tool, such as MyEclipse for Java, java EE and mobile application development, and the files are automatically compiled into class files after being saved by the codes developed by the MyEclipse.
Unlike the code applied to the IOS system, the code applied to the android system is compiled to generate a source file, which is used to store source codes.
S3, receiving a coverage rate ec file named by a commit id of a code generated after a test packet uploaded by a tester is tested, and storing the coverage rate ec file into a folder named by the commit id;
the ec file refers to a file with a suffix of ec, the file is automatically generated by the running of the test package, and the name of the file is still named by the commit id of the tested code.
The coverage ec file is the basis for the latter generation of coverage reports.
S4, calculating the file in the commit id file through a code coverage rate tool to generate a test coverage rate report of the current code;
the code coverage tool may employ a Jacoco (Java Code Coverage abbreviation) tool, the method of use of which is described in the specification.
And S5, combining the test coverage report of the current version code with the test coverage report of the previous version code through a combination algorithm to generate a full coverage report.
The step S5 may specifically include the following steps:
s51, obtaining codes of a part of the current version code, which is changed compared with the previous version code, through a gitdiff command, so as to calculate the offset of the codes;
s52, merging the code coverage rate in the test coverage rate report of the previous version code into the test coverage rate report of the current version code according to the offset of the code.
By adopting the merging method, the test coverage rate reports can be gradually merged in pairs, and then the full coverage rate report is finally generated.
S6, obtaining codes of a change part of the current version code compared with the previous version code through a gitdiff command, and extracting code coverage corresponding to the codes of the change part from the total coverage report to generate an incremental coverage report.
The test coverage report in this embodiment is a report that presents the coverage file obtained previously. Including but not limited to the following: class coverage, method coverage, statement block coverage, and branch coverage.
The second embodiment differs from the first embodiment only in S2-S4, and the rest of the steps are the same as the first embodiment.
In a third embodiment, based on the first or second embodiment, the code coverage rate calculation and analysis method further includes the following steps:
and S7, sending the incremental coverage rate report and the full coverage rate report to a tester for testing the current version code.
The report may be sent to the tester's mailbox for detailed reading.
If necessary, the report can also be automatically sent to all relevant personnel, as long as the mailbox of the relevant personnel is preset in the system.
The report is sent through the mailbox, so that a tester can know the test result in time, and the operation of actively initiating the report acquisition is avoided.
Next, the present application proposes an electronic device on which a code coverage calculation analysis system 20 is stored, the system 20 being divisible into one or more program modules.
For example, FIG. 3 shows a program module schematic of a first embodiment of the code coverage calculation analysis system 20, in which the system 20 may be partitioned into a code acquisition module 201, a package compilation module 202, a coverage file reception module 203, a current report generation module 204, a full report generation module 205, and an incremental report generation module 206. Program modules in accordance with the application are understood to mean a sequence of computer program instructions capable of carrying out particular functions. The following description will specifically introduce specific functions of the program modules 201-206.
The code obtaining module 201 is configured to obtain, from a code library, a code of a current version and a commit id corresponding to the code through a git command.
The id in the commit id refers to a hash value, which is a numeric value obtained by logical operation according to data of the content of the file, and the hash values obtained by different files (even the same file name) are different, so that the hash value can be used as an identification card for identifying each file.
When the code needs to be tested, the latest code (namely, the code of the current version) is pulled from the code library through the git command, because the installation program of the same version can be subjected to multiple modifications in the development process, each modification can generate a new code, the current version does not refer to the version number of the code, but refers to the hash value of the code, and the current version and the previous version are distinguished through the hash value.
In particular, the Jenkins tool may be used to obtain codes from a code library. The Jenkins is an open-source Continuous Integration (CI) tool that provides a friendly operation interface, originating from Hudson (Hudson is commercially available), and is mainly used for continuous, automatic construction/test software projects and monitoring of external tasks. For specific operation of the Jenkins tool, reference is made to the specification.
The packaging and compiling module 202 packages the code to generate a corresponding test package, compiles the code to generate a compiled file, and then saves the test package and the compiled file into a folder named with a commit id corresponding to the code.
For an installer applied to the IOS end, the gcno file is generated after the code is compiled.
The test package may be packaged in an Apple recommended manner, that is, packaged with an archive function (applicable to personal development) of xcode (xcode is an integrated development tool running on the operating system Mac OS X), and then may be dragged in by iTunes (iTunes is a professional Apple device management tool), or may be compiled into a fully automatic compiling script to implement code (described in reference to method embodiment one).
The compiled gcno file is obtained by instrumentation of the original code, which is called program instrumentation, and the program instrumentation is a method for achieving the purpose of testing by inserting operations into the tested program, i.e. inserting probes (also called "probes") into the program on the basis of ensuring the original logic integrity of the tested program. These probes are essentially code segments that perform information gathering, which may be assignment statements or function calls that gather overlay information. And executing the probe and outputting the running characteristic data of the program. Based on an analysis of these feature data, the internal behavior and features of the program are revealed.
Aiming at an installation program applied to an android system, a class file and a source file generated after code compiling are performed.
The test package of the code specifically refers to an installation program after the code for generating coverage rate data is inserted, and after the installation program is installed and operated by a tester, a corresponding code test rate ec file (file with the suffix of ec) is automatically generated.
The packaging of the test packet is usually completed by a self-contained packaging tool of a code writing tool, such as Eclipse self-contained packaging tool Ant, and some code writing tools have specific packaging commands, and the test packet is automatically generated by inputting the specific packaging commands.
The full name of the class file is Java class file, and a source file (code) written in Java language is compiled to be changed into a corresponding class file. The compiling is generally implemented by a compiling function of a development tool, such as MyEclipse for Java, java EE and mobile application development, and the files are automatically compiled into class files after being saved by the codes developed by the MyEclipse.
Unlike the code applied to the IOS system, the code applied to the android system is compiled to generate a source file, which is used to store source codes.
The coverage file receiving module 203 is configured to receive a coverage file named by a commit id of a code generated after a test packet uploaded by a tester is tested, and store the coverage file in a folder named by the commit id.
The generated coverage rate file is a gcda file aiming at an installation program applied to an IOS end, and the gcov command is obtained through a gcov command tool, wherein the gcov command is a tool for testing the code coverage rate of a program. After the code is tested by the tool, a coverage rate file with the suffix gcda is finally obtained, and the name of the file is named as the commit id of the tested code.
Aiming at an installation program applied to an android system, the generated coverage rate file is an ec file, the file is automatically generated through the operation of a test package, and the name of the file is still named as the commit id of the tested code.
The coverage file is the basis for the latter generation of coverage reports.
The current report generating module 204 is configured to calculate, by using a code coverage tool, a file in the commit id file to generate a test coverage report of the current code.
The report is generated as follows: firstly, a code of a part of a current version code which is changed compared with a previous version code is obtained through a gitdiff command, so that the offset of the code is calculated; and then merging the code coverage rate in the test coverage rate report of the previous version code into the test coverage rate report of the current version code according to the offset of the code.
And gradually combining the test coverage rate reports in pairs to finally generate a full coverage rate report.
The full coverage report generating module 205 is configured to combine, by using a combining algorithm, a test coverage report of a current version code with a test coverage report of a previous version code, to generate a full coverage report;
and the increment report generation module is used for obtaining the code of the change part of the current version code compared with the previous version code through the gitdiff command, extracting the code coverage corresponding to the code of the change part from the total coverage report and generating an increment coverage report.
The test coverage report in this embodiment is a report that presents the coverage file obtained previously. Including but not limited to the following: class coverage, method coverage, statement block coverage, and branch coverage.
The application further provides computer equipment.
Fig. 4 is a schematic diagram of a hardware architecture of an embodiment of a computer device according to the present application. In this embodiment, the computer device 2 is a device capable of automatically performing numerical calculation and/or information processing according to a preset or stored instruction. For example, it may be a smart phone, a tablet computer, a notebook computer, a desktop computer, a rack server, a blade server, a tower server, or a rack server (including a stand-alone server or a server cluster composed of a plurality of servers), etc. As shown, the computer device 2 includes, but is not limited to, at least a memory 21, a processor 22, a network interface 23, and a code coverage calculation analysis system 20, which are communicatively coupled to each other via a system bus. Wherein:
the memory 21 includes at least one type of computer-readable storage medium including flash memory, hard disk, multimedia card, card memory (e.g., SD or DX memory, etc.), random Access Memory (RAM), static Random Access Memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the storage 21 may be an internal storage unit of the computer device 2, such as a hard disk or a memory of the computer device 2. In other embodiments, the memory 21 may also be an external storage device of the computer device 2, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card) or the like, which are provided on the computer device 2. Of course, the memory 21 may also comprise both an internal memory unit of the computer device 2 and an external memory device. In this embodiment, the memory 21 is typically used for storing an operating system and various application software installed on the computer device 2, such as program codes of the code coverage calculation analysis system 20. Further, the memory 21 may be used to temporarily store various types of data that have been output or are to be output.
The processor 22 may be a Central processing unit (Central ProcessingUnit, CPU), controller, microcontroller, microprocessor, or other data processing chip in some embodiments. The processor 22 is typically used to control the overall operation of the computer device 2, such as performing control and processing related to data interaction or communication with the computer device 2. In this embodiment, the processor 22 is configured to execute the program code or process data stored in the memory 21, for example, to execute the code coverage calculation analysis system 20.
The network interface 23 may comprise a wireless network interface or a wired network interface, which network interface 23 is typically used for establishing a communication connection between the computer device 2 and other computer devices. For example, the network interface 23 is used to connect the computer device 2 to an external terminal through a network, establish a data transmission channel and a communication connection between the computer device 2 and the external terminal, and the like. The network may be an Intranet (Intranet), the Internet (Internet), a global system for mobile communications (Global System of Mobile communication, GSM), wideband code division multiple access (Wideband Code Division Multiple Access, WCDMA), a 4G network, a 5G network, bluetooth (Bluetooth), wi-Fi, or other wireless or wired network.
It is noted that fig. 4 only shows a computer device 2 having components 21-23, but it is understood that not all of the illustrated components are required to be implemented, and that more or fewer components may alternatively be implemented.
In this embodiment, the code coverage calculation analysis system 20 stored in the memory 21 may be executed by one or more processors (the processor 22 in this embodiment) to perform the operations of the code coverage calculation analysis method described above.
Furthermore, the present application provides a computer-readable storage medium having stored therein a code coverage calculation analysis system 20, which code coverage calculation analysis system 20, when executed by one or more processors, implements the operations of the above-described code coverage calculation analysis method or electronic device.
While specific embodiments of the application have been described above, it will be appreciated by those skilled in the art that this is by way of example only, and the scope of the application is defined by the appended claims. Various changes and modifications to these embodiments may be made by those skilled in the art without departing from the principles and spirit of the application, but such changes and modifications fall within the scope of the application.