CN112559348B

CN112559348B - Test analysis method, system, equipment and medium based on jacoco

Info

Publication number: CN112559348B
Application number: CN202011480231.9A
Authority: CN
Inventors: 周诺奕; 解月敏
Original assignee: Guangzhou Yuncong Dingwang Technology Co Ltd
Current assignee: Guangzhou Yuncong Dingwang Technology Co Ltd
Priority date: 2020-12-15
Filing date: 2020-12-15
Publication date: 2021-09-14
Anticipated expiration: 2040-12-15
Also published as: CN112559348A

Abstract

The invention relates to the technical field of program testing, in particular to a test analysis method, a test analysis system, test analysis equipment and a test analysis medium based on jacoco. The method aims to solve the technical problems of reducing the workload of manual configuration, automatically and efficiently obtaining the full-quantity/increment coverage rate statistical analysis of the test version and even the difference analysis of different versions. According to the method, jacoco is developed for the second time, jacoco source codes are modified to customize project parameters, a test analysis system based on jacoco is developed by using flash, jacoco is uploaded to a designated position of a server where a tested service is located, a tested service script is started by using jacoco, corresponding project parameters of the corresponding tested service are transmitted, corresponding coverage rate analysis tasks and/or difference analysis tasks are generated according to the analysis project parameters and service information of a database, and the tasks are scanned and executed at regular time. Thus, the present invention enables automated analysis of a large number of tests to provide a simple and easy-to-use tool for full/incremental coverage analysis and differential analysis to test personnel.

Description

Test analysis method, system, equipment and medium based on jacoco

Technical Field

The invention relates to the technical field of program code testing, in particular to a method, a system, equipment and a medium for testing statistics and analysis based on jacoco.

Background

Code Coverage (Code Coverage) is an important index reflecting the Coverage degree of a test case to a tested program, and is also a reference value for measuring the test integrity. Whether it is a unit test, an API (Application Program Interface) test, or a functionality test, the code that calls the Program is the end. After the test is finished, whether the test is sufficient or not and what aspects the weak points of the test are can be known through the code coverage rate data, and then a developer or an auxiliary tester can be guided to increase the test case of the coverage rate.

In the process of testing the functions of the program product, statistics needs to be carried out on the total amount and the incremental coverage rate of each version of each service of the product, and the coverage rate can be understood as the proportion of the number of tested code lines and the total number of code lines from the dimension of the lines. The full test coverage rate is used for counting the overall coverage condition of each version, and the incremental coverage rate is used for counting the coverage rate of the code variation part of the current test version compared with the last version. The existing open-source software jacoco can achieve the purpose that the full coverage rate is obtained through manually configuring a code path. However, the incremental coverage rate cannot be obtained, and meanwhile, the incremental coverage rate can only be manually operated, so that the configuration quantity is large, and the incremental coverage rate cannot be applied to actual test activities.

On the other hand, when the product test version changes, new codes and changed codes are checked, and the requirement of performing accurate regression test is met. If the difference of the codes between the two versions needs to be known, the codes of the two versions need to be downloaded, and a tool is used for code comparison, so that the difference comparison analysis of the versions cannot be quickly realized under the conditions of more products and more test versions.

Disclosure of Invention

The invention provides a statistical analysis method, a device and a medium for testing aiming at the defects, so as to solve or partially solve the problem of realizing the automatic analysis of a large number of services, and provide a simple and easy-to-use tool for full/incremental coverage analysis and difference analysis for testing personnel.

According to a first aspect of the invention, a jacoco-based test analysis method is provided, which comprises the following steps: adding a jacobage in a start script of a test service so as to transmit a customized project parameter through the jacobage; analyzing the service information corresponding to the input project parameters, and generating a coverage rate analysis task and/or a difference analysis task corresponding to the service information; performing the coverage analysis task and/or the variance analysis task; the project parameters at least comprise a project name, a service name, a release version number, a code branch, a platform ip and a platform port of the test service.

Adding a jacobage in a start script of a test service, wherein the step of transmitting customized project parameters through the jacobage specifically comprises the following steps: uploading the jacobage.jar file to a specified position of a server where the test service is located, so that the jacobage is used for starting a test service script and transmitting the project parameters; analyzing the service information corresponding to the introduced project parameters, and generating a coverage rate analysis task or a difference analysis task corresponding to the project parameters, wherein the method specifically comprises the following steps: judging whether service information corresponding to the project parameters exists or not; if yes, generating a coverage rate analysis task according to the project parameters; and/or, if an old version of the test service exists and also exists, generating a difference analysis task according to the project parameters; executing the coverage rate analysis task or the difference analysis task regularly, which specifically comprises the following steps: and scanning the tasks according to a preset time period, and executing the coverage rate analysis task or the difference analysis task when the coverage rate analysis task or the difference analysis task meeting the conditions is scanned.

The customized project parameters are obtained by modifying the source code of the jaccoagent; judging whether the service information corresponding to the project parameter exists, specifically including: comparing the service name, the layout number and the code branch in the project parameters with service records stored in a database; judging whether the service records have records with the same service name, release version number and code branch; the service record comprises an item name, a service name, a release version number and a code branch of the test service.

Wherein the coverage analysis task comprises a full coverage analysis task and/or an incremental coverage analysis task; the executing the coverage analysis task specifically includes: performing a full coverage analysis and generating a full coverage analysis report; and/or performing incremental coverage analysis and generating incremental coverage analysis reports; the executing the difference analysis task specifically includes: version discrepancy analysis is performed and a discrepancy analysis report is generated.

Generating a coverage rate analysis task according to the project parameters, specifically comprising: judging whether the release version number in the item parameter exists in a release version table or not; if the version number does not exist, adding a piece of release version information corresponding to the release version number into the release version table; judging whether an existing coverage rate analysis task corresponding to the service name in the project parameter exists in a coverage rate analysis table or not; if so, updating the platform ip and platform port fields in the existing coverage rate analysis task by using the platform ip and platform port in the project parameters, and setting the task state to be valid; and if not, adding a coverage rate analysis task corresponding to the service name in the project parameter into the coverage rate analysis table.

Generating a difference analysis task according to the project parameters, specifically comprising: judging whether the release version number in the item parameter exists in a release version table or not; if so, judging whether an old version exists in the release version number, wherein the old version is a version before the current service version; if yes, judging whether an existing difference analysis task corresponding to the service name in the project parameter exists in the difference analysis table; and if not, adding a difference analysis task corresponding to the service name in the project parameter into the difference analysis table.

Wherein, executing the full coverage analysis and generating a full coverage analysis report, specifically comprising: judging whether a full coverage analysis task with an online task state exists according to the timing task scanning; if so, judging whether a platform ip and a platform port in the project parameters corresponding to the full coverage analysis task can be accessed; if so, judging whether the time from the previous successful execution of the full coverage rate analysis task to the current full coverage rate analysis task is longer than a second time period; if so, judging whether the git downloading source code state and the maven packing state of the source code of the test service corresponding to the current full coverage rate analysis task are successful or not; if the total coverage rate analysis task is successful, directly executing the current total coverage rate analysis task, generating an analysis report, and updating the task state of the total coverage rate task; and if the verification is unsuccessful, executing the git downloading source code and the maven package, respectively updating the downloading source code state and the packaging state, then executing the current full coverage rate analysis task, generating a full coverage rate analysis report, and updating the full coverage rate analysis state.

The method includes the steps of performing incremental coverage analysis and generating an incremental coverage analysis report, and specifically includes: judging whether an incremental coverage analysis task with an online task state exists according to the timing task scanning; if so, judging whether a platform ip and a platform port in the project parameters corresponding to the incremental coverage analysis task can be accessed; if so, judging whether the distance between the current incremental coverage analysis task and the last time of successfully executing the incremental coverage analysis task is greater than a second time period; if so, judging whether the git downloading source code state and the maven packing state of the source code of the test service corresponding to the incremental coverage analysis task are successful or not; if the incremental coverage rate analysis task is successful, judging the differential analysis state of the source code of the test service corresponding to the incremental coverage rate analysis task; when the difference analysis state is not started or failed, not executing an increment coverage rate analysis task; updating the incremental coverage analysis state to be non-incremental when the difference analysis state is successful and there is no difference or no old version between the two versions; when the difference analysis state is that the analysis is successful and there is a difference between the two versions of the analysis, executing the current incremental coverage analysis task, generating an incremental coverage analysis report, and updating the incremental coverage analysis state.

Wherein, executing version difference analysis and generating a difference analysis report, specifically comprising: judging whether a difference analysis task with an online task state and an uninitiated or failed analysis state exists according to the timing task scanning; if so, judging whether a platform ip and a platform port in the project parameters corresponding to the difference analysis task can be accessed; if so, judging whether the time from the last successful execution of the difference analysis task to the current difference analysis task is longer than a second time period; if so, judging whether the git downloading source code state and the maven packing state of the source release version and the target release version of the test service corresponding to the current difference analysis task are both successful; if the difference analysis is successful, executing the full difference analysis, generating a difference analysis report, updating the difference analysis state to be successful, and changing the difference analysis execution result of the source release version and the target release version.

When the difference analysis task is executed, comparing each package and each file of the source version and the target version one by one to generate difference data; the difference data is a change code line identification and a change type.

Wherein, when the coverage rate analysis task is executed, one or more of line coverage rate, class coverage rate, branch coverage rate, method coverage rate, instruction level coverage rate, circle complexity and statement block coverage rate are analyzed.

In a second aspect of the present invention, there is provided a jacoco-based test analysis system, comprising: the jaccoagent module is used for modifying the source code of the jaccoagent to obtain a customized project parameter and adding the jaccoagent in a starting script of the test service to transfer the project parameter; the jaccoagent data receiving module is used for providing an interface called by the jaccoagent, and analyzing the service information corresponding to the project parameters after receiving the project parameters through the interface so as to generate a coverage rate analysis task or a difference analysis task corresponding to the service information; the timing task module is used for scanning the tasks at fixed time, and calling the corresponding task module to execute the coverage rate analysis task or the difference analysis task when the coverage rate analysis task or the difference analysis task meeting the conditions is scanned; the project parameters at least comprise a project name, a service name, a release version number, a code branch, a platform ip and a platform port of the test service.

Wherein, still include: a front end display module; the jaccoagent module is specifically configured to: uploading the jacobage.jar file to a specified position of a server where the test service is located, so that the jacobage is used for starting a test service script and transmitting the project parameters; the jaccoagent data receiving module is specifically configured to: judging whether the service information corresponding to the project parameter exists in the data displayed on the service management page of the front-end display module; if yes, generating a coverage rate analysis task according to the project parameters; and/or, if an old version of the test service exists and also exists, generating a difference analysis task according to the project parameters; the timing task module is specifically configured to: and scanning the tasks according to preset time, and calling a coverage rate analysis module to execute the coverage rate analysis tasks or calling a difference analysis module to execute the difference analysis tasks or calling the difference analysis module to execute the difference analysis tasks when the coverage rate analysis tasks or the difference analysis tasks meeting the conditions are scanned.

When the jaccoagent data receiving module executes the operation of generating a coverage analysis task according to the project parameters, the jaccoagent data receiving module is specifically configured to: judging whether the release version number in the item parameter exists in a release version table or not; if the version number does not exist, adding a piece of release version information corresponding to the release version number into the release version table; judging whether an existing coverage rate analysis task corresponding to the service name in the project parameter exists in a coverage rate analysis table or not; if so, updating the platform ip and platform port fields in the existing coverage rate analysis task by using the platform ip and platform port in the project parameters, and setting the task state to be valid; if not, adding a coverage rate analysis task corresponding to the service name in the project parameter to the coverage rate analysis table; wherein the coverage analysis task comprises a full coverage analysis task and/or an incremental coverage task.

When the jaccoagent data receiving module executes the operation of generating a difference analysis task according to the project parameters, the jaccoagent data receiving module is specifically configured to: judging whether the release version number in the item parameter exists in a release version table or not; if so, judging whether an old version exists in the release version number, wherein the old version is a version before the current service version; if yes, judging whether an existing difference analysis task corresponding to the service name in the project parameter exists in the difference analysis table; and if not, adding a difference analysis task corresponding to the service name in the project parameter into the difference analysis table.

Wherein the coverage analysis module comprises a full coverage analysis module for performing a full coverage analysis; the timing task module executes the following specific operations: judging whether a full coverage analysis task with an online task state exists according to the timing task scanning; if so, judging whether a platform ip and a platform port in the project parameters corresponding to the full coverage analysis task can be accessed; if so, judging whether the time from the previous successful execution of the full coverage rate analysis task to the current full coverage rate analysis task is longer than a second time period; if so, judging whether the git downloading source code state and the maven packing state of the source code of the test service corresponding to the current full coverage rate analysis task are successful or not; if the total coverage rate analysis is successful, directly executing the current total coverage rate analysis task by the total coverage rate analysis module, generating an analysis report, and updating the task state of the total coverage rate task; if the test is unsuccessful, calling the full coverage analysis module to obtain a source code of the test service, executing the git downloading source code and maven packaging, respectively updating the downloading source code state and the packaging state, executing the current full coverage analysis task, generating a full coverage analysis report, and updating the full coverage analysis state.

Wherein the coverage analysis module comprises an incremental coverage analysis module to perform an incremental coverage analysis; the timing task module executes the following specific operations: judging whether a full coverage analysis task with an online task state exists according to the timing task scanning; if so, judging whether a platform ip and a platform port in the project parameters corresponding to the incremental coverage analysis task can be accessed; if so, judging whether the distance between the current incremental coverage analysis task and the last time of successfully executing the incremental coverage analysis task is greater than a second time period; if so, judging whether the git downloading source code state and the maven packing state of the source code of the test service corresponding to the incremental coverage analysis task are successful or not; if the incremental coverage rate analysis task is successful, judging the differential analysis state of the source code of the test service corresponding to the incremental coverage rate analysis task; when the difference analysis state is not started or failed, not executing an increment coverage rate analysis task; when the difference analysis state is a successful non-difference or non-old version, updating the incremental coverage analysis state to be non-incremental; when the difference analysis state is analysis success and the two analyzed versions have difference, calling the incremental coverage analysis module to execute the current incremental coverage analysis task, generating an incremental coverage analysis report, and updating the incremental coverage analysis state.

The timing task module executes the following specific operations: judging whether a difference analysis task with an online task state and an uninitiated or failed analysis state exists according to the timing task scanning; if so, judging whether a platform ip and a platform port in the project parameters corresponding to the difference analysis task can be accessed; if so, judging whether the time from the last successful execution of the difference analysis task to the current difference analysis task is longer than a second time period; if so, judging whether the git downloading source code state and the maven packing state of the source release version and the target release version of the test service corresponding to the current difference analysis task are both successful; if the difference analysis is successful, the difference analysis module is called to execute the difference analysis, a difference analysis report is generated, the difference analysis state is updated to be successful, and the difference analysis execution result of the source release version and the target release version is changed.

In a third aspect of the present invention, there is provided a terminal device comprising a processor and a storage device, the storage device being adapted to store a plurality of program codes, the program codes being adapted to be loaded and run by the processor to perform the steps of the jacoco-based test analysis method according to any of the preceding first aspects.

In a fourth aspect of the invention, a terminal device is provided, which comprises the jacoco-based test analysis system of any one of the second aspects.

In a fifth aspect of the invention, a service platform is provided, which comprises the jacoco-based test analysis system of any one of the second aspects.

In a sixth aspect of the present invention, there is provided a computer readable storage medium storing a plurality of program codes, wherein the program codes are adapted to be loaded and executed by the processor to perform the steps of the jacoco-based test analysis method according to any one of the preceding first aspects.

One or more technical schemes of the invention at least have one or more of the following beneficial effects:

according to the technical scheme, jacoco is developed for the second time, and a scheme for carrying out test coverage statistical analysis and version difference analysis is developed by using flash, so that the service logic of reconstruction and redevelopment is realized, and in the test of the program code, the full coverage, the incremental coverage and the difference comparison analysis among different test versions of the test version can be automatically obtained only by a small amount of configuration. Therefore, the condition that the full coverage rate in the test activity process cannot be counted from the code level in the test process is avoided, and further, whether the test design is sufficient in the previous period, whether the codes are abandoned or not can be reversely deduced through codes which are not covered in the coverage rate report.

Furthermore, by the technical scheme of the invention, the condition that the coverage rate of the test increment cannot be counted from the code level in the test activity process is avoided, and the coverage rate of the increment part of the current version can be determined by counting the coverage rate of the newly added or changed code between different versions, so that the increment coverage rate between different test versions is obtained, and whether the newly added or changed code is tested in place or not can be determined.

Furthermore, by the technical scheme of the invention, the situation that the difference comparison between different test versions is difficult is avoided, and the difference analysis results of different test versions can be conveniently generated. Therefore, through difference comparison and analysis, a tester can select the function cases related to the partial codes for testing aiming at the partial codes with the differences, so that the regression testing range is reduced, the testing accuracy is improved, and the labor and the time are saved.

Drawings

Embodiments of the invention are described below with reference to the accompanying drawings, in which:

FIG. 1 is a block diagram of one embodiment of a jacoco-based test analysis system according to the invention;

FIG. 2 is a flow chart illustrating the main steps of the present invention in performing processing according to one embodiment of FIG. 1;

FIG. 3 is a flow chart illustrating the main steps of the generation of a coverage analysis task according to an embodiment of the present invention;

FIG. 4 is a flow chart illustrating the main steps involved in the generation of a variance analysis task according to an embodiment of the present invention;

FIG. 5 is a flow chart illustrating the main steps of a full coverage analysis according to an embodiment of the present invention;

FIG. 6 is a flow chart illustrating the main steps involved in incremental coverage analysis in an embodiment of the present invention;

FIGS. 7 and 8 are schematic diagrams of the effect of coverage analysis on full/incremental coverage analysis according to an embodiment of the present invention;

FIG. 9 is a flow chart illustrating the main steps of a variance analysis according to an embodiment of the present invention;

FIGS. 10 and 11 are schematic diagrams of the analysis effect of the difference analysis according to an embodiment of the solution of the invention;

fig. 12 and 13 are examples of the technical solution according to the present invention applied to a terminal device or a service platform.

Detailed Description

Some embodiments of the invention are described below with reference to the accompanying drawings. It should be understood by those skilled in the art that these embodiments are only for explaining the technical principle of the present invention, and are not intended to limit the scope of the present invention.

In the description of the present invention, a "module" or "processor" may include hardware, software, or a combination of both. A module may comprise hardware circuitry, various suitable sensors, communication ports, memory, may comprise software components such as program code, or may be a combination of software and hardware. The processor may be a central processing unit, microprocessor, image processor, digital signal processor, or any other suitable processor. The processor has data and/or signal processing functionality. The processor may be implemented in software, hardware, or a combination thereof. Non-transitory computer readable storage media include any suitable medium that can store program code, such as magnetic disks, hard disks, optical disks, flash memory, read-only memory, random-access memory, and the like. The term "a and/or B" denotes all possible combinations of a and B, such as a alone, B alone or a and B. The term "at least one A or B" or "at least one of A and B" means similar to "A and/or B" and may include only A, only B, or both A and B. The singular forms "a", "an" and "the" may include the plural forms as well.

Some terms to which the present invention relates are explained first.

jacoco, Java Code Coverage, is a Coverage tool for the open source of the Java language. Jacoco can be embedded into ant and maven, and java programs can also be monitored by using java technology. Jacoco can realize on-the-fly instrumentation through jacocoagent. jacoco contains coverage counters of various scales, including instruction level coverage (C0 coverage), branch (C1 coverage), round-robin complexity (cyclic complexity), line coverage (Lines), method coverage (non-abstract methods), class coverage (classes).

jaccoagent: jacoco uses a class file tool to record row coverage data and uses javaagent to detect class files in an on-the-fly mode. The Jacocoagent can be used as a dependence and a plug-in of a third party and put into an xml file, so that the problem of acquiring the coverage rate of a test code during maven compiling is solved; and code coverage rate data in the server can be acquired by configuring the jar packet into a service process. And the Listener module of the Jacocoagent monitors whether the request is received, and when the Dump request is received, the Jacocoagent generates a test report according to the code coverage rate data.

on-the-fly mode: the usage of jacoco is divided into three parts, wherein the first part is injection and collection, the second part is export, the third part is report generation, and the three parts can be executed separately. Firstly, adding a java option in a starting command line of a tested program, and designating jaccoagent. The jaccoagent collects execution information. There are three different patterns of derived data: 1) a file system: when the JVM stops, the data is exported to a local file; 2) TCP socket Server: monitoring port connection, and acquiring execution data through socket connection. At VM exit, data reset and data export may be selected. 3) TCP socket Client: when starting, the jaccoagent is connected to a given TCP end, data is written to the socket when requested, and data resetting and data exporting can be selected when the VM exits.

git: the system is an open-source distributed version control system, and can effectively process the version management of projects from very small to very large at high speed. git has many advantages such as good version branch control, version number management, and is applied to the actual project management of most internet companies. In the coverage rate obtaining process based on jacoco, the source code for development and modification (including the original version code and the modified version code) is stored in a code warehouse preset by a server.

The main implementation process of one embodiment of the technical scheme of the invention is as follows: adding a jacobage in a start script of a test service so as to transmit a customized project parameter through the jacobage; analyzing the service information corresponding to the input project parameters, and generating an analysis task corresponding to the service information; and executing the analysis task regularly. The method comprises the steps that a modified jaccoagent startup script is added into a tested service, the jaccoagent collects execution information and transmits data of the tested service to an analysis system according to a specified path, a coverage rate analysis task and/or a difference analysis task are/is generated, and the corresponding analysis task is determined to be executed through timing task scanning. Therefore, the data condition of the test of the tested service/test program is periodically transmitted to the analysis platform, so that the analysis platform can conveniently count the test full/incremental coverage rate from the code level in the test activity process; furthermore, whether the test design is sufficient in the previous period, whether a waste code exists or not and the like can be deduced reversely through codes of uncovered parts in the coverage rate report; furthermore, the incremental coverage rate (the difference analysis state of the two versions) between different test versions exists, and whether the newly added or changed codes are tested in place or not can be determined; the defect of difficulty in difference comparison between different test versions is overcome, and therefore through difference comparison analysis, a tester can select the function cases related to the partial codes for testing aiming at the partial codes with differences, the regression test range is narrowed, the test accuracy is improved, and manpower and time are saved.

FIG. 1 is a schematic diagram of the schematic structure of an embodiment of a joco-based test analysis system according to the present invention for implementing coverage, version difference analysis.

As shown in fig. 1, the system structure includes a jaccoagent module 1, a jaccoagent data receiving module 2, a full coverage analysis module 3, an incremental coverage analysis module 4, a difference analysis module 5, a timing task module 6, and a front-end display module 7.

The jaccount module 1 customizes parameters such as a project name, a service name, a version number, a code branch/code warehouse branch, a platform IP, a platform port and the like by modifying a jaccount source code, and simultaneously generates a monitoring interface of the jaccount automatically and randomly.

Adding a javacent option in a starting command line of the tested service by the jaccoagent module 1, designating jaccoagent. After the successful start, the jacocoagent collects execution information, the data of the service to be tested is automatically reported to a specified interface of a test coverage rate platform (such as the jacoco-based test analysis system of the invention), and a heartbeat is sent to the test coverage rate platform every a first time period (for example, 5 minutes). Therefore, the data generated after the tested service starting test can be obtained, and coverage rate analysis (such as statistics) and even difference analysis and the like can be carried out.

The jaccount data receiving module 2 provides a data receiving interface to communicate with the sending interface of the jaccount module 1. After the data receiving interface receives the data reported by the jacocogent module, the data is compared with the existing data displayed on the service management page in the front-end display module 7, and if the corresponding record of the service name, the version number and the code branch uploaded by jacoco is confirmed to exist, a coverage analysis task is generated.

Receiving the reported data and comparing, specifically, for example: a service name (servicename), a version number (serviceversion), a branch (gitbrac, referring to a code warehouse branch) can be input/configured through the service management page, and a corresponding gitlab warehouse address, a username and password and the like can be configured at the same time, and the data are stored in a database (such as mysql); if jaccoagent uploads data (custom project parameters): if the service name + version number + code branch is not matched with the existing record in the database (namely the service information does not exist), the data parameters uploaded by the jaccoagent cannot be reserved, the tested service cannot be analyzed, namely the corresponding gitlab warehouse address and password cannot be found, and the analysis cannot be carried out; and if jaccoagent uploads data (custom project parameters): if the service name + version number + code branch and the record in the database exist, the corresponding record exists, and the parameter is inserted into the corresponding table in the database, so that the analysis process is triggered.

Further, the coverage analysis task may be a full coverage analysis task, or an incremental coverage analysis task, or a full coverage analysis task and an incremental coverage analysis task are generated simultaneously. Further, if the old version of the service is confirmed, a difference analysis task is generated.

The full coverage analysis task is completed by the full coverage analysis module 3. The full coverage analysis module 3 pulls the source code of the corresponding service from the code warehouse, packages the code, moves the source code, the code of the dependent package and the jar package to the specified directory, generates a configuration file according to the code directory, and obtains a full coverage report according to the configuration file.

Usually, after a programmer writes a program, the program is uploaded to a specific code warehouse, and when the code needs to be tested, the current version of the code is pulled from the code warehouse. After the code is pulled, the code is packed to generate a corresponding test packet.

In one particular embodiment, the full coverage analysis module 3 uses a git clone to pull the source code of the corresponding test service from the code repository, cloning the data into the new directory.

In a particular embodiment, the code packaging of the source code of the corresponding test service is a maven packaging.

In a specific embodiment, the full coverage analysis module 3 generates a build.xml file executed by an ant command according to the code directory, and executes the ant run command to obtain a full coverage report in an html format.

The incremental coverage analysis task is performed by an incremental coverage analysis module 4. The incremental coverage analysis module 4 firstly judges whether the source codes of the two versions are successfully pulled, if so, further confirms whether the java files of the two versions are different, acquires packet paths of the files with the difference, generates a configuration file, and obtains an incremental coverage report of the file packet with the difference according to the configuration file.

The two versions refer to the current version and the last version, i.e. the old version.

In a specific embodiment, the incremental coverage analysis module 4 generates a build.xml file executed by an ant command, and executes an ant run command to obtain a coverage report of the differentiated file package in the html format.

Further, the incremental coverage analysis module 4 modifies the html file, so that the coverage report is accurate to the class, and the incremental coverage report is generated.

The disparity analysis task is performed by the disparity analysis module 5. The difference analysis module 5 compares each package and each file of the two versions one by one, generates difference data, and stores the difference data in a database, such as mongodb.

The timing task module 6 executes a full coverage rate analysis task, an incremental coverage rate analysis task and a difference analysis task at regular time, and if the tasks meeting the execution conditions are scanned, the

corresponding module

4, 5 or 6 is called to execute corresponding analysis.

The front-end display module 7 comprises three front-end pages, namely a service management page, a coverage analysis management page and a difference analysis management page, and displays the results executed by the jaccount module 1, the jaccount data receiving module 2, the full coverage analysis module 3, the incremental coverage analysis module 4, the difference analysis module 5 and the timing task module 6 through the three front-end pages and corresponding background interfaces.

Fig. 2 is a schematic flow chart of the main steps of an embodiment of a corresponding method according to an embodiment of the system of fig. 1. The method comprises the following steps:

s201, adding a jaccoagent program in a start script of a service to be tested (namely the service to be tested/the program to be tested), and transmitting parameters.

Adding a jaccount option in a start script of the tested service, and designating jaccount.

Specifically, the jaccoagent module 1 modifies a jaccoagent source code to customize parameters such as a project name, a service name, a version number, a code branch, a platform IP (service _ IP), a platform port (service _ port), and the like, and simultaneously, randomly and automatically generates a monitoring interface. The jacobount module 1 uploads jacobount.jar to a designated position of a server where a service to be tested is located, and adds jacobount $ { path } ═ include ═ package ·, output ═ tcp server, port $ { coverage platform port }, address $ { coverage platform IP }, localadress $ { IP } of the server where the current service is located, servicename $ { service name }, namespace $ { project name }, serviceversion $ { issue }, girranch $ { git branch or tag }, ap ═ true, and starts the service.

The jaccoagent collects execution information. Jar is used for specifying a path of jaccoagent. The start script of the service starts the agent program added in the service, receives the parameters and sends the parameters to the jacobage data receiving module 2.

Wherein, the meaning of each parameter is as follows:

include: indicating that only the classes under the specified package are analyzed for coverage injection, by default.

output: and an output mode representing the coverage. The valid options include: file, tcpserver, tcpclient, none. Under the tcpserver mode, jacoco can uniformly write coverage rate data acquired and collected currently to a specified ip and a specified port when a client executes dump operation.

port: the original limit only used by tcpserver and tcpclient indicates the port number of the application server to be monitored, and original jacobage defaults to 6300, and here, according to the embodiment of the present invention, the port number 5000 of the coverage analysis platform is introduced by modifying the code of jacobage, and is a random port automatically generated by the modified jacobage, and is sent to the coverage analysis platform (i.e., jacobo-based test analysis system) through the interface in the background.

address: only tcpserver and tcpclient are used, indicating the intercepted application server IP address or hostname.

localadress: indicating the IP of the server where the current service under test is located.

servicename: indicating the service name of the current service under test.

namespace: and the item name of the item to which the current tested service belongs is represented.

serviceversion: indicating the release version number of the current service under test.

gitbranch: the branches or tags are listed.

and (4) append: the default is true, which indicates the manner of adding coverage data. When the client executes dump operation, if the exec coverage file already exists, the coverage data of the round is directly appended at the end of the text, so that the exec coverage file already exists, and the coverage data of the round is larger and larger. If the coverage is changed to false, the client will directly empty the content of the original coverage file when performing dump operation, and ensure that the coverage file has only the coverage data of the round.

S202, processing the data uploaded by the jaccoagent, and generating a coverage rate analysis task and/or a difference analysis task.

A tester inputs a record through a service management page, wherein the record comprises a project name, a service name, a release version number, a code warehouse address, a code warehouse branch, a code warehouse user name and a password. Users using the system, such as testing personnel, only need to maintain basic data of the service on the service management page, corresponding parameters are transmitted when the jaccoagent is started, and the analysis process can be automatically carried out.

After the jaccoagent data receiving module 2 receives the data reported by the jaccoagent module 1, comparing the data with the data recorded through the service management page, judging whether service information such as items, services and versions uploaded by jacoco exists, if the service information exists, generating a coverage rate analysis task by the jacocoagent data receiving module, wherein the coverage rate analysis task can be a full coverage rate analysis task or an incremental coverage rate analysis task, or simultaneously generating the full coverage rate analysis task and the incremental coverage rate analysis task. Further, if the old version of the service is confirmed, a difference analysis task is generated.

The data uploaded by the jaccoagent is compared with the data of the service management page, mainly for finding out the code warehouse address/user name/password corresponding to the service name + version number + branch, and the subsequent analysis needs to download the source code to the server through the warehouse address.

If the service name + version number + code branch uploaded by the jacobount is configured in the service management page, the parameters carried by the jacobount, including the namespace (item name) + agent monitoring interface, are updated to a table related to the coverage analysis and difference analysis of the mysql, a subsequent analysis process finds a code warehouse to download source codes through the service name + version number + branch in the table, and coverage data are discarded through a tcp-server mode dump through an agent IP and an agent monitoring port in the table.

S203, scanning is carried out through the timing task module 6, and if a full coverage analysis task with an execution interval larger than a second time period exists, the step S204 is skipped; if there is an incremental coverage analysis task that is executed at intervals greater than the second time period, it jumps to step S205.

And step S204, calling the full coverage rate analysis module 3 to perform full coverage rate analysis, and ending the process.

Step S205, the incremental coverage analysis module 4 is called to perform incremental coverage analysis, and the process is ended.

The tester can view the full/incremental coverage results directly on the coverage analysis management page of the system and can click on the link to view the detailed report.

The code coverage data may include a proportion of the number of lines of the coverage code to the number of lines of the total code, package, class, method, and line information of the coverage code, and so on.

In a particular embodiment, the second time period is 30 minutes.

Further, the timing task module 6 may scan, and if there is a coverage analysis task that has not been executed or the execution result of the difference analysis is a failure, the step S206 is skipped.

And S206, calling the difference analysis module 5 to perform version difference analysis, and ending the process.

The difference analysis module executes task scanning at regular time, compares each package and each file of the two versions one by one, generates difference data, and stores the difference data into a database, such as mongodb.

The tester can directly view the difference analysis report on the difference analysis management page of the system.

In a particular embodiment, the report may be displayed in a tree structure, accurate to each row, convenient, intuitive, and easy to use.

FIG. 3 is a flow chart of the main steps of a generation process of a coverage statistics task in an embodiment of a jacoco-based test analysis method according to the present invention. It includes:

s301, starting the java program to be tested by using the jaccoagent.

S302, processing the data uploaded by the jaccoagent, judging whether corresponding service information exists according to servicename, serviceversion and gitbrach parameter information, if the item name, the service name or the release version number uploaded by the jaccoagent does not exist, jumping to S303, and if the item name, the service name or the release version number exists, jumping to S304.

Further, it is judged that the jaccoagent uploaded data can only pass through the service name + version number + branch. Because the project names Namespace are only used for distinguishing which projects are, and the service management page is only used for managing the service, one service can be deployed on a plurality of projects, but if the plurality of projects use the same service, the plurality of projects only need to be configured once, and therefore, the comparison of the project names can be omitted.

Specifically, after receiving the data uploaded by the jaccount module, the jaccount data receiving module 2 compares the data with data entered through a service management page, and determines whether information of services such as the services uploaded by jacoco exists according to servicename, serviceversion, and gitbrach parameters. (for an example of specific comparison of the uploaded data, see the description of the jaccoagent data receiving module 2 above). For example, the test service is simply understood as an application program, a jar packet of a java program, a service name + version number + code branch can determine a unique warehouse code, the first step of jacobount is to determine whether the service name + version number + branch exists, if so, the data is inserted into the coverage and difference analysis related table, and when the analysis is performed later, the later analysis process is triggered by scanning the coverage and difference analysis related table.

And S303, not processing.

S304, judging whether the release version number of the current version exists in the release version table, if so, jumping to the step S303, and if not, jumping to the step S305.

In one example, each service has a version number (major version number), for example, 5.1.1.7.2.4 type external version number of android, but there is not only one Jar package during a major version number, and there is a release version number, that is, during the whole major version development process, there is one Jar package for each test of development to the test environment, and each Jar package corresponds to a release version number. For example, the service major version number of cw-bat-service is 2.4.5, and may correspond to N release version numbers, 2.4.5-T2011171128, 2.4.5-T2011191203 and the like. The serviceversion of the knee on the parameter with the jaccoagent source code modified is actually the release version number releaseversion 2.4.5-T2011171128. Comparing the release version number with the version number in service management, for example, comparing the text/symbol/number before the release version number is "-" with the version number provided in the service management page: suppose the service version number is 2.4.5 and the release version number is 2.4.5-T2011192010, the characters before the release version number is 'minus' are compared with the service version number, namely 2.4.5.

Further, the coverage rate and the difference analysis are analyzed for each jar packet, and jar packets corresponding to different release version numbers are different, so that data uploaded by each jaccoagent needs to determine whether a record exists in a release version number table, if not, the record is inserted, and if so, the operation is not needed.

S305, adding a new release version information corresponding to the release version number to the release version table.

S306, judging whether the coverage rate analysis table has a coverage rate analysis task corresponding to the current service, if so, jumping to the step S307, and if not, jumping to the step S308.

S307, if the coverage analysis table already has a coverage analysis task corresponding to the current service, the task does not need to be repeatedly established, the service _ ip and the service _ port fields of the existing coverage analysis task of the coverage analysis table are directly updated by using the service _ ip and the service _ port parameters in the jaccoagent, the task state is set to be valid, and the process is ended.

S308, if the coverage rate analysis table does not have a coverage rate analysis task corresponding to the current service, the jaccoagent data receiving module adds a new coverage rate analysis task to the coverage rate analysis table, wherein the coverage rate analysis task can be a full coverage rate analysis task or an incremental coverage rate analysis task, or simultaneously generates the full coverage rate analysis task and the incremental coverage rate analysis task, and the process is ended.

The specific coverage rate to be used is determined by the content of the test stage, for example, in the case of pre-online test, regression test, etc., the change of the change point is mainly concerned, the effect of using the incremental coverage rate is more ideal, and if the test is a test of newly adding a function, the effect of using the full coverage rate is more ideal.

The coverage analysis task may include analysis of line coverage (Lines), class coverage (classes), branch coverage (Branches, C1coverage), method coverage (non-abstract methods), instruction level coverage (Instructions, C0coverage), cycle complexity (cyclic complexity), and statement block coverage, etc.

FIG. 4 is a flow chart of the main steps of the generation of the variance analysis task according to an embodiment of the method for statistical and analysis based on jacoco test of the present invention, as shown in FIG. 4, including the following steps:

s401, starting the java program to be tested by using the jaccoagent.

S402, processing the data uploaded by the jaccount, and judging whether the service information exists or not by using the servicename, serviceversion and gitbrach parameter information, if the item name, the service name or the release version number uploaded by the jaccount does not exist, jumping to the step S403, and if the item name, the service name or the release version number exists, jumping to the step S404. The uploaded data and database relationships were compared as described above.

Specifically, after receiving the data reported by the jaccount module, the jaccount data receiving module compares the data with the data entered through the service management page, and judges whether the service information such as the service name uploaded by jacoco exists according to the servicename, serviceversion and gitbrach parameters.

For example, the test service is simply understood as an application program, a jar packet of a java program, a service name + version number + code branch can determine a unique warehouse code, the first step of jacobount is to determine whether the service name + version number + branch exists, if so, the data is inserted into the coverage and difference analysis related table, and when the analysis is performed later, the later analysis process is triggered by scanning the coverage and difference analysis related table.

And S403, no processing is performed.

S404, judging whether the release version number of the current version exists in the release version table, if not, jumping to the step S403, and if so, jumping to the step S405.

In one example, each service has a version number (major version number), for example, 5.1.1.7.2.4 type external version number of android, but there is not only one Jar package during a major version number, and there is a release version number, that is, during the whole major version development process, there is one Jar package for each test of development to the test environment, and each Jar package corresponds to a release version number. For example, the service major version number of cw-bat-service is 2.4.5, and may correspond to N release version numbers, 2.4.5-T2011171128, 2.4.5-T2011191203 and the like. The knee compares the published version number with the version number in service management, for example, compares the text/symbol/number before the published version number is "-" with the version number provided in the service management page: suppose the service version number is 2.4.5 and the release version number is 2.4.5-T2011192010, the characters before the release version number is 'minus' are compared with the service version number, namely 2.4.5.

S405, judging whether the current version has an old version, if not, skipping to the step S403 without difference analysis, and if so, skipping to the step S406.

S406, if the current release version has an old version, judging whether the difference analysis table has a difference analysis task corresponding to the current service, if so, skipping to the step S403 without repeated analysis, and if not, skipping to the step S407.

S407, if the difference analysis table does not have the difference analysis task corresponding to the current service, adding a new difference analysis task into the difference analysis table, wherein the state of the difference analysis task is automatic, comparing the difference between the current version and the old version, and ending the whole process.

In a particular embodiment, the default is to compare the difference between the current version and the previous version.

In a specific embodiment, the difference analysis module uses gitdiff tool to compare and analyze the java files of the two versions to obtain the code difference state information between the codes of the two versions.

In a specific embodiment, the code difference information between the two versions of code may be information such as the line identification of the changed code line (e.g., the line number of the changed code line) and the type of change. For example, the 7 th, 8 th and 9 th lines in the current version code are new code lines, the 2 nd, 3 th and 4 th lines in the old version code are deleted code lines, or the 7 th line in the old version code is replaced by the 14 th line in the current version code, etc. The type of change may include delete, add, replace, etc.

In a specific embodiment, to facilitate the calculation of the coverage rate and improve the speed of the coverage rate test, the code difference information may be further converted into a tag format representation, wherein the code difference tag may represent the difference information between the code lines, such as the identity of the code line to be changed and the change type, and the like. For example: the code difference tag may include a change type identifier for indicating a type of change to the code and a change code line identifier for identifying a line of change code.

FIG. 5 is a flow chart illustrating the main steps of a full coverage analysis in one embodiment of a jacoco-based test analysis method according to the present invention.

Wherein, the timed task module 6 executes the timed task, and if the full coverage rate task meeting the execution condition is scanned, executes the command of generating the full coverage rate analysis report.

The task meeting the execution condition refers to a full coverage analysis task in which the task state is online, and the time interval between the current task and the last successful execution of the full coverage analysis task is greater than a second time period, for example, 30 minutes. The method specifically comprises the following steps:

s501, timing task scanning is executed.

S502, judging whether a full coverage rate analysis task with a task state of an online state is scanned, if not, jumping to the step S503, and if so, jumping to the step S504.

S503, if the task with the task state being the online state is not scanned, the task which is not to be executed currently is represented, and no operation is performed.

S504, if the task with the task state being online state is scanned, further judging whether the address and the port (i.e. ip: port) of the service corresponding to the full coverage rate analysis task can be accessed, if not, jumping to the step S505, otherwise, jumping to the step S506.

And S505, if the address and the port of the service cannot be connected, setting the task to be in an off-line state, and not analyzing.

S506, if the address and the port of the service can be connected, whether the time from the current task to the last successful execution of the full coverage analysis task is longer than the second time period is further judged, if not, the step S507 is skipped, and if so, the step S508 is skipped.

And S507, as the time of the current task for successfully executing the full coverage rate analysis task last time is less than the second time period, no operation is performed.

S508, if the time of the current task from the last successful execution of the full coverage analysis task is longer than the second time period, further judging whether the git downloading source code state and the maven packing state of the source code of the service are successful, if so, jumping to the step S509, otherwise, jumping to the step S510.

In one embodiment, for the full coverage analysis module 3, using git clone to pull the source code of the corresponding test service from the code repository, and clone the data into the new directory, and the code packaging of the source code of the corresponding test service is maven packaging, that is, the executed gitclone and maven packaging, which are executed during the full coverage analysis. And other analyses may be performed after the full coverage analysis is performed. And, after the full-scale analysis is performed, the status of git clone and maven is updated in the database coverage rate table cw _ coverage _ analysis. When performing incremental coverage analysis and variance analysis, this status is looked up in the table of item names namespace + service + releasepersonification to coverage analysis.

The system downloads the code according to the corresponding code branch and submitted version number by using the git command according to the transmitted parameters, and updates the code downloading state.

The system further packages the code to generate a corresponding test package while updating the maven state.

S509, if the git downloading source code state and the maven packing state are successful, the git downloading source code and the maven packing operation are not executed again, and the step S512 is skipped.

It should be noted that all analyses are based on source code. If the code of the source code has been downloaded and masen has been packaged, the analysis process will continue without repeating downloading and packaging.

S510, if the git source code downloading state and the maven packing state are unsuccessful, executing git source code downloading and maven packing operation, and updating git and maven states. And judging whether the git and maven states are updated successfully, if the git and maven states are updated unsuccessfully, jumping to the step S511, otherwise, jumping to the step S512.

And S511, if the state updating is unsuccessful, not performing full coverage analysis.

S512, if the state is updated successfully, performing full coverage analysis, generating a jacoco analysis full coverage analysis report, storing the report into a database (for example, mysql), updating the full coverage state of the service to be successful, and ending the whole process.

And analyzing all the class files corresponding to all the codes together to generate a coverage rate file. When analyzing the generated full coverage rate file, not all the coverage rate file is needed to be analyzed, and only the part of the function code covered by the test function needs to be concerned.

FIG. 6 is a flow chart illustrating the main steps of incremental coverage analysis in one embodiment of a jacoco-based test analysis method according to the present invention.

In the method, the timing task module 6 executes the timing task, and if the increment coverage rate task meeting the execution condition is scanned, a command for generating an increment coverage rate analysis report is executed.

The task meeting the execution condition is that the task state is online, the time of the current task from the last successful execution of the incremental coverage analysis task is longer than the second time period (for example, 30 minutes), and the incremental coverage analysis task packed by maven is executed after the source code is downloaded by git. Specifically, the method comprises the following steps:

s601, executing timing task scanning.

S602, judging whether the incremental coverage rate analysis task with the task state being the online state is scanned, if not, jumping to the step S603, and if so, jumping to the step S604.

S603, if the incremental coverage rate analysis task with the task state being the online state is not scanned, the current task to be executed is not detected, and no operation is performed.

S604, if the incremental coverage rate analysis task of which the task state is the online state is scanned, further judging whether the address and the port of the service corresponding to the task can be accessed, if not, jumping to the step S605, otherwise, jumping to the step S606.

And S605, setting the incremental coverage rate analysis task to be in an off-line state, and not analyzing.

And S606, further judging whether the time from the current task to the last successful execution of the incremental coverage analysis task is greater than the second time period, if not, jumping to the step S607, and if so, jumping to the step S608.

And S607, as the current task is less than the second time period from the time of the last successful execution of the incremental coverage analysis task, no operation is performed.

S608, further determining whether a git download source code state (i.e. git clone) and a maven packing state of the source code of the service corresponding to the incremental coverage analysis task are successful, if not, jumping to S609, otherwise, jumping to S610.

S609, if the git downloading source code state and the maven packing state are unsuccessful, not executing the increment coverage rate analysis.

S610, if the git downloading source code state and the maven packing state are successful, further confirming the source codes of the two versions of the service corresponding to the incremental coverage rate analysis task, namely the difference analysis state of the java file.

S611, judging whether the difference analysis state of the java file is not started or fails, and if so, jumping to the step S612.

And S612, not executing the increment coverage rate analysis task.

S613, judging whether the analysis of the difference analysis state of the java file is successful, and if so, skipping to the step S614.

And S614, updating the incremental coverage rate analysis state to be non-incremental, and ending the whole process.

S615, judging whether the analysis of the difference analysis state of the java file is successful or not, wherein the two versions have difference, and if so, jumping to the step S616.

S616, if the difference analysis state of the java file is successful and the two versions are different, performing incremental coverage analysis, generating a jacoco analysis report of the packet with the difference, removing redundant content in the report, counting the total coverage again, storing the report path in a database (such as mysql), updating the incremental coverage state of the service to be successful, and ending the whole process.

In one embodiment, the principle of incremental analysis is as follows: firstly, writing codes to analyze which java files between two versions have difference, and recording the packet names and class names with difference into mongodb; then, when incremental coverage analysis is executed, generating a build.xml file to be used by jacoco analysis only according to the different packet names, and only removing the coverage report of the packets above dump after the analysis is executed; and traversing the html of each packet by processing the html, deleting the non-difference class files in the html, traversing each html after deleting redundant information, and modifying the coverage rate data in the html again according to the conditions of the existing classes.

The increment coverage rate analysis report is obtained according to the difference of the development code change, the range of the change code is obtained, and the generated class file only comprises a change part. Thus, when the coverage rate report is obtained through analysis, the generated report file only comprises the difference part, and then only the modified code coverage rate result is generated according to the range in a targeted mode.

Fig. 7 and 8 are graphs of the effect of full, incremental coverage analysis according to one embodiment of the present invention.

As shown in fig. 7, through the coverage analysis management page, a project name, a service name, a release version number, a git download source code state, a maven package state, a java file difference state, an incremental analysis state, a full analysis state, a task state, an update time, and an operation state can be obtained.

As shown in fig. 8, test coverage expressed in the form of progress bars (for example, a ratio of instructions that are not actually tested to instructions that need to be tested, a ratio of branches that are actually tested to branches that need to be tested, and the like), test coverage expressed in percentage, the number of codes that are not actually tested, the number of codes that are actually tested, test coverage of codes corresponding to a specific method, class, and the like, and the number of codes that are not actually tested, and the like can be obtained.

The contents included in the generated test report may be set as necessary.

FIG. 9 is a flow chart illustrating the main steps of a jacoco-based test analysis method according to an embodiment of the present invention.

In the method, the timing task module 6 executes the timing task, and if the difference task meeting the execution condition is scanned, a command for generating a difference analysis report is executed.

The task meeting the execution condition refers to a difference analysis task with online task state, un-started or failed task analysis state, source code downloaded through git clone and maven package executed. The method specifically comprises the following steps:

and S901, executing timing task scanning.

S902, judging whether the scanning task state is the online state and the analysis state is the non-started or failed difference analysis task, if not, jumping to the step S903, and if so, jumping to the step S904.

And S903, no operation is performed because no task to be executed exists currently.

And S904, judging whether the address and the port of the service corresponding to the difference analysis task can be accessed, if not, jumping to the step S905, otherwise, jumping to the step S906.

S905, if the address and the port of the service corresponding to the difference analysis task cannot be connected, setting the difference analysis task to be in an off-line state, and not performing analysis.

S906, further judging whether the time from the current task to the last successful execution of the difference analysis task is greater than the second time period, if not, jumping to the step S907, and if so, jumping to the step S908.

And S907, as the distance between the current task and the last time of successfully executing the difference analysis task is less than the second time period, no operation is performed.

S908, further determining whether the git download source code status and the maven packing status of the two release versions of the service corresponding to the difference analysis task are both successful (see the packing determination method in the foregoing example of the full and incremental coverage analysis), if not, jumping to step S909, otherwise, jumping to step S910. The two release versions refer to the current version and the old version. In one particular embodiment, the default two release versions are the current version and the last version.

S909, if the git downloading source code state and the maven packing state of the two release versions are not both successful, the difference analysis task is not executed.

S910, executing total difference analysis, generating a jacoco difference analysis report, storing the report details into a database, updating the difference analysis state of the service to be successful, changing the difference analysis execution results of the two release versions in the database, and ending the process.

In a specific embodiment, the difference analysis module uses gitdiff tool to compare and analyze the java files of the two versions to obtain the code difference state information between the codes of the two versions. Specifically, the code of the changed part of the current version code compared with the old version code is obtained through the git diff command, and the offset of the code is calculated.

In a specific embodiment, the code difference information between the two versions of code may be information such as line identification of the changed code (e.g. line number of the changed code line) and type of change, including packet, class, method, line information of the modified code, and the line information includes the specific modified line number and the modified total line number. For example, the 7 th, 8 th and 9 th code lines in the current version code, the 2 nd, 3 th and 4 th code lines in the old version code are deleted code lines, or the 7 th code line in the old version code is replaced by the 14 th code line in the current version code, etc. The type of change may include delete, add, replace, etc.

The effect of the difference analysis is shown in fig. 10 and 11.

By the technical scheme of the invention, a tool which cannot be applied to actual test activities originally is transformed and business logic is redeveloped, so that automatic analysis of a large number of services is realized, a simple and easy-to-use tool for full/incremental coverage analysis and difference analysis is provided for testers, and the problems that the coverage rate cannot be accurately counted and the test range cannot be accurately regressed are solved.

It should be noted that, although the foregoing embodiments describe each step in a specific sequence, those skilled in the art will understand that, in order to achieve the effect of the present invention, different steps do not necessarily need to be executed in such a sequence, and they may be executed simultaneously (in parallel) or in other sequences, and these changes are all within the protection scope of the present invention.

It will be understood by those skilled in the art that all or part of the flow of the method according to the above-described embodiment may be implemented by a computer program, which may be stored in a computer-readable storage medium and used to implement the steps of the above-described embodiments of the method when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc.

Further, the invention also provides a computer readable storage medium. In one computer-readable storage medium embodiment according to the present invention, the storage device may be configured to store a program that executes the above-described method embodiments, which program may be loaded and executed by a processor to implement the steps of the above-described method embodiments. For convenience of explanation, only the parts related to the embodiments of the present invention are shown, and details of the specific techniques are not disclosed. The storage device may be a storage device apparatus formed by including various electronic devices, and optionally, a non-transitory computer-readable storage medium is stored in the embodiment of the present invention. The computer-readable medium may include: any entity or device capable of carrying said computer program code, media, usb disk, removable hard disk, magnetic diskette, optical disk, computer memory, read-only memory, random access memory, electrical carrier wave signals, telecommunication signals, software distribution media, etc. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.

Further, the invention also provides a terminal device. In an embodiment of the terminal device according to the present invention, the terminal device comprises a processor and a storage device, the storage device may be configured to store a program for executing the above method embodiments, and the processor may be configured to execute the program in the storage device, the program including but not limited to the program for executing the method of the above method embodiments. For convenience of explanation, only the parts related to the embodiments of the present invention are shown, and details of the specific techniques are not disclosed. The terminal device may be a control or processing device formed of various electronic devices.

The embodiment of the present invention is mainly applied to a scenario of a terminal device (system platform), and further describes implementation of the present invention. The hardware configuration of the terminal device is shown in fig. 12. The terminal device may include: an input device 1100, a first processor 1101, an output device 1102, a first memory 1103, and at least one communication bus 1104. The communication bus 1104 is used to implement communication connections between the elements. The first memory 1103 may include a high-speed RAM memory, and may also include a non-volatile storage NVM, such as at least one disk memory, and the first memory 1103 may store various programs for performing various processing functions and implementing the method steps of the present embodiment.

Alternatively, the first processor 1101 may be, for example, a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a controller, a microcontroller, a microprocessor, or other electronic components, and the processor 1101 is coupled to the input device 1100 and the output device 1102 through a wired or wireless connection.

Optionally, the input device 1100 may include a variety of input devices, such as at least one of a user-oriented user interface, a device-oriented device interface, a software programmable interface, a camera, and a sensor. Optionally, the device interface facing the device may be a wired interface for data transmission between devices, or may be a hardware plug-in interface (e.g., a USB interface, a serial port, etc.) for data transmission between devices; optionally, the user-facing user interface may be, for example, a user-facing control key, a voice input device for receiving voice input, and a touch sensing device (e.g., a touch screen with a touch sensing function, a touch pad, etc.) for receiving user touch input; optionally, the programmable interface of the software may be, for example, an entry for a user to edit or modify a program, such as an input pin interface or an input interface of a chip; the output devices 1102 may include output devices such as a display, audio, and the like. In this embodiment, the processor of the terminal device includes a function for executing each module of the speech recognition apparatus in each device, and specific functions and technical effects may refer to the above embodiments, which are not described herein again.

Fig. 13 is a schematic hardware structure diagram of a terminal device according to another embodiment of the present application. FIG. 13 is a specific embodiment of the implementation of FIG. 12. As shown, the terminal device of the present embodiment may include a second processor 1201 and a second memory 1202.

The second processor 1201 executes the computer program code stored in the second memory 1202 to implement the method described in fig. 1 in the above embodiment. The second memory 1202 is configured to store various types of data to support operations at the terminal device. Examples of such data include instructions for any application or method operating on the terminal device, such as messages, pictures, videos, and so forth. The second memory 1202 may include a Random Access Memory (RAM) and may further include a non-volatile memory (non-volatile memory), such as at least one disk memory.

Optionally, the first processor 1201 is provided in the processing assembly 1200. The terminal device may further include: communication component 1203, power component 1204, multimedia component 1205, speech component 1206, input/output interfaces 1207, and/or sensor component 1208. The specific components included in the terminal device are set according to actual requirements, which is not limited in this embodiment.

The processing component 1200 generally controls the overall operation of the terminal device. The processing assembly 1200 may include one or more second processors 1201 to execute instructions to perform all or part of the steps of the method illustrated in fig. 1 described above. Further, the processing component 1200 can include one or more modules that facilitate interaction between the processing component 1200 and other components. For example, the processing component 1200 can include a multimedia module to facilitate interaction between the multimedia component 1205 and the processing component 1200. The power supply component 1204 provides power to the various components of the terminal device. The power components 1204 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the terminal device. The multimedia components 1205 include a display screen that provides an output interface between the terminal device and the user. In some embodiments, the display screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the display screen includes a touch panel, the display screen may be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. The voice component 1206 is configured to output and/or input voice signals. For example, the voice component 1206 includes a Microphone (MIC) configured to receive external voice signals when the terminal device is in an operational mode, such as a voice recognition mode. The received speech signal may further be stored in the second memory 1202 or transmitted via the communication component 1203. In some embodiments, the speech component 1206 further comprises a speaker for outputting speech signals.

The input/output interface 1207 provides an interface between the processing component 1200 and peripheral interface modules, which may be click wheels, buttons, etc. These buttons may include, but are not limited to: a volume button, a start button, and a lock button.

The sensor component 1208 includes one or more sensors for providing various aspects of status assessment for the terminal device. For example, the sensor component 1208 may detect an open/closed state of the terminal device, relative positioning of the components, presence or absence of user contact with the terminal device. The sensor assembly 1208 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact, including detecting the distance between the user and the terminal device. In some embodiments, the sensor assembly 1208 may also include a camera or the like.

The communication component 1203 is configured to facilitate communications between the terminal device and other devices in a wired or wireless manner. The terminal device may access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In one embodiment, the terminal device may include a SIM card slot therein for inserting a SIM card therein, so that the terminal device may log onto a GPRS network to establish communication with the server via the internet.

As can be seen from the above, the communication component 1203, the voice component 1206, the input/output interface 1207 and the sensor component 1208 referred to in the embodiment of fig. 13 can be implemented as the input device in the embodiment of fig. 3.

Furthermore, the invention also provides a terminal device or a service platform, which comprises the jacoco-based test analysis system.

Further, it should be understood that, since the modules are only configured to illustrate the functional units of the system of the present invention, the corresponding physical devices of the modules may be the processor itself, or a part of software, a part of hardware, or a part of a combination of software and hardware in the processor. Thus, the number of individual modules in the figures is merely illustrative.

Those skilled in the art will appreciate that the various modules in the system may be adaptively split or combined. Such splitting or combining of specific modules does not cause the technical solutions to deviate from the principle of the present invention, and therefore, the technical solutions after splitting or combining will fall within the protection scope of the present invention.

So far, the technical solution of the present invention has been described with reference to one embodiment shown in the drawings, but it is easily understood by those skilled in the art that the scope of the present invention is obviously not limited to these specific embodiments. Equivalent changes or substitutions of related technical features can be made by those skilled in the art without departing from the principle of the invention, and the technical scheme after the changes or substitutions can fall into the protection scope of the invention.

Claims

1. A jacoco-based test analysis method is characterized by comprising the following steps:

adding a jacobage in a start script of a test service so as to transmit a customized project parameter through the jacobage;

analyzing the service information corresponding to the input project parameters, and generating a coverage rate analysis task and/or a difference analysis task corresponding to the service information;

performing the coverage analysis task and/or the variance analysis task;

the project parameters at least comprise a project name, a service name, a release version number, a code branch, a platform ip and a platform port of the test service;

adding a jacobage in a start script of a test service, so that the step of transmitting customized project parameters through the jacobage specifically comprises the following steps: uploading the jacobage.jar file to a specified position of a server where the test service is located, so that the jacobage is used for starting a test service script and transmitting the project parameters;

analyzing the service information corresponding to the introduced project parameters, and generating a coverage rate analysis task or a difference analysis task corresponding to the project parameters, wherein the method specifically comprises the following steps: judging whether service information corresponding to the project parameters exists or not; if yes, generating a coverage rate analysis task according to the project parameters; and/or, if an old version of the test service exists and also exists, generating a difference analysis task according to the project parameters;

executing the coverage analysis task or the difference analysis task, specifically including: and scanning the tasks according to a preset time period, and executing the coverage rate analysis task or the difference analysis task when the coverage rate analysis task or the difference analysis task meeting the conditions is scanned.

2. The method of claim 1,

the customized project parameters are obtained by modifying the source code of the jaccoagent;

judging whether the service information corresponding to the project parameter exists, specifically including:

comparing the service name, the release version number and the code branch in the project parameters with service records stored in a database;

judging whether the service records have records with the same service name, release version number and code branch;

the service record comprises an item name, a service name, a release version number and a code branch of the test service.

3. The method of claim 2,

wherein the coverage analysis task comprises a full coverage analysis task and/or an incremental coverage analysis task;

the executing the coverage analysis task specifically includes:

performing a full coverage analysis and generating a full coverage analysis report;

and/or the presence of a gas in the gas,

performing incremental coverage analysis and generating an incremental coverage analysis report;

the executing the difference analysis task specifically includes:

version discrepancy analysis is performed and a discrepancy analysis report is generated.

4. The method of claim 3,

generating a coverage analysis task according to the project parameters, which specifically comprises:

judging whether the release version number in the item parameter exists in a release version table or not;

if the version number does not exist, adding a piece of release version information corresponding to the release version number into the release version table;

judging whether an existing coverage rate analysis task corresponding to the service name in the project parameter exists in a coverage rate analysis table or not;

if so, updating the platform ip and platform port fields in the existing coverage rate analysis task by using the platform ip and platform port in the project parameters, and setting the task state to be valid; and if not, adding a coverage rate analysis task corresponding to the service name in the project parameter into the coverage rate analysis table.

5. The method of claim 3,

generating a difference analysis task according to the project parameters, which specifically comprises:

if so, judging whether the release version number has an old version, wherein the old version is a version before the current release version;

if yes, judging whether an existing difference analysis task corresponding to the service name in the project parameter exists in the difference analysis table;

and if not, adding a difference analysis task corresponding to the service name in the project parameter into the difference analysis table.

6. The method of claim 4, wherein performing a full coverage analysis and generating a full coverage analysis report comprises:

judging whether a full coverage analysis task with an online task state exists according to the timing task scanning;

if so, judging whether a platform ip and a platform port in the project parameters corresponding to the full coverage analysis task can be accessed;

if so, judging whether the time from the previous successful execution of the full coverage rate analysis task to the current full coverage rate analysis task is longer than a second time period;

if so, judging whether the git downloading source code state and the maven packing state of the source code of the test service corresponding to the current full coverage rate analysis task are successful or not;

if the total coverage rate analysis task is successful, directly executing the current total coverage rate analysis task, generating an analysis report, and updating the task state of the total coverage rate analysis task;

and if the task is unsuccessful, executing git downloading source code and maven packaging, updating the downloading source code state and the packaging state respectively, then executing the current full coverage rate analysis task, generating a full coverage rate analysis report, and updating the task state of the full coverage rate analysis task.

7. The method of claim 4, wherein performing incremental coverage analysis and generating incremental coverage analysis reports comprises:

judging whether an incremental coverage analysis task with an online task state exists according to the timing task scanning;

if so, judging whether a platform ip and a platform port in the project parameters corresponding to the incremental coverage analysis task can be accessed;

if so, judging whether the distance between the current incremental coverage analysis task and the last time of successfully executing the incremental coverage analysis task is greater than a second time period;

if so, judging whether the git downloading source code state and the maven packing state of the source code of the test service corresponding to the incremental coverage analysis task are successful or not;

if the incremental coverage rate analysis task is successful, judging the differential analysis state of the source code of the test service corresponding to the incremental coverage rate analysis task;

when the difference analysis state is not started or failed, not executing an increment coverage rate analysis task;

when the difference analysis state is successful and no difference exists between the two versions or no old version exists, updating the task state of the incremental coverage rate analysis task to be non-incremental;

when the difference analysis state is that the analysis is successful and there is a difference between the two analyzed versions, executing the current incremental coverage analysis task, generating an incremental coverage analysis report, and updating the task state of the incremental coverage analysis task.

8. The method of claim 5, wherein performing version difference analysis and generating a difference analysis report comprises:

judging whether a difference analysis task with an online task state and an uninitiated or failed analysis state exists according to the timing task scanning;

if so, judging whether a platform ip and a platform port in the project parameters corresponding to the difference analysis task can be accessed;

if so, judging whether the time from the last successful execution of the difference analysis task to the current difference analysis task is longer than a second time period;

if so, judging whether the git downloading source code state and the maven packing state of the source release version and the target release version of the test service corresponding to the current difference analysis task are both successful;

if the difference analysis is successful, executing the full difference analysis, generating a difference analysis report, updating the difference analysis state to be successful, and changing the difference analysis execution result of the source release version and the target release version.

9. The method of claim 8,

when the difference analysis task is executed, comparing each package and each file of the source release version and the target release version one by one to generate difference data;

the difference data is a change code line identification and a change type.

10. The method of claim 1,

when the coverage rate analysis task is executed, one or more of line coverage rate, class coverage rate, branch coverage rate, method coverage rate, instruction level coverage rate, circle complexity and statement block coverage rate are analyzed.

11. A jacoco-based test analysis system, comprising:

the jaccoagent module is used for modifying the source code of the jaccoagent to obtain a customized project parameter and adding the jaccoagent in a start script of the test service to transfer the project parameter;

the jaccoagent data receiving module is used for providing an interface called by the jaccoagent, and analyzing the service information corresponding to the project parameters after receiving the project parameters through the interface so as to generate a coverage rate analysis task or a difference analysis task corresponding to the service information;

the timing task module is used for scanning the tasks at fixed time, and calling the corresponding task module to execute the coverage rate analysis task or the difference analysis task when the coverage rate analysis task or the difference analysis task meeting the conditions is scanned;

further comprising: a front end display module;

the jaccoagent module is specifically configured to: uploading the jacobage.jar file to a specified position of a server where the test service is located, so that the jacobage is used for starting a test service script and transmitting the project parameters;

the jaccoagent data receiving module is specifically configured to: judging whether the service information corresponding to the project parameter exists in the data displayed on the service management page of the front-end display module; if yes, generating a coverage rate analysis task according to the project parameters; and/or, if an old version of the test service exists and also exists, generating a difference analysis task according to the project parameters;

the timing task module is specifically configured to: and scanning the tasks according to preset time, and calling a coverage rate analysis module to execute the coverage rate analysis tasks or calling a difference analysis module to execute the difference analysis tasks when the coverage rate analysis tasks or the difference analysis tasks meeting the conditions are scanned.

12. The system of claim 11,

when the jaccoagent data receiving module executes the operation of generating a coverage analysis task according to the project parameters, the jaccoagent data receiving module is specifically configured to:

if so, updating the platform ip and platform port fields in the existing coverage rate analysis task by using the platform ip and platform port in the project parameters, and setting the task state to be valid; if not, adding a coverage rate analysis task corresponding to the service name in the project parameter to the coverage rate analysis table;

wherein the coverage analysis task comprises a full coverage analysis task and/or an incremental coverage analysis task.

13. The system of claim 11,

when the jaccoagent data receiving module executes the operation of generating a difference analysis task according to the project parameters, the jaccoagent data receiving module is specifically configured to:

14. The system of claim 12,

the coverage analysis module comprises a full coverage analysis module for performing a full coverage analysis;

the timing task module executes the following specific operations:

if the total coverage analysis task is successful, directly executing the current total coverage analysis task by the total coverage analysis module, generating an analysis report, and updating the task state of the total coverage analysis task;

if the test is unsuccessful, calling the full coverage analysis module to obtain a source code of the test service, executing git downloading source code and maven packaging, updating a downloading source code state and a packaging state respectively, executing the current full coverage analysis task, generating a full coverage analysis report, and updating a task state of the full coverage analysis task.

15. The system of claim 12,

the coverage analysis module comprises an incremental coverage analysis module for performing an incremental coverage analysis;

the timing task module executes the following specific operations:

when the difference analysis state is a successful non-difference or non-old version, updating the task state of the incremental coverage rate analysis task to be non-incremental;

and when the difference analysis state is analysis success and the two analyzed versions are different, calling the incremental coverage analysis module to execute the current incremental coverage analysis task, generating an incremental coverage analysis report, and updating the task state of the incremental coverage analysis task.

16. The system of claim 13,

the timing task module executes the following specific operations:

if the difference analysis is successful, the difference analysis module is called to execute the difference analysis, a difference analysis report is generated, the difference analysis state is updated to be successful, and the difference analysis execution result of the source release version and the target release version is changed.

17. The system of claim 16,

the difference data is a change code line identification and a change type.

18. The system of claim 11,

19. A terminal device comprising a processor and a storage means adapted to store a plurality of program codes, wherein said program codes are adapted to be loaded and run by said processor to perform the jacoco-based test analysis method of any of claims 1 to 10.

20. A computer readable storage medium having stored therein a plurality of program codes, wherein the program codes are adapted to be loaded and executed by a processor to perform the jacoco-based test analysis method of any of claims 1 to 10.

21. A terminal device comprising the jacoco-based test analysis system of any one of claims 11 to 18.