Automatic test script generation method and system, storage medium and electronic equipment

Abstract

The invention relates to the technical field of software testing, and discloses an automatic test script generation method and system, a storage medium and electronic device.The method comprises the steps that test case information and tested environment information are received, and structured case representation is generated; enhancing the structured use case representation based on a preset knowledge base; generating a plurality of positioning candidates for the target control in the testing step, and establishing a priority relationship among the positioning candidates; generating an executable automatic test script; running the script, and when execution failure is detected, automatically adjusting a positioning strategy, a waiting strategy or a business process based on a failure type, and executing again; and feeding back the successfully executed script information to the knowledge base, and updating the content and priority of the knowledge base. Through organic combination of knowledge base enhancement, multi-candidate positioning and a self-healing mechanism, the technical problems that an existing automatic test script is high in maintenance cost, poor in stability and lack of domain knowledge are solved.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to an automated test script generation method, system, storage medium, and electronic device. Background Technology

[0002] With the rapid iteration of mobile applications and the increasing demand for multi-device adaptation, automated testing plays an increasingly important role in software quality assurance. However, existing methods for writing automated test scripts for mobile applications suffer from numerous technical bottlenecks.

[0003] Recording and playback tools generate test scripts by recording user actions. While they are easy to learn, the generated scripts are highly sensitive to control paths and page loading sequences. When the application interface undergoes minor adjustments, such as changes in control positions or page element hierarchies, the scripts often fail to execute correctly, leading to a large number of script failures. This vulnerability makes the maintenance cost of test scripts high, especially in scenarios with frequent application updates, requiring testing teams to invest significant manpower in repeatedly fixing and adjusting the scripts.

[0004] While manual coding or keyword-driven approaches offer better stability, they require test engineers to have a deep understanding of the application's interface structure and control hierarchy. Writing a complete test script necessitates testers manually analyzing page elements, writing location logic, setting wait times, and implementing assertion verification—a time-consuming and error-prone process. More importantly, when the application evolves across versions, the differences in interface, changes in control properties, and adjustments to interaction flows between versions all require manual identification and adaptation, resulting in extremely low script reusability.

[0005] In recent years, with the development of large language model technology, some solutions have attempted to leverage the model's code generation capabilities to automatically generate test steps. However, these solutions generally lack effective input of test domain expertise. The models lack understanding of business-specific control positioning methods, common waiting times, and typical business processes, resulting in unstable script quality. Furthermore, existing solutions lack effective feedback and repair mechanisms after script execution failures. When a script encounters problems on its first run, the system cannot automatically analyze the cause of the failure and make targeted adjustments, still requiring manual intervention. In addition, these solutions have failed to form an accumulative and transferable knowledge system; each generation is almost starting from scratch, unable to leverage historical experience to optimize subsequent script generation processes, and thus struggling to support large-scale, multi-module testing scenarios.

[0006] In practical applications, test scripts often need to be adapted to various device models, operating system versions, and application versions. Resource identifiers for controls may differ in different environments, page layouts may vary, and business processes may change due to regional or language settings. Existing technologies lack a systematic cross-version adaptation mechanism, and when scripts need to run in new environments, a significant amount of manual adjustment work is usually required. Summary of the Invention

[0007] The purpose of this invention is to provide an automated test script generation method, system, storage medium, and electronic device, aiming to solve the technical problems of existing automated test scripts lacking domain knowledge injection and being unable to self-heal after script failure.

[0008] To achieve the above-mentioned objectives, this invention provides an automated test script generation method, comprising: Receive test case information and test environment information, and generate structured test case representations; The structured use case representation is enhanced based on a preset knowledge base, which includes control location knowledge, business process knowledge, and waiting timing knowledge. Multiple location candidates are generated for the target control in the testing step, and a priority relationship is established between the location candidates; Based on the enhanced use case representation and the location candidates, an executable automated test script is generated; When the script is run, if an execution failure is detected, the positioning strategy, waiting strategy, or business process will be automatically adjusted based on the failure type, and the script will be re-executed. The information of successfully executed scripts is fed back to the knowledge base, updating the content and priority of the knowledge base.

[0009] Optionally, the enhancement of the structured use case representation based on the preset knowledge base includes: retrieving knowledge items related to the current test scenario from the knowledge base by combining a large language model with retrieval enhancement generation technology, and integrating the retrieval results into the structured use case representation.

[0010] Optionally, the location candidates include at least one of resource identifier location, content descriptor location, text matching location, path location, and relative location anchor point.

[0011] Optionally, the priority relationship between the positioning candidates is determined based on historical execution success rate statistics and is dynamically adjusted with new execution results.

[0012] Optionally, generating an executable automated test script includes configuring a waiting strategy for the test steps in the script based on the waiting timing knowledge.

[0013] Optionally, before generating the executable automated test script, the method further includes: pre-validating the script, wherein the pre-validation includes at least one of syntax validation, dependency validation, ambiguity detection, assertion reachability check, and idempotency check.

[0014] Optionally, the automatic adjustment process based on failure type includes: collecting execution evidence, analyzing failure types, and selecting the corresponding adjustment strategy according to the preset mapping relationship between failure types and adjustment strategies; The execution evidence includes at least one of the following: screenshots, control tree information, execution logs, and operation timelines.

[0015] Optionally, the failure type includes at least one of location failure, timing anomaly, business process interference, and status anomaly.

[0016] Optionally, when a location failure is detected, the automatic adjustment of the location strategy includes: trying the alternative location candidates in order of priority until the location is successful or all candidates have been traversed; When a timing anomaly is detected, the automatic adjustment of the waiting strategy includes: extending the timeout period of the condition wait, adding additional condition waits, or increasing the duration of the delay wait; When business process interference is detected, automatic adjustment of the business process includes: retrieving a matching business sub-process template from the business process knowledge and inserting it into the current execution position; When an abnormal status is detected, the automatic adjustment of the business process includes: performing a status cleanup operation, which includes at least one of returning to the initial page, logging in again, or cleaning up test data.

[0017] Optionally, the number of iterations to be re-executed is set to an upper limit, which is between 5 and 20 times.

[0018] Optionally, the updated knowledge base content and priorities include: recording successful location candidates, effective waiting strategies, and verified business process templates, and increasing the priority of multiple consecutively successful location candidates or waiting strategies.

[0019] Optionally, feeding back the successfully executed script information to the knowledge base includes: recording cross-version resource renaming mapping, layout structure mapping, and conditional branch selection rules to form version adaptation information indexed by device model, system version, and application version.

[0020] This invention also provides an automated test script generation system, comprising: The input processing module is used to receive test case information and test environment information, and generate structured test case representations; The knowledge base module stores control location knowledge, business process knowledge, and waiting timing knowledge. The reasoning module is used to enhance the structured use case representation based on the knowledge base and generate multiple location candidates and their priority relationships for the target controls in the test steps; The script generation module is used to generate executable automated test scripts based on the enhanced test case representation and the location candidates; The execution module is used to run the script and collect execution information; The self-healing module is used to automatically adjust the positioning strategy, waiting strategy or business process based on the failure type when an execution failure is detected, and trigger re-execution. The update module is used to feed back information about successfully executed scripts to the knowledge base and update the content and priority of the knowledge base.

[0021] Optionally, the script generation module includes a waiting policy configuration submodule and a verification submodule; The waiting strategy configuration submodule is used to configure conditional waiting, delayed waiting, timeout time and retry mechanism for the test steps based on the waiting timing knowledge. The verification submodule is used to perform syntax verification, dependency verification, ambiguity detection, assertion reachability check, and idempotency check on the generated script.

[0022] Optionally, the self-healing module includes a failure type analyzer, a policy mapper, and a policy executor; The failure type analyzer is used to determine the failure type based on execution evidence; The strategy mapper is used to select the corresponding adjustment strategy according to the mapping relationship between failure type and adjustment strategy, and the mapping relationship supports online updates with running statistics; The policy executor is used to execute the selected adjustment policy and trigger re-execution.

[0023] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the automated test script generation method described above.

[0024] The present invention also 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 computer program to implement the automated test script generation method described above.

[0025] Compared to existing technologies, this invention enhances test cases by using a pre-built knowledge base including control location knowledge, business process knowledge, and waiting timing knowledge, combined with a large language model and retrieval enhancement generation technology. It generates multiple location candidates for the target control and establishes priority relationships. When script execution fails, it automatically adjusts the location strategy, waiting strategy, or business process based on the failure type and re-executes, forming a complete closed loop from knowledge enhancement to script generation, execution, self-healing, and knowledge updating. This solution solves the problems of traditional automated test scripts being sensitive to UI changes, having high maintenance costs, and lacking self-healing capabilities. It achieves rapid generation, automatic repair, and continuous optimization of test scripts, significantly improving script generation speed, reducing maintenance costs, and enhancing script stability and cross-version adaptability.

[0026] Furthermore, this invention effectively reduces occasional failures caused by premature clicks or assertions by configuring conditional waiting for test steps and, when necessary, adding delayed waiting as a fallback strategy. Pre-validation, including syntax checking, dependency validation, ambiguity detection, assertion reachability checks, and idempotency checks, eliminates explicit defects before execution, improving the first-run success rate. By determining the priority relationships between location candidates based on historical execution success rate statistics and dynamically adjusting them according to execution results, and by feeding back successfully executed script information to the knowledge base for updates and priorities, continuous learning and optimization of the knowledge base are achieved, allowing subsequent similar test cases to directly reuse verified successful strategies. Recording cross-version resource mapping relationships to form version adaptation information improves script maintainability and cross-device / version adaptability. This forms a virtuous cycle of knowledge accumulation, script generation, execution verification, and knowledge updating, continuously improving test automation capabilities. Attached Figure Description

[0027] Figure 1 This is a flowchart of an automated test script generation method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of an automated test script generation system module in an embodiment of the present invention. Detailed Implementation

[0028] The present invention will now be described with reference to the accompanying drawings, which illustrate preferred embodiments of the invention. It should be understood that those skilled in the art can modify the invention described herein while still achieving its advantageous effects. Therefore, the following description should be understood as being of general knowledge to those skilled in the art and is not intended to limit the invention.

[0029] The serial numbers assigned to components in this document, such as "first," "second," etc., are merely used to distinguish the described objects and have no sequential or technical meaning. The terms "connection" and "linkage" used in this application, unless otherwise specified, include both direct and indirect connections (linkages). In the description of this invention, it should be understood that the terms "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," and "counterclockwise," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention.

[0030] In this invention, unless otherwise explicitly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "over," and "on top" of the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0031] The invention is described more specifically by way of example in the following paragraphs with reference to the accompanying drawings. The advantages and features of the invention will become clearer from the following description. It should be noted that the drawings are in a very simplified form and use non-precise proportions, and are only used to facilitate and clarify the illustration of the embodiments of the invention.

[0032] Example 1 Please refer to Figure 1 This invention provides an automated test script generation method, comprising the following steps: S1. Receive test case information and test environment information, and generate structured test case representations; S2. Enhance the structured use case representation based on a preset knowledge base, which includes control location knowledge, business process knowledge, and waiting timing knowledge; S3. Generate multiple location candidates for the target control in the test step, and establish the priority relationship between the location candidates; S4. Generate an executable automated test script based on the enhanced use case representation and the location candidates; S5. Run the script. When an execution failure is detected, automatically adjust the positioning strategy, waiting strategy, or business process based on the failure type, and re-execute. S6. Feedback the successfully executed script information to the knowledge base, and update the content and priority of the knowledge base.

[0033] This embodiment provides an automated test script generation method that solves the technical problems of high maintenance costs, poor stability, and lack of domain knowledge in existing automated test scripts by organically combining knowledge base enhancement, multi-candidate localization, and self-healing mechanisms.

[0034] Specifically, in step S1, the following two types of input information are received: (1) Test case information Test case information can come from various sources, including but not limited to: Historical test case scripts: Existing automated test scripts from which step logic and location methods can be extracted.

[0035] List of steps: Test steps for natural language description.

[0036] Semi-structured test case document: A test case template that includes preconditions, operation steps, and expected results.

[0037] (2) Information on the measured environment The test environment information includes at least one of the following: application version, device model, operating system version, and screen resolution. This information is used to subsequently retrieve suitable knowledge entries from the knowledge base, ensuring that the generated script can adapt to the specific test environment.

[0038] In a specific example, the information of the environment under test may include: App version, device model, operating system, and screen resolution.

[0039] The system parses and standardizes the received test case information, extracting and unifying it into an intermediate representation. This structured test case representation includes preconditions, step sequences, assertion points, and dependencies.

[0040] Specifically, the preconditions refer to the states that need to be met before the test can be executed, such as the user has logged out, the network connection is normal, and storage permissions have been granted.

[0041] A step sequence refers to the operational steps of a test and their sequential relationship, which may include logical structures such as sequential execution, conditional branching, and loops.

[0042] Assertion points are the expected results that need to be verified at each step, such as the login button being visible or the page title being "Homepage".

[0043] Dependency is a data dependency between steps, such as step 3 using the user ID obtained in step 2.

[0044] In this embodiment, by unifying test case information in various formats into a standardized structured representation, a reliable context is provided for subsequent large-scale model inference, reducing the instability and information omission problems caused by generating from scratch.

[0045] Furthermore, in step S2, domain knowledge is introduced to address the problem in existing technologies where large models are insensitive to business-specific controls and atomic operation paths.

[0046] The knowledge base includes three parts: control location knowledge, business process knowledge, and waiting timing knowledge. The knowledge of control location includes multiple stable location methods for commonly used controls and their alternatives. This knowledge is indexed by the control identifier and stores multiple location methods for each commonly used control, along with their historical success rates.

[0047] The business process knowledge includes parameterizable business sub-process templates, which cover at least one of the following: login process, authorization process, payment process, or system pop-up handling process. These templates encapsulate standard handling methods for high-risk, high-frequency business scenarios. The parameterizability includes at least one of channel parameters, region parameters, and language parameters, and supports batch mapping based on resource keys or regular expressions.

[0048] The knowledge base covers at least one of the following: when the page finishes loading, when controls become visible, when list rendering is complete, and when animations end. It records common empirical timings for page or control loading and animation completion.

[0049] Furthermore, in step S2, the process of enhancing the structured use case representation based on the preset knowledge base includes: retrieving knowledge items related to the current test scenario from the knowledge base by combining a large language model with retrieval enhancement generation technology (RAG), and integrating the retrieval results into the structured use case representation.

[0050] In a specific example, the implementation process can be as follows: Step 1: Query Vector Generation The structured use case representation generated in step S1 is converted into query vectors. This process uses an encoder from a large language model to map the semantic information of the use cases into a high-dimensional vector space.

[0051] Step 2: Knowledge Retrieval Using query vectors, similarity searches are performed in three knowledge bases respectively, and the Top-K most relevant knowledge entries are returned.

[0052] Step 3: Knowledge Integration The large language model analyzes the matching degree between the search results and the current step, and decides whether to insert, replace or parameterize the relevant steps.

[0053] For the integration of business process knowledge, the system checks whether any necessary business sub-processes are missing from the current use case graph and automatically inserts them. For example, if the original use case does not have a step for handling the initial login authorization, but it is detected that the application under test requires authorization upon initial login, the business process template will be automatically inserted.

[0054] Regarding the integration of waiting timing knowledge, the system will automatically add waiting strategy configuration after each operation step to ensure that subsequent operations are executed only after the preceding conditions are met.

[0055] In this embodiment, knowledge augmentation is used to address the shortcomings of the large model in terms of domain knowledge, enabling the generated test scripts to cover high-risk business paths and adapt to differences in different channels, regions, and languages.

[0056] Further, in step S3, the location candidates include at least one of resource identifier location, content descriptor location, text matching location, path location, and relative location anchor point.

[0057] For each target control, the system extracts all available positioning methods from the control positioning knowledge base and performs adaptability filtering based on the current testing environment information.

[0058] Resource identifier location is based on Android's resource-id or iOS's accessibilityidentifier attribute. This is the most stable location method, but it may change during UI refactoring.

[0059] Content descriptor positioning is based on the content-desc attribute of Android or the accessibility label attribute of iOS.

[0060] Text matching and positioning is based on the text content displayed by the control. Text matching and positioning is simple and intuitive, but in a multilingual environment, multiple sets of text mappings need to be maintained.

[0061] Path positioning is based on the path of the control in the UI hierarchy tree.

[0062] Relative positioning anchors are anchored based on the parent-child hierarchy, sibling hierarchy, or screen geometric position of controls. This is particularly suitable for static disambiguation in scenarios with multiple controls on the same screen.

[0063] Furthermore, in step S3, the priority relationship between the positioning candidates is determined based on historical execution success rate statistics and is dynamically adjusted with new execution results.

[0064] The initial priority is provided by the knowledge base, and the priority will be dynamically adjusted as the script executes and provides feedback.

[0065] In this embodiment, by preparing multiple positioning candidates for each control, the system can automatically switch to alternative positioning methods when UI tweaks cause the primary positioning method to fail, preventing the script from failing directly. This significantly improves the script's tolerance to UI changes and reduces maintenance costs by approximately 70%.

[0066] It should be noted that the order of steps S2 and S3 is not restricted.

[0067] Furthermore, in step S4, the aforementioned structured use cases, knowledge enhancement results, and location candidate sets are combined to generate a final test script that can be executed on the mobile automation framework.

[0068] In one specific example, the executable automated test script is generated based on a mobile automation testing framework, such as Appium or uiautomator2. The script generation module selects the appropriate framework based on the tested environment information (Android or iOS) and generates code that conforms to the framework's API specifications.

[0069] The process of generating an executable automated test script includes configuring a waiting strategy for the test steps in the script based on the waiting timing knowledge.

[0070] The waiting strategy includes conditional waiting and delayed waiting, with conditional waiting being prioritized and delayed waiting being added as a fallback mechanism when necessary. Timeout and retry mechanisms are also configured.

[0071] The conditional waiting includes at least one of the following: waiting for an element to become visible, waiting for an element to become clickable, waiting for a list to finish loading, waiting for a page to become idle, or waiting for an animation to complete.

[0072] When necessary, such as when the page has animation effects or network requests take time, a short delay can be added to the conditional wait.

[0073] The retry mechanism employs an exponential backoff strategy and a partial step rollback strategy. When a step fails due to a temporary problem (such as network latency or incomplete animation), it is not immediately considered a failure, but is retried a limited number of times.

[0074] Furthermore, before generating the executable automated test script, the method further includes: pre-validating the script, wherein the pre-validation includes at least one of syntax validation, dependency validation, ambiguity detection, assertion reachability check, and idempotency check.

[0075] Syntax validation checks whether the generated script code conforms to the syntax rules of the target programming language (such as Python) and whether it correctly calls the automation framework's API. Syntax errors are intercepted and automatically corrected or flagged at this stage.

[0076] Dependency checks are used to verify whether dependencies between steps are satisfied. For example, if step 5 depends on the output data of step 3, the check verifies whether step 3 can correctly produce that data and whether step 5 correctly references it.

[0077] The positioning ambiguity detection includes automatically introducing relative positioning anchors to disambiguate when multiple controls matching the same positioning expression are detected on the same screen. The positioning ambiguity detection is based on a joint determination of structural similarity thresholds and relative positional consistency between candidates. If the parent containers of multiple matching controls are different, or their positions on the screen are significantly different (e.g., one at the top and one at the bottom), the target control can be accurately located using relative positioning anchors.

[0078] Assertion reachability checks are used to verify whether each assertion point can be validated when the step is executed. For example, if an assertion shows a user's nickname as a test user, it checks whether there has been an operation or data preparation to retrieve the user's nickname before the step that executes the assertion.

[0079] The idempotency check is achieved by simulating the initial state, repeatedly executing key steps, and performing a consistency comparison on key assertions. Idempotency means that executing the same operation multiple times should yield consistent results. For the test script, if it is executed twice starting from the same initial state, it should produce the same result. If the assertion results of the two executions are inconsistent, it indicates that the script has an idempotency problem, possibly due to some states not being properly cleaned up. The system will prioritize triggering state cleanup and repair actions in its self-healing mechanism.

[0080] In this embodiment, by pre-configuring a waiting strategy and performing multiple checks during the generation phase, the success rate of the generated script on its first execution is significantly improved. The pre-checking mechanism can eliminate explicit defects before the script runs, reducing the time cost of repeated debugging after execution failures.

[0081] Furthermore, in step S5, a self-healing mechanism solves the problem of requiring manual intervention to repair scripts after failure in the prior art.

[0082] The automatic adjustment process based on failure type in step S5 includes: collecting execution evidence, analyzing failure types, and selecting the corresponding adjustment strategy according to the preset mapping relationship between failure types and adjustment strategies.

[0083] The execution evidence includes at least one of the following: screenshots, control tree information, execution logs, and operation timelines.

[0084] Screenshots refer to automatically taking screenshots before and after each key step, used to visually determine whether the UI state meets expectations.

[0085] Control tree information refers to obtaining the complete UI hierarchy structure of the current page, including the attributes of each control (id, class, text, bounds, etc.). This is especially important for analyzing failed location attempts.

[0086] An execution log records information such as the timestamp, operation type, target control, and execution result of each operation, forming a complete operation trajectory.

[0087] An operation timeline records the start time, end time, and waiting time of each step, and is used to analyze timing issues.

[0088] The failure types mentioned in step S5 include at least one of location failure, timing anomaly, business process interference, and status anomaly.

[0089] The system automatically determines the failure type by analyzing execution evidence: When a location failure is detected, the automatic adjustment of the location strategy includes: trying the alternative location candidates in order of priority until the location is successful or all candidates have been traversed.

[0090] When a timing anomaly is detected, the automatic adjustment of the waiting strategy includes: extending the timeout period of the condition wait, adding additional condition waits, or increasing the duration of the delay wait.

[0091] When business process interference is detected, the automatic adjustment of the business process includes: retrieving a matching business sub-process template from the business process knowledge and inserting it into the current execution position.

[0092] When an abnormal status is detected, the automatic adjustment of the business process includes: performing a status cleanup operation, which includes at least one of returning to the initial page, logging in again, or cleaning up test data.

[0093] The number of iterations to be re-executed is set to an upper limit, which is between 5 and 20 times.

[0094] After the automatic adjustment strategy is executed, the script will restart from the failed step. If it fails again, it will continue to analyze the failure type and apply the corresponding adjustment strategy, forming a closed loop of iterative repair.

[0095] Iteration termination conditions include: The script executed successfully, reached the preset maximum number of iterations (default 5-20 times, configurable), and all adjustment strategies were tried but still failed.

[0096] In this embodiment, a self-healing mechanism is used to bring the script from a runnable stage to a stable state without frequent manual intervention. Experimental data shows that out of 100 test cases, approximately 75 cases succeeded on the first execution, 20 cases succeeded after 1-3 self-healing iterations, and only 5 cases failed due to the inability to automatically repair themselves. Compared to traditional methods that require manual repair of each failed script, this method reduces maintenance costs by approximately 70% and improves script stability by approximately 25%.

[0097] Furthermore, step S6 forms a closed loop of knowledge accumulation: knowledge → script → feedback → knowledge, enabling the system to continuously optimize as it is used more.

[0098] Specifically, the updated knowledge base content and priority in step S6 includes: recording successful location candidates, effective waiting strategies, and verified business process templates, and increasing the priority of multiple consecutively successful location candidates or waiting strategies.

[0099] For example, when a location candidate successfully locates the target control, it is recorded in the control location knowledge base, and its success rate statistics are updated. When a waiting strategy successfully avoids timing issues, it is recorded in the waiting timing knowledge base. When a business process template successfully handles business interference, its application scenario and parameter configuration are recorded.

[0100] Priority is increased based on the number of consecutive successes. If a location candidate or waiting strategy succeeds N times consecutively (e.g., N=5), its priority is automatically increased.

[0101] Furthermore, the step of feeding back the successfully executed script information to the knowledge base includes: recording cross-version resource renaming mappings, layout structure mappings, and conditional branch selection rules, forming version adaptation information indexed by device model, system version, and application version.

[0102] The modifications generated after automatic adjustment are recorded in a minimal patch manner, which only includes changes to the positioning strategy, adjustments to waiting parameters, or modifications to business process parameters.

[0103] Furthermore, the verified scripts and their minimum patches will be submitted to the script repository in a versioned manner, and change descriptions and evidence links will be generated.

[0104] In this embodiment of the invention, through a knowledge feedback mechanism, the system develops the ability to learn and continuously optimize itself. Subsequent similar use cases can directly reuse the verified candidate location and waiting strategies, avoiding repeated pitfalls. Experimental data shows that as the knowledge base accumulates, the first-time execution success rate of newly generated scripts gradually increases from approximately 60% to approximately 85%, demonstrating the value of knowledge accumulation. Cross-device and cross-version adaptability is also significantly enhanced, with the universality of the same script on different devices improving by approximately 70%.

[0105] Example 2 This embodiment provides another specific method based on Embodiment 1, including the following specific steps: 1. Basic input and standardization.

[0106] Input: Historical test case scripts, step list (natural language or semi-structured), and information about the test environment (App version, device / system, resolution, etc.).

[0107] The received test case information is parsed and standardized, and extracted and unified into an intermediate representation, which includes steps, positioning methods, assertions, preconditions and dependency data.

[0108] Specifically, for historical test case scripts, the system extracts existing step logic and location methods; for step lists, the system identifies operation descriptions and expected results; for the tested environment information, the system records key parameters such as App version, device model, system version, and resolution. All information undergoes a unified format conversion to form a standardized data structure.

[0109] Output: Standardized corpus.

[0110] 2. Sub-use case analysis.

[0111] Input: Standardized corpus.

[0112] The large model performs in-depth analysis on the standardized corpus, breaking it down into preconditions, step sequence / branch, assertion points, and dependent data relationships, forming an orchestratable use case graph.

[0113] The large model identifies the logical relationships between steps, including sequential execution, conditional branching, and loop structures. It also clarifies the preconditions and postconditions for each step, as well as the data dependencies between steps. For example, it identifies dependencies. The goals and decision boundaries for each step are clearly defined to facilitate subsequent automatic synthesis and checking.

[0114] Output: Structured use case diagram.

[0115] 3. Atomic path location (candidate generation).

[0116] Input: Use case graph, atomic path knowledge base.

[0117] The system generates multiple stable positioning candidates for the target control in each step, including resource-id (ResourceIdentifier), content-desc (Content Description), text, relative positioning, etc., sorted by experience priority, and prepares alternative solutions.

[0118] Historical positioning data for the control is extracted from the atomic path knowledge base, and priorities are determined based on historical success rates and stability metrics. The primary solution is typically the positioning method with the highest historical success rate, while alternative solutions are ranked in order of priority to ensure rapid switching if the primary solution fails.

[0119] Output: Location candidate set (including main solution + alternatives).

[0120] 4. Module Knowledge Enhancement (RAG).

[0121] Inputs: use case graph, candidate location, module-specific knowledge base.

[0122] The system retrieves the business template that best matches the current context, and inserts, replaces, and parameterizes the steps to adapt to differences in channels, regions, languages, etc.

[0123] The retrieval process utilizes a large language model combined with retrieval enhancement generation technology to match the semantic information of the use case graph with business templates in the knowledge base. When a use case is found to be missing certain necessary business processing steps, the corresponding template is automatically inserted. Simultaneously, template parameters are configured based on the tested environment information, such as selecting different text content or validation methods based on the region. This supplements domain knowledge, covers high-risk business paths, and improves effective coverage and portability. Through the automatic insertion of business templates, key business processing steps are avoided, improving the completeness and reliability of test cases.

[0124] Output: Enhanced sequence of steps (including business sub-processes and reinforcement assertions).

[0125] 5. Dynamic waiting optimization.

[0126] Input: Enhanced step sequence, waiting time library.

[0127] The system configures a waiting strategy for each test step based on the waiting timing library, prioritizing conditional waiting, including element visibility, element clickability, list loading completion, animation end, etc. If necessary, a short sleep is added as a fallback, and timeout and small-step retry mechanisms are configured.

[0128] The timeout for conditional waits is determined based on historical statistics in the wait timing library and is typically set to 1.5 times the average wait time. The retry mechanism employs an exponential backoff strategy, performing a limited number of retries after the first timeout to avoid script failures due to occasional network or animation delays.

[0129] Output: A stable sequence of steps with a waiting strategy.

[0130] 6. Script synthesis and consistency verification.

[0131] Input: stable step sequence, location candidate set.

[0132] The stable step sequence and the candidate location set are combined into an executable script based on Appium or uiautomator2, and syntax validation, dependency validation, location ambiguity detection, assertion reachability check and idempotency check are performed.

[0133] In the positioning ambiguity detection stage, when multiple controls matching the same positioning expression are detected on the same screen, the system automatically introduces relative positioning anchors for disambiguation, and makes a joint judgment based on the structural similarity threshold and relative position consistency between candidates. In the idempotency check stage, the system simulates the initial state, repeatedly executes key steps, and performs consistency comparison on key assertions to ensure consistent results across multiple script executions. Explicit defects are eliminated before execution, improving the first-run success rate. Through a multi-verification mechanism, potential problems are intercepted during the script generation stage, avoiding repeated debugging during execution and saving time.

[0134] Output: Executable script (draft) and pre-screening report.

[0135] 7. Execution and self-healing closed loop (can be iterated 5–20 times).

[0136] Input: Executable script, test environment.

[0137] Scripts are run on the mobile automation framework, and execution evidence is collected, including screenshots, short videos, control trees, logs, and timelines. If an execution failure is detected, the system performs targeted automatic repairs based on the failure type. Through iterative repair via a self-healing mechanism, most scripts can be successfully executed after automatic adjustments, with only a few special cases requiring manual intervention.

[0138] Location failure: Automatically switch to alternative location candidates, or add relative location anchor points for precise location; Timing issues: Increase the timeout for conditional waits, or add a short-term retry mechanism; Business Interference: When business process interference such as permission requests, login expiration, or payment confirmation is detected, the corresponding business template sub-process is automatically inserted; Dirty data status: Automatically return to the initial page, log in again, or clean up the test data to restore to a clean initial state; Cross-version differences: Record and update resource renaming maps or layout maps to adapt to UI changes in different versions.

[0139] The script is re-executed immediately after the fix, forming a closed loop of iterative repair. The number of iterations is set to an upper limit of 5 to 20. When the upper limit is reached or all adjustment strategies have been tried but still fail, the iteration is terminated and a detailed failure report is output.

[0140] Output: Self-healing script and a minimal patch list (only changes to location / wait / subprocesses), and execution evidence package.

[0141] 8. Write-back of data and multi-version adaptation.

[0142] Input: The final approved script, patch list, and execution evidence.

[0143] Submit to the test repository using minimal patching, generating change notes and evidence links for easier version management and issue tracing. Synchronously update three types of knowledge bases: adding stable location candidates, business template instances, and pending experience data. If multiple version differences are involved during execution, the system generates version mapping entries and binds them to the script, recording cross-version resource renaming mappings, layout structure mappings, and conditional branch selection rules, forming version adaptation information indexed by device model, system version, and application version.

[0144] The minimum patch only includes changes to the location strategy, adjustments to waiting parameters, or modifications to business process parameters, avoiding changes to irrelevant steps and ensuring the maintainability and traceability of the script.

[0145] Output: Final script artifacts, knowledge base increments, and version adaptation list.

[0146] Through continuous accumulation and optimization of knowledge, the system continuously improves its intelligence level as it is used more often, resulting in higher quality newly generated scripts and less maintenance workload.

[0147] The method provided in this embodiment automates the entire process from test case input to executable script generation, execution, self-healing, and knowledge feedback, significantly improving the efficiency, stability, and maintainability of automated test script generation. Furthermore, the complete process demonstrated in this embodiment has been validated in real-world projects. In applications involving upgrading the O19A mobile phone's automated script to the C3FW_IN version and upgrading to the O19 version, it achieved a mobile automated script generalization rate of over 70%, increased script generation speed by more than 5 times, reduced maintenance costs by approximately 70%, improved script stability by approximately 25%, and shortened adaptation time by 60%, fully demonstrating the effectiveness and practicality of the method of this invention.

[0148] Example 3 This embodiment provides an automated test script generation system. The system implements the methods described in Embodiments 1 and 2 at the hardware level, and provides a detailed design of the connection relationships and data flow between the modules.

[0149] like Figure 2 As shown, it includes: an input processing module, a knowledge base module, a reasoning module, a script generation module, an execution module, a self-healing module, and an update module.

[0150] The input processing module receives test case information and the environment under test, and generates structured test case representations. It connects to the knowledge base module and the inference module via a data interface, passing the structured test case representations to the inference module for further processing.

[0151] The knowledge base module stores control location knowledge, business process knowledge, and waiting time information. The knowledge base module adopts a layered storage architecture: Storage layer: Use a relational database (such as PostgreSQL) to store structured knowledge, and use a vector database (such as Milvus) to store the embedding vectors of knowledge to support similarity retrieval. Index layer: Creates indexes for different types of knowledge, including control name indexes, business scenario indexes, page type indexes, etc.

[0152] Update layer: Supports online incremental updates. When a candidate or waiting strategy is successfully located in multiple tasks, its priority is automatically increased.

[0153] The knowledge base module and the reasoning module are bidirectionally connected: the reasoning module retrieves relevant knowledge entries from the knowledge base and feeds back the results to the knowledge base for updates.

[0154] The knowledge base module's database includes: a control location knowledge table, a business process knowledge table, and a waiting time knowledge table.

[0155] Furthermore, the reasoning module is used to enhance the structured use case representation based on the knowledge base, and to generate multiple location candidates and their priority relationships for the target controls in the test steps.

[0156] This module integrates a large language model and a search-enhanced generation engine.

[0157] In a specific example, the inference module includes the following sub-units: A query vector generator converts structured use case representations into query vectors for similarity retrieval in a knowledge base.

[0158] The knowledge retrieval engine performs similarity searches within the knowledge base module, returning the most relevant knowledge entries for the current test scenario. The engine supports hybrid search strategies, combining keyword matching and semantic similarity.

[0159] The knowledge fusion decision-maker, based on the reasoning ability of a large language model, analyzes the matching degree between the retrieved knowledge items and the current step, and decides whether to insert a business process template, supplement the positioning candidate, or adjust the waiting strategy.

[0160] The location candidate generator generates multiple location candidates for each target control and establishes a priority relationship based on historical success rates in the knowledge base.

[0161] Furthermore, the script generation module is used to generate executable automated test scripts based on the enhanced test case representation and the location candidates.

[0162] In a specific example, the script generation module includes a waiting strategy configuration submodule and a verification submodule. The waiting strategy configuration submodule is used to configure conditional waiting, delayed waiting, timeout time, and retry mechanism for the test steps based on the waiting timing knowledge. The retry mechanism adopts an exponential backoff strategy and a partial step rollback strategy.

[0163] The workflow of the waiting policy configuration submodule includes: Read waiting strategy suggestions from the waiting timing knowledge base; Insert the appropriate wait code for each test step; Configure the timeout period (based on the 90th percentile of historical statistics); Configure retry mechanisms (maximum number of retries, backoff coefficient, rollback strategy).

[0164] The verification submodule is used to perform syntax verification, dependency verification, ambiguity detection, assertion reachability check, and idempotency check on the generated script.

[0165] Once the verification submodule detects a problem, it will provide feedback to the inference module for adjustment, forming a closed-loop optimization.

[0166] The output of the script generation module is an executable Python script file or a script in another format (depending on the target automation framework). This script is then passed to the execution module for execution.

[0167] The execution module is used to run the script and collect execution information.

[0168] The execution module interfaces with a mobile automation testing framework to run scripts, capture screenshots, control tree information, and execution logs. Supported automation frameworks include Appium and uiautomator2, which are familiar to those skilled in the art and will not be elaborated upon further.

[0169] Furthermore, the self-healing module is used to automatically adjust the positioning strategy, waiting strategy, or business process based on the failure type when an execution failure is detected, and to trigger re-execution.

[0170] The self-healing module includes a failure type analyzer, a policy mapper, and a policy executor.

[0171] The failure type analyzer is used to determine the failure type based on execution evidence.

[0172] This failure type analyzer uses a rule engine combined with a machine learning model: Rule engine: performs rule matching based on features such as exception type, error message keywords, and control tree differences.

[0173] Machine learning model: Classifies and predicts complex failure scenarios; the model is trained using historical failure cases.

[0174] The strategy mapper is used to select the corresponding adjustment strategy based on the mapping relationship between failure type and adjustment strategy, and the mapping relationship supports online updates with running statistics.

[0175] The policy executor is used to execute the selected adjustment policy and trigger re-execution.

[0176] The strategy executor calls the retry and state rollback interfaces provided by the execution module, applies the corresponding adjustment actions, and monitors the adjustment effects. If the adjustment is successful, the result is fed back to the update module; if it fails, it switches to the next candidate strategy to continue trying.

[0177] The self-healing module is closely connected with the execution module, inference module, and update module, forming a closed loop of automatic repair.

[0178] Furthermore, the update module is used to feed back the information of successfully executed scripts to the knowledge base, and update the content and priority of the knowledge base.

[0179] The various modules of this system are connected through standardized data interfaces, forming a clear data flow path.

[0180] First, the input processing module receives test case information and the environment under test, generates a structured test case representation, and passes it to the inference module. The inference module establishes a bidirectional connection with the knowledge base module, retrieving relevant control location knowledge, business process knowledge, and waiting timing knowledge from the knowledge base to enhance the structured test case representation. Simultaneously, it generates multiple location candidates and their priority relationships for the target controls in the test steps. The enhanced test case representation and the set of location candidates are then passed to the script generation module.

[0181] The generated script undergoes pre-validation, including syntax checking, dependency checking, ambiguity detection, assertion reachability checks, and idempotency checks, ultimately producing an executable automated test script. This script is then passed to the execution module for execution.

[0182] The execution module runs scripts on a mobile automation framework and collects execution evidence in real time, including screenshots, control tree information, execution logs, and operation timelines. When an execution failure is detected, the execution module passes the execution results and evidence to the self-healing module. The self-healing module analyzes the failure type, selects the appropriate adjustment strategy based on the preset mapping relationship between failure types and adjustment strategies, and feeds back the adjusted strategy to the execution module for re-execution, forming a self-healing closed loop. This process can iterate 5 to 20 times until the script executes successfully or the iteration limit is reached.

[0183] Once the script executes successfully, the execution module passes the successful execution information to the update module. The update module extracts valuable knowledge and feeds this knowledge back to the knowledge base module for updates, while also increasing the priority of candidates or waiting strategies that have been successfully located multiple times consecutively.

[0184] The data flow of this system is divided into three main paths: First, the forward process is: input processing → structured representation → knowledge enhancement → script generation → execution; Second, the self-healing process is: execution failure → self-healing adjustment → re-execution; Third, the feedback process is: successful execution → knowledge update → accumulation and optimization.

[0185] Through the synergistic effect of these three data streams, the system forms a complete closed loop from input to output and from execution to feedback, enabling continuous accumulation of knowledge and continuous optimization of system capabilities.

[0186] This invention also provides an electronic device, which may be a server, computer, or other similar device.

[0187] The electronic device may include a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the method as described in the foregoing embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0188] For ease of explanation, only one processor is described in the above-described electronic device. However, it should be noted that in some embodiments, the electronic device of the present invention may also include multiple processors. Therefore, the steps performed by one processor as described in the present invention may also be performed jointly or individually by multiple processors. For example, if the processor of the electronic device performs steps A and B, it should be understood that steps A and B may also be performed jointly by two different processors or individually by one processor. For example, a first processor performs step A, a second processor performs step B, or a first processor and a second processor jointly perform steps A and B, etc.

[0189] In some embodiments, the processor may include one or more processing cores (e.g., a single-core processor (S) or a multi-core processor (S)). By way of example only, the processor may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), an application-specific instruction-set processor (ASIP), a graphics processing unit (GPU), a physical processing unit (PPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a microcontroller unit, a reduced instruction set computing (RISC) computer, or a microprocessor, or any combination thereof.

[0190] Accordingly, other embodiments of this application may also provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the various method embodiments of this application. Computer-readable storage media include permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information may be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0191] This invention discloses an automated test script generation method, system, storage medium, and electronic device. By converting test case information into a structured representation, combined with knowledge base enhancement and large model reasoning, the script generation speed is increased by more than 5 times compared to traditional manual writing or recording and playback methods. Regarding maintenance costs, by preparing multiple location candidates for each control and establishing priority relationships, combined with a self-healing mechanism, approximately 90% of the scripts can automatically repair themselves after UI changes, reducing maintenance costs by about 70%. Regarding script stability, through intelligent configuration waiting strategies, idempotency checks, and state cleanup mechanisms, script stability is improved by about 25%, and the occasional failure rate is reduced from about 20% to about 5%. Regarding knowledge accumulation, by feeding back information from successfully executed scripts to the knowledge base, a closed-loop accumulation of knowledge-script-feedback-knowledge is formed. Regarding cross-version adaptation, the number of scripts requiring modification during cross-device adaptation is reduced from about 60% to about 15%, significantly reducing the workload of adaptation. In terms of self-healing capabilities, through failure type analysis, strategy mapping, and iterative repair mechanisms, approximately 75% of use cases succeed on the first execution, 20% of use cases succeed after 1 to 3 self-healing attempts, and only 5% require manual intervention.

[0192] In summary, this invention systematically solves the technical problems of high maintenance costs, poor stability, and lack of domain knowledge in existing automated test scripts by organically combining knowledge base enhancement, multi-candidate localization, and self-healing mechanisms, forming a set of automated testing solutions that can be continuously optimized, reused, and migrated.

[0193] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for generating automated test scripts, characterized in that, include: Receive test case information and test environment information, and generate structured test case representations; The structured use case representation is enhanced based on a preset knowledge base, which includes control location knowledge, business process knowledge, and waiting timing knowledge. Multiple location candidates are generated for the target control in the testing step, and a priority relationship is established between the location candidates; Based on the enhanced use case representation and the location candidates, an executable automated test script is generated; When the script is run, if an execution failure is detected, the positioning strategy, waiting strategy, or business process will be automatically adjusted based on the failure type, and the script will be re-executed. The information of successfully executed scripts is fed back to the knowledge base, updating the content and priority of the knowledge base.

2. The automated test script generation method according to claim 1, characterized in that, The enhancement of the structured use case representation based on the preset knowledge base includes: retrieving knowledge items related to the current test scenario from the knowledge base by combining a large language model with retrieval enhancement generation technology, and integrating the retrieval results into the structured use case representation.

3. The automated test script generation method according to claim 1, characterized in that, The location candidates include at least one of resource identifier location, content descriptor location, text matching location, path location, and relative location anchor.

4. The automated test script generation method according to claim 1, characterized in that, The priority relationship between the positioning candidates is determined based on historical execution success rate statistics and is dynamically adjusted with new execution results.

5. The automated test script generation method according to claim 1, characterized in that, The process of generating an executable automated test script includes configuring a waiting strategy for the test steps in the script based on the waiting timing knowledge.

6. The automated test script generation method according to claim 1, characterized in that, Before generating the executable automated test script, the method further includes: pre-validating the script, wherein the pre-validation includes at least one of syntax validation, dependency validation, ambiguity detection, assertion reachability check, and idempotency check.

7. The automated test script generation method according to claim 1, characterized in that, The automatic adjustment process based on failure type includes: collecting execution evidence, analyzing failure types, and selecting the corresponding adjustment strategy according to the preset mapping relationship between failure types and adjustment strategies; The execution evidence includes at least one of the following: screenshots, control tree information, execution logs, and operation timelines.

8. The automated test script generation method according to claim 7, characterized in that, The failure types include at least one of location failure, timing anomaly, business process interference, and status anomaly.

9. The automated test script generation method according to claim 8, characterized in that, When a location failure is detected, the automatic adjustment of the location strategy includes: trying the alternative location candidates in order of priority until the location is successful or all candidates have been traversed; When a timing anomaly is detected, the automatic adjustment of the waiting strategy includes: extending the timeout period of the condition wait, adding additional condition waits, or increasing the duration of the delay wait; When business process interference is detected, automatic adjustment of the business process includes: retrieving a matching business sub-process template from the business process knowledge and inserting it into the current execution position; When an abnormal status is detected, the automatic adjustment of the business process includes: performing a status cleanup operation, which includes at least one of returning to the initial page, logging in again, or cleaning up test data.

10. The automated test script generation method according to claim 1, characterized in that, The number of iterations to be re-executed is set to an upper limit, which is between 5 and 20 times.

11. The automated test script generation method according to claim 1, characterized in that, The updated knowledge base includes the following content and priorities: recording successful location candidates, effective waiting strategies, and verified business process templates, and increasing the priority of multiple consecutively successful location candidates or waiting strategies.

12. The automated test script generation method according to claim 1, characterized in that, The process of feeding back the successfully executed script information to the knowledge base includes: recording cross-version resource renaming mapping, layout structure mapping, and conditional branch selection rules, forming version adaptation information indexed by device model, system version, and application version.

13. An automated test script generation system, characterized in that, include: The input processing module is used to receive test case information and test environment information, and generate structured test case representations; The knowledge base module stores control location knowledge, business process knowledge, and waiting timing knowledge. The reasoning module is used to enhance the structured use case representation based on the knowledge base and generate multiple location candidates and their priority relationships for the target controls in the test steps; The script generation module is used to generate executable automated test scripts based on the enhanced test case representation and the location candidates; The execution module is used to run the script and collect execution information; The self-healing module is used to automatically adjust the positioning strategy, waiting strategy or business process based on the failure type when an execution failure is detected, and trigger re-execution. The update module is used to feed back information about successfully executed scripts to the knowledge base and update the content and priority of the knowledge base.

14. The automated test script generation system according to claim 13, characterized in that, The script generation module includes a waiting policy configuration submodule and a verification submodule; The waiting strategy configuration submodule is used to configure conditional waiting, delayed waiting, timeout time and retry mechanism for the test steps based on the waiting timing knowledge. The verification submodule is used to perform syntax verification, dependency verification, ambiguity detection, assertion reachability check, and idempotency check on the generated script.

15. The automated test script generation system according to claim 13, characterized in that, The self-healing module includes a failure type analyzer, a policy mapper, and a policy executor. The failure type analyzer is used to determine the failure type based on execution evidence; The strategy mapper is used to select the corresponding adjustment strategy according to the mapping relationship between failure type and adjustment strategy, and the mapping relationship supports online updates with running statistics; The policy executor is used to execute the selected adjustment policy and trigger re-execution.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the automated test script generation method as described in any one of claims 1 to 12.

17. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the automated test script generation method as described in any one of claims 1 to 12.

Images