Application compatibility detection method and device and electronic equipment

Abstract

The embodiment of the invention provides an application program compatibility detection method and device and electronic equipment. The method comprises the steps that a state relation network of an application program is obtained; the coverage and the redundancy are determined; the coverage degree represents the proportion of the effective coverage part in the interface jump relation of the state relation network to the whole; the redundancy represents the proportion of the redundant part in the interface jump relation of the state relation network to the whole; screening the test paths in the initial test path set according to the coverage and the redundancy to obtain a target test path set; generating a test case according to the test path in the target test path set; the initial test path set is determined according to the state relation network; in a preset distributed test cluster, executing each test case to obtain a compatibility matrix; and according to the compatibility matrix, determining a compatibility score of the application program. The method is used for achieving the effect of accurately detecting the compatibility of the application program.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a method, apparatus, and electronic device for testing application compatibility. Background Technology

[0002] With the rapid development of mobile internet and software development technologies, the iteration speed of applications has accelerated significantly. At the same time, the updates of operating system versions, the diversification of device hardware configurations, and the increasing complexity of user interaction logic have led to increasingly prominent compatibility issues of applications across different platforms, devices, and environments.

[0003] In existing technologies, fixed-path testing is usually based on preset interface interaction rules (such as clicking button A → jumping to page B → entering text → submitting), simulating user operations through scripts or tools, and then analyzing compatibility issues.

[0004] However, in the above methods, the test path is fixed, which makes it difficult to cover complex interaction logic that is not preset, and it is easy to miss critical paths when facing dynamic interfaces or non-linear processes, thus leading to inaccurate compatibility analysis. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for detecting application compatibility, so as to achieve the effect of accurately detecting application compatibility.

[0006] In a first aspect, embodiments of this application provide a method for detecting application compatibility, comprising:

[0007] Obtain the application's state relationship network; and determine its coverage and redundancy; wherein, the state relationship network represents the jump relationships between the application's interfaces; the coverage represents the proportion of the effectively covered part of the interface jump relationships in the state relationship network to the whole; and the redundancy represents the proportion of the redundant part of the interface jump relationships in the state relationship network to the whole.

[0008] Based on the coverage and redundancy, the test paths in the initial test path set are filtered to obtain a target test path set; test cases are generated based on the test paths in the target test path set; wherein, the initial test path set is determined based on the state relationship network; the initial test path set includes at least one test path; the test path represents the interface jump order of the application; the test cases are used to test whether the compatibility of the application meets the expected results;

[0009] In a pre-defined distributed test cluster, each test case is executed to obtain a compatibility matrix; based on the compatibility matrix, the compatibility score of the application is determined.

[0010] In one possible implementation, determining coverage and redundancy includes:

[0011] The initial test path set is determined based on the state relationship network;

[0012] The coverage and redundancy are determined based on the state relationship network and the initial test path set.

[0013] In one possible implementation, determining the initial test path set based on the state relationship network includes:

[0014] Based on the state relationship network, determine the set of executable test paths;

[0015] The coverage excitation factor is determined based on the ratio of the total number of interface transitions to the number of interfaces that do not transition in the state relationship.

[0016] The repetitive operation inhibition factor is determined based on the similarity between the current path and the historical path in the set of executable test paths.

[0017] Based on the coverage incentive factor and the repetitive operation inhibition factor, the test paths in the executable test path set are filtered to determine the initial test path set.

[0018] In one possible implementation, determining the coverage and the redundancy based on the state relationship network and the initial test path set includes:

[0019] Based on the test paths in the initial test path set, perform tests in a preset test environment to determine the success rate of each test path.

[0020] The coverage is determined based on the total number of interface transitions in the state relationship network and the operation success rate;

[0021] The redundancy is determined based on the state transition sequence of the test paths in the initial test path set, the number of repeatedly accessed interfaces of the test paths, and the frequency of repeatedly triggered operations in the test paths.

[0022] In one possible implementation, the test paths in the initial test path set are filtered according to the coverage and the redundancy to obtain a target test path set, including:

[0023] Based on the coverage and the redundancy, determine the comprehensive evaluation value of the test paths in the initial test path set;

[0024] If the comprehensive evaluation value of the test path is determined to be greater than or equal to a preset threshold, then the corresponding test path is determined to be the test path set in the target test path set.

[0025] In one possible implementation, in a pre-defined distributed test cluster, each test case is executed to obtain a compatibility matrix, including:

[0026] In the preset distributed test cluster, each test case is executed to obtain the execution data corresponding to the test case; wherein, the execution data represents the relevant information data of the application generated during the execution of the test cases;

[0027] The execution data is aggregated to obtain a compatibility matrix.

[0028] In one possible implementation, the method further includes:

[0029] If the compatibility score of the application is determined to be less than the preset score value, then the application is determined to be the target application;

[0030] Based on the compatibility score, the coverage activation factor and the repetitive operation inhibition factor are modified to obtain the modified coverage activation factor and the modified repetitive operation inhibition factor.

[0031] Based on the modified coverage incentive factor and the modified repetitive operation suppression factor, the test paths in the target test path set of the target application are adjusted.

[0032] In one possible implementation, obtaining the application's state relationship network includes:

[0033] Based on the interactive element attributes of the application's interface and the application's interface transition states, a state transition matrix is ​​determined; wherein, the state transition matrix represents the probability of transitions between different interfaces of the application.

[0034] A state relationship network is determined based on the interface state transition matrix and the behavior data of the application's historical operation interface.

[0035] Secondly, embodiments of this application provide an application compatibility detection device, comprising:

[0036] An acquisition module is used to acquire the state relationship network of an application and determine its coverage and redundancy. The state relationship network represents the navigation relationships between the application's interfaces. The coverage represents the proportion of effectively covered navigation relationships in the state relationship network. The redundancy represents the proportion of redundant navigation relationships in the state relationship network.

[0037] A generation module is used to filter test paths in an initial test path set according to the coverage and redundancy to obtain a target test path set; and to generate test cases based on the test paths in the target test path set; wherein, the initial test path set is determined according to the state relationship network; the initial test path set includes at least one test path; the test path represents the interface jump order of the application; and the test cases are used to test whether the compatibility of the application meets the expected results.

[0038] The execution module is used to execute various test cases in a preset distributed test cluster to obtain a compatibility matrix; and to determine the compatibility score of the application based on the compatibility matrix.

[0039] In one possible implementation, the acquisition module includes:

[0040] The first determining module is used to determine the initial test path set based on the state relationship network;

[0041] The second determining module is used to determine the coverage and the redundancy based on the state relationship network and the initial test path set.

[0042] In one possible implementation, the first determining module includes:

[0043] Based on the state relationship network, determine the set of executable test paths;

[0044] The coverage excitation factor is determined based on the ratio of the total number of interface transitions to the number of interfaces that do not transition in the state relationship.

[0045] The repetitive operation inhibition factor is determined based on the similarity between the current path and the historical path in the set of executable test paths.

[0046] Based on the coverage incentive factor and the repetitive operation inhibition factor, the test paths in the executable test path set are filtered to determine the initial test path set.

[0047] In one possible implementation, the second determining module includes:

[0048] Based on the test paths in the initial test path set, perform tests in a preset test environment to determine the success rate of each test path.

[0049] The coverage is determined based on the total number of interface transitions in the state relationship network and the operation success rate;

[0050] The redundancy is determined based on the state transition sequence of the test paths in the initial test path set, the number of repeatedly accessed interfaces of the test paths, and the frequency of repeatedly triggered operations in the test paths.

[0051] In one possible implementation, the generation module includes:

[0052] Based on the coverage and the redundancy, determine the comprehensive evaluation value of the test paths in the initial test path set;

[0053] If the comprehensive evaluation value of the test path is determined to be greater than or equal to a preset threshold, then the corresponding test path is determined to be the test path set in the target test path set.

[0054] In one possible implementation, the execution module includes:

[0055] In the preset distributed test cluster, each test case is executed to obtain the execution data corresponding to the test case; wherein, the execution data represents the relevant information data of the application generated during the execution of the test cases;

[0056] The execution data is aggregated to obtain a compatibility matrix.

[0057] In one possible implementation, the device further includes:

[0058] The correction module is used to determine that the application is the target application if it is determined that the compatibility score of the application is less than a preset score value.

[0059] Based on the compatibility score, the coverage activation factor and the repetitive operation inhibition factor are modified to obtain the modified coverage activation factor and the modified repetitive operation inhibition factor.

[0060] Based on the modified coverage incentive factor and the modified repetitive operation suppression factor, the test paths in the target test path set of the target application are adjusted.

[0061] In one possible implementation, the acquisition module includes:

[0062] Based on the interactive element attributes of the application's interface and the application's interface transition states, a state transition matrix is ​​determined; wherein, the state transition matrix represents the probability of transitions between different interfaces of the application.

[0063] A state relationship network is determined based on the interface state transition matrix and the behavior data of the application's historical operation interface.

[0064] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0065] The memory stores computer-executed instructions;

[0066] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0067] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0068] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0069] This application provides a method, apparatus, and electronic device for detecting application compatibility. By acquiring the application's state relationship network and determining coverage and redundancy, the state relationship network represents the jump relationships between interfaces, coverage reflects the proportion of effective interface jumps, and redundancy reflects the proportion of ineffective redundant jumps. By quantifying these two indicators, the initial test path set (generated based on the state relationship network and containing multiple interface jump order paths) can be filtered and optimized, eliminating redundant paths and retaining high-coverage paths to form a target test path set. Based on this, test cases are generated and executed in parallel in a distributed test cluster, quickly obtaining a compatibility matrix (reflecting compatibility performance under different devices / systems). Finally, a compatibility score is obtained through matrix quantification. Through accurate modeling of the state relationship network and dynamic balancing of coverage / redundancy, the problems of redundancy and low efficiency in traditional compatibility testing paths are solved. This ensures comprehensive test coverage while avoiding the waste of ineffective test resources. Simultaneously, the parallel execution mechanism of the distributed cluster further improves testing speed. Finally, the quantitative score enables an intuitive evaluation of compatibility results, providing efficient and reliable detection support for cross-platform application adaptation. Attached Figure Description

[0070] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0071] Figure 1 A flowchart illustrating an application compatibility detection method provided in this application embodiment. Figure 1 ;

[0072] Figure 2 A flowchart illustrating an application compatibility detection method provided in this application embodiment. Figure 2 ;

[0073] Figure 3 A flowchart illustrating step S202 in an application compatibility detection method provided in this application embodiment;

[0074] Figure 4 A schematic diagram of the structure of an application compatibility detection device provided in this application embodiment. Figure 1 ;

[0075] Figure 5 A schematic diagram of the structure of an application compatibility detection device provided in this application embodiment. Figure 2 ;

[0076] Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application.

[0077] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0078] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0079] With the rapid iteration of mobile internet and software development technologies, the application update cycle has been shortened from the traditional months to weeks or even days. This rapid iteration characteristic is deeply coupled with the fragmentation of operating system versions, the diversification of device hardware configurations (such as different resolutions, processor architectures, and memory capacities), and the increasing complexity of user interaction logic (such as multi-tasking parallel operation, gesture interaction, and voice control), resulting in an exponential increase in compatibility issues across platforms, devices, and environments.

[0080] Traditional fixed-path testing constructs test scripts using pre-defined linear interaction rules (such as "click button A → jump to page B → enter text → submit"), which can effectively cover basic function verification in static interfaces and linear process scenarios.

[0081] However, it suffers from three major flaws: First, the fixed path leads to blind spots in test coverage. When facing dynamic interfaces (such as responsive designs that adjust layout in real time based on user behavior) or non-linear processes (such as multi-branch decision trees or user-defined operation sequences), the preset path cannot cover undefined interaction logic. For example, users may trigger hidden functions through unconventional operations such as long presses or swipes, or cause abnormal interface states through multitasking. Second, path dependency leads to decreased test efficiency. When interface elements shift positions or change styles due to system updates or device differences, test scripts based on coordinates or fixed IDs will become invalid, requiring re-recording or path adjustments, resulting in high maintenance costs. Third, the single path leads to biased problem localization. For example, issues such as memory leaks, thread conflicts, and compatibility conflicts in edge scenarios may be missed because they are not covered by the preset path, ultimately leading to a significant deviation between compatibility analysis results and real user scenarios, creating the paradox of tests passing but user complaints. In a dynamic, personalized, and intelligent application ecosystem, this testing method is no longer sufficient to meet the needs for accurate identification and in-depth attribution of compatibility issues.

[0082] This application provides a method for detecting application compatibility. By acquiring the application's state relationship network to characterize the jump relationships between its interfaces, and calculating coverage and redundancy to quantify the proportion of effective coverage and redundant parts of the test path to the overall ratio, the method filters the initial test path set derived from the state relationship network based on these indicators, removing redundant paths and retaining high-coverage paths, thereby obtaining a refined target test path set. Based on this, targeted test cases are generated, achieving efficient and accurate evaluation of application compatibility to save testing resources and accelerate the development process.

[0083] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0084] Figure 1 A flowchart illustrating an application compatibility detection method provided in this application embodiment. Figure 1 ,like Figure 1 As shown, the method includes:

[0085] S101. Obtain the application's state relationship network; and determine the coverage and redundancy; wherein, the state relationship network represents the jump relationship between the application's interfaces; the coverage represents the proportion of the effectively covered part of the interface jump relationship in the state relationship network to the whole; the redundancy represents the proportion of the redundant part of the interface jump relationship in the state relationship network to the whole.

[0086] For example, a state relation network is a graph structure used to represent the navigation relationships between application interfaces. In this network, each node represents an interface of the application, and the directed edges between nodes represent the relationship that allows navigation from one interface to another. For instance, in an e-commerce application, the homepage node may be connected to the product list page node via directed edges, and the product list page node may in turn be connected to the product details page node, and so on. These nodes and edges together constitute the state relation network of the e-commerce application.

[0087] Coverage measures the proportion of effectively covered interface transition relationships within a state relationship network. Effectively covered relationships typically refer to those interface relationships that users actually perform transition actions in real-world application scenarios. For example, during application testing, if some interface transition relationships are found in the state relationship network, but users almost never trigger these transitions in actual use, then these relationships do not belong to the effectively covered portion. Higher coverage indicates that the state relationship network more accurately reflects the actual usage of the application.

[0088] Redundancy characterizes the proportion of redundant parts in the interface navigation relationships of a state relationship network. Redundant parts refer to those interface navigation relationships that exist in the state relationship network but do not substantially contribute to the application's functionality or user experience, and may even cause confusion or interference. Examples include unnecessary repeated navigation paths, or special navigation paths that are rarely used in normal operation. Lower redundancy indicates a more concise and efficient state relationship network.

[0089] After selecting appropriate automated testing tools and configuring the testing environment, write test scripts to perform comprehensive traversal testing of the application. The test scripts should cover as many functional modules and interfaces as possible, recording information such as the name of each interface, how to enter that interface, and the target interface to navigate to from that interface.

[0090] If the application has detailed logging capabilities, UI transition information can be extracted directly from the log file. First, the log file needs to be parsed to identify log entries related to UI transitions, and then key information such as the source UI, target UI, and transition time can be extracted.

[0091] Each different interface collected is defined as a node, and each node is assigned a unique identifier, such as the name or number of the interface.

[0092] Based on the collected navigation data, directed edges are added between the corresponding nodes. For example, if there is a record of navigation from interface A to interface B, a directed edge from A to B is added between the node representing interface A and the node representing interface B.

[0093] To view the state relationship network more intuitively, graph visualization tools can be used to visualize the constructed network. By adjusting parameters such as the position, size, and color of nodes, as well as the thickness and color of edges, the network structure can be made clearer and easier to understand.

[0094] Organize relevant personnel, including developers, testers, and product managers, to jointly determine the definition of valid navigation relationships based on the application's actual business logic and user habits. Detailed rules and standards can be established; for example, navigation between certain functional modules may be mandatory, while navigation in some exceptional circumstances may be invalid.

[0095] Based on the defined rules for valid jump relationships, all jump relationships in the state relationship network are filtered, and the number of valid jump relationships is counted.

[0096] The coverage is obtained by dividing the number of valid jump relationships by the total number of jump relationships in the state relationship network. The calculation formula is: Coverage = Number of valid jump relationships / Total number of jump relationships.

[0097] Multiple methods were employed to identify redundant jump relationships. One method was to analyze the frequency of jump relationships; if certain jump relationships appeared very infrequently in the test data, they might be considered redundant. Another method was to compare the functional similarity of different jump paths; if multiple functionally similar jump paths existed, some of them might be redundant. The identified redundant jump relationships were then statistically analyzed to determine their total number.

[0098] The redundancy is calculated by dividing the number of redundant jump relationships by the total number of jump relationships in the state relationship network. The formula is: Redundancy = Number of redundant jump relationships / Total number of jump relationships.

[0099] S102. Based on coverage and redundancy, the test paths in the initial test path set are filtered to obtain the target test path set; test cases are generated based on the test paths in the target test path set; wherein, the initial test path set is determined based on the state relationship network; the initial test path set includes at least one test path; the test path represents the interface jump order of the application; the test cases are used to test whether the compatibility of the application meets the expected results.

[0100] For example, the initial test path set is a set of test paths determined based on the application's state relationship network, where each test path represents the application's interface navigation sequence. For instance, a test path might be "Home -> Product List Page -> Product Details Page -> Shopping Cart Page," which describes the user's journey from entering the application's home page, through the product list page, the product details page, and finally to the shopping cart page, a series of interface navigation steps. The initial test path set must contain at least one such test path for the purpose of preliminary testing of the application's interface navigation functionality.

[0101] The target test path set is a set of test paths obtained by filtering the initial test path set based on coverage and redundancy. It removes redundant test paths from the initial set and retains paths that effectively cover application interface transitions. It is a more streamlined and efficient set of test paths, enabling more precise testing of the application and improving the relevance and effectiveness of the tests.

[0102] Set a coverage threshold, such as 80%. Iterate through each test path in the initial test path set and calculate the coverage of each path for application interface navigation. This can be evaluated by statistically analyzing the proportion of interface navigation relationships contained in that path within the effective navigation relationships in the state relationship network. If the coverage of a test path is below the set threshold, and that path is not a critical path (critical paths can be determined based on the application's business logic, such as the core path in a shopping process), consider removing it from the initial test path set.

[0103] Analyze the initial test path set to identify redundant test paths. This can be determined by comparing the similarity between different test paths. For example, if two test paths have mostly the same interface transition order, differing only in a few interfaces, and these differences have little impact on the test results, then one path can be considered redundant. Set a redundancy threshold; when the similarity between two test paths exceeds this threshold, retain one path and remove the other redundant path. After filtering based on coverage and redundancy, the target test path set is obtained.

[0104] For each test path in the target test path set, start generating the corresponding test cases.

[0105] Based on the interface navigation sequence of the test path, describe in detail the operation steps for each interface. For example, for the test path "Homepage -> Search Page -> Search Results Page", the test steps can be described as follows: Enter keywords in the search box on the homepage, click the search button to enter the search page; view the search results on the search page, click on a search result to enter the search results page.

[0106] Determine appropriate input data for each test step. For example, the keywords entered in the search box can be different types of data, such as common, special, or boundary values, to test the application's compatibility under different input conditions.

[0107] Based on the application's business logic and design requirements, determine the expected results for each test step. For example, after entering keywords and clicking the search button, it is expected that the user should be correctly redirected to the search page and have the relevant search results displayed; after clicking the search result, it is expected that the user should be correctly redirected to the corresponding details page and have the correct information displayed.

[0108] The test steps, input data, and expected results are integrated to form a complete test case, which is then recorded in the test case document.

[0109] S103. In the preset distributed test cluster, execute each test case to obtain the compatibility matrix; based on the compatibility matrix, determine the compatibility score of the application.

[0110] For example, a pre-built distributed test cluster is a pre-configured network system consisting of multiple computers or devices distributed across different geographical locations or network nodes, interconnected and working collaboratively. They jointly undertake testing tasks, simulating various testing environments, such as different operating system versions, hardware configurations, and network conditions. The advantage of a distributed test cluster is that it can utilize the resources of multiple devices to execute tests in parallel, greatly improving testing efficiency, shortening the testing cycle, and more comprehensively covering various possible testing scenarios.

[0111] Ensure the pre-set distributed test cluster has been set up and is running normally. Check whether the nodes in the cluster can communicate normally and whether the network connection is stable.

[0112] Install and configure the required testing environment on each node, including different operating systems, browser versions, device simulators, etc., to ensure that various real-world testing scenarios can be simulated.

[0113] Distribute the previously generated test cases to each node of the distributed test cluster. Automated deployment tools can be used to transfer the test case files to each node, ensuring that the test cases are correctly installed and configured on each node.

[0114] Configure the test execution environment variables and related parameters on each node, such as the storage path of test data and the output location of log files, so that test cases can be executed smoothly and relevant information can be recorded.

[0115] Start the test execution tasks of the distributed test cluster. Test execution commands can be sent to each node through the test management platform or command-line tools, so that each node can start executing the assigned test cases simultaneously.

[0116] During test execution, the progress and status of each node are monitored in real time. Information on test execution can be obtained through log files, monitoring tools, etc., to promptly identify and address potential issues, such as node failures or test case freezes.

[0117] After the test cases are executed, the test results at each node are collected. The test results may include the execution status of the test cases (pass, fail, skip, etc.), the reason for failure, error logs, and other information.

[0118] The collected test results are organized according to the test environment and test cases to generate a compatibility matrix. Spreadsheet software (such as Excel) or a dedicated test management tool can be used to create the compatibility matrix, with the test environment as rows and the test cases as columns. The execution result of each test case in the corresponding test environment is then entered into the matrix.

[0119] Based on the results in the compatibility matrix, determine the algorithm for calculating the compatibility score. For example, a simple algorithm could be used: Compatibility Score = (Number of Passed Test Cases / Total Number of Test Cases) × 100. Alternatively, the algorithm can be optimized by assigning different weights to the test cases based on their importance, making the score more accurately reflect the application's compatibility status.

[0120] The compatibility score of the application is calculated based on the data in the compatibility matrix according to the determined algorithm.

[0121] This application provides a method for detecting application compatibility. It acquires the application's state relationship network and determines coverage and redundancy. The state relationship network represents the jump relationships between interfaces, coverage reflects the proportion of effective interface jumps, and redundancy reflects the proportion of ineffective redundant jumps. By quantifying these two metrics, the initial test path set (generated based on the state relationship network, containing multiple interface jump order paths) can be filtered and optimized, eliminating redundant paths and retaining high-coverage paths to form a target test path set. Test cases are generated based on this and executed in parallel in a distributed test cluster, quickly obtaining a compatibility matrix (reflecting compatibility performance under different devices / systems). Finally, a compatibility score is obtained through matrix quantification. Through accurate modeling of the state relationship network and dynamic balancing of coverage / redundancy, the method solves the problems of redundancy and low efficiency in traditional compatibility testing paths. It ensures comprehensive test coverage while avoiding the waste of ineffective test resources. Furthermore, the parallel execution mechanism of the distributed cluster further improves testing speed. Finally, the quantitative score provides an intuitive evaluation of the compatibility results, offering efficient and reliable detection support for cross-platform application adaptation.

[0122] Figure 2 A flowchart illustrating an application compatibility detection method provided in this application embodiment. Figure 2 ,like Figure 2 As shown, in this embodiment... Figure 1 Based on the embodiments, a method for detecting application compatibility is described in detail, the method comprising:

[0123] S201. Determine the interface state transition matrix based on the interactive element attributes of the application's interface and the application's interface transition states; wherein, the interface state transition matrix represents the probability of transitions between different interfaces of the application; determine the state relationship network based on the interface state transition matrix and the behavior data of the application's historical operation interface.

[0124] For example, the interactive element attributes of an application's interface are the various characteristics of elements on the application's interface that users can interact with. These elements include, but are not limited to, buttons, text boxes, drop-down menus, and links. Their attributes cover multiple aspects, such as the element's position (its location on the screen), size (width and height), type (whether it's a button or a text box, etc.), visibility (whether it's displayed on the interface), clickability (whether it can be clicked by the user), and the feedback effect after the interaction (e.g., whether a button changes color or a pop-up message appears after clicking). Understanding these attributes helps in gaining a deeper understanding of how users interact with the application interface and their possible behavioral patterns.

[0125] Use interface analysis tools to scan and analyze the application's interface. These tools can obtain attribute information such as the position, size, type, and visibility of each interactive element on the interface, and store this information in a database or file.

[0126] Embedding monitoring code within the application records user actions that trigger interface transitions. When a user performs an action (such as clicking a button or submitting a form) that causes a change in the interface, the monitoring code records information such as the current interface identifier, the identifier of the interface after the transition, and the time of the action. These records can be stored in log files for easy analysis and processing later.

[0127] The system analyzes recorded interface transition data to calculate the number of times each interface transitions to other interfaces. For example, it counts the number of times a user transitions from the login interface to the main interface, and the number of times a user transitions from the main interface to the product list interface.

[0128] Based on the statistical count of jumps, calculate the probability of each interface transitioning to another interface. The probability formula is: Probability of a certain interface transitioning to another interface = Number of times that interface transitions to another interface / Total number of jumps for that interface. Fill the calculated probability values ​​into a matrix, where the rows and columns of the matrix represent different interfaces of the application, thus obtaining the interface state transition matrix.

[0129] Each interface of the application is defined as a node, and edges between nodes are defined based on the transition relationships between interfaces in the interface state transition matrix. If the probability of interface A transitioning to interface B is greater than 0, then an edge from node A to node B is added to the state relationship network.

[0130] Based on the jump probability values ​​calculated from the interface state transition matrix, the weights of the edges in the state relationship network are set. The larger the edge weight, the higher the jump probability between the two interfaces.

[0131] Use graphical tools to visualize the state relationship network. Visualization allows for an intuitive observation of the relationships between application interface states and the flow of user actions.

[0132] S202. Determine the initial test path set based on the state relationship network; determine the coverage and redundancy based on the state relationship network and the initial test path set.

[0133] For example, an initial set of test paths is determined based on the state relationship network; coverage and redundancy are determined based on the state relationship network and the initial set of test paths.

[0134] Figure 3This is a flowchart illustrating step S202 of an application compatibility detection method provided in an embodiment of this application; as shown below. Figure 3 As shown, step S202 includes:

[0135] S2021. Based on the state relationship network, determine the set of executable test paths; based on the ratio of the total number of interface jumps to the number of non-jump interfaces in the state relationship, determine the coverage stimulus factor; based on the similarity between the current path and the historical path in the test paths in the set of executable test paths, determine the repetitive operation inhibition factor; based on the coverage stimulus factor and the repetitive operation inhibition factor, filter the test paths in the set of executable test paths to determine the initial test path set.

[0136] For example, the coverage incentive factor is a metric used to measure the extent to which a test path covers software interface transitions. It is determined by calculating the ratio of the total number of interface transitions in a state relationship to the number of interfaces that do not transition, aiming to incentivize test paths to cover as many different interface transitions as possible, thereby improving the comprehensiveness of testing and uncovering more potential software defects.

[0137] The duplicate operation suppression factor measures the similarity between the current path and historical paths in the executable test path set. If the current path and historical paths are too similar, it means that duplicate test operations may exist. The duplicate operation suppression factor suppresses such duplicate tests by evaluating similarity, avoiding waste of test resources and improving test efficiency.

[0138] Based on the characteristics of the state-relationship network and the testing requirements, select an appropriate traversal algorithm, such as depth-first search or breadth-first search. Determine the starting interface state for the test; typically, the software's initial interface is chosen as the starting node.

[0139] Using a selected traversal algorithm, the state relationship network is traversed starting from the initial node, recording the node sequence during the traversal to form a test path. This process is repeated until a sufficient number of test paths are generated, forming an executable test path set. During path generation, constraints can be set, such as the maximum path length and avoiding repeated visits to certain nodes, to control the quality and diversity of the test paths.

[0140] Traverse the state relationship network and count the number of all existing interface transitions. Identify the interface states in the state relationship network that are not involved by any transition relationship and count their number. Divide the total number of interface transitions by the number of interfaces that did not transition to obtain the value of the coverage stimulus factor.

[0141] Based on the characteristics of the test paths, select an appropriate similarity calculation method, such as edit distance or cosine similarity. For each current path in the executable test path set, compare its similarity with previously processed historical paths. Based on the similarity score, calculate the value of the repetition suppression factor according to certain rules. For example, the higher the similarity, the larger the repetition suppression factor, indicating a stronger degree of suppression of repetitive operations.

[0142] Taking into account the impact of coverage incentive factors and repetitive operation inhibition factors, screening rules are established. For example, test paths with higher coverage incentive factors and lower repetitive operation inhibition factors are preferentially selected. Based on the screening rules, test paths in the executable test path set are filtered, and those that meet the criteria are selected to form an initial test path set.

[0143] S2022. Based on the test paths in the initial test path set, execute tests in the preset test environment and determine the operation success rate of each test path; determine the coverage based on the total number of interface jumps in the state relationship network and the operation success rate; determine the redundancy based on the state transition sequence of the test paths in the initial test path set, the number of repeatedly accessed interfaces in the test paths, and the frequency of repeatedly triggered operations in the test paths.

[0144] For example, based on the software's operational requirements, the corresponding hardware and software environment is set up, including installing the necessary operating system, database, middleware, etc., and ensuring a normal network connection. Test paths are selected sequentially from the initial test path set for testing. Following the steps of the test path, operations are performed in a preset test environment, and the execution result of each operation step is recorded, including success or failure and the reason for failure. The number of successfully executed operation steps in the test path is counted, and divided by the total number of operation steps to obtain the operation success rate of that test path.

[0145] Traverse the state relationship network and count the number of all existing interface transitions. Obtain the operation success rate for each test path from the above steps. A weighted average method can be used to calculate the overall coverage based on the number of interface transitions covered by each test path in the state relationship network and the operation success rate. For example, for each test path, calculate the product of its covered interface transitions and operation success rate, then add the products of all test paths, and divide by the total number of interface transitions in the state relationship network to obtain the coverage.

[0146] Analyze the state transition sequence of each test path to check for unreasonable state transitions, such as being unable to transfer to the next interface state according to normal logic from a certain interface state. Traverse the test paths to count the number of interfaces that are repeatedly accessed. Count the number of times each operation in the test path is repeatedly executed, divide it by the total number of operations to obtain the repeated trigger frequency of each operation, and then conduct a comprehensive analysis of the repeated trigger frequencies of all operations. Based on the rationality of the state transition sequence, the number of repeatedly accessed interfaces, and the repeated trigger operation frequency, set corresponding weights, and obtain the redundancy of the test path through weighted calculation. For example, the weight of the rationality of the state transition sequence can be set to 0.4, the weight of the number of repeatedly accessed interfaces to 0.3, and the weight of the repeated trigger operation frequency to 0.3, and then perform a weighted sum according to the scores of each indicator to obtain the redundancy.

[0147] S203. Determine the comprehensive evaluation value of the test paths in the initial test path set according to the coverage and redundancy; if it is determined that the comprehensive evaluation value of the test path is greater than or equal to the preset threshold, determine the corresponding test path as the test path in the target test path set.

[0148] Exemplarily, extract the coverage and redundancy values of each test path from the above steps. Ensure the accuracy and integrity of these data because they are the basis for calculating the comprehensive evaluation value.

[0149] Select a suitable calculation method to combine the coverage and redundancy into an evaluation value. Common methods include the weighted average method, the multiplication combination method, etc. For example, when using the weighted average method, it is necessary to first determine the weights of the coverage and redundancy. Assume the weight of the coverage is w1 and the weight of the redundancy is w2, and w1 + w2 = 1. The magnitudes of the weights can be adjusted according to their importance to the test quality.

[0150] For each test path, calculate its comprehensive evaluation value according to the selected calculation method and the determined weights. If the weighted average method is used, the comprehensive evaluation value V = w1×C + w2×R, where C is the coverage and R is the redundancy.

[0151] Set a suitable preset threshold T according to the specific requirements and objectives of the software test. This threshold should be able to screen out high-quality test paths that meet the test requirements and avoid including too many test paths in the target set.

[0152] Compare the comprehensive evaluation value V of each test path with the preset threshold T. If V≥T, determine the test path as the test path in the target test path set; if V<T, exclude the test path.

[0153] Combine all the test paths that meet the conditions to form the target test path set for subsequent software test work.

[0154] Optionally, if the similarity of the operation instruction sequences of two test paths in the initial test path set exceeds a preset similarity threshold, the test path with the higher comprehensive evaluation value is retained, and the test path with the lower comprehensive evaluation value is removed.

[0155] S204. Generate test cases based on the test paths in the target test path set.

[0156] For example, this step can refer to step S102 above, and will not be repeated here.

[0157] S205. In the preset distributed test cluster, execute each test case to obtain the execution data corresponding to the test case; wherein, the execution data represents the relevant information data of the application generated during the execution of the test case; aggregate the execution data to obtain the compatibility matrix.

[0158] For example, select appropriate hardware and network environment to build a distributed test cluster. Ensure that all nodes in the cluster can communicate normally and have sufficient computing resources and storage space to support the execution of test tasks. Install and configure the software environment required for testing on each node, including the operating system, testing tools, application dependencies, etc. Ensure that the software environment of all nodes is consistent to guarantee the accuracy and comparability of test results.

[0159] Design a comprehensive series of test cases based on the application's functionality and characteristics, as well as the target testing environment (such as different operating systems, device models, browser versions, etc.). Test cases should cover the application's main functions and common use cases to ensure adequate testing of application compatibility. Define clear inputs, execution conditions, and expected results for each test case to facilitate accurate verification and judgment during testing. Understandably, test cases include sequences of operation instructions, expected sequence of interface state transitions, and corresponding environmental parameter configuration information.

[0160] The designed test cases are distributed across the nodes of the distributed test cluster. Task scheduling algorithms can be used to allocate test tasks rationally based on node load and test case resource requirements, achieving load balancing and improving testing efficiency. Each node starts the application and executes tests in the designated test environment according to the assigned test cases. During execution, execution data generated by the application, such as runtime logs, performance metrics, and error messages, are collected in real time. Data collection can be achieved by embedding monitoring code in the application or using dedicated monitoring tools. Execution data includes the actual interface state transition paths and their deviations from the expected paths, the standard deviation of response time across device environments, peak resource utilization, and the frequency of triggered exception events.

[0161] The collected execution data is transmitted to a central data processing node or aggregated using a distributed data processing framework. The execution data is cleaned and preprocessed to remove invalid and duplicate data, ensuring data quality and accuracy. Based on the testing objectives and analytical needs, the data is categorized, statistically analyzed, and calculated. For example, this includes calculating the application's average response time, maximum response time, and error rate across different operating system versions; and statistically analyzing the types and number of compatibility issues occurring on different device models.

[0162] Based on the results of the aggregation processing, the structure of the compatibility matrix is ​​designed. Typically, rows in the compatibility matrix represent different test environment factors (such as operating system version), and columns represent other test environment factors (such as device model). Each cell in the matrix records the application's compatibility status under that specific environment combination. The compatibility matrix is ​​populated based on the statistical data and analysis results obtained from the aggregation processing. For each environment combination, its compatibility status (such as compatible, incompatible, partially compatible, etc.) is determined based on the application's actual performance, and the corresponding information is entered into the matrix. The generated compatibility matrix is ​​reviewed and verified to ensure the accuracy of the information within it. The quality of the matrix can be ensured by comparing it with actual test results or by having relevant personnel review it. Understandably, the compatibility matrix includes interface state coverage, operation success rate, and abnormal event occurrence rate.

[0163] S206. Determine the application's compatibility score based on the compatibility matrix.

[0164] For example, by comparing the compatibility matrices of multiple target applications, abnormal applications that deviate from the group behavior are identified, and conflicting operation instructions in the execution trajectory of the test cases corresponding to the abnormal applications are extracted. Based on the execution differences of conflicting operation instructions in different applications, combined with the device type, operating system version and hardware configuration information of the abnormal applications, the environmental characteristic factors of compatibility defects are located, and a feature profile of compatibility defects is generated. Then, based on the feature profile, compatibility repair suggestions are generated.

[0165] The interface state coverage, operation success rate, and abnormal event occurrence rate are extracted from the compatibility matrix as compatibility indicators. Each compatibility indicator is compared with its corresponding standard compatibility indicator, and the deviation value of each compatibility indicator is output. The deviation values ​​of each compatibility indicator are combined and calculated to output the compatibility score of each test case.

[0166] S207. If the compatibility score of the application is determined to be less than the preset score value, then the application is determined to be the target application; based on the compatibility score, the coverage incentive factor and the repetitive operation inhibition factor are corrected to obtain the corrected coverage incentive factor and the corrected repetitive operation inhibition factor; based on the corrected coverage incentive factor and the corrected repetitive operation inhibition factor, the test paths in the target test path set of the target application are adjusted.

[0167] For example, a comprehensive set of compatibility test cases is designed and executed, covering various environmental combinations such as different operating system versions, device models, and browsers. The execution results of each test case are collected, including information such as whether the functionality is normal, performance metrics (e.g., response time, resource utilization), and whether errors or anomalies occur. Based on pre-defined scoring rules and algorithms, the collected test results are comprehensively and quantitatively evaluated to calculate the application's compatibility score. The scoring rules may consider factors such as functional completeness (e.g., the proportion of passed test cases to the total number of test cases), performance (e.g., whether the average response time is within a reasonable range), and stability (e.g., the frequency of errors).

[0168] The calculated compatibility score is compared with a preset score. If the compatibility score is lower than the preset score, the application is identified as the target application and proceeds to the next step; otherwise, the application is considered to meet the compatibility standard and no further adjustments are required.

[0169] Analyze the characteristics of compatibility issues in the target application, such as whether the problems lie in specific functional modules or whether overall performance fluctuates significantly under different environments. Based on the analysis results, formulate adjustment strategies for the coverage incentive factor and the repetitive operation inhibition factor. If certain functional modules are found to have significant compatibility issues, the coverage incentive factor can be appropriately increased to encourage test paths to cover more of these modules. If many repetitive operations occur during testing without discovering new problems, the repetitive operation inhibition factor can be increased to reduce the occurrence of repetitive operations. Based on the adjustment strategy, the initial coverage incentive factor and repetitive operation inhibition factor are numerically adjusted to obtain the revised coverage incentive factor and revised repetitive operation inhibition factor.

[0170] Obtain the target test path set for the target application. This set is typically pre-generated during the test planning phase and contains a series of possible test paths. Recalculate the weight of each test path using the revised coverage incentive factor and repetitive operation inhibition factor. When calculating the weight, consider factors such as the number of functional modules covered by the test path, the coverage of key functions, and the number of repetitive operations, combining these with the revised factors for a comprehensive calculation. Based on the calculated weights, sort the test paths and prioritize executing those with higher weights. For test paths with lower weights and many repetitive operations or non-critical coverage, optimize them, such as removing some repetitive operations, adding operations for uncovered key functions, etc.; or directly replace them with new test paths to ensure that the test path set can more effectively detect compatibility issues in the target application.

[0171] In one possible implementation, the compatibility score is compared with a preset score value to identify applications below a threshold as target applications with compatibility risks; the compatibility indicators of the target applications are recorded as risk indicators, and the risk indicators are mapped back to the corresponding test cases to locate the corresponding operation instruction sequences as risk sequences.

[0172] The response time and resource utilization rate of the risk sequence are collected and fed back to the reward mechanism to form a correction factor. The coverage incentive factor and the repeated operation inhibition factor are adjusted according to the correction factor.

[0173] Based on the adjusted coverage incentive factor and repeated operation inhibition factor, the priority weight of each operation path is recalculated, and the target test path is adjusted according to the recalculated priority weight. Then, based on the adjusted target test path, the compatibility test is re-executed.

[0174] This application provides a method for testing application compatibility. It constructs a state transition matrix based on the attributes of interactive elements and their transition states. This matrix quantifies the probability of transitions between interfaces and, combined with historical operation data, forms a state relationship network to ensure that generated paths conform to actual user usage patterns. Through quantitative analysis of coverage (the proportion of effective paths) and redundancy (the proportion of duplicate and invalid paths), combined with a comprehensive evaluation threshold, low-value paths are eliminated, retaining high-coverage, low-redundancy, high-quality test paths to form a target test path set. Test cases generated based on this set are executed in parallel by a distributed cluster, rapidly aggregating execution data to generate a compatibility matrix and ultimately quantifying a compatibility score. If the score is below the threshold, the test path is dynamically adjusted by modifying the coverage incentive factor and the duplicate operation inhibition factor, forming a closed-loop optimization mechanism. Through precise modeling of the state network, dynamic balancing of coverage redundancy, and parallel acceleration of distributed execution, the method solves the problems of redundancy and low efficiency in traditional test paths, achieving high efficiency, accuracy, and adaptive optimization in compatibility testing, providing reliable technical support for cross-platform application adaptation.

[0175] Figure 4 A schematic diagram of the structure of an application compatibility detection device provided in this application embodiment. Figure 1 ,like Figure 4 As shown, the application compatibility detection device 40 provided in this embodiment includes:

[0176] The acquisition module 401 is used to acquire the state relationship network of the application and determine the coverage and redundancy. The state relationship network represents the jump relationship between the interfaces of the application; the coverage represents the proportion of the effectively covered part of the interface jump relationship in the state relationship network to the whole; and the redundancy represents the proportion of the redundant part of the interface jump relationship in the state relationship network to the whole.

[0177] The generation module 402 is used to filter the test paths in the initial test path set according to coverage and redundancy to obtain the target test path set; and to generate test cases based on the test paths in the target test path set. The initial test path set is determined according to the state relationship network; the initial test path set includes at least one test path; the test path represents the interface jump order of the application; and the test cases are used to test whether the compatibility of the application meets the expected results.

[0178] The execution module 403 is used to execute each test case in a preset distributed test cluster to obtain a compatibility matrix; and to determine the compatibility score of the application based on the compatibility matrix.

[0179] This embodiment provides an application compatibility detection device that can execute the methods provided in the above-described method embodiments. Its implementation principle and technical effects are similar, and will not be described in detail here.

[0180] Figure 5 A schematic diagram of the structure of an application compatibility detection device provided in this application embodiment. Figure 2 ,like Figure 5 As shown, the application compatibility detection device 50 provided in this embodiment includes:

[0181] The acquisition module 501 is used to acquire the state relationship network of the application and determine the coverage and redundancy. The state relationship network represents the jump relationship between the interfaces of the application; the coverage represents the proportion of the effectively covered part of the interface jump relationship in the state relationship network to the whole; and the redundancy represents the proportion of the redundant part of the interface jump relationship in the state relationship network to the whole.

[0182] The generation module 502 is used to filter the test paths in the initial test path set according to coverage and redundancy to obtain the target test path set; and to generate test cases based on the test paths in the target test path set. The initial test path set is determined according to the state relationship network; the initial test path set includes at least one test path; the test path represents the interface jump order of the application; and the test cases are used to test whether the compatibility of the application meets the expected results.

[0183] The execution module 503 is used to execute each test case in a preset distributed test cluster to obtain a compatibility matrix; and to determine the compatibility score of the application based on the compatibility matrix.

[0184] In one possible implementation, the acquisition module 501 includes:

[0185] The first determining module 5011 is used to determine the initial test path set based on the state relationship network;

[0186] The second determination module 5012 is used to determine coverage and redundancy based on the state relationship network and the initial test path set.

[0187] In one possible implementation, the first determining module 5011 includes:

[0188] Based on the state relationship network, determine the set of executable test paths;

[0189] The coverage stimulus factor is determined based on the ratio of the total number of interface transitions to the number of interfaces that do not transition in the state relationship.

[0190] The repetitive operation inhibition factor is determined based on the similarity between the current path and historical paths in the set of executable test paths.

[0191] Based on the coverage incentive factor and the repetitive operation inhibition factor, the test paths in the executable test path set are filtered to determine the initial test path set.

[0192] In one possible implementation, the second determining module 5012 includes:

[0193] Based on the test paths in the initial test path set, execute tests in a preset test environment to determine the success rate of each test path.

[0194] The coverage is determined based on the total number of interface transitions and the operation success rate in the state relationship network;

[0195] Redundancy is determined based on the state transition sequence of the test paths in the initial test path set, the number of repeatedly accessed interfaces in the test paths, and the frequency of repeatedly triggered operations in the test paths.

[0196] In one possible implementation, the generation module 502 includes:

[0197] Based on coverage and redundancy, determine the comprehensive evaluation value of the test paths in the initial test path set;

[0198] If the overall evaluation value of a test path is greater than or equal to a preset threshold, then the corresponding test path is determined to be the test path set in the target test path set.

[0199] In one possible implementation, the execution module 5035 includes:

[0200] In a pre-defined distributed test cluster, each test case is executed to obtain the execution data corresponding to the test cases; the execution data represents the relevant information data of the application generated during the execution of the test cases.

[0201] The execution data is aggregated to obtain a compatibility matrix.

[0202] In one possible implementation, the device 50 further includes:

[0203] The correction module 504 is used to determine the application as the target application if the application's compatibility score is determined to be less than a preset score value.

[0204] Based on the compatibility score, the coverage activation factor and the repetitive operation inhibition factor are modified to obtain the modified coverage activation factor and the modified repetitive operation inhibition factor.

[0205] Based on the modified coverage incentive factor and the modified repetitive operation inhibition factor, the test paths in the target test path set of the target application are adjusted.

[0206] In one possible implementation, the acquisition module 501 includes:

[0207] The interface state transition matrix is ​​determined based on the interactive element attributes of the application's interface and the application's interface transition states; whereby the interface state transition matrix represents the probability of transitions between different interfaces of the application.

[0208] Based on the interface state transition matrix and the historical operation data of the application interface, a state relationship network is determined.

[0209] This embodiment provides an application compatibility detection device that can execute the methods provided in the above-described method embodiments. Its implementation principle and technical effects are similar, and will not be described in detail here.

[0210] Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0211] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0212] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0213] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0214] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0215] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0216] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0217] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0218] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0219] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0220] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0221] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0222] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0223] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0224] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0225] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for detecting application compatibility, characterized in that, include: Obtain the application's state relationship network; And determine coverage and redundancy; wherein, the state relationship network represents the jump relationship between the application's interfaces; the coverage represents the proportion of the effectively covered part of the interface jump relationship in the state relationship network to the whole; the redundancy represents the proportion of the redundant part of the interface jump relationship in the state relationship network to the whole. Based on the coverage and redundancy, the test paths in the initial test path set are filtered to obtain a target test path set; test cases are generated based on the test paths in the target test path set; wherein, the initial test path set is determined based on the state relationship network; the initial test path set includes at least one test path; the test path represents the interface jump order of the application; the test cases are used to test whether the compatibility of the application meets the expected results; In a pre-defined distributed test cluster, each test case is executed to obtain a compatibility matrix; based on the compatibility matrix, the compatibility score of the application is determined.

2. The method according to claim 1, characterized in that, The determination of coverage and redundancy includes: The initial test path set is determined based on the state relationship network; The coverage and redundancy are determined based on the state relationship network and the initial test path set.

3. The method according to claim 2, characterized in that, Based on the state relationship network, the initial test path set is determined, including: Based on the state relationship network, determine the set of executable test paths; The coverage excitation factor is determined based on the ratio of the total number of interface transitions to the number of interfaces that do not transition in the state relationship. The repetitive operation inhibition factor is determined based on the similarity between the current path and the historical path in the set of executable test paths. Based on the coverage incentive factor and the repetitive operation inhibition factor, the test paths in the executable test path set are filtered to determine the initial test path set.

4. The method according to claim 2, characterized in that, Based on the state relationship network and the initial test path set, the coverage and redundancy are determined, including: Based on the test paths in the initial test path set, perform tests in a preset test environment to determine the success rate of each test path. The coverage is determined based on the total number of interface transitions in the state relationship network and the operation success rate; The redundancy is determined based on the state transition sequence of the test paths in the initial test path set, the number of repeatedly accessed interfaces of the test paths, and the frequency of repeatedly triggered operations in the test paths.

5. The method according to claim 1, characterized in that, Based on the coverage and redundancy, the test paths in the initial test path set are filtered to obtain the target test path set, including: Based on the coverage and the redundancy, determine the comprehensive evaluation value of the test paths in the initial test path set; If the comprehensive evaluation value of the test path is determined to be greater than or equal to a preset threshold, then the corresponding test path is determined to be the test path set in the target test path set.

6. The method according to claim 1, characterized in that, In a pre-defined distributed test cluster, each test case is executed to obtain a compatibility matrix, including: In the preset distributed test cluster, each test case is executed to obtain the execution data corresponding to the test case; wherein, the execution data represents the relevant information data of the application generated during the execution of the test cases; The execution data is aggregated to obtain a compatibility matrix.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: If the compatibility score of the application is determined to be less than the preset score value, then the application is determined to be the target application; Based on the compatibility score, the coverage activation factor and the repetitive operation inhibition factor are modified to obtain the modified coverage activation factor and the modified repetitive operation inhibition factor. Based on the modified coverage incentive factor and the modified repetitive operation suppression factor, the test paths in the target test path set of the target application are adjusted.

8. The method according to any one of claims 1-6, characterized in that, Obtain the application's state relationship network, including: Based on the interactive element attributes of the application's interface and the application's interface transition states, a state transition matrix is ​​determined; wherein, the state transition matrix represents the probability of transitions between different interfaces of the application. A state relationship network is determined based on the interface state transition matrix and the behavior data of the application's historical operation interface.

9. An application compatibility detection device, characterized in that, include: The acquisition module is used to acquire the application's state relationship network; And determine coverage and redundancy; wherein, the state relationship network represents the jump relationship between the application's interfaces; the coverage represents the proportion of the effectively covered part of the interface jump relationship in the state relationship network to the whole; the redundancy represents the proportion of the redundant part of the interface jump relationship in the state relationship network to the whole. A generation module is used to filter test paths in an initial test path set according to the coverage and redundancy to obtain a target test path set; and to generate test cases based on the test paths in the target test path set; wherein, the initial test path set is determined according to the state relationship network; the initial test path set includes at least one test path; the test path represents the interface jump order of the application; and the test cases are used to test whether the compatibility of the application meets the expected results. The execution module is used to execute various test cases in a preset distributed test cluster to obtain a compatibility matrix; and to determine the compatibility score of the application based on the compatibility matrix.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

Images