Automatic testing method and device, electronic equipment and computer storage medium

Abstract

The invention relates to an automatic testing technology, and provides an automatic testing method and device, electronic equipment and a computer storage medium, and the method comprises the steps: obtaining a test task for a target test scene, the target test scene comprises a plurality of preset sub-services; according to the basic test knowledge and the self-defined test knowledge of each preset sub-service, constructing a target agent of each preset sub-service, the target agent being used for planning a test process corresponding to the preset sub-service; and performing automatic testing on the test task by utilizing the target intelligent agents of the plurality of preset sub-businesses. The automatic testing efficiency can be improved.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology, and more specifically, to an automated testing method, apparatus, electronic device, and computer storage medium. Background Technology

[0002] Traditional automated testing tools typically employ techniques such as recording test operation sequences and replaying them to automate testing, locating interface elements based on element identifiers and coordinates, simulating user operations such as clicking, swiping, and inputting, and checking whether the expected results match the actual results. These techniques usually use predefined linear execution flows and cannot cope with dynamically changing test scenarios.

[0003] Large-scale model-based automated testing can understand natural language task descriptions, analyze screenshots to identify the state of the graphical user interface, and decide on the next operation based on reasoning. Although this approach can cope with the dynamic changes of the graphical user interface to some extent compared to traditional automated testing tools, the efficiency of automated testing is not high due to the long reasoning time and low decision-making efficiency. Summary of the Invention

[0004] The purpose of this invention is to provide an automated testing method, apparatus, electronic device, and computer storage medium that can improve the efficiency of automated testing.

[0005] The embodiments of the present invention can be implemented as follows: In a first aspect, the present invention provides an automated testing method, the method comprising: Obtain test tasks for a target test scenario, wherein the target test scenario includes multiple preset sub-services; Based on the basic test knowledge and custom test knowledge of each preset sub-service, a target intelligent agent is constructed for each preset sub-service. The target intelligent agent is used to plan the test process of the corresponding preset sub-service. The test task is automated by using the target intelligent agents of the multiple preset sub-services.

[0006] In an optional implementation, the test task includes multiple operation objects, and the step of automating the test task using the target intelligent agents of the multiple preset sub-services includes: Based on the preset sub-service to which the test operation performed by each operation object belongs, create a smart instance of a corresponding target smart agent for each operation object; The test task is executed using intelligent instances of the multiple operation objects to automate the testing of the test task.

[0007] In an optional implementation, the step of using intelligent instances of the plurality of operational objects to execute the test task to complete the automated testing of the test task includes: Obtain the state transition diagram of the test task, which includes a start state, an end state, and an abnormal termination state. Determine the target intelligent instance associated with the starting state from among the multiple intelligent instances; Assign a target device to the target smart instance from the device resource pool; The target intelligent instance is started, and based on the target intelligent instance's own state, the knowledge of the operation process of the preset sub-services possessed by the corresponding target intelligent agent, and the state transition diagram, the target device is controlled to execute the state transition process until the end state or the abnormal termination state is reached, thereby completing the automated testing of the test task.

[0008] In an optional implementation, after the step of activating the target smart instance, the following steps are included: When a control transfer request is received from any started smart instance, the current execution state is saved. The control transfer request is issued by the started smart instance when it detects that the smart instance related to the next state to be transitioned is not itself. From the plurality of said smart instances, determine the takeover smart instance associated with the next state to be transitioned; Assign takeover devices to the takeover smart instance from the device resource pool; The takeover smart instance is activated to control the takeover device to perform a state transition process.

[0009] In an optional implementation, the test task includes test actions, operation objects, exception handling, and verification processing, and the step of obtaining the state transition diagram of the test task includes: The state after each step of the test action is executed, the initialization state of the operation object, the state after exception handling, and the state after verification processing are respectively regarded as state vertices; The state transition diagram is obtained by determining the transition relationships between the state vertices based on the triggering conditions of the test actions, exception handling, and verification handling.

[0010] In an optional implementation, the step of obtaining the test task for the target test scenario includes: Receive test requirements described in natural language from the user for the target test scenario; The test requirements are transformed into a declarative task description language to obtain the test task.

[0011] In an optional implementation, the step of constructing the target agent for each preset sub-service based on the basic test knowledge and custom test knowledge of each preset sub-service includes: Based on the basic test knowledge and custom test knowledge of each preset sub-service, a knowledge graph of each preset sub-service is constructed so that the target intelligent agent of each preset sub-service can plan the business test process of the corresponding preset sub-service based on the corresponding knowledge graph. Encapsulate a query interface for querying knowledge graphs; Based on the knowledge graph and query interface of each preset sub-service, a target intelligent agent for each preset sub-service is constructed.

[0012] In a second aspect, the present invention provides an automated testing device, the device comprising: The acquisition module is used to acquire test tasks for a target test scenario, wherein the target test scenario includes multiple preset sub-services; A construction module is used to construct a target intelligent agent for each preset sub-service based on the basic test knowledge and custom test knowledge of each preset sub-service. The target intelligent agent is used to plan the test process of the corresponding preset sub-service. The testing module is used to automate the testing tasks by utilizing the target intelligent agents of the multiple preset sub-services.

[0013] Thirdly, the present invention provides an electronic device including a processor and a memory, the memory being used to store a program, and the processor being used to implement the automated testing method as described in any of the foregoing embodiments when executing the program.

[0014] Fourthly, the present invention provides a computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the automated testing method as described in any of the foregoing embodiments.

[0015] Compared with the prior art, the present invention has the following beneficial effects: This invention identifies a target intelligent agent for each of the multiple preset sub-services included in the target test scenario. The target intelligent agent for each preset sub-service is constructed based on the basic test knowledge and custom test knowledge of that preset sub-service. This target intelligent agent is used to plan the test process for the corresponding preset sub-service. Multiple target intelligent agents are used to automate the test tasks. Since each target intelligent agent is constructed based on the basic test knowledge and custom test knowledge of each preset sub-service, the specialization of the target intelligent agent is improved. The coordinated operation of multiple specialized target intelligent agents shortens the inference time and improves decision-making efficiency in automated testing, thereby enhancing the efficiency of automated testing. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is an example diagram illustrating the business process for paying fans in a live streamer testing scenario.

[0018] Figure 2 This is an example diagram of the system layered architecture provided in this embodiment.

[0019] Figure 3 The embodiment provided is based on Figure 2 Example diagram of the operation process of paid fans.

[0020] Figure 4 This is a flowchart illustrating the automated testing method provided in this embodiment.

[0021] Figure 5 This is an example diagram of the hierarchical knowledge structure of an agent in the live streaming testing domain provided in this embodiment.

[0022] Figure 6 An example diagram of a finite state machine for testing paid fans in this embodiment.

[0023] Figure 7 This is a flowchart illustrating the concurrent execution of intelligent instances for paid fan testing provided in this embodiment.

[0024] Figure 8 Provided for this embodiment Figure 7 Example flowchart of the transfer of control in the process.

[0025] Figure 9 This is a block diagram of the automated testing device provided in this embodiment.

[0026] Figure 10 This is a block diagram of the electronic device provided in this embodiment.

[0027] Icons: 10-Electronic device; 11-Processor; 12-Memory; 13-Bus; 100-Automatic test device; 110-Acquisition module; 120-Building module; 130-Test module. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0029] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0030] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0031] In the description of this invention, it should be noted that if terms such as "upper," "lower," "inner," or "outer" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship in which the product of this invention is usually placed, they are only for the convenience of describing this invention and 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, and therefore should not be construed as a limitation of this invention.

[0032] Furthermore, the terms "first" and "second" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0033] It should be noted that, where there is no conflict, the features in the embodiments of the present invention can be combined with each other.

[0034] Existing mobile applications, especially social and live streaming applications, typically involve automated testing for multi-user interaction scenarios. In order to more clearly analyze the inefficiencies in this testing scenario, this embodiment uses a typical testing scenario of paying to become a streamer's fan in a preset platform as an example to illustrate the analysis process.

[0035] Test scenario: Becoming a streamer's fan by paying for live streaming on the platform; Test objective: To verify the complete business process of user A paying to become a fan of streamer B; The test involved several business systems: 1. Live Streaming System: managing live streaming rooms and fan relationships; 2. Payment System: handling payment and recharge processes; 3. User System: updating user status and benefits; Key points to verify: Users can successfully enter the streamer's live room; the payment process is completed correctly (including recharging when the balance is insufficient); fan relationships are established correctly; the status of both parties is updated synchronously; and fan rights are activated correctly.

[0036] Please refer to Figure 1 , Figure 1 This is an example diagram illustrating the business process for paying fans in a live streamer testing scenario. Figure 1 In this scenario, users and streamers each correspond to two different devices: Device 1 and Device 2. From user A's perspective on Device 1, the workflow includes: logging into user A's account; entering streamer B's live stream room; clicking to become a fan; selecting a payment level (x yuan / month); completing the payment; verifying the fan badge display; and verifying the activation of exclusive benefits. From streamer B's perspective on Device 2, the workflow includes: logging into streamer B's account; viewing the current number of fans (1520); verifying the fan count update (1521); and verifying that the fan list includes user A.

[0037] Figure 1 Due to the limitation of a single device, it is impossible to log in to two accounts simultaneously, making it impossible to verify the real-time synchronization of the status between the two parties. Furthermore, traditional automated testing tools are used for testing... Figure 1 When applied to certain scenarios, at least the following drawbacks still exist: (1) Vulnerability: For example, after the identifier of the button to become a fan is changed from "fan_button" to "become_fan_btn", the original test script will not work properly and will need to be manually re-recorded or modified.

[0038] (2) Linear thinking: The predefined linear execution process cannot cope with dynamically changing test scenarios.

[0039] To overcome the shortcomings of traditional automated testing tools, large language models are typically used to understand natural language task descriptions, analyze screenshots to identify graphical user interface states, and determine the next action based on reasoning. While large language models can understand the semantic meaning of "become a fan" and can cope with changes in the user interface to some extent, they still have the following shortcomings when dealing with complex business scenarios such as business interactions: (1) Knowledge overload leads to decision-making difficulties Such a large model, acting as a single intelligent agent, needs to simultaneously master knowledge from multiple domains, including live streaming operations (live streaming room management, fan relationships), payment operations (payment processes, recharge mechanisms), and user operations (account systems, permission management). This mixture of knowledge leads to "choice paralysis" for the single intelligent agent when faced with complex scenarios, resulting in excessively long reasoning times and low decision-making efficiency.

[0040] (2) The fundamental limitations of single-device architecture The single-device architecture is based on the design concept of one agent controlling one device, attempting to solve all problems with a general agent. This architecture cannot effectively handle test scenarios that require multi-user collaboration.

[0041] Through analysis of the two automated testing methods mentioned above, the inventors summarized the main core issues: (1) Business understanding dilemma: Existing methods all attempt to use general intelligent agents to understand and process specific business logic. This "jack-of-all-trades" design is destined to fail to deeply understand complex business scenarios.

[0042] (2) Multi-device coordination problem: Existing testing methods either do not support multiple devices or simply associate one agent with one device, lacking a flexible and efficient device scheduling mechanism.

[0043] (3) Insufficient ability to handle exceptions: When faced with business exceptions such as insufficient balance and need to recharge, existing testing methods generally lack intelligent handling strategies.

[0044] (4) Lack of knowledge management: Testing experience and business knowledge cannot be effectively accumulated and reused, and each test has to start from scratch.

[0045] In view of this, this embodiment provides an automated testing method, apparatus, electronic device, and computer storage medium. It plans the testing process of each preset sub-service based on the basic testing knowledge and custom testing knowledge of each preset sub-service, which improves the specialization of the target intelligent agent. The same collaboration of multiple specialized target intelligent agents shortens the inference time in automated testing and improves decision-making efficiency, thereby improving the efficiency of automated testing. It will be described in detail below.

[0046] This embodiment introduces a layered architecture approach, dividing the automated testing system into four layers: user interface layer, main control layer, business expert layer, and resource management layer. Please refer to [reference needed]. Figure 2 , Figure 2 This is an example diagram of the system layered architecture provided in this embodiment. Figure 2In this framework, the user interface layer provides a user-friendly interface for inputting test tasks, allowing users to describe them using natural language. The main control layer intelligently coordinates and manages the test process. For example, it describes the test task flow as a finite state machine, with the main agent responsible for decomposing and scheduling test tasks, and coordinating collaboration among multiple agents. The task scheduler assigns the decomposed test tasks to appropriate agents. The business expert layer comprises pre-defined expert groups for specific domains, such as live streaming test experts, payment test experts, user test experts, and other business expert groups. Based on a concurrent computing model, the business expert layer assigns different test domains within a test task to corresponding business experts. Each expert can make test decisions in parallel based on their professional knowledge. The resource management layer provides the various resources and infrastructure required for test tasks. For example, a device pool provides devices for executing test operations, a knowledge base provides hierarchical management of knowledge from various business experts, and a message queue supports message passing mechanisms. Business experts are not bound to specific devices; instead, they are dynamically coordinated from the device pool when needed, improving device utilization.

[0047] To provide a more intuitive understanding of the layered architecture described above, this embodiment combines... Figure 1 The test scenario will be described below. Please refer to... Figure 3 , Figure 3 The embodiment provided is based on Figure 2 A diagram illustrating the workflow of paid fans. Figure 3 In the test task, the user inputs a natural language description of "testing the paid fan-to-follower function". The main agent, acting as the main coordinator, understands the test task, performs test planning, generates a test plan, and identifies the business domain experts involved in the test task: live streaming test business domain expert, payment test business domain expert, and user test business domain expert. Based on the device dynamic control mechanism, when each business domain expert needs it, the device resource pool is allocated to the corresponding business domain expert for control.

[0048] Based on an understanding of the system's layered architecture, the automated testing method provided in this embodiment will be introduced next. Please refer to [link / reference]. Figure 4 , Figure 4 This is a flowchart illustrating the automated testing method provided in this embodiment. The method includes the following steps: Step S101: Obtain test tasks for the target test scenario, which includes multiple preset sub-services.

[0049] In this embodiment, the test task can be based on a preset description template, analyzing the test requirements described in natural language input by the user, and converting them into a declarative task description language format. It should be noted that the user can also fine-tune the initial declarative task description language format to ultimately form a test task that accurately describes the test requirements.

[0050] In this embodiment, the preset sub-services may include several functional modules or business process units that may be triggered during the testing process, such as login process, payment process, data synchronization process, etc. Each preset sub-service has a relatively independent operation process, and these processes are usually composed of a series of predefined operation steps, which are repeatable and predictable.

[0051] Step S102: Based on the basic test knowledge and custom test knowledge of each preset sub-service, construct the target intelligent agent for each preset sub-service. The target intelligent agent is used to plan the test process of the corresponding preset sub-service.

[0052] In this embodiment, the target intelligent agent may include a software entity possessing knowledge of the corresponding preset sub-service operation process. The target intelligent agent is constructed based on the basic testing knowledge and custom testing knowledge of the corresponding preset sub-service. The testing process of the preset sub-service includes, but is not limited to, the normal process, the exception handling process, and the interaction process with other sub-services. The core of the target intelligent agent lies in its ability to automatically deduce the next execution action based on the current state and historical behavior. As one implementation method, the target intelligent agent can be based on a framework combining reasoning and acting. Based on this framework, the target intelligent agent can interactively combine the thinking process and external actions to perform dynamic reasoning to create, maintain, and adjust the operation plan, so as to make reasonable decisions and inferences for the next test.

[0053] Step S103: Automated testing of the test task is performed using target intelligent agents from multiple preset sub-businesses.

[0054] In this embodiment, each target intelligent agent collaborates to execute the test task based on its corresponding preset sub-service knowledge. Specifically, the execution of the test task is not completed independently by a single intelligent agent, but is achieved through state perception, task scheduling, and process switching among multiple intelligent agents. Each target intelligent agent is responsible for the test process control of its corresponding sub-service, including but not limited to the generation of operation sequences, the call for device resources, and the judgment of state transitions.

[0055] The method provided in this embodiment allows each target agent to plan its own business testing process based on its own preset sub-business basic testing knowledge and custom testing knowledge, thereby improving the specialization of the target agents. The same collaboration of multiple specialized target agents shortens the inference time in automated testing, improves decision-making efficiency, and thus enhances the efficiency of automated testing.

[0056] In an optional implementation, to make the description of the test task more natural and accurate, this embodiment provides an implementation method for obtaining the test task: First, receive test requirements described in natural language from users for the target test scenario; In this embodiment, the test requirements described in natural language can be the specific test content that the user wants the test system to perform, described by the user through conventional text input methods (such as voice input, keyboard input, and filling out an interface form). For example, the user can enter the test requirement "Test user A pays to become a fan of streamer B, user balance x yuan, fan fee y yuan / month" on the test configuration interface. This test requirement implicitly includes several preset sub-businesses, such as user login, streamer login, and user payment. These sub-businesses will be processed by the corresponding target intelligent agents in subsequent steps.

[0057] Secondly, the test requirements are transformed into a declarative task description language to obtain the test tasks.

[0058] In this embodiment, the declarative task description language may include a task description format with structured syntax and semantic definitions. It can explicitly describe the goals, constraints, expected states, and key behavioral paths of a test task through declarative statements, rather than the specific execution flow. In practical applications, this conversion process is completed collaboratively by a natural language processing engine and a task parser. The natural language processing engine is responsible for semantically parsing the user-inputted test requirements, extracting key operational objects, business processes, and related constraints. The task parser then generates a structured test task according to the extracted information and a preset declarative syntax format.

[0059] To more accurately meet users' testing needs, users can also adjust and improve the generated descriptions. For example, users can add "network error" handling: retry 3 times, timeout 30 seconds, so as to describe the testing requirements more accurately and comprehensively.

[0060] In an optional implementation, in response to the problems of difficult knowledge retrieval, complex updates, and poor reusability caused by the mixed knowledge of the intelligent agent in traditional testing methods, this embodiment constructs the target intelligent agent based on a two-layer knowledge system architecture. While achieving efficient management of knowledge, it enables the target intelligent agent to have more professional business testing knowledge and to plan the testing process of the corresponding preset sub-business more professionally.

[0061] In this embodiment, the two-layer knowledge system architecture includes a common foundational knowledge layer and a domain-specific knowledge layer. General process knowledge can be found in the common foundational knowledge layer, while custom process knowledge can be found in the domain-specific knowledge layer. The common foundational knowledge layer stores general testing knowledge shared by all target agents, including basic user interface operation knowledge (how to click, swipe, and input text), general verification methods (text matching, numerical comparison, element existence checks), basic exception handling strategies (timeout retries, network anomaly recovery, application crash handling), and test management-related knowledge (log recording, screenshot saving, report generation). This knowledge is universal and applicable to all types of mobile application testing. The domain-specific knowledge layer stores specialized knowledge for each business domain.

[0062] For professional knowledge in the live streaming testing domain, the two-layer knowledge reminder architecture includes general knowledge of the live streaming platform and platform-specific knowledge. General knowledge includes the live streaming room state model, the interaction methods between the streamer and the audience, and the general process of gift-giving. Platform-specific knowledge includes the platform's unique UI layout, the specific rules of the fan system, and solutions to known problems. Similarly, payment testing knowledge is divided into general payment knowledge (payment security specifications, common payment anomalies) and platform-specific payment knowledge (platform-specific currency system, recharge discount rules). This example uses the live streaming testing domain to illustrate the architecture of the two-layer knowledge system; please refer to [reference needed]. Figure 5 , Figure 5 This is an example diagram of the hierarchical knowledge structure of an agent in the live streaming testing domain provided in this embodiment. Figure 5 In this context, the professional knowledge of live streaming testing comprises two layers: The first layer: common foundational knowledge – basic testing knowledge shared by all intelligent agents; the second layer: domain knowledge – professional knowledge specific to each business domain. The first layer of common foundational knowledge includes, but is not limited to, basic user interface operations, general verification methods, basic exception handling, and test management. The second layer of live streaming testing domain knowledge also covers the professional knowledge of each business domain, including, but not limited to, knowledge of pre-defined sub-businesses such as live streaming testing, payment testing, and user testing. The knowledge of each pre-defined sub-business includes general knowledge related to that sub-business and business knowledge of the pre-defined platform.

[0063] Specifically, the knowledge domain for live streaming testing includes general live streaming knowledge and platform-specific knowledge. General live streaming knowledge includes, but is not limited to, live streaming room state models, streamer permission systems, audience interaction modes, and gift-giving processes. Platform-specific knowledge includes, but is not limited to, user interface element positioning, business rules (fan system), known issues, and solutions. The knowledge domain for payment testing includes general payment knowledge and platform-specific payment knowledge. General payment knowledge includes, but is not limited to, payment process standards, payment security requirements, and anomaly handling strategies. Platform-specific payment knowledge includes, but is not limited to, the platform's currency system, recharge rules and restrictions, and third-party payment integration. The knowledge domain for user testing includes general user knowledge and platform-specific user knowledge. General user knowledge includes, but is not limited to, account systems, permission management, and state transitions. Platform-specific user knowledge includes, but is not limited to, user level reminders, fan identity identification, and activation mechanisms.

[0064] It should be noted that, Figure 5 This is just one example of a layered knowledge structure. For different testing scenarios, corresponding layered knowledge structures can be constructed according to the needs of specific testing scenarios.

[0065] based on Figure 5 In the paid fan testing, the AI ​​agent of the live streaming testing sub-business demonstrated profound professional capabilities. This agent possessed a complete knowledge system of the preset platform's live streaming, including the live stream's state model (preparing, live, replaying, ended), the streamer's permission system (regular streamers, contracted streamers, guild streamers), the fan system rules (fan levels, benefits, renewal mechanisms), and the operation of the gift system. During testing, the live streaming testing sub-business's AI agent knew how to efficiently locate streamers (using room numbers instead of nicknames), understood the positional changes of user interface elements (the fan button's position differed depending on the streamer type), and could handle various abnormal situations (such as a streamer temporarily ending their broadcast or live stream audience limits).

[0066] The AI ​​agent for the payment testing sub-business also demonstrated its expertise in the field. It not only understood general payment processes but also mastered the payment system specific to the pre-set platform, including the platform's exchange rules, recharge tiers and promotional strategies (recharge x yuan and get y yuan free), payment method priorities, and methods for handling various payment anomalies. When dealing with insufficient balance, the AI ​​agent could quickly make a decision: upon detecting insufficient balance to pay x yuan, it immediately chose to recharge y yuan (more than x yuan) because it knew the platform's minimum recharge amount was y yuan, and recharging y yuan ensured that the insufficient balance issue would not recur in subsequent tests.

[0067] It should be noted that in this embodiment, knowledge can be organized using a graph structure, with intelligent instances connected through relationships. For example, the "Fan Button" entity is connected to "bottom right corner of the live stream" through the "located" relationship, to "Fan Panel" through the "triggered" relationship, and to "Login Status" through the "required" relationship. This structured organization supports complex knowledge reasoning. The knowledge reasoning mechanism can derive new conclusions based on existing knowledge. For example, when dealing with the "insufficient balance" problem, the reasoning process is as follows: query public knowledge to understand the definition of "insufficient balance" (current balance is less than the required amount), query payment domain knowledge to understand the processing options (recharge, change payment method, reduce amount), query preset platform-specific knowledge to obtain the recharge rules (minimum recharge of y yuan), and comprehensively reason to derive the optimal solution (recharge y yuan to ensure sufficient balance and avoid frequent recharges).

[0068] Based on the above two-layer knowledge architecture, this embodiment also provides at least two ways to construct the target intelligent agent.

[0069] Method 1: First, based on the basic test knowledge and custom test knowledge of each preset sub-service, a knowledge graph of each preset sub-service is constructed so that the target intelligent agent of each preset sub-service can plan the business test process of the corresponding preset sub-service based on the corresponding knowledge graph. In this embodiment, the knowledge graph of the preset sub-business provides a structured knowledge representation for the corresponding preset sub-business domain, enabling the target intelligent agent to plan and reason about the test process based on the knowledge graph. The knowledge graph can be represented by a graph structure, where entity nodes represent test objects or operations, and edges represent the relationships between them, thus forming a semantically rich and scalable knowledge network.

[0070] Secondly, encapsulate the query interface for querying the knowledge graph; In this embodiment, the query interface may include capabilities such as entity retrieval, relationship query, and path reasoning. For example, when the target agent in a live test needs to determine the location of the "follower button," it can call the interface to query the "location" relationship between the "follower button" and the "bottom right corner of the live stream," thereby obtaining accurate location information from the graphical user interface. This query interface design not only improves the accessibility of knowledge but also enhances the modularity and maintainability of knowledge management.

[0071] Finally, based on the knowledge graph and query interface of each preset sub-business, the target intelligent agent of each preset sub-business is constructed.

[0072] This method of constructing target intelligent entities using knowledge graphs can effectively improve the accuracy and adaptability of test process planning, enabling target intelligent entities to make more reasonable decisions when facing complex and ever-changing test scenarios.

[0073] Method 2: First, based on the basic test knowledge and custom test knowledge of each preset sub-business, the training corpus of the question-answering model for each preset sub-business is constructed. In this embodiment, the training corpus for the question-answering model is a training dataset used to fine-tune the larger model. The basic and custom test knowledge for each preset sub-business is systematically organized into question-answer pairs, constituting the training corpus for the question-answering model. This corpus guides the larger model to understand the testing process and operational logic of a specific sub-business. Taking live streaming testing as an example, the corpus content includes, but is not limited to, questions such as: "How to determine if a user has successfully entered the live stream?", "What interface changes should be triggered after clicking the follower button?", and "What are the verification methods for updating the number of followers of the streamer?" and their corresponding standard answers. These questions and answers can originate from explicit modeling of business rules, summarization of historical test cases, and solutions to known problems.

[0074] Secondly, the large model is fine-tuned based on the corpus of the question-answering model for each preset sub-business to obtain the target intelligent agent for each preset sub-business.

[0075] This large-scale model fine-tuning approach, driven by question-and-answer corpora, effectively enhances the semantic understanding and operation generation capabilities of the target intelligent agent in complex testing scenarios, enabling it to automatically generate reasonable test procedures based on the description of the test task.

[0076] After constructing the target intelligent agent for each preset sub-business, for test tasks involving multiple operation objects, in order to better meet the testing requirements for interactions between multiple operation objects, this embodiment also provides an implementation method: First, based on the preset sub-business to which the test operation performed by each operation object belongs, create a corresponding intelligent instance of the target intelligent agent for each operation object; Secondly, test tasks are executed using intelligent instances of multiple operation objects to automate the testing process.

[0077] In this embodiment, the operation object can be a specific interactive entity involved in the test task. Its test operation includes, but is not limited to, actions such as clicking, inputting, jumping, and verifying. The test operation performed by each operation object usually belongs to a specific preset sub-business.

[0078] In this embodiment, an intelligent instance can be a software unit that represents the operation object in making behavioral decisions and controlling execution during the test execution process. Essentially, it is an instantiation of the target intelligent agent on a specific operation object. Each intelligent instance inherits the operational process knowledge of the target intelligent agent corresponding to its preset sub-business, including but not limited to the standard process, state transition logic, exception handling strategy, and interaction rules with external systems of that sub-business.

[0079] In this embodiment, one operation object corresponds to one intelligent instance. Different intelligent instances can belong to the same preset sub-business and inherit the basic test knowledge and custom test knowledge of the target intelligent agent of the same preset sub-business. For example, the live streaming test scenario includes a live streaming test sub-business and a payment test sub-business, corresponding to target intelligent agents A and B respectively. The operation objects include three: the broadcaster, the user, and the payment processor. The broadcaster corresponds to intelligent instance 1, the user corresponds to intelligent instance 2, and the payment processor corresponds to intelligent instance 3. Among them, intelligent instance 1 and intelligent instance 2 both belong to the live streaming test sub-business. Intelligent instance 1 utilizes the process knowledge related to the broadcaster in A, intelligent instance 2 utilizes the process knowledge related to the user in B, and intelligent instance 3 utilizes the process knowledge related to the payment in C. Of course, the live streaming test sub-business can also be further subdivided into a broadcaster test sub-business and a user test sub-business, corresponding to target intelligent agents A1 and A2 respectively. In this case, intelligent instance 1 and intelligent instance 2 belong to different preset sub-businesses, with the former corresponding to A1 and the latter corresponding to A2.

[0080] In this embodiment, multiple intelligent instances interact and collaborate to execute test tasks, ultimately completing the automated testing of the test tasks. As an interactive and collaborative implementation method, it can include the following processes: First, obtain the state transition diagram of the test task, which includes the start state, end state, and abnormal termination state. In this embodiment, the state transition diagram can be a graphical representation of all possible states of a test task and their transition relationships. The state transition diagram consists of multiple state vertices and state transition edges. The state vertices represent key state nodes in the execution process of the test task, such as the state after the test action is executed, the initialization state of the operation object, the state after exception handling, the state after verification processing, etc. The state transition edges represent the transition conditions between states. These conditions are usually triggered by the execution result of the test action, system feedback signals, or abnormal events.

[0081] It should be noted that, in addition to the start state, end state, and abnormal termination state, the state transition diagram can also include one or more other intermediate states during the execution of the test task. The states can be transformed according to the transition rules. For example, the start state can be transformed into an intermediate state, and there can also be transition paths between intermediate states.

[0082] In optional implementations, test tasks typically include test actions, operation objects, exception handling, and verification processing. To systematically identify the state changes caused by various operations, exception handling, and verification processing within a test task, and to establish transition relationships between states based on triggering conditions, facilitating test operations based on state transitions, this embodiment also provides a method for obtaining a state transition diagram: (1) The state after each step of the test action is executed, the initialization state of the operation object, the state after exception handling, and the state after verification are respectively taken as state vertices; In this embodiment, based on information such as test actions, operation objects, exception handling mechanisms, and verification rules, all possible state nodes are identified and used as vertices in the state transition graph. A "test action" can refer to a specific operational behavior defined in a test task, such as clicking a button, entering text, or submitting a form. Each test action typically triggers a change in the system state, and these new states are recorded as state vertices. The initial state of the operation object can include the initial environmental conditions or system state in which the operation object is at the start of the test task. For example, when the operation object is a user account, its initial state might be "not logged in".

[0083] In this embodiment, if unexpected system feedback or operation failure occurs, the system will execute corresponding procedures according to a predefined exception handling mechanism, such as retrying, skipping, or switching paths. The state after these processes are completed will also be included in the state transition diagram. For example, when login fails, the system may enter the "display error message" state.

[0084] In this embodiment, "verification processing" refers to the checking behavior used in the test task to determine whether the current execution meets expectations, such as whether interface elements exist, whether data is returned correctly, and whether the response time meets the standard. After verification is completed, the system enters a new state, such as "verification passed" or "verification failed," and these states are also vertices in the state transition diagram.

[0085] (2) Determine the transition relationship between state vertices based on the triggering conditions of test actions, exception handling, and verification handling to obtain the state transition diagram.

[0086] In this embodiment, the triggering condition refers to the precondition that must be met for a transition from one state to another, which is usually determined by the execution result of the test action, the occurrence of an abnormal event, or the verification result. The system parses the logical rules in the test task description and maps these triggering conditions to transition edges between state vertices, thereby constructing a complete state transition graph.

[0087] As an implementation, the state transition diagram can be implemented in the form of a finite state machine. The finite state machine abstracts the test process into a series of states and state transitions. Each state represents a stage in the test process, and the transitions between states are triggered by specific conditions. This modeling approach has several advantages: clear state definitions, with each state having clear entry conditions, execution actions, and exit conditions; clear transition logic, with the transition paths and triggering conditions between states being obvious; standardized exception handling, where each state can define an exception handling strategy; and strong verifiability, where the correctness of the state machine can be verified through formal methods.

[0088] In this embodiment, the test tasks described in the declarative task description language can be transformed into a finite state machine. The transformation can be carried out according to the test actions, operation objects, exception handling, and verification handling in the test tasks. The main transformation cases include the following: (1) Map the test actions to states; (2) The initial state of the operation object affects the branch logic; (3) Exception handling generates exception transitions; (4) The state after verification handling is transformed into a verification state; To more intuitively display the state transition diagram, this embodiment is described in combination with the test tasks of paid fans. For example, the conversion examples between the test tasks described in the declarative task description language and the states of the corresponding finite state machine are as follows: Test actions: "User login" → S1 (Login preparation) "Enter the live broadcast room" → S2 (Enter the live broadcast room) "Click to pay to become a fan" → S3 (Initiate payment) Operation objects: user_a.balance: x → S4 Add balance judgment fan_price: y → Branch to S4.1 when balance < y Exception handling: "Insufficient balance → Recharge z yuan" → S4.1 (Recharge) "Network exception → Retry 3 times" → Add exception edges to each state Verification handling: 4 verification items → S6 (Parallel verification) In the above conversion example, actions such as "user login", "enter the live broadcast room", and "click to pay to become a fan" are respectively converted into states S1, S2, S3, etc. When it is recognized that the balance of user user_a is x yuan and the fan fee is y yuan (x < y), a balance judgment branch is automatically added in state S4. The defined rule of "automatically recharge z yuan when the balance is insufficient" (z > y) is reflected as a conditional conversion from S4 to S4.1 in the finite state machine; the rule of "retry 3 times for network exception" adds an exception handling edge to each state. Four verification items (fan badge, fan count update, balance change, fan privileges) are combined into the S6 parallel verification state.

[0089] To more intuitively display the state transition diagram, this embodiment is described in combination with the test task of paid fans. Please refer to Figure 6 , Figure 6 which is an example diagram of the finite state machine for the paid fan test provided by this embodiment, Figure 6 including a total of 9 states from S0 to S7, and the conversion rules included are defined as: S0 → S1: Initialization completed; S1 → S2: Login successful; S2 → S3: Enter the live broadcast room successfully; S3 → S4: Click the payment button; S4 → S4.1: Balance < x; S4 → S5: Balance >= x; S4.1 → S5: Recharge completed; <0000​​​​​​​​​​​​​​​​​​Third, allocate target devices to target intelligent instances from the device resource pool; In this embodiment, the device resource pool includes a set of physical or virtual devices that can be used to execute test tasks, such as mobile terminal emulators, browser instances, and server nodes. The target device is the device on which the target intelligent instance performs the test. Based on the type of operation object represented by the target intelligent instance, the device compatibility requirements of the target sub-service, and the availability of current device resources, a suitable target device is dynamically selected and allocated. For example, if the target intelligent instance represents a mobile user account, the system may allocate a mobile terminal emulator running a specific operating system as the target device.

[0093] Fourth, start the target intelligent instance, and based on the target intelligent instance's own state, the knowledge of the operation process of the corresponding target intelligent agent's preset sub-services, and the state transition diagram, control the target device to execute the state transition process until it reaches the end state or abnormal termination state, thus completing the automated testing of the test task.

[0094] In this embodiment, after startup, the target intelligent instance first loads the knowledge base of its corresponding target intelligent agent, obtains the state transition path of the current test task and its own current state information (such as the identity of the operation object, initial permissions, data context, etc.), and then combines the path logic in the state transition diagram with the knowledge model of the target intelligent agent to generate a series of test operation instructions and control the target device to execute them sequentially. These operations may include actions such as clicking, inputting, jumping, waiting for response, and verifying interface elements. Throughout the execution process, the target intelligent instance continuously monitors the execution status and determines the next action according to the guidance of the state transition diagram until it reaches the end state or the abnormal termination state.

[0095] In an optional implementation, the execution of the state transition process is not linear, but may involve collaboration and switching between multiple intelligent instances. Correspondingly, there may be a switching of device control between multiple intelligent instances. This embodiment also provides a handling method for this scenario: (1) When a control transfer request is received from any started smart instance, the current execution state is saved. The control transfer request is issued by the started smart instance when it detects that the smart instance related to the next state to be transitioned is not itself; In this embodiment, in addition to the smart instances involved in the test task, a master smart instance is pre-created to coordinate the multiple smart instances involved in the test task. When a started smart instance determines during execution that it cannot continue processing the test operation corresponding to the next state transition, it sends a control transfer request to the master smart instance. This determination process is usually based on the matching judgment between the transition conditions between the current state and the next state in the state transition diagram and the smart instance identifier associated with the target state. At this time, the smart instance will no longer have the ability or permission to execute the next state transition task, so a control transfer mechanism needs to be triggered.

[0096] In this embodiment, the current execution state includes, but is not limited to, the context information of the current test task, the device status, the current state transition path, and the abnormal state marker, so that the subsequent takeover smart instance can continue to execute the test task based on the saved execution state.

[0097] (2) Identify the takeover smart instance from multiple smart instances that is associated with the next state to be transitioned; In this embodiment, the determination of the takeover smart instance typically relies on the mapping relationship between each state in the state transition diagram and the smart instance, as well as the identification information of the next state to be transitioned to.

[0098] (3) Assign takeover devices to the takeover smart instance from the device resource pool; In this embodiment, the allocation strategy can be dynamically adjusted based on factors such as device availability, performance matching, and task priority.

[0099] (4) Start the takeover smart instance to control the takeover device to perform the state transition process.

[0100] In this embodiment, the takeover smart instance continues to execute the subsequent state transition process based on its own state, the current context of the assigned device, and the path guidance in the state transition graph.

[0101] In the above implementation, by pooling device resources, any intelligent instance can request and release device control as needed. This maximizes resource utilization, allowing idle devices to be immediately used by intelligent instances that require them; and ensures optimal matching of professional capabilities, with the most professional intelligent instance controlling the devices in each testing phase.

[0102] The aforementioned multiple smart instances may involve concurrent execution during the process. To more intuitively demonstrate the concurrent execution process of each smart instance, this embodiment combines a paid fan test scenario. Please refer to [link / reference]. Figure 7 , Figure 7 This is a flowchart illustrating the concurrent execution of intelligent instances for paid fan testing provided in this embodiment. Figure 7Among them, the operations are performed in chronological order as follows: Start at 00:00; At 00:01, the main intelligent instance is created. After creation, it receives the test task: "Test paying to become a fan"; At 00:02, the main intelligent instance decomposes the task and creates 3 intelligent instances, namely: Live Expert Intelligent Instance 1 (responsible for User A), Live Expert Intelligent Instance 2 (responsible for Anchor B), and Payment Expert Intelligent Instance (on standby); At 00:15, the first stage of parallel execution of Intelligent Instance 1 and Intelligent Instance 2: Account login. The two respectively apply for their own devices: Device 1 and Device 2. Device 1 is used for Intelligent Instance 1 to log in User A, and Device 2 is used for Intelligent Instance 2 to log in Anchor B; At 00:35, the second stage of parallel execution of Intelligent Instance 1 and Intelligent Instance 2: Scene preparation. The two respectively perform their own scene preparations. The scene preparation of Intelligent Instance 1 is: User A waits for the home page to load. The scene preparation of Intelligent Instance 2 is: Anchor B starts a live broadcast; At 00:55, the serial execution stage of Intelligent Instance 1 and Intelligent Instance 2: Enter the live broadcast room. Intelligent Instance 1 searches for and enters Anchor B's live broadcast room; At 01:15, the task transfer stage: Intelligent Instance 1 detects that payment is required, sends a message to the main intelligent instance, and the main intelligent instance schedules the Payment Expert Intelligent Instance; At 01:16, the Payment Expert Intelligent Instance is activated: The Payment Album Intelligent Instance takes over the control of Device 1; At 01:20, the Payment Expert Intelligent Instance performs the following operations: Check the balance: x yuan < y yuan, make a decision: recharge z yuan, execute the recharge process, and complete the payment; At 01:50, the control right returns: The control of Device 1 is transferred from the Payment Expert Intelligent Instance to Intelligent Instance 1; At 01:55, the parallel verification stage of Intelligent Instance 1 and Intelligent Instance 2: Intelligent Instance 1 verifies the fan identification and rights. Intelligent Instance 2 verifies the fan number update and list; At 02:10, result summary: All intelligent instances report to the main intelligent instance, and the main intelligent instance generates a test report.

[0103] As can be seen from the above process, at the start of the test, the main intelligent instance assigns device 1 to intelligent instance 1 and device 2 to intelligent instance 2. Intelligent instance 1 controls device 1 to complete operations such as user login, entering the live broadcast room, and clicking the fan button. When payment is required, intelligent instance 1 recognizes that this is not its area of ​​expertise and requests a transfer of control from the main intelligent instance. After the payment expert intelligent instance takes over device 1, it quickly completes the payment-related operations based on its professional knowledge: it recognizes the insufficient balance prompt, selects to recharge z yuan (z>y), completes the payment, returns to the fan payment page, and completes the y yuan payment. Throughout the process, the payment expert intelligent instance fully utilizes its domain knowledge; for example, it knows that the balance display needs to be manually refreshed after the recharge is completed, and it knows that the payment timeout is 30 seconds. After the payment is completed, the payment expert intelligent instance returns control of the device to intelligent instance 1, which continues the subsequent verification work. Compared with the traditional fixed one-to-one binding mode between intelligent instances and devices, this embodiment dynamically allocates devices to intelligent instances when needed, realizing the full utilization of device resources.

[0104] Based on the above concurrent execution process, this embodiment also provides a detailed description of the device control transfer process. Please refer to [link / reference]. Figure 8 , Figure 8 Provided for this embodiment Figure 7 The following is a flowchart illustrating the process of control transfer, which includes the following stages: Phase 1: Intelligent Instance 1 Control Period (0-45 seconds) Device 1 status: Login complete → Enter live stream room → Click the follower button; Payment request detected, control transfer requested. Phase 2: Transfer of Control (45-50 seconds) This includes the following processing: (2.1) Saved status { Screenshot: "current_screen.png", User interface tree: "ui_hierarchy.xml", Context: { Current page: "Paid Page for Fans" Payment amount: 30 User balance: 10 } } (2.2) Device control is temporarily frozen so that the state can be safely transferred to another smart instance; (2.3) Update controller: Smart Instance 1 → Payment Expert Smart Instance; (2.4). Transmit status data.

[0105] Phase 3: Payment Expert Smart Instance Control Period (50-90 seconds) Device 1 status: Insufficient balance detected → Top up z yuan → Return to payment → Payment completed; Payment completed, request refund.

[0106] Phase 4: Return of Control (90-95 seconds) Repeated transfer process, controller: Payment Expert Smart Instance → Smart Instance 1, Smart Instance 1 continues to control Device 1 to perform subsequent test operations.

[0107] To perform the corresponding steps in the above embodiments and various possible implementations, an implementation method of the automated testing device 100 is given below. Please refer to... Figure 9 , Figure 9 This is a block diagram of the automated testing device provided in this embodiment. It should be noted that the basic principle and technical effects of the automated testing device 100 provided by the present invention are the same as those of the corresponding embodiments described above. For the sake of brevity, some parts of this embodiment are not mentioned.

[0108] The automated testing device 100 includes an acquisition module 110, a construction module 120, and a testing module 130.

[0109] The acquisition module 110 is used to acquire test tasks for the target test scenario, which includes multiple preset sub-businesses; The construction module 120 is used to construct the target intelligent agent for each preset sub-service based on the basic test knowledge and custom test knowledge of each preset sub-service. The target intelligent agent is used to plan the test process of the corresponding preset sub-service. Test module 130 is used to automate the testing of test tasks by utilizing target intelligent agents of multiple preset sub-businesses.

[0110] In an optional implementation, the test task includes multiple operation objects, and the test module 130 is specifically used for: Based on the preset sub-business to which the test operation performed by each operation object belongs, create a corresponding intelligent instance of the target intelligent agent for each operation object; Utilize intelligent instances of multiple operands to execute test tasks, thereby automating the testing of test tasks.

[0111] In an optional implementation, the test module 130 is specifically used to: execute test tasks using intelligent instances of multiple operational objects to complete automated testing of the test tasks. Obtain the state transition diagram of the test task, which includes the start state, end state, and abnormal termination state. Identify the target smart instance related to the starting state from multiple smart instances; Allocate target devices to target intelligent instances from the device resource pool; Start the target intelligent instance, and based on the target intelligent instance's own state, the knowledge of the operation process of the corresponding target intelligent agent's preset sub-services, and the state transition diagram, control the target device to execute the state transition process until it reaches the end state or abnormal termination state, thus completing the automated testing of the test task.

[0112] In an optional implementation, the test module 130 is further configured to: When a control transfer request is received from any started smart instance, the current execution state is saved. The control transfer request is issued by the started smart instance when it detects that the smart instance related to the next state to be transitioned is not itself. Identify the takeover smart instance from multiple smart instances that is associated with the next state to be transitioned; Assign takeover devices to the takeover smart instance from the device resource pool; Initiate a takeover smart instance to control the takeover device to perform state transition procedures.

[0113] In an optional implementation, the test task includes test actions, operation objects, exception handling, and verification handling. The test module 130 is also used to obtain the state transition diagram of the test task, specifically for: The state after each step of the test action is executed, the initialization state of the operation object, the state after exception handling, and the state after verification are respectively regarded as state vertices; The transition relationships between state vertices are determined based on the triggering conditions of test actions, exception handling, and verification processing, resulting in a state transition diagram.

[0114] In an optional implementation, the acquisition module 110 is specifically used for: Receive test requirements described in natural language from users for the target test scenario; The test requirements are transformed into a declarative task description language to obtain the test tasks.

[0115] In an optional implementation, the construction module 120 is specifically used to: construct a knowledge graph for each preset sub-service based on the basic test knowledge and custom test knowledge of each preset sub-service, so that the target intelligent agent of each preset sub-service can plan the business test process of the corresponding preset sub-service based on the corresponding knowledge graph; encapsulate a query interface for querying the knowledge graph; and construct the target intelligent agent of each preset sub-service based on the knowledge graph and query interface of each preset sub-service.

[0116] This invention also provides a block diagram of an electronic device 10, which implements the automated testing method described in the foregoing embodiments. Please refer to... Figure 10 , Figure 10 This is a block diagram of the electronic device 10 provided in this embodiment. The electronic device 10 includes a processor 11, a memory 12 and a bus 13. The processor 11 and the memory 12 are connected through the bus 13.

[0117] Processor 11 can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the automated testing method described in the above embodiments can be completed by the integrated logic circuitry in the hardware of processor 11 or by software instructions. The processor 11 can be a general-purpose processor, including a CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be a DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Logic Gate Array), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0118] The memory 12 is used to store programs that implement automated testing methods. These programs can be software functional modules stored in the memory 12 in the form of software or firmware, or embedded in the OS (Operating System) of the electronic device 10.

[0119] After receiving the execution instruction, the processor 11 executes the program to implement the automated testing method of the aforementioned embodiment.

[0120] This embodiment provides a computer storage medium storing a computer program, which, when executed by a processor, implements the automated testing method described in the foregoing embodiments.

[0121] In summary, the embodiments of the present invention provide an automated testing method, apparatus, electronic device, and computer storage medium. The method includes: acquiring test tasks for a target test scenario, the target test scenario including multiple preset sub-services; constructing a target intelligent agent for each preset sub-service based on basic test knowledge and custom test knowledge of each preset sub-service; and using the target intelligent agents of multiple preset sub-services to perform automated testing on the test tasks. Compared with the prior art, this embodiment has at least the following advantages: (1) Each target intelligent agent is constructed based on the basic test knowledge and custom test knowledge of its own preset sub-business, which is used to plan the test process of the corresponding preset sub-business, thereby improving the specialization of the target intelligent agent. The same collaboration of multiple specialized target intelligent agents shortens the reasoning time in automated testing and improves decision-making efficiency, thereby improving the efficiency of automated testing; (2) The test requirements are transformed into test tasks in a declarative task description language, making the description of test tasks more natural and accurate; (3) The state transition diagram provides a clear and verifiable modeling method for complex test processes; (4) Multiple intelligent instances can be executed in parallel; (5) When intelligent instances need it, the equipment is dynamically allocated to them, so that the control of the equipment can be transferred between multiple intelligent instances, thereby improving the utilization rate of the equipment; (6) The two-layer knowledge architecture can manage and reuse test knowledge more systematically.

[0122] The above descriptions are merely various embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An automated testing method, characterized in that, The method includes: Obtain test tasks for a target test scenario, wherein the target test scenario includes multiple preset sub-services; Based on the basic test knowledge and custom test knowledge of each preset sub-service, a target intelligent agent is constructed for each preset sub-service. The target intelligent agent is used to plan the test process of the corresponding preset sub-service. The test task is automated by using the target intelligent agents of the multiple preset sub-services.

2. The method according to claim 1, characterized in that, The test task includes multiple operation objects, and the step of automating the test task using the target intelligent agents of the multiple preset sub-services includes: Based on the preset sub-service to which the test operation performed by each operation object belongs, create a smart instance of a corresponding target smart agent for each operation object; The test task is executed using intelligent instances of the multiple operation objects to automate the testing of the test task.

3. The method according to claim 2, characterized in that, The step of using intelligent instances of the multiple operation objects to execute the test task to complete the automated testing of the test task includes: Obtain the state transition diagram of the test task, which includes a start state, an end state, and an abnormal termination state. Determine the target intelligent instance associated with the starting state from among the multiple intelligent instances; Assign a target device to the target smart instance from the device resource pool; The target intelligent instance is started, and based on the target intelligent instance's own state, the knowledge of the operation process of the preset sub-services possessed by the corresponding target intelligent agent, and the state transition diagram, the target device is controlled to execute the state transition process until the end state or the abnormal termination state is reached, thereby completing the automated testing of the test task.

4. The method according to claim 3, characterized in that, After the step of activating the target smart instance, the following steps are included: When a control transfer request is received from any started smart instance, the current execution state is saved. The control transfer request is issued by the started smart instance when it detects that the smart instance related to the next state to be transitioned is not itself. From the plurality of said smart instances, determine the takeover smart instance associated with the next state to be transitioned; Assign takeover devices to the takeover smart instance from the device resource pool; The takeover smart instance is activated to control the takeover device to perform a state transition process.

5. The method according to claim 3, characterized in that, The test task includes test actions, operation objects, exception handling, and verification processing. The step of obtaining the state transition diagram of the test task includes: The state after each step of the test action is executed, the initialization state of the operation object, the state after exception handling, and the state after verification processing are respectively regarded as state vertices; The state transition diagram is obtained by determining the transition relationships between the state vertices based on the triggering conditions of the test actions, exception handling, and verification handling.

6. The method according to claim 1, characterized in that, The steps for obtaining test tasks for the target test scenario include: Receive test requirements described in natural language from the user for the target test scenario; The test requirements are transformed into a declarative task description language to obtain the test task.

7. The method according to any one of claims 1-6, characterized in that, The step of constructing the target intelligent agent for each preset sub-service based on the basic test knowledge and custom test knowledge of each preset sub-service includes: Based on the basic test knowledge and custom test knowledge of each preset sub-service, a knowledge graph of each preset sub-service is constructed so that the target intelligent agent of each preset sub-service can plan the business test process of the corresponding preset sub-service based on the corresponding knowledge graph. Encapsulate a query interface for querying knowledge graphs; Based on the knowledge graph and query interface of each preset sub-service, a target intelligent agent for each preset sub-service is constructed.

8. An automated testing device, characterized in that, The device includes: The acquisition module is used to acquire test tasks for a target test scenario, wherein the target test scenario includes multiple preset sub-services; A construction module is used to construct a target intelligent agent for each preset sub-service based on the basic test knowledge and custom test knowledge of each preset sub-service. The target intelligent agent is used to plan the test process of the corresponding preset sub-service. The testing module is used to automate the testing tasks by utilizing the target intelligent agents of the multiple preset sub-services.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory being used to store a program, and the processor being used to implement the automated testing method as described in any one of claims 1-7 when executing the program.

10. A computer storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the automated testing method as described in any one of claims 1-7.

Images