Information display method, device, equipment and storage medium

Abstract

The application discloses an information display method and device, equipment and a storage medium, and belongs to the technical field of computers. The method comprises the following steps: displaying description information of a first test step, the first test step being any test step in a test case; in response to the first test step meeting a step execution condition, acquiring an execution result of the first test step; and displaying first prompt information in an associated area of the description information of the first test step, the first prompt information being used for prompting the execution result of the first test step. Based on the method, the interaction of the test step level in the test case can be realized, the user can perceive more fine-grained information, the interaction experience of the user is improved, and the human-computer interaction rate is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an information display method, apparatus, device, and storage medium. Background Technology

[0002] With the continuous development of computer technology, the functions and structures of software systems are becoming increasingly complex, making software testing increasingly important in product development and quality assurance. Test cases, as the basic unit of software testing, are a collection of structured testing steps used to verify whether a software system or its components meet preset requirements and functional indicators. They are a crucial foundation for achieving standardized and reproducible testing. In some cases, information related to the test cases can be displayed for user viewing. Summary of the Invention

[0003] This application provides an information display method, apparatus, device, and storage medium, which can be used to improve the human-computer interaction rate. The technical solution provided by this application includes the following aspects.

[0004] On one hand, embodiments of this application provide an information display method, the method comprising: Display the description information of the first test step, which is any test step in the test case; In response to the first test step satisfying the step execution condition, the execution result of the first test step is obtained; A first prompt message is displayed in the associated area of ​​the description information of the first test step. The first prompt message is used to indicate the execution result of the first test step.

[0005] On the other hand, an information display device is provided, the device comprising: The display unit is used to display the description information of the first test step, which is any test step in the test case; The acquisition unit is used to acquire the execution result of the first test step in response to the first test step satisfying the step execution condition; The display unit is further configured to display a first prompt message in the associated area of ​​the description information of the first test step, the first prompt message being used to indicate the execution result of the first test step.

[0006] In one possible implementation, the acquisition unit is configured to automatically execute the first test step; in response to the first test step not being successfully executed automatically, display a takeover control; in response to the triggering operation of the takeover control, display mode switching information and a completion control, wherein the mode switching information is used to indicate that the automatic execution mode has been switched to the manual execution mode; and in response to the triggering operation of the completion control, acquire the manual execution result of the first test step.

[0007] In one possible implementation, the acquisition unit is configured to automatically execute the first test step based on the automated execution instruction bound to the first test step.

[0008] In one possible implementation, the acquisition unit is configured to invoke a neural network model to predict inference instructions for automatically executing the first test step; and automatically execute the first test step based on the inference instructions.

[0009] In one possible implementation, the neural network model includes a visual model and an inference model; the acquisition unit is used to call the visual model to extract visual features of the operation page screenshot, the operation page screenshot being obtained by performing image capture on the page on which the first test step depends; and to call the inference model to predict the inference instruction based on the visual features and the description information of the first test step.

[0010] In one possible implementation, the acquisition unit is used to invoke the inference model to analyze the step intent of the first test step based on the visual features and the description information of the first test step, and predict the inference instruction according to the step intent.

[0011] In one possible implementation, the display unit is further configured to display a second prompt message in response to the first test step not being successfully executed automatically, the second prompt message being used to indicate that the first test step was not successfully executed automatically.

[0012] In one possible implementation, the first test step includes an assertion step in the test case. The display unit is further configured to display suspected defect information and a confirmation control if the execution result of the assertion step is an assertion failure. The suspected defect information is used to indicate a suspected defect in the test case. In response to the triggering operation of the confirmation control, a defect reporting prompt is displayed. The defect reporting prompt is used to indicate relevant information about the defect indicated by the suspected defect information that has been stored.

[0013] In one possible implementation, the first test step is the first test step in the test case, and the first test step satisfies the step execution conditions, including: obtaining the trigger operation of the execution control; or... The first test step is not the first test step in the test case. The first test step satisfies the step execution conditions, including: the execution result of the second test step has been obtained, and the second test step is the test step in the test case that precedes the first test step.

[0014] In one possible implementation, the display unit is further configured to display a details control; in response to a triggering operation of the details control, display identification information of each test step in the test case; and in response to a triggering operation of the identification information of the first test step, display detailed execution information of the first test step.

[0015] In one possible implementation, the acquisition unit is configured to automatically execute the first test step; in response to the first test step being successfully executed automatically, to acquire the automatic execution result of the first test step.

[0016] In one possible implementation, the acquisition unit is further configured to acquire execution process record information of the first test step; and based on the execution process record information, acquire auxiliary information, which is used to provide assistance for the subsequent execution process of the first test step.

[0017] In one possible implementation, the auxiliary information includes at least one of inference description information, inference automation execution instructions, or inference code; wherein the inference description information is information inferred based on the execution process record information to describe the first test step; the inference automation execution instructions are instructions inferred based on the execution process record information to automatically execute the first test step; and the inference code is the code corresponding to the first test step in the automation execution code for automatically executing the test case, inferred based on the execution process record information.

[0018] In one possible implementation, the acquisition unit is configured to, when the auxiliary information includes inference description information, reverse-optimize the description information of the first test step based on the inference description information to obtain optimized description information of the first test step, and the optimized description information of the first test step is used for subsequent execution of the first test step.

[0019] In one possible implementation, the acquisition unit is configured to, when the auxiliary information includes inference automated execution instructions and the first test step is bound to an automated execution instruction, reverse-optimize the automated execution instructions bound to the first test step based on the inference automated execution instructions to obtain optimized automated execution instructions, the optimized automated execution instructions being used to subsequently execute the first test step; or, when the auxiliary information includes inference automated execution instructions and the first test step is not bound to an automated execution instruction, assist in creating automated execution instructions for the first test step based on the inference automated execution instructions, the automated execution instructions being used to subsequently execute the first test step.

[0020] In one possible implementation, the acquisition unit is configured to, when the auxiliary information includes inference code and the test cases of the first test step are bound to automated execution code, reverse-optimize the code in the automated execution code used to execute the first test step based on the inference code to obtain optimized automated execution code, the optimized automated execution code being used to subsequently execute the test cases of the first test step; or, when the auxiliary information includes inference code and the test cases of the first test step are not bound to automated execution code, assist in creating automated execution code for the test cases based on the inference code, the created automated execution code being used to subsequently execute the test cases of the first test step.

[0021] In one possible implementation, the acquisition unit is configured to acquire execution process recording information of the first test step in response to the execution process of the first test step satisfying the information recording conditions. The execution process of the first test step satisfying the information recording conditions includes the first test step not being bound to an automated execution instruction, or the first test step not being successfully executed based on the automated execution instruction bound to the first test step.

[0022] In one possible implementation, the test case is a test case that does not meet the conditions for automated execution.

[0023] In one possible implementation, the device further includes: An execution unit is configured to execute the test case in a managed manner via an automated pipeline in response to the test case meeting the managed execution conditions.

[0024] In one possible implementation, the test case satisfies the managed execution condition, including: each test step in the test case satisfies the managed execution sub-condition; wherein, the test step satisfies the managed execution sub-condition, including: the test step corresponds to an instruction for automatically executing the test step, and the test step has been successfully executed based on the instruction.

[0025] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to enable the computer device to implement any of the information display methods described above.

[0026] On the other hand, a computer-readable storage medium is also provided, wherein at least one computer program is stored in the computer-readable storage medium, the at least one computer program being loaded and executed by a processor to enable a computer to implement any of the information display methods described above.

[0027] On the other hand, a computer program or computer program product is also provided, the computer program or computer program product including computer instructions, which are loaded and executed by a processor to enable the computer to implement any of the information display methods described above.

[0028] The technical solution provided in this application has at least the following beneficial effects: The technical solution provided in this application displays the description information of the first test step in the test case and displays the first prompt information for indicating the execution result of the first test step in the associated area of ​​the description information. Based on this, it is possible to realize the interaction at the test step level in the test case, so that users can perceive more granular information, improve the user's interactive experience, and thus improve the human-computer interaction rate. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is a schematic diagram of a computer system provided in an embodiment of this application; Figure 2 This is a flowchart of an information display method provided in an embodiment of this application; Figure 3 This is a schematic diagram of a display page provided in an embodiment of this application; Figure 4 This is a schematic diagram of a test flowchart for a first test step provided in an embodiment of this application; Figure 5 This is a schematic diagram of a test flowchart for an assertion step provided in an embodiment of this application; Figure 6 This is a schematic diagram of another display page provided in an embodiment of this application; Figure 7 This is a schematic diagram illustrating the execution process of a first test step provided in an embodiment of this application; Figure 8 This is a timing diagram provided in this application embodiment, which unfolds from the perspective of test case interaction and data consistency; Figure 9 This is a system architecture diagram provided in an embodiment of this application; Figure 10 This is a schematic diagram of the interaction process of modules in a system architecture diagram provided in an embodiment of this application; Figure 11 This is a test case lifecycle state transition diagram provided in an embodiment of this application; Figure 12 This application provides a data flow diagram from test case input to accumulating assets. Figure 13 This is a schematic diagram of an information display device provided in an embodiment of this application; Figure 14 This is a schematic diagram of the structure of a server provided in an embodiment of this application; Figure 15 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0032] For ease of understanding, the terms used in this application are explained here.

[0033] Test cases are a set of structured testing steps used to verify whether a software system or its components meet preset requirements and functional specifications. They are an important foundation for achieving standardized and reproducible testing. Test cases are the basic unit of software testing.

[0034] Test steps are the core structured execution units that constitute test cases. They are pre-designed, ordered, executable, and reproducible sequences of operations to verify whether a software system or its components meet preset requirements and functional indicators. In some embodiments, test steps in a test case include, but are not limited to, given steps, when steps, and assertion steps (also known as result verification steps).

[0035] The GIVEN step is a pre-test preparation step used to set and establish the initial state, system environment, dependency data, user permissions, pre-configuration, and pre-business conditions required for test execution. It ensures that the test starts in a defined and consistent context, providing a stable foundation for subsequent operations and result verification.

[0036] WHEN step: This belongs to the core action test step. It is a sequence of specific actions such as triggering, interaction, input, calling, and business operation performed on the system or component under test. Through clear operation instructions and input data, it drives the system to produce corresponding behaviors, state changes or output results. It is the core execution link to achieve the test objective.

[0037] THEN step: This is a result verification test step, used to compare, judge and verify the output content, interface performance, data status, return results, log information or business rules after the system performs the operation, to confirm whether the system behavior and output meet the preset requirements, functional indicators and expected results, and is the key basis for judging whether the test case passes.

[0038] Human In The Loop (HITL): Introducing an interactive mechanism of human supervision and intervention at key decision-making nodes to ensure the involvement of human wisdom and experience.

[0039] Execution process log information: Information recorded during the execution of test steps in a test case. For example, execution process log information may include, but is not limited to, behavioral sequences generated when operating a page, DOM (Document Object Model) fragments, network data, click coordinates, image information, and descriptive information of test steps. In some embodiments, execution process log information may also be referred to as fingerprint data, process fingerprint, operation fingerprint data, operation fingerprint, etc.

[0040] In related technologies, test cases are automatically executed based on automated code execution, and the execution results are displayed, such as test case not executed successfully, test case passed, or test case failed. However, this only enables test case-level interaction, resulting in coarse-grained information perceived by the user, a poor interactive experience, and a low human-computer interaction rate.

[0041] In response, this application provides an information display method that can be used to improve the human-computer interaction rate.

[0042] refer to Figure 1 This diagram illustrates a computer system provided in an embodiment of this application. The computer system may include a terminal 11 and a server 12.

[0043] Terminal 11 is equipped with a target client, and the information display method provided in this application embodiment can be executed by the target client. The target client is a client capable of displaying information related to test cases. In some embodiments, the target client may be called an LBDA (LMM-based Desktop Automation) client.

[0044] Server 12 provides background services to the target client. In one possible implementation, server 12 undertakes the main computational work of the target client, while terminal 11 undertakes the secondary computational work. Alternatively, server 12 undertakes the secondary computational work of the target client, while terminal 11 undertakes the main computational work. Or, terminal 11 and server 12 employ a distributed computing architecture for collaborative computation of the target client. Exemplarily, server 12 is equipped with an LMM (Logistic Model), and terminal 11 can interact with server 12 to invoke the LMM during the execution of the information display method provided in this embodiment.

[0045] Optionally, terminal 11 can be any electronic product capable of human-computer interaction with the user through one or more methods such as a keyboard, touchpad, touchscreen, remote control, voice interaction, or handwriting device, such as PC (Personal Computer), mobile phone, PDA (Personal Digital Assistant), wearable device, PPC (Pocket PC), tablet computer, smart car system, smart TV, smart speaker, in-vehicle terminal, etc. Server 12 can be a single server, a server cluster consisting of multiple servers, or a cloud computing service center. Terminal 11 and server 12 establish a communication connection through wired or wireless network.

[0046] In this embodiment, terminal 11 can display description information of a first test step, which is any test case in the test cases. When the execution conditions of the first test step are met, the execution result of the first test step is obtained, and a first prompt message indicating the execution result of the first test step is displayed in the associated area of ​​the description information of the first test step.

[0047] For example, the process of obtaining the execution result of the first test step includes: automatically executing the first test step; if the first test step is successfully executed automatically, obtaining the automatic execution result of the first test step; if the first test step is not successfully executed automatically, obtaining the manual execution result of the first test step.

[0048] For example, the first test step can be a GIVEN step, a WHEN step, or a THEN step.

[0049] See Figure 1 When the first test step is the GIVEN step, terminal 11 displays the description information 1 of the GIVEN step. If the GIVEN step meets the execution conditions, it is automatically executed. Taking the successful automatic execution of the GIVEN step as an example, terminal 11 obtains the automatic execution result of the GIVEN step and displays the first prompt information 2 in the associated area of ​​the description information 1 of the GIVEN step to indicate the automatic execution result. The first prompt information 2 indicates that the GIVEN step has been successfully completed through automatic execution.

[0050] When the first test step is the WHEN step, the terminal 11 displays the description information 3 of the WHEN step. When the WHEN step meets the step execution conditions, the WHEN step is executed automatically. Taking the WHEN step as an example where the WHEN step is not executed automatically, the terminal 11 obtains the manual execution result of the WHEN step and displays the first prompt information 4 in the associated area of ​​the description information 3 of the WHEN step to indicate the manual execution result of the WHEN step. The first prompt information 4 is used to indicate that the WHEN step has been completed by successfully executing the WHEN step manually.

[0051] When the first test step is THEN step, terminal 11 displays the description information 5 of THEN step. When the execution conditions of THEN step are met, THEN step is executed automatically. Taking the successful automatic execution of THEN step as an example, terminal 11 obtains the automatic execution result of THEN step and displays the first prompt information 6 in the associated area of ​​the description information 5 of THEN step to indicate the automatic execution result of THEN step. The first prompt information 6 is used to indicate that the assertion failed by successfully executing THEN step automatically.

[0052] Those skilled in the art should understand that the above-described terminal 11 and server 12 are merely examples. Other existing or future terminals or servers that are applicable to this application should also be included within the scope of protection of this application, and are hereby incorporated by reference.

[0053] This application provides an information display method, which can be applied to the above-mentioned... Figure 1 The computer system shown. This method can be executed by a computer device, which may include a terminal (such as...). Figure 1 Terminal 11 in the middle), may also include a server (such as Figure 1 (Server 12 in the example). In other words, the information display method provided in this application embodiment can be executed by a terminal, or it can be executed interactively by the terminal and the server. Taking the method executed by the terminal as an example, such as... Figure 2 As shown, the information display method provided in this application embodiment may include the following steps 201 to 203: In step 201, the description information of the first test step is displayed. The first test step is any test step in the test case.

[0054] Test cases can be any type of test case.

[0055] In one possible implementation, the test cases are those that do not meet the conditions for automated execution. These test cases have a high demand for test step-level interaction. Providing test step-level interaction for these test cases helps to meet their interaction requirements and ensures the quality of their interaction.

[0056] Test cases that do not meet the conditions for automated execution are test cases that cannot be executed automatically successfully. In an exemplary embodiment, test cases that do not meet the conditions for automated execution include: test cases that are not bound to automated execution code; or test cases that fail to execute based on bound automated execution code.

[0057] Whether it is a test case that is not bound to automated execution code or a test case that fails to execute successfully based on bound automated execution code, the information display method provided in this application embodiment can be used to achieve interaction at the test step level. The information display method provided in this application embodiment is applicable to a wide range of scenarios and can achieve fine-grained information interaction for test cases in a wide range of scenarios.

[0058] Automated execution code is code pre-written by a technician to automatically execute test cases. The technician can be any person with the ability to write automated execution code; for example, the technician can be an automation test engineer.

[0059] For example, the failure of a test case to be executed based on the binding-based automated execution code can refer to the failure of the previous execution of the test case based on the binding-based automated execution code, or it can refer to the proportion of unsuccessful executions of test cases based on the binding-based automated execution code being greater than a proportion threshold.

[0060] The first test step is any test step in the test case, and the description information of the first test step is textual information used to describe the first test step. This application embodiment does not limit the type of the first test step. Exemplarily, the first test step can be a precondition step (GIVEN step), an operation execution step (WHEN step), or an assertion step (THEN step, also known as a result verification step).

[0061] In some embodiments, the test case database records the status information and test case details of candidate test cases. In some embodiments, the test case database may also be referred to as a test case library. A candidate test case refers to a test case that has been created and is not yet offline. In some embodiments, a candidate test case is a test case used to test the same software system and its components. The status information of a candidate test case is used to indicate whether the candidate test case meets the conditions for automated execution. The test case details of a candidate test case are used to describe the candidate test case in detail. For example, the test case details of a candidate test case include the test case identifier of the candidate test case, the description information of the test steps in the candidate test case, and the status identifier of the test steps in the candidate test case.

[0062] The test case identifier of a candidate test case is used to uniquely identify the candidate test case. In some embodiments, the test case identifier can refer to the ID (Identifier) ​​of the candidate test case. The description information of the test steps in the candidate test case is information used to describe the test steps. For example, the description information of the test steps is textual information that clearly, completely, and in a standardized manner expresses the purpose, operation content, execution order, input conditions, operation objects, expected behavior, and verification rules of the test steps. It is used to clarify the execution intent, operation details, and verification basis of the test steps, making the test steps readable, executable, reproducible, and traceable. The status identifier of the test steps in the candidate test case is used to indicate whether the test steps in the candidate test case are bound to automated execution instructions. Automated execution instructions are terminal-recognizable instructions obtained by converting the code used to execute the test steps in the automated execution code bound to the candidate test case.

[0063] In some embodiments, taking a test case that does not meet the conditions for automated execution as an example, the implementation of displaying the description information of the first test step can be as follows: in response to the test plan instruction, obtain the test case details of the test case that does not meet the conditions for automated execution from the test case database; extract the description information of each test step in the test case that does not meet the conditions for automated execution from the test case details of the test case that does not meet the conditions for automated execution, and display the description information of each test step in the test case that does not meet the conditions for automated execution, wherein each test step includes the first test step.

[0064] In some embodiments, test plan instructions can be instructions entered by a user in an input box in the target client. These instructions instruct interaction at the test step level with test cases that do not meet the conditions for automated execution. The user can be any user capable of interacting with test cases at the test step level; for example, a user can be a manual test engineer. In some embodiments, the target client is a client provided in this application embodiment that allows users to interact with test cases at the test step level in a visual manner. In some embodiments, the target client may also be referred to as an LBDA client.

[0065] In some embodiments, obtaining test case details of test cases that do not meet the conditions for automated execution from the test case database can be achieved by calling a first interface to obtain the test case details of test cases that do not meet the conditions for automated execution from the test case database. The first interface is an interface used to access the test case database; in some embodiments, the first interface is an API (Application Programming Interface).

[0066] In some embodiments, if there are multiple test cases that do not meet the automated execution conditions, all test cases that do not meet the automated execution conditions can be obtained, or only the first test case among all test cases that do not meet the automated execution conditions can be obtained. After the first test case is executed, the subsequent test cases are obtained sequentially. In some embodiments, the first test case among all test cases that do not meet the automated execution conditions refers to the test case that first fails to meet the automated execution conditions.

[0067] In an exemplary embodiment, displaying descriptions of each test step in a test case that does not meet the conditions for automated execution may refer to displaying descriptions of each test step in a test case that does not meet the conditions for automated execution on the target client's display page.

[0068] For example, the target client's display page includes a test case display area, which is used to display description information of each test step in the test case that does not meet the conditions for automated execution. That is, the way to display the description information of each test step in the test case that does not meet the conditions for automated execution on the target client's display page is to display the description information of each test step in the test case display area of ​​the target client's display page.

[0069] For example, the target client's display page also includes a dialog area for displaying dialogue initiated by the test assistant and / or the user during the execution of various test steps in test cases that do not meet the conditions for automated execution. The test assistant is an intelligent or automated processing module embedded in the target client that has test assistance capabilities. In some embodiments, the test assistant is an AI (Artificial Intelligence) assistant.

[0070] For example, the target client's display page also includes an input box and a send control. The input box is used for the user to input information, and the send control is used for the user to send the information entered in the input box to the dialog area to form user-initiated dialog content.

[0071] This application does not limit the display positions of the test case display area, dialog area, input box, and send control on the display page. In some real-time scenarios, the test case display area is displayed in the upper area of ​​the display page, the dialog area is displayed in the lower area of ​​the display page, the input box is displayed below the dialog area, and the send control is displayed to the right of the input box.

[0072] For example, the target client's display page can be as follows: Figure 3 As shown. In Figure 3 The displayed page includes a test case display area 310, a dialog area 320, an input box 330, and a send control 340. The test case display area 310 displays descriptive information of each test step in the test case. The dialog area 320 displays dialogue content initiated by the test assistant and / or the user during the execution of each test step in the test case. The input box 330 is for the user to input information, and the send control 340 allows the user to send the information entered in the input box 330 to the dialog area 320 to form user-initiated dialogue content.

[0073] exist Figure 3The test case display area 310 shows the description information 311 of the three test steps in the test case. The three test steps are the GIVEN step, the WHEN step, and the THEN step. The description information of the GIVEN step is "Open mind map editor", the description information of the WHEN step is "Move a node", and the description information of the THEN step is "Verify node position change".

[0074] In some embodiments, after obtaining the test case details from the test case database, execution data related to the test case can also be obtained from the execution database based on the test case identifier. The execution database is used to store execution data related to test cases. In some embodiments, the execution database may also be referred to as a fingerprint database, fingerprint repository, etc.

[0075] For example, the execution data related to the test case may include, but is not limited to, the automated execution instructions bound to the test steps in the test case, the historical execution process records of the test steps in the test case, and auxiliary information obtained based on the historical execution process records of the test steps in the test case. Historical execution process records refer to information recorded during the historical execution of the test steps of the test case. In some embodiments, historical execution process records may include information recorded during the previous one or more historical executions of the test steps of the test case. A further description of historical execution process records and auxiliary information obtained based on them can be found in the later description of the execution process records of the first test step and the auxiliary information obtained based on them; these details will not be repeated here.

[0076] For example, the method for retrieving test case-related execution data from the execution database based on the test case identifier can be as follows: based on the test case identifier, a second interface is called to retrieve the test case-related execution data from the execution database. The second interface is an interface used to access the execution database; in some embodiments, the second interface is an API.

[0077] In step 202, in response to the first test step satisfying the step execution conditions, the execution result of the first test step is obtained.

[0078] The fact that the first test step meets the execution conditions indicates that the first test step needs to be executed. For example, the way in which the first test step meets the execution conditions depends on its position within the test case.

[0079] In one possible implementation, if the first test step is the first test step in the test case, the first test step satisfies the step execution conditions by obtaining the trigger operation of the execution control; or, if the first test step is not the first test step in the test case, the first test step satisfies the step execution conditions by obtaining the execution result of the second test step, and the second test step is the test step in the test case that precedes the first test step.

[0080] When the first test step is the first test step in the test case, the execution of the first test step is triggered by the trigger operation of the execution control, and the execution process of the first test step in the test case is manually controlled, which is highly standardized; when the first test step is not the first test step in the test case, the execution process of the first test step is automatically triggered based on the execution result of the previous test step, without the need for manual intervention, which is highly efficient.

[0081] The execution control is used to control the start of test case execution. Since test cases are executed by executing each test step in the test case sequentially, if the execution control is triggered, it is assumed that the first test step in the test case needs to be executed, that is, the first test step meets the step execution conditions.

[0082] In some embodiments, the triggering operation of the control may include, but is not limited to, clicking or long-pressing the control.

[0083] This application does not limit the order in which the description information and execution controls of the first test step are displayed. In some embodiments, the description information and execution controls of the first test step may be displayed together on the display page; in some embodiments, the description information of the first test step is displayed on the display page first, and then the execution controls are displayed on the display page; in some embodiments, the execution controls are displayed on the display page first, and then the description information of the first test step is displayed on the display page.

[0084] This application does not limit the display position of the execution control in its embodiments. Exemplarily, the execution control can be displayed in the test case display area of ​​the display page. Exemplarily, the execution control can be displayed above the description information of the first test step in the test case display area. For example, see... Figure 3 The test case display area 310 shows the execution control 312.

[0085] If the execution conditions of the first test step are met, the execution result of the first test step is obtained. The execution result of the first test step may be the result of automatic execution or the result of manual execution.

[0086] The content of the manually executed result of the first test step may be the same as or different from the content of the automatically executed result of the first test step. In some embodiments, the content of the manually executed result of the first test step includes content indicating the specific result and content indicating the specific result was obtained through manual execution; the content of the automatically executed result of the first test step includes content indicating the specific result and content indicating the specific result was obtained through automatic execution.

[0087] The content of the execution result of the first test step is related to the type of the first test step. For example, if the first test step is a test step other than the assertion step (THEN step), the content of the execution result of the first test step is used to indicate that the first test step has been completed. For example, the content of the automatic execution result of the first test step can be the text "Completed" or "Automatically Completed", and the content of the manual execution result of the first test step can be the text "Manually Completed".

[0088] For example, if the first test step is an assertion step, the content of the execution result of the first test step is used to indicate whether the assertion was successful. For example, the content of the automatic execution result of the first test step can be the text "assertion successful" or "assertion failed", and the content of the manual execution result of the first test step can be the text "manual assertion successful" or "manual assertion failed".

[0089] In some embodiments, the assertion step is the last test step in the test case. If the execution result of the assertion step is an assertion success, the entire test case can be considered to have been successfully tested; if the execution result of the assertion step is an assertion failure, the entire test case can be considered to have failed.

[0090] In one possible implementation, obtaining the execution result of the first test step includes: automatically executing the first test step; and obtaining the automatic execution result of the first test step in response to the successful automatic execution of the first test step.

[0091] In the process of obtaining the execution result of the first test step, the first test step is executed automatically first. If the first test step is successfully executed automatically, the automatic execution result of the first test step is obtained directly. This helps to improve the efficiency of obtaining the execution result of the first test step and can also reduce the labor cost brought about by directly executing the first test step manually.

[0092] In one possible implementation, automatically executing the first test step includes: automatically executing the first test step based on an automated execution instruction bound to the first test step. In some embodiments, this implementation of automatically executing the first test step can occur when the first test step is bound to an automated execution instruction.

[0093] The automatic execution of the first test step based on the automated execution instructions bound to the first test step can ensure the efficiency of the automatic execution of the first test step, thereby improving the efficiency of obtaining the execution results of the first test step.

[0094] An automated execution instruction is an instruction used to automatically execute the first test step. In an exemplary embodiment, the automated execution instruction is a terminal-recognizable instruction derived from the code used to execute the first test step in the automated execution code bound to the test case. In an exemplary embodiment, the automated execution instruction is an instruction inferred from the historical execution of the first test step for the purpose of automatically executing the first test step.

[0095] In some embodiments, the method for determining whether the first test step is bound to an automated execution instruction can be: extracting the status identifier of the first test step from the test case details, and determining whether the first test step is bound to an automated execution instruction based on the status identifier of the first test step.

[0096] For example, the status identifier of the first test step can be either a first identifier or a second identifier. When the status identifier of the first test step is the first identifier, the first test step is bound to an automated execution instruction; when the status identifier of the first test step is the second identifier, the first test step is not bound to an automated execution instruction. This application embodiment does not limit the types of the first identifier and the second identifier, as long as they are different. In some embodiments, the first identifier is true and the second identifier is false. In some embodiments, the first identifier is 1 and the second identifier is 0.

[0097] If an automated execution instruction is bound to the first test step, the automated execution instruction bound to the first test step can be extracted from the execution data related to the test case, and then the first test step can be executed automatically based on the automated execution instruction.

[0098] In some embodiments, the automated execution instructions are Playwright MCP (Playwright-adapted Model Context Protocol) instructions. Playwright MCP instructions are protocol implementations based on MCP extensions, specifically designed for interacting with Playwright, and are responsible for mapping MCP instructions to native operations executable by Playwright. Playwright is an open-source, cross-platform, cross-browser automation framework that supports web page manipulation, API requests, element manipulation, and result assertions, and is the core execution engine for front-end and API automation. MCP is a standardized communication protocol used for structured instruction interaction, context passing, and result feedback between intelligent models and external tools and execution engines, enabling models to invoke and control external capabilities.

[0099] For example, when the automated execution instruction is a Playwright MCP instruction, the implementation method of automatically executing the first test step based on the automated execution instruction can be: converting the Playwright MCP instruction into a Playwright executable operation, and having Playwright complete the automated execution and verification of the browser or interface based on the executable operation.

[0100] In some embodiments, the first test step is a web page-type test step, which refers to a test step involving interaction with a web page, such as clicking a button, entering text, validating page elements, or navigating to a new page. When the first test step is a web page-type test step, the terminal may display a page from a browser controlled by Playwright during the automatic execution of the first test step by the automated execution instruction.

[0101] There are two possible outcomes for automatically executing the first test step based on the automated execution instructions: successful execution of the first test step based on the automated execution instructions, or unsuccessful execution of the first test step based on the automated execution instructions.

[0102] If the first test step is successfully executed based on the automated execution instructions, it can be directly determined that the first test step was successfully executed automatically. If the first test step is not successfully executed based on the automated execution instructions, it can be directly determined that the first test step was not successfully executed automatically, or an inference instruction can be obtained and the first test step can be automatically executed again based on the inference instruction.

[0103] In one possible implementation, the automatic execution of the first test step includes: invoking a neural network model to predict inference instructions for automatically executing the first test step; and automatically executing the first test step based on the inference instructions. In some embodiments, this implementation occurs when the first test step is not bound to an automated execution instruction, or when the automated execution instruction bound to the first test step fails to execute the first test step.

[0104] The first test step is executed automatically based on inference instructions, ensuring automatic execution of the first test step under various conditions. Furthermore, the inference instructions are predicted by calling a neural network model, resulting in high accuracy and thus guaranteeing the reliability of the automatic execution of the first test step based on inference instructions.

[0105] The type of inference instructions is the same as the type of automated execution instructions; for example, the inference instructions are also a type of Playwright MCP instruction. The principle of automatically executing the first test step based on inference instructions is the same as the principle of automatically executing the first test step based on automated execution instructions.

[0106] The automatic execution of the first test step based on the inference instruction has two possible outcomes: successful execution or unsuccessful execution. If the first test step is successfully executed based on the inference instruction, it is determined that the first test step was successfully executed automatically; if it is unsuccessfully executed based on the inference instruction, it is determined that the first test step was not successfully executed automatically.

[0107] In an exemplary embodiment, the neural network model includes a visual model and an inference model; the process of calling the neural network model to predict the inference instructions for automatically executing the first test step includes: calling the visual model to extract visual features of the operation page screenshot, the operation page screenshot being obtained by capturing the page execution image on which the execution of the first test step depends; and calling the inference model to predict the inference instructions based on the visual features and the description information of the first test step.

[0108] First, the visual model is called to extract the visual features of the screenshot of the operation page. Then, the inference model is called to predict the inference instruction by comprehensively considering the visual features and the description information of the first test step. The process of predicting the inference instruction considers a relatively rich amount of information, which helps to further ensure the accuracy of the inference instruction, thereby further ensuring the reliability of automatically executing the first test step based on the inference instruction.

[0109] The screenshot of the operation page is an image obtained by cropping the image of the page on which the first test step depends. The screenshot of the operation page can represent the page environment in which the first test step is executed. For example, taking the first test step as moving a node in a mind map, the page on which the first test step depends can be a browser page displaying the mind map.

[0110] The visual model can be any model with visual feature extraction capabilities, and the visual features of the screenshot of the operation page are used to characterize the screenshot. Different types of visual models may extract visual features from the screenshot of the operation page in different ways, and this application does not limit this. In some embodiments, the visual features extracted by the visual model can be a vector, and the dimension of the vector is related to the type of visual model.

[0111] The inference model can be any model with inference capabilities. After inputting visual features and descriptive information of the first test step into the inference model, the inference model can analyze the intention of the first test step and predict the inference instruction based on the intention. In some embodiments, the inference instruction may also be referred to as operational behavior, AI instruction, etc.

[0112] In one possible implementation, the first test step may not be executed automatically. In this case, in response to the failure of the first test step to be executed automatically, a takeover control is displayed; in response to the triggering operation of the takeover control, mode switching information and a completion control are displayed, the mode switching information indicating that the automatic execution mode has been switched to the manual execution mode; in response to the triggering operation of the completion control, the manual execution result of the first test step is obtained.

[0113] If the first test step fails to execute automatically, it is handed over to a human to continue executing the first test step, ensuring its successful execution. During this manual execution, the displayed content and visual effects are richer, which improves the user's interactive experience and thus increases the human-computer interaction rate.

[0114] The takeover control is a control used to allow the user to take over the execution process of the first test step. In this application embodiment, the timing and location of the display of the takeover control are not limited.

[0115] For example, the timing of displaying the takeover control can be as follows: The takeover control is displayed when it is determined that the first test step has not been successfully executed automatically. Alternatively, the takeover control can be displayed by default on the display page. In this case, after the first test step meets the execution conditions but before it is determined that the first test step has not been successfully executed automatically, the takeover control is in a non-triggerable state. When it is determined that the first test step has not been successfully executed automatically, the takeover control changes from a non-triggerable state to a triggerable state. The triggering operation of the takeover control refers to the triggering operation of the takeover control when it is in a triggerable state.

[0116] For example, the takeover control can be displayed at the top of the target client's display page. See, for example, [link to relevant documentation]. Figure 3 A takeover control 350 is displayed at the top of the target client's display page.

[0117] For example, the triggering operation of the takeover control may include, but is not limited to, clicking the takeover control, long-pressing the takeover control, etc.

[0118] After receiving the trigger action of the takeover control, mode switching information and a completion control are displayed. The mode switching information indicates that the system has switched from automatic execution mode to manual execution mode, meaning the first test step is to be performed manually by the user. The completion control identifies whether the manual execution of the first test step has ended. After triggering the takeover control, the user manually executes the first test step; upon completion of the manual execution of the first test step, the completion control is triggered.

[0119] This application does not limit the display position of the mode switching information and the completion control in its embodiments. Exemplarily, the mode switching information and the completion control can be displayed in the test flow box of the first test step. The test flow box of the first test step is used to display information related to the test flow of the first test step. Exemplarily, the test flow box of the first test step can be displayed in the dialog area of ​​the target client's display page. Exemplarily, the completion control is displayed to the right of the mode switching information.

[0120] When the trigger operation of the completed control is obtained, it means that the process of manually executing the first test step has been completed. At this time, the manual execution result of the first test step is obtained.

[0121] In some embodiments, if the first test step is a test step other than the assertion step, after obtaining the trigger operation of the completion control, the manual execution result of the first test step can be obtained directly. The manual execution result is used to indicate that the first test step has been manually completed.

[0122] In some embodiments, when the first test step is a test step other than the assertion step, after the user triggers the completion control, a dialog message initiated by the user can be displayed in the test flow box of the first test step. The dialog message initiated by the user is used to indicate that the manual execution of the first test step has been completed. The dialog message can be automatically displayed in the test flow box of the first test step after the trigger operation of the completion control is obtained, or it can be displayed in the test flow box of the first test step after the user enters relevant information in the input box and triggers the send control.

[0123] In some embodiments, when the first test step is an assertion step, the user can enter the assertion result (e.g., assertion failed, assertion succeeded) in the input box of the display page after triggering the completion control, and send the assertion result to the test flow box of the first test step by triggering the send control. The terminal can determine the manual execution result based on the assertion result in the test flow box of the first test step.

[0124] In an exemplary embodiment, the method further includes: displaying a second prompt message in response to the first test step not being successfully executed automatically, the second prompt message being used to indicate that the first test step was not successfully executed automatically.

[0125] If the first test step is not executed automatically, a second prompt message is displayed to indicate that the first test step was not executed automatically. This allows users to intuitively understand that the first test step was not executed automatically, which helps to improve the user's interactive experience and thus increase the human-computer interaction rate.

[0126] The content of the second prompt message can be set based on experience or adjusted flexibly according to needs. This application embodiment does not limit this, as long as it can be used to indicate that the first test step was not successfully executed automatically. In some embodiments, the second prompt message may include the reason why the first test step was not successfully executed automatically. The reason why the first test step was not successfully executed automatically is related to the type of the first test step, and this application embodiment does not limit this. In some embodiments, the reason why the first test step was not successfully executed automatically may include, but is not limited to, element positioning timeout, missing element, operation execution timeout, DOM structure drift, etc.

[0127] In some embodiments, a second prompt message may be displayed in the test flow box of the first test step.

[0128] In step 203, a first prompt message is displayed in the associated area of ​​the description information of the first test step. The first prompt message is used to indicate the execution result of the first test step.

[0129] After obtaining the execution result of the first test step, a first prompt message indicating the execution result of the first test step is displayed in the associated area of ​​the description information of the first test step. The execution result of the first test step can be either the result of manual execution or the result of automatic execution. Based on this, users can quickly and conveniently learn the execution result of the first test step according to the information displayed in the associated area of ​​the description information of the first test step, improving the user's interactive experience and thus increasing the human-computer interaction rate.

[0130] The associated area of ​​the descriptive information for the first test step can be set based on experience or adjusted flexibly according to needs, and this application embodiment does not limit it in this way. For example, the associated area of ​​the descriptive information for the first test step can be the right area, left area, top area, bottom area, etc. of the descriptive information for the first test step.

[0131] In some embodiments, the first prompt message may be text, or text and identifiers, indicating the result of the execution of the first test step.

[0132] In some embodiments, in addition to displaying the first prompt information in the associated area of ​​the description information of the first test step, an identifier corresponding to the execution result of the first test step may also be displayed in the surrounding area of ​​the description information of the first test step. The identifier is used to symbolically indicate the execution result of the first test step. The surrounding area of ​​the description information of the first test step is different from the associated area of ​​the description information of the first test step. For example, the associated area of ​​the description information of the first test step may be the right-hand area of ​​the description information of the first test step, and the surrounding area of ​​the description information of the first test step may be the left-hand area of ​​the description information of the first test step.

[0133] For example, see Figure 3 The area surrounding the description information of each test step in the test case may include the left area 361 of the description information of each test step, and the associated area of ​​the description information of each test step in the test case may include the right area 362 of the description information of each test step. The left area 361 is used to display the identifier, and the right area 362 is used to display the first prompt information.

[0134] In an exemplary embodiment, the test flow box of the first test step may also display the execution result of the first test step, such as the automatic execution result of the first test step or the manual execution result of the first test step.

[0135] In some embodiments, when an automated execution instruction is bound to the first test step, the test flow box of the first test step may also display instruction information for the automated execution instruction. This instruction information may include information indicating the name of the automated execution instruction and information indicating the content of the automated execution instruction. In some embodiments, a copy control may also be displayed around the information indicating the content of the automated execution instruction; this copy control is used to copy the content of the automated execution instruction.

[0136] In some embodiments, the top area of ​​the test flow block of the first test step may also display identification information of the first test step. For example, the identification information of the first test step may include at least one of the step number of the first test step and the description information of the first test step.

[0137] In some embodiments, the top area of ​​the test flow box of the first test step may display information indicating the execution result of the first test step, so that the user can directly know the execution result of the first test step from the top area of ​​the test flow box of the first test step.

[0138] In some embodiments, a content control control may also be displayed in the top area of ​​the test flow box of the first test step, which is used to control the expansion or collapse of the content in the test flow box of the first test step.

[0139] For example, taking the first test step as the Give step, and assuming the Give step is successfully executed automatically, the test flowchart for the first test step can be found here. Figure 3 370 in. Figure 3 In the test flowchart 370 of the first test step shown, the top area displays identification information 371 for the first test step, information 372 indicating the execution result of the first test step, and content control controls 373. The test flowchart 370 of the first test step also displays indication information 374 for the automated execution instructions bound to the first test step and the automated execution result 375 of the first test step.

[0140] For example, taking the first test step as the WHEN step, and the WHEN step failing to execute automatically, the test flowchart for the first test step could be as follows: Figure 4 As shown. In Figure 4The test flow box for the first test step, as shown, displays identification information 401 for the first test step, information 402 indicating the execution result of the first test step, and content control controls 403 in the top area. The test flow box for the first test step also displays instruction information 404 for the automated execution command bound to the first test step, first prompt information 405, mode switching information 406, completion control 407, user-initiated dialogue content 408 indicating the completion of manual execution of the first test step, and the manual execution result 409 of the first test step.

[0141] In an exemplary embodiment, the first test step includes an assertion step in the test case, and the method further includes: if the execution result of the assertion step is an assertion failure, displaying suspected defect information and a confirmation control, wherein the suspected defect information is used to indicate a suspected defect in the test case; and in response to the triggering operation of the confirmation control, displaying defect reporting prompt information, wherein the defect reporting prompt information is used to indicate relevant information about the defect indicated by the stored suspected defect information.

[0142] If the assertion step fails, suspected defect information can be displayed for user confirmation. After user confirmation, the defect indicated by the suspected defect information is reported. Based on this, automatic defect identification can be achieved, reducing manual costs, and defects can be reported only after manual confirmation, ensuring the reliability of defect reporting.

[0143] For example, the assertion step is the last test step in the test case.

[0144] In some embodiments, a suspected defect in a test case can be predicted by calling a defect inference model. The defect inference model can be the same model as the inference model used for prediction inference instructions mentioned above, or it can be a different model.

[0145] In some embodiments, potential defects in test cases can be predicted based on first reference information and second reference information. For example, a defect inference model is invoked to predict potential defects in test cases based on the first and second reference information. The first reference information is the execution process record information of the test steps obtained during the current execution of each test step in the test case, and the second reference information is the execution process record information of the test steps obtained during the historical execution of each test step in the test case. In some embodiments, the first reference information can be referred to as new fingerprint data of the test case, and the second reference information can be referred to as historical fingerprint data of the test case.

[0146] This application does not limit the display position of the suspected defect information and the confirmation control. In an exemplary embodiment, both the suspected defect information and the confirmation control are displayed in the test flow box of the assertion step, with the confirmation control displayed to the right of the suspected defect information.

[0147] The confirmation control allows users to confirm that a suspected defect in a test case is indeed a real defect (bug). Upon receiving a confirmation control trigger, the relevant information of the defect indicated by the suspected defect information is stored in the defect database. After storage, a defect reporting prompt message is displayed to notify the user that the relevant information of the suspected defect information has been stored. In some embodiments, the defect reporting prompt message is displayed in the test flow box of the assertion step.

[0148] For example, the relevant information of the defect indicated by the suspected defect information may include, but is not limited to, test case information, image information related to the defect, network information related to the defect, etc.

[0149] In some embodiments, the defect reporting prompt information may include defect identification information, defect name, defect priority, and defect viewing control, which is used to view the details of the defect.

[0150] In some embodiments, in addition to displaying a confirmation control, a rejection control can also be displayed. The rejection control is used by the user to reject a suspected defect in the test case. If the rejection control is triggered, the suspected defect in the test case is determined to be a false defect, and the defect reporting operation is not performed.

[0151] In some embodiments, when a negative control trigger operation is obtained, the first reference information can be used as the second reference information to participate in the verification of the subsequent testing process.

[0152] In some embodiments, after the user triggers the confirmation control, a dialog message initiated by the user to indicate that the user has confirmed the creation of the defect can also be displayed in the test flow box of the assertion step.

[0153] For example, the test flowchart for the assertion step can be as follows: Figure 5 As shown. In Figure 5The test flowchart for the assertion step, as shown, displays the assertion step's identification information 501, information indicating the execution result of the assertion step 502, and content control controls 503 in the top area. The test flowchart also displays the instruction information 504 for the automated execution command bound to the assertion step, and the automatic execution result 505. Furthermore, the test flowchart also displays suspected defect information 506, a confirmation control 507, a rejection control 508, a user-initiated dialog indicating that the user has confirmed the creation of a defect 509, and a defect reporting prompt 510.

[0154] In one possible implementation, the method further includes: obtaining execution process recording information of the first test step; and obtaining auxiliary information based on the execution process recording information, wherein the auxiliary information is used to assist the subsequent execution process of the first test step.

[0155] Collecting the execution process records of the first test step and obtaining auxiliary information based on them can assist the subsequent execution process of the first test step, realize closed-loop learning, and improve the effectiveness of maintaining test cases.

[0156] Execution process recording information refers to information recorded during the execution of the first test step. For example, execution process recording information may include, but is not limited to, behavioral sequences generated when operating the page, DOM (Document Object Model) fragments, network data, click coordinates, image information, and descriptive information of the test steps. In some embodiments, execution process recording information may also be referred to as fingerprint data, process fingerprint, operation fingerprint data, operation fingerprint, etc.

[0157] Assistance information is information that can provide assistance to the subsequent execution process of the first test step. Providing assistance to the subsequent execution process of the first test step means that it can be used directly or indirectly in the subsequent execution process of the first test step.

[0158] In an exemplary embodiment, the auxiliary information includes at least one of inference description information, inference automated execution instructions, or inference code; wherein, the inference description information is information used to describe the first test step inferred from the execution process record information; the inference automated execution instructions are instructions used to automatically execute the first test step inferred from the execution process record information; and the inference code is the code corresponding to the first test step in the automated execution code used to automatically execute the test cases, which is based on the execution process record information.

[0159] The auxiliary information includes at least one of inference description information, inference automation execution instructions, or inference code. The inference description information, inference automation execution instructions, and inference code can all provide strong support for the subsequent execution process of the first test step, thereby ensuring the reliability of the auxiliary information.

[0160] For example, the inference description information is used to reverse-optimize the description information of the first test step, so that the optimized description information of the first test step is used in subsequent executions of the first test step.

[0161] For example, when an automated execution instruction is bound to the first test step, the inference automated execution instruction is used to reverse-optimize the automated execution instruction bound to the first test step, so that the optimized automated execution instruction is used in the subsequent execution of the first test step; when no automated execution instruction is bound to the first test step, the inference automated execution instruction is used to assist in the creation of an automated execution instruction for the first test step, so that the newly created automated execution instruction is used in the subsequent execution of the first test step.

[0162] For example, when the test cases of the first test step are bound to automated execution code, the inference code is used to reverse-optimize the code in the automated execution code used to execute the first test step, so that in the subsequent execution of the first test step, the test cases of the first test step are automatically executed by using the optimized automated execution code to execute the first test step; when the test cases are not bound to automated execution code, the inference code is used to assist in creating the automated execution code of the test cases, so that in the subsequent execution of the first test step, the test cases of the first test step are executed by using the created automated execution code to execute the first test step.

[0163] In some embodiments, inference description information, inference automation execution instructions, and inference code can all be obtained by calling the inference model. The inference model called for different content can be the same or different.

[0164] In an exemplary embodiment, the method for obtaining the execution process record information of the first test step includes: in response to the execution process of the first test step satisfying the information recording conditions, obtaining the execution process record information of the first test step.

[0165] Obtaining the execution process record information of the first test step only when the information recording conditions are met can avoid invalid information acquisition operations and reduce resource waste.

[0166] The execution process of the first test step can meet the information recording conditions, which can be set based on experience or adjusted flexibly according to needs. This application embodiment does not limit this.

[0167] For example, the execution process of the first test step satisfies the information recording conditions as follows: the first test step is not bound to an automated execution instruction, or the automated execution instruction bound to the first test step is not successfully executed.

[0168] If the execution result of the first test step is an automatic execution result obtained after the first test step is successfully executed automatically based on the inference instruction, the execution process recording information of the first test step only includes the information recorded during the automatic execution of the first test step based on the inference instruction. If the execution result of the first test step is a manual execution result, the execution process recording information of the first test step includes not only the information recorded during the automatic execution of the first test step based on the inference instruction, but also the information recorded during the manual execution of the first test step.

[0169] In one possible implementation, the method further includes: displaying a details control; displaying identification information of each test step in the test case in response to a triggering operation of the details control; and displaying detailed execution information of the first test step in response to a triggering operation of the identification information of the first test step.

[0170] Providing a details control for users to view the detailed execution status of the first test step improves the convenience for users to view the detailed execution status of the first test step, enhances the user's interactive experience, and thus increases the human-computer interaction rate.

[0171] This application does not limit the timing or location of the display of the details control. For example, the details control is displayed after the execution results of each test step in the test case have been obtained. For example, the details control is displayed by default on the display page. Before obtaining the execution results of each test step in the test case, the details control is in an untriggerable state; after obtaining the execution results of each test step in the test case, the details control becomes triggerable. Triggering the details control refers to triggering the details control when it is in a triggerable state.

[0172] The identification information of any test step is used to identify any test step. For example, the identification information of any test step may include the step number of any test step, or it may include the description information of any test step, etc.

[0173] The detailed execution status of the first test step is used to describe in detail the execution of the first test step. In some embodiments, the detailed execution status of the first test step includes at least one of the following: step description, automated execution instructions, code, tools, and execution process log information.

[0174] For example, the step description includes the original description information of the first test step and the inference description information of the first test step; the automated execution instruction includes the automated execution instruction originally bound to the first test step and the inference automated execution instruction of the first test step; the code includes the code used to automatically execute the first test step in the automated code bound to the test case and the inference code of the first test step; the tool includes the tools supported for use in the first test step; and the execution process recording information includes the execution process recording information of the first test step.

[0175] For example, assuming the first test step is the second test step in a test case, a display page showing detailed execution information for the first test step could be as follows: Figure 6 As shown in the image. The display page shows the identification information of the first test step 601, the step text of the first test step 602, the automated execution instructions of the first test step 603, the code of the first test step 604, the tools of the first test step 605, and the execution process record information of the first test step 606.

[0176] In the first test step's step description (602), the displayed test case step content is a new step description inferred by the inference model based on the execution process record information. This step description content will automatically optimize the current test case description, achieving autonomous updating of the test case step content. The first test step's automated execution instruction (603) displays the automated execution instruction bound to the current step. This instruction content is also autonomously updated by the inference model based on the execution process record information. The first test step's code (604) displays the content of the automated code in the code repository, also inferred and transformed by the inference model based on the execution process record information. The first test step's tool information (605) shows the instruction details supported by the current tool. The first test step's execution process record information (606) displays the execution process record information autonomously extracted during both autonomous execution by the visual model and manual takeover execution. This execution process record information will be stored in the execution database. In the next run, it will be used as verification data, given to the inference model to complete the inference and judgment of the test case results.

[0177] In one possible implementation, the method further includes: executing test cases in a managed manner via an automated pipeline in response to test cases meeting managed execution conditions.

[0178] When test cases meet the conditions for managed execution, they can be handed over to an automated pipeline for managed execution. This eliminates the need to execute each step of the test case sequentially, which helps improve the execution efficiency of test cases.

[0179] The fact that test cases meet the managed execution conditions indicates that the test cases have a high probability of being successfully executed through the automated pipeline. The conditions for test cases to meet the managed execution conditions can be set based on experience or flexibly adjusted according to needs; this application's embodiments do not impose such limitations.

[0180] In an exemplary embodiment, a test case satisfies the managed execution condition, including: each test step in the test case satisfies the managed execution sub-condition; wherein, a test step satisfies the managed execution sub-condition, including: the test step corresponds to an instruction for automatically executing the test step, and the test step has been successfully executed based on the instruction.

[0181] If a test step has corresponding instructions for automatic execution and has already been successfully executed based on those instructions, then the test step meets the managed execution sub-condition, indicating high reliability. When all test steps in a test case meet the managed execution sub-condition, it means the test case has a high probability of being automatically executed. Entrusting such test cases to an automated pipeline for managed execution improves the probability of successful managed execution.

[0182] For example, the instructions for automatically executing the test steps corresponding to the test steps may include any one of the following: automated execution instructions bound to the test steps, predicted inference execution instructions for automatically executing the test steps, and inference automated execution instructions for automatically executing the test steps inferred from the execution process record information of the test steps.

[0183] In this embodiment of the application, the description information of the first test step in the test case is displayed, and the first prompt information for indicating the execution result of the first test step is displayed in the associated area of ​​the description information. Based on this, the interaction at the test step level in the test case can be realized, so that the user can perceive more granular information, improve the user's interactive experience, and thus improve the human-computer interaction rate.

[0184] For example, in the information display method provided in this application embodiment, the execution process of the first test step is an execution mode based on "rule priority + AI backup". It prioritizes the selection of a deterministic execution path (Playwright MCP instruction) based on the status identifier. When typical automation anomalies occur (e.g., missing elements, operation execution timeout, DOM structure drift), it enters the self-healing link. The self-healing link takes the screenshot of the operation page and the description information of the first test step as input. It completes the semantic localization of the screenshot and intent reasoning through a visual model (e.g., VLM (Vision Language Model)) and an inference model (e.g., LLM (Large Language Model)) to generate an executable temporary operation sequence (i.e., inference instructions). If the execution based on the inference instructions fails, it switches to manual takeover (HITL) and continuously collects execution process recording information (location, DOM fragment, coordinates / size, screenshot hash, time sequence information, etc.) during the execution process. At the end of the process, multi-task inference output is used for asset accumulation: step text optimization, MCP instruction update, Playwright script generation, and finally, the execution database is written back in a versioned manner for subsequent reuse.

[0185] See Figure 7 The execution process of the first test step may include steps 701 to 710.

[0186] 701: Begin executing the first test step.

[0187] 702: Load the description information and status identifier of the first test step.

[0188] 703: Determine whether the status flag of the first test step is true.

[0189] If the status flag of the first test step is true, proceed to step 704; if the status flag of the first test step is false, proceed to step 707.

[0190] 704: The first test step is executed automatically based on the automated execution instruction bound to the first test step.

[0191] 705: Determine whether the automated execution instruction bound to the first test step has been successfully executed.

[0192] If the automated execution instruction bound to the first test step is successfully executed, proceed to step 720; if the automated execution instruction bound to the first test step is not successfully executed, proceed to step 706.

[0193] 706: The reason for the failure to execute was captured.

[0194] 707: Triggering the A1 self-healing process.

[0195] 708: Use the visual model to extract visual features from the screenshot of the operation page.

[0196] 709: Invoke the inference model to identify and locate the intent of the first test step based on visual features and the descriptive information of the first test step.

[0197] 710: Invoke the inference model to predict the inference instructions used to automatically execute the first test step.

[0198] 711: Automatically execute the first test step based on inference instructions.

[0199] 712: Determine whether the first test step was successfully executed based on the inference instructions.

[0200] If the first test step is successfully executed based on the inference instruction, proceed to step 713; if the first test step is not successfully executed based on the inference instruction, proceed to step 714.

[0201] 713: Obtain information recorded during the execution of the first test step based on the inference instructions.

[0202] 714: Entering manual takeover mode.

[0203] 715: Get the trigger operation of the completed control.

[0204] 716: Obtain information recorded during the manual execution of the first test step.

[0205] 717: Switch back to automatic mode.

[0206] 718: Perform multi-task inference updates based on information recorded during the execution of the first test step.

[0207] Obtain inference description information to optimize the steps; obtain inference automation execution instructions to update the bound automation execution instructions; obtain inference code to assist in generating test cases through automation execution code.

[0208] 719: Write back the information obtained from the multi-task inference update and the information recorded during the execution of the first test step to the execution database.

[0209] 720: The first test step has been completed.

[0210] Under the information display method provided in the embodiments of this application, the timing diagram unfolded from the perspective of test case interaction and data consistency can be as follows: Figure 8As shown, the user requests a test plan and historical fingerprints from the LBDA client. The LBDA client retrieves test case details and status indicators, carrying the test case identifier, and determines the execution path. Under the automatic path, the executor drives the browser according to the MCP instructions. If the execution fails or the automation conditions are not met, the step semantics + screenshot / DOM context are sent to the AI ​​model. The AI ​​model generates the operation behavior and drives the executor. If necessary, manual intervention is initiated, but the data collection of the same execution process fingerprint is still maintained. After execution, a multi-task inference update (text / MCP / code) is triggered and the fingerprint assets are written back. Then, the old and new fingerprints are verified, a "pass / defect" judgment is generated, and the defect platform is linked to create and associate the defect. Finally, the script maintenance prompts and automation identifier updates are issued through the IDE (Integrated Development Environment) plugin, and the stability indicators are fed back to the lifecycle management during the CI (Continuous Integration) cycle, realizing a closed loop of "execution-repair-accumulation-management-circuit breaker-relearning".

[0211] Figure 8 The detailed process of the timing diagram shown includes the following 10 steps: Step 1: The user sends my test plan instruction to retrieve the first test case data details from the test case database via API.

[0212] Step 2: Using the unique identifier of the use case, read the fingerprint data related to the use case from the use case fingerprint database via API.

[0213] Step 3: The user clicks the Execute button on the use case view in the LBDA client. The LBDA client determines the action based on the acquired fingerprint data and status indicator. When the status indicator is true, the bound Playwright MCP instruction will be executed automatically. When the status indicator is false, LBDA sends the use case description for this step to the inference model. The inference model, in conjunction with the visual model, identifies the action based on the step intent and completes the action. Fingerprint data is recorded during the action execution.

[0214] Step 4, Scenario 1: When this step completes automatically, multiple inference tasks will be triggered: ① Infer new step text based on fingerprint data. ② Infer new MCP instructions based on fingerprint data. ③ Infer new Playwright automation script content based on fingerprint data. After the inference is completed, this data will be written back to the fingerprint database, including the new fingerprint data.

[0215] Step 4, Scenario 2: If the LBDA client's automatic identification fails, a manual takeover process will begin. A human will then complete the subsequent operations according to the step description. Upon completion of this step, the human will also complete the three inference tasks from Scenario 1 and update the fingerprint data to the fingerprint database.

[0216] Step 5: Automatically switch from manual to automatic execution mode and continue to the next step.

[0217] Step 6: Upon entering the verification step, an automatic verification process will be triggered. Based on the newly acquired fingerprint data and historical fingerprint data, the inference model will perform inference and judgment, and provide a decision. If it is a defect, after the user confirms "Create Defect," a defect ticket will be automatically created, including use case information, image information, network information, etc., and the acquired defect information will be bound to this step. If it is not a defect, the user clicks "No, Pass," which will update the fingerprint data and proceed to the next step or the next use case.

[0218] Step 7: Based on the updated script data information in the fingerprint data, the IDE plugin reminds the user to complete the script maintenance and update on the IDE.

[0219] Step 8: When all steps of a test case are in an automated state (i.e., all steps meet the managed execution subconditions), and automated execution has been completed on the LBDA client, the IDE plugin will mark the test case as a fully automated test case in the test case code library.

[0220] Step 9: Automated Pipeline. Within the CI process, the execution of automated scripts is automatically triggered. If the test case consistently passes, its state remains unchanged. If an automated test case continuously fails in the pipeline and reaches a certain threshold, the IDE plugin will prompt the user to automatically remove the test case from the pipeline.

[0221] Step 10: Test cases that automatically change to fully automated status disappear from the test plan, and the result is reported by the automated pipeline. When a test case is in a non-fully automated state, it will be automatically deployed in the test plan. The subsequent process returns to Step 1.

[0222] Figure 8 The timing diagram shown can be based on Figure 9 The system architecture diagram shown is an implementation.

[0223] Figure 9 The module functions in the system architecture diagram and Figure 8 The correspondence between the 10 steps in the timing diagram shown in the figure can be seen in Table 1:

[0224] For example, Figure 9 The interaction process of the modules in the system architecture diagram shown can be as follows: Figure 10 As shown, the architecture is layered into "Access Layer—Core Cluster—Data Layer—External Ecosystem": The access side includes IDE plugins (script maintenance / status identification), LBDA console (visualization and manual takeover), and the controlled browser (Playwright Agent). Traffic enters the cluster via load balancer and API gateway, with the gateway handling routing, authentication, rate limiting, and auditing; the configuration center / registration center provides support for multi-environment and service discovery, and services use ServiceMesh for traffic governance and observability enhancement. The business domain uses the scheduling center as the orchestration hub, linking fingerprint services (collection / matching / versioning updates), verification services (baseline comparison / judgment), defect services (creation / association with external defect platforms), and the execution side (MCP instruction execution and script execution); the AI ​​domain provides visual understanding, intent reasoning, and script / instruction generation capabilities. The data layer primarily stores use test case libraries, fingerprint libraries, and defect libraries, supplemented by Redis (a type of database) for caching / queueing / idempotent control; the external ecosystem interfaces with Git (code repository), CI, TAPD (defect management platform), social application notifications, and detection and alarm systems to achieve closed-loop development and operation.

[0225] For example, the state transition diagram of the entire lifecycle of a test case can be as follows: Figure 11 As shown. Figure 11 The state transition diagram illustrates the evolution strategy of use case assets from the "exploration phase" to the "managed phase": In the creation phase, only metadata and step definitions are available; after the first execution, a semi-automated phase begins, allowing AI assistance and manual intervention to collect fingerprints and generate scripts in parallel. Once a use case meets the automation coverage / pass rate thresholds, it is upgraded to "fully automated (CI managed)," executed by the pipeline according to trigger strategies (scheduled / committed / released) and produces observable metrics (pass rate, stability, MTTR). When consecutive failures on the CI side exceed the threshold, a circuit breaker is triggered, and the status enters "maintenance," blocking automatic execution and prompting script maintenance to avoid noise alarms and resource waste. After maintenance is completed, it can revert to semi-automation for relearning or enter an offline state for archiving. If necessary, it supports re-enabling and retraining / verifying the baseline fingerprint.

[0226] For example, the data flow diagram from test case input to deposited assets can be as follows: Figure 12 As shown. Figure 12Emphasis is placed on data objects and write points: The input side consists of test plans / use case identifiers / step semantics (which can carry context such as environment, account, and preconditions). These first fall into the use case library to form traceable execution units. Subsequently, historical fingerprints (location, DOM fragments, coordinates / size, screenshot hash, version number) are read from the fingerprint library for status identification and execution acceleration. During the execution phase, regardless of whether MCP automation, AI self-healing, or manual intervention is used, a "process fingerprint" is generated and uniformly aggregated at the collection node, serving as training / validation samples for subsequent learning and regression. Multi-task inference transforms process fingerprints and result labels into reusable assets (step text, MCP instructions, Playwright scripts) and writes them back to the fingerprint library. The verification module outputs judgments based on the differences between the baseline and new fingerprints, and writes them to the defect library and associates them with external defect platforms when necessary. Finally, the fingerprint assets are used by the IDE for script maintenance prompts and automated identification, and by CI for managed execution and stability assessment, achieving continuous iteration and de-management.

[0227] This solution proposes a system based on visual model analysis, operated by AI, with human intervention in case of failure. It automatically collects fingerprint data during execution and leverages large-scale model inference capabilities to construct test cases and automated code that autonomously evolve. This addresses multiple issues, including the ambiguity of test case descriptions, the high cost of writing and maintaining automated code, and improved efficiency of manual test execution. This solution restructures existing automation models through systematic process improvements, reshaping behavior in the testing domain and enhancing efficiency across multiple dimensions without increasing human resources.

[0228] After the visual model understands the intent of the test case steps, it calls the humanoid operation tool, and the AI ​​completes the execution of the steps; if the visual model fails to execute, the LBDA client notifies a human to take over, and the human completes the execution of the steps according to the test case description.

[0229] The LBDA client uses fingerprint data from AI or manual execution processes to reverse-engineer test case steps, improving the understandability and readability of test cases. It also uses this fingerprint data to reverse-engineer automated scripts, enabling automated maintenance during the automated testing process and reducing the cost of dedicated manual maintenance. The LBDA client executes a human-like tool—a series of instructions; script execution, on the other hand, is based on code files. Automation instructions and automation script files are two different products, and AI facilitates the conversion between them.

[0230] The LBDA client also optimizes the instruction data corresponding to each step based on the operational instructions inferred during AI or manual execution. When this step is executed again in the next round, it automatically becomes an automated step, eliminating the need for secondary inference. This reduces the time spent understanding the model and computational costs, accelerating the execution process. In the automated test case verification stage, the LBDA client stores verification data. In the next round of execution, the previous experience data will automatically verify the data against the current data, improving verification accuracy and reducing verification time. Based on the verification data, when the user determines a defect, the LBDA client automatically creates a defect ticket, which includes: test case content, network information, and on-site screenshots.

[0231] This solution transforms automation scripts developed by automation test engineers into human-like tools, automating manually executed steps using the LBDA client. It automates some steps, enabling the transfer of high-dimensional value to the manual testing process. Leveraging the integrated model reasoning and visual model capabilities within the LBDA client, it attempts to understand and execute non-automated steps autonomously, increasing the automation rate of manual testing. During automated execution in the LBDA client, fingerprint data is automatically collected. Through the reasoning capabilities of large models, the step descriptions of test cases and corresponding automation instructions are automatically optimized. A conversion tool, referencing approved automation instructions, automatically optimizes the automation scripts, enabling autonomous maintenance. In case of automated execution failure, manual intervention takes over the execution of test cases. The LBDA client collects fingerprint data from the test engineer's execution process, automatically optimizing test case descriptions and corresponding automation instructions. It also autonomously maintains the automation scripts. This transforms valuable data generated during manual testing into high-dimensional value processes. The stored fingerprint data will automatically serve as verification data in the next execution round, supporting rapid verification of both manual and automated testing processes and improving testing accuracy. At the same time, fingerprint data can provide more comprehensive reference data for development when defects are discovered.

[0232] This solution constructs a next-generation automated testing system based on "rule-driven, AI-enhanced, human-machine collaboration, asset accumulation, and process governance." The fundamental changes and benefits it brings can be summarized in the following four aspects: I. Breakthrough in Core Competencies: From "Static Execution" to "Dynamic Evolution" Test case self-healing and self-evolution: AI collects "process fingerprints" during execution, optimizes steps, instructions, and scripts in real time through multi-task reasoning, and writes back in version. This forms an enhanced loop of "execution → learning → optimization," enabling test cases to become "more stable the more they run."

[0233] Manual testing assetization: The "process fingerprints" such as location information, operation sequence, and visual status during manual operation are automatically transformed into high-dimensional, reusable automated assets, breaking down the asset barriers between automated and manual testing.

[0234] II. Expanding Application Scenarios: From "Fully Automated Isolated Systems" to "Full Coverage of Human-Machine Collaboration" High-dimensional asset generalization application: The generated automated assets can be flexibly transformed into executable instructions, which can be used not only for fully automated scripts, but also embedded in manual test flows, replacing individual steps in real time and realizing "step-level" human-machine collaboration.

[0235] Solving the "non-automation" problem: For use cases that cannot be automated end-to-end due to environmental factors, CAPTCHAs, etc., stable and repetitive steps can be automated to achieve "partial automation" and quantifiable local efficiency improvements.

[0236] III. Strengthening Operational Efficiency and Quality Governance Upgraded measurement criteria: The standard for measuring automation benefits has been upgraded from the crude "number of use cases" to the precise "number of automatable steps," which truly reflects the efficiency improvement and avoids underestimating its value.

[0237] Improved maintenance efficiency: By leveraging accumulated fingerprint assets and AI reasoning capabilities, automated scripts can achieve intelligent self-healing, reducing maintenance costs and skill thresholds, so that maintenance work no longer relies on a few experts.

[0238] Quality closed-loop traceability: All operations (whether automatic or manual) are recorded using fingerprints, enabling full traceability. When defects are discovered, data-driven review can be conducted quickly to pinpoint the root cause.

[0239] Comprehensive defect analysis: By comparing the differences in fingerprints before and after execution, the results are accurately determined and automatically linked to the defect management system. This provides developers with defect reports containing comprehensive information such as operational context and visual changes, improving defect resolution efficiency.

[0240] More stable CI / CD processes: Set intelligent thresholds in the CI pipeline to automatically isolate unstable use cases to the "maintenance pool", reduce noise alarms and resource waste, and ensure the stability and reliability of the core pipeline.

[0241] IV. Organizational Value Accumulation: From "Project Assets" to "Organizational Intelligence" Organizational assetization and intelligent reuse: Through a centralized "fingerprint database," testing knowledge scattered across individuals and projects (such as optimal positioning methods, operation sequences, and assertion patterns) is consolidated into organizational-level intelligent assets that can be reused across teams and projects. Manual testing provides training data for automation, and automated assets, in turn, improve the efficiency of manual testing, forming a positive reinforcement cycle.

[0242] This system not only significantly improves the breadth, depth, and stability of automated testing, but more importantly, it reshapes the way test assets are produced, applied, and evolved, laying the foundation for building a truly adaptive and evolvable intelligent quality assurance system.

[0243] See Figure 13 This application provides an information display device, which includes: Display unit 1301 is used to display description information of the first test step, which is any test step in the test case; The acquisition unit 1302 is used to acquire the execution result of the first test step in response to the first test step meeting the step execution conditions; The display unit 1301 is also used to display first prompt information in the associated area of ​​the description information of the first test step, the first prompt information being used to indicate the execution result of the first test step.

[0244] In one possible implementation, the acquisition unit 1302 is used to automatically execute the first test step; in response to the first test step not being successfully executed automatically, a takeover control is displayed; in response to the triggering operation of the takeover control, mode switching information and a completion control are displayed, the mode switching information being used to indicate that the automatic execution mode has been switched to the manual execution mode; in response to the triggering operation of the completion control, the manual execution result of the first test step is acquired.

[0245] In one possible implementation, the acquisition unit 1302 is used to automatically execute the first test step based on the automated execution instruction bound to the first test step.

[0246] In one possible implementation, the acquisition unit 1302 is used to call the neural network model to predict inference instructions for automatically executing the first test step; and automatically execute the first test step based on the inference instructions.

[0247] In one possible implementation, the neural network model includes a visual model and an inference model; the acquisition unit 1302 is used to call the visual model to extract visual features of the operation page screenshot, which is obtained by performing image capture on the page on which the first test step depends; and to call the inference model to predict the inference instruction based on the visual features and the description information of the first test step.

[0248] In one possible implementation, the acquisition unit 1302 is used to call the inference model to analyze the step intent of the first test step based on visual features and the description information of the first test step, and predict the inference instruction according to the step intent.

[0249] In one possible implementation, the display unit 1301 is further configured to display a second prompt message in response to the first test step not being successfully executed automatically, the second prompt message being used to indicate that the first test step was not successfully executed automatically.

[0250] In one possible implementation, the first test step includes an assertion step in the test case. The display unit 1301 is further configured to display suspected defect information and a confirmation control if the execution result of the assertion step is an assertion failure. The suspected defect information is used to indicate a suspected defect in the test case. In response to the triggering operation of the confirmation control, a defect reporting prompt is displayed. The defect reporting prompt is used to indicate relevant information about the defect indicated by the stored suspected defect information.

[0251] In one possible implementation, the first test step is the first test step in the test case, and the first test step satisfies the step execution conditions, including: obtaining the trigger operation of the execution control; or, The first test step is not the first test step in the test case. The first test step meets the step execution conditions, including: the execution result of the second test step has been obtained, and the second test step is the test step in the test case that precedes the first test step.

[0252] In one possible implementation, the display unit 1301 is further configured to display a details control; in response to a trigger operation of the details control, display the identification information of each test step in the test case; and in response to a trigger operation of the identification information of the first test step, display the detailed execution status of the first test step.

[0253] In one possible implementation, the acquisition unit 1302 is used to automatically execute the first test step; in response to the first test step being successfully executed automatically, the automatic execution result of the first test step is acquired.

[0254] In one possible implementation, the acquisition unit 1302 is further configured to acquire execution process record information of the first test step; based on the execution process record information, acquire auxiliary information, which is used to provide assistance for the subsequent execution process of the first test step.

[0255] In one possible implementation, the auxiliary information includes at least one of inference description information, inference automation execution instructions, or inference code; wherein, the inference description information is information used to describe the first test step inferred based on the execution process record information; the inference automation execution instructions are instructions used to automatically execute the first test step inferred based on the execution process record information; and the inference code is the code corresponding to the first test step inferred based on the execution process record information in the automation execution code used to automatically execute the test cases.

[0256] In one possible implementation, the acquisition unit 1302 is used to optimize the description information of the first test step based on the reasoning description information when the auxiliary information includes reasoning description information, so as to obtain the optimized description information of the first test step, and the optimized description information of the first test step is used for subsequent execution of the first test step.

[0257] In one possible implementation, the acquisition unit 1302 is used to, when the auxiliary information includes inference automated execution instructions and the first test step is bound to an automated execution instruction, reverse-optimize the automated execution instructions bound to the first test step based on the inference automated execution instructions to obtain optimized automated execution instructions, which are then used to execute the first test step subsequently; or, when the auxiliary information includes inference automated execution instructions and the first test step is not bound to an automated execution instruction, assist in creating automated execution instructions for the first test step based on the inference automated execution instructions, which are then used to execute the first test step subsequently.

[0258] In one possible implementation, the acquisition unit 1302 is used to, when the auxiliary information includes inference code and the test cases of the first test step are bound to automated execution code, optimize the code used to execute the first test step in the automated execution code based on the inference code to obtain optimized automated execution code, which is then used for subsequent test cases executing the first test step; or, when the auxiliary information includes inference code and the test cases of the first test step are not bound to automated execution code, assist in creating automated execution code for the test cases based on the inference code, which is then used for subsequent test cases executing the first test step.

[0259] In one possible implementation, the acquisition unit 1302 is used to acquire the execution process record information of the first test step in response to the execution process of the first test step meeting the information recording conditions. The execution process of the first test step meeting the information recording conditions includes the first test step not being bound to an automated execution instruction, or the first test step not being successfully executed based on the automated execution instruction bound to the first test step.

[0260] In one possible implementation, the test cases are those that do not meet the conditions for automated execution.

[0261] In one possible implementation, the device further includes: The execution unit is used to execute test cases in a managed pipeline in response to test cases meeting the managed execution conditions.

[0262] In one possible implementation, the test case satisfies the managed execution condition, including: each test step in the test case satisfies the managed execution sub-condition; wherein, the test step satisfies the managed execution sub-condition, including: the test step corresponds to an instruction for automatically executing the test step, and the test step has been successfully executed based on the instruction.

[0263] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process and beneficial effects are detailed in the method embodiments, which will not be repeated here.

[0264] In an exemplary embodiment, a computer device is also provided, comprising a processor and a memory storing at least one computer program. The at least one computer program is loaded and executed by one or more processors to enable the computer device to implement any of the information display methods described above. In some embodiments, the computer device may include a terminal and a server. The structures of the terminal and the server will be described below.

[0265] Figure 14 This is a schematic diagram of a server structure provided in an embodiment of this application. The server can vary significantly due to differences in configuration or performance. It may include one or more Central Processing Units (CPUs) 1401 and one or more memories 1402. The one or more memories 1402 store at least one computer program, which is loaded and executed by the one or more processors 1401 to enable the server to implement the information display methods provided in the various method embodiments described above. Of course, the server may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The server may also include other components for implementing device functions, which will not be elaborated upon here.

[0266] Figure 15 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. In some embodiments, the terminal may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names.

[0267] Typically, a terminal includes a processor 1501 and a memory 1502.

[0268] Processor 1501 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1501 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1501 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1501 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen. In some embodiments, processor 1501 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0269] The memory 1502 may include one or more computer-readable storage media, which may be non-transitory. The memory 1502 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1502 are used to store at least one instruction, which is executed by the processor 1501 to cause the terminal to implement the information display method provided in the method embodiments of this application.

[0270] In some embodiments, the terminal may also optionally include: a peripheral device interface 1503 and at least one peripheral device. The processor 1501, memory 1502, and peripheral device interface 1503 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1503 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of: a radio frequency circuit 1504, a display screen 1505, a camera assembly 1506, an audio circuit 1507, and a power supply 1508.

[0271] Peripheral device interface 1503 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 1501 and memory 1502. In some embodiments, processor 1501, memory 1502 and peripheral device interface 1503 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1501, memory 1502 and peripheral device interface 1503 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0272] The radio frequency (RF) circuit 1504 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 1504 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 1504 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 1504 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 1504 can communicate with other terminals via at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: metropolitan area networks (MANs), various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks (WLANs), and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 1504 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0273] Display screen 1505 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 1505 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 1501 for processing. In this case, display screen 1505 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, display screen 1505 can be a single screen, disposed on the front panel of the terminal; in other embodiments, display screen 1505 can be at least two screens, disposed on different surfaces of the terminal or in a folded design; in other embodiments, display screen 1505 can be a flexible display screen, disposed on a curved or folded surface of the terminal. Furthermore, display screen 1505 can be configured as a non-rectangular, irregular shape, i.e., a non-rectangular screen. Display screen 1505 can be made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0274] The camera assembly 1506 is used to acquire images or videos. Optionally, the camera assembly 1506 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 1506 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, which can be used for light compensation at different color temperatures.

[0275] The audio circuit 1507 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting the sound waves into electrical signals that are input to the processor 1501 for processing, or input to the radio frequency circuit 1504 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each positioned at a different location on the terminal. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert electrical signals from the processor 1501 or the radio frequency circuit 1504 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 1507 may also include a headphone jack.

[0276] Power supply 1508 is used to power the various components in the terminal. Power supply 1508 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery. When power supply 1508 includes a rechargeable battery, the rechargeable battery can support wired or wireless charging. The rechargeable battery can also be used to support fast charging technology.

[0277] In some embodiments, the terminal further includes one or more sensors 1509. The one or more sensors 1509 include, but are not limited to: an acceleration sensor 1510, a gyroscope sensor 1511, a pressure sensor 1512, an optical sensor 1513, and a proximity sensor 1514.

[0278] Accelerometer 1510 can detect the magnitude of acceleration along the three coordinate axes of a coordinate system established by the terminal. For example, accelerometer 1510 can be used to detect the components of gravitational acceleration along the three coordinate axes. Processor 1501 can control display screen 1505 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by accelerometer 1510. Accelerometer 1510 can also be used for games or for acquiring user motion data.

[0279] The gyroscope sensor 1511 can detect the terminal's orientation and rotation angle. The gyroscope sensor 1511 can work in conjunction with the accelerometer sensor 1510 to collect the user's 3D movements on the terminal. Based on the data collected by the gyroscope sensor 1511, the processor 1501 can perform the following functions: motion sensing (e.g., changing the UI based on the user's tilt), image stabilization during shooting, game control, and inertial navigation.

[0280] The pressure sensor 1512 can be disposed on the side bezel of the terminal and / or the lower layer of the display screen 1505. When the pressure sensor 1512 is disposed on the side bezel of the terminal, it can detect the user's grip signal on the terminal, and the processor 1501 can perform left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 1512. When the pressure sensor 1512 is disposed on the lower layer of the display screen 1505, the processor 1501 can control the operable controls on the UI interface based on the user's pressure operation on the display screen 1505. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0281] Optical sensor 1513 is used to collect ambient light intensity. In one embodiment, processor 1501 can control the display brightness of display screen 1505 based on the ambient light intensity collected by optical sensor 1513. Specifically, when the ambient light intensity is high, the display brightness of display screen 1505 is increased; when the ambient light intensity is low, the display brightness of display screen 1505 is decreased. In another embodiment, processor 1501 can also dynamically adjust the shooting parameters of camera assembly 1506 based on the ambient light intensity collected by optical sensor 1513.

[0282] The proximity sensor 1514, also known as a distance sensor, is typically installed on the front panel of the terminal. The proximity sensor 1514 is used to detect the distance between the user and the front of the terminal. In one embodiment, when the proximity sensor 1514 detects that the distance between the user and the front of the terminal is gradually decreasing, the processor 1501 controls the display screen 1505 to switch from a screen-on state to a screen-off state; when the proximity sensor 1514 detects that the distance between the user and the front of the terminal is gradually increasing, the processor 1501 controls the display screen 1505 to switch from a screen-off state to a screen-on state.

[0283] Those skilled in the art will understand that Figure 15 The structure shown does not constitute a limitation on the terminal and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0284] In an exemplary embodiment, a computer-readable storage medium is also provided, which stores at least one computer program, which is loaded and executed by a processor of a computer device to enable the computer to implement any of the above-described information display methods.

[0285] In one possible implementation, the aforementioned computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a solid-state drive (SSD), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc. The random access memory can include resistive random access memory (ReRAM) and dynamic random access memory (DRAM).

[0286] In an exemplary embodiment, a computer program or computer program product is also provided, which includes computer instructions that are loaded and executed by a processor to enable the computer to implement any of the above-described information display methods.

[0287] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the description information and triggering operations of the first test step involved in this application were obtained with full authorization.

[0288] In other words, the data collection and processing in this application should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0289] It should be further noted that the terms "first," "second," etc., used in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The implementation methods described in the above exemplary embodiments do not represent all implementation methods consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0290] It should be understood that "multiple" as used in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0291] Furthermore, the step numbers described herein are merely illustrative of one possible execution order between steps. In some other embodiments, the steps may not be executed in the order of their numbers, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0292] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. Optionally, the program is stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0293] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. An information display method, characterized in that, The method includes: Display the description information of the first test step, which is any test step in the test case; In response to the first test step satisfying the step execution condition, the execution result of the first test step is obtained; A first prompt message is displayed in the associated area of ​​the description information of the first test step. The first prompt message is used to indicate the execution result of the first test step.

2. The method according to claim 1, characterized in that, Obtaining the execution result of the first test step includes: The first test step is executed automatically; In response to the failure of the first test step to be executed automatically, a takeover control is displayed; In response to the triggering operation of the takeover control, mode switching information and a completion control are displayed, wherein the mode switching information is used to indicate that the automatic execution mode has been switched to the manual execution mode; In response to the triggering operation of the completion control, the manual execution result of the first test step is obtained.

3. The method according to claim 2, characterized in that, The automatic execution of the first test step includes: The first test step is executed automatically based on the automated execution instructions bound to the first test step.

4. The method according to claim 2, characterized in that, The automatic execution of the first test step includes: The neural network model is invoked to predict the inference instructions used to automatically execute the first test step; The first test step is executed automatically based on the inference instructions.

5. The method according to claim 4, characterized in that, The neural network model includes a visual model and an inference model; the invocation of the neural network model to predict inference instructions for automatically executing the first test step includes: The visual features of the operation page screenshot are extracted by calling the visual model. The operation page screenshot is obtained by performing image capture on the page on which the first test step depends. The inference model is invoked to predict the inference instruction based on the visual features and the description information of the first test step.

6. The method according to claim 5, characterized in that, The step of invoking the inference model to predict the inference instruction based on the visual features and the description information of the first test step includes: The inference model is invoked to analyze the step intent of the first test step based on the visual features and the description information of the first test step, and the inference instruction is predicted based on the step intent.

7. The method according to claim 2, characterized in that, The method further includes: In response to the failure of the first test step to be executed automatically, a second prompt message is displayed, which indicates that the first test step has not been executed automatically.

8. The method according to claim 1, characterized in that, The first test step includes the assertion step in the test case, and the method further includes: If the assertion step fails, suspected defect information and a confirmation control are displayed. The suspected defect information is used to indicate a suspected defect in the test case. In response to the confirmation control's triggering operation, a defect reporting prompt message is displayed, which indicates relevant information about the defect indicated by the stored suspected defect information.

9. The method according to claim 1, characterized in that, The first test step is the first test step in the test case, and the first test step satisfies the step execution conditions, including: obtaining the trigger operation of the execution control; or, The first test step is not the first test step in the test case. The first test step satisfies the step execution conditions, including: the execution result of the second test step has been obtained, and the second test step is the test step in the test case that precedes the first test step.

10. The method according to claim 1, characterized in that, The method further includes: Display details control; In response to the triggering operation of the details control, the identification information of each test step in the test case is displayed; In response to the triggering operation of the identification information of the first test step, the detailed execution status of the first test step is displayed.

11. The method according to any one of claims 1 to 10, characterized in that, The method further includes: Obtain the execution process record information of the first test step; Based on the execution process record information, auxiliary information is obtained, which is used to provide assistance for the subsequent execution process of the first test step.

12. The method according to claim 11, characterized in that, The auxiliary information includes at least one of inference description information, inference automation execution instructions, or inference code; Wherein, the inference description information is information used to describe the first test step inferred based on the execution process record information; the inference automated execution instruction is an instruction used to automatically execute the first test step inferred based on the execution process record information; and the inference code is the code corresponding to the first test step in the automated execution code used to automatically execute the test case, inferred based on the execution process record information.

13. The method according to claim 11, characterized in that, After obtaining the auxiliary information, the method further includes: When the auxiliary information includes inference description information, the description information of the first test step is optimized in reverse based on the inference description information to obtain the optimized description information of the first test step. The optimized description information of the first test step is used for subsequent execution of the first test step.

14. The method according to claim 11, characterized in that, After obtaining the auxiliary information, the method further includes: When the auxiliary information includes inference automated execution instructions and the first test step is bound to an automated execution instruction, the automated execution instructions bound to the first test step are optimized in reverse based on the inference automated execution instructions to obtain optimized automated execution instructions, which are used to execute the first test step in a subsequent manner. Alternatively, if the auxiliary information includes inference automation execution instructions and the first test step is not bound to an automation execution instruction, an automation execution instruction for the first test step can be created based on the inference automation execution instructions, and the automation execution instruction is used to subsequently execute the first test step.

15. The method according to claim 11, characterized in that, After obtaining the auxiliary information, the method further includes: When the auxiliary information includes inference code and the test cases of the first test step are bound to automated execution code, the code used to execute the first test step in the automated execution code is optimized based on the inference code to obtain optimized automated execution code. The optimized automated execution code is used for subsequent test cases that execute the first test step. Alternatively, if the auxiliary information includes inference code and the test case of the first test step is not bound to automated execution code, automated execution code for the test case is created based on the inference code, and the created automated execution code is used to subsequently execute the test case of the first test step.

16. The method according to any one of claims 11-15, characterized in that, The step of obtaining the execution process record information of the first test step includes: In response to the execution process of the first test step satisfying the information recording conditions, the execution process recording information of the first test step is obtained. The execution process of the first test step satisfying the information recording conditions includes the first test step not being bound to an automated execution instruction, or the first test step not being successfully executed based on the automated execution instruction bound to the first test step.

17. The method according to any one of claims 1 to 10, characterized in that, The method further includes: In response to the test case meeting the managed execution conditions, the test case is executed in a managed manner through an automated pipeline. The test case meeting the managed execution conditions includes: each test step in the test case meets the managed execution sub-condition. The test step satisfies the managed execution sub-condition, including: the test step corresponds to an instruction for automatically executing the test step, and the test step has been successfully executed based on the instruction.

18. An information display device, characterized in that, The device includes: The display unit is used to display the description information of the first test step, which is any test step in the test case; The acquisition unit is used to acquire the execution result of the first test step in response to the first test step satisfying the step execution condition; The display unit is further configured to display a first prompt message in the associated area of ​​the description information of the first test step, the first prompt message being used to indicate the execution result of the first test step.

19. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one computer program, which is loaded and executed by the processor to enable the computer device to implement the information display method as described in any one of claims 1 to 17.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to enable the computer to implement the information display method as described in any one of claims 1 to 17.

21. A computer program product, characterized in that, The computer program product includes computer instructions that are loaded and executed by a processor to enable the computer to implement the information display method as described in any one of claims 1 to 17.

Images