Scene automatic testing method and device of software, electronic equipment and storage medium

Abstract

This application provides a method, apparatus, electronic device, and storage medium for automated scenario testing of software. The method includes: acquiring behavioral data of the software and generating a scenario link model based on the behavioral data, wherein the scenario link model includes multiple scenarios; performing scenario traversal based on the scenario link model and a target traversal pattern to generate a test execution path for the software, wherein the target traversal pattern is determined according to the test execution path and a preset test strategy; testing test cases based on the test execution path and the preset test strategy to obtain test execution results for the software; and generating a test result report in response to the test execution results meeting preset test termination conditions. This achieves fully automated testing from data acquisition to report generation, significantly improving testing efficiency. Simultaneously, it ensures clear and traceable relationships between test cases, providing a structured data foundation for subsequent dynamic optimization.

Description

Technical Field

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

[0002] With the increasing complexity of software system functions, especially the rapid development of in-vehicle software, mobile applications, operating systems, and other fields, the number of functional modules within the software is increasing and the interaction between modules is becoming increasingly complex.

[0003] The following technical problems exist in related technologies: First, scenario coverage is incomplete and strategies are rigid. Existing methods mostly adopt a single, fixed depth-first or breadth-first strategy. The depth-first strategy is prone to missing some scenario nodes, while the breadth-first strategy is difficult to deeply explore key scenarios, resulting in an imbalance between the depth and breadth of scenario coverage. Second, problem link testing lacks specificity. Existing methods use a uniform test frequency and test case configuration for all scenario links, failing to identify high-problem links for focused testing. This leads to a significant waste of testing resources on links with no or few problems, while the testing intensity of key problem links is insufficient, resulting in low problem discovery efficiency. Third, the level of testing intelligence is low and it relies on manual intervention. Existing methods require testers to manually adjust test strategies and supplement test cases to address problem links discovered during testing. They cannot achieve automatic strategy optimization and intelligent expansion of test cases. Testing efficiency is limited by human experience and is difficult to adapt to the rapid iteration requirements of software. Summary of the Invention

[0004] This application aims to at least partially address one of the technical problems in the related art.

[0005] Therefore, the first objective of this application is to propose a scenario-based automated testing method for software, which achieves fully automated testing from data acquisition to report generation. Scenario modeling, path generation, test execution, and result determination can be completed without manual intervention, significantly improving testing efficiency. Simultaneously, the data organization method centered on a scenario link model ensures clear and traceable relationships between test cases, providing a structured data foundation for subsequent dynamic strategy adjustments.

[0006] The second objective of this application is to propose a software scenario-automated testing device.

[0007] The third objective of this application is to propose an electronic device.

[0008] The fourth objective of this application is to provide a computer-readable storage medium.

[0009] To achieve the above objectives, the first aspect of this application proposes a method for automated scenario testing of software, comprising: acquiring behavioral data of the software and generating a scenario link model based on the behavioral data, wherein the scenario link model includes multiple scenarios; performing scenario traversal based on the scenario link model and a target traversal pattern to generate a test execution path for the software, wherein the target traversal pattern is determined according to the test execution path and a preset test strategy; testing test cases based on the test execution path and the preset test strategy to obtain test execution results for the software; and generating a test result report in response to the test execution results meeting a preset test termination condition.

[0010] In addition, the scene automation testing method for software according to the above embodiments of this application may also have the following additional technical features: According to one embodiment of this application, the target traversal pattern is determined based on the test execution path and the preset test strategy, including: obtaining the preset traversal pattern; testing test cases based on the test execution path and the preset test strategy to generate test performance results of the software; adjusting the preset traversal pattern based on the test performance results to obtain the target traversal pattern in response to the test performance results meeting the preset adjustment conditions; and using the preset traversal pattern as the target traversal pattern in response to the test performance results not meeting the preset adjustment conditions.

[0011] According to one embodiment of this application, scene traversal includes a first traversal stage, a second traversal stage, and a third traversal stage. Obtaining a preset traversal mode includes: adopting a breadth-first search mode as the preset traversal mode in response to the scene traversal being in the first traversal stage; adopting a depth-first search mode as the preset traversal mode in response to the scene traversal being in the second traversal stage; and adopting a mixed-weighted search mode as the preset traversal mode in response to the scene traversal being in the third traversal stage.

[0012] According to one embodiment of this application, the scenario link model further includes scenario relationship data. The process of traversing test cases based on the scenario link model and the target traversal pattern to generate test execution paths for the software includes: constructing a test case matrix based on the scenario relationship data and test cases; traversing the test case matrix based on the target traversal pattern to generate a test path set; and filtering the test path set based on a preset filtering method to determine the test execution path.

[0013] According to one embodiment of this application, testing test cases based on test execution paths and preset test strategies to generate test performance results includes: obtaining the current test results of the test execution path; and analyzing the current test results based on a preset performance analysis mechanism to generate test performance results.

[0014] According to one embodiment of this application, the test performance result includes the problem discovery density, wherein adjusting the preset traversal mode based on the test performance result includes: shortening the first traversal stage in response to the problem discovery density being higher than a preset density threshold; and extending the first traversal stage in response to the problem discovery density being lower than a preset density threshold.

[0015] According to one embodiment of this application, the software scenario automated testing method further includes: in response to the test execution result not meeting the preset test termination condition, modifying the preset test strategy and scenario link model; performing scenario traversal based on the modified scenario link model and target traversal mode to generate the software test execution path, and testing the test cases based on the regenerated test execution path and the modified preset test strategy to obtain the software test execution result, until the re-obtained test execution result meets the preset test termination condition.

[0016] To achieve the above objectives, a second aspect of this application proposes a software scenario automated testing device, comprising: a modeling module for acquiring software behavior data and generating a scenario link model based on the behavior data, wherein the scenario link model includes multiple scenarios; a path generation module for performing scenario traversal based on the scenario link model and a target traversal pattern to generate a test execution path for the software, wherein the target traversal pattern is determined according to the test execution path and a preset test strategy; a test execution module for testing test cases based on the test execution path and the preset test strategy to obtain the test execution result of the software; and a report generation module for generating a test result report in response to the test execution result meeting a preset test termination condition.

[0017] The software scenario automation testing device of this application implements the aforementioned software scenario automation testing method. It achieves fully automated testing from data acquisition to report generation, completing scenario modeling, path generation, test execution, and result judgment without manual intervention, significantly improving testing efficiency. Simultaneously, the data organization method centered on the scenario link model ensures clear and traceable relationships between test cases, providing a structured data foundation for subsequent dynamic strategy adjustments.

[0018] To achieve the above objectives, a third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the aforementioned software scene automation testing method.

[0019] According to the electronic device of this application, the processor executes a computer program stored in the memory to implement the aforementioned software scenario-based automated testing method. This achieves fully automated testing from data acquisition to report generation, completing scenario modeling, path generation, test execution, and result determination without manual intervention, significantly improving testing efficiency. Simultaneously, the data organization method centered on the scenario link model ensures clear and traceable relationships between test cases, providing a structured data foundation for subsequent dynamic strategy adjustments.

[0020] To achieve the above objectives, a fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the aforementioned software scene automation testing method.

[0021] According to the computer-readable storage medium of this application, an automated scenario testing method for software stored thereon is implemented. This method achieves fully automated testing from data acquisition to report generation, completing scenario modeling, path generation, test execution, and result determination without manual intervention, significantly improving testing efficiency. Simultaneously, the data organization method centered on a scenario link model ensures clear and traceable relationships between test cases, providing a structured data foundation for subsequent dynamic strategy adjustments. Attached Figure Description

[0022] Figure 1 This is a flowchart of a scenario-based automated testing method for software according to some embodiments of this application; Figure 2 This is a block diagram of a scene-automated testing apparatus for software according to some embodiments of this application; Figure 3 This is a block diagram of an electronic device according to some embodiments of this application. Detailed Implementation

[0023] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0024] The following describes in detail, with reference to the accompanying drawings, the software scenario automation testing method, apparatus, electronic device, and storage medium of the present application embodiments.

[0025] Figure 1 This is a flowchart illustrating a scenario-based automated testing method for software according to some embodiments of this application. (Refer to...) Figure 1 Automated testing methods for software applied to vehicles may include: S1. Acquire the software's behavioral data and generate a scenario link model based on the behavioral data. The scenario link model includes multiple scenarios.

[0026] Behavioral data in software refers to the collective information generated by the target software during its functional definition and actual use. This data may include functional specifications and state transition rules recorded in the software functional requirements document, as well as operation sequences and usage habits recorded in the user interaction flow. Behavioral data can be obtained from requirements specifications and design documents generated during the software development phase, or from user operation logs, embedded data, or historical test records collected during the software operation phase. The specific source and format of the behavioral data are determined by technical personnel based on the actual situation of the software under test and are not specifically limited.

[0027] The scenario link model is a data structure used to organize and manage software testing scenarios. This model describes the transition relationships between various functional states in the software in the form of a weighted directed graph. Nodes in the graph represent reachable functional or interface states, and directed edges represent legal transitions from one state to another and the operation instructions that trigger these transitions. The scenario link model supports assigning weights to nodes and edges, and these weights can be calculated and dynamically updated based on functional importance, user frequency, or historical issue popularity. Furthermore, the scenario link model includes multiple scenarios.

[0028] This embodiment can transform scattered software functional requirements and user behavior data into a structured scenario link model, using scenarios as the basic unit to describe the functional states of the software and the transition relationships between states, providing a unified data foundation for the dynamic adjustment of subsequent testing strategies and path generation.

[0029] S2, based on the scenario link model and target traversal mode, performs scenario traversal to generate the test execution path of the software. The target traversal mode is determined according to the test execution path and the preset test strategy.

[0030] The test execution path can refer to one or more node sequences generated from the scenario link model. Each sequence represents the order in which scenario nodes need to be visited during a test execution. The length, complexity, and priority of the test execution path are determined by the path generation unit based on the target traversal pattern and the weight information in the scenario link model. Different test execution paths may share nodes or have parallel relationships.

[0031] A pre-defined test strategy refers to a set of rules that are pre-set to guide resource allocation and behavioral decisions during test execution. This strategy is set by technical personnel before test initiation based on test objectives, software characteristics, and resource constraints, and can be dynamically adjusted during testing based on test performance results. Specific content is not limited. A pre-defined test strategy may include, but is not limited to, the following: test case execution priority rules, used to determine the execution order of multiple test execution paths; test frequency allocation rules, used to determine the number of times each test execution path is repeatedly executed in a single test round; test case dimension expansion rules, used to determine which boundary scenarios or abnormal scenarios to add to the link when the link's problem heat value exceeds a pre-defined threshold; and resource usage control rules, used to determine how to adjust the length or complexity of the test execution path when resource usage exceeds a pre-defined threshold. The parameters and thresholds in the pre-defined test strategy are pre-set by technical personnel based on the actual situation and quality requirements of the software under test; specific values ​​are not limited.

[0032] To provide a detailed description of the target traversal pattern, in some embodiments of this application, the target traversal pattern is determined based on the test execution path and a preset test strategy, including: obtaining a preset traversal pattern; testing test cases based on the test execution path and the preset test strategy to generate software test performance results; adjusting the preset traversal pattern based on the test performance results in response to the test performance results meeting preset adjustment conditions to obtain a target traversal pattern; and using the preset traversal pattern as the target traversal pattern in response to the test performance results not meeting the preset adjustment conditions.

[0033] The preset traversal mode refers to a pre-defined strategy template used to guide scenario traversal behavior. This mode is set by technical personnel before the test starts based on the test objectives and software characteristics, and can be dynamically adjusted during the test based on performance results. The specific setting value is not limited.

[0034] In some embodiments of this application, scene traversal includes a first traversal stage, a second traversal stage, and a third traversal stage. Obtaining a preset traversal mode includes: adopting a breadth-first search mode as the preset traversal mode in response to the scene traversal being in the first traversal stage; adopting a depth-first search mode as the preset traversal mode in response to the scene traversal being in the second traversal stage; and adopting a mixed weighted search mode as the preset traversal mode in response to the scene traversal being in the third traversal stage.

[0035] The first traversal phase refers to the initial traversal phase after the test starts, corresponding to the process of increasing scene coverage from 0% to a first preset threshold. The core objective of this phase is to quickly cover as many scene nodes as possible, avoiding omission of low-priority but necessary scenes.

[0036] The second traversal phase can refer to the mid-stage traversal phase during testing, corresponding to the process of scenario coverage increasing from the first preset threshold to the second preset threshold. The core objective of this phase is to focus on in-depth analysis of links with high importance or identified issues.

[0037] The third traversal phase refers to the final traversal phase of testing, corresponding to the process of increasing scenario coverage from the second preset threshold to the target coverage. The core objective of this phase is to optimize testing efficiency with limited resources, focusing on testing important and problematic links, and quickly concluding testing on links without issues.

[0038] The first and second preset thresholds are preset by technicians based on test resources and quality requirements. For example, the first preset threshold can be set to 30% and the second preset threshold can be set to 80%, with no specific value limit.

[0039] Specifically, in response to the scene traversal being in the first traversal phase, breadth-first search is used as the default traversal mode.

[0040] The breadth-first search (BFS) mode starts from the starting node and traverses all adjacent nodes of the current node in descending order of node association weights. It completes the traversal of all nodes at the current level before moving to the next level. This mode prioritizes ensuring the breadth of scene coverage, guaranteeing that each scene node is visited at least once.

[0041] In response to the scene traversal being in the second traversal phase, a depth-first traversal mode is used as the default traversal mode.

[0042] The depth-first traversal mode starts from the initial node and traverses as deeply as possible along a path until it can no longer proceed. Then, it backtracks to the previous branch point and selects the next path to continue. This mode prioritizes links with high importance or identified problems for multiple rounds of depth-first traversal, and the path branch selection logic can be adjusted in each round.

[0043] In response to the scene traversal being in the third traversal phase, a mixed weighted mode is used as the preset traversal mode.

[0044] The hybrid weighted mode refers to a traversal method that dynamically allocates the proportion of depth-first and breadth-first strategies based on a weight calculation formula. This mode calculates a depth-first strategy weight value for each scene node or link. When the depth-first strategy weight is greater than a preset threshold, the depth-first strategy is used; otherwise, the breadth-first strategy is used. The depth-first strategy weight is calculated by weighting the scene node's importance weight and the link's problem popularity value. The formula is: depth-first strategy weight = importance weight coefficient multiplied by scene node importance weight plus problem popularity coefficient multiplied by link problem popularity value. The importance weight coefficient and problem popularity coefficient are preset by technical personnel according to the testing stage and quality requirements, and can be dynamically adjusted based on test performance results; their specific values ​​are not limited.

[0045] As a specific embodiment of this example, the application of the three traversal modes is explained using a scenario test of an in-vehicle autonomous driving system as an example.

[0046] Assume the scenario link model contains the following scenario nodes: Node A is "Start Autonomous Driving", Node B is "Emergency Braking Trigger", Node C is "Navigation and Positioning", Node D is "Lane Keeping", Node E is "Music Playback", and Node F is "Air Conditioning Adjustment". Nodes B ("Emergency Braking Trigger") and C ("Navigation and Positioning") are labeled as Level A functional nodes, and Node E ("Music Playback") is labeled as a Level D functional node. The transformation relationships and initial weights between nodes have been pre-defined.

[0047] In the first traversal phase, scene coverage increased from 0% to 30%. A breadth-first search approach was adopted at this stage. The test began with node A, "Start Autonomous Driving," and the breadth-first strategy traversed all adjacent nodes of node A in descending order of node association weight. Nodes with higher weights, such as node B, "Emergency Braking Trigger," and node C, "Navigation and Positioning," were traversed first, followed by nodes with lower weights, such as node E, "Music Playback," and node F, "Air Conditioning Adjustment." After traversing the adjacent nodes of node A, the test proceeded to the next level, traversing the adjacent nodes of node B, node C, and so on. Through this approach, the test device quickly covered all core and auxiliary functions of the autonomous driving system in the early stages of testing, including both Level A and Level D functional nodes, ensuring that no necessary scene nodes were missed, achieving the goal of "full coverage without omissions."

[0048] In the second traversal phase, the scene coverage increased from 30% to 80%. At this point, the depth-first mode was switched. Assume that in the previous test, a problem was found where navigation and positioning were lost after emergency braking was triggered on the link from node A ("Start Autopilot") through node B ("Emergency Braking Triggered") to node C ("Navigation and Positioning"). Both nodes B and C are Class A functional nodes, indicating high importance. The depth-mining mode starts from node A ("Start Autopilot") and prioritizes the path through node B ("Emergency Braking Triggered") to node C ("Navigation and Positioning") for depth traversal. The test device performs multiple rounds of traversal on this path: the first round follows standard conditions, i.e., emergency braking is triggered while the vehicle is driving normally; the second round adjusts the path branch selection logic to simulate a weak GPS signal environment during emergency braking; the third round further adjusts the logic to simulate navigation voice prompts after emergency braking. Each round of traversal delves into potential problems hidden within this complex link. For other links where no issues were found, such as the path from node A to node D ("lane keeping"), the in-depth analysis mode was not used at this time to ensure that testing resources were focused on areas with high problem incidence. Through this mode, the testing device successfully discovered a timing conflict between emergency braking and navigation positioning, achieving the goal of "deepening the investigation and finding hidden dangers".

[0049] In the third traversal phase, scene coverage increases from 80% to 100%. At this point, a hybrid weighted mode is adopted.

[0050] The optimization mode employs a hybrid weighted strategy, and its depth-first strategy weights are calculated using the following formula: W DFS =α×S i +β×H j Among them, W DFS This represents the depth-first strategy weight, a value between 0 and 1, used to determine the priority of using depth-first search for nodes or links in the current scenario. When W... DFS When W exceeds a preset threshold, depth-first search is preferred; when W... DFS When the threshold is less than or equal to the preset threshold, breadth-first search is preferred. The preset threshold is set by technical personnel based on the test objectives and resource constraints; for example, it can be set to 0.5, and the specific value is not limited.

[0051] Assuming node B, "Emergency Braking Trigger," has a heat value of 0.9 and a node importance of 1.0 (Level A), with an importance weight coefficient of 0.4 and a heat value coefficient of 0.6, the depth-first strategy weight is 0.94, which is greater than the preset threshold of 0.5. Therefore, the emergency braking and navigation-related links including nodes B and C will continue to use the depth-first strategy for enhanced testing. For node E, "Music Playback," its heat value is 0 and its node importance is 0.3 (Level D). The depth-first strategy weight is calculated as 0.4 multiplied by 0.3 plus 0.6 multiplied by 0, which equals 0.12, less than the preset threshold of 0.5. Therefore, the music playback-related links will switch to the breadth-first strategy, performing only a quick traversal and cleanup. For node F, "Air Conditioning Adjustment," its heat value is 0.1 and its node importance is 0.3. The depth-first strategy weight is calculated as 0.4 multiplied by 0.3 plus 0.6 multiplied by 0.1, which equals 0.18, still less than the preset threshold. Similarly, the breadth-first strategy will be used for quick cleanup. Through this mode, the testing device prioritizes the allocation of limited testing resources to high-importance, high-problem-frequency emergency braking and navigation links in the later stages of testing, while only providing basic coverage for low-problem-frequency links such as music playback and air conditioning adjustment, thus achieving the goal of "optimizing resources and improving efficiency".

[0052] In some embodiments of this application, test cases are tested based on test execution paths and preset test strategies to generate test performance results, including: obtaining the current test results of the test execution path; and analyzing the current test results based on a preset performance analysis mechanism to generate test performance results.

[0053] The current test result refers to the raw data set collected by the test execution module after executing a test execution path. The current test result may include, but is not limited to, the following: the execution status of each test execution path, including successful, failed, or partially successful execution; a comparison of the actual response time and expected response time for each scenario node; system logs generated during the test, including error logs, warning logs, and debug logs; performance metrics data during the test execution, including CPU utilization, memory utilization, or network latency; and the assertion results for each test case, used to determine whether the test case passes. The specific data format and collection granularity of the current test result are determined by the test execution module according to the preset test strategy and are not specifically limited.

[0054] Test performance results refer to a set of metrics used to evaluate the efficiency of test strategy execution, obtained through quantitative analysis of current test results. Test performance results may include, but are not limited to, the following: scenario coverage rate, which refers to the number of scenario nodes traversed per unit time, reflecting the speed of test progress; issue discovery density, which refers to the number of issues discovered per preset number of scenario nodes, reflecting issue discovery efficiency; resource utilization rate, which refers to the utilization of resources such as the central processing unit, memory, or bus during test execution, reflecting the degree of system resource consumption by the test; and issue distribution statistics, which refers to the distribution of issues in different scenario links or different functional modules, used to identify high-incidence areas of issues. The specific types and calculation methods of test performance results are determined by the preset performance analysis mechanism, and different performance metrics can be focused on at different test stages.

[0055] A pre-defined performance analysis mechanism refers to a set of rules and algorithms pre-set to transform raw test data into quantifiable performance indicators. This mechanism is set by technical personnel before testing begins, based on testing objectives and quality requirements, and can be dynamically adjusted as needed during testing; its specific content is not limited. A pre-defined performance analysis mechanism may include the following: data cleaning rules to remove invalid or noisy data from the current test results; indicator calculation formulas to define the specific calculation methods for each performance indicator, such as defining problem discovery density as the total number of problems divided by the number of traversed nodes multiplied by 100; threshold judgment rules to define the normal range of each performance indicator, triggering corresponding adjustments when an indicator exceeds a pre-defined threshold; and trend analysis methods to compare the changing trends of performance indicators over multiple consecutive testing periods to determine whether the testing strategy needs optimization. The parameters, formulas, and thresholds in the pre-defined performance analysis mechanism are pre-set by technical personnel based on the actual situation and quality requirements of the software under test; the specific values ​​are not limited.

[0056] Test performance results refer to a set of metrics used to evaluate the efficiency of test strategy execution, obtained through quantitative analysis of current test results. Test performance results may include scenario coverage rate (the number of scenario nodes traversed per unit time); problem discovery density (the number of problems discovered per preset number of scenario nodes traversed); and resource utilization rate (the usage of resources such as CPU, memory, or bus during test execution).

[0057] This application first obtains the current test results of the test execution path, and then analyzes the results through a preset performance analysis mechanism to generate test performance results. Through the above-mentioned real-time monitoring and analysis mechanism of test performance results, this application can dynamically evaluate the execution efficiency of the current test strategy and promptly detect abnormal situations such as low coverage rate, insufficient problem detection density, or excessive resource consumption.

[0058] In some embodiments of this application, the test performance results include problem discovery density, wherein adjusting the preset traversal mode based on the test performance results includes: shortening the first traversal stage in response to the problem discovery density being higher than a preset density threshold; and extending the first traversal stage in response to the problem discovery density being lower than a preset density threshold.

[0059] The issue discovery density refers to the number of issues discovered per preset number of scenario nodes, used to quantify the efficiency of issue discovery during testing. This metric is calculated by dividing the total number of issues discovered in the current round by the number of scenario nodes already traversed, then multiplying by 100, with the unit being issues per 100 nodes. A higher issue discovery density indicates a better focus of the current testing strategy on the issue chain; a lower issue discovery density indicates that the current testing strategy may be too scattered and fail to effectively target high-incidence areas of issues.

[0060] The preset density threshold refers to a pre-defined reference value for issue discovery density, used to determine whether the duration of the traversal phase needs adjustment in the current testing strategy. When the issue discovery density is higher than this threshold, it indicates that the testing strategy is highly efficient, and the first traversal phase can be ended earlier to enter the deep mining phase more quickly. When the issue discovery density is lower than this threshold, it indicates that the testing strategy is inefficient, and the first traversal phase needs to be extended to ensure sufficient coverage of the entire scenario. The preset density threshold is preset by technical personnel based on the complexity and quality requirements of the software under test and historical test data. For example, it can be set to 2 per 100 nodes, and the specific value is not limited.

[0061] Furthermore, in response to an issue discovery density exceeding a preset density threshold, the first traversal phase is shortened. Specifically, the upper limit of scene coverage corresponding to the first traversal phase is lowered from the first preset threshold to a lower value, allowing the testing device to switch to the depth-first mode of the second traversal phase earlier. For example, when the preset density threshold is 2 per 100 nodes and the actual measured issue discovery density is 3.5 per 100 nodes, the upper limit of coverage for the first traversal phase is lowered from 30% to 25%. In response to an issue discovery density below the preset density threshold, the first traversal phase is extended. Specifically, the upper limit of scene coverage corresponding to the first traversal phase is raised from the first preset threshold to a higher value, allowing the testing device to postpone entering the second traversal phase and continue using the breadth-first mode to expand scene coverage. For example, when the preset density threshold is 2 per 100 nodes and the actual measured issue discovery density is 1.2 per 100 nodes, the upper limit of coverage for the first traversal phase is raised from 30% to 35%. Through this dynamic adjustment mechanism, the testing device can adaptively optimize the timing of phase switching based on actual testing efficiency, achieving a reasonable allocation of testing resources across different traversal phases.

[0062] In some embodiments, adjusting the preset traversal mode based on test performance results further includes optimizing the α and β coefficients of the hybrid weighted strategy according to the strategy evaluation results. α and β are the weighting coefficients for the importance weight of scene nodes and the hotness value of link issues in the hybrid weighted strategy, respectively, and their sum is 1. When the strategy evaluation unit detects low issue discovery efficiency, the β coefficient is increased, up to a maximum of 0.8, while the α coefficient is correspondingly decreased, thereby strengthening the influence of the hotness value of issues on the weight of the depth-first strategy, causing test resources to be tilted towards links with high issue incidence. When the strategy evaluation unit detects incomplete scene coverage, the α coefficient is increased, up to a maximum of 0.7, while the β coefficient is correspondingly decreased, thereby strengthening the influence of the importance weight of scene nodes on the weight of the depth-first strategy, causing test resources to be tilted towards highly important nodes. The specific adjustment step size of the α and β coefficients is preset by technical personnel according to test requirements, for example, adjusting by 0.05 or 0.1 each time, with no specific value limitation. Through the above coefficient optimization mechanism, the hybrid weighted strategy can adaptively balance the two objectives of comprehensive coverage and issue focus, maintaining the optimal strategy configuration under different test stages and different test requirements.

[0063] In some embodiments of this application, the scenario link model further includes scenario relationship data. The process of traversing test cases based on the scenario link model and the target traversal pattern to generate test execution paths for the software includes: constructing a test case matrix based on scenario relationship data and test cases; traversing the test case matrix based on the target traversal pattern to generate a test path set; and filtering the test path set based on a preset filtering method to determine the test execution path.

[0064] Scene relationship data refers to the data set describing the transformation relationships between various scene nodes in the scene link model. Scene relationship data may include directed connections between nodes, the weight values ​​of those connections, and the operation instructions required to trigger the transformation. Scene relationship data can be extracted from software behavior data, and its specific form and storage method are determined by the structure of the scene link model and are not specifically limited.

[0065] Furthermore, a test case matrix is ​​constructed based on scene relationship data and test cases. The test case matrix is ​​a two-dimensional data structure using scene nodes as rows and columns to represent the transformation relationships between nodes. Rows in the test case matrix represent the current scene node, and columns represent the target scene node. Each element in the matrix stores transformation information from the current node to the target node. Transformation information may include reachability, relationship weight, issue popularity value, and triggering operation instructions. The test case matrix can be dynamically updated based on scene relationship data; for example, when the issue popularity value changes, the popularity value of the corresponding element in the matrix is ​​updated accordingly. The specific dimensions and storage format of the test case matrix are determined by the number of scene nodes in the scene link model.

[0066] A test path set is a collection of node sequences generated after traversing the test case matrix. Each node sequence represents a complete traversal path from the starting node to the ending node. Each path in the test path set can contain multiple scenario nodes and the transformation relationships between nodes. The length of the path is determined by the number of nodes it traverses, and the priority of the path is calculated by combining the weights or popularity values ​​of the edges contained in the path. The test path set can contain all reachable paths, or it can contain a subset of paths filtered according to the target traversal pattern. The specific range is determined by the traversal strategy and is not limited.

[0067] A preset screening method refers to a set of rules pre-defined to select the optimal subset of paths from the test path set. This screening method is set by technical personnel before the test begins, based on the test objectives and resource constraints, and can be dynamically adjusted during the test based on the test performance results. Specific details are not limited. Preset screening methods may include screening by path complexity level, by link problem frequency, by path length, sorting by path priority and selecting the top N paths, or a combination of these methods. Path complexity levels can be categorized as simple, medium, and complex based on the number of nodes, branches, functional domains involved, or resource contention levels. The parameters and thresholds in the preset screening method are pre-set by technical personnel based on the actual situation of the software under test and test resources. For example, the screening ratio can be set to 30% to 50%, prioritizing paths with high complexity and high problem frequency.

[0068] Specifically, the test path set is filtered based on a preset filtering method to determine the test execution path.

[0069] As a specific embodiment of this application, an improved adjacency matrix algorithm is used to generate and filter test paths.

[0070] First, an adjacency matrix is ​​constructed. The constructed weighted adjacency matrix not only marks the relationships between scene nodes (reachable or unreachable, represented by 0 or 1), but also embeds relationship weights. These weights are determined based on user frequency and functional importance; for example, paths frequently used by users have higher weights, and paths containing functional nodes with security level A have higher weights. The weighted adjacency matrix provides data support for subsequent path priority ranking.

[0071] Then, initial path generation and deduplication are performed. All reachable paths are traversed based on a weighted adjacency matrix to generate an initial path set. The initial path set is then deduplicated using a node sequence hash verification algorithm. This algorithm converts the node identifier sequence of each path into a unique hash value. If two paths have the same hash value, they are considered duplicate paths and are removed, ensuring that each path is unique in the set.

[0072] Next, path filtering and sorting are performed. The initial set of deduplicated paths is bidirectionally sorted according to path complexity level and link problem popularity value. Path complexity level can be divided into three levels: simple, medium, and complex, determined by factors such as path length, number of branches, and number of functional domains involved. The link problem popularity value is dynamically calculated by the problem analysis module based on historical test results. The bidirectional sorting prioritizes retaining paths with high complexity and high problem popularity, and selects the optimal subset of paths (30% to 50%) based on the sorting results to improve the probability of problem discovery.

[0073] Finally, validity verification is performed. The selected optimal path subset undergoes logical conflict verification and length compliance verification. Logical conflict verification prevents mutually exclusive scenario nodes from appearing on the same path, such as the constraint prohibiting video playback while driving. Length compliance verification ensures that the path length does not exceed the preset maximum number of nodes, preventing excessively long execution times for a single path. After passing validity verification, the final output is a scenario traversal path that is non-repeating, high-priority, and conflict-free, serving as the test execution path.

[0074] S3 tests test cases based on the test execution path and preset test strategies to obtain the test execution results of the software.

[0075] As a specific embodiment of this example, firstly, based on the functional type of each scene node in the scene link model, the corresponding test case template is automatically matched. For example, a positioning accuracy test template can be matched for navigation scene nodes, and an audio quality test template can be matched for multimedia scene nodes. The matched test case template is then combined with the specific node parameters in the current test execution path to generate personalized executable test cases.

[0076] Then, according to the operation instructions defined in the generated test cases, corresponding interactive events are sent to the software under test to drive the software state transition. Simulated interaction methods include one or more of the following: screen clicks, voice commands, physical buttons, gestures, and steering wheel buttons.

[0077] During test execution, various types of data are collected synchronously and stored in association with the current test execution path and test cases. The collected data includes interface status data, system log data, and performance data. Interface status data may include the control layout and displayed content of the current page, system log data may include application logs and error reports, and performance data may include CPU utilization, memory utilization, and network latency.

[0078] Finally, all collected data is aggregated to form structured test execution results for subsequent use.

[0079] S4 generates a test result report in response to the test execution result meeting the preset test termination conditions.

[0080] The preset test termination conditions refer to a set of pre-defined rules for determining whether a test should be terminated. These conditions are set by technical personnel before the test starts, based on the test objectives and resource constraints, and can be dynamically adjusted during the test; their specific content is not limited.

[0081] For example, the preset test termination conditions support the following three termination methods: The first method involves reaching a preset threshold for scene coverage. The test ends when the proportion of traversed scene nodes in the scene link model to the total number of scene nodes reaches or exceeds a preset threshold. This preset threshold can be set by technical personnel to 100% full coverage, or it can be set to 95% or other values ​​according to actual testing needs; there are no specific limitations.

[0082] The second type involves multiple rounds of testing without discovering any new issues. The test terminates when the testing equipment has performed N complete rounds of testing without finding any new problems or defects in each round. Here, N is the number of rounds preset by technical personnel based on software quality requirements and testing adequacy standards; for example, it could be set to 3 rounds, but the specific value is not limited.

[0083] The third method involves reaching a preset test time or test round limit. The test terminates when the total test execution time reaches the preset time limit, or when the total number of test rounds reaches the preset round limit. The preset test time and test round limit are set by technical personnel based on the test resource budget and project schedule requirements. For example, the test time can be set to 24 hours or the test rounds to 10 rounds; the specific values ​​are not limited.

[0084] As a specific implementation of this embodiment, after each round of testing is completed and the test results are obtained, a multi-dimensional statistical analysis is first performed on the test results to accurately identify high-problem links. By statistically analyzing the frequency, severity, and type of problems in each scenario link, a link problem heatmap is generated to visually present the problem distribution of different links. For example, if the "navigation plus music concurrency" link experiences multiple stuttering issues with a high severity level, this link will be displayed in orange on the heatmap, making it easy to quickly locate key areas of concern. This analysis process transforms fragmented test results into structured data that can guide strategy adjustments.

[0085] Subsequently, it is determined whether the current scene coverage has reached or exceeded a preset threshold. If so, the test is terminated and a test result report is generated. Otherwise, it is determined whether the number of consecutive rounds without new issues has reached a preset round N. If so, the test is terminated and a test result report is generated. Otherwise, it is determined whether the current cumulative test time or cumulative test rounds has reached a preset upper limit. If so, the test is terminated and a test result report is generated. If none of the above three conditions are met, the next round of testing continues. When any termination condition is triggered, the testing device generates a test result report based on the test execution results of each historical round. This report may include one or more of the following: scene coverage statistics, issue discovery list, issue distribution heatmap, performance index comparison of each round, and strategy adjustment records.

[0086] In some embodiments of this application, in response to the test execution result not meeting the preset test termination condition, the preset test strategy and scenario link model are modified; the scenario is traversed based on the modified scenario link model and target traversal mode to generate the test execution path of the software, and the test cases are tested based on the regenerated test execution path and the modified preset test strategy to obtain the test execution result of the software, until the re-obtained test execution result meets the preset test termination condition.

[0087] Specifically, when the results of this round of testing do not meet the preset test termination conditions, the preset test strategy is first modified. This includes identifying links with high frequency and severity of problems based on the link problem heatmap generated by the problem analysis module, increasing the testing frequency of these links (e.g., from once per round to three times per round); expanding the test case dimensions for these links (e.g., adding boundary scenario test cases such as network outages and low battery); and increasing the execution priority of these links so that they are executed first in the next round of testing. Simultaneously, for links that have not shown problems for several consecutive rounds and have low importance, their testing frequency or priority is reduced to save testing resources.

[0088] Simultaneously, the scenario link model is revised, including supplementing missing scenario nodes or directed edges based on new scenarios or paths discovered during this round of testing; correcting erroneous node associations based on discrepancies between actual transformation relationships and model definitions found in test results; and updating the problem heat values ​​of each link in the scenario link model based on the problem heat values ​​output by the problem analysis module, so that the model can reflect the latest problem distribution.

[0089] After revising the preset test strategy and scenario link model, the testing device re-traverses the scenario based on the revised scenario link model and the current target traversal mode, generating a new round of test execution paths. Then, based on the regenerated test execution paths and the revised preset test strategy, the test cases are tested to obtain a new round of test execution results. The testing device then determines whether the result meets the preset test termination conditions. If it does, the test terminates and a test result report is generated; otherwise, the above revision and testing process is repeated until the test execution result obtained in a certain round meets the preset test termination conditions. Through this closed-loop iterative mechanism, the testing device can continuously optimize strategy configuration and model accuracy in multiple rounds of testing, enabling testing capabilities to gradually improve with each test round.

[0090] Compared with related technologies, this application has the following technical advantages: First, it achieves fully automated testing. From data acquisition, model building, path generation, test execution to result determination, this application can complete all processes automatically without human intervention, significantly improving testing efficiency.

[0091] Second, the scenario coverage is more comprehensive. This application uses a scenario link model to fully describe the transition relationships between the various functional states of the software, and combines a breadth-first and depth-first phased traversal strategy to quickly achieve full scenario coverage in the early stages of testing, avoiding the omission of necessary scenario nodes.

[0092] Third, the efficiency of problem discovery is higher. This application focuses on high-importance or already discovered problem links through a deep mining mode, and dynamically allocates test resources based on the problem popularity value of the link and the importance of the node, so that test resources are accurately deployed to areas with high problem incidence, and the efficiency of problem discovery is significantly improved compared with fixed strategy testing methods.

[0093] Fourth, test resources are used more efficiently. This application increases the testing frequency for links with frequent problems and decreases the testing frequency for links without problems through a strategy adjustment module, and adjusts path parameters in real time based on resource occupancy through a dynamic adaptation unit, thus avoiding the waste of test resources on links without problems.

[0094] Fifth, it possesses closed-loop iterative optimization capabilities. This application uses a feedback iteration module to feed the test execution results back to the scenario modeling module, continuously revising the model and optimizing strategy parameters, so that the testing capability gradually improves with each test round, making it suitable for the entire lifecycle testing of software.

[0095] Corresponding to the above embodiments, this application also provides a software scene automated testing device, referring to... Figure 2 The device 200 includes: a modeling module 210, a path generation module 220, a test execution module 230, and a report generation module 240.

[0096] The modeling module 210 is used to acquire the software's behavioral data and generate a scenario link model based on the behavioral data. The scenario link model includes multiple scenarios. The path generation module 220 is used to perform scenario traversal based on the scenario link model and the target traversal mode to generate the software's test execution path. The target traversal mode is determined according to the test execution path and the preset test strategy. The test execution module 230 is used to test the test cases based on the test execution path and the preset test strategy to obtain the software's test execution results. The report generation module 240 is used to generate a test result report in response to the test execution results meeting the preset test termination conditions.

[0097] In some embodiments of this application, the path generation module 220 determines the target traversal mode based on the test execution path and the preset test strategy, specifically for: obtaining the preset traversal mode; testing test cases based on the test execution path and the preset test strategy to generate software test performance results; adjusting the preset traversal mode based on the test performance results to obtain the target traversal mode in response to the test performance results meeting the preset adjustment conditions; and using the preset traversal mode as the target traversal mode in response to the test performance results not meeting the preset adjustment conditions.

[0098] In some embodiments of this application, the path generation module 220 determines that scene traversal includes a first traversal stage, a second traversal stage, and a third traversal stage, and obtains a preset traversal mode, specifically used for: adopting a breadth-first search mode as the preset traversal mode in response to the scene traversal being in the first traversal stage; adopting a depth-first search mode as the preset traversal mode in response to the scene traversal being in the second traversal stage; and adopting a mixed weighted search mode as the preset traversal mode in response to the scene traversal being in the third traversal stage.

[0099] In some embodiments of this application, the path generation module 220 determines that the scenario link model also includes scenario relationship data. Specifically, the test cases are traversed based on the scenario link model and the target traversal pattern to generate the test execution path of the software. This is specifically used for: constructing a test case matrix based on the scenario relationship data and test cases; traversing the test case matrix based on the target traversal pattern to generate a test path set; and filtering the test path set based on a preset filtering method to determine the test execution path.

[0100] In some embodiments of this application, the path generation module 220 tests test cases based on the test execution path and a preset test strategy to generate test performance results. Specifically, it is used to: obtain the current test results of the test execution path; and analyze the current test results based on a preset performance analysis mechanism to generate test performance results.

[0101] In some embodiments of this application, the path generation module 220 determines the test performance results, including the problem discovery density. The adjustment of the preset traversal mode based on the test performance results includes: shortening the first traversal stage in response to the problem discovery density being higher than a preset density threshold; and extending the first traversal stage in response to the problem discovery density being lower than a preset density threshold.

[0102] In some embodiments of this application, the report generation module 240 is further configured to: in response to the test execution result not meeting the preset test termination condition, modify the preset test strategy and scenario link model; perform scenario traversal based on the modified scenario link model and target traversal mode to generate the test execution path of the software, and test the test cases based on the regenerated test execution path and the modified preset test strategy to obtain the test execution result of the software, until the re-obtained test execution result meets the preset test termination condition.

[0103] It is understood that any details not disclosed in the scene automation testing device of the software in this application can be found in the details disclosed in the scene automation testing method of the software, and will not be repeated here.

[0104] This application also provides an electronic device, with reference to... Figure 3 The electronic device 300 includes: a memory 310, a processor 320, and a computer program stored on the memory 310 and executable on the processor 320. The processor 320 executes the program to implement the aforementioned software scenario automation testing method.

[0105] This application also provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the aforementioned software scenario automation testing method.

[0106] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0107] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0108] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0109] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

[0110] Any process or method described in the flowchart or otherwise herein is to be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0111] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0112] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0113] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0114] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0115] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

[0116] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0117] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for automated scenario testing of software, characterized in that, include: Acquire software behavior data and generate a scenario link model based on the behavior data, wherein the scenario link model includes multiple scenarios; The scenario is traversed based on the scenario link model and the target traversal mode to generate the test execution path of the software, wherein the target traversal mode is determined according to the test execution path and the preset test strategy. The test cases are tested based on the test execution path and the preset test strategy to obtain the test execution results of the software; In response to the test execution result meeting the preset test termination condition, a test result report is generated.

2. The method according to claim 1, characterized in that, The target traversal pattern is determined based on the test execution path and the preset test strategy, including: Get the preset traversal mode; The test cases are tested based on the test execution path and the preset test strategy to generate the test performance results of the software. In response to the test performance results meeting the preset adjustment conditions, the preset traversal mode is adjusted based on the test performance results to obtain the target traversal mode; In response to the test performance result not meeting the preset adjustment conditions, the preset traversal mode is used as the target traversal mode.

3. The method according to claim 2, characterized in that, The scene traversal includes a first traversal stage, a second traversal stage, and a third traversal stage. Obtaining the preset traversal mode includes: In response to the scenario traversal being in the first traversal phase, a breadth-first search mode is adopted as the preset traversal mode. In response to the scene traversal being in the second traversal phase, a depth-first mode is adopted as the preset traversal mode. In response to the scene traversal being in the third traversal stage, a mixed weighted mode is adopted as the preset traversal mode.

4. The method according to claim 1, characterized in that, The scenario link model also includes scenario relationship data, wherein the step of traversing the test cases based on the scenario link model and the target traversal pattern to generate the test execution path of the software includes: Construct a test case matrix based on the scenario relationship data and the test cases; The test case matrix is ​​traversed based on the target traversal pattern to generate a test path set; The test path set is filtered based on a preset filtering method to determine the test execution path.

5. The method according to claim 2, characterized in that, The step of testing the test cases based on the test execution path and preset test strategy to generate test performance results includes: Obtain the current test results for the test execution path; The current test results are analyzed based on a preset performance analysis mechanism to generate the test performance results.

6. The method according to claim 3, characterized in that, The test performance results include the problem discovery density, wherein adjusting the preset traversal mode based on the test performance results includes: In response to the problem finding that the density is higher than a preset density threshold, the first traversal phase is shortened; In response to the problem that the density is found to be lower than a preset density threshold, the first traversal phase is extended.

7. The method according to claim 1, characterized in that, Also includes: In response to the test execution result not meeting the preset test termination condition, the preset test strategy and the scenario link model are modified; The scenario is traversed based on the modified scenario link model and target traversal mode to generate the test execution path of the software. The test cases are then tested based on the regenerated test execution path and the modified preset test strategy to obtain the test execution result of the software, until the re-obtained test execution result meets the preset test termination condition.

8. A software scenario automated testing device, characterized in that, include: A modeling module is used to acquire the software's behavioral data and generate a scene link model based on the behavioral data, wherein the scene link model includes multiple scenes; The path generation module is used to perform scene traversal on the scene based on the scene link model and the target traversal mode to generate the test execution path of the software, wherein the target traversal mode is determined according to the test execution path and the preset test strategy; The test execution module is used to test the test cases based on the test execution path and the preset test strategy to obtain the test execution results of the software. The report generation module is used to generate a test result report in response to the test execution result meeting the preset test termination conditions.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement a scenario-automated testing method for the software as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the scenario-automated testing method for the software as described in any one of claims 1-7.

Images