Test bench-oriented automatic test method and device

Abstract

The application provides a test bench-oriented automatic testing method and device, and relates to the technical field of bench testing. In the test bench-oriented automatic testing method, in the process of automatic testing of the test bench, configuration information corresponding to a test execution instruction of the test bench is obtained in response to the test execution instruction received; the configuration information is parsed to obtain a target action sequence and execution context information; each target test action corresponding to the target action sequence is respectively instantiated based on a preset registry according to a group of target action identifiers and target action parameters, to obtain an instantiated action object corresponding to each target test action; each instantiated action object is sequentially called based on the execution context information, to execute a corresponding target test action, until the test of the test bench corresponding to the test execution instruction is completed. The method can effectively improve the test efficiency in the process of test bench-oriented automatic testing.

Description

Technical Field

[0001] This application relates to the field of bench testing technology, and in particular to an automatic testing method and apparatus for test benches. Background Technology

[0002] Existing automated testing systems generally employ a "dual-track" architecture when handling business scheduling and hardware control: a combination of built-in control flow mechanisms and external interaction flow mechanisms. The built-in control flow mechanism hard-codes process control logic such as conditional statements, waiting, and jumps within the core scheduling engine (e.g., using a multi-branch tree static structure or built-in jump primitives). The external interaction flow mechanism integrates specific hardware operations (such as sending messages, clicking the screen, and taking screenshots) as plugins, separating them from the control flow.

[0003] Existing automated testing methods for test benches suffer from bloated and highly coupled scheduling models, with process control operations and hardware interaction operations residing at different abstraction levels. As test scenarios become more complex, the core scheduling logic expands, requiring frequent modifications to the underlying framework code to add new scheduling strategies. Typically, automated testing methods for test benches exhibit poor adaptive scalability in complex, heterogeneous physical test bench scenarios, resulting in low testing efficiency. Therefore, providing an automated testing method for test benches that addresses the issue of low testing efficiency is of significant practical importance. Summary of the Invention

[0004] This application provides an automated testing method and apparatus for test benches, which can improve testing efficiency in the automated testing process for test benches.

[0005] To achieve the above objectives, the technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide an automated testing method for a test bench, the method comprising: Responding to the received test execution command from the test bench, obtain the configuration information corresponding to the test execution command; The configuration information is parsed to obtain the target action sequence and execution context information; the target action sequence includes a set of target action identifiers and target action parameters corresponding to the target action identifiers; each target action identifier is used to represent a target test action; the action type of the target test action includes flow control operation and hardware interaction operation; Based on the set of target action identifiers and the target action parameters, each target test action corresponding to the target action sequence is instantiated according to a preset registry, so as to obtain the instantiated action object corresponding to each target test action. Based on the execution context information, each instantiated action object is called sequentially to execute the corresponding target test action until the test bench corresponding to the test execution instruction is completed.

[0006] The automatic testing method for test benches provided in this application embodiment, during the automatic testing of the test bench, responds to the received test execution command of the test bench and obtains the configuration information corresponding to the test execution command; the configuration information is parsed to obtain a target action sequence and execution context information; the target action sequence includes a set of target action identifiers and target action parameters corresponding to the target action identifiers; each target action identifier is used to represent a target test action; the action type of the target test action includes flow control operation and hardware interaction operation; based on the set of target action identifiers and the target action parameters, each target test action corresponding to the target action sequence is instantiated according to a preset registry to obtain an instantiated action object corresponding to each target test action; based on the execution context information, each instantiated action object is called sequentially to execute the corresponding target test action until the test bench corresponding to the test execution command is completed. This method provides an automated testing mechanism that instantiates process control operations and hardware interaction operations based on the same action abstract base class. This makes process control operations no longer the built-in logic of the core scheduling engine, but a pluggable module with the same status as hardware interaction operations. This improves the adaptive expansion capability in the face of complex heterogeneous physical test bench scenarios, enhances the execution efficiency of test actions, and effectively improves the testing efficiency in the automated testing process for test benches.

[0007] In one optional embodiment, parsing the configuration information to obtain the target action sequence and execution context information includes: The configuration information is parsed to obtain global initialization information, step sequence information, and action declaration information; The execution context information is obtained based on the global initialization information, and the target action sequence is obtained based on the step sequence information and the action declaration information.

[0008] The method of this embodiment obtains global initialization information, step sequence information, and action declaration information by parsing the configuration information; obtains the execution context information based on the global initialization information; and obtains the target action sequence based on the step sequence information and the action declaration information. This method can construct unified execution context information during automated testing of test benches, enabling indirect communication of state data based on execution context information regardless of the action type. This improves the execution efficiency of test actions and effectively enhances the testing efficiency during automated testing of test benches.

[0009] In an optional embodiment, obtaining the target action sequence based on the step sequence information and the action declaration information includes: Based on the step sequence information, the step order of the set of target action identifiers is obtained; The target action sequence is obtained based on the step sequence and the action declaration information.

[0010] In this embodiment, the step sequence information is used to obtain the step order of the set of target action identifiers; the step order and the action declaration information are used to obtain the target action sequence, thereby accurately and efficiently generating the target action sequence. This allows process control operations and hardware interaction operations to be uniformly implemented through the target action sequence to create instantiated actions and call instantiated action objects, which can further improve the execution efficiency of test actions and effectively improve the test efficiency in the automatic testing process for test benches.

[0011] In an optional embodiment, the step of instantiating each target test action corresponding to the target action sequence based on the set of target action identifiers and the target action parameters, according to a preset registry, to obtain an instantiated action object corresponding to each target test action, includes: Based on the set of target action identifiers, the registry is retrieved to obtain the target object construction logic for each target test action corresponding to the target action sequence; According to the target object construction logic, the target action parameters of each target test action corresponding to the target action sequence are injected into the target subclass corresponding to each target test action to obtain the instantiated action object corresponding to each target test action.

[0012] The method of this embodiment retrieves the target object construction logic for each target test action corresponding to the target action sequence by retrieving the registry based on the set of target action identifiers; according to the target object construction logic, the target action parameters of each target test action corresponding to the target action sequence are injected into the target subclass corresponding to each target test action to obtain the instantiated action object corresponding to each target test action. This method provides an instantiated action object construction mechanism that can efficiently create unified instantiated action objects for target test actions whose action types include flow control operations and hardware interaction operations, improve the adaptive expansion capability in the face of complex heterogeneous physical test bench scenarios, improve the execution efficiency of test actions, and effectively improve the testing efficiency in the automatic testing process for test benches.

[0013] In an optional embodiment, the step of sequentially invoking each instantiated action object based on the execution context information to execute the corresponding target test action until the test bench corresponding to the test execution instruction is completed includes: Each instantiated action object is invoked sequentially through a single execution interface; For the currently instantiated action object being invoked, the current execution context information is passed as an input parameter to the currently instantiated action object; Run the currently instantiated action object to obtain standard execution result information and updated execution context information, and then execute the target test action corresponding to the currently instantiated action object until the test bench corresponding to the test execution instruction is completed.

[0014] The method of this embodiment sequentially calls each instantiated action object through a single execution interface; for the currently called instantiated action object, the current execution context information is passed as an input parameter to the current instantiated action object; the current instantiated action object is run to obtain standard execution result information and updated execution context information, so as to execute the target test action corresponding to the current instantiated action object until the test bench corresponding to the test execution instruction is completed. This method provides an instantiated action object driving mechanism, which can uniformly drive the instantiated action objects of target test actions, including flow control operations and hardware interaction operations, through a single execution interface, and uniformly transmit state data information through execution context information, thereby improving the adaptive expansion capability in the face of complex heterogeneous physical bench scenarios, improving the execution efficiency of test actions, and effectively improving the test efficiency in the automatic testing process for test benches.

[0015] Secondly, embodiments of this application also provide an automated testing device for a test bench, the device comprising: The configuration information acquisition unit is used to respond to the received test execution command from the test bench and acquire the configuration information corresponding to the test execution command; An information parsing and processing unit is used to parse the configuration information to obtain a target action sequence and execution context information; the target action sequence includes a set of target action identifiers and target action parameters corresponding to the target action identifiers; each target action identifier is used to characterize a target test action; the action type of the target test action includes flow control operation and hardware interaction operation; A unified object creation unit is used to instantiate each of the target test actions corresponding to the target action sequence based on a preset registry, according to the set of target action identifiers and the target action parameters, to obtain an instantiated action object corresponding to each of the target test actions. The test control execution unit is used to sequentially call each of the instantiated action objects based on the execution context information to execute the corresponding target test action until the test bench corresponding to the test execution instruction is completed.

[0016] In one optional embodiment, the information parsing processing unit is specifically used for: The configuration information is parsed to obtain global initialization information, step sequence information, and action declaration information; The execution context information is obtained based on the global initialization information, and the target action sequence is obtained based on the step sequence information and the action declaration information.

[0017] In one optional embodiment, the information parsing processing unit is specifically used for: Based on the step sequence information, the step order of the set of target action identifiers is obtained; The target action sequence is obtained based on the step sequence and the action declaration information.

[0018] In one optional embodiment, the unified object creation unit is specifically used for: Based on the set of target action identifiers, the registry is retrieved to obtain the target object construction logic for each target test action corresponding to the target action sequence; According to the target object construction logic, the target action parameters of each target test action corresponding to the target action sequence are injected into the target subclass corresponding to each target test action to obtain the instantiated action object corresponding to each target test action.

[0019] In one optional embodiment, the test control execution unit is specifically used for: Each instantiated action object is invoked sequentially through a single execution interface; For the currently instantiated action object being invoked, the current execution context information is passed as an input parameter to the currently instantiated action object; Run the currently instantiated action object to obtain standard execution result information and updated execution context information, and then execute the target test action corresponding to the currently instantiated action object until the test bench corresponding to the test execution instruction is completed.

[0020] Thirdly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the automatic testing method for a test bench as described in the first aspect.

[0021] Fourthly, embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and when the computer program is executed by the processor, the processor enables the processor to implement the automated testing method for a test bench as described in the first aspect.

[0022] Fifthly, according to an embodiment of this application, a computer program product includes computer instructions stored in a computer-readable storage medium; when a processor of a computer device reads the computer instructions from the computer-readable storage medium, the processor executes the computer instructions, causing the computer device to perform the steps of the automated testing method for a test bench according to the first aspect.

[0023] The technical effects of any of the implementation methods in aspects two through five can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here. Attached Figure Description

[0024] 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.

[0025] Figure 1 A flowchart illustrating an automated testing method for a test bench provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the process of parsing configuration information to obtain a target action sequence and execution context information for an automated testing method for a test bench provided in this application embodiment. Figure 3 This is a flowchart illustrating the process of obtaining a target action sequence in an automated testing method for a test bench, as provided in an embodiment of this application. Figure 4 This is a flowchart illustrating the process of obtaining the instantiated action object corresponding to each target test action in an automatic testing method for a test bench provided in this application embodiment. Figure 5 This is a flowchart illustrating the process of calling each instantiated action object to execute the corresponding target test action in an automated testing method for a test bench provided in this application embodiment. Figure 6 A schematic diagram of an automatic testing device for a test bench provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] It should be noted that the terms "comprising" and "having" and their variations used in this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or device.

[0028] The following are explanations of some of the words that appear in the text: (1) Flow control operation: Flow control operation is the operation of the control flow that directs the flow jump.

[0029] (2) Hardware interaction operation: Hardware interaction operation refers to the operation that directly drives the interaction flow of hardware devices.

[0030] (3) Script: A script is an executable file written in a specific descriptive language and saved in plain text format. It is executed by an interpreter or compiler and can be divided into daemon process scripts, monitoring process scripts, etc.

[0031] (4) Instantiation: In object-oriented programming, instantiation refers to the process of creating an object from a class. Instantiation is the process of making an abstract concept class into a concrete physical object of that class.

[0032] Existing automated testing systems generally employ a "dual-track" architecture when handling business scheduling and hardware control: a combination of built-in control flow mechanisms and external interaction flow mechanisms. The built-in control flow mechanism hard-codes process control logic such as conditional statements, waiting, and jumps within the core scheduling engine (e.g., using a multi-branch tree static structure or built-in jump primitives). The external interaction flow mechanism integrates specific hardware operations (such as sending messages, clicking the screen, and taking screenshots) as plugins, separating them from the control flow.

[0033] Existing automated testing methods for test benches suffer from bloated and highly coupled scheduling models, with process control operations and hardware interaction operations residing at different abstraction levels. As test scenarios become more complex, the core scheduling logic expands, requiring frequent modifications to the underlying framework code to add new scheduling strategies. Typically, automated testing methods for test benches exhibit poor adaptive scalability in complex, heterogeneous physical test bench scenarios, resulting in low testing efficiency. Therefore, providing an automated testing method for test benches that addresses the issue of low testing efficiency is of significant practical importance.

[0034] To address existing technical problems, this application provides an automated testing method and apparatus for test benches. During automated testing of the test bench, the method responds to received test execution commands from the test bench and obtains configuration information corresponding to the commands. The configuration information is parsed to obtain a target action sequence and execution context information. The target action sequence includes a set of target action identifiers and corresponding target action parameters. Each target action identifier represents a target test action. The action types of the target test actions include flow control operations and hardware interaction operations. Based on the set of target action identifiers and target action parameters, each target test action corresponding to the target action sequence is instantiated according to a preset registry, resulting in an instantiated action object for each target test action. Based on the execution context information, each instantiated action object is sequentially invoked to execute the corresponding target test action until the test bench corresponding to the test execution command is completed. This method provides an automated testing mechanism that instantiates process control operations and hardware interaction operations based on the same action abstract base class. This makes process control operations no longer the built-in logic of the core scheduling engine, but a pluggable module with the same status as hardware interaction operations. This improves the adaptive expansion capability in the face of complex heterogeneous physical test bench scenarios, enhances the execution efficiency of test actions, and effectively improves the testing efficiency in the automated testing process for test benches.

[0035] To make the inventive objectives, technical solutions, and advantages of the embodiments of this application clearer, the present application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] The technical solutions provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0037] The automated testing method for test benches provided in this application can be applied to servers or terminal devices. The following embodiments of this application illustrate the application of the automated testing method for test benches to terminal devices.

[0038] This application provides an automated testing method for test benches, such as... Figure 1 As shown, it includes the following steps: Step S101: Respond to the received test execution command from the test bench and obtain the configuration information corresponding to the test execution command.

[0039] In practice, the terminal device responds to the test execution command received from the test bench and obtains the configuration information corresponding to the test execution command.

[0040] Step S102: Parse the configuration information to obtain the target action sequence and execution context information.

[0041] The target action sequence includes a set of target action identifiers and target action parameters corresponding to the target action identifiers; each target action identifier is used to represent a target test action; the action types of the target test actions include flow control operations and hardware interaction operations.

[0042] In practice, the terminal device parses the configuration information to obtain the target action sequence and execution context information. The target action sequence includes a set of target action identifiers and target action parameters corresponding to the target action identifiers. Each target action identifier is used to represent a target test action. The action types of the target test actions include flow control operations and hardware interaction operations.

[0043] In some embodiments of this application, the target action sequence may be an action list, and the execution context information may be a unified execution context. The action list is an ordered declaration of a set of action type identifiers and their parameters in the configuration text; the unified execution context is a runtime container that carries state data.

[0044] In some embodiments of this application, after the action list is instantiated into action objects one by one by the core scheduling engine during runtime, it participates in the scheduling loop with a unified execution context as the only input parameter and a unique state read / write object.

[0045] In some optional embodiments, the process of parsing the configuration information to obtain the target action sequence and execution context information in step S102 above, such as... Figure 2 As shown, this can be achieved through the following steps: Step S201: Parse the configuration information to obtain global initialization information, step sequence information, and action declaration information.

[0046] In practice, the terminal device parses the configuration information to obtain global initialization information, step sequence information, and action declaration information.

[0047] In some embodiments of this application, the global initialization information, step sequence information, and action declaration information are respectively referred to as the global initialization segment, the step sequence segment, and the action declaration item.

[0048] In some embodiments of this application, the configuration information is structured test configuration text; the structured test configuration text is parsed to separate three types of information: global initialization segment, step sequence segment, and action declaration item.

[0049] The global initialization section includes hardware proxy references (such as terminal control device handles, communication bus handles, and image acquisition component handles), the initial test variable table, and the initial value of the anti-repetition protection counter. These three components together constitute the initialization data of the unified execution context.

[0050] The step sequence segment contains each test step in an ordered list. Each test step includes a precondition expression, a main action list, a postcondition expression, and a failure branch action list.

[0051] Action declaration items consist of an action type identifier and action parameters. The action type identifier is used for addressing in the action registry.

[0052] Step S202: Obtain execution context information based on global initialization information, and obtain target action sequence based on step sequence information and action declaration information.

[0053] In some embodiments of this application, the initial state of the runtime state container is determined based on the global initialization segment, and an initialized unified execution context is obtained.

[0054] In some embodiments of this application, the action set of the configurator declaration structure is determined based on the step sequence segment and the action declaration item to obtain the action list.

[0055] The method described in the above embodiments obtains global initialization information, step sequence information, and action declaration information by parsing configuration information; it obtains execution context information based on the global initialization information, and obtains the target action sequence based on the step sequence information and action declaration information. This method can construct unified execution context information during automated testing of test benches, enabling indirect communication of state data based on execution context information without distinguishing between action types. This can improve the execution efficiency of test actions and effectively enhance the testing efficiency during automated testing of test benches.

[0056] In some optional embodiments, the process of obtaining the target action sequence based on the step sequence information and action declaration information in step S202 above, such as... Figure 3 As shown, this can be achieved through the following steps: Step S301: Based on the step sequence information, obtain the step order of a set of target action identifiers.

[0057] For example, the step sequence information can be a step sequence segment, which is an ordered list containing various test steps. Each test step includes a precondition expression, a main action list, a postcondition expression, and a failure branch action list. Based on the step sequence information, the step order of this set of target action identifiers is obtained.

[0058] Step S302: Obtain the target action sequence based on the step order and action declaration information.

[0059] For example, action declaration information can be action declaration items. Each action declaration item consists of an action type identifier and action parameters, with the action type identifier used for addressing in the action registry. Based on the step sequence segment and the action declaration items, the target action sequence is obtained.

[0060] The method in the above embodiments obtains a set of target action identifiers based on the step sequence information; and obtains a target action sequence based on the step sequence and action declaration information. This allows for the accurate and efficient generation of target action sequences, enabling process control operations and hardware interaction operations to be uniformly implemented through the target action sequence to create instantiated actions and call instantiated action objects. This further improves the execution efficiency of test actions and effectively enhances the testing efficiency in the automated testing process for test benches.

[0061] Step S103: Based on a set of target action identifiers and target action parameters, instantiate each target test action corresponding to the target action sequence according to a preset registry, and obtain the instantiated action object corresponding to each target test action.

[0062] In practice, the registry is an action registry; all action subclasses are registered with the action registry during system initialization. After the core scheduling engine reads the action identifier from the configuration text, the action registry is responsible for dynamically instantiating the objects.

[0063] In some optional embodiments, the core scheduling engine is configured as a stateless loop pipeline. The core scheduling engine does not contain any pre-defined business control logic; for example, it has no embedded infinite loop retry or sleep / wait code. The core scheduling engine is only responsible for mechanically calling the unified execution interface of the action objects. By delegating process control to specific instantiated action objects, architectural equality and bidirectional pluggability between the control strategy and the hardware driver are achieved.

[0064] In some optional embodiments, the process in step S103 above, which involves instantiating each target test action corresponding to the target action sequence based on a set of target action identifiers and target action parameters using a preset registry, to obtain the instantiated action object corresponding to each target test action, is as follows: Figure 4 As shown, this can be achieved through the following steps: Step S401: Based on a set of target action identifiers, retrieve the registry to obtain the target object construction logic for each target test action corresponding to the target action sequence.

[0065] In some optional embodiments, the target action identifier can be an action type identifier; the terminal device looks up the action registry based on the action type identifier, and the factory method of the action registry calls the construction logic of the corresponding action subclass.

[0066] Step S402: According to the target object construction logic, inject the target action parameters of each target test action corresponding to the target action sequence into the target subclass corresponding to each target test action to obtain the instantiated action object corresponding to each target test action.

[0067] In some optional embodiments, the target object construction logic is the construction logic of the action subclass corresponding to the action type identifier; according to the construction logic of the action subclass corresponding to the action type identifier, the target action parameters of each target test action corresponding to the target action sequence are injected into the target subclass corresponding to each target test action to obtain the instantiated action object corresponding to each target test action.

[0068] In practice, the instantiated action object obtained is a test action object instance that inherits from the unified action abstract base class; the instantiated action object has the parameters required for this execution bound internally, and the execution interface signature exposed to the outside is consistent with all other action subclasses.

[0069] In some embodiments of this application, the target subclass is a subclass instance of the action subclass corresponding to the target test action.

[0070] The method described in the above embodiments provides an instantiation action object construction mechanism that can efficiently create unified instantiation action objects for target test actions, including process control operations and hardware interaction operations. This improves the adaptive expansion capability in the face of complex heterogeneous physical test bench scenarios, enhances the execution efficiency of test actions, and effectively improves the testing efficiency in the automatic testing process for test benches.

[0071] Step S104: Based on the execution context information, each instantiated action object is called sequentially to execute the corresponding target test action until the test bench corresponding to the test execution instruction is completed.

[0072] In some embodiments of this application, an instantiated action object is called through a single execution interface, with the unified execution context passed as the only input parameter. The instantiated action object reads the hardware agent reference information, test variable table information, and anti-repeated counter information in the unified execution context within its execution logic, and decides to execute control flow logic (modify the context scheduling state or write redirection instructions) or interactive flow logic (issue instructions to the physical test bench via the hardware agent and write back derived data to the variable table) based on the type of the instantiated action object, and finally returns a standard execution result structure.

[0073] In some embodiments of this application, the unified execution context is updated when generating the standard execution result structure.

[0074] In the embodiments of this application, an abstract base class for actions is predefined; test actions of flow control operations and hardware interaction operations are all subclasses of this abstract base class for actions. The abstract base class for actions is configured with a unified execution interface, for example, it only accepts the execution context as input and returns a standard execution result structure.

[0075] In some embodiments of this application, the instantiated action object is run to obtain standard execution result information, including a standard execution result structure.

[0076] In some embodiments of this application, the standard execution result information obtained by running the instantiated action object is a standard execution result structure. The standard execution result structure contains information on the unified return type of the execution interface for all action subclasses (regardless of whether they are control flow or interaction flow classes).

[0077] In some embodiments of this application, the standard execution result structure includes, but is not limited to, the following information items: execution status code, derived data pointer, process redirection instruction, anti-duplicate protection impact value, and exception description.

[0078] The execution status code indicates whether the action was successfully executed (success / failure / not executed); the execution status code is used to determine whether an abnormal branch is triggered. Derived data pointers are references to the hardware acquisition results written back by interaction stream actions of type hardware interaction operation (such as screenshot file paths, message response data), which are then transferred to the execution context information by the core scheduling engine; The process redirection instruction is a redirection field containing the target step identifier. After the redirection field of the process redirection instruction is read by the core scheduling engine, it first checks whether the anti-duplicate counter in the execution context has exceeded the limit. If it has not exceeded the limit, the current execution pointer is rewritten accordingly. The anti-duplicate protection impact value is information that indicates whether the anti-duplicate counter should be incremented during this execution. The anti-duplicate counter in the unified execution context is updated by the core scheduling engine after reading the anti-duplicate protection impact value. The exception description includes diagnostic information when it fails, exception handling branches, and logging actions.

[0079] In some optional embodiments, the action subclass instance that acts as the processing subject of flow control is a flow redirection action, such as a `goto` action. The flow redirection action instance fills in the information used in the flow redirection instruction field, which is the target step identifier in its own action parameters; this target step identifier is explicitly given in the action declaration by the test configuration text, for example, in the form of `action: goto + target: "step_1"`. The flow redirection action instance itself does not make a decision on whether to jump; as long as its execution interface is called, it unconditionally writes the target step identifier into the redirection field of the standard execution result structure. The decision-making power to actually trigger a jump belongs to the upper-level condition evaluation pipeline and the core scheduling engine: the condition evaluation pipeline evaluates the precondition / postcondition expressions and determines whether to enter the list of failed branch actions containing `goto` actions or the main flow action list based on the evaluation result; the core scheduling engine only calls the instance when it encounters a `goto` action during the execution of this action list. Therefore, "under what conditions should the `goto` action be executed" is determined by the condition evaluation pipeline based on the following information: Information from the unified execution context includes real-time physical state values ​​read by the hardware agent (such as the current gear signal) and data written back from the previous action in the variable table. The evaluation result of the conditional expression: The condition evaluation pipeline evaluates the precondition or postconditional expression of the current step based on the above context information. When the output Boolean result is true, the main flow action list (excluding goto) is executed. When the output Boolean result is false, the failure branch action list (including goto, constituting a retry or abnormal jump) is executed.

[0080] Once the goto action instance is invoked, it only needs to complete the atomic operation of "writing the target step identifier into the redirection field", and finally the core scheduling engine reads and executes the pointer rewriting.

[0081] In some alternative embodiments, the "wait-retry" pattern is decoupled from the scheduler kernel's embedded code into a configurable sequence of actions by declaratively combining process redirection actions and delay waiting actions; the core scheduling engine thread redirects to the current step to re-evaluate the preconditions after the delay waiting action returns, and the retry loop can be implemented without modifying the scheduler code.

[0082] In practice, the "target step" in the process redirection action does not always point to the current step itself, but rather to any test step identifier explicitly declared in the action parameters. The target step can be the current step (constituting a self-loop retry), a step that has been executed before the current step (constituting a backtracking retry), or a step after the current step (constituting a skip forward redirection).

[0083] In some optional embodiments, the execution process of the process redirection action includes: Step A01, Precondition Evaluation; Precondition evaluation includes: when the core scheduling engine enters the current test step, it first calls the condition evaluation pipeline to evaluate the precondition expression of the current step (such as "the current gear signal is equal to the parking gear"); the condition evaluation pipeline reads the real-time gear signal value obtained by the hardware agent from the unified execution context and outputs the Boolean precondition result.

[0084] Step A02, Failure Branch Extraction; Failure branch extraction includes: when the current result is false, the core scheduling engine extracts a list of failure branch actions from the configuration of the current step. The list contains two action declaration items in order: "delay waiting action" and "process redirection action".

[0085] Step A03, Delay action execution; Delay action execution includes: the core scheduling engine instantiates a delay waiting action object through the action registry and calls its execution interface; the action object reads the delay threshold in the action parameters and executes the delay.

[0086] The process redirection action in the above embodiments replaces the sleep waiting method of blocking threads in the traditional test framework, further improving the adaptive expansion capability in the face of complex heterogeneous physical test bench scenarios, improving the execution efficiency of test actions, and effectively improving the test efficiency in the automatic testing process for test benches.

[0087] In some embodiments of this application, to address the problem that pure configuration text (such as standard text structures) cannot handle complex computational logic (such as image algorithm judgment), a controlled bridging mechanism is provided. The controlled bridging mechanism includes: when a script action is executed, a "unified execution context" is injected into the script environment in the form of a restricted sandbox. After the script code uses the injected execution context information to obtain the peripheral device status and completes the calculation, the core scheduling engine automatically writes the script output variables back to the execution context information. This mechanism achieves a perfect closed loop of "imperative computation -> automatic variable write-back -> declarative condition evaluation". The method of this embodiment can overcome the shortcomings of the separation between declarative and imperative capabilities: pure declarative configuration (such as standard text structures) is highly readable but difficult to handle complex computational verification (such as image algorithm judgment); pure imperative code is flexible but lacks state consistency. This method enables custom scripts to safely intervene and seamlessly return to the declarative condition evaluation pipeline, improving the execution efficiency of test actions and effectively improving the testing efficiency in the automated testing process for test benches.

[0088] In some embodiments of this application, the script execution is triggered during the lifecycle of the action object as follows: after the core scheduling engine instantiates the script action object via the action registry, it calls its unified execution interface. Specifically, when the core scheduling engine encounters an action type identifier of a script bridging action in the scheduling loop, it creates a script action object instance via the registry. This object instance internally encapsulates a piece of script code specified by the test configuration text (the script code can be an interpreted language code segment such as Python / JavaScript, or an external script file path). Subsequently, the core scheduling engine calls the execution interface of this object instance. The execution interface loads the script code into the interpreter environment and injects the unified execution context into the script runtime environment as a restricted sandbox parameter, thereby triggering the actual execution of the script. After the script execution is completed and returns to the execution interface, a standard execution result structure is returned according to the unified interface contract.

[0089] In some embodiments of this application, when the core scheduling engine calls the script action execution interface, it injects the following information items from the unified execution context into the script runtime environment as restricted sandbox parameters: Hardware agent reference: Based on this, the script can call the hardware agent to read the physical state (such as reading the current gear signal and obtaining the screenshot image data pointer); Variable table: The script can read all variables written by the preceding action in the variable table, but the write operation must go through the controlled write interface provided by the core scheduling engine rather than directly modifying the internal data structure of the context; Information that is not allowed to be accessed: Scripts are not authorized to access the internal private data structures of the core scheduling engine (such as step pointers, scheduling loop states, and internal values ​​of anti-duplicate counters) to ensure that the hollowing-out mechanism of the engine is not compromised.

[0090] In practice, after the unified execution context is injected into the script execution environment, the information changes within the script execution environment include: The script environment now includes hardware-readable status: the script reads the real-time physical status through the hardware agent, and the status is entered into the script's local variable space; A new context variable cache has been added to the script environment: After the variable table contents are read by the script in read-only mode, they enter the script's local variable space; After the script is executed, it produces output variables: The script executes its internal calculation logic (such as calling external image algorithms or performing regular expression matching), writes the Boolean result, numerical result, or string result into the script's local variable space, and declares the variable names and values ​​that need to be written back to the unified execution context through the controlled write interface.

[0091] In some embodiments of this application, after the script execution is complete, the tail logic of the core scheduling engine execution interface completes the following information write-back: The core scheduling engine scans the script by writing the set of variable names and values ​​declared in the controlled writing interface; Write the variable name and variable value into the variable table of the unified execution context, overwriting fields with the same name or adding new fields; Template variable placeholders in subsequent conditional expressions (such as ${script output variable name}) are first queried and replaced with actual values ​​in the variable table before being processed by the condition evaluation pipeline; The replaced conditional expression is evaluated in the condition evaluation pipeline, and the evaluation result determines the next state machine route of the core scheduling engine (delay, redirection, or abnormal termination).

[0092] The method described in the above embodiments provides a controlled bridging mechanism. This controlled bridging mechanism includes injecting a "unified execution context" into the script environment in the form of a restricted sandbox during script action execution. After the script code uses the injected execution context information to obtain peripheral device status and completes calculations, the core scheduling engine automatically writes the script output variables back into the execution context information. This mechanism achieves a perfect closed loop of "imperative computation -> automatic variable write-back -> declarative condition evaluation," enabling custom scripts to safely intervene and seamlessly return to the declarative condition evaluation pipeline. This solves the problem that pure configuration text (such as standard text structures) cannot handle complex computational logic, improves the execution efficiency of test actions, and effectively enhances testing efficiency in the automated testing process for test benches.

[0093] In some optional embodiments, step S104 above, which involves sequentially calling each instantiated action object based on the execution context information to execute the corresponding target test action until the test bench corresponding to the test execution instruction is completed, is as follows: Figure 5 As shown, this can be achieved through the following steps: Step S501: Each instantiated action object is called sequentially through a single execution interface.

[0094] Step S502: For the currently instantiated action object being called, the current execution context information is passed as an input parameter to the currently instantiated action object.

[0095] Step S503: Run the current instantiated action object to obtain standard execution result information and updated execution context information, and execute the target test action corresponding to the current instantiated action object until the test bench corresponding to the test execution instruction is completed.

[0096] In some embodiments of this application, test results are obtained if and only if one of the following two conditions occurs: Normal termination: The current pointer in the WHILE loop increments linearly until it equals the length of the step list, meaning that all test steps have been executed in sequence and the postcondition assertion of the last step has passed. At this point, the core scheduling engine returns "test passed" as the test result. Abnormal Termination: If any of the following abnormal judgment conditions are triggered, an abnormal test result will be returned; the abnormal judgment conditions include: the execution status code returned by the action instance execution interface is failure, the anti-repeating protection counter exceeds the preset limit and triggers a safety circuit breaker exception, the postcondition assertion fails and the failure route target of the current step is the termination node.

[0097] In some embodiments of this application, the test results are given in the form of a unified return value from the core scheduling engine (such as "Test passed" / "Safety circuit breaker" / "Step N postcondition failed" etc.), which is the final output after the test configuration text has been executed.

[0098] The method described above provides an instantiation action object-driven mechanism that can uniformly drive the instantiation action objects of target test actions, including flow control operations and hardware interaction operations, through a single execution interface, and uniformly transmit state data information through execution context information. This improves the adaptive expansion capability in the face of complex heterogeneous physical test bench scenarios, enhances the execution efficiency of test actions, and effectively improves the test efficiency in the automatic testing process for test benches.

[0099] The automatic testing method for test benches provided in this application involves responding to received test execution commands from the test bench during the automatic testing process, obtaining configuration information corresponding to the test execution commands, parsing the configuration information to obtain target action sequences and execution context information, and specifying that the target action sequence includes a set of target action identifiers and target action parameters corresponding to the target action identifiers, each target action identifier representing a target test action, and the action types of the target test actions including flow control operations and hardware interaction operations. Based on the set of target action identifiers and target action parameters, each target test action corresponding to the target action sequence is instantiated according to a preset registry, resulting in an instantiated action object corresponding to each target test action. Based on the execution context information, each instantiated action object is sequentially called to execute the corresponding target test action until the test bench corresponding to the test execution command is completed. This method provides an automated testing mechanism that instantiates process control operations and hardware interaction operations based on the same action abstract base class. This makes process control operations no longer the built-in logic of the core scheduling engine, but a pluggable module with the same status as hardware interaction operations. This improves the adaptive expansion capability in the face of complex heterogeneous physical test bench scenarios, enhances the execution efficiency of test actions, and effectively improves the testing efficiency in the automated testing process for test benches.

[0100] Based on the same inventive concept, this application also provides an automatic testing device for a test bench. Since this device corresponds to the automatic testing method for a test bench provided in this application, and the principle by which this device solves the problem is similar to that of the method, the implementation of this device can refer to the implementation of the above method, and repeated details will not be elaborated further.

[0101] Figure 6 This illustration shows a structural schematic diagram of an automated testing device for a test bench according to an embodiment of this application. Figure 6 As shown, the automated testing device for the test bench includes a configuration information acquisition unit 601, an information parsing and processing unit 602, a unified object creation unit 603, and a test control execution unit 604.

[0102] The configuration information acquisition unit 601 is used to respond to the received test execution command from the test bench and acquire the configuration information corresponding to the test execution command. The information parsing and processing unit 602 is used to parse the configuration information to obtain the target action sequence and execution context information; the target action sequence includes a set of target action identifiers and target action parameters corresponding to the target action identifiers; each target action identifier is used to represent a target test action; the action types of the target test actions include flow control operations and hardware interaction operations; The unified object creation unit 603 is used to instantiate each target test action corresponding to the target action sequence based on a set of target action identifiers and target action parameters and a preset registry, so as to obtain the instantiated action object corresponding to each target test action. The test control execution unit 604 is used to sequentially call each instantiated action object based on the execution context information to execute the corresponding target test action until the test bench corresponding to the test execution instruction is completed.

[0103] In an optional embodiment, the information parsing processing unit 602 is specifically used for: Parse the configuration information to obtain global initialization information, step sequence information, and action declaration information; Based on the global initialization information, the execution context information is obtained, and based on the step sequence information and action declaration information, the target action sequence is obtained.

[0104] In an optional embodiment, the information parsing processing unit 602 is specifically used for: Based on the step sequence information, the step order of a set of target action identifiers is obtained; Based on the step sequence and action declaration information, the target action sequence is obtained.

[0105] In an optional embodiment, the unified object creation unit 603 is specifically used for: Based on a set of target action identifiers, the registry is retrieved to obtain the target object construction logic for each target test action corresponding to the target action sequence. Based on the target object construction logic, the target action parameters of each target test action corresponding to the target action sequence are injected into the target subclass corresponding to each target test action, so as to obtain the instantiated action object corresponding to each target test action.

[0106] In an optional embodiment, the test control execution unit 604 is specifically used for: Each instantiated action object is invoked sequentially through a single execution interface; For the currently instantiated action object being invoked, the current execution context information is passed as an input parameter to the currently instantiated action object; Run the current instantiated action object to obtain standard execution result information and updated execution context information, and then execute the target test action corresponding to the current instantiated action object until the test bench corresponding to the test execution instruction is completed.

[0107] Based on the same inventive concept as the above-described method embodiments, this application also provides an electronic device. This electronic device can be used for automated testing of test benches. In this application, the electronic device can be a server or a terminal device. In one embodiment, the electronic device can be a terminal device. In this embodiment, the structure of the electronic device can be as follows... Figure 7 As shown, it includes a memory 701, a communication module 703, and one or more processors 702.

[0108] The memory 701 is used to store computer programs executed by the processor 702. The memory 701 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0109] Memory 701 may be volatile memory, such as random-access memory (RAM); memory 701 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 701 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 701 may be a combination of the above-mentioned memories.

[0110] The processor 702 may include one or more central processing units (CPUs) or digital processing units, etc. The processor 702 is used to implement the aforementioned automated testing method for the test bench when it calls the computer program stored in the memory 701.

[0111] The communication module 703 is used to communicate with terminal devices and other servers.

[0112] This application embodiment does not limit the specific connection medium between the memory 701, communication module 703, and processor 702 described above. This application embodiment... Figure 7 The memory 701 and the processor 702 are connected via a bus 704, and the bus 704 is in Figure 7 The connections between other components are shown in bold lines only and are not intended to be limiting. The 704 bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 7The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0113] This application also provides a computer-readable storage medium storing computer-executable instructions required to execute the processor, including a program required to execute the processor.

[0114] In some possible implementations, various aspects of the automated test method for a test bench provided in this application can also be implemented as a program product, including program code that, when run on a terminal device, causes the terminal device to perform the steps of the automated test method for a test bench according to the various exemplary embodiments of this application described above. For example, an electronic device can perform such implementations. Figure 1 The example shown.

[0115] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0116] The automated test program product for a test bench according to embodiments of this application can employ a portable compact disc read-only memory (CD-ROM) and include program code, and can run on a computing device. However, the program product of this application is not limited thereto. In this document, the readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0117] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take many forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0118] The program code contained on the readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wired, optical fiber, RF, or any suitable combination thereof.

[0119] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including entity-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0120] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0121] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0122] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0123] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable file processing device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable file processing device, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0124] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable file processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0125] These computer program instructions can also be loaded onto a computer or other programmable document processing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0126] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

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

Claims

1. An automated testing method for test benches, characterized in that, The method includes: Responding to the received test execution command from the test bench, obtain the configuration information corresponding to the test execution command; The configuration information is parsed to obtain the target action sequence and execution context information; the target action sequence includes a set of target action identifiers and target action parameters corresponding to the target action identifiers; each target action identifier is used to represent a target test action; the action type of the target test action includes flow control operation and hardware interaction operation; Based on the set of target action identifiers and the target action parameters, each target test action corresponding to the target action sequence is instantiated according to a preset registry, so as to obtain the instantiated action object corresponding to each target test action. Based on the execution context information, each instantiated action object is called sequentially to execute the corresponding target test action until the test bench corresponding to the test execution instruction is completed.

2. The method according to claim 1, characterized in that, The step of parsing the configuration information to obtain the target action sequence and execution context information includes: The configuration information is parsed to obtain global initialization information, step sequence information, and action declaration information; The execution context information is obtained based on the global initialization information, and the target action sequence is obtained based on the step sequence information and the action declaration information.

3. The method according to claim 2, characterized in that, The step of obtaining the target action sequence based on the step sequence information and the action declaration information includes: Based on the step sequence information, the step order of the set of target action identifiers is obtained; The target action sequence is obtained based on the step sequence and the action declaration information.

4. The method according to claim 1, characterized in that, The step of instantiating each target test action corresponding to the target action sequence based on the set of target action identifiers and the target action parameters, according to a preset registry, to obtain an instantiated action object corresponding to each target test action, includes: Based on the set of target action identifiers, the registry is retrieved to obtain the target object construction logic for each target test action corresponding to the target action sequence; According to the target object construction logic, the target action parameters of each target test action corresponding to the target action sequence are injected into the target subclass corresponding to each target test action to obtain the instantiated action object corresponding to each target test action.

5. The method according to claim 1, characterized in that, The step of sequentially invoking each instantiated action object based on the execution context information to execute the corresponding target test action until the test bench corresponding to the test execution instruction is completed includes: Each instantiated action object is invoked sequentially through a single execution interface; For the currently instantiated action object being invoked, the current execution context information is passed as an input parameter to the currently instantiated action object; Run the currently instantiated action object to obtain standard execution result information and updated execution context information, and then execute the target test action corresponding to the currently instantiated action object until the test bench corresponding to the test execution instruction is completed.

6. An automatic testing device for a test bench, characterized in that, The device includes: The configuration information acquisition unit is used to respond to the received test execution command from the test bench and acquire the configuration information corresponding to the test execution command; An information parsing and processing unit is used to parse the configuration information to obtain a target action sequence and execution context information; the target action sequence includes a set of target action identifiers and target action parameters corresponding to the target action identifiers; each target action identifier is used to characterize a target test action; the action type of the target test action includes flow control operation and hardware interaction operation; A unified object creation unit is used to instantiate each of the target test actions corresponding to the target action sequence based on a preset registry, according to the set of target action identifiers and the target action parameters, to obtain an instantiated action object corresponding to each of the target test actions. The test control execution unit is used to sequentially call each of the instantiated action objects based on the execution context information to execute the corresponding target test action until the test bench corresponding to the test execution instruction is completed.

7. The apparatus according to claim 6, characterized in that, The information parsing and processing unit is specifically used for: The configuration information is parsed to obtain global initialization information, step sequence information, and action declaration information; The execution context information is obtained based on the global initialization information, and the target action sequence is obtained based on the step sequence information and the action declaration information.

8. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores program code that, when executed by the processor, causes the processor to perform the steps of the method according to any one of claims 1 to 5.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

10. A computer program product, characterized in that, It includes computer instructions stored in a computer-readable storage medium; when a processor of a computer device reads the computer instructions from the computer-readable storage medium, the processor executes the computer instructions, causing the computer device to perform the steps of the method according to any one of claims 1 to 5.

Images