Method, system, electronic device and readable medium for state transfer between pipeline modules

Abstract

The application relates to a pipeline inter-module state transmission method and system, electronic equipment and a readable medium. The method comprises the following steps: an upstream test module obtains a running parameter through non-user interface interaction with a system under test, and writes the running parameter into an in-process shared storage area; a downstream test module detects a data ready state of the in-process shared storage area before execution; if the data ready state is ready, the downstream test module directly reads the running parameter from the in-process shared storage area; if the data ready state is not ready, the downstream test module obtains the running parameter by identifying user interface display information of the system under test; and the downstream test module executes a test task by using the obtained running parameter. The downstream test module can quickly obtain parameters from the shared storage area, and automatically switches to a user interface identification mode when the shared storage area is unavailable, thereby improving test efficiency and independent execution capability of the module.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, and in particular to a method, system, electronic device, and readable medium for state transfer between pipeline modules. Background Technology

[0002] In the field of automated testing, when the system under test (SUT) contains multiple functional modules, the testing platform typically needs to chain the tests of each module in a certain order to form a test pipeline, simulating the complete path of a user's actual operation. In this pipelined testing process, the testing behavior of downstream modules often depends on the environmental state of the SUT after the upstream modules have executed, such as the current operating mode, function switch status, or device status.

[0003] In existing technologies, to address the aforementioned state dependency problem between modules, the following approaches are commonly used: One approach involves each test module acquiring the current environmental state by identifying the user interface of the system under test, for example, by searching for text labels in the interface to determine the current operating mode. In this approach, since each module needs to independently perform user interface detection operations, repeated detection steps are introduced when multiple modules execute sequentially. Another approach is to employ an explicit parameter passing mechanism within the test pipeline framework, such as through artifact file transfer, environment variable injection, or external cache sharing, to pass the state information acquired by the upstream module to the downstream module. In this approach, the upstream module needs to be aware of the specific transmission target (such as file path, environment variable name, or cache key), resulting in a certain degree of coupling between modules. Furthermore, in the above approaches, if the upstream module fails to execute or the state writing fails, the downstream module may not be able to obtain the required state information, and there is a lack of corresponding alternative acquisition methods, affecting the continuity of the test process.

[0004] Therefore, how to transfer state between modules in a test pipeline in order to reduce redundant operations while ensuring the availability of downstream modules in different execution scenarios is a technical problem in related technologies. Summary of the Invention

[0005] This application provides a method, system, electronic device, and readable medium for state transfer between pipeline modules, in order to at least solve the technical problems in the related art where, in the scenario of multi-module serial execution in an automated test pipeline, the operating environment state obtained by the upstream module is difficult to be automatically transferred to the downstream module, the downstream module needs to repeatedly execute user interface detection or rely on a highly coupled explicit parameter transfer mechanism, and the downstream module lacks a backup means of obtaining the state when the upstream module is not executed.

[0006] According to one aspect of the embodiments of this application, a method for state transfer between pipeline modules is provided, comprising: an upstream test module acquiring operating parameters through non-user interface interaction with the system under test, and writing the operating parameters into an intra-process shared memory area; a downstream test module detecting the data readiness status of the intra-process shared memory area before execution; if the data readiness status is ready, the downstream test module directly reading the operating parameters from the intra-process shared memory area; if the data readiness status is not ready, the downstream test module acquiring the operating parameters by recognizing the user interface display information of the system under test; and the downstream test module executing a test task using the acquired operating parameters.

[0007] Furthermore, the upstream testing module obtains operational parameters through non-user interface interaction with the system under test, including: the upstream testing module captures network request response messages sent by the system under test through an Application Programming Interface (API) proxy interceptor, and extracts the operational parameters from the response messages; or, the upstream testing module performs hook operations on function calls of the system under test, intercepts and parses the internal communication data of the system under test, and obtains the operational parameters.

[0008] Furthermore, the downstream testing module obtains operating parameters by recognizing the user interface display information of the system under test, including: extracting the interface control tree structure of the system under test, locating preset feature text labels in the control tree structure, and traversing the parent controls upwards based on the hierarchical relationship to match the operating parameters; if no match is found, traversing all controls within the entire interface range of the system under test to find text information that matches the operating parameters.

[0009] Furthermore, the operating parameters include at least a scene mode identifier and an enhancement status identifier; before the downstream testing module executes the test task using the obtained operating parameters, it further includes: mapping the scene mode identifier and the enhancement status identifier to a corresponding computing resource upper limit value according to a preset mode mapping table, and using the computing resource upper limit value as the execution benchmark for the current test task.

[0010] Furthermore, the generation method of the preset mode mapping table includes: during the pipeline startup phase, the pipeline orchestrator sends a probe command to the system under test to obtain a list of supported modes and corresponding resource quota information; based on the returned list of modes and resource quota information, the mode mapping table is dynamically constructed and cached.

[0011] Furthermore, the method also includes: the pipeline orchestrator initializes the intra-process shared memory area when the pipeline starts, and before the pipeline execution ends or a new round of testing begins, it calls the reset method of the intra-process shared memory area to clear historical running parameters and reset the data ready state to not ready.

[0012] Furthermore, the method also includes: if the downstream testing module fails to obtain the operating parameters after performing the step of obtaining the operating parameters by recognizing the user interface display information of the system under test, it is determined that the environment status is abnormal; at this time, the downstream testing module stops the execution of the current test task, generates a test failure report containing abnormal diagnostic information, and sends a status abnormality signal to the pipeline orchestrator to trigger an alarm.

[0013] Furthermore, the method also includes: after the pipeline orchestrator detects a switch in the operating mode of the system under test, it calls the write method of the intra-process shared memory area to update the operating parameters corresponding to the new mode to the intra-process shared memory area.

[0014] Furthermore, the intra-process shared memory area is implemented using a global singleton pattern, and read and write operations on the intra-process shared memory area are synchronized using mutexes or atomic variables.

[0015] According to another aspect of the embodiments of this application, a pipeline module inter-module state transfer system is provided, comprising: a shared state storage module configured as an intra-process shared storage area for storing operating parameters; an upstream testing module configured to obtain operating parameters through non-user interface interaction with the system under test and write the operating parameters into the shared state storage module; and a downstream testing module configured to detect the data readiness status of the shared state storage module before execution, and if the data readiness status is ready, directly read the operating parameters from the shared state storage module; if the data readiness status is not ready, obtain the operating parameters by recognizing the user interface display information of the system under test, and execute the test task using the obtained operating parameters.

[0016] According to another aspect of the embodiments of this application, an electronic device is provided, including: a processor, and a memory storing a program, the program including instructions that, when executed by the processor, cause the processor to perform the method described above.

[0017] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, characterized in that the computer program implements the above-described method when executed by a processor.

[0018] Compared with the prior art, this application has the following beneficial effects: By using a shared memory area within the process to achieve state transfer between modules, the downstream test module can directly read the running parameters from the shared memory area when the data is ready, which can reduce the time overhead of the downstream module in obtaining the running parameters.

[0019] By setting up an adaptive switching mechanism from reading from the shared storage area to user interface recognition, the downstream test module can obtain running parameters in different execution environments, which can balance the transmission efficiency in pipeline mode and the availability when the module runs independently.

[0020] The upstream testing module obtains operating parameters by interacting with the non-user interface of the system under test. It does not rely on user interface recognition operations, which can reduce the deviation in parameter acquisition caused by interface rendering delay or control changes. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art 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 embodiments can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart of a pipeline module state transfer method provided in an embodiment of this application; Figure 2 The data flow timing diagram provided for the upstream write-shared state-downstream consumption in the embodiments of this application; Figure 3 A flowchart illustrating the downstream module dual-source degradation reading provided in this application embodiment; Figure 4 A flowchart illustrating the multi-mode looping and shared state update of a pipeline orchestrator provided in this application embodiment; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that embodiments of this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the embodiments of this application. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0024] To facilitate understanding of the technical solution of this application, several terms involved in this application will be explained first.

[0025] Non-user interface interaction: refers to the method of directly exchanging data with the internal logic, data interface or communication protocol of the system under test without relying on the recognition or operation of the graphical user interface of the system under test. This includes, but is not limited to, application programming interface calls, command line interaction, inter-process communication, database queries, etc.

[0026] User interface display information: refers to the visual presentation information in the graphical user interface of the system under test that can be programmatically identified and extracted, including but not limited to the control tree structure, control attribute text, and interface display text.

[0027] Pipeline orchestrator: refers to an execution coordinator that executes multiple test modules in a predetermined order and manages the lifecycle of a shared storage area.

[0028] According to one aspect of the embodiments of this application, a method for state transfer between pipeline modules is provided. This method is applied to desktop application automated testing scenarios, and is particularly suitable for pipeline execution environments that require serial testing of multiple functional modules. Taking industrial software developed using the Electron framework as an example, the software includes a device management module and a task calculation module. The testing pipeline needs to execute device management tests first, and then execute task calculation tests. The behavior of the task calculation tests depends on the running state of the system under test after the device management tests are executed.

[0029] Figure 1 A flowchart of the pipeline module state transfer method provided in the embodiments of this application is shown below. Figure 1 As shown, the method includes the following steps: In step S102, the upstream testing module obtains operating parameters through non-user interface interaction with the system under test (SUT) and writes these parameters into the in-process shared storage area. After startup, the upstream testing module (e.g., a device management tester) establishes a connection with the SUT. Specifically, the upstream testing module calls the application programming interface (API) provided by the SUT to send a status query request. The SUT returns a response message containing the current operating status, including fields such as the scene mode name (e.g., standard mode), enhancement function on / off status (e.g., whether Turbo acceleration is activated), and device status code. The upstream testing module parses and extracts this information from the response message as operating parameters. After obtaining the operating parameters, the upstream testing module calls the write interface provided by the in-process shared storage area to write the operating parameters into the shared storage area. This shared storage area exists as a global singleton within the process, accessible to all testing modules within the same process.

[0030] In step S104, before execution, the downstream testing module checks the data readiness status of the shared memory area within the process. Before executing the test task, the downstream testing module (e.g., a task calculation tester) first checks the data readiness status of the shared memory area within the process. The data readiness status indicates whether the shared memory area contains valid runtime parameters that can be read. The downstream testing module performs this check by querying the status attributes provided by the shared memory area.

[0031] In step S106, if the data ready status is "ready," the downstream test module directly reads the running parameters from the shared storage area within the process. If the data ready status is detected as "ready," it indicates that the upstream test module has successfully written the running parameters to the shared storage area. The downstream test module directly reads the running parameters from the shared storage area; this read operation is completed within the process and does not involve any network communication, file read / write, or user interface operations. The read running parameters include information such as the scene mode name and enhancement status identifier.

[0032] In step S108, if the data ready state is not ready, the downstream test module obtains the operating parameters by recognizing the user interface display information of the system under test; if the data ready state is detected as not ready, it indicates that the upstream test module has not executed or has not yet completed the write operation. In this case, the downstream test module starts an alternative acquisition path and obtains the current operating parameters by recognizing the user interface display information of the system under test. Specifically, the downstream test module extracts the control tree structure of the current interface of the system under test, locates the text control used to display mode information in the control tree, and identifies the current operating parameters by matching preset feature text (e.g., standard, precise, and other mode names).

[0033] In step S110, the downstream testing module executes test tasks using the acquired runtime parameters. For example, in a task computation test, the downstream testing module determines the upper limit of computing resources to be used in the current test based on the acquired scene mode name and enhancement status identifier, and uses this as a basis to create computation tasks and perform computation verification and other operations.

[0034] Through the above steps, the downstream testing module can quickly obtain parameters from the shared memory area in pipeline mode, and can also autonomously obtain parameters through interface recognition when running independently, realizing adaptive switching between the two acquisition paths.

[0035] In this embodiment of the application, by setting an intra-process shared storage area as a state transfer channel between modules and configuring an adaptive degradation path from the shared storage area to the user interface recognition, the downstream test module can obtain running parameters under different execution environments, which can improve the efficiency of parameter transfer while maintaining the independent execution capability of the test module.

[0036] On the one hand, when the upstream module has already executed, the downstream module reads parameters through the in-process shared memory area. The read operation is completed at the memory level, resulting in low latency. On the other hand, when the upstream module has not executed, the downstream module automatically switches to the user interface recognition path, still able to acquire parameters and execute tests. This adaptive switching between the two paths allows the test module to benefit from the efficient parameter passing of the pipelined mode without losing its availability for independent operation, thus balancing test efficiency and execution flexibility to a certain extent.

[0037] In some embodiments, the upstream testing module obtains runtime parameters through non-user interface interaction with the system under test, including: the upstream testing module captures network request response messages sent by the system under test through an API proxy interceptor and extracts runtime parameters from the response messages; or, the upstream testing module performs hook operations on function calls of the system under test, intercepts and parses the internal communication data of the system under test, and obtains runtime parameters.

[0038] In one optional implementation, the upstream testing module embeds an API proxy interceptor into the network request chain of the system under test (SUT). When the SUT sends a network request or receives a response, the API proxy interceptor captures the network request response message sent by the SUT. This response message is typically structured data in JSON format, containing fields such as device status code, computing mode identifier, and enhancement feature on / off status. The upstream testing module parses and extracts these fields from the captured response message as runtime parameters. This method leverages the existing API communication mechanism of the SUT to obtain its true runtime status without intruding on the SUT's internal logic.

[0039] In another alternative implementation, the upstream testing module performs hooking operations on function calls of the system under test. Specifically, the upstream testing module locates key functions in the system under test responsible for state management or configuration reading, and inserts intercept code at the function's entry or exit point. When these functions are called internally by the system under test, the hooking operation intercepts the internal communication data transmitted during the function call, parses the intercepted data, and extracts the runtime parameters. This method is suitable for scenarios where the system under test does not have explicit API interfaces, or where a more granular approach to obtaining internal state is required.

[0040] Both of the above methods involve non-user interface interaction with the system under test, meaning they do not rely on the recognition or operation of the graphical user interface of the system under test, but instead obtain operating parameters by directly interacting with the data interface, communication protocol, or function call of the system under test.

[0041] In this embodiment of the application, the dependence of the process of obtaining running parameters on the rendering state of the user interface of the system under test can be reduced, thereby reducing the parameter acquisition delay and the possibility of misjudgment caused by interface loading delay or changes in control hierarchy.

[0042] Compared with the existing technology that relies on user interface (UI) detection, the embodiments of this application obtain parameters directly from the data level through API proxy or Hook, bypassing the UI rendering and control recognition process, thereby reducing the requirements for interface stability in the testing process.

[0043] In some embodiments, the downstream testing module obtains operating parameters by recognizing the user interface display information of the system under test, including: extracting the interface control tree structure of the system under test, locating preset feature text labels in the control tree structure, and traversing the parent controls upwards based on the hierarchical relationship to match the operating parameters; if no match is found, traversing all controls within the entire interface range of the system under test to find text information that matches the operating parameters.

[0044] In this embodiment, when the downstream testing module cannot obtain operating parameters from the shared state storage area, it activates an alternative acquisition path and obtains the current operating parameters by recognizing the user interface display information of the system under test. Specifically, this includes the following steps: The downstream testing module calls the user interface automation access interface provided by the system under test to obtain the control tree structure of the current interface. This control tree structure is organized in a hierarchical manner, with the root node representing the top-level window and child nodes representing the various control elements within the window. Each control element contains attribute information such as its type, position, visibility, and text content.

[0045] Furthermore, the downstream testing module performs a search within the control tree structure to find control nodes whose text content matches preset feature tags (e.g., scene configuration). These feature tags are fixed text identifiers in the interface used to identify the area where the runtime parameters are located.

[0046] Furthermore, after locating the control node containing the feature text label, the downstream testing module traverses the parent-child relationship chain of the control tree upwards, with a traversal depth of a preset limited number of levels (e.g., no more than four levels upwards). During each level of traversal, a depth-first search is performed on the control at that level and its child controls to find whether there is a control whose text content matches the mode name of the running parameter (e.g., standard, precise, overclocking). Once a match is found, the text content is identified as the current running parameter.

[0047] Furthermore, if the hierarchical traversal based on feature text tags fails to match any running parameters, the downstream test module initiates a global scan mode: traversing all controls across the entire interface of the system under test, checking the text content of each control one by one to see if it matches the mode name of the running parameters. When the first matching text is found, the current running parameter is determined.

[0048] Through the above four-level progressive mechanism (e.g., locating feature labels, traversing parent levels upwards, depth-first search, and global control traversal), the downstream testing module can adaptively identify and obtain the current operating parameters of the system under test under different interface layouts.

[0049] In this embodiment, when the shared state storage area is unavailable, the running parameters can be obtained autonomously by traversing the interface control tree, which can improve the adaptability of the downstream testing module in different execution environments.

[0050] Compared to solutions that rely solely on upstream propagation, this application's embodiments introduce a fallback acquisition mechanism based on a control tree, enabling downstream testing modules to acquire parameters even when running independently or when the upstream module is not executing, thereby enhancing the robustness of the testing process. In some embodiments, the running parameters include at least a scene mode identifier and an enhancement status identifier; before the downstream testing module executes the test task using the acquired running parameters, it further includes: mapping the scene mode identifier and enhancement status identifier to a corresponding upper limit value of computing resources according to a preset mode mapping table, and using the upper limit value of computing resources as the execution benchmark for the current test task.

[0051] In this embodiment, the operating parameters obtained by the downstream testing module include at least a scenario mode identifier and an enhancement status identifier. The scenario mode identifier is used to indicate the current operating mode of the system under test, such as standard mode, precision mode, or overclocking mode; the enhancement status identifier is used to indicate whether the system under test has enabled enhancement functions, such as whether the Turbo acceleration function is active.

[0052] Before executing test tasks using the acquired runtime parameters, the downstream testing module performs the following mapping transformation steps: The downstream testing module reads a pre-configured mode mapping table. This table records the maximum computing resources corresponding to different scenarios, mode identifiers, and enhancement status identifier combinations. For example, for a combination of standard mode and enhanced status not activated, the mapping table records the basic maximum computing resources; for a combination of standard mode and enhanced status activated, the mapping table records the enhanced computing resources maximum value, which is higher than the basic value; for precise mode or overclocking mode, the mapping table records their respective dedicated computing resources maximum values.

[0053] Furthermore, the downstream testing module uses the acquired scene mode identifier and enhancement status identifier as combined input parameters to perform a query and matching in the mode mapping table. The mapping table returns the corresponding upper limit value of computing resources based on different combinations of the two identifiers. For example, when the scene mode identifier is standard and the enhancement status identifier indicates an active state, the mapping table returns the increased upper limit value of computing resources; when the scene mode identifier is precise, the mapping table returns the upper limit value of computing resources corresponding to the precise mode.

[0054] Furthermore, the downstream testing module sets the mapped computing resource upper limit as the execution benchmark for the current test task. When performing subsequent test operations, the downstream testing module uses this computing resource upper limit as a reference, for example, when configuring the matrix size or allocating computing resources when creating a computing task.

[0055] In this way, the downstream testing module can convert the pattern identifiers and status identifiers from the upstream or from the interface into quantitative parameters that can be directly used by the test execution, thereby completing the connection from status identification to test execution.

[0056] In this embodiment of the application, by combining and mapping the scene mode identifier with the enhanced state identifier, discrete mode state information can be converted into a quantitative test execution benchmark, which enables the resource configuration of the test task to match the actual operating state of the system under test.

[0057] In some embodiments, the preset mode mapping table is generated in the following ways: during the pipeline startup phase, the pipeline orchestrator sends a probe command to the system under test to obtain a list of supported modes and corresponding resource quota information; and dynamically constructs and caches the mode mapping table based on the returned mode list and resource quota information.

[0058] In this embodiment, the preset pattern mapping table is not pre-configured statically, but is dynamically generated by the pipeline orchestrator during the pipeline startup phase. Specifically, it includes the following steps: During the pipeline startup phase, the pipeline orchestrator sends a probe command to the system under test (SUT). This probe command queries the SUT's currently supported mode configuration information. Upon receiving the probe command, the SUT returns response data based on its internal state and capabilities.

[0059] Furthermore, the pipeline orchestrator receives response data from the system under test (SUT), extracts a list of modes supported by the SUT, and resource quota information for each mode. The mode list contains one or more scene mode names currently available to the SUT, such as Standard Mode, Precision Mode, Overclocking Mode, etc.; the resource quota information indicates the upper limit of computing resources or other relevant quota parameters for each mode.

[0060] Furthermore, the pipeline orchestrator dynamically constructs a mode mapping table in memory based on the acquired mode list and resource quota information. This mapping table uses a combination of scene mode identifier and enhancement state identifier as the input key and the corresponding computational resource limit value as the output value. During the construction process, the pipeline orchestrator calculates the resource limit value corresponding to each combination state according to preset mapping rules (for example, the resource limit is increased by a certain percentage when the enhancement state is activated in the standard mode) and writes it into the mapping table.

[0061] Furthermore, the pipeline orchestrator caches the completed pattern mapping table in the in-process shared memory or other accessible storage location. During subsequent test execution, downstream test modules can directly query this cached mapping table to convert the obtained scene pattern identifiers and enhancement status identifiers into corresponding computing resource limits.

[0062] In this way, the content of the pattern mapping table is determined by the configuration information actually returned by the system under test at runtime, rather than being pre-fixed in the test code or configuration file.

[0063] In this embodiment of the application, the content of the pattern mapping table can be dynamically consistent with the pattern configuration supported by the system under test during actual operation, which can reduce the risk of mapping errors caused by the inconsistency between the static configuration in the test code and the actual state of the system under test.

[0064] Compared to the static configuration scheme, in this implementation scheme, when the mode configuration of the system under test changes (e.g., adding a mode, adjusting resource quotas, or disabling certain modes), the pipeline orchestrator obtains the latest configuration through probe commands and dynamically builds a mapping table. This makes the mapping data used by downstream test modules more likely to match the actual state of the system under test, thereby reducing test deviations caused by configuration asynchrony.

[0065] In some embodiments, the above method further includes: the pipeline orchestrator initializes the in-process shared memory area when the pipeline starts, and before the pipeline execution ends or a new round of testing begins, it calls the reset method of the in-process shared memory area to clear historical running parameters and reset the data ready state to not ready.

[0066] In this embodiment, the pipeline orchestrator performs lifecycle management on the intra-process shared memory area, specifically including an initialization phase and a reset phase.

[0067] When the pipeline starts, the pipeline orchestrator performs initialization operations on the shared memory area within the process. Initialization includes: setting the runtime parameter fields stored in the shared memory to null values, setting the scene mode identifier to null, setting the enhancement status identifier to its default value (e.g., off), and setting the data ready status to not ready. After initialization, the shared memory area is in a write-ready state, waiting for the upstream test module to write the runtime parameters. This initialization step is completed before the pipeline starts executing the first test module, ensuring that the shared memory area is in a consistent initial state at the start of each pipeline execution cycle.

[0068] Furthermore, during pipeline execution, the upstream test module writes runtime parameters to the shared memory area, and the downstream test module reads runtime parameters from the shared memory area. The data ready state automatically changes to ready after the write operation is completed, and reverts to not ready after the reset operation is completed.

[0069] Furthermore, the pipeline orchestrator triggers a reset operation in two situations: first, when the current pipeline execution has ended and all test modules have completed; second, before a new round of testing begins, i.e., when the same pipeline needs to be executed repeatedly or a new pipeline is about to start. The specific steps of the reset operation include: calling the reset method provided by the shared memory area, clearing the historical runtime parameters stored therein, and resetting the data ready state to not ready. After the reset is complete, the shared memory area is restored to the same state as after initialization to accommodate write operations in the next pipeline execution cycle.

[0070] Through the combination of initialization and reset described above, the state of the shared memory area will not interfere with each other between different pipeline execution cycles.

[0071] In this embodiment, by initializing the shared memory area at startup and resetting it at end by the pipeline orchestrator, the states between different execution cycles can be isolated from each other, which can reduce the possibility of historical running parameters interfering with subsequent test rounds.

[0072] In scenarios involving multiple rounds of testing or continuous execution across multiple pipelines, without a clear state reset mechanism, runtime parameters written in the previous test round may remain in the shared storage area, causing downstream modules in the next test round to retrieve outdated parameters. By using an orchestrator to centrally manage initialization and reset operations, each test round starts from an empty state, thereby improving the state independence and result reliability of test execution.

[0073] In some embodiments, the method further includes: if the downstream test module fails to obtain the operating parameters after performing the step of obtaining the operating parameters by recognizing the user interface display information of the system under test, it is determined that the environment is abnormal; at this time, the downstream test module stops the execution of the current test task, generates a test failure report containing abnormal diagnostic information, and sends a status abnormality signal to the pipeline orchestrator to trigger an alarm.

[0074] In this embodiment, when the downstream testing module fails to obtain the operating parameters after activating the alternative acquisition path, an exception handling process is triggered. This specifically includes the following steps: The downstream testing module attempts to read the runtime parameters from the shared storage area and then obtain them through an alternative acquisition path (i.e., by recognizing the information displayed on the user interface). If neither of these methods successfully obtains valid runtime parameters, the downstream testing module determines that the current environment is abnormal. Possible causes of this abnormality include: the upstream testing module not executing correctly, shared storage area write failure, and the user interface of the system under test failing to correctly display runtime parameter information.

[0075] Furthermore, upon determining that the environmental condition is abnormal, the downstream testing module immediately suspends the execution of the current test task and ceases execution of subsequent test steps that depend on this operating parameter. This operation can prevent invalid test results or misleading test feedback due to a lack of valid operating parameters.

[0076] Furthermore, the downstream testing module collects the context information at the time of the anomaly and generates a test failure report containing anomaly diagnostic information. This anomaly diagnostic information includes, but is not limited to: the timestamp of the anomaly, the identifier of the downstream testing module, a description of the reason for the failure to obtain the running parameters (e.g., the shared memory area is empty and no pattern identifier is recognized in the interface control), and a snapshot or summary of the current interface state of the system under test.

[0077] Furthermore, the downstream testing module sends a status anomaly signal to the pipeline orchestrator, which carries the aforementioned anomaly diagnostic information. Upon receiving the status anomaly signal, the pipeline orchestrator triggers corresponding alarm operations according to a preset alarm strategy, such as recording the anomaly event in the test execution log, sending a notification message to the testers, or marking the test task as an anomaly in the test report management platform.

[0078] Through the above-described exception handling process, the entire pipeline can detect parameter acquisition failures in downstream modules and respond to abnormal states in a unified manner.

[0079] In this embodiment of the application, when the running parameters fail to be obtained, the test execution is stopped and a report containing abnormal diagnostic information is generated, which enables the test process to detect abnormal states in a timely manner and reduces the time consumption caused by executing invalid test steps due to missing parameters.

[0080] In test schemes lacking fault tolerance mechanisms, when downstream modules cannot obtain runtime parameters, the test process may continue to attempt to execute test steps that depend on those parameters, leading to unnecessary execution time consumption and potentially generating errors that are difficult to locate. By setting explicit exception checkpoints, promptly terminating execution, and providing diagnostic information, the test process can exit earlier when exceptions occur. Simultaneously, it provides testers or pipeline orchestrators with contextual information that can be used for troubleshooting, thereby improving the fault tolerance and diagnosability of the test process.

[0081] In some embodiments, the above method further includes: after the pipeline orchestrator detects a change in the operating mode of the system under test, it calls the write method of the intra-process shared memory area to update the operating parameters corresponding to the new mode to the intra-process shared memory area.

[0082] In this embodiment, when the operating mode of the system under test changes, the pipeline orchestrator actively updates the operating parameters in the shared memory area to ensure that the parameters obtained by the downstream test modules are consistent with the new mode of the system under test after the switch. Specifically, this includes the following steps: During pipeline execution, the pipeline orchestrator continuously monitors the operating mode status of the system under test. Operating mode switching can be triggered in various ways, such as: the upstream test module sending a notification to the orchestrator after performing a mode switching operation; the orchestrator actively sending a query command to the system under test to obtain the current mode; or the orchestrator detecting the switch by listening for mode change events issued by the system under test.

[0083] When the orchestrator detects that the operating mode of the system under test has switched from the current mode to a new mode (for example, from standard mode to precision mode), it records the identification information of the new mode and the corresponding enhanced status identifier.

[0084] Furthermore, the pipeline orchestrator obtains the operating parameters corresponding to the new mode based on the new mode identifier after the switch. These operating parameters include the scene mode identifier (i.e., the new mode name) and the value of the enhanced status identifier under this mode. The orchestrator can obtain these parameters through the following methods: extracting them from the response data returned when the upstream test module performs a mode switching operation, obtaining them by sending a status query command to the system under test, or determining them according to a preset mode parameter mapping relationship.

[0085] Furthermore, the pipeline orchestrator calls the write method provided by the in-process shared memory area to write the runtime parameters corresponding to the new mode into the shared memory area. The write operation overwrites the original runtime parameters in the shared memory area and sets the data ready status to ready.

[0086] The write operation is initiated by the orchestrator and does not require waiting for the upstream test module to re-execute or the downstream test module to trigger it.

[0087] Furthermore, when downstream test modules need to obtain runtime parameters before or during execution, they check the data readiness status of the shared storage area. Since the orchestrator has proactively written the runtime parameters of the new mode after the mode switch, the downstream test modules can read parameters from the shared storage area that match the current state of the system under test without having to re-identify through the interface or send another request to the upstream.

[0088] Through the aforementioned proactive update mechanism, the operating parameters in the shared storage area can be updated synchronously as the tested system switches modes.

[0089] In this embodiment, the pipeline orchestrator actively updates the shared storage area after detecting a change in the operating mode of the system under test. This enables the operating parameters in the shared storage area to synchronize with the state changes of the system under test in a timely manner, allowing downstream test modules to obtain parameters that match the current mode in different mode scenarios.

[0090] In scenarios where tests need to be performed sequentially on multiple operating modes of the same system under test, if the parameters in the shared memory area are not updated with mode switching, downstream test modules may use the parameters from the previous mode to perform tests in the current mode, resulting in a mismatch between the test parameters and the actual mode. By actively monitoring mode switching and updating the shared memory area through an orchestrator, the parameters in the memory area can be kept in correspondence with the new mode after each mode change, thereby improving the timeliness and accuracy of parameter transfer in multi-mode serial testing scenarios.

[0091] In some embodiments, the intra-process shared memory area is implemented using a global singleton pattern, and read and write operations on the intra-process shared memory area are synchronized using mutexes or atomic variables.

[0092] In this embodiment, the intra-process shared memory area is implemented using a global singleton pattern, and read and write operations on this shared memory area are synchronized using mutexes or atomic variables. The specific implementation is as follows: The shared memory area within the process exists as a global singleton in the address space of the test execution process. This singleton object is created when the test process starts and remains a unique instance throughout the entire test execution. All test modules within the same process (including upstream and downstream test modules) obtain a reference to this singleton object through a unified access interface, thereby achieving access to the same shared memory area. The global singleton pattern guarantees the uniqueness of the shared memory area within the process, avoiding inconsistencies in state caused by multiple instances.

[0093] Since multiple test modules may be executed concurrently in an automated test pipeline (e.g., multiple downstream test modules start at the same time), concurrent read and write operations on the shared storage area require a synchronization control mechanism to prevent data races.

[0094] Specifically, both the write and read interfaces of the shared storage area are protected by synchronization mechanisms. Synchronization control can be achieved in the following ways: One is mutex lock control. The shared storage area maintains a mutex lock object. When the upstream test module calls the write interface, it first attempts to acquire the mutex lock. After successful acquisition, it performs the write operation and releases the mutex lock after completion. When the downstream test module calls the read interface, it also needs to acquire the same mutex lock first, and release it after completion. Under mutex lock protection, only one thread can perform write or read operations at a time; other threads must wait for the lock to be released before continuing. Another method is atomic variable control. For simple status fields such as data readiness status flags, atomic variables can be used for management. Atomic variables support lock-free atomic operations, such as atomic assignment, atomic comparison and swapping, etc. When the upstream test module completes the write operation, it updates the data readiness status flag through atomic operations; when the downstream test module checks the data readiness status, it obtains the status value through atomic read operations. Atomic variable operations are guaranteed to be indivisible by the processor at the underlying level, achieving thread safety without the need for mutex locks.

[0095] The above synchronization control mechanism is applied to the following operations in the shared storage area: field assignment operations when writing runtime parameters, operations to update data ready status flags, field reading operations when reading runtime parameters, and query operations to check data ready status.

[0096] Using the above method, in a multi-threaded testing environment, concurrent access to the shared storage area by multiple test modules can be processed in an orderly manner, without data corruption or inconsistent states.

[0097] In this embodiment of the application, by adopting the global singleton pattern to implement the shared storage area within the process, and using mutex locks or atomic variables to synchronize read and write operations, the shared storage area can maintain data consistency in a multi-threaded test environment, and can avoid state disorder or data race problems caused by concurrent access.

[0098] In automated testing pipelines, multiple test modules may execute concurrently in different threads. Without synchronization control mechanisms, when an upstream module is writing runtime parameters, a downstream module might simultaneously read those parameters, potentially reading incomplete or outdated intermediate state data. By using mutexes or atomic variables, write and read operations are processed in an ordered manner, ensuring that the downstream module reads either the complete old value before the write or the complete new value after the write, avoiding partially updated intermediate states. This improves the reliability of shared memory in concurrent scenarios.

[0099] Figure 2 The data flow timing diagram provided for the upstream write-shared state-downstream consumption embodiments of this application is as follows: Figure 2 As shown in the sequence diagram, this diagram illustrates the interaction order between the upstream testing module, the shared state storage module, the downstream testing module, and the pipeline orchestrator. The specific interaction flow is as follows: First, the pipeline orchestrator initiates a command to instantiate the upstream device management tester and start the test process. In this initial phase, the system initializes relevant variables, such as setting all status fields to their default values ​​(e.g., None).

[0100] The upstream device management tester interacts with the API of the system under test via HTTP requests to obtain current device status information. In response, the API of the system under test returns a data packet in JSON format. As shown in the figure, this data packet contains key operating parameters, such as status=1 (indicating that the device is online), computingMode=0 (indicating the current computing mode), and isTurbo=True (indicating that enhanced mode is enabled).

[0101] The upstream device management tester executes the corresponding device management test steps based on the acquired status information. After the test steps are completed, the upstream module needs to pass the key status information to the downstream. At this time, the upstream device management tester calls the interface of the shared state singleton to write the scene identifier (scene) and Turbo status (turbo=True) to the shared storage area. Subsequently, the upstream module calls set_device_status(1) to update the device status and sets the data ready flag is_available to True to indicate that the data is ready.

[0102] Simultaneously or subsequently, the pipeline orchestrator instantiates and starts testing the downstream task computation tester. Before executing a specific computation task, the downstream task computation tester first accesses the shared state singleton and checks the `is_available` flag. If `is_available` is detected as `True` (i.e., data is ready), the downstream module directly calls methods such as `get_scene()` from the shared state singleton to read previously written runtime parameters (e.g., standard mode, Turbo enabled, etc.). If `is_available` is detected as `False`, a backup UI recognition mechanism is triggered.

[0103] After successfully acquiring the runtime parameters, the downstream task computation tester uses them as the execution benchmark. Based on the read parameters (e.g., standard mode, Turbo=True), it determines the current computational resource limit (e.g., 1300s limit) and executes specific task computation tests accordingly.

[0104] Through the above process, efficient state transfer between upstream and downstream test modules based on in-process shared memory is achieved, avoiding time-consuming UI recognition or network requests by downstream modules, and significantly improving the execution efficiency of pipeline testing.

[0105] The interaction between the upstream module and the system under test is not limited to HTTP requests, but can also be other non-user interface interaction methods such as Remote Procedure Call (RPC) calls and Socket communication; the returned data format is not limited to JSON, but can also be XML, Protobuf, etc.

[0106] Figure 3 The flowchart for the downstream module dual-source degradation reading provided in the embodiments of this application is as follows: Figure 3 As shown, the downstream testing module attempts to read runtime parameters from the shared state storage module; if the read fails, it degrades to UI control tree traversal matching; if that still fails, it further degrades to full text scan matching. The specific steps of this process are as follows: First, an attempt is made to import and access the Shared State Singleton. At this point, the first check is performed: whether the singleton call was successful and whether the data-ready flag `electron_state.is_available` is True. If the result is Yes (i.e., data is ready), the normal reading process begins, calling the `get_scene()` interface to obtain complete runtime parameters including mode, bit rate, and Turbo status, and then the process ends. If the result is No (e.g., the singleton is not initialized or the flag is False), a fallback mechanism is triggered, and the UI detection process begins.

[0107] UI control tree traversal and matching (first-level degradation) initiates an automated scan of the tested system's interface. First, it searches for target controls with specific attribute configurations (e.g., specific text tags or IDs). If a target control is found, its attribute tree structure is parsed. During this process, a traversal depth limit is set (e.g., a maximum of 4 levels of parent nodes or 8 related objects) to avoid infinite loops or performance overhead. Then, it checks if the expected state information is matched. If a match is successful, the relevant information is extracted, and the system proceeds to the subsequent parameter assignment step. If a match fails, it indicates that the local control search is invalid, and the system expands the search scope to enter the full-text scan stage. If no target control is found, it also directly jumps to the full-text scan stage.

[0108] Full text scanning and regular expression matching (second-level fallback): When local control searches fail to obtain valid information, a global scan of the current interface is performed to obtain all visible text content. Then, a pre-defined regular expression file is used to perform pattern matching on the obtained text. If a match is successful, key status parameters are extracted from the matched text fragment. If a match fails, it means that the UI layer also cannot obtain a clear status indicator, and a fallback strategy is adopted, using the "Standard Value" as the current running parameter by default.

[0109] Regardless of the path used to obtain the basic scene information (control matching, regular expression matching, or default value), a final integrity check will be performed. It checks whether the currently obtained parameters include the Turbo state. If missing, an additional check for the Turbo state will be performed. Finally, the determined scene mode (scene_mode), device mode (device_mode), and Turbo enabled state (turbo_enabled) will be assigned to internal variables. After all parameters have been obtained and assigned, the process returns, signifying the completion of the degradation acquisition process, and downstream modules can then use these parameters to continue executing subsequent test tasks.

[0110] Figure 4 A flowchart illustrating the multi-mode looping and shared state update of the pipeline orchestrator provided in this application embodiment is shown below. Figure 4 As shown, the pipeline orchestrator processes multiple operating modes sequentially, actively updating the operating parameters in the shared state storage module during mode switching, and resetting the shared state storage module after all modes have been processed. The specific steps are as follows: The pipeline-based startup command first initializes key test components sequentially, including the device management tester (corresponding to the upstream module) and the task calculation tester (corresponding to the downstream module). Then, it obtains the current status information of the device under test and a list of all supported operating modes (e.g., including high-speed, precise, timeout, and other mode configurations) via API interfaces.

[0111] The system determines the sequence of test modes to be executed from the obtained mode list and begins processing each mode sequentially. At this point, a decision node is entered: Is a mode switch necessary? If a switch is needed (e.g., switching from the previous round's high-speed mode to the current precise mode), the test switch operation is executed. If the switch is successful, the `electron_state.set_scene(mode,turbo)` interface is called to update the new scene mode and Turbo state in the shared state singleton, enabling downstream modules to detect the environmental change. Subsequently, the downstream task computation test process is triggered via `task_tester.detect_device_mode()`. If the switch fails, the test result for the current mode is recorded as a failure, and this mode is marked as skipped, proceeding directly to the subsequent process summary. If a switch is not needed (e.g., the current mode is the same as the previous round, or this is the first run), the downstream task computation test process is triggered directly.

[0112] Regardless of whether a mode switch occurs, after executing the corresponding test logic, record the test result for the current mode. Then, check if there is another mode to be processed in the mode list; if so, the process loops back to the step of retrieving the next mode and continues to execute the next round of testing. If not, it means that all preset modes have been traversed, and the process enters the final stage.

[0113] After all modes have been tested, a final test report is generated, summarizing the execution status of each mode. To ensure the purity of the environment for the next pipeline, the `electron_state.reset()` method is called to clear all historical data (e.g., scene identifiers, device status, etc.) from the shared state singleton, achieving closed-loop lifecycle management. Finally, the pipeline officially ends.

[0114] According to another aspect of the embodiments of this application, a state transfer system between pipeline modules is provided. This system is used to execute the state transfer method described in the foregoing embodiments. The system includes a shared state storage module, an upstream testing module, and a downstream testing module. The configuration and cooperation method of each module are as follows: The shared state storage module is configured as an in-process shared memory area for storing runtime parameters. This shared memory area is implemented as a global singleton within the process, located in the address space of the test execution process. All test modules within the same process can access this memory area. The shared memory area maintains runtime parameter fields and data readiness status flags, and provides synchronization control mechanisms such as mutexes or atomic variables for read / write operations to ensure data consistency in a multi-threaded environment.

[0115] Specifically, the shared state storage module provides write, read, and status query interfaces. The write interface is called by the upstream test module to write the running parameters into the storage area, and automatically sets the data ready status to "ready" after the write is completed. The read interface is called by the downstream test module to read the running parameters from the storage area. The status query interface is called by the downstream test module to check the data ready status.

[0116] The upstream testing module is configured to acquire operational parameters through non-user interface interaction with the system under test (SUT) and write these parameters to a shared state storage module. During pipeline execution, the upstream testing module establishes a connection with the SUT after startup. The upstream testing module calls the application programming interface (API) provided by the SUT to send a status query request. The SUT returns a response message containing the current operational status, including the scene mode name, enhancement function on / off status, and device status code. The upstream testing module parses and extracts this information from the response message as operational parameters.

[0117] After obtaining the runtime parameters, the upstream testing module calls the write interface provided by the shared state storage module to write the runtime parameters into the shared storage area. Once the write operation is complete, the data ready state of the shared storage area changes to "ready," indicating that it is available for downstream modules to read.

[0118] The downstream testing module is configured to detect the data readiness status of the shared state storage module before execution. If the data readiness status is "ready", the module directly reads the running parameters from the shared state storage module. If the data readiness status is "not ready", the module obtains the running parameters by recognizing the user interface display information of the system under test, and uses the obtained running parameters to execute the test task.

[0119] Specifically, the downstream test module calls the status query interface of the shared state storage module before execution to obtain the data ready status.

[0120] If the data readiness status is "Ready," it indicates that the upstream test module has successfully written the runtime parameters to the shared storage area. In this case, the downstream test module calls the read interface of the shared state storage module to directly read the runtime parameters from the shared storage area. This read operation is completed within the process and does not involve network communication, file I / O, or user interface operations.

[0121] If the data readiness status is not ready, it indicates that the upstream test module has not executed or has not yet completed the write operation. In this case, the downstream test module starts an alternative acquisition path and obtains the current operating parameters by recognizing the user interface display information of the system under test. Specifically, the downstream test module extracts the control tree structure of the current interface of the system under test, locates the text control used to display mode information in the control tree, and identifies the current operating parameters by matching preset feature text (such as mode names such as "standard" and "precise").

[0122] After obtaining the runtime parameters, the downstream testing module uses these parameters to execute test tasks. For example, based on the obtained scene mode name and enhancement status identifier, the downstream testing module determines the upper limit of computing resources that should be used for the current test, and executes the corresponding test operations accordingly.

[0123] In this embodiment, by setting a shared state storage module as a state transfer intermediary between the upstream test module and the downstream test module, and configuring the downstream test module to adaptively select the reading path according to the data ready state, the downstream test module can obtain the running parameters with low latency when the data ready state is ready, and obtain the running parameters through the backup path when the data ready state is not ready. This can improve the efficiency of parameter transfer while ensuring the availability of the downstream test module in different execution environments.

[0124] In some embodiments, the system adopts a layered and modular design concept, mainly divided into the following areas: actuator layer, scheduling and orchestration layer, infrastructure layer, and state management layer. The modules interact through standardized interfaces, and the specific architecture is as follows: The executor layer is primarily responsible for executing specific test tasks. This layer includes an upstream device management tester and a downstream task calculation tester. The upstream device management tester integrates an Acquirer component to obtain runtime parameters; the downstream task calculation tester contains the specific test logic scripts. These two testers act as the execution terminals of the pipeline, responsible for direct interaction with the system under test.

[0125] The scheduling and orchestration layer is the control center of the system, labeled as the pipeline orchestrator. This module is responsible for the lifecycle management of the entire testing process, including initializing each tester, distributing test commands, and coordinating the execution order of upstream and downstream modules. It connects downwards to the executor layer and upwards to configuration and state management, ensuring that test tasks are performed in an orderly manner according to preset logic.

[0126] The infrastructure layer provides underlying support capabilities for upper-layer business logic. This layer contains several basic functional modules, such as API interceptors, Hook injection modules, and text scanning engines. These modules are called by the upper-layer testers. For example, when non-UI interaction is required to obtain data, the tester will call the API interceptor; when UI degradation is required, the text scanning engine will be called.

[0127] The core component of the state management layer includes a shared state singleton. This module is used to store and synchronize critical runtime parameters (e.g., scene mode, Turbo state, etc.). After completing the retrieval operation, the upstream tester writes the parsed parameters into the shared state singleton. Before execution, the downstream tester reads the required parameters from the shared state singleton. The state reset mechanism ensures that the shared storage area is correctly initialized or cleared before a new round of testing begins, preventing historical data from polluting the current test environment.

[0128] According to another aspect of the embodiments of this application, an electronic device is provided, including: a processor, and a memory storing a program, the program including instructions that, when executed by the processor, cause the processor to perform the method described above.

[0129] refer to Figure 5 The present invention describes a structural block diagram of an electronic device that can serve as a server or client in embodiments of this application, which is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the application described and / or claimed herein.

[0130] like Figure 5 As shown, the electronic device includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the electronic device. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0131] Multiple components in the electronic device are connected to I / O interface 505, including: input unit 506, output unit 507, storage unit 508, and communication unit 509. Input unit 506 can be any type of device capable of inputting information into the electronic device. Input unit 506 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of the electronic device. Output unit 507 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 508 may include, but is not limited to, disks and optical discs. Communication unit 509 allows the electronic device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, and wireless communication transceivers, such as Bluetooth devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0132] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, CPUs, graphics processing units (GPUs), various special-purpose artificial intelligence (AI) computing units, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processors, controllers, microcontrollers, etc. The computing unit 501 performs the various methods and processes described above. For example, in some embodiments, the method embodiments of this application can be implemented as computer programs tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on an electronic device via ROM 502 and / or communication unit 509. In some embodiments, the computing unit 501 can be configured to perform the methods described above by any other suitable means (e.g., by means of firmware).

[0133] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, characterized in that the computer program implements the above-described method when executed by a processor.

[0134] It should be noted that the computer-readable storage medium in this embodiment can be any tangible medium that contains or stores a computer program, which can be used by or in conjunction with an instruction execution system, apparatus, or device. Specifically, the computer-readable storage medium can include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media can include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, flash memory, optical fiber, portable optical disc read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0135] In this embodiment, the method steps implemented when the computer program is executed by the processor correspond to the steps in the aforementioned method embodiment. For details, please refer to the foregoing description, which will not be repeated here.

[0136] It should be noted that the term "comprising" and its variations used in the embodiments of this application are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; and the term "some embodiments" means "at least some embodiments". The modifications of "one" and "multiple" mentioned in the embodiments of this application are illustrative and not restrictive. Those skilled in the art should understand that, unless explicitly indicated otherwise in the context, they should be understood as "one or more".

[0137] The steps described in the method embodiments provided in this application can be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of protection of this application is not limited in this respect.

[0138] The term "embodiment" in this specification refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily imply the same embodiment, nor does it imply independence from or alternative to other embodiments. The various embodiments in this specification are described in a related manner, with reference to each other for similar or identical parts. In particular, for apparatus, device, and system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, and relevant details are referred to in the description of the method embodiments.

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

Claims

1. A method for state transfer between pipeline modules, characterized in that, include: The upstream testing module obtains operating parameters by interacting with the non-user interface of the system under test, and writes the operating parameters into the in-process shared memory area; Before execution, the downstream testing module checks the data readiness status of the shared storage area within the process; If the data ready status is "ready", the downstream test module directly reads the running parameters from the shared storage area within the process. If the data ready status is not ready, the downstream testing module obtains the operating parameters by recognizing the user interface display information of the system under test; The downstream testing module uses the acquired operating parameters to execute testing tasks.

2. The method according to claim 1, characterized in that, The upstream testing module obtains runtime parameters through non-user interface interaction with the system under test, including: The upstream testing module captures the network request response messages sent by the system under test through an API proxy interceptor, and extracts the operating parameters from the response messages; or... The upstream testing module intercepts and parses the internal communication data of the system under test by performing hook operations on the function calls of the system under test, and obtains the operating parameters.

3. The method according to claim 1, characterized in that, The downstream testing module obtains operating parameters by recognizing the user interface display information of the system under test, including: Extract the interface control tree structure of the system under test, locate the preset feature text label in the control tree structure, and traverse the parent control upwards based on the hierarchical relationship to match the running parameters; if no match is found, traverse all controls within the entire interface of the system under test to find text information that matches the running parameters.

4. The method according to claim 1, characterized in that, The operating parameters include at least a scene mode identifier and an enhancement status identifier; before the downstream testing module executes the test task using the acquired operating parameters, it also includes: According to the preset mode mapping table, the scene mode identifier and the enhanced state identifier are combined and mapped to the corresponding computing resource upper limit value, and the computing resource upper limit value is used as the execution benchmark of the current test task.

5. The method according to claim 4, characterized in that, The preset pattern mapping table is generated in the following ways: During the pipeline startup phase, the pipeline orchestrator sends a probe command to the system under test to obtain a list of supported modes and corresponding resource quota information. Based on the returned list of modes and resource quota information, the mode mapping table is dynamically constructed and cached.

6. The method according to claim 1, characterized in that, The method further includes: The pipeline orchestrator initializes the in-process shared memory area when the pipeline starts, and calls the reset method of the in-process shared memory area before the pipeline execution ends or before a new round of testing begins, clearing historical running parameters and resetting the data ready state to not ready.

7. The method according to claim 1, characterized in that, The method further includes: If the downstream testing module fails to obtain the operating parameters after performing the step of obtaining the operating parameters by recognizing the user interface display information of the system under test, it is determined that the environment is abnormal. At this point, the downstream testing module suspends the execution of the current testing task, generates a test failure report containing abnormal diagnostic information, and sends a status abnormality signal to the pipeline orchestrator, triggering an alarm.

8. The method according to claim 1, characterized in that, The method further includes: After the pipeline orchestrator detects a change in the operating mode of the system under test, it calls the write method of the intra-process shared memory area to update the operating parameters corresponding to the new mode to the intra-process shared memory area.

9. The method according to claim 1, characterized in that, The shared memory area within the process is implemented using a global singleton pattern, and read and write operations on the shared memory area within the process are synchronized using mutexes or atomic variables.

10. A status transfer system between pipeline modules, characterized in that, include: The shared state storage module is configured as an in-process shared storage area for storing runtime parameters; The upstream testing module is configured to obtain operating parameters through non-user interface interaction with the system under test, and write the operating parameters into the shared state storage module; The downstream testing module is configured to detect the data readiness status of the shared state storage module before execution. If the data readiness status is ready, the module directly reads the running parameters from the shared state storage module. If the data readiness status is not ready, the module obtains the running parameters by recognizing the user interface display information of the system under test, and uses the obtained running parameters to execute the test task.

11. An electronic device, comprising: A processor and a memory storing a program, characterized in that the program includes instructions that, when executed by the processor, cause the processor to perform the method of any one of claims 1 to 9.

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

Images