Test method, device, computer equipment, storage medium and program product

Abstract

The application relates to a test method, a test device, a computer device, a storage medium and a program product. The method comprises the following steps: obtaining a test case to be executed; determining a target test process corresponding to a test business scene identifier, and obtaining a target reverse routing table corresponding to the target test process; obtaining a current test action identifier from a test action sequence, and determining a target interface execution node corresponding to the current test action identifier based on the target reverse routing table; executing a current test action corresponding to the current test action identifier through the target interface execution node, and obtaining a test action execution result of the current test action; returning to the step of obtaining the current test action identifier from the test action sequence until there is no current test action identifier, and determining a test result corresponding to the test case to be executed based on the test action execution result. The method can improve the flexibility of the test.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a testing method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] With the development of artificial intelligence technology, intelligent robots based on large language models are widely used in customer service dialogues, business processing, and automated decision-making. These intelligent robots typically interact with external systems through interface calls. After receiving user input, the large language model generates response results, and the business processing flow is completed through multiple interface execution nodes, thereby achieving the automated execution of complex tasks.

[0003] In traditional technologies, intelligent robots are typically tested using static test scripts. This involves pre-writing test scripts for different business scenarios and executing corresponding test actions according to the test scripts to complete the test of the intelligent robot, which results in low flexibility in the testing process. Summary of the Invention

[0004] Therefore, it is necessary to provide a testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve testing flexibility in response to the above-mentioned technical problems.

[0005] On the one hand, this application provides a testing method, the method comprising:

[0006] Obtain test cases to be executed; test cases to be executed include test business scenario identifiers and test action sequences, and the test action sequences include multiple test action identifiers arranged in execution order;

[0007] Determine the target test process corresponding to the test business scenario identifier, and obtain the target reverse routing table corresponding to the target test process; the target reverse routing table includes the correspondence between test action identifiers and interface execution nodes;

[0008] Obtain the current test action identifier from the test action sequence, and determine the target interface execution node corresponding to the current test action identifier based on the target reverse routing table;

[0009] The current test action corresponding to the current test action identifier is executed by the target interface execution node to obtain the test action execution result of the current test action;

[0010] Return to the step of obtaining the current test action identifier from the test action sequence until there is no current test action identifier. Based on the test action execution result, determine the test result corresponding to the test case to be executed.

[0011] On the other hand, this application also provides a testing apparatus, the apparatus comprising:

[0012] The acquisition module is used to acquire test cases to be executed. The test cases to be executed include test business scenario identifiers and test action sequences. The test action sequences include multiple test action identifiers arranged in execution order.

[0013] The determination module is used to determine the target test process corresponding to the test business scenario identifier and obtain the target reverse routing table corresponding to the target test process; the target reverse routing table includes the correspondence between test action identifiers and interface execution nodes;

[0014] The matching module is used to obtain the current test action identifier from the test action sequence and determine the target interface execution node corresponding to the current test action identifier based on the target reverse routing table;

[0015] The calling module is used to execute the current test action corresponding to the current test action identifier through the target interface execution node, and obtain the test action execution result of the current test action;

[0016] The output module is used to return the steps of obtaining the current test action identifier from the test action sequence until there is no current test action identifier. Based on the test action execution result, the test result corresponding to the test case to be executed is determined.

[0017] On the other hand, this application also provides a computer device including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method described in any of the first aspects.

[0018] On the other hand, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any of the first aspects.

[0019] On the other hand, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0020] The aforementioned testing methods, apparatus, computer equipment, storage media, and computer program products acquire test cases to be executed. Each test case includes a test business scenario identifier and a sequence of test actions. The sequence of test actions includes multiple test action identifiers arranged in execution order. A target test process corresponding to the test business scenario identifier is determined, and a target reverse routing table corresponding to the target test process is obtained. The target reverse routing table includes the correspondence between test action identifiers and interface execution nodes. The current test action identifier is obtained from the test action sequence, and the target interface execution node corresponding to the current test action identifier is determined based on the target reverse routing table. The current test action corresponding to the current test action identifier is executed through the target interface execution node, and the test action execution result of the current test action is obtained. The process returns to the step of obtaining the current test action identifier from the test action sequence until no current test action identifier exists. Based on the test action execution result, the test result corresponding to the test case to be executed is determined. By structuring test cases to be executed into test business scenario identifiers and test action sequences, and dynamically determining the target test process and its corresponding target reverse routing table based on the test business scenario identifiers, different test business scenarios can dynamically match the corresponding target test processes through the test business scenario identifiers, thereby improving the flexibility of target test process determination. Furthermore, during the execution of the test action sequence, the target interface execution node corresponding to the current test action identifier is dynamically determined based on the correspondence between the test action identifier and the interface execution node in the target reverse routing table, thereby improving the flexibility and accuracy of target interface execution node determination. Then, the target interface execution node is driven to execute the current test action corresponding to the current test action identifier, and after each test action in the test action sequence is completed, the test result corresponding to the test case to be executed is determined based on the execution result of each test action, so that the test process can automatically advance according to the test action sequence. Compared with writing fixed test scripts for test cases to be executed, the above method can dynamically determine the target test process according to the test business scenario, and dynamically determine the corresponding interface execution node according to the test action sequence and the target reverse routing table, thereby adapting to the test requirements of different test business scenarios and different test action sequences, and improving the flexibility of testing. Attached Figure Description

[0021] Figure 1 This is a diagram illustrating the application environment of the test method in one embodiment;

[0022] Figure 2 This is a flowchart illustrating a testing method in one embodiment;

[0023] Figure 3 This is a schematic diagram of the business scenario distribution process for a first-level distribution template in one embodiment;

[0024] Figure 4This is a schematic diagram of the execution flow of the target interface execution node in one embodiment;

[0025] Figure 5 This is a schematic diagram of the timing execution of the target interface execution node in one embodiment;

[0026] Figure 6 This is a schematic diagram of the model review and evaluation process in one embodiment;

[0027] Figure 7 This is a flowchart illustrating the interface response result verification process in one embodiment;

[0028] Figure 8 This is a schematic diagram illustrating the process of determining the current test action identifier in one embodiment;

[0029] Figure 9 This is a schematic diagram of a concurrent execution method in one embodiment;

[0030] Figure 10 This is a schematic diagram of the architecture of a test method in one embodiment;

[0031] Figure 11 This is a schematic diagram of the version update process for extended configuration information in one embodiment;

[0032] Figure 12 This is a structural block diagram of the test apparatus in one embodiment;

[0033] Figure 13 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0035] The testing method provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be located in the cloud or on another network server. Both the terminal and the server can be used independently to execute the test methods provided in the embodiments of this application. The terminal and the server can also be used collaboratively to execute the test methods provided in the embodiments of this application. For example, terminal 102 obtains test cases to be executed; the test cases to be executed include test business scenario identifiers and test action sequences, the test action sequences include multiple test action identifiers arranged in execution order; it determines the target test process corresponding to the test business scenario identifier and obtains the target reverse routing table corresponding to the target test process; the target reverse routing table includes the correspondence between test action identifiers and interface execution nodes; it obtains the current test action identifier from the test action sequence and determines the target interface execution node corresponding to the current test action identifier based on the target reverse routing table; it executes the current test action corresponding to the current test action identifier through the target interface execution node to obtain the test action execution result of the current test action; it returns to the step of obtaining the current test action identifier from the test action sequence until there is no current test action identifier, and determines the test result corresponding to the test cases to be executed based on the test action execution result. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0036] In one embodiment, such as Figure 2 As shown, a testing method is provided. This embodiment uses the application of this method to a computer device as an example for illustration, including steps 202 to 210.

[0037] Step 202: Obtain test cases to be executed; test cases to be executed include test business scenario identifiers and test action sequences, and the test action sequences include multiple test action identifiers arranged in execution order.

[0038] Among them, test cases to be executed refer to structured test data used to describe a complete test task, which drives the test execution process to run automatically according to preset test logic. Test cases to be executed may include, but are not limited to, test business scenario identifiers, test action sequences, concurrent cursor advance switches, test case-level context information, and metadata. Test business scenario identifiers are identification information used to identify the business application scenario type to which the test cases to be executed belong, used to distinguish the test execution scope in different business environments. Test business scenario identifiers may include, but are not limited to, customer service dialogue scenario identifiers, business processing scenario identifiers, intelligent decision-making scenario identifiers, or other artificial intelligence interaction scenario identifiers. Test action sequence refers to an ordered set of test action identifiers arranged in a preset execution order. Test action identifiers are identification information used to identify specific test actions. Concurrent cursor advance switches are control parameters used to control whether the execution cursor in the test action sequence is allowed to advance in parallel, used to control whether the test action execution process adopts a single-threaded sequential execution mode or a multi-threaded concurrent execution mode. When the concurrent cursor advance switch is on, multiple test action identifiers corresponding to execution cursors are allowed to advance in parallel across different interface execution nodes, improving test execution efficiency. When the concurrent cursor advance switch is off, the test action sequence is executed according to the order of a single execution cursor, ensuring consistency and controllability of the test execution order. Test case-level context information refers to a set of global runtime environment data shared by a single test case during execution, providing unified context environment support during test action execution. Test case-level context information may include, but is not limited to, session identifier information, user identity information, environment variable information, interface call history information, and intermediate execution result information, used to achieve data sharing and state transfer between multiple test actions. Metadata refers to a set of data describing the attribute information of the test case to be executed, used to characterize the static descriptive features of the test case. Metadata may include, but is not limited to, test case number, creation time, version information, business line information, execution priority information, and tag information, used to support the management, retrieval, and classification of test cases. Metadata does not directly participate in the test action execution logic, but is used to assist in test case scheduling and execution strategy selection.

[0039] For example, the computer device acquires the test cases to be executed corresponding to the target intelligent robot, determines the first-level distribution template corresponding to the target intelligent robot, and performs structured parsing processing on the test cases to be executed through the first-level distribution template to extract the test business scenario identifier and test action sequence. The first-level distribution template refers to a template structure layer used for the first-level structured distribution and control of the test execution process of the target intelligent robot. It is used to perform initial parsing and scenario classification of the test cases to be executed based on the test business scenario identifier, and generate sub-process call instructions corresponding to the target business scenario, so as to realize the hierarchical scheduling and jump control of the test execution process from the business scenario layer to the second-level business line process template. Each first-level distribution template corresponds to a single intelligent robot; that is, different intelligent robots correspond to different first-level distribution templates. The first-level distribution template includes a start node, a scenario matching and configuration node, a second-level business line process template reference node, and an end node, used to sequentially complete the processing of test case access, business scenario identification, second-level business line process template selection, and control flow termination.

[0040] In one embodiment, after obtaining the test cases to be executed, the method further includes: performing multi-level intermediate representation transformation on the test cases to obtain structured test data used to drive the test execution process. The multi-level intermediate representation includes test case-level intermediate representation, process-level intermediate representation, and interface-level intermediate representation. Specifically, the test case-level intermediate representation describes the overall test semantics of the test cases to be executed, and includes at least one of the following: test business scenario identifier, test action sequence, test parameter information, test case-level context information, and metadata. The process-level intermediate representation describes the execution structure of the test cases to be executed in the target test process, and includes at least one of the following: target business line identifier, test action identifier, execution location, control signal, and reverse routing table. The interface-level intermediate representation describes the interface call structure of a single interface execution node, and includes at least one of the following: interface address, request parameter configuration, response structure configuration, verification rule configuration, and result verification configuration information. A semantic degradation operator refers to a processing operator used to progressively convert high-level test semantics into low-level executable test structures. High-level test semantics refers to the business semantic information in the test cases to be executed that describes the test business scenario, test intent, or test actions. The semantic degradation operator includes a first semantic degradation operator and a second semantic degradation operator. The first semantic degradation operator converts the test business scenario, test intent, or test action description in the use case-level intermediate representation into test business scenario identifiers, test action sequences, and test action identifiers in the process-level intermediate representation. The second semantic degradation operator converts the test action identifiers in the process-level intermediate representation into interface execution node identifiers, target interface request generation rules, and result verification rules in the interface-level intermediate representation. Through the first and second semantic degradation operators, the computer device progressively degrades the natural language or business semantic test descriptions into structured test data that is machine-recognizable, routable, callable, and verifiable.

[0041] By constructing intermediate representations at the test case level, process level, and interface level, the test cases to be executed are expressed in layers from the business semantic layer, test process layer, and interface execution layer, thus avoiding the direct binding of high-level business test descriptions to specific interface scripts. The first semantic degradation operator transforms high-level test semantics into test business scenario identifiers, test action sequences, and test action identifiers, enabling first-level distribution templates and second-level business line process templates to perform scenario distribution and action routing based on structured process information. The second semantic degradation operator transforms test action identifiers into interface execution node identifiers, target interface request generation rules, and result verification rules, enabling third-level atomic interface templates to generate target interface requests and perform result verification based on interface-level structured data. Therefore, the testing method supports business semantic configuration while achieving a step-by-step routable, reusable, and verifiable transformation from test semantics to test process, and then from test process to interface execution, improving the flexibility of test case generation and test process orchestration.

[0042] Step 204: Determine the target test process corresponding to the test business scenario identifier, and obtain the target reverse routing table corresponding to the target test process; the target reverse routing table includes the correspondence between test action identifiers and interface execution nodes.

[0043] The target test process refers to the process structure used to describe the organization of test actions and node routing rules under a specific business scenario. The target test process can be a secondary business line process template corresponding to a test business scenario identifier. A secondary business line process template is a test process template corresponding to a target business line identifier. Secondary business line process templates can correspond to different business line identifiers such as intelligent customer service, user assistant, and public welfare robot, with different business line identifiers corresponding to different secondary business line process templates. Each secondary business line process template contains a reverse routing table, which records the correspondence between test action identifiers and interface execution nodes, enabling computer equipment to determine the corresponding target interface execution node based on the current test action identifier. The secondary business line process template does not pre-draw fixed flow relationships between interface execution nodes; instead, during test execution, it dynamically determines the next interface execution node to be executed based on the current test action identifier. Therefore, the secondary business line process template is not a static script process, but a process template used to carry business line-level test orchestration rules, reverse routing tables, and dynamic jump logic.

[0044] The target reverse routing table is a data table used to record the mapping relationship between test action identifiers and interface execution nodes. The reverse routing table corresponds one-to-one with the test process; that is, different test processes correspond to different reverse routing tables. An interface execution node is an execution unit used to execute specific interface call logic, carrying the actual execution capability of the test action.

[0045] For example, the computer device queries the business scenario distribution table based on the test business scenario identifier using the first-level distribution template, determines the target business line identifier, loads the corresponding second-level business line process template according to the target business line identifier, and uses the loaded second-level business line process template as the target test process; the computer device obtains the target reverse routing table through the target test process.

[0046] Step 206: Obtain the current test action identifier from the test action sequence, and determine the target interface execution node corresponding to the current test action identifier based on the target reverse routing table.

[0047] Here, the current test action identifier refers to the identifier of the test action to be executed. The current test action identifier is the test action identifier corresponding to the current execution position in the test action sequence. The target interface execution node refers to the interface execution unit used to execute the current test action, and is used to carry the specific interface call logic.

[0048] For example, the computer device obtains the current test action identifier from the test action sequence based on the current execution position through the secondary business line process template, and queries the target interface execution node corresponding to the current test action identifier through the target reverse routing table.

[0049] Step 208: Execute the current test action corresponding to the current test action identifier through the target interface execution node to obtain the test action execution result of the current test action.

[0050] The test action execution result refers to the result obtained by executing the current test action.

[0051] For example, the computer device executes the current test action corresponding to the current test action identifier through the third-level atomic interface template corresponding to the target interface execution node, and obtains the test action execution result of the current test action. The third-level atomic interface template refers to a template structure used to standardize and reuse the smallest executable interface unit in the test action execution process. It serves as the specific execution carrier downstream of the second-level business line process template and carries the complete execution logic of the interface-level test action. The third-level atomic interface template uses atomic interface nodes as basic components. Atomic interface nodes can include, but are not limited to, user inbound interfaces, user message sending interfaces, streaming message query interfaces, and session clearing interfaces, used to directly call and verify the backend services of the target intelligent robot under test. Each atomic interface node in the third-level atomic interface template adopts a three-stage script structure, including a parameter assembly stage, an interface call stage, and a result verification stage. The parameter assembly stage is used to initialize the interface request parameters and prepare the test environment; the interface call stage is used to call the backend services of the target intelligent robot under test and obtain the synchronous response result of the interface; and the result verification stage is used to trigger the asynchronous assertion processing flow after the synchronous return of the interface.

[0052] Step 210: Return to the step of obtaining the current test action identifier from the test action sequence until there is no current test action identifier. Based on the test action execution result, determine the test result corresponding to the test case to be executed.

[0053] For example, the computer device returns to the step of obtaining the current test action identifier from the test action sequence. If the current test action identifier exists, the target interface execution node corresponding to the current test action identifier is determined based on the target reverse routing table, and steps 208 and 210 are continued. If the current test action identifier does not exist, the test result corresponding to the test case to be executed is determined based on the test action execution result corresponding to each test action.

[0054] In this embodiment, by structuring the test cases to be executed into test business scenario identifiers and test action sequences, and dynamically determining the target test process and its corresponding target reverse routing table based on the test business scenario identifiers, different test business scenarios can dynamically match the corresponding target test processes through the test business scenario identifiers, thereby improving the flexibility of target test process determination. Furthermore, during the execution of the test action sequence, based on the correspondence between the test action identifiers and interface execution nodes in the target reverse routing table, the target interface execution node corresponding to the current test action identifier is dynamically determined, thereby improving the flexibility and accuracy of target interface execution node determination. Then, the target interface execution node is driven to execute the current test action corresponding to the current test action identifier, and after each test action in the test action sequence is completed, the test result corresponding to the test case to be executed is determined based on the execution result of each test action, so that the test process can automatically advance according to the test action sequence. Compared with writing fixed test scripts for the test cases to be executed, the above method can dynamically determine the target test process according to the test business scenario, and dynamically determine the corresponding interface execution node according to the test action sequence and the target reverse routing table, thereby adapting to the test requirements of different test business scenarios and different test action sequences, and improving the flexibility of testing.

[0055] In one embodiment, determining the target test process corresponding to the test business scenario identifier includes:

[0056] Obtain the business scenario distribution table; the business scenario distribution table includes the correspondence between candidate business scenario identifiers and candidate business line identifiers; based on the business scenario distribution table, determine the target business line identifier corresponding to the test business scenario identifier; from multiple candidate test processes, determine the target test process corresponding to the target business line identifier.

[0057] The business scenario distribution table is a data table used to record the correspondence between candidate business scenario identifiers and candidate business line identifiers. It is used to determine the corresponding business line identifier based on the test business scenario identifier in the test case to be executed. A candidate business scenario identifier is a pre-configured, matchable business scenario identifier in the business scenario distribution table. A candidate business line identifier is the business line identifier in the business scenario distribution table that corresponds to a candidate business scenario identifier. A target business line identifier is a candidate business line identifier that matches a test business scenario identifier, used to determine the target business line to which the test case to be executed belongs. Candidate test processes are pre-configured test processes corresponding to different business lines.

[0058] For example, after obtaining the test business scenario identifier in the test case to be executed, the computer device reads the business scenario distribution table through the first-level distribution template and determines the target business line identifier corresponding to the test business scenario identifier from the business scenario distribution table; the computer device determines the candidate test process corresponding to the target business line identifier from multiple candidate test processes as the target test process.

[0059] In one embodiment, a schematic diagram of the business scenario distribution process for the primary distribution template is shown below. Figure 3 As shown, the process includes: the computer device acquiring the test business scenario identifier, test action sequence, and test parameter information from the test cases to be executed; in the scenario matching phase, the computer device matches the test business scenario identifier with the business scenario distribution table based on the first-level distribution template to determine the target business line identifier corresponding to the test business scenario identifier, and loads the test parameter information into the context container corresponding to the target business line; in the jump phase, the computer device determines the target test process corresponding to the target business line identifier from multiple candidate test processes through the first-level distribution template. The target test process is the second-level business line process template corresponding to the test business scenario identifier, and jumps to the target test process based on the jump instruction. For example, when the test scenario identifier matches the intelligent customer service business line, the corresponding secondary business line process template is determined as the target test process, and a jump command is used to navigate to that secondary business line process template. Similarly, when the test scenario identifier matches the user assistant business line, the corresponding secondary business line process template is determined as the target test process, and a jump command is used to navigate to that secondary business line process template. Likewise, when the test scenario identifier matches the public welfare insurance robot business line, the corresponding secondary business line process template is determined as the target test process, and a jump command is used to navigate to that secondary business line process template. Thus, the computer equipment dynamically distributes different test scenarios to different target test processes through a primary distribution template.

[0060] In this embodiment, by pre-configuring a business scenario distribution table that includes the correspondence between candidate business scenario identifiers and candidate business line identifiers, the computer device can determine the target business line identifier based on the test business scenario identifier in the test cases to be executed, and further determine the target test process corresponding to the target business line identifier from multiple candidate test processes. Therefore, different test business scenarios can dynamically determine their corresponding target business line identifiers and target test processes through the business scenario distribution table, without needing to write fixed test scripts for different test business scenarios. This improves the flexibility of target test process determination and further enhances the test's adaptability to different test business scenarios.

[0061] In one embodiment, the current test action corresponding to the current test action identifier is executed through the target interface execution node to obtain the test action execution result of the current test action, including:

[0062] The target interface execution node assembles the current test action execution parameters corresponding to the current test action identifier to generate a target interface request; based on the target interface execution node, the target interface request is sent to the interface under test corresponding to the target interface execution node, and the interface response result is obtained; the interface response result is verified to obtain the test action execution result corresponding to the current test action.

[0063] The current test action execution parameters refer to the parameter information required to execute the current test action, providing input data for the interface call process corresponding to the current test action. These parameters may include, but are not limited to, at least one of the following: user identifier, session identifier, message content, interface call address, request header information, business parameters, and test case-level context information. Assembly processing refers to combining, completing, formatting, or mapping the current test action execution parameters according to the parameter assembly rules corresponding to the target interface execution node, to generate an interface request that meets the requirements of the interface under test. The target interface request refers to the request data generated by the target interface execution node based on the current test action execution parameters, used to call the interface under test. The interface under test refers to the interface in the target intelligent robot or its associated business system used to receive the target interface request and return the interface response result. The interface under test can be an interface provided externally by the target intelligent robot's backend service or its associated subsystems. Associated subsystems may include, but are not limited to, a session center, a knowledge retrieval system, a business interface system, and a message database. The interface response result refers to the response data returned by the interface under test based on the target interface request. Result verification processing refers to the process of determining whether the interface response result meets the verification conditions corresponding to the current test action. The test action execution result refers to the result information obtained after validating the interface response. The test action execution result may include, but is not limited to, the interface response result, the corresponding validation result, the test action execution status, and error reason information.

[0064] For example, after determining the target interface execution node corresponding to the current test action identifier through the secondary business line process template, the computer device calls the tertiary atomic interface template corresponding to the target interface execution node; through the parameter assembly stage in the tertiary atomic interface template, the computer device assembles the execution parameters of the current test action corresponding to the current test action identifier to generate a target interface request; through the interface call stage in the tertiary atomic interface template, the computer device sends the target interface request to the interface under test corresponding to the target interface execution node and obtains the interface response result; through the result verification stage in the tertiary atomic interface template, the computer device performs result verification processing on the interface response result to obtain the test action execution result corresponding to the current test action.

[0065] In one embodiment, the execution flow diagram of the target interface execution node is as follows: Figure 4 As shown, the process includes a parameter assembly phase, an interface call phase, and a result verification phase. In the parameter assembly phase, the computer device uses the third-level atomic interface template corresponding to the target interface execution node to obtain the execution parameters for the current test action. Based on the current test action identifier, it selects the corresponding request body template and generates a target interface request. In the interface call phase, the computer device uses the third-level atomic interface template corresponding to the target interface execution node to send the target interface request to the interface under test and obtains the interface response result. In the result verification phase, the computer device uses the third-level atomic interface template corresponding to the target interface execution node to perform synchronous field verification, asynchronous message database polling, streaming sharding aggregation, and model evaluation verification on the interface response result to obtain the test action execution result corresponding to the current test action.

[0066] In one embodiment, the timing execution diagram of the target interface execution node is as follows: Figure 5As shown, the process includes: a computer device acquiring a sequence of test actions from the test cases to be executed and initializing the current execution position; the computer device acquiring the current test action identifier corresponding to the current execution position from the test action sequence and passing the current test action identifier and the current test action execution parameters to the third-level atomic interface template corresponding to the target interface execution node. The computer device assembles the current test action execution parameters corresponding to the current test action identifier through the parameter assembly stage in the third-level atomic interface template to generate a target interface request; through the interface call stage in the third-level atomic interface template, it sends the target interface request to the interface under test corresponding to the target interface execution node and obtains the interface response result; through the result verification stage in the third-level atomic interface template, it performs result verification processing on the interface response result to obtain the test action execution result corresponding to the current test action. After the current test action is executed, the computer device updates the state information set corresponding to the current test action identifier to obtain a state information set including the next execution position, and obtains the next test action identifier from the test action sequence based on the next execution position to continue executing the next test action.

[0067] In this embodiment, by assembling the execution parameters of the current test action through the target interface execution node, the test action parameters corresponding to different test actions can be converted into target interface requests according to the interface call requirements, thereby improving the flexibility of interface request generation. By calling the corresponding interface under test through the target interface execution node and obtaining the interface response result, the abstract test action corresponding to the test action identifier can be implemented as a specific interface call process. By performing result verification processing on the interface response result, the test action execution result of the current test action can be determined based on the interface response result. Thus, the target interface execution node can uniformly complete the parameter assembly, interface call, and result verification process, enabling different test actions to be executed and verified through the corresponding interface execution node, thereby improving the flexibility of the test action execution process.

[0068] In one embodiment, the target interface request is sent to the interface under test corresponding to the target interface execution node, and the interface response result is obtained, including:

[0069] The target interface execution node sends the target interface request to the interface under test and obtains the initial response result; the initial response result is validated at the field level to obtain the validation result; if the validation result is successful, the asynchronous message database is polled based on the asynchronous message identifier in the initial response result until the asynchronous message result corresponding to the target interface request is obtained; the asynchronous message result includes multiple streaming fragments of data; the multiple streaming fragments of data are concatenated to obtain the interface response result.

[0070] The initial response result refers to the response data synchronously returned by the interface under test after receiving a request from the target interface. It represents the initial processing result of the interface under test on the target interface request. The initial response result may include, but is not limited to, response status, response code, session identifier, asynchronous message identifier, request processing status, and error message information. Field-level validation refers to the process of validating preset fields in the initial response result to determine whether the initial response result meets the conditions for continuing asynchronous message querying. Validation result refers to the result information obtained after performing field-level validation on the initial response result, representing whether the initial response result passes the field-level validation. Validation passed means that the preset fields in the initial response result meet the corresponding validation conditions. Asynchronous message identifier refers to the identifier information used to identify asynchronous message results, used to query the asynchronous message result corresponding to the target interface request in the asynchronous message database. The asynchronous message database refers to the data storage unit used to store message results asynchronously generated by the interface under test, used to query the asynchronous message result corresponding to the target interface request based on the asynchronous message identifier. Polling query refers to the processing method of repeatedly querying the asynchronous message database at preset query intervals, used to continuously query until the corresponding asynchronous message result is obtained or the preset query stop condition is reached. Asynchronous message results refer to the message results generated asynchronously after the tested interface synchronously returns the initial response result, used to characterize the asynchronous response content corresponding to the target interface request. Streaming fragmented data refers to the segmented data generated in the asynchronous message results according to a streaming output method. Concatenation refers to the processing of combining multiple streaming fragmented data according to preset concatenation rules to generate a complete interface response result.

[0071] For example, the computer device sends the target interface request to the interface under test through the interface call phase in the three-level atomic interface template corresponding to the target interface execution node, and receives the initial response result synchronously returned by the interface under test. The computer device performs field-level validation on the initial response result to obtain the validation result. If the validation result is successful, the asynchronous message identifier is extracted from the initial response result, and the asynchronous message database is polled according to the asynchronous message identifier at a preset query interval to obtain multiple streaming fragments of data. The multiple streaming fragments of data are identified as asynchronous message results. The multiple streaming fragments of data are concatenated according to the fragmentation order corresponding to the multiple streaming fragments of data to obtain the interface response result corresponding to the target interface request.

[0072] In one embodiment, field-level validation is performed on the initial response result to obtain a validation result, including: validating the response status code in the initial response result to obtain a first field validation result; validating the message status in the initial response result to obtain a second field validation result; validating the session identifier in the initial response result to obtain a third field validation result; validating the response data structure corresponding to the initial response result to obtain a structure validation result; if the first field validation result, the second field validation result, the third field validation result, and the structure validation result are all valid, the validation result is determined to be valid; if any of the first field validation result, the second field validation result, the third field validation result, or the structure validation result is valid, the validation result is determined to be valid. Here, the response status code refers to the information in the initial response result used to characterize the overall processing status of the tested interface in response to the target interface request. The response status code can be used to determine whether the tested interface successfully received or successfully processed the target interface request. The first field validation result refers to the validation result obtained after validating the response status code, used to characterize whether the response status code meets the corresponding status code validation conditions. The message status refers to the information in the initial response result used to characterize the message processing status corresponding to the target interface request. The second field validation result refers to the validation result obtained after validating the message status, used to indicate whether the message status meets the corresponding message status validation conditions. The session identifier refers to the identifier information in the initial response result used to identify the session to which the current interface call belongs. The third field validation result refers to the validation result obtained after validating the session identifier, used to indicate whether the session identifier meets the corresponding session identifier validation conditions. The response data structure refers to the data structure formed by the various response fields and their organizational relationships in the initial response result. Compliance validation refers to the process of judging whether the response data structure corresponding to the initial response result conforms to the preset requirements based on the preset response structure specifications. The structure validation result refers to the validation result obtained after validating the response data structure corresponding to the initial response result. Validation failure refers to the result state where any field validation result or structure validation result fails to meet the corresponding validation conditions. Asynchronous message query processing refers to the process of querying asynchronous message results in the asynchronous message database based on the asynchronous message identifier in the initial response result after the initial response result passes field-level validation.

[0073] In one embodiment, based on the asynchronous message identifier in the initial response result, a polling query is performed in the asynchronous message database until an asynchronous message result corresponding to the target interface request is obtained. This includes: obtaining the asynchronous message identifier and session identifier from the initial response result, and using the asynchronous message identifier and session identifier as joint query conditions; performing a message query in the asynchronous message database based on the joint query conditions to obtain candidate asynchronous message results; and stopping the polling query if a target asynchronous message result with a message state belonging to a preset final state set exists among the candidate asynchronous message results, and determining the target asynchronous message result as the asynchronous message result corresponding to the target interface request. The joint query conditions refer to query conditions composed of the asynchronous message identifier and session identifier, used to locate the message record corresponding to the target interface request in the asynchronous message database. By using the asynchronous message identifier and session identifier as joint query conditions, mismatches caused by querying based on only a single identifier can be reduced, improving the accuracy of asynchronous message result queries. Message query refers to the process of retrieving message records in the asynchronous message database based on joint query conditions. Candidate asynchronous message results refer to asynchronous message results that may correspond to the target interface request, obtained from the asynchronous message database based on joint query conditions. Candidate asynchronous message results can include one or more message records. Each message record can include information such as message content, message status, generation time, or streaming fragment data. The preset final state set refers to a pre-set set of message status values ​​indicating that the asynchronous message result has been successfully generated. The status values ​​in the preset final state set are used to determine whether a candidate asynchronous message result can be used as the complete asynchronous message result corresponding to the target interface request. The target asynchronous message result refers to the asynchronous message result whose message status belongs to the preset final state set among the candidate asynchronous message results. The target asynchronous message result is used as the asynchronous message result corresponding to the target interface request and is passed to the subsequent streaming fragment concatenation process.

[0074] In one embodiment, based on the asynchronous message identifier in the initial response result, a polling query is performed in the asynchronous message database until an asynchronous message result corresponding to the target interface request is obtained. This further includes: if no target asynchronous message result with a message state belonging to a preset final state set exists among the candidate asynchronous message results, and the cumulative waiting time is greater than or equal to a preset waiting time threshold, the polling query is stopped, and a polling timeout exception result is generated; if no target asynchronous message result with a message state belonging to a preset final state set exists among the candidate asynchronous message results, and the cumulative waiting time is less than the preset waiting time threshold, the process waits based on the current waiting interval, updates the current waiting interval according to a preset backoff strategy, and returns to the step of querying the message in the asynchronous message database based on the joint query conditions. Here, the cumulative waiting time refers to the waiting time elapsed from the start of the polling query to the current query time. The cumulative waiting time is used to determine whether the polling query has exceeded the allowed waiting time range. The preset waiting time threshold is a pre-set maximum waiting time for the polling query. The preset waiting time threshold is used to terminate the polling query when an asynchronous message result has not been generated for a long time, preventing the computer device from continuously executing invalid queries. The preset waiting time threshold can be determined based on the response characteristics of the interface under test, the business scenario, or the test configuration. A polling timeout exception result refers to the exception information generated when the cumulative waiting time is greater than or equal to the preset waiting time threshold, and the target asynchronous message result has still not been found. The polling timeout exception result indicates that the asynchronous message result corresponding to the target interface request has not been returned within the specified time. The current waiting interval refers to the waiting time between two adjacent polling queries. The current waiting interval is used to control the pause time before the computer device executes the next message query, to avoid excessively frequent access to the asynchronous message database. The preset backoff strategy refers to the strategy used to adjust the current waiting interval. The preset backoff strategy can be used to gradually increase the current waiting interval as the number of polls increases, thereby reducing the query pressure on the asynchronous message database. The preset backoff strategy can be an exponential backoff strategy, a linear backoff strategy, or a fixed interval backoff strategy.

[0075] In one embodiment, concatenating multiple streaming fragments to obtain an interface response result includes: obtaining multiple streaming fragments from asynchronous message results; grouping the multiple streaming fragments based on the stream identifier corresponding to each streaming fragment to obtain at least one streaming fragment group; for each streaming fragment group, sorting the streaming fragments in the streaming fragment group in ascending order based on the fragment sequence number corresponding to each streaming fragment in the streaming fragment group to obtain a sorted streaming fragment group; determining the corresponding target concatenation strategy based on the message type corresponding to each streaming fragment in the sorted streaming fragment group; concatenating the streaming fragments in the sorted streaming fragment group based on the target concatenation strategy to obtain complete response content; and generating an interface response result based on the session identifier and the complete response content. Here, the stream identifier refers to the identification information used to identify the data stream to which the streaming response belongs, and is used to group multiple streaming fragments belonging to the same streaming response into the same group. Grouping refers to the process of classifying and aggregating multiple streaming data fragments according to their corresponding stream identifiers. A streaming data fragment group refers to a set of streaming data fragments partitioned based on the same stream identifier. Fragment number refers to the sequence information used to characterize the order of streaming data fragments within the same streaming response. Ascending sorting refers to the process of arranging the streaming data fragments in the streaming data fragment group in ascending order of their fragment numbers. A sorted streaming data fragment group refers to the data group obtained by sorting the streaming data fragments in the streaming data fragment group in ascending order of their fragment numbers. Message type refers to the type information used to characterize the message content type corresponding to the streaming data fragments. Target concatenation strategy refers to the concatenation rules determined based on the message types corresponding to the streaming data fragments, used to combine the streaming data fragments in the sorted streaming data fragment group. Complete response content refers to the complete response content obtained after concatenating the streaming data fragments in the sorted streaming data fragment group.

[0076] In this embodiment, by obtaining the initial response result after sending the target interface request and performing field-level validation on the initial response result, it is possible to confirm whether the synchronous response of the interface under test meets the conditions for continued processing before executing the asynchronous message query, thereby avoiding the continued execution of invalid asynchronous queries in the event of an abnormal initial response. If the validation passes, the asynchronous message database is polled based on the asynchronous message identifier in the initial response result to obtain the asynchronous message results generated asynchronously by the interface under test. Furthermore, by grouping, sorting, and concatenating multiple streaming fragments in the asynchronous message results, the scattered streaming fragments can be restored into complete response content. Thus, for target intelligent robot interfaces that combine synchronous return and asynchronous streaming output, the interface response results corresponding to the target interface request can be completely obtained, thereby improving the completeness and reliability of the interface response result acquisition.

[0077] In one embodiment, result verification processing is performed on the interface response result to obtain the test action execution result corresponding to the current test action, including:

[0078] The interface response result is evaluated based on the first evaluation model to obtain a first confidence level; if the first confidence level is less than the confidence level threshold, the interface response result is evaluated based on the second evaluation model to obtain a second confidence level; the confidence level difference between the first confidence level and the second confidence level is determined; based on the confidence level difference and the interface response result, the test action execution result corresponding to the current test action is determined.

[0079] The first evaluation model is used for the initial evaluation of the interface response result. It assesses the degree of matching between the interface response result and the expected response conditions corresponding to the current test action. The first confidence level is the confidence information obtained after the first evaluation model evaluates the interface response result, representing the degree to which the interface response result satisfies the expected response conditions corresponding to the current test action. The confidence threshold is a preset threshold used to determine whether the first confidence level meets the requirements for determining the test action execution result. If the first confidence level is greater than or equal to the confidence threshold, the test action execution result corresponding to the current test action can be determined based on the first confidence level; if the first confidence level is less than the confidence threshold, it indicates that the evaluation result of the first evaluation model has low reliability and further verification evaluation is required. The second evaluation model is used for verification evaluation of the interface response result when the first confidence level is less than the confidence threshold. The second evaluation model may have different model structures, model parameters, evaluation prompts, or evaluation rules than the first evaluation model. The second confidence level refers to the confidence information obtained after the second evaluation model evaluates the interface response result. It is used to characterize the degree of confidence that the second evaluation model believes the interface response result meets the expected response conditions corresponding to the current test action. The confidence difference is the difference between the first and second confidence levels. It is used to characterize the degree of consistency between the evaluation results of the first and second evaluation models on the interface response result. The smaller the confidence difference, the higher the consistency between the evaluation results of the first and second evaluation models; the larger the confidence difference, the higher the difference between the evaluation results of the first and second evaluation models.

[0080] For example, after receiving the interface response result, the computer device performs a semantic evaluation of the interface response result using a first evaluation model to obtain a first confidence level. The computer device compares the first confidence level with a confidence level threshold. If the first confidence level is less than the confidence level threshold, the computer device performs a review evaluation of the interface response result based on a second evaluation model to obtain a second confidence level. The computer device calculates the confidence level difference between the first and second confidence levels. If the confidence level difference is less than or equal to a preset difference threshold, the computer device determines the test action execution result corresponding to the current test action based on the first confidence level, the second confidence level, and the interface response result. If the confidence level difference is greater than the preset difference threshold, the test action execution result corresponding to the current test action is determined as a result to be reviewed. The result to be reviewed refers to the test action execution result determined when the confidence level difference is greater than the preset difference threshold. This result indicates a significant difference between the evaluation results of the first and second evaluation models on the interface response result and indicates that the interface response result corresponding to the current test action will proceed to the subsequent review process. The subsequent review process includes at least one of manual review, third evaluation model review, or preset rule review.

[0081] In one embodiment, after comparing the first confidence level with the confidence threshold, the method further includes: if the first confidence level is greater than or equal to the confidence threshold, determining the test action execution result corresponding to the current test action based on the first confidence level and the interface response result.

[0082] In one embodiment, when the confidence difference is less than or equal to a preset difference threshold, the execution result of the test action corresponding to the current test action is determined based on the first confidence level, the second confidence level, and the interface response result. This includes: determining the average confidence level of the first confidence level and the second confidence level; and determining the execution result of the test action corresponding to the current test action based on the average confidence level and the interface response result. The average confidence level refers to the confidence level information obtained by averaging the first confidence level and the second confidence level.

[0083] In one embodiment, evaluating the interface response result based on a first evaluation model to obtain a first confidence level includes: obtaining evaluation prompt information corresponding to the current test action; calling the first evaluation model to perform evaluation based on the evaluation prompt information and the interface response result to obtain a first evaluation result; the first evaluation result includes a total evaluation score, dimension scoring information, a first confidence level, and an evaluation reason; and extracting the first confidence level from the first evaluation result. The evaluation prompt information includes scoring dimension information, scoring output structure information, and a total score calculation rule; the scoring dimension information includes intent hit rate, key information coverage, and factual consistency; the scoring output structure information is used to instruct the first evaluation model to output the evaluation result according to a preset data object structure; the total score calculation rule is used to determine the total evaluation score corresponding to the interface response result based on intent hit rate, key information coverage, and factual consistency, and the total evaluation score can be equal to the sum of the product of intent hit rate and the first weight, the product of key information coverage and the second weight, and the product of factual consistency and the third weight.

[0084] In one embodiment, the flowchart for model verification and evaluation is as follows: Figure 6 As shown, the process includes: after receiving the interface response result, the computer device performs a semantic evaluation of the interface response result using a first evaluation model to obtain a first confidence level; the computer device compares the first confidence level with a confidence level threshold. If the first confidence level is greater than or equal to the confidence level threshold, the computer device determines the test action execution result corresponding to the current test action based on the first confidence level and the interface response result. If the first confidence level is less than a confidence threshold, the interface response result is reviewed and evaluated based on the second evaluation model to obtain a second confidence level; the confidence difference between the first and second confidence levels is determined; if the confidence difference is less than a first preset difference threshold, the execution result of the test action corresponding to the current test action is determined based on the first or second confidence level and the interface response result; if the confidence difference is greater than or equal to the first preset difference threshold and less than the second preset difference threshold, the average confidence level of the first and second confidence levels is determined, and the execution result of the test action corresponding to the current test action is determined based on the average confidence level and the interface response result; if the confidence difference is greater than or equal to the second preset difference threshold, the execution result of the test action corresponding to the current test action is determined as a result to be reviewed. The second preset difference threshold is greater than the first preset difference threshold.

[0085] In one embodiment, the flowchart for verifying the interface response result is as follows: Figure 7As shown, the determination process sequentially includes field-level validation, polling query, streaming fragment data concatenation, and result validation processing. Specifically, the computer device first performs field-level validation on the initial response result to obtain the validation result; if the validation result is successful, it performs a polling query on the asynchronous message database based on the asynchronous message identifier in the initial response result until it obtains the asynchronous message result corresponding to the target interface request. The asynchronous message result includes multiple streaming fragment data; then, the multiple streaming fragment data are concatenated to obtain the interface response result; finally, result validation processing based on the evaluation model is performed on the interface response result to obtain the test action execution result corresponding to the current test action.

[0086] In this embodiment, the interface response result is evaluated using a first evaluation model to obtain a first confidence level. This allows the verification process of the interface response result to move beyond relying solely on field matching or fixed rule judgments, and instead incorporates a semantic evaluation of the interface response content. If the first confidence level is less than a confidence threshold, the interface response result is re-evaluated using a second evaluation model to obtain a second confidence level. This allows low-confidence response results to enter a secondary evaluation process, preventing a single evaluation model from directly determining the test action execution result due to semantic understanding bias, unstable output, or insufficient confidence. Furthermore, by calculating the confidence difference between the first and second confidence levels, and based on the confidence difference and the interface response result, the execution result of the current test action is determined. This ensures that the test action execution result is simultaneously constrained by both the interface response content and the consistency of multi-model evaluations. Therefore, by triggering a re-evaluation based on low confidence and determining the test action execution result based on the confidence difference, the reliability of semantic interface response result verification is improved, the impact of misjudgments by a single evaluation model on the test action execution result is reduced, and the accuracy of the test action execution result corresponding to the current test action is improved.

[0087] In one embodiment, obtaining the current test action identifier from the test action sequence includes:

[0088] Obtain a reference state information set, which is the state information set corresponding to the reference test action identifier. The reference test action identifier is the test action identifier corresponding to the latest completed test action. Update the reference state information set to obtain the current state information set. The current state information set includes the current execution position. If the control signal in the current state information set is executing normally, obtain the current test action identifier corresponding to the current execution position from the test action sequence.

[0089] The state information set refers to the data set used to characterize the finite state machine states during the execution of the test action sequence. The state information set includes at least one of the following: execution position, test action identifier, interface execution node identifier, and control signal. The execution position characterizes the current cursor position in the test action sequence. The test action identifier in the state information set characterizes the test action to be executed or already executed in the corresponding state. The interface execution node identifier characterizes the identifier information of the interface execution node obtained after looking up the test action identifier in the reverse routing table; the interface execution node identifier is used to determine the target interface execution node corresponding to the test action identifier. The control signal controls the state transition direction of the state information set. The state information set is used to transition between different execution states according to the control signal to determine the current test action identifier in the test action sequence. The reference state information set refers to the state information set corresponding to the reference test action identifier, used to characterize the state machine state corresponding to the most recently completed test action. The reference state information set includes at least one of the following: reference execution position, reference test action identifier, and reference interface execution node identifier. The reference execution position characterizes the position of the most recently completed test action in the test action sequence. The reference interface execution node identifier is used to represent the identifier information of the interface execution node obtained by looking up the reference test action identifier through the reverse routing table. The current state information set refers to the state information set obtained after state transition based on the reference state information set and control signals, used to represent the state machine state corresponding to the current test action to be executed. The current state information set includes at least one of the following: current execution position, control signal, current test action identifier, and current interface execution node identifier. When the control signal is "normal execution," the current execution position is the position obtained by advancing based on the reference execution position, the current test action identifier is the test action identifier corresponding to the current execution position in the test action sequence, and the current interface execution node identifier is the identifier information of the interface execution node obtained by looking up the current test action identifier through the reverse routing table. When the control signal is an interrupt signal or a termination signal, the current state information set transitions to the termination state. The most recently completed test action refers to the last test action that was completed before the current test action identifier acquisition process. Normal execution means that the test execution state represented by the control signal is a "continue execution" state, used to indicate continuing to acquire the current test action identifier from the test action sequence.

[0090] For example, after completing the test action corresponding to the reference test action identifier, the computer device obtains the reference state information set corresponding to the reference test action identifier; the computer device performs state transition on the reference state information set based on the control signals in the reference state information set, and when the control signals are executed normally, it advances and updates the execution position in the reference state information set to obtain the current state information set; the computer device reads the control signals in the current state information set, and when the control signals are executed normally, it obtains the current execution position from the current state information set, and obtains the corresponding test action identifier from the test action sequence based on the current execution position, and determines the test action identifier as the current test action identifier.

[0091] In one embodiment, the flowchart for determining the current test action identifier is shown below. Figure 8 As shown, the process includes: obtaining a reference state information set; the reference state information set is the state information set corresponding to the reference test action identifier, and the reference test action identifier is the test action identifier corresponding to the most recently completed test action; updating the reference state information set to obtain the current state information set, which includes the current execution position; if the control signal in the current state information set is normal execution, obtaining the current test action identifier corresponding to the current execution position from the test action sequence; if the control signal in the current state information set is an interrupt signal, or if the updated current execution position exceeds the length of the test action sequence, transferring the current state information set to a termination state and stopping the acquisition of the current test action identifier from the test action sequence.

[0092] In one embodiment, updating the reference state information set to obtain the current state information set includes: dividing the test action sequence into multiple test action sub-sequences when the concurrent cursor advance switch of the test case to be executed is in the on state and the test action sequence meets the preset concurrency conditions; configuring a corresponding execution cursor and state information set for each test action sub-sequence; updating the current state information set corresponding to each execution cursor based on the reference state information set corresponding to each execution cursor; each current state information set includes the current execution position of the corresponding execution cursor; and when the control signal in any current state information set is executing normally, obtaining the current test action identifier corresponding to the current execution position from the corresponding test action sub-sequence. For example, a schematic diagram of the concurrent advancement method is shown below. Figure 9As shown, the test action sequence includes test action identifiers 1 to 20. The computer device divides this test action sequence into four sub-sequences: the first sub-sequence includes test action identifiers 1 to 5, the second sub-sequence includes test action identifiers 6 to 10, the third sub-sequence includes test action identifiers 11 to 15, and the fourth sub-sequence includes test action identifiers 16 to 20. The computer device configures a corresponding set of state information for each sub-sequence. For each sub-sequence, the computer device sequentially obtains the corresponding current test action identifier based on the current execution position in the state information set. The state information sets for different sub-sequences are executed in parallel. Therefore, compared to the sequential execution method of test action identifiers 1 to 20, the concurrent execution method shortens the overall execution time of the test action sequence.

[0093] In this embodiment, by acquiring the reference state information set corresponding to the latest completed test action and updating the reference state information set, a current state information set including the current execution position is obtained, so that the advancement process of the test action sequence is driven by the finite state machine state. Furthermore, when the control signal in the current state information set is in normal execution mode, the current test action identifier corresponding to the current execution position is obtained from the test action sequence, so that the advancement process of the test action sequence is constrained by the control signal in the current state information set. Therefore, the test action sequence is not executed solely according to a fixed script order, but rather the current test action identifier is dynamically determined based on the current execution position and control signal in the current state information set, thereby improving the flexibility and controllability of the test action sequence advancement process.

[0094] In one exemplary embodiment, the architecture diagram of the testing method is as follows: Figure 10As shown, the test architecture includes a test case layer, a first-level distribution template layer, a second-level business line process template layer, and a third-level atomic interface template layer. The test case layer provides test cases to be executed, which include test business scenario identifiers, test action sequences, and test parameter information. The first-level distribution template layer performs scenario matching for the test cases to be executed and determines the corresponding target business line based on the test business scenario identifier. The second-level business line process template layer carries the test processes corresponding to different business lines and records the correspondence between test action identifiers and interface execution nodes through a reverse routing table. The third-level atomic interface template layer encapsulates atomic interface call logic such as user inbound, user message sending, and streaming message retrieval, and is reused by multiple second-level business line process templates. The third-level atomic interface template layer also generates target interface requests based on the target interface execution node, sends the target interface requests to the target intelligent robot under test, and performs result verification processing on the interface response results returned by the target intelligent robot. Result verification processing includes at least one of synchronous field assertions, asynchronous message queries, streaming sharding aggregation, and model evaluation verification, thereby obtaining the test results corresponding to the test cases to be executed.

[0095] Based on the architecture diagram of the above testing method, the testing method includes: The computer device obtains test cases to be executed through the test case layer. Each test case includes a test business scenario identifier and a test action sequence. The test action sequence includes multiple test action identifiers arranged in execution order. The computer device performs scenario matching on the test cases to be executed through the first-level distribution template layer and determines the corresponding target business line based on the test business scenario identifier. The computer device obtains the target test process corresponding to the target business line and the target reverse routing table through the second-level business line process template layer. The target reverse routing table includes the correspondence between test action identifiers and interface execution nodes. The computer device obtains the current test action identifier from the test action sequence through the second-level business line process template layer and determines the target reverse routing table based on the target business line. The routing table determines the target interface execution node corresponding to the current test action identifier; the computer device executes the current test action corresponding to the current test action identifier based on the target interface execution node through the three-level atomic interface template layer, generates a target interface request, and sends the target interface request to the target intelligent robot under test; the computer device receives the interface response result returned by the target intelligent robot through the three-level atomic interface template layer, and performs synchronous field assertion, asynchronous message query, streaming fragmentation aggregation, and model evaluation verification on the interface response result to obtain the test action execution result corresponding to the current test action; if all test action identifiers in the test action sequence have been executed, the computer device determines the test result corresponding to the test case to be executed based on the test action execution result corresponding to each test action.

[0096] The aforementioned testing method supports a configuration-based dynamic expansion mechanism. This mechanism means that when a new business line, test action, or interface under test is added, the testing capabilities can be expanded by updating the extended configuration information, without rewriting fixed test scripts or modifying test execution code. The extended configuration information includes at least one of the following: business scenario configuration information, reverse routing configuration information, and interface call configuration information. Specifically, the business scenario configuration information establishes the correspondence between the new business scenario identifier and the new business line identifier, enabling the first-level distribution template to distribute the new business scenario to the corresponding second-level business line process template; the reverse routing configuration information establishes the correspondence between the new test action identifier and the new interface execution node, enabling the second-level business line process template to determine the interface execution node corresponding to the new test action based on the updated reverse routing table; and the interface call configuration information describes the request parameters, interface address, response structure, and verification rules corresponding to the new interface under test, enabling the third-level atomic interface template to generate the target interface request and complete the result verification based on the interface call configuration information. Therefore, by updating the configuration to expand business lines, test actions, and interfaces under test, the testing method's adaptability to new business scenarios and new interface capabilities is improved.

[0097] The diagram illustrating the version update process for extended configuration information is as follows: Figure 11 As shown, the configuration publishing end submits a new version of the extended configuration information to the configuration center. The configuration center performs a consistency check between the current version and the expected version. If the consistency check passes, the current configuration version number is updated to the new version number, and the new version number is returned to the configuration publishing end and published to the computer device. For test cases that have already started, the computer device continues to use the configuration version locked at startup to execute the test action sequence. For newly started test cases, the computer device reads and locks the new version configuration to execute tests based on the new version configuration. If there is an anomaly in the new version configuration, the configuration center performs a rollback based on the historical version information and sends a rollback success message to the configuration publishing end, so that subsequent test cases can reread the rolled-back configuration version. Therefore, during the extended configuration information update process, running test cases are not affected by configuration changes, and newly started test cases use the updated configuration version, thereby improving the stability and consistency of the configuration extension process.

[0098] In an exemplary test scenario, this solution is applied to the automated testing of target intelligent robots across multiple business lines, and compared with traditional fixed-script testing solutions. In the traditional solution, each new business line typically requires a separate, complete test script, with business line integration taking approximately 2 to 3 days. With this solution, business line integration is completed using business scenario configuration information, reverse routing configuration information, and interface call configuration information, reducing integration time to approximately 0.5 days, a reduction of approximately 75% to 83%. In the traditional solution, the reuse rate of interface scripts between different business lines is low, with an atomic interface capability reuse rate of approximately 20% to 30%. With this solution, third-level atomic interface templates such as user connection, user message sending, streaming message retrieval, and session clearing are reused by multiple second-level business line process templates, increasing the atomic interface capability reuse rate to approximately 70% to 80%. Traditional solutions typically rely on single interface responses or manual checks for streaming response results, achieving a complete streaming response acquisition rate of approximately 70% to 80%. This new solution, through field-level validation, asynchronous message database polling, and streaming fragment data concatenation, improves the complete streaming response acquisition rate to over 95%. In traditional solutions, semantic response results mainly rely on manual judgment or single-model evaluation, resulting in semantic validation consistency of approximately 75% to 85%. This new solution introduces a second evaluation model for verification when the first evaluation model has low confidence, and determines the test action execution result based on the confidence difference, improving semantic validation consistency to approximately 90% to 95%. Therefore, this solution achieves improvements over traditional fixed-script testing solutions in terms of business line access efficiency, interface capability reusability, streaming response completeness acquisition rate, and semantic validation consistency.

[0099] In this embodiment, by inputting the test cases to be executed into the test case layer, and having the first-level distribution template layer perform scenario matching and business line distribution based on the test business scenario identifier, the test cases to be executed for different business scenarios dynamically enter the corresponding second-level business line process templates, thereby improving the flexibility of test process determination; by configuring a reverse routing table in the second-level business line process template, and determining the corresponding target interface execution node based on the current test action identifier in the test action sequence, the correspondence between test actions and interface execution nodes no longer depends on fixed script hard coding, but is dynamically determined through the reverse routing table, thereby improving the flexibility and maintainability of interface execution node determination; by encapsulating the atomic interface call processes such as user inbound, user message sending, and streaming message retrieval through the third-level atomic interface template, and completing the target interface request generation, the tested interface call, and the interface response result verification in the parameter assembly stage, the interface call stage, and the result verification stage respectively, multiple second-level business line process templates can reuse the same atomic interface capabilities, thereby reducing the writing of repetitive interface scripts and improving the reusability of test capabilities; by sequentially executing field-level verification, asynchronous message database polling, streaming fragmented data splicing, and model evaluation verification in the result verification layer, the test process is improved. The response results of the target intelligent robot interface, which combines synchronous return and asynchronous streaming output, are fully acquired and verified, thereby improving the completeness of the interface response results and the reliability of the test action execution results. By introducing a second evaluation model for verification when the confidence of the first evaluation model is insufficient, and determining the test action execution results based on the confidence difference, the verification of semantic interface response results is constrained by both the interface response content and the consistency of multi-model evaluations, thus reducing the impact of misjudgments by a single evaluation model on the test action execution results. By recording the current execution position and control signals during the test action sequence execution process through a state information set, the test action sequence is dynamically advanced according to the finite state machine state, rather than mechanically executed according to a fixed script order, thereby improving the flexibility and controllability of the test action sequence advancement process. By extending configuration information to configure new business lines, new test actions, and new interfaces under test, and through configuration version locking, version release, and historical version rollback mechanisms, running test cases are unaffected by configuration changes, and newly started test cases use the updated configuration version, thereby improving the adaptability of the testing method to new business scenarios and new interface capabilities, as well as the stability and consistency of the configuration extension process. Overall, this embodiment achieves end-to-end automated test orchestration, from business scenario distribution, test action routing, interface calls, asynchronous result acquisition, semantic result verification to configuration-based extension, improving the flexibility, reliability, and scalability of the multi-business line testing process for the target intelligent robot.

[0100] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0101] Based on the same inventive concept, this application also provides a testing apparatus for implementing the testing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more testing apparatus embodiments provided below can be found in the limitations of the testing method described above, and will not be repeated here.

[0102] In one embodiment, such as Figure 12 As shown, a testing apparatus is provided, comprising: an acquisition module 1202, a determination module 1204, a matching module 1206, a calling module 1208, and an output module 1210, wherein:

[0103] The acquisition module 1202 is used to acquire test cases to be executed; the test cases to be executed include test business scenario identifiers and test action sequences, and the test action sequences include multiple test action identifiers arranged in execution order;

[0104] The determination module 1204 is used to determine the target test process corresponding to the test business scenario identifier and obtain the target reverse routing table corresponding to the target test process; the target reverse routing table includes the correspondence between test action identifiers and interface execution nodes;

[0105] The matching module 1206 is used to obtain the current test action identifier from the test action sequence and determine the target interface execution node corresponding to the current test action identifier based on the target reverse routing table;

[0106] Call module 1208 to execute the current test action corresponding to the current test action identifier through the target interface execution node, and obtain the test action execution result of the current test action;

[0107] Output module 1210 is used to return the steps of obtaining the current test action identifier from the test action sequence until there is no current test action identifier, and to determine the test result corresponding to the test case to be executed based on the test action execution result.

[0108] In one embodiment, the determining module 1204 is further configured to: obtain a business scenario distribution table; the business scenario distribution table includes the correspondence between candidate business scenario identifiers and candidate business line identifiers; determine the target business line identifier corresponding to the test business scenario identifier based on the business scenario distribution table; and determine the target test process corresponding to the target business line identifier from multiple candidate test processes.

[0109] In one embodiment, the calling module 1208 is further configured to: assemble the current test action execution parameters corresponding to the current test action identifier through the target interface execution node to generate a target interface request; send the target interface request to the interface under test corresponding to the target interface execution node based on the target interface execution node, and obtain the interface response result; perform result verification processing on the interface response result to obtain the test action execution result corresponding to the current test action.

[0110] In one embodiment, the calling module 1208 is further configured to: send the target interface request to the interface under test based on the target interface execution node and obtain the initial response result; perform field-level validation on the initial response result to obtain the validation result; if the validation result is successful, perform a polling query in the asynchronous message database based on the asynchronous message identifier in the initial response result until the asynchronous message result corresponding to the target interface request is obtained; the asynchronous message result includes multiple streaming fragments of data; and concatenate the multiple streaming fragments of data to obtain the interface response result.

[0111] In one embodiment, the calling module 1208 is further configured to: evaluate the interface response result based on the first evaluation model to obtain a first confidence level; if the first confidence level is less than the confidence level threshold, evaluate the interface response result based on the second evaluation model to obtain a second confidence level; determine the confidence level difference between the first confidence level and the second confidence level; and determine the test action execution result corresponding to the current test action based on the confidence level difference and the interface response result.

[0112] In one embodiment, the matching module 1206 is further configured to: obtain a reference state information set, wherein the reference state information set is a state information set corresponding to a reference test action identifier, and the reference test action identifier is a test action identifier corresponding to the latest completed test action; update the reference state information set to obtain a current state information set; the current state information set includes the current execution position; and, if the control signal in the current state information set is in normal execution mode, obtain the current test action identifier corresponding to the current execution position from the test action sequence.

[0113] Each module in the aforementioned testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0114] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 13 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a test method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0115] Those skilled in the art will understand that Figure 13The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0116] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0117] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0118] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0119] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0120] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0121] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0122] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A testing method, characterized in that, The method includes: Obtain test cases to be executed; the test cases to be executed include test business scenario identifiers and test action sequences, the test action sequences including multiple test action identifiers arranged in execution order; Determine the target test process corresponding to the test business scenario identifier, and obtain the target reverse routing table corresponding to the target test process; the target reverse routing table includes the correspondence between test action identifiers and interface execution nodes; Obtain the current test action identifier from the test action sequence, and determine the target interface execution node corresponding to the current test action identifier based on the target reverse routing table; The current test action corresponding to the current test action identifier is executed through the target interface execution node to obtain the test action execution result of the current test action; Return to the step of obtaining the current test action identifier from the test action sequence until there is no current test action identifier. Based on the test action execution result, determine the test result corresponding to the test case to be executed.

2. The method according to claim 1, characterized in that, The determination of the target test process corresponding to the test service scenario identifier includes: Obtain the business scenario distribution table; the business scenario distribution table includes the correspondence between candidate business scenario identifiers and candidate business line identifiers; Based on the business scenario distribution table, determine the target business line identifier corresponding to the test business scenario identifier; From multiple candidate test processes, determine the target test process corresponding to the target business line identifier.

3. The method according to claim 1, characterized in that, The step of executing the current test action corresponding to the current test action identifier through the target interface execution node to obtain the test action execution result of the current test action includes: The target interface execution node assembles the current test action execution parameters corresponding to the current test action identifier to generate a target interface request. Based on the target interface execution node, the target interface request is sent to the interface under test corresponding to the target interface execution node, and the interface response result is obtained; Perform result verification processing on the interface response result to obtain the test action execution result corresponding to the current test action.

4. The method according to claim 3, characterized in that, The step of sending the target interface request to the tested interface corresponding to the target interface execution node and obtaining the interface response result includes: Based on the target interface execution node, the target interface request is sent to the interface under test, and the initial response result is obtained; The initial response result is validated at the field level to obtain the validation result; If the verification result is successful, a polling query is performed in the asynchronous message database based on the asynchronous message identifier in the initial response result until the asynchronous message result corresponding to the target interface request is obtained; the asynchronous message result includes multiple streaming fragments of data; The multiple streaming fragments are concatenated to obtain the interface response result.

5. The method according to claim 3, characterized in that, The step of performing result verification processing on the interface response result to obtain the test action execution result corresponding to the current test action includes: The interface response result is evaluated based on the first evaluation model to obtain a first confidence level; If the first confidence level is less than the confidence threshold, the interface response result is evaluated based on the second evaluation model to obtain the second confidence level; Determine the confidence difference between the first confidence level and the second confidence level; Based on the confidence difference and the interface response result, the test action execution result corresponding to the current test action is determined.

6. The method according to claim 1, characterized in that, Obtaining the current test action identifier from the test action sequence includes: Obtain a reference status information set, which is a status information set corresponding to a reference test action identifier, which is a test action identifier corresponding to the latest completed test action; The reference state information set is updated to obtain the current state information set; the current state information set includes the current execution position; If the control signal in the current state information set is being executed normally, the current test action identifier corresponding to the current execution position is obtained from the test action sequence.

7. A testing apparatus, characterized in that, The device includes: The acquisition module is used to acquire test cases to be executed; the test cases to be executed include test business scenario identifiers and test action sequences, and the test action sequences include multiple test action identifiers arranged in execution order; The determination module is used to determine the target test process corresponding to the test business scenario identifier, and obtain the target reverse routing table corresponding to the target test process; the target reverse routing table includes the correspondence between test action identifiers and interface execution nodes; The matching module is used to obtain the current test action identifier from the test action sequence and determine the target interface execution node corresponding to the current test action identifier based on the target reverse routing table; The calling module is used to execute the current test action corresponding to the current test action identifier through the target interface execution node, and obtain the test action execution result of the current test action; The output module is used to return the step of obtaining the current test action identifier from the test action sequence until there is no current test action identifier, and to determine the test result corresponding to the test case to be executed based on the test action execution result.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images