Page code coverage rate testing method and device and related equipment

Abstract

The embodiment of the invention discloses a page code coverage rate testing method and device and related equipment. The page code coverage rate testing method comprises the steps of determining page weights of all pages in a target application; based on the page weight of each page, determining an instrumentation point number corresponding to each page; performing code instrumentation on the target application according to the number of the instrumentation points corresponding to each page to form instrumentation points; running the target application after code instrumentation, and obtaining the execution number of instrumentation points corresponding to each page in the running process; and determining the code coverage rate of each page according to the execution number of the instrumentation points of each page and the corresponding number of the instrumentation points. By implementing the technical scheme of the embodiment of the invention, the accuracy of a page code coverage rate test result can be improved.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a method, apparatus and related equipment for page code coverage testing. Background Technology

[0002] With the rapid development of mobile internet technology, applications are becoming increasingly feature-rich, and their internal page structures and interaction logic are becoming more complex. Code coverage, as a key indicator of the adequacy of software testing, plays a crucial role in ensuring the quality and stability of applications.

[0003] In relevant coverage testing techniques, code coverage is mainly obtained by statistically analyzing the execution of instrumentation points during program runtime. However, in application scenarios with complex page structures, the statistical results obtained by existing coverage methods are difficult to use to accurately assess the code coverage of each page, resulting in insufficient accuracy of the obtained page code coverage. Summary of the Invention

[0004] This application addresses some of the deficiencies mentioned in the background art by providing a page code coverage testing method, apparatus, and related equipment.

[0005] In a first aspect, embodiments of this application provide a method for testing page code coverage, including: Determine the page weight of each page in the target application; Based on the page weight of each page, determine the number of instrumentation points corresponding to each page; Based on the number of instrumentation points corresponding to each page, code instrumentation is performed on the target application to form instrumentation points; After the target application runs the code instrumentation, the execution count of the instrumentation points corresponding to each page is obtained during the running process; The code coverage of each page is determined based on the number of instrumentation executions and the number of instrumentation points corresponding to each page.

[0006] In one embodiment of the first aspect, after determining the code coverage of each of the pages, the method further includes: Based on the number of instrumentation executions for each page, determine the number of pages with a non-zero number of instrumentation executions, and determine the page coverage of each target application based on the number of pages with a non-zero number of instrumentation executions.

[0007] In one embodiment of the first aspect, determining the page weight of each page in the target application includes: Obtain the page attributes of each of the aforementioned pages; Based on the page attributes, the page weight of each page in the target application is determined.

[0008] In one embodiment of the first aspect, the page attribute includes execution frequency.

[0009] In one embodiment of the first aspect, the execution frequency is determined based on historical data, which includes the number of page instrumentation executions or the number of page visits.

[0010] In one embodiment of the first aspect, the page attributes include page hierarchy.

[0011] In one embodiment of the first aspect, the page hierarchy is determined based on a pre-constructed page navigation graph of the target application.

[0012] In one embodiment of the first aspect, the page attribute includes page importance.

[0013] In one embodiment of the first aspect, the page attributes include execution frequency, page level, and page importance; Determining the page weight of each page in the target application based on the page attributes includes: The page weight is determined based on the weight score corresponding to the execution frequency, the weight score corresponding to the page level, and the weight score corresponding to the page importance.

[0014] In one embodiment of the first aspect, determining the number of instrumentation points corresponding to each of the pages based on the page weight of each page includes: Based on the page weight of each page, determine the proportion of each page weight to the total weight; Based on the stated ratio and the preset total number of stubbing points, the number of stubbing points corresponding to each page is determined.

[0015] In one embodiment of the first aspect, the step of instrumenting the target application according to the number of instrumentation points corresponding to each of the pages includes: Using the target instrumentation tool, code instrumentation is performed based on the number of instrumentation points corresponding to each page.

[0016] In one embodiment of the first aspect, the target instrumentation tool is a Gradle instrumentation tool.

[0017] In one embodiment of the first aspect, the target application after running the code instrumentation obtains the execution count of the instrumentation points corresponding to each page during operation, including: A random sampling model is constructed based on the Monte Carlo algorithm; Based on the random sampling model, the target application is driven to run, and the execution count of instrumentation points corresponding to each page is obtained during the running process.

[0018] In one embodiment of the first aspect, the construction of the random sampling model based on the Monte Carlo algorithm includes: The random sampling model is constructed based on the pre-built page navigation graph of the target application.

[0019] In one embodiment of the first aspect, before determining the page weights of each page in the target application, the method further includes constructing a page transition graph of the target application; The construction of the page transition graph for the target application includes: Use a breadth-first search algorithm to traverse the page nodes to construct a preliminary jump graph; The configuration file of the target application is parsed to supplement the missing page nodes in the preliminary jump diagram, thus obtaining the page jump diagram.

[0020] In one embodiment of the first aspect, the page transition diagram is an Activity transition diagram, and the page node is an Activity node.

[0021] Secondly, embodiments of this application provide a page code coverage testing device, comprising: The first determining module is used to determine the page weight of each page in the target application; The second determining module is used to determine the number of instrumentation points corresponding to each page based on the page weight of each page. The instrumentation module is used to instrument the target application code according to the number of instrumentation points corresponding to each page, so as to form instrumentation points; The execution module is used to run the target application after the code instrumentation, and obtain the execution count of the instrumentation points corresponding to each page during the execution process; The third determining module is used to determine the code coverage of each page based on the number of instrumentation executions and the number of corresponding instrumentation points for each page.

[0022] In one embodiment of the second aspect, the third determining module is further configured to: Based on the number of instrumentation executions for each page, determine the number of pages with a non-zero number of instrumentation executions, and determine the page coverage of each target application based on the number of pages with a non-zero number of instrumentation executions.

[0023] In one embodiment of the second aspect, the first determining module includes: An attribute acquisition unit is used to acquire the page attributes of each of the pages. The weight determination unit is used to determine the page weight of each page in the target application based on the page attributes.

[0024] In one embodiment of the second aspect, the second determining module includes: The proportion determination unit is used to determine the proportion of the page weight of each page to the total weight; The number of insertion points determination unit is used to determine the number of insertion points corresponding to each page based on the ratio and the preset total number of insertion points.

[0025] In one embodiment of the second aspect, the operating module includes: The sampling model building unit is used to build a random sampling model based on the Monte Carlo algorithm. The running drive unit is used to drive the target application to run based on the random sampling model.

[0026] In one embodiment of the second aspect, when the sampling model construction unit is used to construct a random sampling model based on the Monte Carlo algorithm, it is specifically used for: Based on the Monte Carlo algorithm and the pre-built page jump graph, a random sampling model is constructed.

[0027] In one embodiment of the second aspect, the apparatus further includes a jump graph construction module for: Use a breadth-first search algorithm to traverse the page nodes to construct a preliminary jump graph; The configuration file of the target application is parsed to supplement the missing page nodes in the preliminary jump diagram, thus obtaining the page jump diagram.

[0028] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of any of the methods described in the first aspect.

[0029] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described in the first aspect. Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the methods described in the first aspect.

[0030] According to the page code coverage testing method, apparatus, and related equipment in this application, by determining the page weight of each page in the target application and allocating the number of instrumentation points corresponding to each page based on the page weight, differentiated allocation of monitoring resources for different pages is achieved; by running the instrumented target application and obtaining the execution number of instrumentation points corresponding to each page, the determined page code coverage can be statistically analyzed in combination with the page weight differences at the page dimension, making the test results more consistent with the actual execution of the page and improving the accuracy of the page code coverage test results. Attached Figure Description

[0031] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The accompanying drawings are used to provide a further understanding of the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the accompanying drawings, the same reference numerals generally represent the same components or steps.

[0032] Figure 1 This is a flowchart of a page code coverage testing method provided in an embodiment of this application.

[0033] Figure 2 This is a flowchart illustrating the determination of page weight in a page code coverage testing method provided in this application embodiment.

[0034] Figure 3 This is a page jump diagram in a page code coverage testing method provided in an embodiment of this application.

[0035] Figure 4 This is a flowchart illustrating the determination of the number of instrumentation points in a page code coverage testing method provided in this application embodiment.

[0036] Figure 5 This is a flowchart illustrating the process of obtaining the number of instrumentation points in a page code coverage testing method provided in this application embodiment.

[0037] Figure 6 This is a flowchart of obtaining and constructing a page jump graph in a page code coverage testing method provided in an embodiment of this application.

[0038] Figure 7 This is another page jump diagram in a page code coverage testing method provided in this application embodiment.

[0039] Figure 8 This is a block diagram of a page code coverage testing device provided in an embodiment of this application.

[0040] Figure 9This is a schematic diagram of a computer program product provided in an embodiment of this application.

[0041] Figure 10 This is a hardware block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application more apparent, exemplary embodiments according to this application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0043] See Figure 1 A method for testing page code coverage, including: S101, Determine the page weight of each page in the target application.

[0044] In this application embodiment, a page code coverage testing method is provided, which can be used to perform page code coverage testing on applications with page structures. For example, it can be used for code coverage testing of each page (such as an Activity page) in an Android application, where Android refers to Android.

[0045] In this step, the target application refers to the application for which page code coverage testing will be performed. Page weight can be determined based on one or more of the following: page importance, execution frequency, and page hierarchy. Page importance reflects the page's criticality within the business process, while page execution frequency reflects the likelihood of the page being accessed during application operation. To enhance the practicality of page code coverage testing, page weight can be determined using a combination of page importance, execution frequency, and page hierarchy.

[0046] By introducing page weights and classifying pages, a basis is provided for the subsequent allocation of instrumentation points, thereby avoiding the problem of insufficient coverage of important pages or waste of resources on non-critical pages caused by applying the same testing intensity to all pages.

[0047] S102, based on the page weight of each page, determine the number of instrumentation points corresponding to each page.

[0048] In this step, based on the page weights determined in the preceding steps, a corresponding number of instrumentation points are assigned to different pages. The number of instrumentation points refers to the expected number of instrumentation points set in the relevant code of a given page, used to record the execution status of that page's code during program runtime. The number of instrumentation points does not limit the specific instrumentation locations; it only represents the scale of instrumentation resources allocated to that page during the code instrumentation phase.

[0049] The number of instrumentation points can be determined from the set of possible instrumentation points on each page, based on the page's weight, thus maintaining a correspondence between the number of instrumentation points and the page's weight. A higher page weight indicates greater importance or higher execution frequency, and therefore more instrumentation points should be allocated to that page; conversely, a lower page weight results in fewer instrumentation points.

[0050] By allocating the number of instrumentation points based on page weight, the instrumentation resources can be allocated reasonably, making the coverage test results more consistent with the actual importance and performance of the page, and improving the rationality of the coverage assessment.

[0051] S103, based on the number of instrumentation points corresponding to each page, performs code instrumentation on the target application to form instrumentation points.

[0052] In this step, the code of the target application is instrumented according to the number of instrumentation points corresponding to each page determined in the previous steps.

[0053] Code instrumentation refers to inserting detection logic into application code to record code execution status, thereby obtaining information about whether relevant code has been executed during application runtime. For each page, a corresponding number of instrumentation points can be created in the relevant code logic based on the number of instrumentation points corresponding to that page.

[0054] By creating instrumentation points in the code that correspond to the number of instrumentation points on the page, the basic conditions for obtaining the execution status of the page code in the subsequent runtime phase are provided, thereby making the page code coverage observable.

[0055] S104, run the target application after code instrumentation, and obtain the execution count of the instrumentation points corresponding to each page during the running process.

[0056] In this step, the instrumented target application is run, and the execution count of each instrumentation point for each page is obtained during application execution. The execution count refers to the number of instrumentation points actually executed during application execution.

[0057] By running the instrumented application and recording the execution status of the instrumentation points, execution data of the page-related code during actual operation can be obtained, providing an objective basis for coverage calculation.

[0058] S105, determine the code coverage of each page based on the number of instrumentation executions and the number of corresponding instrumentation points for each page.

[0059] In this step, the code coverage of each page is determined based on the number of instrumentation executions obtained in the previous steps and the number of instrumentation points determined in the previous steps, thereby achieving code coverage testing at the page level.

[0060] The page code coverage testing method according to the embodiments of this application determines the page weight of each page in the target application and allocates the number of instrumentation points corresponding to each page based on the page weight, thereby realizing the differentiated allocation of monitoring resources for different pages. By running the instrumented target application and obtaining the execution number of the instrumentation points corresponding to each page, the determined page code coverage can be statistically analyzed in combination with the differences in page weights at the page level, making the test results more consistent with the actual execution of the page and improving the accuracy of the page code coverage test results.

[0061] In one embodiment, the number of pages with a non-zero number of instrumentation executions is determined based on the number of instrumentation executions for each page, and the page coverage of each target application is determined based on the number of pages with a non-zero number of instrumentation executions.

[0062] In this step, the page coverage rate of each target application can be obtained by comparing the number of pages with non-zero instrumentation execution counts to the total number of pages. By determining whether a page is covered based on whether an instrumentation point is executed, it directly reflects whether the page was actually executed during the testing process, thus achieving accurate statistics on page-level coverage.

[0063] In one embodiment, see Figure 2 Determine the page weight of each page in the target application, including: S201, retrieve the page attributes for each page. Page attributes are used to characterize one or more of the following: page hierarchy characteristics, execution frequency characteristics, and page importance characteristics.

[0064] In this step, page attributes corresponding to each page in the target application are obtained. These page attributes characterize the features of a page within the target application and may include one or more of the following: page hierarchy features, execution frequency features, and page importance features.

[0065] Page hierarchy features characterize the position and level of a page within the page structure or page navigation relationships, such as the page's depth from the application's entry point. Execution frequency features characterize how frequently a page is executed or accessed during application operation. Page importance features characterize the page's importance within the business process; for example, core function pages are more important than non-core function pages. These page attributes can be obtained by analyzing the application's page structure, historical runtime data, or preset configuration information, and this application does not limit the scope of these methods.

[0066] S202, Based on page attributes, determine the page weight of each page in the target application.

[0067] In this step, the page weight of each page in the target application is determined based on the page attributes obtained in the preceding steps.

[0068] Page weight reflects the relative importance of a page in a coverage test or the likelihood of it being executed. When determining page weight based on page attributes, the page attributes can be weighted according to preset weight values ​​corresponding to different page attributes to obtain the page weight. It should be noted that this application does not limit the specific calculation method of page weight; as long as the importance of different pages can be distinguished based on page attributes, the implementation requirements of this application are met.

[0069] By determining page weights based on page attributes, page weights can comprehensively reflect the page's structural position, execution characteristics, and page importance, thus providing a reasonable basis for subsequently allocating the number of instrumentation points based on page weights.

[0070] In one example, page attributes include execution frequency. Execution frequency characterizes how frequently a page is executed or accessed during the target application's runtime. Execution frequency can be determined based on historical data, including the number of times page instrumentation points are executed or the number of times the page is accessed. For example, the execution frequency of corresponding page instrumentation points can be counted based on their historical execution patterns. Here, the page instrumentation points can be set with default weights, and the weight allocation can be optimized using historical instrumentation data in subsequent iterations of testing. Alternatively, the page access frequency can be determined based on the number of times the page is accessed during historical runtime. This application does not limit this approach. By introducing execution frequency, page weights can reflect the actual execution characteristics of the page, thereby improving the representativeness of coverage test results to real-world scenarios.

[0071] In one example, page attributes include page hierarchy. Page hierarchy represents the position of a page within the target application's page structure or page navigation relationships. Page hierarchy is determined based on a pre-built page navigation graph of the target application. The page navigation graph describes the navigation relationships between pages; by analyzing a page's position within the page navigation graph, its depth from the application's entry point can be determined. For example, shallower-level pages are typically entry pages or core process pages. Introducing page hierarchy allows page weights to reflect the page's importance within the page structure, helping to improve the coverage adequacy of critical path pages in coverage testing.

[0072] In this example, relevant techniques can be used to generate a page navigation graph for the target application. For instance, a page navigation graph can be constructed based on the Breadth-First Search (BFS) algorithm. Specifically, an initial navigation graph can be built using the BFS algorithm, and the configuration file can be parsed to supplement the missing page nodes in the initial navigation graph, thus obtaining the final page navigation graph. Taking 11 pages in the target application as an example, such as... Figure 3As shown, the generated page navigation graph 300 includes pages 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, and 11. The initial navigation graph from page 1 to page 7 is obtained based on a breadth-first search algorithm. Pages 8, 9, 10, and 11 are missing page nodes in the initial navigation graph. Page 8 can navigate to pages 9 and 10, while page 11 is an isolated page.

[0073] In one example, page attributes include page importance. Page importance characterizes how important a page is within the target application's business process. Page importance can be determined based on business configuration, manual annotation, or preset rules; for example, pages involving core business functions can be assigned higher page importance. By introducing page importance, page code coverage test results can better serve business needs, ensuring that critical business pages receive more comprehensive test coverage.

[0074] In one example, page attributes include execution frequency, page level, and page importance. Based on these attributes, the page weight of each page in the target application is determined, including: determining the page weight based on the weight score corresponding to execution frequency, page level, and page importance. By simultaneously introducing execution frequency, page level, and page importance, a multi-dimensional characterization of the page is achieved. This allows the page weight to comprehensively reflect the page's execution characteristics, structural position, and business value, making the calculation results more comprehensive and reasonable. Consequently, in subsequent instrumentation point allocation and coverage testing, the importance of different pages is more accurately reflected, improving the granularity of page code coverage assessment.

[0075] For example, determining the page weight of each page in a target application is based on execution frequency, page level, and page importance. Execution frequency can be determined from historical data based on the number of times page instrumentation points are executed; higher execution frequencies result in higher weights. This can be calculated by dividing the number of page instrumentation executions by the total number of page instrumentations. For page level, lower-level pages have higher weights. It's important to note that in practice, not all pages can be directly accessed through page navigation. For instance, some pages may be accessed through external triggers or only under specific conditions, making them unreachable via conventional navigation paths. In such cases, pages that cannot be directly accessed can be handled separately when determining page levels. For example, if a page at the same level can be directly accessed through the application entry point or conventional navigation paths, it can be assigned a higher level weight score. Conversely, pages that cannot be directly accessed and require specific trigger conditions can be assigned a lower level weight score according to predefined rules. Regarding page importance, the page is considered to be part of the module or function it belongs to. The higher the page importance, the higher its weight.

[0076] For example, Table 1 below is based on Figure 3 Calculated weight values: Table 1

[0077] In one embodiment, see Figure 4 Based on the page weight of each page, determine the number of instrumentation points corresponding to each page, including: S401, based on the page weight of each page, determine the proportion of each page's weight to the total weight.

[0078] In this step, the page weights of each page in the target application are obtained, and based on these page weights, the proportion of each page weight to the sum of all page weights is calculated. The total weight refers to the sum of the page weights of all pages in the target application, and the proportion of a page weight to the total weight is used to characterize the relative weight of a particular page among all pages.

[0079] Taking the page weights of each page in Table 1 as an example, the proportion of page weight to total weight is calculated using the following formula:

[0080] in, Indicates the first The proportion of a page's weight to its total weight; Indicates the first Page weight; Indicates the first Page weight; This indicates the total number of pages in the target application.

[0081] Assuming a total of 1000, the number of stake points shown in Table 2 can be calculated: Table 2

[0082] S402, based on the ratio and the preset total number of stubs, determine the number of stubs corresponding to each page.

[0083] In this step, the number of instrumentation points for each page is determined based on the proportion of each page's weight to the total weight as determined in the preceding steps, and the preset total number of instrumentation points. The total number of instrumentation points refers to the pre-set number of instrumentation points used during coverage testing to control the overall instrumentation scale. The number of instrumentation points can be obtained by allocating the total number of instrumentation points according to the page weight proportion.

[0084] By following the steps above, a reasonable allocation of instrumentation points can be achieved based on page weight, making the page code coverage testing process controllable and differentiated, thereby improving the accuracy of coverage test results.

[0085] In one embodiment, code instrumentation is performed on the target application based on the number of instrumentation points corresponding to each page. This includes using a target instrumentation tool to perform code instrumentation based on the number of instrumentation points corresponding to each page. During code instrumentation, a corresponding number of instrumentation points can be formed in the code logic related to each page, based on the number of instrumentation points corresponding to each page. The instrumentation location can be located at the method entry point, method exit point, or other executable code location related to the page; this embodiment does not limit this.

[0086] In one example, the target instrumentation tool is the Gradle instrumentation tool. Gradle instrumentation tools are tools that modify application bytecode based on the Gradle build system during the application build process. By using Gradle instrumentation tools, code instrumentation can be automated during the build phase, reducing manual intervention costs and facilitating repeated execution of page code coverage tests in different test scenarios. Specifically, ClassReader can be used to read file streams; ClassWriter can be used to write modified bytecode; and ClassVisitor can be used to instrument methods, recording method names and inserting counting logic at method entry / exit points to accumulate the number of times the instrumentation points are executed.

[0087] In one embodiment, see Figure 5 After running the instrumented code in the target application, the execution count of the instrumentation points for each page is obtained during runtime, including: S501, a random sampling model is constructed based on the Monte Carlo algorithm.

[0088] The Monte Carlo algorithm is a method for statistical estimation of complex systems through random sampling. In this application, a random sampling model is used to generate a sequence of random operations that drive the target application, simulating the page access behavior of the target application in actual use.

[0089] S502, based on a random sampling model, drives the target application to run and obtains the number of instrumentation points executed for each page during the running process.

[0090] Driving the target application to run refers to performing page navigation or page triggering operations on the target application based on the operation sequence generated by the random sampling model, thereby causing the target application to execute the code logic of the corresponding page during its runtime. During the execution of the target application, when an instrumentation point is executed, the corresponding execution information is recorded for subsequent statistics on the execution count of instrumentation points on each page. This step can be executed multiple times based on the random sampling model to drive the target application to run.

[0091] By driving the target application to run based on a random sampling model, the execution status of the instrumentation points can be collected in multiple random runs, thereby improving the statistical representativeness of the coverage test results.

[0092] In one example, a random sampling model is constructed based on the Monte Carlo algorithm, including: A random sampling model is constructed based on a pre-built page navigation graph of the target application.

[0093] The page transition graph is used to describe the transition relationships between pages in the target application. When constructing a random sampling model based on the page transition graph, page nodes can be used as sampling states, and the transition relationships between pages can be used as sampling paths, thus performing random sampling under the constraints of the page transition graph. By introducing the page transition graph, the page transition paths generated by the random sampling model conform to the actual page structure of the target application, avoiding the generation of invalid running paths that do not conform to the page transition relationships.

[0094] In one example, after obtaining the number of instrumentation executions for each page, the code coverage of each page is determined based on the number of instrumentation executions and the number of instrumentation points for each page. Specifically, the page code coverage can be obtained as the ratio of the average number of instrumentation executions to the number of instrumentation points.

[0095] In one embodiment, before determining the page weights of each page in the target application, the method further includes constructing a page transition graph.

[0096] See Figure 6 Construct page transition diagrams, including: S601 uses a breadth-first search algorithm to traverse page nodes to construct a preliminary jump graph.

[0097] This step uses a breadth-first search algorithm to traverse the page nodes in order to build a preliminary jump graph.

[0098] See Figure 7 Using an Android application as the target application, Activity 700 is a page transition graph constructed using a breadth-first search algorithm. An Activity is a page component in the Android platform used to host user interface interactions. Figure 7 It includes 1st Activity, 2nd Activity, 3rd Activity, 4th Activity, 5th Activity, 6th Activity, 7th Activity, 8th Activity, 9th Activity, 10th Activity, and 11th Activity. 1st represents the first Activity, 2nd represents the second Activity, and so on.

[0099] For example, this step may include: 1. Define nodes and edges: Each Activity is treated as a node, and the navigation operation from one Activity to another is treated as an edge, thus obtaining a graph structure of page navigation relationships.

[0100] 2. Initialize the queue: Starting with the root Activity, add the root Activity to the queue.

[0101] 3. Traverse nodes: While the queue is not empty, perform the following operations in a loop: Remove and return the first element of the queue as the currently visited node; Visit all unvisited neighbor nodes of the current node and add them to the queue. The neighbor nodes represent the target Activities that the current node can jump to.

[0102] 4. Mark visited nodes: Visited nodes are marked to ensure that each node is visited only once, thus avoiding repeated traversal when there are loops in page navigation.

[0103] By performing the BFS traversal described above, a preliminary navigation graph consisting of page nodes and page navigation edges can be obtained. For example, if the arrows represent unidirectional navigation relationships, the corresponding Activity nodes can be obtained by traversing in the order of Activity 1 to Activity 7, and the corresponding preliminary navigation graph can be constructed.

[0104] S602, parse the target application's configuration file, supplement the missing page nodes in the preliminary jump diagram, and obtain the page jump diagram.

[0105] In this step, the target application's configuration file is parsed to supplement the missing page nodes in the initial jump graph, thereby obtaining a more complete page jump graph.

[0106] Taking Android applications as an example, the configuration file can be AndroidManifest.xml. AndroidManifest.xml is a configuration file used to declare application components and their attributes. Since some Activity pages in the application may not be accessible through the traversal method described above, such as pages that may not be reached through the normal navigation path or require specific triggering conditions to enter, it is necessary to supplement and improve the initial navigation diagram by parsing AndroidManifest.xml.

[0107] In one example, parsing the configuration file and supplementing page nodes may include: Filtering with intent-filter: Intent-filter is used to declare the matching rules for intents that a component can respond to. This step allows you to filter configuration items related to page navigation from the intent-filter related information.

[0108] Using Android Debug Bridge (adb) to simulate a redirect scheme: adb is used to interact with Android devices or emulators; a scheme can be used to describe a specific redirect protocol or deep link path. This step can use adb to trigger a redirect with a scheme to verify or supplement page redirect relationships.

[0109] Filter Activities and supplement nodes: Extract the list of Activities from the configuration file, list the Activities not included in the initial navigation graph, and supplement them as missing page nodes in the page navigation graph; for missing pages that can be navigated to from certain pages, corresponding navigation edges can also be added.

[0110] For example, such as Figure 7As shown, Activity 8 can navigate to Activity 9 and Activity 10, while Activity 11 is an isolated Activity. By parsing the configuration file and supplementing the missing page nodes, Activities 8, 9, 10, and 11 can be added to the page navigation graph, resulting in a more complete Activity navigation graph.

[0111] This embodiment can construct a page jump graph that covers regular jump paths and configuration declaration pages, providing a structured foundation for page weight calculation, random sampling model construction, and page coverage evaluation.

[0112] See Figure 8 A page code coverage testing device, comprising: The first determining module 801 is used to determine the page weight of each page in the target application.

[0113] The second determining module 802 is used to determine the number of instrumentation points for each page based on the page weight of each page.

[0114] Instrumentation module 803 is used to instrument code in the target application according to the number of instrumentation points corresponding to each page, so as to form instrumentation points.

[0115] Run module 804, which is used to run the target application after code instrumentation, and obtain the execution count of the instrumentation points corresponding to each page during the running process.

[0116] The third determination module 805 is used to determine the code coverage of each page based on the number of instrumentation executions and the number of corresponding instrumentation points.

[0117] In one embodiment, the third determining module 805 is further configured to: determine the number of pages with non-zero instrumentation execution counts based on the number of instrumentation executions for each page, and determine the page coverage of each target application based on the number of pages with non-zero instrumentation execution counts.

[0118] In one embodiment, the first determining module 801 includes: The attribute acquisition unit is used to acquire the page attributes of each page. The page attributes are used to represent one or more of the following characteristics: page hierarchy, execution frequency, and page importance.

[0119] The weight determination unit is used to determine the page weight of each page in the target application based on page attributes.

[0120] In one embodiment, the second determining module 802 includes: The proportion determination unit is used to determine the proportion of each page's weight to the total weight.

[0121] The number of insertion points determination unit is used to determine the number of insertion points for each page based on the ratio and the preset total number of insertion points.

[0122] In one embodiment, the running module 804 includes: The sampling model building unit is used to build a random sampling model based on the Monte Carlo algorithm.

[0123] The runtime driver unit is used to drive the target application to run based on a random sampling model.

[0124] In one embodiment, when the sampling model building unit is used to build a random sampling model based on the Monte Carlo algorithm, it is specifically used for: A random sampling model is constructed based on the Monte Carlo algorithm and a pre-built page jump graph.

[0125] In one embodiment, the apparatus further includes a jump graph construction module for: Use a breadth-first search algorithm to traverse the page nodes to construct a preliminary jump graph.

[0126] Parse the target application's configuration file, supplement the missing page nodes in the preliminary jump graph, and obtain the page jump graph.

[0127] An exemplary embodiment of this application also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform a method according to an embodiment of this application.

[0128] Exemplary embodiments of this application also provide a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0129] refer to Figure 9 An exemplary embodiment of this application also provides a computer program product 900, including a computer program 901, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0130] refer to Figure 10The present invention describes a structural block diagram of an electronic device 1000 that can serve as a server or client of this application, which is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0131] Electronic device 1000 includes a computing unit 1001, which can perform various appropriate actions and processes according to a computer program stored in read-only memory (ROM) 1002 or a computer program loaded into random access memory (RAM) 1003 from storage unit 1008. The RAM 1003 may also store various programs and data required for device operation. The computing unit 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. An input / output (I / O) interface 1005 is also connected to bus 1004.

[0132] Multiple components in electronic device 1000 are connected to I / O interface 1005, including: input unit 1006, output unit 1007, storage unit 1008, and communication unit 1009. Input unit 1006 can be any type of device capable of inputting information to electronic device 1000. Input unit 1006 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 1007 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 1008 may include, but is not limited to, disk and optical disk. Communication unit 1009 allows electronic device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0133] The computing unit 1001 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 performs the various methods and processes described above. For example, in some embodiments, the methods of the embodiments of this application can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 1008. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 1000 via ROM 1002 and / or communication unit 1009. In some embodiments, the computing unit 1001 can be configured to perform the methods of the embodiments of this application by any other suitable means (e.g., by means of firmware).

[0134] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method of page code coverage testing, the method comprising: The method comprises the following steps: determining the page weight of each page in the target application; determining the number of insertion points corresponding to each page based on the page weight of each page; performing code insertion on the target application according to the number of insertion points corresponding to each page to form insertion points; running the target application after code insertion, and obtaining the number of insertion point executions corresponding to each page during the running process; determining the code coverage of each page according to the number of insertion point executions and the number of insertion points corresponding to each page.

2. The method of claim 1, wherein, After determining the code coverage of each page, the method further comprises: determining the number of pages with non-zero number of insertion point executions based on the number of insertion point executions corresponding to each page, and determining the page coverage of each target application based on the number of pages with non-zero number of insertion point executions.

3. The method of claim 1, wherein, The method for determining the page weight of each page in the target application comprises: obtaining the page attributes of each page; determining the page weight of each page in the target application based on the page attributes.

4. The method of claim 3, wherein, The page attributes include execution frequency.

5. The method of claim 4, wherein, The execution frequency is determined based on historical data, and the historical data includes the number of page insertion point executions or the number of page visits.

6. The method of claim 3, wherein, The page attributes include page level.

7. The method of claim 6, wherein, The page level is determined based on the pre-constructed page jump graph of the target application.

8. The method of claim 3, wherein, The page attributes include page importance.

9. The method of claim 3, wherein, The page attributes include execution frequency, page level and page importance. The method for determining the page weight of each page in the target application based on the page attributes comprises: determining the page weight of the page according to the weight score corresponding to the execution frequency, the weight score corresponding to the page level and the weight score corresponding to the page importance.

10. The method of claim 1, wherein, The method for determining the number of insertion points corresponding to each page based on the page weight of each page comprises: determining the proportion of each page weight in the total weight based on the page weight of each page; determining the number of insertion points corresponding to each page according to the proportion and the total number of preset insertion points.

11. The method of claim 1, wherein, The method for performing code insertion on the target application according to the number of insertion points corresponding to each page comprises: performing code insertion based on the number of insertion points corresponding to each page by using a target insertion tool.

12. The method of claim 11, wherein, The target insertion tool is a Gradle insertion tool.

13. The method of claim 1, wherein, The method for running the target application after code insertion and obtaining the number of insertion point executions corresponding to each page during the running process comprises: constructing a random sampling model based on the Monte Carlo algorithm; driving the target application to run based on the random sampling model, and obtaining the number of insertion point executions corresponding to each page during the running process.

14. The method of claim 13, wherein, The method for constructing a random sampling model based on the Monte Carlo algorithm comprises: constructing the random sampling model based on the pre-constructed page jump graph of the target application.

15. The method of any one of claims 1-14, wherein, Before determining the page weight of each page in the target application, the method further comprises constructing a page jump graph of the target application. The method for constructing a page jump graph of the target application comprises: traversing page nodes using a breadth-first search algorithm to construct a preliminary jump graph; Analyzing a configuration file of the target application, supplementing a missing page node in the preliminary jump graph, and obtaining a page jump graph.

16. The method of claim 15, wherein, The page jump graph is an Activity jump graph, and the page node is an Activity node.

17. A page code coverage testing apparatus characterized by comprising: Comprise: A first determining module configured to determine a page weight of each page in a target application; A second determining module configured to determine a number of instrumentation points corresponding to each page based on the page weight of each page; An instrumentation module configured to perform code instrumentation on the target application according to the number of instrumentation points corresponding to each page, so as to form an instrumentation point; A running module configured to run the target application after the code instrumentation, and obtain a number of executions of the instrumentation point corresponding to each page during the running process; A third determining module configured to determine a code coverage rate of each page according to the number of executions of the instrumentation point corresponding to each page and the number of instrumentation points corresponding to each page.

18. The apparatus of claim 17, wherein, The third determining module is further configured to: Determine a number of pages with a non-zero number of executions of the instrumentation point according to the number of executions of the instrumentation point corresponding to each page, and determine a page coverage rate of each target application based on the number of pages with the non-zero number of executions of the instrumentation point.

19. The apparatus of claim 17, wherein, The first determining module comprises: An attribute obtaining unit configured to obtain a page attribute of each page; A weight determining unit configured to determine a page weight of each page in a target application based on the page attribute.

20. The apparatus of claim 17, wherein, The second determining module comprises: A proportion determining unit configured to determine a proportion of the page weight of each page in a total weight; A point number determining unit configured to determine a number of instrumentation points corresponding to each page according to the proportion and a total number of preset instrumentation points.

21. The apparatus of claim 17, wherein, The running module comprises: A sampling model constructing unit configured to construct a random sampling model based on a Monte Carlo algorithm; A running driving unit configured to drive the target application to run based on the random sampling model.

22. The apparatus of claim 21, wherein, When the sampling model constructing unit is configured to construct a random sampling model based on a Monte Carlo algorithm, the sampling model constructing unit is specifically configured to: Construct a random sampling model based on the Monte Carlo algorithm and a pre-constructed page jump graph.

23. The apparatus of any of claims 17-22, wherein, The device further comprises a jump graph constructing module configured to: Use a breadth-first search algorithm to traverse a page node, so as to construct a preliminary jump graph; Analyze a configuration file of the target application, supplement a missing page node in the preliminary jump graph, and obtain a page jump graph.

24. An electronic device comprising a memory, a processor, and a computer program stored on the memory, wherein the computer program comprises instructions that when executed by the processor cause the processor to perform the method of any one of claims 1-23. The processor executes the computer program to implement the steps of the method of any one of claims 1-16.

25. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1-16.

26. A computer program product comprising a computer program, characterised in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1-16.

Images