Internet product acceptance test method and system, electronic product and storage medium

Abstract

The application relates to an Internet product acceptance test method, system, electronic product and storage medium, wherein the method comprises the following steps: analyzing acceptance test case data of a target product to generate an acceptance execution graph; performing test planning based on the acceptance execution graph to generate a test execution plan; establishing a test execution environment to realize interaction with a running system of the target product; sequentially performing test operations on the target product in the test execution environment according to the test execution plan; before performing one test operation of each test node, identifying a corresponding test entry based on context data of the target product in the test execution environment; obtaining state data of the target product after performing the test operation, evaluating the state data based on corresponding acceptance conditions, and generating corresponding acceptance result data. The application improves the reuse rate of test cases, covers a wide range of Internet products, and saves labor costs.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to an Internet product acceptance testing method, system, electronic product, and storage medium. Background Technology

[0002] As the iteration speed of software and internet products continues to increase, acceptance testing is usually required before a product is released and launched to verify whether the product functions meet the expected business needs and to confirm that new, modified, and existing functions can all operate normally, thereby ensuring product quality.

[0003] Currently, acceptance testing mainly adopts two methods: manual acceptance and automated testing.

[0004] Manual acceptance testing typically involves testers performing tests on the system under test item by item according to pre-designed acceptance test cases, and judging whether the test passes based on the system's feedback. This method offers good flexibility and can adapt to complex business scenarios and ad-hoc testing needs. However, manual acceptance testing requires testers to complete a large number of repetitive operations step by step, which is not only inefficient but also prone to fatigue due to prolonged repetitive operations, thus affecting the consistency and accuracy of test results. In addition, with continuous product iteration and frequent version releases, manual methods are difficult to complete large-scale regression testing, and test coverage is limited.

[0005] To improve testing efficiency, existing technologies widely employ acceptance testing solutions based on automated test scripts. This approach typically requires converting acceptance test cases into executable automated test scripts, which are then automatically executed by automated testing tools according to a predetermined process, generating test results. While automated testing reduces manual workload, these scripts often rely on specific business processes, page elements, and interface layouts. When business logic changes, user interfaces are updated, or page elements change, existing test scripts often need to be redeveloped or extensively modified; otherwise, test failures or inability to continue execution are likely. Therefore, acceptance testing solutions using automated test scripts suffer from high development and maintenance costs, and poor adaptability. Especially during rapid product iteration, the maintenance workload of automated scripts continuously increases, offsetting the efficiency gains brought by automated testing to some extent. Furthermore, existing automated acceptance testing solutions usually require converting acceptance test cases into script code that can be executed by specific automated testing tools, resulting in tight coupling between test execution capabilities and scripts. Consequently, test cases are difficult to reuse directly. When business requirements change, both test cases and automated scripts often need to be modified simultaneously, leading to complex test asset maintenance, long automation deployment cycles, and limiting further improvements in the automation level of acceptance testing. Summary of the Invention

[0006] In view of the technical problems existing in the prior art, the present invention proposes an acceptance testing method, system, electronic product and storage medium for Internet products, so as to improve the efficiency and flexibility of acceptance testing of Internet products and reduce labor costs.

[0007] To address the aforementioned technical problems, according to one aspect of the present invention, an acceptance testing method for internet products is provided, the method comprising: Parse the acceptance test case data of the target product to generate an acceptance execution diagram, which includes at least test behaviors, behavior objects, and acceptance conditions. Test planning is performed based on the acceptance execution diagram to generate a test execution plan; the test execution plan includes one or more test nodes that are executed sequentially, and each test node includes one or more test operations corresponding to a test behavior; Establish a test execution environment to enable interaction with the target product's operating system; According to the test execution plan, test operations are sequentially performed on the target product in the test execution environment; wherein, before executing a test operation at each test node, the corresponding test entry is identified based on the context data of the target product in the test execution environment, and the corresponding test operation is performed based on the test entry; Obtain the status data of the target product after performing test operations; and The status data is evaluated based on the corresponding acceptance criteria, and the corresponding acceptance result data is generated. Optionally, the acceptance test case data for the target product may be described in natural language text, structured text, or JSON format.

[0008] Optionally, when parsing the acceptance test case data of the target product, the acceptance steps and acceptance conditions in the acceptance test cases are identified by semantics or keywords, and the corresponding test behaviors and behavior objects are obtained from each identified acceptance step; the acceptance type and acceptance target are parsed from the identified acceptance conditions; correspondingly, the acceptance intent is determined based on the test behaviors and behavior objects, and the corresponding acceptance conditions are matched based on the acceptance intent to generate an acceptance execution diagram.

[0009] Optionally, when parsing the acceptance test cases of the target product, in addition to obtaining the corresponding test behaviors and behavior objects, the corresponding parameter data is also included; correspondingly, when implementing the corresponding test operations, the corresponding parameter data is input.

[0010] Optionally, the test behavior refers to behavior implemented through an interactive channel in the test execution environment, including click behavior and / or information input behavior.

[0011] Optionally, the interaction channel includes a user interface object tree and / or an API interface.

[0012] Optionally, the context data of the test execution environment may be one or more of the following: interface object tree data, API interface data, and interface visual feature data.

[0013] Optionally, when identifying the corresponding test entry based on the context data of the target product in the test execution environment, the corresponding operation intent is determined based on the test operation, and the test entry corresponding to the operation intent is identified from the context data in the test execution environment based on the operation intent.

[0014] Optionally, the status data of the target product after performing test operations includes one or more of the following: interface change data, interface data of the business database, and system log information.

[0015] Optionally, the step of evaluating the status data based on the corresponding acceptance criteria includes: Assess whether the status data meets the acceptance objectives in the acceptance criteria; and When the status data meets the acceptance target of the corresponding test behavior, the corresponding test node is determined to have passed acceptance.

[0016] Optionally, when the status data is field content generated in response to a test operation, when evaluating whether the status data meets the acceptance target in the acceptance conditions, the field content in the status data is compared with the preset field content in the acceptance target. If the field content in the status data is consistent with the preset field content in the acceptance target, it is determined that the status data of the test operation meets the acceptance target of the corresponding test behavior.

[0017] Optionally, when the status data is text data, when evaluating whether the status data meets the acceptance target in the acceptance conditions, semantic analysis of the text is used to determine whether the semantics of the status data is the same as the semantics of the acceptance target. If the semantics of the status data is the same as the semantics of the acceptance target, it is determined that the status data of the test operation meets the acceptance target of the corresponding test behavior.

[0018] Optionally, evaluating the status data based on the corresponding acceptance criteria further includes: determining business logic conditions based on all test behaviors and behavior objects, evaluating whether the status data meets the business logic conditions; and determining that the corresponding test node has passed acceptance when the status data meets the business logic conditions and satisfies the acceptance target of the corresponding test behavior.

[0019] Optionally, the Internet product acceptance testing method further includes: after all test behaviors, behavior objects and acceptance conditions in the acceptance execution diagram have been executed, generating an acceptance evaluation report based on the acceptance result data, which includes one or more of the following: overall acceptance summary data, test detail data for each test behavior, and acceptance result detail data.

[0020] Optionally, when generating a test execution plan based on the acceptance execution graph, an initial test execution plan is generated, which includes an initial test node corresponding to a test action; correspondingly, when performing test operations on the target product sequentially in the test execution environment according to the test execution plan, after completing the test operation of the initial test node, the next test node is planned based on the context data and acceptance execution graph in the current test execution environment.

[0021] According to another aspect of the present invention, the present invention also provides an acceptance testing method for Internet products based on AI intelligent agents, comprising: Create an AI agent and grant the AI ​​agent access to acceptance testing of the target product. Monitor the acceptance test triggering conditions of the target product, and when the acceptance test triggering conditions of the target product are met, send an acceptance test task instruction to the AI ​​agent, the acceptance test task instruction including the target product identifier; The AI ​​agent, upon receiving an acceptance test task instruction, retrieves acceptance test case data for the target product based on the target product identifier in the task instruction; and The AI ​​agent performs acceptance testing on the target product according to the aforementioned Internet product acceptance testing method.

[0022] Optionally, when creating the AI ​​agent, the AI ​​agent is provided with a task description, constraints, and a call interface for the required tools, wherein the task description includes at least an execution description for performing acceptance testing according to any one of the Internet product acceptance testing methods described in claims 1-15.

[0023] Optionally, the required tools include one or more of the following: a screenshot tool, an execution engine, a logging system, a business database, and a system database.

[0024] According to another aspect of the present invention, the present invention also provides an acceptance testing system for Internet products based on AI intelligent agents, comprising: The intelligent agent creation module is configured to create an AI intelligent agent and grant the AI ​​intelligent agent acceptance testing permissions for the target product. The triggering module is configured to monitor the acceptance test triggering conditions of the target product. When the acceptance test triggering conditions of the target product are met, it sends an acceptance test task instruction to the AI ​​agent. The acceptance test task instruction includes a target product test task identifier. The AI ​​agent module is configured to respond to receiving an acceptance test task instruction, obtain the acceptance test case data of the target product based on the target product identifier in the task instruction, and perform acceptance testing on the target product using the aforementioned Internet product acceptance test method.

[0025] According to another aspect of the present invention, the present invention also provides an electronic device comprising a processor and a memory, wherein the memory stores a set of computer program instructions, and the processor executes the aforementioned Internet product acceptance test method or the Internet product acceptance test method based on an AI agent when executing the set of computer program instructions in the memory.

[0026] According to another aspect of the present invention, the present invention also provides a computer-readable storage medium, wherein a computer program instruction set is stored on the computer-readable storage medium, and the computer program instruction set, when executed by a processor, performs the aforementioned Internet product acceptance testing method or the Internet product acceptance testing method based on AI intelligent agents.

[0027] According to another aspect of the present invention, the present invention also provides a computer program product, including a computer program instruction set, which, when executed by a processor, implements the aforementioned Internet product acceptance testing method or the Internet product acceptance testing method based on an AI agent.

[0028] According to the acceptance testing method provided by this invention, when conducting acceptance testing on Internet products, the test path can be planned autonomously, and the test entry point can be dynamically found according to interface changes. It no longer depends on specific business logic processes, page elements, and interface layouts, thus improving the reusability of test cases, covering a wide range of Internet products, and saving a lot of maintenance, modification, and other labor costs. Attached Figure Description

[0029] The preferred embodiments of the present invention will now be described in further detail with reference to the accompanying drawings, wherein: Figure 1 This is a flowchart of an internet product acceptance testing method according to an embodiment of the present invention; Figure 2 This is a flowchart of a method for performing test operations on a target product according to a test node of a test execution plan in a test execution environment according to an embodiment of the present invention; Figure 3 This is a flowchart of a method for performing test operations on a target product according to a test execution plan in a test execution environment according to an embodiment of the present invention; Figure 4 This is a flowchart of an acceptance testing method for internet products based on AI intelligent agents according to an embodiment of the present invention; Figure 5 This is a schematic diagram of an AI-based intelligent agent-based internet product acceptance testing system according to an embodiment of the present invention; and Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0030] 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, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] In the following detailed description, reference can be made to the accompanying drawings, which form part of this application and illustrate specific embodiments of the present application. In the drawings, similar reference numerals describe substantially similar components in different figures. Specific embodiments of the present application are described in sufficient detail below to enable those skilled in the art to implement the technical solutions of the present application. It should be understood that other embodiments may also be utilized, or structural, logical, or electrical changes may be made to the embodiments of the present application.

[0032] See Figure 1 , Figure 1 This is a flowchart of an internet product acceptance testing method according to an embodiment of the present invention, the method comprising the following steps: Step S10: Parse the acceptance test case data of the target product to generate an acceptance execution diagram, which includes at least test behaviors, behavior objects, and acceptance conditions. Step S20: Perform test planning based on the acceptance execution diagram to generate a test execution plan; the test execution plan includes one or more test nodes to be executed sequentially, and each test node includes one or more test operations corresponding to a test behavior; Step S30: Establish a test execution environment to enable interaction with the target product's operating system; Step S40: Perform test operations on the target product sequentially in the test execution environment according to the test execution plan; wherein, before performing a test operation at each test node, identify the corresponding test entry based on the context data of the target product in the test execution environment, and perform the corresponding test operation based on the test entry; Step S50: Obtain the status data of the target product after performing the test operation; and Step S60: Evaluate the status data based on the corresponding acceptance conditions and generate the corresponding acceptance result data.

[0033] In step S10, the acceptance test cases are manually written in natural language. Acceptance test case data typically includes basic information about the target product, such as the test case identifier, the corresponding target product name or identifier, and preconditions. To facilitate understanding and correct execution of the acceptance test task, the acceptance test case data also includes test steps, target objects, required input data (if necessary), and expected results. In one embodiment, the acceptance test case data is divided into two main categories: test steps and acceptance conditions. The test steps include multiple sequentially organized steps, each of which can be identified using text, numbers, etc. Each step includes the test behavior, the behavior object, and, if necessary, parameter data. The test behavior refers to the behavior implemented through the UI interface of the test execution environment, including click behavior and information input behavior. Furthermore, more detailed behaviors can be derived from these two types of behavior, such as "login," "click," "select," and "confirm." The behavior object is the operable target of the test behavior. For example, for the "login" behavior, the behavior object can be the "user login" button displayed on the interface. For "click," the behavior object can be a function button displayed on the interface. The acceptance criteria section should at least include the acceptance type and the acceptance objective. The acceptance objective is the expected result, and its specific content should correspond to the acceptance type. For example, the acceptance objective could be a piece of text, with the corresponding acceptance type being "existing text." The acceptance objective could also be a specific expected state, with the corresponding acceptance type being "changed state." The acceptance objective could also be a descriptive text of a rule, with the corresponding acceptance type being "business rule."

[0034] Acceptance test cases can be presented in the form of natural language text, structured text organized according to a certain structure, or JSON format.

[0035] In step S10, the acceptance test case data is parsed using semantics or keywords. For example, text segmentation and semantic analysis can be performed to identify the basic information of the target product, test steps, target objects, required input data (if necessary), and expected results. An acceptance execution diagram is then generated based on this information, which consists of structured and related data. For instance, if the acceptance test case data includes acceptance steps and multiple acceptance conditions, multiple acceptance steps and conditions are parsed from the data. From each acceptance step, the corresponding test behavior, behavior object, and input parameter data are identified. The test behavior, behavior object, and parameter data are encapsulated into a triplet data object, referred to as a test data object. From the identified acceptance conditions, the acceptance type and acceptance objective are parsed, and each acceptance objective and acceptance type are encapsulated into a binary data object, referred to as an acceptance data object. The acceptance intent is determined based on the test behavior and behavior object, and the corresponding acceptance conditions are matched based on the acceptance intent, thus establishing a correspondence between each test data object and acceptance data object, thereby obtaining the acceptance execution diagram. In another embodiment, the acceptance test cases of the target product can be parsed using a large language model. For example, the acceptance test cases of the target product and the corresponding prompts are sent to the large language model through the large language model interface, and the acceptance execution diagram generated by the large language model according to the requirements in the prompts is received.

[0036] In step S20, the acceptance execution diagram is broken down into steps to generate an executable sequence of test operations. Specifically, each test behavior in the acceptance execution diagram is treated as a test node, and the corresponding test operation is determined based on the behavior object and the specific meaning of the test behavior. For example, for the "login" behavior, according to the conventional login operation, after clicking the "User Login" button on the homepage, the page will redirect to the login page, where a correct username and password are required to complete the login. Therefore, based on the specific meaning of the "login" behavior and the behavior object "User Login" button, the sequentially executed test operations are: "Click the 'User Login' button on the homepage", "Enter username" in the username input box on the login page, "Enter password" in the password input box, and "Click the 'Login' button". Each test operation includes an operation type and a corresponding entry point. The operation type is similar to the test behavior type, including click operations and data input operations. The entry point corresponding to the operation is similar to the behavior object, such as a button or input box. Some operation types also include corresponding parameter data.

[0037] Furthermore, based on the intent corresponding to the test behaviors, the logical relationships between the test behaviors are determined, thereby determining the execution order of the test behaviors. For example, when the test behaviors include the "login" behavior and the click behavior on a button on the homepage after login, according to the logical relationship, the "login" behavior is executed first, and then the click behavior is executed. Therefore, the execution order of the test behaviors is determined by the logical relationships between them. Each test behavior is broken down into one or more test operations, which include specific operation types, operation objects, and parameter data to be used. These are organized together to form an execution plan. In one embodiment, when the execution order of multiple test behaviors is not unique after logical relationship analysis, multiple execution plans are generated. Each execution plan takes one test behavior as a test node, and the execution order of the test behaviors constitutes an execution path. In the subsequent step S40, when there are multiple execution plans, an optimal execution plan is determined based on the number of test operations on the execution path. Alternatively, an execution plan can be randomly selected. In one embodiment, the acceptance execution graph can be sorted and decomposed using a large language model to generate an executable sequence of test operations. For example, the acceptance execution graph and corresponding prompts can be sent to the large language model via the large language model interface. The prompts should clearly state the task of the large language model and the specific execution requirements of the task. For example, it may require that each test behavior in the acceptance execution graph be treated as a test node, and that the corresponding test operation be determined based on the behavior object and the specific meaning of the test behavior, and that specific output requirements be given, such as sorting the test nodes in order and marking the operation sequence number for the test operation of each test node, etc.

[0038] In step S30, the test execution environment is an environment capable of performing test operations. First, depending on the form of the target product, the target product is installed in the corresponding test system and a connection is established with the corresponding support system. For example, when the target product is a web product, it is installed in an electronic device, such as a personal terminal or server, and the target product is run by a browser in the electronic device. When the target product is a mobile app, it can be a plug-in product running on a client or server, and it is installed on the corresponding client or server. The client usually runs on a personal terminal, and the server usually runs on a server. Then, the API interface for running the target product test system is obtained. The API interface can be a browser interface for a web application or an automation interface for a mobile application. When the mobile application has a built-in browser and the target product is run by the browser, the API interface can be a browser interface. When the target product is not run by a browser but by a mobile operating system (such as Android or iOS), the API interface is an interface provided by the operating system.

[0039] These API interfaces enable interaction with the target product's operating system. Furthermore, the UI object tree can be used as an interaction channel to conduct testing of the target product. For web applications, the UI object tree is the DOM (Document Object Model) of the web page. For mobile applications, when the mobile operating system is Android, the UI object tree is the UI Accessibility Tree, and when the mobile operating system is iOS, the UI object tree is the UI Automation Tree.

[0040] Based on the interface object tree, the current interface structure elements and their attributes can be obtained, thereby enabling the determination of the test entry point.

[0041] In step S40, when performing test operations sequentially on the target product in the test execution environment according to the test execution plan, see [link to relevant documentation]. Figure 2 , Figure 2 This is a flowchart illustrating a method for performing test operations on a target product according to a test node of a test execution plan in a test execution environment, based on an embodiment of the present invention. Specifically, it includes the following steps: Step S401: Send a target product startup command to the target product operating system. Upon receiving the startup command, the target product operating system starts the target product and enters the target product's homepage.

[0042] Step S402: Obtain the current interface structure information of the target product's operating system through the API interface. For example, obtain the interface object tree information through the API interface. Alternatively, a screenshot tool can be used to capture the current interface of the target product's operating system, and visual recognition can be performed on the screenshot to obtain video feature information of the interface elements.

[0043] Step S403: Identify the current interface structure information and determine the corresponding test entry point, which corresponds to the operation object of the target test operation. For example, when the first test node is the login behavior, the first test operation is clicking the "User Login" button. Using the interface object tree information as context data, the "User Login" button is identified as the test entry point. During identification, the operation intent is determined based on the test operation and the operation object. Based on the operation intent, the operation object that implements the operation intent is determined from the interface structure information. For example, the target product homepage includes two button objects, "login" and "register". First, through language conversion and semantic matching, it can be determined that the intent of "login" and "User Login" is the same, thus the "login" button is determined as the operation object.

[0044] Step S404: Send the specific information and control instructions of the target test operation to the target product operating system via the API interface. The target product operating system executes the control instructions on the target product. For example, if the control instruction is "click", the corresponding specific information includes the button object, whose attribute information is the text "user login". After the target product operating system executes the control instruction, it will redirect from the homepage to the login page.

[0045] Step S405: Determine whether the test operation of the current test node is completed. If not, return to step S402. If all test operations have been completed, end the test of the current test node.

[0046] As can be seen from the above testing process, the present invention identifies the test entry point from the interface state information during the test execution process. Therefore, it is no longer limited to a fixed UI structure, but can identify the operation object according to the current specific UI interface structure information. No matter how the UI structure of the product changes, the corresponding operation object can be flexibly identified according to the test operation to be performed.

[0047] When the test execution plan includes multiple test nodes, in one embodiment, the test operations of each test node are executed sequentially. In another embodiment, see [link to embodiment]. Figure 3 , Figure 3 This is a flowchart illustrating a method for performing test operations on a target product according to a test execution plan in a test execution environment, based on an embodiment of the present invention. Specifically, it includes the following: Step S411: Determine the target test node. Initially, the first test node in the test execution plan is selected as the target test node.

[0048] Step S412: Perform the test operation on the target test node. See [link / details] for the specific execution process. Figure 2 The process shown will not be repeated here.

[0049] Step S413: Determine if there are any untested test nodes in the test execution plan. If so, proceed to step S414; otherwise, end the test.

[0050] Step S414: Determine the first candidate test node. Specifically, based on the test execution plan, the next node after a completed test node is selected as the first candidate test node.

[0051] Step S415: Obtain the current context data and match the second candidate test node from the test execution plan based on the current context data.

[0052] Step S416: Compare whether the first candidate test node and the second candidate test node are the same. If they are the same, then in step S417, the first candidate test node is determined as the new target test node. Return to step S412. If they are not the same, then in step S418, the second candidate test node is determined as the new target test node, and return to step S412.

[0053] In this embodiment, after each test node is executed, a new candidate test node is planned based on the current context data, and then the original test execution plan is verified, so that the test execution plan can be dynamically modified during the test execution process.

[0054] In another embodiment, when generating the test execution plan in step S20, only the first test node is generated as the initial test node. Then, during test execution, the next test node and its corresponding test operation are dynamically planned based on the current context data, as described above. Figure 3 The verification process is similar to that in other contexts, so it will not be described in detail here.

[0055] Steps S50 and S60 can be executed after each test operation is completed, or they can be executed after all test operations for a test node are completed. The status data of the target product after the test operation is performed, obtained in step S50, includes one or more of the following: interface change data, business database interface data, and system log information. Step S60 evaluates whether the acceptance criteria are met based on this status data. If the status data of all test operations for a test node meets the acceptance criteria for the corresponding test behavior, the corresponding test node is deemed to have passed acceptance; otherwise, the corresponding test node is deemed to have failed acceptance. Specifically, when the status data is field content generated in response to a test operation, when evaluating whether the status data meets the acceptance criteria, the field content is compared with the preset content of the field in the acceptance criteria. If they match, the status data of the test operation meets the acceptance criteria for the corresponding test behavior; if they do not match, the status data of the test operation does not meet the acceptance criteria for the corresponding test behavior. When the status data is text data, when evaluating whether the status data meets the acceptance target in the acceptance conditions, semantic analysis of the text is used to determine whether the semantics of the status data are the same as the semantics of the acceptance target. If the semantics are the same, it is determined that the status data of the test operation meets the acceptance target of the corresponding test behavior. If the semantics are different, it is determined that the status data of the test operation does not meet the acceptance target of the corresponding test behavior.

[0056] Furthermore, based on all test behaviors and behavior objects, business logic conditions are determined, and the status data is evaluated to see if it meets the business logic conditions. When the status data meets the business logic conditions and the acceptance target of the corresponding test behavior, the corresponding test node is determined to have passed acceptance.

[0057] In addition, after all test behaviors, behavior objects and acceptance conditions in the acceptance execution diagram have been executed, an acceptance evaluation report is generated based on the acceptance result data, which includes one or more of the following: overall acceptance summary data, test detail data for each test behavior, and acceptance result detail data.

[0058] In one embodiment, the aforementioned acceptance assessment and report generation can be implemented using a large language model. The large language model interface sends the status data of all test operations for each test node, acceptance conditions, and corresponding prompts to the large language model, specifying the task and execution requirements within the prompts. For example, the status data undergoes multi-level evaluation. First, structured data is evaluated according to rules, such as whether field data in the status data has become the predefined content of the acceptance target fields. Second, unstructured, text-based data is evaluated semantically. Finally, a business rule-level evaluation is performed to determine whether the current status data conforms to business logic. Specific output requirements are given in the prompts; for example, the generated acceptance assessment report may include an overall summary, a path diagram of the test nodes, and summaries and details for each test node. When acceptance fails, the failed node is marked in the path diagram, and detailed information is provided, including the reasons for the failure and evidence, such as interface data, screenshots, and logs.

[0059] This invention, through the aforementioned method, enables autonomous planning of test paths and dynamic location of test entry points based on interface changes during acceptance testing of internet products. It eliminates reliance on specific business logic processes, page elements, and interface layouts, thereby improving test case reusability, covering a wide range of internet products, and saving significant maintenance and modification costs. When the target product is updated, test engineers only need to update the test case data to be applicable to the new product. This lowers the technical threshold and maintenance costs for test engineers.

[0060] With the rapid development of artificial intelligence technology, especially the increasing maturity of AI agent technology, AI agents possess perception, decision-making, and execution capabilities. They can simulate human operational behavior, transforming many tasks from a "script-driven" work model to an "intent-driven" work model executed by AI agents. That is, the AI ​​agent understands the task and intent of the task and operates various tools to achieve the task. Therefore, this invention also provides an acceptance testing method for internet products based on AI agents, see [link to relevant documentation]. Figure 4 , Figure 4 This is a flowchart of an acceptance testing method for internet products based on AI intelligent agents according to an embodiment of the present invention. The method specifically includes the following steps: Step S1: Create an AI agent and grant the AI ​​agent access to the acceptance testing of the target product.

[0061] Step S2: Monitor the acceptance test triggering conditions of the target product. When the acceptance test triggering conditions of the target product are met, send an acceptance test task instruction to the AI ​​agent. The acceptance test task instruction includes the target product identifier.

[0062] Step S3: Upon receiving the acceptance test task instruction, the AI ​​agent obtains the acceptance test case data of the target product based on the target product identifier in the task instruction.

[0063] Step S4: The AI ​​agent executes the acceptance test process for the target product.

[0064] In step S1, when creating the AI ​​agent, the AI ​​agent is provided with task descriptions, constraints, and interfaces for calling the required tools.

[0065] The task description includes the tasks that the AI ​​agent needs to complete, including... Figure 1 The acceptance testing method shown includes parsing the acceptance test case data of the target product to generate an acceptance execution diagram, performing test planning based on the acceptance execution diagram to generate a test execution plan, establishing a test execution environment, sequentially performing test operations on the target product, obtaining the status data of the target product after performing the test operations, evaluating the status data based on the corresponding acceptance conditions, and generating corresponding acceptance result data.

[0066] The task description may also include examples of task completion, such as examples of acceptance execution diagrams, test execution plans, evaluation rules, methods, requirements, etc. The constraints may include, for example, the scope of parsing acceptance test case data, the expression methods of acceptance execution diagrams and test execution plans, the rule relationships during evaluation, output content requirements, format requirements, etc.

[0067] The required tools include one or more of the following: a screenshot tool, an execution engine, a logging system, a business database, and a system database. The screenshot tool is used to capture images of the target product's running system interface after the test operation is completed, to obtain visual information about the interface. The execution engine is adapted to the target product's running system. For example, when the target product is a web application run by a browser, or a mobile application plugin run by a browser embedded in a mobile application, the execution engine can be Playwright, Selenium, Puppeteer, Chrome DevTools Protocol (CDP), or other execution engines capable of interacting with the browser, capable of calling browser interfaces to obtain DOM and state information from the browser and sending control commands to the browser. When the target product is a mobile application or mobile application plugin that is not run by a built-in browser, the execution engine can be a tool capable of calling the mobile operating system's interfaces. When the operating system is Android, the execution engine can be Appium, UIAutomator2, Espresso, etc.; when the operating system is iOS, the execution engine can be XCUITest, WebDriverAgent, etc. Log systems, business databases, and system databases can provide AI agents with various status data after performing test operations on target products.

[0068] The triggering conditions include, for example, receiving a manually submitted acceptance test case, reaching a preset time interval based on the timing configuration, or receiving a preset trigger event notification.

[0069] In step S4, the AI ​​agent performs the acceptance testing process for the target product (see [link]). Figures 1 to 3 And the corresponding explanations, which will not be repeated here.

[0070] Traditional manual acceptance testing involves a large amount of repetitive labor, such as repeatedly inputting data and visually verifying results. This not only consumes a significant amount of valuable human resources, causing acceptance costs to increase linearly with business volume, but also leads to staff fatigue, resulting in missed tests, misjudgments, and other issues that make it difficult to guarantee consistent acceptance quality. This solution, however, automates the process, allowing an AI agent to replace manual execution of repetitive acceptance procedures. It can operate automatically around the clock, eliminating uncertainties caused by human fatigue. While significantly reducing labor costs, it greatly improves acceptance efficiency and the accuracy of results, solving the problems of low efficiency, high cost, and high error rates associated with manual acceptance. This embodiment also addresses the problem of "rigid and inflexible transitions" between acceptance test cases and system execution. Traditional automation tools typically rely on fixed element location (such as XPath, ID) and hard-coded process steps, lacking an understanding of business semantics. When the acceptance process logic is complex, involves multiple system jumps, or non-standard interactions, traditional methods struggle to cope flexibly, forcing many complex acceptance scenarios to revert to manual processes and preventing true end-to-end automation. This embodiment employs an AI Agent, which possesses human-like understanding and reasoning abilities. It can intelligently locate and execute operations on corresponding system nodes based on the input / output logic specified in the acceptance test cases. Instead of relying on rigid code paths, it is driven by an understanding of business intent, thus enabling it to handle more complex acceptance scenarios and achieving a leap from "script-driven" to "logic / intent-driven."

[0071] See Figure 5 , Figure 5 This is a block diagram illustrating the principle of an AI-based intelligent agent-based internet product acceptance testing system according to an embodiment of the present invention. The acceptance testing system includes an intelligent agent creation module 1, a triggering module 2, and an intelligent agent module 3. The intelligent agent creation module 1 creates an AI intelligent agent and grants the AI ​​intelligent agent acceptance testing permissions for the target product. The triggering module 2 monitors the acceptance testing trigger conditions of the target product. When the acceptance testing trigger conditions are met, it sends an acceptance testing task instruction to the AI ​​intelligent agent. The acceptance testing task instruction includes a target product test task identifier. Upon receiving the acceptance testing task instruction, the intelligent agent module 3 obtains the acceptance test case data of the target product based on the target product identifier in the task instruction and performs acceptance testing on the target product through the AI ​​intelligent agent.

[0072] Application Examples In this application example, the target product to be accepted is a plugin for claiming free traffic and empowering job positions on a recruitment platform webpage. The plugin's application process is as follows: after logging into the system, enterprise users access the free traffic portal, click to claim free traffic, select the job positions to be empowered, and finally confirm and submit. The system will then allocate the free traffic to the corresponding positions. Before deploying the plugin to the recruitment platform, regression acceptance testing is required. Traditional regression acceptance testing methods involve test engineers writing Python + Selenium scripts based on business logic, the structure of the traffic claiming page, and the interface layout, and then running the scripts for automated acceptance testing. However, because the layout of the interface elements on the traffic claiming page frequently changes as needed—for example, button names or positions—the script needs to be modified and maintained every time the traffic claiming page changes, which can take 2-3 days.

[0073] In this embodiment, the test engineer only needs to write a standardized text file of test cases for free data collection and empowerment job acceptance, and submit it to the AI-based intelligent agent-based internet product acceptance testing system provided in this embodiment. The created AI intelligent agent integrates an execution engine for operating the browser and a screenshot tool, enabling it to interact with the browser to simulate human interaction with the page and capture images of the page interface using the screenshot tool.

[0074] After receiving the test case text file, the AI-based Internet product acceptance testing system automatically performs acceptance testing on the target product according to the aforementioned method and outputs an acceptance evaluation report.

[0075] In this embodiment, the acceptance test case text written by the test engineer is as follows: { "case_id": "FREE_TRAFFIC_001", Title: "B-end Enterprises Claim Free Traffic and Empower Job Process Acceptance", "precondition": { "account_type": "enterprise_user", "login_state": true, "data_seed": "auto }, "steps": [ { "step_id": 1, "action": "login", "target": "Enterprise Login"}, { "step_id": 2, "action": "click", "target": "Free traffic entry point"}, { "step_id": 3, "action": "click", "target": "Claim free data"}, { "step_id": 4, "action": "select", "target": "List of job postings", "value": "Available job postings randomly selected by the system" }, { "step_id": 5, "action": "confirm"} ], "assertions": [ { "type": "text_exist", "target": "Successfully claimed"}, { "type": "state_change", "target": "free data balance", "value": "full amount"}, { "type": "business_rule", "description": "The job posting has successfully received traffic distribution"} ] } The acceptance test cases in this embodiment are described in JSON format, which is a structured text. They include three parts: basic information, test steps, and acceptance conditions. The basic information includes the test case identifier (case_id), the target product name (title), and preconditions. In this embodiment, the test case identifier is Flow-free-trafic_001, and the corresponding target product name is "B-end Enterprises Claim Free Traffic and Empower Jobs." The preconditions include "Account Type," "Login Status," and "Data Seed," which are used during acceptance testing.

[0076] This embodiment consists of five test steps, each with a step identifier (step_id). Each step includes a test action and a target, and may also include parameter data (value) if necessary. For example, the test action in step 1 is "login," and the target is "enterprise login." Similarly, the test action in step 2 is "click," and the test action in step 3 is "select," with the target being the "job list," and the required parameter data being "randomly select available jobs."

[0077] The acceptance criteria in this embodiment include three conditions, each with an acceptance type and an acceptance target. For example, the first acceptance criterion has an acceptance type of "existing text" and a corresponding acceptance target of "successfully claimed". The second acceptance type in this embodiment is "state change", the corresponding acceptance target is "free data balance", and the corresponding parameter value is "sufficient". The third acceptance type is "business rule", and the corresponding acceptance target is a description, namely "the position has successfully received data distribution".

[0078] Upon receiving the acceptance test case, the AI ​​agent-based internet product acceptance testing system first parses it, breaking down the structured description in the test case text into behaviors, their objects, and required input information, and then derives assertion conditions—the acceptance criteria used to determine whether the final result is correct. This constitutes the acceptance execution diagram.

[0079] Next, the AI ​​agent understands the overall business intent based on the parsed acceptance execution graph. Based on this graph, it abstracts the acceptance test cases into an execution plan, resulting in a complete test path from start to finish. This path includes one or more test operations to be executed for each test line (corresponding to a step in the test case). These test operations can simulate user behavior, such as opening a page, clicking a button, entering information, selecting options, and confirming submission.

[0080] Then the AI ​​agent enters the environment connection phase, where it gains access to the execution engine and screenshot tools, thus acquiring the "operational ability" to the system under test.

[0081] The test then proceeds to the execution phase, where the AI ​​agent executes each test operation in the test path according to the generated execution plan. During execution, the AI ​​agent plans the next test operation based on the DOM structure information and screenshots obtained after each test operation is completed, and determines the corresponding test entry point, ensuring that the object of each test operation is reachable.

[0082] During execution, the test system will enter the result collection phase, continuously collecting system feedback, including text changes on the page, API return data, system status changes, and screenshots or log information when necessary. This data is used for subsequent judgment.

[0083] Next, the AI ​​agent performs multi-level judgments on the collected results. First, it makes a rule-based judgment, such as whether a certain field has changed as expected. Second, it makes a semantic-based judgment, which is to judge unstructured goals such as "whether the receipt was successful" or "whether the business goal was achieved". Finally, it makes a business rule-based judgment, which is to judge whether the entire business logic loop is satisfied, such as whether the traffic has been successfully increased or whether the position has successfully obtained the distribution capability.

[0084] Once all assertions are completed, the final result output stage begins. The AI ​​agent generates an acceptance report when all conditions are met; if any conditions are not met, a failure report is generated, indicating the specific step where the failure occurred, along with relevant evidence such as logs, screenshots, or API response information to facilitate problem backtracking.

[0085] In this embodiment, the AI ​​agent simulates an enterprise user to complete the execution process at the business level. The test engineer only needs to provide the test case text. The AI ​​agent parses the test case text and abstracts the enterprise user's execution process at the business level into a semantically driven automatic execution chain. It then automatically accepts the results by collecting the execution results, thus completing the full acceptance test without the need to maintain complex scripts.

[0086] According to another aspect of the invention, the invention also provides an electronic device, see [link to relevant documentation]. Figure 6 , Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. The electronic device can be implemented as a server in the aforementioned application system, including a processor 601 and a memory 602. The memory 602 stores a program instruction set, and the aforementioned Internet product acceptance test method is implemented when the processor 601 executes the program instruction set in the memory 602.

[0087] Specifically, the processor 601 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of the present invention.

[0088] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 602 is non-volatile solid-state memory.

[0089] The memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the Internet product acceptance testing method provided by this invention.

[0090] In one example, the electronic device may also include a communication interface 603 and a bus 604. The processor 601, memory 602, and communication interface 603 are connected via the bus 604 and communicate with each other.

[0091] The communication interface 603 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of the present invention.

[0092] Bus 604 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 604 may include one or more buses. While specific buses are described and illustrated in embodiments of the invention, the invention contemplates any suitable bus or interconnect.

[0093] The present invention also provides a computer-readable storage medium storing computer program instructions thereon, which, when executed by a processor, implement any of the Internet product acceptance testing methods described in the foregoing embodiments. The computer-readable storage medium can be any medium that can tangibly contain or store computer-executable instructions for use by or in conjunction with an instruction execution system, apparatus, or device. The storage medium can be a transient computer-readable storage medium or a non-transitory computer-readable storage medium. Non-transitory computer-readable storage media may include, but are not limited to, magnetic storage devices, optical storage devices, and / or semiconductor storage devices. Examples of such storage devices include, for example, magnetic disks, optical discs based on CD, DVD, or Blu-ray technology, and persistent solid-state storage such as flash memory and solid-state drives.

[0094] This invention also provides a computer program product, comprising a set of computer program instructions, which, when executed by a processor, implement any of the internet product acceptance testing methods described in the foregoing embodiments. The computer program product includes, but is not limited to, application installation packages published on websites and app stores, application plugins, and mini-programs that can run within certain applications.

[0095] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0096] The above embodiments are for illustrative purposes only and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the scope of the invention. Therefore, all equivalent technical solutions should also fall within the scope of the invention.

Claims

1. A method for acceptance testing of internet products, characterized in that, include: Parse the acceptance test case data of the target product to generate an acceptance execution diagram, which includes at least test behaviors, behavior objects, and acceptance conditions. Test planning is performed based on the acceptance execution diagram to generate a test execution plan; The test execution plan includes one or more test nodes that are executed sequentially, and each test node includes one or more test operations corresponding to a test behavior; Establish a test execution environment to enable interaction with the target product's operating system; According to the test execution plan, test operations are sequentially performed on the target product in the test execution environment; wherein, before performing the test operation of each test node, the corresponding test entry is identified based on the context data of the target product in the test execution environment, and the corresponding test operation is performed based on the test entry; Obtain the status data of the target product after performing test operations; and The status data is evaluated based on the corresponding acceptance criteria, and the corresponding acceptance result data is generated.

2. The Internet product acceptance testing method according to claim 1, characterized in that, The acceptance test case data for the target product is described in natural language text, structured text, or JSON format.

3. The Internet product acceptance testing method according to claim 2, characterized in that, When parsing the acceptance test case data of the target product, the acceptance steps and acceptance conditions in the acceptance test cases are identified by semantics or keywords, and the corresponding test behaviors and behavior objects are obtained from each identified acceptance step; the acceptance type and acceptance target are parsed from the identified acceptance conditions; correspondingly, the acceptance intent is determined based on the test behaviors and behavior objects, and the corresponding acceptance conditions are matched based on the acceptance intent to generate an acceptance execution diagram.

4. The Internet product acceptance testing method according to claim 1, characterized in that, Furthermore, when parsing the acceptance test cases of the target product, in addition to obtaining the corresponding test behaviors and behavior objects, the corresponding parameter data is also included; correspondingly, when implementing the corresponding test operations, the corresponding parameter data is input.

5. The internet product acceptance testing method according to any one of claims 1-4, characterized in that, The test behavior refers to the behavior implemented through the interaction channel in the test execution environment, including click behavior and / or information input behavior.

6. The Internet product acceptance testing method according to claim 5, characterized in that, The interaction channel includes a user interface object tree and / or an API interface.

7. The Internet product acceptance testing method according to claim 6, characterized in that, The context data of the test execution environment consists of one or more of the following: interface object tree data, API interface data, and interface visual feature data.

8. The Internet product acceptance testing method according to claim 1, characterized in that, When identifying the corresponding test entry based on the context data of the target product in the test execution environment, the corresponding operation intent is determined based on the test operation, and the test entry corresponding to the operation intent is identified from the context data in the test execution environment based on the operation intent.

9. The Internet product acceptance testing method according to claim 1, characterized in that, The status data of the target product after the test operation includes one or more of the following: interface change data, interface data of the business database, and system log information.

10. The Internet product acceptance testing method according to claim 1, characterized in that, The steps for evaluating the status data based on the corresponding acceptance criteria include: Assess whether the status data meets the acceptance objectives in the acceptance criteria; and When the status data meets the acceptance target of the corresponding test behavior, the corresponding test node is determined to have passed acceptance.

11. The Internet product acceptance testing method according to claim 10, characterized in that, When the status data is the field content generated in response to the test operation, when evaluating whether the status data meets the acceptance target in the acceptance conditions, the field content in the status data is compared with the preset field content in the acceptance target. If the field content in the status data is consistent with the preset field content in the acceptance target, it is determined that the status data of the test operation meets the acceptance target of the corresponding test behavior.

12. The Internet product acceptance testing method according to claim 10, characterized in that, When the status data is text data, when evaluating whether the status data meets the acceptance target in the acceptance conditions, semantic analysis of the text is used to determine whether the semantics of the status data is the same as the semantics of the acceptance target. If the semantics of the status data is the same as the semantics of the acceptance target, it is determined that the status data of the test operation meets the acceptance target of the corresponding test behavior.

13. The internet product acceptance testing method according to any one of claims 10-12, characterized in that, The evaluation of the status data based on the corresponding acceptance criteria further includes: determining business logic conditions based on all test behaviors and behavior objects, evaluating whether the status data meets the business logic conditions; and determining that the corresponding test node has passed acceptance when the status data meets the business logic conditions and the acceptance target of the corresponding test behavior.

14. The internet product acceptance testing method according to any one of claims 10-12, characterized in that, Further includes: After all test actions, action objects, and acceptance conditions in the acceptance execution diagram have been executed, an acceptance evaluation report is generated based on the acceptance result data. This report includes one or more of the following: overall acceptance summary data, test detail data for each test action, and acceptance result detail data.

15. The Internet product acceptance testing method according to claim 1, characterized in that, When generating a test execution plan based on the acceptance execution graph, an initial test execution plan is generated, which includes an initial test node corresponding to a test action. Correspondingly, when performing test operations on the target product sequentially in the test execution environment according to the test execution plan, after completing the test operation of the initial test node, the next test node is planned based on the context data and acceptance execution graph in the current test execution environment.

16. A method for acceptance testing of internet products based on AI intelligent agents, characterized in that, include: Create an AI agent and grant the AI ​​agent access to acceptance testing of the target product. Monitor the acceptance test triggering conditions of the target product, and when the acceptance test triggering conditions of the target product are met, send an acceptance test task instruction to the AI ​​agent, the acceptance test task instruction including the target product identifier; The AI ​​agent, upon receiving an acceptance test task instruction, retrieves acceptance test case data for the target product based on the target product identifier in the task instruction; and The AI ​​agent performs acceptance testing on the target product according to any one of the Internet product acceptance testing methods described in claims 1-15.

17. The acceptance testing method for internet products based on AI intelligent agents according to claim 16, characterized in that, When creating an AI agent, the AI ​​agent is provided with a task description, constraints, and a call interface for the required tools. The task description includes at least an execution instruction for performing acceptance testing according to any one of the Internet product acceptance testing methods described in claims 1-15.

18. The acceptance testing method for internet products based on AI intelligent agents according to claim 17, characterized in that, The required tools include one or more of the following: a screenshot tool, an execution engine, a logging system, a business database, and a system database.

19. An acceptance testing system for internet products based on AI intelligent agents, characterized in that, include: The intelligent agent creation module is configured to create an AI intelligent agent and grant the AI ​​intelligent agent acceptance testing permissions for the target product. The triggering module is configured to monitor the acceptance test triggering conditions of the target product. When the acceptance test triggering conditions of the target product are met, the module sends an acceptance test task instruction to the AI ​​agent. The acceptance test task instruction includes the target product test task identifier. as well as The AI ​​agent module is configured to respond to receiving an acceptance test task instruction, obtain acceptance test case data of the target product based on the target product identifier in the task instruction, and perform acceptance testing on the target product using the AI ​​agent in accordance with the Internet product acceptance test method described in any one of claims 1-15.

20. An electronic device comprising a processor and a memory, wherein the memory stores a set of computer program instructions, characterized in that, When the processor executes the computer program instruction set in the memory, it executes the Internet product acceptance test method according to any one of claims 1-15, or the Internet product acceptance test method based on AI intelligent agent according to any one of claims 16-18.

21. A computer-readable storage medium, wherein, The computer-readable storage medium stores a set of computer program instructions, characterized in that, when the set of computer program instructions is executed by a processor, it executes the Internet product acceptance test method according to any one of claims 1-15, or the Internet product acceptance test method based on AI intelligent agents according to any one of claims 16-18.

22. A computer program product comprising a computer program instruction set, characterized in that, When the computer program instruction set is executed by the processor, it performs the Internet product acceptance test method according to any one of claims 1-15, or the Internet product acceptance test method based on AI intelligent agents according to any one of claims 16-18.

Images