Detailed Description
The following description of the embodiments of the present application will be made more apparent and fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the application are shown. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to fall within the scope of the application.
The embodiment of the application provides an information acquisition method, an information acquisition device, electronic equipment and a computer readable storage medium. Specifically, the embodiment of the application provides an information acquisition device suitable for electronic equipment, wherein the electronic equipment comprises terminal equipment or a server, and the terminal equipment comprises equipment such as a notebook computer, a desktop computer, a television and the like. The server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server or the like for providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs, content Delivery Network), basic cloud computing services such as big data and artificial intelligent platforms, and the servers may be directly or indirectly connected through wired or wireless communication modes.
Specifically, referring to fig. 1, fig. 1 is a schematic view of a scenario in which a terminal device executes an information acquisition method provided by an embodiment of the present application, where a server executing the information acquisition method may be understood by referring to steps of the terminal device executing the information acquisition method, where a specific execution process of the terminal device executing the information acquisition method is as follows:
the terminal device 10 obtains project information of a target project through a target plug-in, generates an operation interface by using the target plug-in according to the project information, responds to an information obtaining request generated through the operation interface, determines information obtaining condition information corresponding to the information obtaining request, and screens target coverage rate information from comprehensive test coverage rate information of the target project according to the information obtaining condition information.
It can be understood that the embodiment of the application screens the comprehensive test coverage information to obtain the target coverage information through the information acquisition condition information, thereby realizing the acquisition of the local test coverage information in the software project and being beneficial to the targeted construction of the test cases. The operation interface is generated through the plug-in, so that the convenience of coverage rate information acquisition is improved.
The following will describe in detail. It should be noted that the following description order of embodiments is not a limitation of the priority order of embodiments.
Referring to fig. 2, fig. 2 is a flowchart of an information obtaining method according to an embodiment of the application. Although a logical order is depicted in the flowchart, in some cases the steps shown or described may be performed in an order different than depicted in the figures. Specifically, the specific flow of the information acquisition method is as follows:
101. Acquiring item information of a target item through a target plug-in, and generating an operation interface by using the target plug-in according to the item information.
In the embodiment of the application, the target item is a software item needing target coverage rate information collection. The target coverage rate information is a part of comprehensive test coverage rate information of the software project, and the comprehensive test coverage rate information is global coverage rate information of the software project, which is obtained by testing a tested case of the target project.
The comprehensive test coverage information reflects the comprehensive coverage condition of codes in the target project in the test process, and comprises percentage information of the code coverage and specific code information of the test coverage. For example, the test case covers percentage information of test code for a software item when testing the software item (such as code that the test covers N% of the software item), and which code is specifically covered.
Similarly, the target coverage rate information also includes coverage percentage information of codes and code information of specific coverage, but the target coverage rate information is coverage rate information of newly added codes after the software project is tested by a test case for local situations in the software project. For example, the test covers the percentage of the newly added code and the portion of the code that covers the newly added code.
Wherein in a software project, a plug-in is typically an extensible component that is used to enhance or extend the functionality, performance, or capability of the project. They may be integrated with project build tools, frameworks, development environments, or other support software to provide additional functionality or specific behavior. In the embodiment of the application, the target plug-in is a tool which is conveniently used on the Android Studio, and the plug-in tool is provided with a corresponding initialization interface after being started.
The item information is identification information of the item, and includes an item name, a package name of the item, a main module of the parsing process, a link (giturl link) of the item, and the like. And refreshing the initialization interface through the item information to obtain an operation interface containing the item information.
For example, referring to fig. 3, fig. 3 is a schematic diagram of an operation interface provided in an embodiment of the present application, where item information of a target item is included, so that an operation on the target item is implemented through the item information in the operation interface.
Meanwhile, in order to achieve the acquisition of the code coverage rate information through the operation interface, an operation control is further arranged in the operation interface, and the acquisition of the code coverage rate information is triggered through the operation control. The operation control includes a button or a drop-down box, for example, a drop-down box corresponding to the statistics type information in fig. 3 includes drop-down contents such as "incremental coverage report", "impact domain incremental report", and "full coverage report", and similarly, buttons such as "refresh", "empty cache file" are also shown on the operation interface.
102. And responding to the information acquisition request generated through the operation interface, and determining information acquisition condition information corresponding to the information acquisition request.
The information acquisition request is a request for acquiring information, and the information acquisition request can be triggered and generated through an operation control of an operation interface, for example, a user triggers and generates the information acquisition request by clicking the operation control provided by the operation interface.
In order to improve accuracy of information acquisition or achieve acquisition of specific information, the information acquisition request may also carry condition information of acquiring information, i.e. information acquisition condition information.
For example, referring to fig. 3, for generating the incremental coverage report, a drop-down content of "incremental coverage report" may be selected in a drop-down frame corresponding to the statistical type information of the operation interface, and then the "information generation" control may be clicked to generate the information acquisition request using "incremental coverage report" as the information acquisition condition information. In the embodiment of the application, the increment is the class or the method corresponding to the newly added code.
103. And screening target coverage rate information from the comprehensive test coverage rate information of the target project according to the information acquisition condition information.
The target coverage information is obtained by screening from the comprehensive test coverage information based on the information acquisition condition information, for example, the target coverage information is obtained by screening from the comprehensive test coverage information according to names, identifications and the like corresponding to the information acquisition condition information.
In summary, the embodiment of the application screens the comprehensive test coverage information to obtain the target coverage information through the information acquisition condition information, thereby realizing the acquisition of the local test coverage information in the software project and being beneficial to the targeted construction of the test cases. The operation interface is generated through the plug-in, so that the convenience of coverage rate information acquisition is improved.
Optionally, since the development of the software project is usually based on the development of a class and a method performed by a single function, and thus the test usually occurs after the development of the class is completed or after the test of the newly added method is completed, the embodiment of the present application may acquire code coverage information of the class or the method after the test, so as to rapidly analyze the development quality condition of the single function, that is, optionally, in some embodiments of the present application, the step of "screening target coverage information from comprehensive test coverage information of the target project according to the information acquisition condition information" includes:
analyzing the information acquisition condition information to obtain statistical type information and statistical object information;
determining target component information according to the statistic type information and the statistic object information;
And screening target coverage rate information from the comprehensive test coverage rate information of the target project according to the target component information.
The target component information is a component which is concerned and needs to acquire coverage rate information, and the component can be a class or a method in a software project, for example, a new class is constructed, or a new method is obtained in the class through a new code, and the new code in the method indicates that the method is newly added. In particular, class (Class) is the basic unit of object-oriented programming that describes the properties and behavior of objects. A class can be seen as a definition of a data structure that contains a set of data members (attributes) and member functions (methods). A class may be used to create multiple objects with the same properties and behavior. The Method (Method) is a function in a class that describes the behavior or operation of the class. It defines operations that can be performed on objects of a class. Methods are typically used to access and modify attributes of classes, or to perform some specific function on objects.
It can be understood that, the target component information is used as a specific screening condition to acquire specific target coverage rate information, which is helpful for specifically analyzing the test coverage condition of the target component corresponding to the target component information. For example, after the target coverage rate information for the target component information is obtained, the coverage percentage of the target component related to the test and the related specific code line can be obtained through the target coverage rate information, and correspondingly, the test case can be constructed based on the code line which is not covered by the test, so that the targeted construction of the test case for the code line which is not tested is realized, the construction difficulty of the test case is simplified, and the construction efficiency of the test case is improved.
Wherein the statistical type information and the statistical object information are conditions for determining the target component information for which the coverage information needs to be acquired. In this embodiment of the present application, the statistics type information and the statistics object information may be obtained through input of an interface, for example, two drop-down boxes are configured in the operation interface of fig. 3, and the user inputs the statistics type information and the statistics object information through the drop-down boxes and clicks an "information generation" control to generate an information acquisition request, where the information acquisition request uses the statistics type information and the statistics object information as contents.
The statistics type information refers to which types of codes are counted, for example, counting incremental codes, codes affecting a domain, global codes, or the like, and the statistics object information refers to which subject is counted, for example, counting local parts, branch parts in a code warehouse, codes of a merging part of the code warehouse, or the like.
Where local refers to a file system on a developer's computer or workstation that contains code, resources, and other related files for the project. The local is where the developer performs development work, writes code, and tests. The local developer can modify, add and delete files and perform various development operations, for example, the developer's own computer (with the source code of the software project).
Wherein in software development, the code repository is a central repository for holding all code, version history, branches and other relevant information of the item. Code warehouses are typically managed by a version control system (VCS, version Control System), such as Git, subversion (SVN), or the like. The code repository may be located on a local computer or a remote server. The code in the code repository may be available after a local commit, for example, a developer commits the code locally into the code repository through a version commit service. The primary role of the code repository is, among other things, to track and manage the version of the code, providing a developer with a central source of access and sharing of the code. It records the history of each code change, enabling the developer to rollback to a previous version, branch to develop new functionality, collaborate with development, and share and synchronize code with other developers.
For example, in the embodiment of the present application, when the statistics type information is a code of a statistics increment, and the statistics object information is a statistics local portion, the target component information is a code of an increment in the local portion.
Accordingly, the step of determining the target component information according to the statistics type information and the statistics object information includes:
If the statistics type information is increment coverage statistics, determining a change component data set from the statistics object information, and taking the component information in the change component data set as target component information;
If the statistics type information is the coverage rate statistics of the influence domain, determining a change component data set from the statistics object information, acquiring reference component information of the component information in the change component data set, and taking the component information and the reference component information as target component information;
and if the statistics type information is full coverage statistics, taking all the component information contained in the statistics object information as target component information.
The incremental coverage statistics refers to the coverage condition of the newly added code during testing, the influence domain coverage statistics refers to the coverage condition of the influence range during testing caused by the statistics of the incremental code, and the total coverage statistics refers to the coverage condition of the whole software project during testing.
Where an increment refers to a newly added class or method in a software project, where the newly added class includes a newly created class, e.g., create a new class a. The new method includes adding a new method to the class, and in the original method, the method is obtained by changing the code through operations such as adding, deleting, modifying, etc., for example, please refer to fig. 4, fig. 4 is a schematic diagram of the new method provided in the embodiment of the present application, in which the content of the method click2 before the new (left side of fig. 4) and the content after the new (right side of fig. 4) are shown, and then the method click2 is the new method. Correspondingly, the method click2 is the target component information aimed at by the statistical coverage rate of the embodiment of the application, and correspondingly, the class (testexact. Java) corresponding to the method click2 can also be the target component information of the embodiment of the application, i.e. the target component information can simultaneously comprise the method click2 and the class (testexact. Java) of the method click 2.
The scope of influence caused by the increment code refers to other methods related to the increment method (the method of the increment code), and the other methods are usually methods directly or indirectly related to the increment method, for example, when the method click2 is the increment method, if the method click3 and the method click4 refer to the method click2, the method click3 and the method click4 are other methods related to the increment method, if the method click3 refers to the method click2 and the method click4 refers to the method 3, the method click3 and the method click4 are all other methods related to the increment method, that is, in the embodiment of the application, the method affected by the new increment of the method click2 is the scope of influence caused by the increment code.
Correspondingly, an increment method requiring coverage statistics or an influence domain related to the increment method can be determined based on different statistics type information, and code coverage information of the target component information corresponding to the statistics type information in the statistics object information after testing is further obtained. For example, test coverage information for a developer local delta method is counted.
Optionally, the target component information for which code coverage information during test needs to be acquired may be acquired by calling a related interface, for example, for an incremental method or class, an interface capable of acquiring the incremental method or class may be called for acquisition, and since call interfaces corresponding to different statistical object information are different, target call interface information may be determined based on the statistical object information, and a changed method or class may be acquired based on the target call interface information, that is, optionally, in some embodiments of the present application, the step of "determining a changed component dataset from the statistical object information" includes:
determining target calling interface information according to the statistical object information;
and calling a target call interface corresponding to the target call interface information to obtain a change component data set.
For example, the statistical object information includes a statistical local part, a branch part in the code warehouse, a merging part of the code warehouse, and the like, wherein, for the case that the statistical object information is the local part, a CHANGELIST dataset may be obtained through a changelistmanager.getchangelist interface of intellij, a class or a method corresponding to the CHANGELIST dataset is a Change component dataset, for the case that the statistical object information is the branch part in the code warehouse, a local GitCommit object may be obtained through a fit 4idea frame, and for the case that the statistical object information is the merging part of the code warehouse, a Change dataset may be obtained through a gitcommot.getchanges interface, a class or a method corresponding to the Change dataset may be obtained through a gitlab interface, and for the case that the statistical object information is the merging part of the code warehouse, a difference (Diff) data may be obtained through a gitlab interface.
Optionally, the step of determining the delta method by altering the data (CHANGELIST dataset, change dataset, or difference (Diff) data) may comprise:
Step 1, acquiring change data;
Step2, judging the difference type of the source file corresponding to the change data, if the difference type is newly added, executing step 3, and if the difference type is modified, executing step 4;
Analyzing the source file and taking all methods of the source file as increment methods;
Analyzing a source file and an old version file corresponding to the source file;
step 5, judging whether the signature of the method of the source file is contained in the signature of the method of the old version file, if not, taking the method as an increment method, and if so, executing step 6;
And 6, judging whether MD5 values of the two methods with the consistent signatures are consistent, and if the MD5 values are inconsistent, taking the method in the source file as an incremental method.
Wherein the source file is primarily a Class (Class) file.
Alternatively, other methods of referencing the incremental method may be acquired by the referencing information acquiring component, for example, invoking a universal interface of intellij.psi, the references search (psiMethod) findAll () method acquires the method of referencing the incremental method, and accordingly, since the method of referencing the incremental method only directly or indirectly is affected by the incremental method, the embodiments of the present application acquire each parent referencing method of the incremental method by circularly invoking the universal interface. That is, optionally, in some embodiments of the present application, the step of "obtaining the reference component information of the component information in the change component dataset" includes:
Recursively calling a reference information acquisition component to acquire each level of father component information of the component information;
and taking the parent component information of each level as reference component information.
In particular, the specific step of obtaining the reference component information may include:
Step 1, analyzing an object entering a parameter through a PSI analysis framework, converting the object into PSI elements, distinguishing element types, and executing step 2 if the element types are PsiMethod;
Step 2, calling universal interface of intellij.psi, reference search (psiMethod) findAll () can obtain all reference objects references of the method in the item, and when recursively resolving the reference objects, if parant element of the reference object is also a method, continuing deep recursion until the calling place has no parent level method. The language compatible with java and kotlin is recursively analyzed, and finally the analyzed reference chain information is assembled into MethodNodeList data objects to obtain the reference component information.
Wherein PSI (Program Structure Interface) is part of the IntelliJ platform for parsing and structuring the code.
In the embodiment of the application, a gradle task is defined, an ec file closing task is firstly executed, basic parameters such as an ec file, a source code file set, a compiling file set, a report path and the like after being combined are configured, then increment classes and method data set change. Json analyzed by a plug-in are added, and finally a java-jar command is matched to call jacoco a jacoccli. Jar packet of two source codes, so that coverage statistics of an increment method is carried out, and coverage information of the increment method is obtained. The ec file is a file format generated when jacoco frames collect coverage rate data, and is the same as exec file.
Optionally, in the embodiment of the present application, for the coverage rate collection component required for obtaining coverage rate information, the coverage rate collection component may be injected into the target item through the target plug-in, so that when the target item is tested through the test case, the coverage rate information of the test can be collected through the coverage rate collection component, that is, optionally, in the embodiment of the present application, before step "the target coverage rate information is screened from the comprehensive test coverage rate information of the target item according to the information obtaining condition information", the method further includes:
In response to an information injection request generated through the operation interface, injecting a coverage rate collection component into the target item;
And reading comprehensive test coverage rate information of the target item, wherein the comprehensive test coverage rate information is collected by the coverage rate collection component when the target item is tested by the test case.
For example, referring to fig. 5, fig. 5 is a flowchart of coverage rate collection component injection according to an embodiment of the present application, and specifically, the flowchart includes:
111. Starting a target plug-in and generating an operation interface;
112. Triggering a one-key injection installation button through the operation interface, and determining a coverage rate collection assembly and a plug-in execution script;
113. Under the root directory of the target item, a build configuration file (building. Gradle) for the whole item is found, and plug-in execution scripts for all sub-modules are configured in the file;
accordingly, each sub-module may perform the functional tasks of the plug-in execution script.
114. Analyzing a building configuration file (building. Gradient) of each module of the target project, identifying a project entry (application) class, and injecting a coverage rate collection component into the class;
115. and executing gradle a task sync, and synchronizing project construction configuration.
Wherein, if a platform signature is needed, a signature plug-in task is called to construct the signature, and a construction task (such as INSTALLAPESIGNRELEASE) is executed to generate an apk corresponding to the item, and if the platform signature is not needed, a native task (assembleRelease) of gradle is called to construct the apk corresponding to the item.
The coverage rate collection assembly for collecting coverage rate information is injected through the plug-in, the plug-in execution script is injected, and assembly injection efficiency is improved.
For a component injected in a target item through a target plug-in, after coverage information is acquired, a rollback task may be executed to delete the component from the target item, that is, optionally, in the embodiment of the present application, after step "the target coverage information is screened from comprehensive test coverage information of the target item according to the information acquisition condition information", the method further includes:
the coverage collection component is deleted from the target item.
It will be appreciated that plug-in execution scripts injected in the target item for functional execution of the target plug-in may also be rolled back together to be deleted from the target item.
The coverage rate collection component comprises a jacobUtil. Jar for executing tasks of coverage rate information collection, and the plug-in execution script comprises jacoco _exact. Gradle script which is constructed based on gradle and is used for being injected into a target item so as to ensure execution of tasks in the target plug-in. gradle is an open source tool for automated project construction that provides powerful dependency management, flexible construction configuration, and efficient project construction. jacoco is an open source Java code coverage tool that can be used to measure the extent of coverage of code.
For example, referring to fig. 6, fig. 6 is a schematic diagram of an embodiment of a functional module of a target plug-in according to an embodiment of the present application, where the functions of the target plug-in include:
The project information obtaining module 201 is configured to obtain project information currently loaded by the Android studio when opening a main page of the target plug-in tool, where the project information includes a project name, a package name of the project, a main module of an parsing process, and giturl links of the project, and refresh a project information interface, and parse the project package name by retrieving the main module, provide default buildtype, flag and other construction parameters, and support configuration modification. Wherein buildtype is release to represent release version, buildtype is debug to represent test version, and flag is customized channel package identifier.
The instrumentation and dependency injection module 202 is used for adding a dependency integration jacoco _exact function script for each sub-module by modifying project root build. Gradle, the script is provided with instrumentation logic, an application entry of the main module is searched, a starting code of the jar package is collected by inserting coverage rate, a plurality of gradle function tasks are also designed in the script, and the tasks can be called and executed through gradle commands.
The building and installing module 203 is configured to execute gradle a building command, such as app: INSTALLAPESIGNRELEASE, app is a main module name, install is a direct install-completed meaning, apeSign is a self-developed signature plug-in tool, release is a default buildtype, and the whole command is to build a release package and then complete a signature, and install directly on a connected device.
The adb communication module 204 is used for initializing an adb device object, acquiring device ip, device name, connection state and the like through the object, setting device monitoring, timely refreshing interface device information, supporting adb command execution, supporting device file transmission to a local computer, and guiding out an ec test file for use in coverage rate statistics.
The coverage report generating module 205 is used for realizing the function in jacoco _exact.gradle, and comprises an ec file merging and coverage statistics, wherein the ec file merging is a jacocoMerge task of jacoco which is utilized to integrate the ec files exported from the equipment, the coverage statistics is a jacocoReport task of jacoco which is utilized to configure the merged ec file, a source code file set, a compiling file set, filtering conditions, a report path and other parameters, a customized task command is executed, and finally an html coverage report is output.
The increment statistics module 206 is used for the plug-in unit to be responsible for increment code analysis, acquiring code_ diffs data of MR through gitlab interface, or acquiring CHANGELIST of local code and submitted information GitCommit list of local branch through git4idea frame, finally analyzing uast elements of change or diff object class through data analysis, acquiring all methods of changing class, comparing MD5 values of front and back versions of each method, filtering out modified methods, and finally outputting all results to a change.
And the increment statistics function is similar to coverage rate report generation, a gradle task is defined, the ec file combination task is firstly executed, the basic parameters such as the combined ec file, source code file set, compiling file set, report path and the like are configured, then increment class and method data set change. Json analyzed by the plug-in are added, finally a java-jar command is matched to call jacoco a jacoccli. Jar package of two source codes, coverage rate statistics of an increment method is carried out, and finally an html-based increment coverage rate report is output.
The report uploading and MR associating module 207 is configured to package and upload two coverage rate files to an ape service, carry parameters such as url, MR id, etc. of the project and associate the project code merging request, store the parameters in a server, and extract the stored report content from the server when the MR request corresponding to the CR is requested, so as to verify coverage rate index access control.
The source code injection rollback module 208 is used for injection rollback, because the project source code content is modified by depending on injection and code instrumentation, in order not to affect the code and construction configuration of the original project, the function of injection rollback is designed, and the modified content is deleted by reversely utilizing the principles of instrumentation and depending on injection, so that the effect of recovering the source code is achieved.
The change influence domain analysis module 209 is used for firstly acquiring change methods from the incremental codes, performing static code analysis on the changed methods to acquire static reference chains of the changed methods, then re-integrating the collected affected method information into a change. Json, and then executing the process of incremental statistics so as to verify the code test coverage rate affected by the code change.
It should be noted that, in the embodiment of the present application, an embodiment of the functional module diagram of the target plug-in provided by the present application is shown in the drawing, and in the actual application process, the target plug-in includes one or more of the functional modules. Optionally, the target plug-in may include one or more of the above functional modules, and may further include other functional modules based on actual application requirements, which is not limited by the present application.
In summary, the embodiment of the application uses the target plug-in (idea plug-in) sidebar tool of the Android Studio, is more in line with the habit of a developer, can flexibly select local differences, branch submission differences, code merging differences, more accurate verification increment codes, has simple flow, is ready-to-use, has the functions of button one-key execution, automatically outputs results and reports, and simultaneously supports changing influence domain test coverage rate and reduces missing test rate.
In order to facilitate understanding of the embodiments of the present application, a system frame diagram with a workbench of a target plug-in as a core is promoted, referring to fig. 7, the system shown in fig. 7 includes:
The code repository management module 211 is configured to manage project codes through a code repository, for example, a developer uploads the locally developed code to the code repository, and performs operations such as submission, pushing, updating, etc. of the project with the target project module 212;
the target item module 212 is a software item tested by the test case in the embodiment of the application, and not only performs operations such as submitting, pushing and updating item codes with the code warehouse management module 211, but also responds to accurate injection and rollback tasks of the plug-in workbench module 214;
The ape service module 213 guarantees pipeline execution, processes information such as codes and products, and provides a plug-in workbench background interface;
Plug-in workbench module 214, corresponding to the target plug-in, providing an operation interface, coverage report display, etc.;
Android device 215, target project deployment device, which is used for executing test cases to test target projects and storing coverage rate files after test. Apk installation, ec file transfer, ADB communication, etc. of the target item are performed with the plug-in table module 214.
In summary, the target plugin of the plugin workbench module provides an operation interface, triggers the acquisition of coverage rate information, triggers the operations such as injection and rollback, and the like, and achieves the acquisition of the coverage rate information after the target project is tested.
Wherein the access control based on the coverage information may also relate to merging, e.g. if the incremental coverage is less than 80%, merging is not allowed, etc.
In order to facilitate better implementation of the information acquisition method, the application also provides an information acquisition device based on the information acquisition method. The meaning of the nouns is the same as that of the information acquisition method, and specific implementation details can be referred to in the description of the method embodiment.
Referring to fig. 8, fig. 8 is a schematic structural diagram of an information obtaining apparatus according to an embodiment of the present application, where the information obtaining apparatus specifically includes:
the generating module 301 is configured to obtain item information of a target item through a target plug-in, and generate an operation interface according to the item information by using the target plug-in;
a determining module 302, configured to determine information acquisition condition information corresponding to an information acquisition request generated through the operation interface in response to the information acquisition request;
and the screening module 303 is configured to screen target coverage rate information from the comprehensive test coverage rate information of the target item according to the information acquisition condition information.
Optionally, in some embodiments of the present application, the screening module 303 includes:
The analysis unit is used for analyzing the information acquisition condition information to obtain statistical type information and statistical object information;
a first determining unit configured to determine target component information according to the statistical type information and the statistical object information;
and the screening unit is used for screening the target coverage rate information from the comprehensive test coverage rate information of the target project according to the target component information.
Wherein, in some embodiments of the application, the first determining unit comprises:
The first determining subunit is configured to determine a change component dataset from the statistics object information if the statistics type information is incremental coverage statistics, and take component information in the change component dataset as target component information;
The second determining subunit is configured to determine a change component dataset from the statistics object information if the statistics type information is an impact domain coverage statistics, obtain reference component information of the component information in the change component dataset, and use both the component information and the reference component information as target component information;
and the third determining subunit is configured to take all the component information included in the statistics object information as target component information if the statistics type information is total coverage statistics.
Wherein, in some embodiments of the present application, the first determining subunit is specifically configured to:
the second determining unit is used for determining target calling interface information according to the statistical object information;
and the calling unit is used for calling the target calling interface corresponding to the target calling interface information to obtain the changed component data set.
Wherein, in some embodiments of the present application, the second determining subunit is specifically configured to:
Recursively calling a reference information acquisition component to acquire each level of father component information of the component information;
and taking the parent component information of each level as reference component information.
Wherein, in some embodiments of the present application, the apparatus further comprises an acquisition module, the acquisition module comprising:
An injection unit for injecting a coverage rate collection component into the target item in response to an information injection request generated through the operation interface;
The reading unit is used for reading comprehensive test coverage rate information of the target item, wherein the comprehensive test coverage rate information is collected by the coverage rate collection component when the target item is tested by the test case.
Wherein, in some embodiments of the present application, the apparatus further includes a rollback module, the rollback module includes:
and the deleting unit is used for deleting the coverage rate collecting component from the target item.
According to the embodiment of the application, firstly, the generating module 301 acquires item information of a target item through a target plug-in, an operation interface is generated by utilizing the target plug-in according to the item information, then, the determining module 302 responds to an information acquisition request generated through the operation interface to determine information acquisition condition information corresponding to the information acquisition request, and then, the screening module 303 screens target coverage rate information from comprehensive test coverage rate information of the target item according to the information acquisition condition information.
According to the embodiment of the application, the target coverage rate information is obtained by screening the comprehensive test coverage rate information through the information obtaining condition information, so that the local test coverage rate information in the software project is obtained, and the targeted construction of the test case is facilitated. The operation interface is generated through the plug-in, so that the convenience of coverage rate information acquisition is improved.
In addition, the present application further provides an electronic device, as shown in fig. 9, which shows a schematic structural diagram of the electronic device according to the present application, specifically:
The electronic device may include one or more processing cores 'processors 401, one or more computer-readable storage media's memory 402, power supply 403, and input unit 404, among other components. It will be appreciated by those skilled in the art that the electronic device structure shown in fig. 9 is not limiting of the electronic device and may include more or fewer components than shown, or may combine certain components, or a different arrangement of components. Wherein:
The processor 401 is a control center of the electronic device, connects various parts of the entire electronic device using various interfaces and lines, and performs various functions of the electronic device and processes data by running or executing software programs and/or modules stored in the memory 402, and calling data stored in the memory 402, thereby performing overall monitoring of the electronic device. Optionally, the processor 401 may include one or more processing cores, and preferably the processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly processes an operating system, a user interface, an application program, etc., and the modem processor mainly processes wireless communication. It will be appreciated that the modem processor described above may not be integrated into the processor 401.
The memory 402 may be used to store software programs and modules, and the processor 401 executes various functional applications and data processing by executing the software programs and modules stored in the memory 402. The memory 402 may mainly include a storage program area that may store an operating system, application programs required for at least one function (such as a sound playing function, an image playing function, etc.), etc., and a storage data area that may store data created according to the use of the electronic device, etc. In addition, memory 402 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.
The electronic device further comprises a power supply 403 for supplying power to the various components, preferably the power supply 403 may be logically connected to the processor 401 by a power management system, so that functions of managing charging, discharging, and power consumption are performed by the power management system. The power supply 403 may also include one or more of any of a direct current or alternating current power supply, a recharging system, a power device commissioning circuit, a power converter or inverter, a power status indicator, etc.
The electronic device may further comprise an input unit 404, which input unit 404 may be used for receiving input digital or character information and generating keyboard, mouse, joystick, optical or trackball signal inputs in connection with user settings and function control.
Although not shown, the electronic device may further include a display unit or the like, which is not described herein. In this embodiment, the processor 401 in the electronic device loads executable files corresponding to the processes of one or more application programs into the memory 402 according to the following instructions, and the processor 401 executes the application programs stored in the memory 402, so as to implement the steps in any information acquisition method provided in the embodiment of the present application.
According to the embodiment of the application, the project information of the target project is acquired through the target plug-in, the operation interface is generated by utilizing the target plug-in according to the project information, the information acquisition condition information corresponding to the information acquisition request is determined in response to the information acquisition request generated through the operation interface, and the target coverage rate information is screened from the comprehensive test coverage rate information of the target project according to the information acquisition condition information.
The target coverage rate information is obtained by screening the information obtaining condition information from the comprehensive test coverage rate information, so that the local test coverage rate information in the software project is obtained, and the targeted construction of the test case is facilitated. The operation interface is generated through the plug-in, so that the convenience of coverage rate information acquisition is improved.
The specific implementation of each operation above may be referred to the previous embodiments, and will not be described herein.
Those of ordinary skill in the art will appreciate that all or a portion of the steps of the various methods of the above embodiments may be performed by instructions, or by instructions controlling associated hardware, which may be stored in a computer-readable storage medium and loaded and executed by a processor.
To this end, the present application provides a computer readable storage medium having stored thereon a computer program that can be loaded by a processor to perform the steps of any of the information acquisition methods provided by the present application.
The specific implementation of each operation above may be referred to the previous embodiments, and will not be described herein.
The computer readable storage medium may include, among others, read Only Memory (ROM), random access Memory (RAM, random Access Memory), magnetic or optical disks, and the like.
Because the instructions stored in the computer readable storage medium can execute the steps in any information acquisition method provided by the present application, the beneficial effects that any information acquisition method provided by the present application can achieve can be achieved, and detailed descriptions of the foregoing embodiments are omitted herein.
The foregoing describes in detail a method, an apparatus, an electronic device, and a computer readable storage medium for obtaining information, and specific examples are provided herein to illustrate the principles and embodiments of the present application, and the above examples are provided to assist in understanding the method and core ideas of the present application, and meanwhile, for those skilled in the art, there are variations in the specific embodiments and application scope according to the ideas of the present application, and the disclosure should not be construed as limiting the application.