Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments of the present invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the embodiments of the present invention are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region, and provide corresponding operation entries for the user to select authorization or rejection.
Some embodiments of the present invention are described in detail below with reference to the accompanying drawings. In the case where there is no conflict between the embodiments, the following embodiments and features in the embodiments may be combined with each other. In addition, the sequence of steps in the method embodiments described below is only an example and is not strictly limited.
Terms or concepts related to the embodiments of the present invention will be explained first:
Test cases (Test cases), which refer to descriptions of Test tasks performed on a specific application program, embody Test schemes, methods, techniques and strategies, and can also be simply considered as a set of Test inputs, execution conditions and expected results compiled for a specific target, for verifying whether the requirements of the specific application program are met.
Directed acyclic graph (DIRECTED ACYCLIC GRAPH, DAG for short) refers to a loop-free directed graph that is made up of multiple nodes and multiple directed edges. In the embodiment of the invention, a plurality of nodes are used for representing a plurality of test cases, each node is associated with code row coverage information of a corresponding test case, and directed edges among the nodes represent the dependency relationship among the test cases.
Sustained integration (Continuous Integration, CI for short) is an application development practice with the core that team members integrate their work on a regular basis, typically at least once a day per member, which also means that multiple integration per day may occur. Each integration is verified by automated build-up (including compilation, release, automated testing) to discover integration errors as early as possible.
Persistent delivery (Continuous Delivery, CD for short) is used to complete the output process of the application program in a short period to ensure that the application program can be stably and continuously maintained in a ready-to-release condition. The method aims to enable compiling, testing and publishing of the application program to be faster and more frequent, so that the cost and time for developing the application program are reduced, and the risk is reduced.
Pull Request (PR) is a notification mechanism that, for example, when you modify the code of another person, informs the original person of the code of your modification, requesting him to merge your modification, which can be called PR.
During the development of an application, iterations of the version, i.e., changes to the code, are often involved. In the CI/CD development mode, the user's change operation to the source code of the application program can be realized by means of Pull Request (PR). After the automated processes are constructed and tested through the CI, the verified code can be automatically deployed from the development environment to the generation environment of the enterprise through the CD. Currently, a tester prepares a plurality of test cases in advance for testing a developed application program. And after part of codes in the source codes of the application programs are changed, the changed source codes are tested again by adopting the test cases, and the test efficiency is low.
In view of this, the embodiment of the present invention provides a solution to the problem of low test efficiency by first acquiring code line coverage information of a plurality of test cases obtained after executing the plurality of test cases in the application source code of the first version, that is, determining which code lines in the application source code are covered by which test cases. And when the source codes of the application programs of the current version are changed, determining a plurality of lines of codes corresponding to the changing operation relative to the source codes of the application programs of the first version, selecting target test cases related to the code lines from a plurality of test cases, and directly executing the target test cases corresponding to the lines of codes in the source codes of the application programs of the second version after the change.
The application program test scheme provided by the embodiment of the invention is described below with reference to the accompanying drawings.
Fig. 1 is a flowchart of an application program testing method provided in an embodiment of the present invention, where the method may be executed by a server, as shown in fig. 1, and the method includes the following steps:
101. and acquiring code line coverage information of a plurality of test cases obtained after the plurality of test cases are executed in the application program source code of the first version.
102. In response to a change operation to the current version of the application source code, a plurality of lines of code corresponding to the change operation relative to the first version of the application source code is determined.
103. And determining the target test case to be executed according to the code line coverage information of the plurality of test cases, the preset dependency relationship among the plurality of test cases and the plurality of lines of codes so as to execute the target test case in the changed application program source code of the second version.
In practical application, when a certain application program needs to be tested, a plurality of test cases corresponding to the application program can be acquired first. The method comprises the steps of obtaining a plurality of tests, wherein the steps comprise determining a test scene and/or a functional module contained in a first version of application program source code, and obtaining a plurality of test cases according to the test scene and/or the functional module. In the embodiment of the present invention, the first version refers to an initial version of the application program, and the current version may be the first version or another version different from the first version.
It should be appreciated that multiple test cases may be made to overlay functional modules contained in the application source code in order to ensure the integrity of the application test. Specifically, as an alternative implementation manner, the functional module included in the source code of the application program of the first version may be determined first, and then the test case corresponding to the functional module may be obtained as a plurality of test cases to be used finally. For example, assuming that the functional module included in the application source code includes a data processing module, a data storage module, and a log module, after determining the functional module, a plurality of test cases corresponding to the data processing module, the data storage module, and the log module may be directly obtained as a plurality of test cases to be finally used. The acquisition of the plurality of test cases refers to the acquisition of test cases compiled by test case writers aiming at the functional modules.
As another alternative implementation, to ensure the comprehensiveness of the application testing, multiple test cases may be determined based on the test scenario. For ease of understanding, for example, it is assumed that the application is a commodity sales application, and it should be understood that the commodity sales application has a user access amount a (test scenario 1) on a common workday or holiday, and a user access amount B (test scenario 2) on a commodity sales promotion day, where B is much larger than a, and requirements on performance, stability, and the like of the application are different, so different test cases may be selected for different test scenarios, so as to be a plurality of test cases to be used finally.
As a further alternative implementation manner, the two conditions of the functional module and the test scenario can be combined, and on the basis of ensuring that a plurality of test cases cover the functional module contained in the source code of the application program, corresponding test cases are selected as a plurality of test cases to be finally used according to different test scenarios, so that the comprehensiveness of the application program test is ensured under the condition of ensuring that the application program test is successfully completed.
After the plurality of test cases are obtained, the plurality of test cases are executed in the first version of application source code. In the process of executing the plurality of test cases, the detection tool can be used for determining code row coverage information of the plurality of test cases, namely determining which code rows in the source code of the application program are covered by which test cases, and can be simply understood as determining the corresponding relation between the code rows and the test cases. At this time, the code line coverage information of the plurality of test cases obtained is stored.
Wherein the selection of the detection tool may be determined based on the programming language type of the application source code. In particular, for example, assuming that the programming language type of the application source code is Python language, the detection tool may be coverage. it can help the developer identify which code lines, statements, or branches are not covered by the test, to guide the developer in writing more test cases, to improve code quality. Assuming that the programming language type of the application source code is C/C++ language, the detection tool may be gcov, and the gcov is a tool in GCC (GNU Compiler Collection, GNU compiler set). Assuming the programming language type of the application source code is Java, the detection tool may be JaCoCo or the like, not to mention here, the JaCoCo is a tool for computing Java code coverage, it provides a number of ways to collect and report code coverage data, helps developers know which parts of the code are covered by their test.
It should be noted that, when the current version of the application source code is changed, in response to the change operation of the current version of the application source code, a plurality of lines of codes corresponding to the change operation with respect to the first version of the application source code are determined, where the plurality of lines of codes are changed in the source code, for example, assuming that the current version of the application source code contains 500 lines of codes in total, and lines 200-300 of the lines are changed, the "lines of codes" refers to the lines 200-300 of the lines of codes. In this process, the changed lines of code may be obtained by comparing the first version with the changed second version of the application source code.
If the current version is the first version, after the 'multi-line code' is obtained, the target test case to be executed can be determined directly according to the code line coverage information of the plurality of test cases, the preset dependency relationship among the plurality of test cases and the multi-line code.
If the current version is other than the first version, the code line coverage information of the plurality of test cases stored before can be directly obtained, and the code line coverage information of the plurality of test cases does not need to be determined by executing the plurality of test cases again, so that the working efficiency is improved. And then, determining the target test case to be executed according to the code line coverage information of the plurality of test cases, the preset dependency relationship among the plurality of test cases and the plurality of lines of codes.
The dependency relationship among the test cases is artificially configured when the test cases are generated. It should be understood that, after the code lines of the plurality of lines are changed relative to the code lines of the source code, in order to ensure the accuracy of the application program test, part of the test cases related to the code lines can be determined in the plurality of test cases, and when the part of test cases are determined, not only the corresponding relationship between the test cases and the code lines, but also the dependency relationship among the plurality of test cases needs to be considered, namely, the target test cases to be executed are determined according to the code line coverage information of the plurality of test cases, the preset dependency relationship among the plurality of test cases and the code lines.
For ease of understanding, for example, assume that "multiple lines of code" are 200 th-300 th lines of code in the source code of the first version of the application program, and according to code line coverage information of multiple test cases, it can be determined that the test cases corresponding to the multiple lines of code include test case a and test case B, and the test case a needs to be executed depending on test case C, and the test case B needs to be executed depending on test case D, then the new test case that is finally determined, that is, the target test case to be executed includes test case a, test case B, test case C, and test case D at the same time.
Further, after the target test case to be executed is determined, the target test case can be directly executed in the changed application program source code of the second version. Based on the above, the application program testing method provided by the embodiment of the invention can obtain the corresponding relation between the test cases and the code lines after obtaining the code line coverage information of the plurality of test cases obtained after executing the plurality of test cases in the application program source code of the first version. And when the current version of the application program source code is changed, selecting a target test case related to a plurality of lines of codes corresponding to the changing operation from a plurality of test cases relative to the first version of the application program source code, and then directly executing the target test case corresponding to the plurality of lines of codes in the changed second version of the application program source code without adopting the plurality of test cases to test the changed source code again, thereby improving the test efficiency.
FIG. 2 is a flowchart of determining a target test case to be executed, where, as shown in FIG. 2, the determining the target test case to be executed according to code line coverage information of a plurality of test cases, dependency relationships among the plurality of test cases and a plurality of lines of codes specifically includes the following steps:
201. generating a directed acyclic graph according to code line coverage information of a plurality of test cases and the dependency relationship among the plurality of test cases, wherein the plurality of test cases are determined to be used as a plurality of nodes in the directed acyclic graph, each node is associated with code line coverage information of a corresponding test case, and directed edges among the nodes represent the dependency relationship among the test cases.
202. And determining the target test case to be executed according to the directed acyclic graph and the plurality of lines of codes.
For ease of understanding, the following illustrates the dependency relationship between code line coverage information of a plurality of test cases and the plurality of test cases in conjunction with fig. 3:
In fig. 3, 4 test cases and 4 different functional modules are included. The 4 test cases are test case A, test case B, test case C and test case D, and the 4 functional modules are respectively a functional module 1 (corresponding to 1-500 lines of codes), a functional module 2 (corresponding to 1-200 lines of codes), a functional module 3 (corresponding to 1-100 lines of codes) and a functional module 4 (corresponding to 1-300 lines of codes). Wherein test case A covers the 200 th-300 th row codes in functional module 1, test case B covers the 400 th-500 th row codes in functional module 1, and test case B depends on test case A. Test case C covers the 20 th-100 th line code in functional module 2 and the 20 th-30 th line code in functional module 3. Test case D covers the 60 th-90 th line codes in functional module 3 and the 200 th-300 th line codes in functional module 4, and test case D depends on test case B and test case C.
After the code line coverage information of the plurality of test cases and the dependency relationship between the plurality of test cases are obtained, a directed acyclic graph can be generated based on the code line coverage information, and the directed acyclic graph can be specifically seen in fig. 4. In fig. 4, a total of 4 nodes are included, and the 4 nodes are used to represent test case a, test case B, test case C, and test case D, respectively. The directed edge between the test case A and the test case B indicates that the test case B depends on the test case A, the directed edge between the test case B and the test case D indicates that the test case D depends on the test case B, the directed edge between the test case C and the test case D indicates that the test case D depends on the test case C, and the "function module 1:200-300" beside the test case A indicates code line coverage information associated with the node of the test case A, wherein the specific content of the code line coverage information is that the test case A covers 200 th-300 th line codes in the function module 1, and the "function module 1:400-500" beside the test case B indicates code line coverage information associated with the node of the test case B, and the specific content of the code line coverage information is that the test case B covers 400 th-500 th line codes in the function module 1. "functional modules 2:20-100" beside test case C, functional modules 3:20-30 "represent code row coverage information associated with this node of test case C, where the specific content of the code row coverage information is that test case C covers 20 th-100 th row codes in functional module 2 and 20 th-30 th row codes in functional module 3. "functional modules 3:60-90" beside the test case D, and "functional modules 4:200-300" represent code line coverage information associated with the node of the test case D, where the specific content of the code line coverage information is that the test case D covers the 60 th-90 th line codes in the functional modules 3 and the 200 th-300 th line codes in the functional modules 4. In fig. 4, the two special nodes "start" and "end" are logical virtual nodes, and are used to represent the head and tail of the directed acyclic graph.
After the directed acyclic graph is obtained, determining a target test case to be executed according to the directed acyclic graph and a plurality of lines of codes, wherein the specific steps are that at least one test case covering the plurality of lines of codes is determined in the directed acyclic graph; and determining that the target test case comprises at least one test case and the test case on which the at least one test case depends respectively.
It should be understood that, by generating the directed acyclic graph according to the code line coverage information of the test cases and the dependency relationship between the test cases, the visualization effect of the information is increased, so that at least one test case covering multiple lines of codes and the test case on which the at least one test case depends can be found quickly and accurately, and in practical application, the at least one test case and the test case on which the at least one test case depends can be determined directly as the final target test case, so that the accuracy of the target test case is ensured. When the target test case is executed, the test case on the depended side in the target test case needs to be executed first, and then the test case on the depended side is executed, for example, if the target test case includes test case a, test case B and test case D, where the test case B depends on the test case a, and the test case D depends on the test case B, the target test case is executed sequentially according to the sequence of the test case a, the test case B and the test case D.
In practical applications, the modification operation of the source code of the first version of the application program may include the operations of modifying, adding and deleting the code line of the existing function module and the operation of adding a new function module.
Based on the above, in the embodiment of the present invention, the source code of the application program of the first version includes codes corresponding to each of the plurality of function modules, the changing operation includes an operation of adding a function module, and correspondingly, the changing operation includes a plurality of lines of codes corresponding to the changing operation including codes of the function module. At this time, a determination process of the target test case is performed with reference to fig. 5.
FIG. 5 is a further flowchart of determining a target test case to be executed according to an embodiment of the present invention, where, as shown in FIG. 5, determining the target test case to be executed specifically includes the following steps:
And acquiring a new test case generated aiming at the newly added functional module and the dependency relationship between the new test case and the existing multiple test cases.
502. And executing the new test case in the changed application program source code of the second version so as to determine the code line coverage information of the new test case.
503. And updating the directed acyclic graph according to the dependency relationship between the new test case and the plurality of test cases and the code row coverage information of the new test case.
504. And determining a new test case covering codes of the newly added functional module in the updated directed acyclic graph.
505. And determining the test cases on which the new test cases depend in the updated directed acyclic graph.
506. The target test cases are determined to comprise new test cases and test cases on which the new test cases depend.
It should be understood that, in practical application, if the operation of changing the source code of the first version of the application program is the operation of the newly added function module, then the code corresponding to the change operation is the code corresponding to the newly added function module. In specific implementation, because a new functional module exists, a corresponding new test case is generated aiming at the new functional module, and the dependency relationship between the new test case and a plurality of test cases is configured. For example, assuming that the functional module 5 is newly added on the basis of the embodiments provided in fig. 3 and 4, a test case E (i.e., a new test case) may be generated for the functional module 5, and the dependency relationship between the test case E and the test case a, the test case B, the test case C, and the test case D may be determined, respectively, for example, finally determining that the test case a depends on the test case E.
And then executing a new test case in the changed application program source code of the second version to determine code line coverage information of the new test case, and updating the previous directed acyclic graph according to the dependency relationship between the new test case and a plurality of test cases and the code line coverage information of the new test case, such as nodes corresponding to the new test case, connecting edges between the nodes are modified, the corresponding code line coverage information is associated for the new node, the code line coverage information associated with other existing nodes is modified, and the like. Assuming that the functional module 5 corresponds to 1-200 lines of code and the test case E covers 10-180 lines of code in the functional module 5 and 50-90 lines of code in the functional module 1, in combination with the above-mentioned dependency relationship "test case a depends on test case E", an updated directed acyclic graph can be obtained, see in particular fig. 6.
After the updated directed acyclic graph is obtained, the new test case covering the code of the newly added functional module and the test case on which the new test case depends can be determined in the updated directed acyclic graph, and the new test case and the test case on which the new test case depends are used as final target test cases, and the specific implementation manner of the process can refer to the embodiments and is not repeated herein. That is, for the change operation of the newly added functional module, the finally determined target test case not only includes the new test case designed for the newly added functional module, but also includes other test cases on which the new test case depends, so that comprehensive and accurate test can be performed for the change operation result.
FIG. 7 is a flowchart of determining code line coverage information of a plurality of test cases according to an embodiment of the present invention, where, as shown in FIG. 7, determining code line coverage information of a plurality of test cases specifically includes the following steps:
701. The method comprises the steps of obtaining at least one basic test case obtained by splitting a plurality of test cases and advanced test cases respectively depending on the at least one basic test case, wherein test configuration information contained in one test case comprises test configuration information contained in the split basic test case and test configuration information contained in a corresponding advanced test case, and each basic test case comprises common test configuration information in at least two test cases in the plurality of test cases.
702. And acquiring the dependency relationship among the optimized test cases, wherein the optimized test cases comprise at least one basic test case and advanced test cases respectively depending on the at least one basic test case.
703. And acquiring code line coverage information of the plurality of test cases obtained after executing the optimized plurality of test cases in the first version of application program source code.
In practical application, a plurality of test cases which are generated initially may contain some common test configuration information, for example, the test case F, the test case G and the test case H which are generated initially all contain the same test environment configuration information, and the difference is that the test configuration information such as test data, test steps and the like in each test case is different. In practical application, if the test case F, the test case G, and the test case H are executed respectively, the same test configuration information is repeatedly executed multiple times, which increases resource consumption and test time.
Therefore, in this embodiment, for a plurality of test cases that are initially generated, extraction of "the same test configuration information" of all or part of the test cases may be performed, as one basic test case corresponding to the test cases, and "the difference test configuration information" is used as a further test case, so as to complete optimization of the plurality of test cases that are initially generated. For example, test case F splits to obtain a base test case a and a further test case b depending on the base test case a, test case G splits to obtain a base test case a and a further test case c depending on the base test case a, and test case H splits to obtain a base test case a and a further test case d depending on the base test case a. Thus, the optimized plurality of test cases includes a base test case a, and a further test case b, a further test case c, and a further test case d, which depend on the base test case a, respectively.
At this time, the basic test case a is executed in the source code of the first version of the application program, and the advanced test case b, the advanced test case c and the advanced test case d are executed respectively, that is, the test configuration information in the basic test case a only needs to be executed once, multiple repeated execution is not needed, so that the resource consumption and the test time are reduced, and the test efficiency is improved.
The generation of the directed acyclic graph may be based on these optimized test cases.
In order to more intuitively understand the application program testing method provided by the embodiment of the present invention, a specific embodiment of an application program testing system is provided below to describe the scheme of the present invention:
fig. 8 is a schematic structural diagram of an application program testing system according to an embodiment of the present invention. As shown in fig. 8, the system includes a code coverage information collection unit 81, a directed acyclic graph construction unit 82, and a test case selection optimization unit 83.
The code coverage information collection unit 81 includes a code coverage information collection tool and a data analysis engine. In practical application, the code coverage information acquisition tool is used for acquiring code row coverage information of a plurality of test cases, and the data analysis engine is used for analyzing the code row coverage information of the plurality of test cases to obtain a corresponding relation table of the test cases and the code rows in the source code.
In particular, as shown in fig. 9, the code coverage information collecting unit 81 includes at least the following steps in actual application:
determining the programming language type of the source code of the application program;
If the programming language type is Python language, adopting coverage. Py as a code coverage information acquisition tool, or if the programming language type is Java language, adopting JaCoCo as a code coverage information acquisition tool, or if the programming language type is C/C++ language, adopting GCC as a code coverage information acquisition tool, or if the programming language type is other languages, adopting a corresponding detection tool as a code coverage information acquisition tool. When the implementation is carried out, after the code coverage information acquisition tool is selected, the code coverage information acquisition tool is integrated into the whole application program test framework;
Executing a plurality of test cases in the source code of the first version of the application program, in the process, determining code line coverage information of the plurality of test cases by using a code coverage information acquisition tool, and generating a code line coverage information analysis report, wherein the code line coverage information analysis report identifies which code lines are covered by which test cases;
And analyzing the code line coverage information analysis report by using a data analysis engine to generate a corresponding relation table of the test cases and the code lines in the source codes.
Based on the above, when the embodiment of the invention faces different programming language types, different code coverage information acquisition tools can be selected, so that the method is suitable for various application environments and has good expansibility and practicability.
The directed acyclic graph construction unit 82 is configured to node-arrange a plurality of test cases, determine a dependency relationship between the plurality of test cases, and generate a directed acyclic graph according to code line coverage information (i.e., a table of correspondence between test cases obtained by the code coverage information collection unit 81 and code lines in source code) of the plurality of test cases and the dependency relationship between the plurality of test cases. The node arrangement of the test cases is to organize and arrange the test cases according to a certain logic and sequence so as to ensure the orderly execution of the test work and the accuracy of the test result.
The test case selection optimizing unit 83 is configured to check the code change line of the current PR, perform code change analysis to obtain a plurality of lines of codes of the current change, determine a target test case to be executed according to the directed acyclic graph (including code line coverage information of a plurality of test cases and dependency relationships among the plurality of test cases) and the plurality of lines of codes obtained by the directed acyclic graph constructing unit 82, and execute the target test case in the changed application source code.
The system shown in fig. 8 may perform the steps performed by the application testing method in the foregoing embodiment, and the detailed execution process and technical effects are referred to the description in the foregoing embodiment, which is not repeated herein.
An application testing apparatus of one or more embodiments of the present invention will be described in detail below. Those skilled in the art will appreciate that these means may be configured by the steps taught by the present solution using commercially available hardware components.
Fig. 10 is a schematic structural diagram of an application program testing device according to an embodiment of the present invention, and as shown in fig. 10, the device includes an obtaining module 11, a response module 12, and a determining module 13.
An acquiring module 11, configured to acquire code line coverage information of a plurality of test cases obtained after the plurality of test cases are executed in source code of an application program in a first version;
a response module 12, configured to respond to a change operation of an application source code of a current version, and determine a plurality of lines of code corresponding to the change operation with respect to the application source code of the first version;
And the determining module 13 is configured to determine a target test case to be executed according to the code line coverage information of the plurality of test cases, the preset dependency relationship among the plurality of test cases, and the plurality of lines of codes, so as to execute the target test case in the changed application source code of the second version.
Wherein optionally the current version is the first version or another version different from the first version.
The determining module 13 is specifically configured to generate a directed acyclic graph according to the code line coverage information of the multiple test cases and the dependency relationship between the multiple test cases, and determine a target test case to be executed according to the directed acyclic graph and the multiple lines of codes, where the multiple test cases are determined to be multiple nodes in the directed acyclic graph, each node is associated with the code line coverage information of the corresponding test case, and directed edges between the nodes represent the dependency relationship between the test cases.
The determining module 13 is specifically configured to determine, in the directed acyclic graph, at least one test case covering the multiple lines of code, determine, in the directed acyclic graph, a test case on which the at least one test case depends, and determine that the target test case includes the at least one test case and a test case on which the at least one test case depends.
Optionally, the source code of the application program of the first version includes codes corresponding to a plurality of function modules, the changing operation includes an operation of adding a function module, and correspondingly, the plurality of lines of codes include codes of the added function module. Based on this, the obtaining module 11 is further configured to obtain a new test case generated for the new function module, and a dependency relationship between the new test case and the multiple test cases.
The determining module 13 is configured to execute the new test case in the changed second version of application source code, so as to determine code line coverage information of the new test case, and update the directed acyclic graph according to the dependency relationship between the new test case and the multiple test cases and the code line coverage information of the new test case.
The determining module 13 is further specifically configured to determine, in the updated directed acyclic graph, the new test case covering the code of the new added function module, determine, in the updated directed acyclic graph, the test case on which the new test case depends, and determine that the target test case includes the new test case and the test case on which the new test case depends.
The obtaining module 11 is further configured to obtain at least one basic test case obtained by splitting the plurality of test cases and a further test case that depends on the at least one basic test case, where test configuration information included in one test case includes test configuration information included in the split basic test case and test configuration information included in a corresponding further test case, each basic test case includes common test configuration information in at least two test cases in the plurality of test cases, and obtain a dependency relationship between the plurality of optimized test cases, where the plurality of optimized test cases includes the at least one basic test case and the further test case that depends on the at least one basic test case.
The obtaining module 11 is specifically configured to obtain code line coverage information of the plurality of test cases obtained after executing the optimized plurality of test cases in the first version of application source code, determine a detection tool to be used according to a programming language type of the application source code, and determine the code line coverage information of the plurality of test cases based on the detection tool.
The apparatus shown in fig. 10 may perform the steps provided in the foregoing embodiments, and detailed execution and technical effects are referred to the descriptions in the foregoing embodiments, which are not repeated herein.
In one possible design, the configuration of the application testing apparatus shown in fig. 10 may be implemented as an electronic device. As shown in fig. 11, the electronic device may include a processor 21, a memory 22, and a communication interface 23. Wherein the memory 22 has stored thereon executable code which, when executed by the processor 21, causes the processor 21 to at least implement the application test method as provided in the previous embodiments.
Additionally, embodiments of the present invention provide a non-transitory machine-readable storage medium having executable code stored thereon, which when executed by a processor of an electronic device, causes the processor to at least implement an application testing method as provided in the previous embodiments.
In addition, an embodiment of the present invention provides a computer program product comprising a computer program which, when executed by a processor of an electronic device, enables the processor to implement at least an application program testing method as provided in the previous embodiment.
The apparatus embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
From the above description of embodiments, it will be apparent to those skilled in the art that the embodiments may be implemented by adding necessary general purpose hardware platforms, or may be implemented by a combination of hardware and application programs. Based on such understanding, the foregoing aspects, in essence and portions contributing to the art, may be embodied in the form of a computer program product, which may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
It should be noted that the above-mentioned embodiments are merely for illustrating the technical solution of the present invention, and not for limiting the same, and although the present invention has been described in detail with reference to the above-mentioned embodiments, it should be understood by those skilled in the art that the technical solution described in the above-mentioned embodiments may be modified or some technical features may be equivalently replaced, and these modifications or substitutions do not make the essence of the corresponding technical solution deviate from the spirit and scope of the technical solution of the embodiments of the present invention.