Method and device for generating software test playback scheme, and electronic device

Abstract

This invention discloses a method, apparatus, and electronic device for generating software test replay schemes, relating to the field of software testing technology or other related fields. The method includes: selecting an initial replay template from a preset scheme template library based on software testing requirements and loading it into a visual design interface to obtain an initial flow canvas; selecting a target component from a preset abstract component library and dragging it to the target position on the initial flow canvas to form a graphical replay flowchart with data flow between components; configuring structured parameters for each component in the replay flowchart to generate configuration data; and encapsulating the configuration data and the replay flowchart into a software test replay scheme and saving it to a replay system and / or the scheme template library. This invention solves the technical problem in related technologies where software test replay schemes are mostly expressed in the form of discrete configuration files or code, lacking structured, visual, and component-based abstraction of the test process, resulting in poor reusability of the replay process.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and more specifically, to a method and apparatus for generating software test playback schemes, and electronic equipment. Background Technology

[0002] In the field of software testing, traffic replay technology has been widely used to verify the consistency of the behavior of the system under test in historical traffic scenarios. The core is to capture the original number of requests and re-trigger the same call chain in the test environment to compare whether the response results meet expectations.

[0003] However, current mainstream replay solutions still rely on traditional form-based configuration methods. Users need to manually fill in a large number of discrete configuration items, such as data source paths, transmission protocol parameters, interface information of the system under test, Mock interception rules, and assertion comparison conditions, in multiple scattered configuration interfaces. Moreover, there is a lack of visual representation of the logical connections between these configuration items. Key elements in the replay process, such as triggering methods, data flow, master-sub-call relationships, Mock interception points, and comparison strategies, are all presented in the form of text parameters, failing to form an intuitive flowchart. This makes it difficult for users to quickly understand the overall structure and business semantics of the replay solution. Especially in scenarios involving complex microservice call chains and multi-level nested sub-calls, the configuration information is highly fragmented, making problem localization difficult and maintenance costs extremely high.

[0004] In existing technologies, the lack of a unified visual orchestration mechanism in replay solutions prevents users from intuitively perceiving data flow paths and component dependencies through graphical means, resulting in extremely poor comprehensibility. New members require extensive learning to master the solution logic. Furthermore, when the interface of the system under test changes, mock requirements are adjusted, or the data source is updated, users must modify each item on multiple configuration pages, unable to dynamically adjust component relationships through drag-and-drop or connection methods. This leads to extremely low solution reusability, and any minor adjustment can trigger a chain of errors. In addition, due to scattered configuration parameters and weak verification mechanisms, hidden defects such as missing components, broken data flow, and unconfigured required parameters frequently occur. The lack of real-time alarms and structured verification capabilities makes it difficult to quickly locate the problem after a replay failure, severely restricting the efficiency and reliability of replay testing.

[0005] The aforementioned problems collectively lead to systemic bottlenecks in traditional replay solutions when facing dynamic, complex, and frequently iterating test scenarios. These bottlenecks include poor understandability, weak scalability, high maintenance costs, and low testing efficiency, making it difficult to meet the agility and visualization requirements of modern software testing. Currently, no effective solutions have been proposed to address these issues. Summary of the Invention

[0006] This invention provides a method, apparatus, and electronic device for generating software test replay schemes, which at least solves the technical problem that software test replay schemes in related technologies are mostly expressed in the form of discrete configuration files or code, lacking structured, visual, and component-based abstraction of the test process, resulting in poor reusability of the replay process.

[0007] According to one aspect of the present invention, a method for generating a software test replay scheme is provided, comprising: selecting an initialization replay template from a preset scheme template library according to software testing requirements, and loading the initialization replay template onto a visual design interface to obtain an initial flow canvas; selecting a target component from a preset abstract component library according to the software testing requirements, and dragging the target component to a target position in the initial flow canvas to form a graphical replay flowchart with data flow between components; configuring structured parameters for each component in the replay flowchart based on the software testing requirements to generate configuration data corresponding to each component; encapsulating all the configuration data and the replay flowchart into a software test replay scheme, and saving the software test replay scheme to a replay system and / or the scheme template library.

[0008] Furthermore, the preset abstract component library includes: a trigger component, a data source component, a transmitter component, an application component, a Mock component, an assertion component, and a data processing component; wherein, the trigger component is used to control the playback triggering method, the data source component is used to provide playback data, the transmitter component is used to schedule the system under test, the application component is used to define the target software under test, the Mock component is used to intercept and simulate sub-call responses, the assertion component is used to compare playback response results, and the data processing component is used to perform data format conversion and encoding / decoding.

[0009] Further, according to the software testing requirements, the step of selecting a target component from a preset abstract component library and dragging the target component to the target position in the initial process canvas to form a graphical playback flowchart with data flow between components includes: dragging the trigger component to the starting position of the initial process canvas; dragging the data source component downstream of the trigger component and establishing a one-way connection from the trigger component to the data source component; dragging the transmitter component downstream of the data source component and establishing a one-way connection from the data source component to the transmitter component; dragging the application component downstream of the transmitter component and establishing a one-way connection from the transmitter component to the application component; and dragging the assertion component downstream of the application component and establishing a one-way connection from the application component to the assertion component.

[0010] Furthermore, the step of configuring structured parameters for each component in the replay flowchart based on the software testing requirements, and generating configuration data corresponding to each component, includes: setting the replay trigger timing and execution strategy for the trigger component according to the software testing requirements, and setting a data acquisition identifier or data source path for the data source component; setting the target system call method and communication parameters for the transmitter component according to the software testing requirements, and setting the tested system environment information, main call interface information, and sub-call interception configuration for the application component; if the replay flowchart includes a Mock component, setting request matching rules and response simulation content for the Mock component according to the software testing requirements; if the replay flowchart includes an assertion component, setting result comparison logic and comparison data type for the assertion component according to the software testing requirements; if the replay flowchart includes a data processing component, setting data conversion methods and encoding rules for the data processing component according to the software testing requirements.

[0011] Furthermore, before encapsulating all the configuration data and the playback flowchart into a software test playback scheme, the method further includes: performing verification on the configuration data and the playback flowchart to obtain a verification result; if the verification result is satisfactory, allowing encapsulation to proceed; otherwise, sending verification error information to the visual design interface.

[0012] Further, the step of performing verification on the configuration data and the playback flowchart to obtain verification results includes: verifying whether there are isolated components in the playback flowchart to obtain a first verification sub-result; verifying whether the playback flowchart contains at least a trigger component, a data source component, a transmitter component, and an application component to obtain a second verification sub-result; verifying whether there are logical conflicts in the connection lines of each component in the playback flowchart to obtain a third verification sub-result; verifying whether the configuration data of each component in the playback flowchart is complete to obtain a fourth verification sub-result; and setting the verification result as passed if all verification sub-results are passed, otherwise setting it as failed.

[0013] Further, the step of encapsulating all the configuration data and the replay flowchart into a software test replay scheme includes: encoding the node topology and connection relationships of the replay flowchart into graph structure data, wherein the graph structure data includes the node ID, connection edge ID, and connection direction of all components; classifying and aggregating all the configuration data to obtain a configuration data set; merging the graph structure data and the configuration data set into a unified JSON format file, wherein the JSON format file includes a process field and a configuration field, the process field storing the flowchart structure, and the configuration field storing the configuration information of each component; generating a scheme ID for the JSON format file, and binding the scheme ID to the JSON format file to generate the software test replay scheme.

[0014] According to another aspect of the present invention, a software test replay scheme generation apparatus is also provided, comprising: a selection unit, configured to select an initialization replay template from a preset scheme template library according to software testing requirements, and load the initialization replay template into a visual design interface to obtain an initial flow canvas; a drag-and-drop unit, configured to select a target component from a preset abstract component library according to the software testing requirements, and drag the target component to a target position in the initial flow canvas to form a graphical replay flowchart with data flow between components; a configuration unit, configured to perform structured parameter configuration on each component in the replay flowchart based on the software testing requirements, and generate configuration data corresponding to each component; and an encapsulation unit, configured to encapsulate all the configuration data and the replay flowchart into a software test replay scheme, and save the software test replay scheme to a replay system and / or the scheme template library.

[0015] Furthermore, the preset abstract component library includes: a trigger component, a data source component, a transmitter component, an application component, a Mock component, an assertion component, and a data processing component; wherein, the trigger component is used to control the playback triggering method, the data source component is used to provide playback data, the transmitter component is used to schedule the system under test, the application component is used to define the target software under test, the Mock component is used to intercept and simulate sub-call responses, the assertion component is used to compare playback response results, and the data processing component is used to perform data format conversion and encoding / decoding.

[0016] Further, the drag-and-drop unit includes: a first drag-and-drop module, used to drag the trigger component to the starting position of the initial process canvas, drag the data source component downstream of the trigger component, and establish a unidirectional connection line from the trigger component to the data source component; a second drag-and-drop module, used to drag the transmitter component downstream of the data source component, and establish a unidirectional connection line from the data source component to the transmitter component; a third drag-and-drop module, used to drag the application component downstream of the transmitter component, and establish a unidirectional connection line from the transmitter component to the application component; and a fourth drag-and-drop module, used to drag the assertion component downstream of the application component, and establish a unidirectional connection line from the application component to the assertion component.

[0017] Further, the configuration unit includes: a first setting module, used to set the replay triggering time and execution strategy for the trigger component according to the software testing requirements, and to set the data acquisition identifier or data source path for the data source component; a second setting module, used to set the target system call method and communication parameters for the transmitter component according to the software testing requirements, and to set the tested system environment information, main call interface information and sub-call interception configuration for the application component; a third setting module, used to set request matching rules and response simulation content for the Mock component according to the software testing requirements when the replay flowchart includes a Mock component; a fourth setting module, used to set result comparison logic and comparison data type for the assertion component according to the software testing requirements when the replay flowchart includes the assertion component; and a fifth setting module, used to set data conversion method and encoding rules for the data processing component according to the software testing requirements when the replay flowchart includes the data processing component.

[0018] Furthermore, the software test replay scheme generation device further includes: a first verification module, used to perform verification on the configuration data and the replay flowchart before encapsulating all the configuration data and the replay flowchart into a software test replay scheme, and obtain a verification result; and a second verification module, used to allow encapsulation if the verification result is passed, otherwise, send verification error information to the visual design interface.

[0019] Further, the first verification module includes: a first verification submodule, used to verify whether there are isolated components in the playback flowchart, and obtain a first verification sub-result; a second verification submodule, used to verify whether the playback flowchart contains at least a trigger component, a data source component, a transmitter component, and an application component, and obtain a second verification sub-result; a third verification submodule, used to verify whether there are logical conflicts in the connection lines of each component in the playback flowchart, and obtain a third verification sub-result; a fourth verification submodule, used to verify whether the configuration data of each component in the playback flowchart is complete, and obtain a fourth verification sub-result; and a sixth setting module, used to set the verification result to pass if all verification sub-results are passed, otherwise set it to fail.

[0020] Further, the encapsulation unit includes: an encoding module, used to encode the node topology and connection relationships of the playback flowchart into graph structure data, wherein the graph structure data includes the node ID, connection edge ID, and connection direction of all components; an aggregation module, used to classify and aggregate all the configuration data to obtain a configuration data set; a merging module, used to merge the graph structure data and the configuration data set into a unified JSON format file, wherein the JSON format file includes a process field and a configuration field, the process field storing the flowchart structure, and the configuration field storing the configuration information of each component; and a binding module, used to generate a scheme ID for the JSON format file and bind the scheme ID to the JSON format file to generate the software test playback scheme.

[0021] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the method for generating any of the above-described software test playback schemes.

[0022] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method for generating any of the above-described software test playback schemes.

[0023] This invention proposes a method for generating software test replay schemes. First, based on software testing requirements, an initialization replay template is selected from a preset scheme template library and loaded into a visual design interface to obtain an initial flow canvas. Then, based on software testing requirements, a target component is selected from a preset abstract component library and dragged to the target position in the initial flow canvas to form a graphical replay flowchart with data flow between components. Next, based on software testing requirements, structured parameter configurations are performed on each component in the replay flowchart to generate configuration data corresponding to each component. Finally, all configuration data and the replay flowchart are encapsulated into a software test replay scheme and saved to the replay system and / or the scheme template library.

[0024] This invention employs a graphical drag-and-drop and component-based orchestration approach. By decoupling the replay function and initializing a process canvas based on a preset template, creating a graphical replay flowchart with a clear data flow, and establishing a structured configuration of parameter configurations and graphical nodes for each component, it transforms the originally fragmented and text-based replay configuration into a visually expressible, dynamically adjustable, and fully reusable entity. This achieves a systematic transformation of the replay solution from discrete parameter configuration to a structured, visual, and component-based object. Furthermore, it addresses the technical problem in related technologies where software test replay solutions are often expressed in discrete configuration files or code, lacking a structured, visual, and component-based abstraction of the test process, resulting in poor reusability of the replay process. This method realistically maps the business chain through a visual canvas, allowing testers to construct the replay process in a "building block" manner according to business intent without needing to understand the underlying protocols or configuration syntax. This significantly improves the efficiency and consistency of solution design and provides a solution for automated testing in complex microservice environments. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0026] Figure 1 This is a flowchart of an optional software test replay scheme generation method according to an embodiment of the present invention;

[0027] Figure 2 This is a visual design flowchart of an optional software test replay scheme according to an embodiment of the present invention;

[0028] Figure 3 This is a visual design architecture diagram of an optional software test replay scheme according to an embodiment of the present invention;

[0029] Figure 4This is a schematic diagram of an optional software test playback scheme generation device according to an embodiment of the present invention;

[0030] Figure 5 This is a structural block diagram of an electronic device for generating a software test playback scheme according to an embodiment of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] To facilitate understanding of the present invention by those skilled in the art, some terms or nouns involved in the various embodiments of the present invention are explained below:

[0034] Mock processing refers to components used to intercept internal sub-calls of the system under test (such as calls to databases, caches, and RPC services) and simulate their response behavior. Its role is to isolate external dependencies and ensure that the replay results only reflect the behavior of the system under test itself and do not depend on the response of the real environment.

[0035] The following embodiments of the present invention can be applied to various systems / applications / devices that require automated software regression testing and dynamic verification of microservice links. They enable the visualization, reuse, and execution of complete replay test processes without writing code. The present invention uses a graphical component drag-and-drop and structured parameter binding mechanism for the visual design of replay schemes. The design results are then encapsulated into a unified, storable scheme entity and loaded into the replay engine for execution. This significantly reduces the testing threshold, improves scheme consistency, shortens the integration testing cycle, and supports the isolation of external system interference through Mock components in complex dependency environments, accurately verifying the behavior of the service under test.

[0036] The present invention will now be described in detail with reference to various embodiments.

[0037] Example 1

[0038] According to an embodiment of the present invention, a method for generating a software test replay scheme is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0039] Examples of embodiments of the present invention Figure 1 The method for generating a software test replay scheme is illustrated. The main implementation entity of this method is the software test replay system. It combines graphical component-based orchestration and structured configuration mapping technology for automated regression testing and link verification scenarios under microservice architecture. In particular, it addresses the problems of traditional replay schemes relying on discrete configuration files, invisible processes, poor reusability, and difficulty in problem localization. It uses a visual drag-and-drop assembly method to assemble the replay process and bind parameter configurations. Specifically, it starts by initializing the process canvas from a preset template, dragging triggers, data sources, transmitters, applications, Mock, assertions, and data processing components from the abstract component library to form a directed flowchart, setting structured parameters for each component and establishing node-configuration mapping, and encapsulating the process integrity into a unified scheme entity. This achieves the goal of graphical representation, reusable storage, and efficient execution of the replay scheme.

[0040] Figure 1 This is a flowchart of an optional software test replay scheme generation method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0041] Step S101: Based on the software testing requirements, select an initialization replay template from the preset solution template library and load the initialization replay template into the visual design interface to obtain the initial process canvas.

[0042] It's important to note that the system includes various template types to meet the playback needs of different users, such as blank templates, test case playback templates, link playback templates, scenario playback templates, and comparison-only templates. Templates are not merely copies of configurations; they are process frameworks containing preset component types, basic connection relationships, and logical structures. For example, the "link playback template" pre-defines a five-stage basic flow: "trigger → data source → transmitter → application → assertion," and may pre-load typical components (such as RPC transmitters and microservice applications). After loading the template, the system generates an "initial process canvas," which is not a blank canvas but a visual workspace with component layout, node position relationships, and connection direction. Users can incrementally modify it rather than building from scratch. Reusing templates to quickly create solutions simplifies the creation process, improves efficiency, and provides the necessary structural support for building block-style visual design.

[0043] For example, if testers need to verify the behavior of an order query interface under multiple downstream service dependencies, they can select the "Link Replay Template". The system will automatically load a component chain containing "Test Case Library → RPC Transmitter → TAP Microservice → Assertion" and preset "the main calling method is searchOrderDetailByLocator" in the application component. Users only need to fill in parameters such as environment IP, test case tags, and comparison rules to immediately enter the configuration phase. If only the comparison logic of the interface response needs to be verified, the "Comparison Template Only" can be selected. The system will only load the two components "Data Source → Assertion", omitting the transmission and calling links and significantly reducing invalid operations.

[0044] In this embodiment, based on software testing requirements, an initial replay template is first selected from a pre-defined scheme template library. This template is a predefined replay scheme structure framework, containing the basic component types and connection relationships of the replay process, but not specific parameter configurations. After selection, the initial replay template is directly loaded into the visual design interface, so that the component structure and logical connection relationships contained in the template are fully presented in the interface, forming an initial process canvas that can be edited later. This canvas retains the original composition structure of the template without any modification or expansion, and only serves as the starting carrier for replay scheme design, ensuring that users start building from a standardized scheme foundation and avoid the configuration complexity and cognitive burden caused by creating from an empty state.

[0045] Step S102: Based on the software testing requirements, select the target component from the preset abstract component library and drag the target component to the target position in the initial process canvas to form a graphical playback flowchart with data flow between components.

[0046] After the graphical replay process is initialized, users can select functional components from a pre-defined abstract component library via visual drag-and-drop, and construct a topology with a clear data flow on the canvas according to business logic, thereby transforming abstract test requirements into a visual execution blueprint. Its core is based on the design philosophy of components as functional units, achieving a modular and composable expression of test capabilities.

[0047] This invention decouples replay capabilities into seven categories of components: triggers, data sources, data processing, transmitters, applications, mocks, and assertions. Each category corresponds to an atomic testing capability. For example, the transmitter handles the call method (RPC / message queue), the mock handles interception and simulation of sub-calls, and the assertion handles response comparison. Components are organized by category in a component pool. Users can drag and drop components to any position on the canvas. Data flow relationships are established between components through unidirectional connections (with arrows), such as "data source → transmitter → application → assertion" forming a complete replay chain. The application component is a container-type node that supports... The system internally nests main and sub-call nodes, with sub-calls further able to attach interception and mock components, forming a nested call relationship that realistically reflects the call hierarchy of microservices. Each component, once dragged in, activates its parameter configuration panel, allowing users to fill in parameters (such as test case tags, interface methods, and mock rules) in subsequent steps. The graphical structure is strongly bound to the parameter configuration, forming a three-in-one replay solution of structure, behavior, and data. This process realizes a design concept similar to building blocks, allowing for the combination of components as needed and the presentation of data flow through connections, transforming the testing process from a configuration list into a readable, reviewable, and modifiable visual workflow.

[0048] For example, a test scenario needs to verify the fault tolerance capability of an order service when it is abnormally interrupted when calling the inventory interface: the user drags in triggers, test case libraries, RPC transporters, and microservice applications from the component library, expands the application components, drags in interception components (bound to Redis calls) in their sub-call areas, then attaches a simulation component (returning a timeout response) after it, and finally connects the assertion component to verify whether the main response is a degraded result. In the traditional way, this process requires writing multiple configuration files, modifying code, and restarting the service. However, in this embodiment of the invention, it can be completed by dragging and dropping four components, attaching them in two places, and connecting them with a single line. All the logic is clear at a glance and there is no need to understand the underlying protocol.

[0049] In this embodiment, firstly, based on the software testing requirements, specific components matching the testing objectives are selected from a pre-defined abstract component library. This component library is a predefined and structured collection of components whose content does not change with specific testing scenarios, and the selection behavior is guided only by the requirements. Then, the selected components are dragged and dropped to place them at the designated target position in the initial process canvas. This operation does not rely on any pre-defined templates or fixed layouts, and the spatial positioning of the components is actively controlled by the user. After the components are placed, the system automatically establishes the data flow relationship between the components, forming a playback flowchart composed of connected graphical elements. This flowchart visually presents the logical transmission order between components in a visual graphical way. Its composition is determined only by the selected components and their drag positions, and does not involve any implicit rules or automatic reasoning.

[0050] Furthermore, the pre-defined abstract component library includes: trigger component, data source component, transmitter component, application component, Mock component, assertion component, and data processing component; among them, the trigger component is used to control the playback triggering method, the data source component is used to provide playback data, the transmitter component is used to schedule the system under test, the application component is used to define the target software under test, the Mock component is used to intercept and simulate sub-call responses, the assertion component is used to compare playback response results, and the data processing component is used to perform data format conversion and encoding / decoding.

[0051] The pre-defined abstract component library constructed in this embodiment of the invention is a deep decoupling and atomic abstraction of the functions of traditional playback systems, forming seven types of standardized and scalable component contracts. Each type of component carries a clear boundary of testing capabilities, has a single responsibility and a unified interface, and is combinable and configurable.

[0052] Specifically, the trigger component not only defines the replay initiation method (manual trigger or timed trigger), but also carries the execution strategy control, such as timeout duration, serial / parallel execution mode, and retry mechanism. For example, in a regression testing scenario, testers select a "timed trigger," setting it to automatically execute the "full-link order replay scheme" at 2 AM daily, configuring a timeout duration of 30 seconds and allowing a maximum of two retries. The system generates a scheduling task accordingly, achieving automated regression loop without manual intervention.

[0053] The data source component supports obtaining test input from various heterogeneous data entry points, including test case files (such as CSV and Excel), test case collection records, and test case library tag filtering sets, and supports dynamic filtering mechanisms. For example, if a tester uses the "Test Case Library" component and sets the tag matching rule to "tagId=regression_v2 AND priority=high", the system will automatically retrieve 500 test samples that meet the conditions from the central test case library as the data input source for this replay.

[0054] The transport component defines the communication protocol and scheduling method used when the system under test is invoked. It is not limited to RPC or HTTP, but also supports protocols such as message queues, FTP, and SSH. Its parameters include request headers, context information, and response extraction rules. For example, in microservice trace testing, selecting the "RPC Transporter" component, configuring the request header to "Content-Type: application / grpc", and specifying to extract the "traceId" from the response for subsequent assertion comparisons.

[0055] As container-type nodes, application components not only describe the interface information of the system under test (service name, environment, version), but also carry the topology of their internal main and sub-calls. They are the only components that allow nested sub-call nodes. For example, selecting the "microservice" application component, configuring the service name as "OrderService", the main call as "getOrderDetail", and nesting two "Redis sub-call" nodes within it, with each node bound to a different sandbox ID, enables independent mock control of the two cache nodes.

[0056] The Mock component is divided into two subtypes: "Intercept" and "Simulate," which work together to achieve precise intervention in sub-calls. The intercept component is responsible for capturing requests of a specified protocol (such as MyBatis SQL or Redis commands), while the mock component is responsible for returning a preset response (such as success, exception, or delay). For example, attaching an "Intercept" component (matching the Redis key stock:123) to the "Query Inventory" sub-call in "OrderService" and then binding a "Simulate" component to it, setting the response to {"stock":0,"code":"OUT_OF_STOCK"}, can simulate an inventory depletion scenario and verify the system degradation logic.

[0057] The assertion component supports multi-format and multi-level comparison of the main response and sub-call responses, including JSON path matching, XML node validation, fuzzy text content comparison, field ignoring, and tolerance range setting. For example, the assertion component can be configured to require that "$.status in the main response must be SUCCESS" and "the code field in the return value of redis.get(stock:123) in the sub-call must be OUT_OF_STOCK", thus achieving end-to-end result consistency verification.

[0058] Data processing components are used for dynamic transformation, mapping, and encoding / decoding within data streams, often for data format adaptation between heterogeneous systems. This includes data mapping (field mapping rules) and format conversion (XML). This includes operations such as JSON encoding (Base64) and decoding. For example, in a playback chain, the upstream test case is in XML format, while the system under test only accepts JSON. Inserting a "Data Conversion" component and setting an "XML to JSON" rule automatically performs the format conversion before passing it to the transmitter, avoiding playback failures due to format mismatch.

[0059] In the above embodiments, a pre-defined abstract component library explicitly includes seven functionally specific abstract components: trigger components, data source components, transmitter components, application components, mock components, assertion components, and data processing components. Each component is then bound to its specific function: the trigger component controls the playback triggering method; the data source component provides playback data; the transmitter component schedules the system under test; the application component defines the target software under test; the mock component intercepts and simulates subcall responses; the assertion component compares playback response results; and the data processing component performs data format conversion and encoding / decoding. This allows users to drag and drop the aforementioned components onto the initial process canvas in a visual design interface, forming a graphical replay flowchart with a clear data flow and logical structure. This fully covers key aspects of the replay process, such as trigger control, data supply, system scheduling, target definition, sub-call simulation, result verification, and data processing. It achieves standardized and structured expression of the replay process, effectively solving the problems of incomplete process expression, unclear logic, and poor comprehensibility caused by ambiguous component functions. This improves the design accuracy of the replay scheme and the ability to reproduce test scenarios, ultimately enhancing the systematic nature and reliability of software testing.

[0060] It should be noted that abstraction can be performed based on playback services, fully decoupling the original playback system functions to form component contracts of different categories. Component types can be divided into two main categories: configuration and scheduling. Configuration components have no specific behavior and mainly provide playback service data; scheduling components, in addition to providing basic configuration, also have corresponding behaviors. An example of component division rules is as follows:

[0061] Table 1

[0062]

[0063]

[0064] When the above secondary category components do not meet the business scenario, the capabilities can be freely extended based on the component contract to realize the customization of specific components.

[0065] Further, the components are uploaded to the preset abstract component library. System business components extended based on component contracts are uploaded to the component management platform, and their status is set to active. After uploading, component-related information is stored in the component definition table. If a component is updated after uploading, the updated component is re-uploaded, and its status is set to active. Next, component status control can be implemented. The status of built-in system components is controlled by the system administrator, while users can control the status of components extended based on component contracts, such as active or unactive. Component status can be changed according to actual usage; inactive or unactive components will not be displayed. Finally, components are presented. After uploading, components can be categorized and displayed in the [Component Pool] of the solution design visual console. Users can select components based on the [Component Pool].

[0066] Furthermore, based on software testing requirements, the steps include selecting target components from a pre-defined abstract component library and dragging them to target positions on the initial process canvas to form a graphical playback flowchart with data flow between components. These steps include: dragging a trigger component to the starting position of the initial process canvas; dragging a data source component downstream of the trigger component and establishing a one-way connection from the trigger component to the data source component; dragging a transmitter component downstream of the data source component and establishing a one-way connection from the data source component to the transmitter component; dragging an application component downstream of the transmitter component and establishing a one-way connection from the transmitter component to the application component; and dragging an assertion component downstream of the application component and establishing a one-way connection from the application component to the assertion component.

[0067] It's important to note that component dragging and connection rely on fixed logic. For example, the logic for trigger → data source is that playback must be initiated by a certain trigger condition (manual or timed), and after triggering, it's necessary to specify "where to obtain test data." Therefore, the trigger is the starting point of the entire process, and the data source is the input source; the two must be connected end-to-end.

[0068] Other fixed logic is as follows:

[0069] The logic behind the data source → transmitter is as follows: after obtaining test data, the request needs to be sent to the system under test through a specific protocol. The transmitter is the "sender" of the data, responsible for encapsulating the data into a callable request body (such as an RPC request or an HTTP message).

[0070] The logic behind the transmitter-to-application connection is as follows: the transmitter's output must act on the specific object under test, and the application component is the only node that carries the information of the system under test (service name, interface, environment). This connection represents "the request finally reaching the target."

[0071] The logic behind application assertions is that after the system under test responds, its output must be verified. Assertions are the endpoint of result verification, used to compare whether the response content meets expectations (such as JSON structure, status code, field values).

[0072] The above four-segment connection chain—trigger → data source → transmitter → application → assertion—is the standard replay process skeleton, following the test lifecycle logic of "input → scheduling → execution → verification" to ensure the process has semantic integrity and execution feasibility.

[0073] In a specific implementation scenario (verifying the response differences of an order query service under different user permissions), the specific steps are as follows:

[0074] Step 1: Drag the "Trigger Component" to the top left corner of the canvas and set it to "Manual Trigger";

[0075] Step 2: Drag and drop the "Test Case Library Component" to the right side of the system and configure the label as "user_role=admin". The system will automatically load all test cases marked with administrator privileges.

[0076] Step 3: Drag and drop the "RPC Transporter Component", connect it to the test case library, configure the request header to "X-User-Role:{{userRole}}", and bind the response extraction rule "Extract User Permission Fields";

[0077] Step 4: Drag and drop the "Microservice Application Component" downstream of the transporter, configure the service name as "OrderQueryService", the main calling method as "getOrderListByUser", and the environment as "testenv";

[0078] Step 5, drag and drop the "Assertion Component" to connect to the application component, and set the comparison rules: "In the response, .totalOrders should be greater than 0, and .userRole should be equal to {{userRole}}";

[0079] At this point, the canvas forms a clear, orderly, and semantically complete test flow: trigger → obtain permission tags → send RPC requests with permission headers → call the service → verify the consistency of the response and permissions. If the connection is not made in this order (such as placing assertions before the connection or skipping the transmitter), the system will prompt "component connection is invalid," prevent saving, and ensure the correctness of the solution logic.

[0080] Alternatively, by fixing the trigger component at the beginning of the initial process canvas and dragging the data source component, transmitter component, application component, and assertion component sequentially downstream of the previous component, a unidirectional connection line is established from trigger to data source, data source to transmitter, transmitter to application, and application to assertion. This forces the construction of a linear data flow structure of trigger → data source → transmitter → application → assertion, making the execution order and data transmission path of the replay process clearly and uniquely defined on the visual interface. This avoids problems such as logical confusion, uncontrollable execution order, and unclear data flow caused by disordered component arrangement or ambiguous connection relationships when users freely arrange components. It ensures that the replay scheme has a high degree of structural consistency and verifiability, thereby improving the reliability, understandability, and debugging efficiency of the replay process, and ultimately achieving precise control and efficient management of the software test replay process.

[0081] In another optional embodiment, the initialization of the playback scheme corresponding to the software test playback service is based on a scheme template. The implementation system has a wealth of pre-built scheme templates, and users can also save the scheme as a template according to their actual needs. The following describes how to initialize a scheme based on a blank template:

[0082] Select the blank template to complete the initialization of the solution. The initialization process is very simple; just set the solution type (use case playback / scenario playback / link playback / comparison only), and the system will automatically generate a solution name. Users can also change the solution name according to their preferences. Solution design and improvement are mainly carried out in the visual solution design console. The console provides personalized areas such as the component pool, solution design panel, panel menu, and panel controls, allowing for quick improvement and adjustment of the solution.

[0083] One optional setting is the **Trigger**, which configures the replay scheme's trigger method and replay strategy (test case replay timeout, serial or parallel replay, etc.). The test case timeout defaults to 10 seconds and can be adjusted as needed. **Data Source** settings include: selecting the **Test Case Library** component, setting the tags for replay test cases, and completing the connection between the **Trigger** and **Data Source** components after parameter settings are complete. **Transmitter** settings include: selecting the **RPC Transmitter** component, setting the application's trigger method, and completing the RPC-related parameters (header and context information). After parameter settings are complete, complete the connection between the **Data Source** and **Transmitter** components. **Application** settings include: selecting the **Microservice** component, setting the application's basic information (environment, software, interfaces, methods, etc.) and main call information. After setting the parameters, complete the connection between the [Transmitter] component and the [Application]; Configure [MOCK] to set sub-call information for the [Microservice] component, and attach [Intercept] and [Simulate] components to the sub-calls according to the actual situation, and complete the setting of interception and simulation rules; Configure [Assertion] to set assertion information for the [Application] (response data and sub-call comparison rule settings). After setting the parameters, complete the connection between the [Application] component and [Assertion]. The above visually presents the composition and data flow of the replay scheme through the combination and connection between components. It can also dynamically adjust the interception and simulation processing of application sub-calls according to actual replay needs. It presents the building elements of the scheme in a structured way.

[0084] Step S103: Based on the software testing requirements, the structured parameters of each component in the playback flowchart are configured to generate configuration data corresponding to each component.

[0085] After the graphical playback flowchart is constructed, structured parameter configuration data that strictly matches its functional type is injected into each component, transforming graphical nodes from visual symbols into test instruction units with executable semantics. Its core is to achieve "graph as configuration"—strong binding between graphical structure and parameter data, semantic consistency, and standardized formatting, ensuring that the visual design can be accurately parsed and executed by the system.

[0086] Each component type (such as triggers, applications, mocks, assertions, etc.) defines a unique parameter structure contract. For example, the parameters of the application component include: environment IP, module name, service name, interface name, main calling method, and sub-call interception configuration (including intercepted type, sandbox ID, mock binding ID), organized in JSON format. The parameters of the test case library component are tag matching rules, using a "conditional expression + logical operator" structure (such as tagId equals 3cc9a97f-a5dd-4921-ba26-082a5e33bd53). The parameters of the mock component include interception rules (such as method name, parameter type) and mock responses (such as fixed JSON, delay time, error code). The parameters of the assertion component are comparison rules (such as JSON path matching, ignored fields, tolerance threshold), supporting multi-format (JSON / XML / text) comparison strategies.

[0087] All parameter configurations are not entered in free text form, but are guided to be filled in by the user through a component-specific configuration panel using field forms, drop-down selections, rule editors, etc., to ensure standardized data format; the configuration data is bound one by one to the graphical nodes to form a mapping relationship of "node ID → structured parameter object", and this mapping relationship is persistently stored as part of the solution metadata.

[0088] In this embodiment, the components in the replay flowchart are first configured with structured parameters based on software testing requirements. This means that each component in the flowchart is given clear and formatted content according to the replay behavior requirements defined by the test scenario, so that each component no longer exists merely as a graphical element, but as a structured data unit carrying specific configuration information. This configuration process does not rely on unstructured text descriptions or scattered parameter inputs, but strictly fills in the data according to the preset data structure corresponding to the component type, ensuring that parameters correspond one-to-one with components and are consistent in form. The configuration data generated directly reflects the functional positioning and operational constraints of the components in the replay process, providing accurate and parsable underlying data support for the subsequent verification, execution, and visualization of the solution, thereby ensuring that each component in the replay flowchart has an executable configuration basis.

[0089] Furthermore, the steps of configuring structured parameters for each component in the replay flowchart based on software testing requirements and generating configuration data corresponding to each component include: setting the replay trigger timing and execution strategy for the trigger component and setting the data acquisition identifier or data source path for the data source component according to software testing requirements; setting the target system call method and communication parameters for the transmitter component and setting the tested system environment information, main call interface information, and sub-call interception configuration for the application component according to software testing requirements; setting request matching rules and response simulation content for the Mock component when the replay flowchart includes a Mock component according to software testing requirements; setting result comparison logic and comparison data type for the assertion component when the replay flowchart includes an assertion component according to software testing requirements; and setting data conversion methods and encoding rules for the data processing component when the replay flowchart includes a data processing component according to software testing requirements.

[0090] The above steps transform each component in the graphical process from a visual symbol into a configuration entity with executable semantics. The core principle is that parameter configuration is not free text input, but rather the injection of a predefined, structured, type-safe data model based on the component type. Each parameter field carries a clear testing intent and is strictly bound to the component's contract definition.

[0091] Specifically, the trigger component controls the "on / off and rhythm" of playback initiation. Configuration includes setting the trigger timing (manual trigger / timed trigger) and execution strategy (timeout duration, serial / parallel execution, number of retries). For example, when configuring a "timed trigger" for a regression testing scenario, setting it to automatically execute at 2 AM daily, with a timeout of 45 seconds, an execution strategy of "serial execution," and enabling "retries twice on failure," the system will generate the following structured parameters: json{"triggerType":"scheduled","scheduleTime":"002 ?","timeout":45, "executionMode":"serial","maxRetries":2}.

[0092] Similarly, the data source component is used to define the "source" of test input. The configuration includes: if it is a "test case library" type, you need to configure tag matching rules (supporting logical operations); if it is a "test case file", you need to specify the storage path and format (such as server address, file name, encoding format).

[0093] The transport component is used to define the "sending protocol" of the request. The configuration includes: selecting the calling protocol (RPC, message queue, HTTP, etc.) and configuring communication parameters, such as request headers, context information, and response extraction fields.

[0094] The application component is used to define the "identity and behavior" of the system under test. The configuration content includes: system environment information (IP, environment ID, module name), main calling interface (method name, call type), and sub-call interception configuration (whether to intercept, the dependency type of the interception, and the bound simulation ID).

[0095] The Mock component is used to achieve "precise forgery" of dependency behavior. The configuration content is divided into two subtypes: interception and simulation. ① Interception rules: match request characteristics (such as Redis Key, method name, SQL statement); ② Simulation rules: define the return content (fixed response, delay, error code).

[0096] The assertion component acts as the "judge" for verifying the results. Its configuration includes: setting the comparison data type (JSON / XML / text), comparison rules (path matching, field value equality, regular expression validation, ignored fields), and tolerance range (numerical error, time difference).

[0097] The data processing component acts as a "translator" for data. Its configuration includes setting the conversion method (XML→JSON, Base64 decoding, field mapping rules) and encoding protocol (UTF-8, GBK).

[0098] In another optional embodiment, based on software testing requirements, after constructing a graphical replay flowchart containing triggers, data sources, transmitters, applications, mocks, assertions, and data processing components through a visual design interface, structured parameter configuration is implemented for the functional positioning of each component: precise replay trigger timing and execution strategies are set for the trigger component to ensure the test process starts as expected; data acquisition identifiers or source paths are configured for the data source component to ensure accurate acquisition of test data; target system call methods and communication parameters are specified for the transmitter component to achieve stable interaction with external systems; and the tested system environment information, main call interface information, and sub-call interception configurations are set for the application component to precisely control the behavioral boundaries of the tested system; when a mock component exists in the flowchart... The system configures request matching rules and response simulation content to achieve non-intrusive simulation of dependent services. When assertion components are present, it defines result comparison logic and comparison data types to ensure the objectivity and verifiability of test conclusions. When data processing components are present, it sets data conversion methods and encoding rules to ensure data consistency and compatibility in the process. Through the one-to-one mapping of the above component parameters and functional roles, the entire replay flowchart has complete and executable control logic and data flow specifications. This enables high-fidelity reproduction of test scenarios and full process controllability without relying on the underlying code implementation. It effectively solves the technical problem of replay failure or unreliable results due to ambiguous component configuration, and significantly improves the accuracy, repeatability, and engineering practicality of software test replay.

[0099] Furthermore, before encapsulating all configuration data and replay flowcharts into a software test replay scheme, the method also includes: performing verification on the configuration data and replay flowcharts to obtain verification results; if the verification results are satisfactory, encapsulation is allowed; otherwise, verification error information is sent to the visual design interface.

[0100] The above steps are necessary before the solution is persistently encapsulated into an executable unit. The system must perform full-dimensional semantic verification of the graphical structure, component connections, and parameter configuration to ensure that the solution is executable, complete, and consistent, and to avoid invalid solutions that "can be saved but cannot run" from polluting the system.

[0101] The pre-packaging verification includes the following five mandatory checks, all of which are automatically triggered when the user clicks "Save" or "Execute" and are reflected in real time to the visual design interface:

[0102] Integrity verification: This checks whether core components (triggers, data sources, transmitters, applications, assertions) are missing from the solution. For example, if a user draws two nodes, Application → Assertion, but does not connect the trigger and transmitter, the system will prompt: "Missing trigger component, unable to start playback".

[0103] Connectivity check: Check for the existence of isolated components (isolated nodes with no input or output). For example, if a user accidentally drags in an assertion component but it is not connected to any upstream node, the system will highlight the node and prompt: "Island component: Assertion has no input source".

[0104] Flow validity check: Check whether the connection between components conforms to semantic rules (e.g., the transporter must be connected to the application, and the assertion cannot be connected to the trigger). For example, if the user connects the assertion component to the trigger component, the system will refuse the connection and prompt: "Assertions must be connected after the application or sub-call, and cannot be placed before it."

[0105] Parameter completeness check: Check whether the required parameters of each component are filled in, such as: application environment ID, transmitter protocol type, assertion comparison type. For example, if the user does not fill in "envId" for the application component, a pop-up message will appear when saving: "Required parameter missing: The environment information of the tested system is not configured".

[0106] Parameter semantics and compatibility verification: Check whether the parameter value conforms to the format (such as JSON path syntax, time format), whether the component version is compatible, and whether the mock binding points to a valid interception point. For example, if the user specifies a non-existent "connectedSimulationId" for the Mock component, the system will prompt: "Mock ID sim-redis-999 is not bound to a valid interception rule".

[0107] In an optional implementation scenario, a user constructs an "order payment link replay solution," comprising: trigger → use case library → RPC transporter → microservice application → Mock (Redis interception + simulation → assertion). In operation, the user needs to configure the main call "payOrder" in the "application components" and attach an "intercept" component to the sub-call "redis:get:balance," but without binding any "simulation" component (i.e., connectedSimulationId is empty). After the verification action (the user clicks "Save"), the system responds with three errors in the alert panel: "Sub-call redis:get:balance has interception enabled, but no simulated response is bound"; "The comparison type of the assertion component is not selected (should be JSON / XML / text)"; "The transporter's protocol is not specified (should be RPC / HTTP, etc.)." At this point, the "Save" button is grayed out and cannot be clicked. The user can perform the following remedial actions: bind a "simulation" component to the Redis sub-call, configuring it to return {"balance":100}; select the "JSON" type for the assertion component and set the comparison path $.status. =="SUCCESS"; Select the "RPC" protocol for the transmitter. Save again; if verification passes, the system generates complete solution metadata and encapsulates it into the database.

[0108] It should be noted that after completing the component drag-and-drop and structured parameter configuration of the replay flowchart, the system performs a completeness and structural rationality check on the configuration data and replay flowchart before encapsulation. The system generates a check result by comparing the connection relationship between components, whether parameters are missing or conflicting, and whether the data flow conforms to logical rules. Only when the check passes can the configuration data and flowchart be encapsulated into an executable test plan. If the check fails, the system immediately provides specific error information to the visual design interface, such as "Component A is not connected to the input source" or "Parameter B is out of valid range". This prompts users to correct errors in real time before encapsulation, thereby avoiding invalid plans being encapsulated and subsequent execution failures caused by configuration omissions, structural breaks, or logical errors. This effectively solves the risk of unusable replay plans caused by the lack of a pre-check mechanism and significantly improves the reliability and development efficiency of test plans.

[0109] Further, the steps of performing validation on the configuration data and replay flowchart to obtain validation results include: validating whether there are isolated components in the replay flowchart to obtain a first validation sub-result; validating whether the replay flowchart contains at least a trigger component, a data source component, a transmitter component, and an application component to obtain a second validation sub-result; validating whether there are logical conflicts in the connection lines of each component in the replay flowchart to obtain a third validation sub-result; validating whether the configuration data of each component in the replay flowchart is complete to obtain a fourth validation sub-result; and setting the validation result to pass if all validation sub-results are passed, otherwise setting it to fail.

[0110] It should be noted that the first check result is used to record whether there are isolated components. An isolated component refers to a component in the flowchart that has no input or output connection, is neither driven by upstream components nor provides data to downstream components. Such components have no function in the replay execution and are considered design redundancy or misoperation, which may mask real logical defects.

[0111] In one embodiment, a user drags an assertion component into the visualization canvas but does not connect it to any upstream node (such as an application or sub-call). The system iterates through the in-degree and out-degree of all nodes in the background and finds that the component has an in-degree of 0 and an out-degree of 0, classifying it as an "island". At this point, an alarm is triggered: "Island component detected: The assertion is not connected to any data source and cannot participate in result comparison. Please connect to the application or sub-call node." The system then prevents saving until the user connects it to the "application component" output.

[0112] The second verification result is used to record whether the four core components are included. The essence of replay is a complete closed loop of "trigger → data acquisition → system invocation → result verification". Therefore, the trigger, data source, transmitter, and application constitute the smallest executable unit. Without any one of these nodes, the process cannot start or has no objective.

[0113] In one optional embodiment, the user is constructing a "comparison-only" solution, which only includes a data source and assertion components, without connecting any transmitters or applications. The system identifies this solution type as comparison-only (allowing for no transmitter), but if it is a link replay or use case replay type, it must include all four types of components. At this time, an alarm is displayed: "The current solution type is 'link replay,' which must include four core components: trigger, data source, transmitter, and application. Currently missing: transmitter and application." The system handles this by dynamically determining the required component set based on the solution template type, not requiring all components, but rather performing semantically driven conditional checks.

[0114] The third validation result records whether there are logical conflicts in the connection path. It's important to note that connections between components must conform to the business semantic flow, meaning data should flow from the "upstream producer" to the "downstream consumer." Incorrect connections will cause the execution engine to be unable to resolve data dependencies, leading to runtime crashes.

[0115] In one alternative embodiment, incorrect connection: Connecting the "Assertion Component" directly to the "Trigger Component" → System prompt: "Assertions must depend on the response of the application or its sub-calls and cannot be preceded." Incorrect connection: Connecting the "Data Source Component" to the "Assertion Component" (skipping the transporter and application) → System prompt: "The data source must be dispatched to the application under test by the transporter before results can be compared." Correct connection: Data Source → Transporter → Application → Assertion (main branch); In-application sub-call → Intercept → Simulate → Assertion (extended path).

[0116] The fourth checksum record indicates whether the configuration data for each component is complete. It should be noted that a valid graphical structure does not guarantee the availability of parameters. Each component has required parameters (such as the environment ID for "Application", the protocol type for "Transmitter", and the comparison format for "Assertion"), none of which can be omitted.

[0117] In one optional embodiment, the user only filled in the service name in the "Application Component" but not the envId (environment identifier → the system highlights this field and prompts: "The environment information of the tested system is a required field, used to determine the deployment target.") The user did not select the "Comparison Type" (JSON / XML / Text) in the "Assertion Component" → the system prompts: "Please select the data comparison format, otherwise the comparison logic cannot be executed." The user filled in the response in the "Mock Simulation" component but did not fill in the type (e.g., redis or rpc) → the system automatically infers failure and prompts: "The simulation type must be explicitly specified to match the interception rules."

[0118] In this embodiment, after generating the graphical playback flowchart and its corresponding configuration data, the system automatically performs four checks on the flowchart's structural integrity, component composition compliance, connection logic correctness, and parameter configuration completeness: First, it checks for isolated components that have not established data flow with any other components, ensuring that all components participate in the process execution; second, it verifies whether the flowchart simultaneously includes trigger components, data source components, transmitter components, and application components, ensuring that the playback process has complete event triggering, data acquisition, transmission processing, and business execution capabilities; and then it analyzes whether the direction of the connection lines between components conforms to the data flow. The semantic logic of the flow is checked to avoid structural errors such as circular dependencies, reversed directions, or broken circuits. Finally, the configuration parameters of each component are verified to ensure they are complete and valid, preventing execution anomalies due to missing key fields. Only when all four verification results pass is the overall flowchart considered executable, and it is allowed to be packaged with configuration data into a standardized software test replay scheme. This effectively avoids the risk of scheme failure due to structural incompleteness, incomplete composition, logical errors, or missing parameters, achieving comprehensive quality control of the replay scheme before packaging, and significantly improving the stability, reproducibility, and engineering usability of test replay.

[0119] A specific scenario for verifying a solution: 1. Verify the existence of isolated components. The solution should not contain isolated components, such as those without downstream data flow or related components. 2. Verify the absence of missing components. Essential components in the solution include: [Trigger], [Data Source], [Transmitter], and [Application]. 3. Verify the compatibility of components and data flow. Components in the solution have certain constraints, such as: [Trigger] must be located at the start node of the solution, and [Transmitter] should be associated with [Application]. 4. Verify the absence of required parameters for components, such as: incomplete basic information settings for the [Application] component, missing environment information, etc. 5. Verify error message prompts. Details of missing components, component compatibility issues, or parameter verification problems can be viewed in the [Alarm] section of the [Panel Menu]. Once the verification problem is resolved, the alarm message will disappear.

[0120] Step S104: Encapsulate all configuration data and playback flowcharts into a software test playback scheme, and save the software test playback scheme to the playback system and / or scheme template library.

[0121] It should be noted that the topology (nodes, connections, hierarchical relationships) and parameter configurations of all components are uniformly serialized into standardized JSON format metadata, forming a complete solution description file. Its structure includes: nodes: ID, type, position, and attributes (such as component type, plugin ID, version) of all component nodes; edges: data flow relationships between components (source-target connections); params: structured parameter objects corresponding to each node, strictly bound to the node ID; metadata: metadata such as solution name, creator, template source, and creation time. The above data structure has integrity constraints: nodes cannot be isolated (without upstream or downstream connections), component types must match, and required parameters cannot be missing.

[0122] Furthermore, the solution storage is divided into two paths: System runtime environment: The solution is persisted to the solution definition table in the database, and its associated component configuration information is stored in the component configuration table, which is used by the playback engine to load and execute by ID; Solution template library: Users can mark the current solution as a template and save it to the template library, so that other users can reuse it through the initialization steps, realizing "design once, reuse N times".

[0123] In this embodiment, all configuration data and replay flowcharts are first encapsulated into a unified software test replay scheme to ensure that all parameter settings, component connection relationships and data flow information required for replay are fully integrated into a structured whole. Then, the encapsulated scheme is saved to the replay system for execution or to the scheme template library for subsequent reuse, thereby realizing persistent storage and centralized management of the replay scheme and ensuring the consistency and traceability of the scheme in different execution environments or reusable scenarios.

[0124] Furthermore, the steps of encapsulating all configuration data and replay flowcharts into a software test replay scheme include: encoding the node topology and connection relationships of the replay flowchart into graph structure data, wherein the graph structure data contains the node ID, connection edge ID, and connection direction of all components; classifying and aggregating all configuration data to obtain a configuration data set; merging the graph structure data and the configuration data set into a unified JSON format file, wherein the JSON format file contains process fields and configuration fields, the process fields storing the flowchart structure, and the configuration fields storing the configuration information of each component; generating a scheme ID for the JSON format file, and binding the scheme ID to the JSON format file to generate the software test replay scheme.

[0125] It should be noted that in the step of encoding the flowchart into graph structure data (node ​​topology and connection relationships), the components in the visualization canvas are "nodes," and the connections between components are "directed edges." The system needs to convert these graphical elements into a computer-processable graph data structure, retaining key information such as node identity, connection direction, and edge semantics. In the step of classifying and aggregating configuration data to form a configuration data set, the parameter configuration of each component is stored independently. Aggregation should be performed using the component ID as the key to avoid separating configuration from the process, achieving decoupling but strong correlation between the process and configuration.

[0126] The steps of merging into a unified JSON format file and separating process and configuration fields decouple the process structure and configuration data into two logical domains, achieving decoupling of structure and semantics. This facilitates: process reuse (same structure, different configurations); configuration portability (same configuration, different environments); and version management (changing only the configuration, without needing to re-save the process). A scheme ID is generated and bound to form the final replay scheme. A globally unique identifier (Scheme ID) is generated for each scheme, serving as its "digital identity card" in the system for: storage, querying, version control; execution scheduling, log tracking, and access control; and integration with the test engine and reporting system.

[0127] In this embodiment, the node topology and connection relationships of the graphical playback flowchart constructed by drag-and-drop components in the visual process canvas are encoded into graph structure data containing node IDs, connection edge IDs, and connection directions. The structured parameter configuration results of each component are classified and aggregated to form a configuration data set. The two are then merged into a unified JSON format file. The process field accurately carries the structural information of the graphical process, and the configuration field completely stores the parameter configuration content of each component, thereby achieving the organic integration and standardized encapsulation of graphical design and structured data. At the same time, a unique scheme ID is generated for this JSON file and bound to it, so that the entire playback scheme has a unified data carrier that can be parsed, stored, and reused across environments. This solves the technical problems of the original scheme where the graphical process and configuration information are scattered and lack standardized encapsulation, resulting in unreliable access and reuse. It realizes the systematic management and efficient reuse of the software test playback scheme, and significantly improves the maintainability and automation level of the test process.

[0128] Through the above steps S101 to S104, an initialization replay template can be selected from the preset scheme template library according to the software testing requirements, and the initialization replay template can be loaded into the visual design interface to obtain the initial process canvas. Then, according to the software testing requirements, a target component can be selected from the preset abstract component library, and the target component can be dragged and dropped to the target position in the initial process canvas to form a graphical replay flowchart with data flow between components. Then, based on the software testing requirements, the structured parameters of each component in the replay flowchart are configured to generate configuration data corresponding to each component. Finally, all configuration data and replay flowchart are encapsulated into a software test replay scheme, and the software test replay scheme is saved to the replay system and / or scheme template library.

[0129] In this embodiment of the invention, a graphical drag-and-drop and component-based orchestration approach is adopted. By decoupling the replay function and initializing the process canvas based on a preset template, creating a graphical replay flowchart with a clear data flow direction, and establishing a structured configuration of parameter configurations and graphical nodes for each component, the fragmented and text-based replay configuration is transformed into a visually expressible, dynamically adjustable, and fully reusable entity. This achieves a systematic transformation of the replay scheme from discrete parameter configuration to a structured, visual, and component-based object. Furthermore, it solves the technical problem in related technologies where software test replay schemes are mostly expressed in discrete configuration files or code, lacking structured, visual, and component-based abstraction of the test process, resulting in poor reusability of the replay process. This method realistically maps the business link through a visual canvas, allowing testers to build the replay process according to business intent without understanding the underlying protocol or configuration syntax. This significantly improves the efficiency and consistency of scheme design and provides a solution for automated testing in complex microservice environments.

[0130] The present invention will now be described in conjunction with another specific embodiment.

[0131] This invention also proposes a visual design method and system for software test replay schemes, aiming to solve the core problems of traditional replay schemes, such as poor understandability, low scalability, poor reusability, and high maintenance costs. The visual replay scheme can intuitively present the replay process, information of the application under test, related systems, and mock processing involved in the replay. It can dynamically adjust and adapt the scheme to meet the personalized needs of users, significantly improving the testing efficiency of replay. The system architecture consists of several core modules: a visual scheme designer, a scheme management module, and a component management module. The visual panel is mainly responsible for the drawing, configuration, and presentation of the scheme; the scheme management module is responsible for the parsing, verification, querying, template management, and storage of the scheme; the component management module provides replay component uploading, status management, scheduling execution, and component parameter configuration storage.

[0132] Specifically, the visual solution designer is the core module of this system, responsible for managing the component pool, visual orchestration of solutions, component parameter configuration and validation, etc. The component pool provides the basic components required for replay solution design, divided into seven categories: triggers, data sources, data processing, transmitters, applications, MOCK, and assertions. Among them, triggers provide replay strategy control, including triggering methods, timeout durations, and serial / parallel control; data sources support access and collection of multiple types of replay data, including test case files, test case collection, and test case libraries; data processing provides format conversion, data mapping, extraction, and encoding / decoding of replay data; applications are the targets of replay testing, such as microservices; transmitters are the scheduling methods for applications, including RPC and message queues; MOCK provides the ability to intercept and simulate sub-calls of applications, including Redis, MyBatis, MyBatis-Plus, RPC, message queues, Encache, and JDBC; assertions are the ability to compare replay results, including JSON, XML, and text comparison. Based on playback requirements, users can combine components as needed and complete the component relationships and parameter configurations to achieve visual orchestration and process definition of the solution.

[0133] The solution management module provides backend parsing, querying, verification, template management, and storage capabilities for solutions. Its functions include solution integrity and component matching verification to ensure solution reliability; it provides solution querying, parsing, and storage capabilities for the visual designer; and it provides different types of solution templates to enable the rapid creation and reuse of replay solutions. Template types include blank, use case, link, scenario, and comparison-only, which can meet the needs of replay solution creation for different business scenarios.

[0134] The component management module provides backend management and scheduling capabilities for components, including component contract customization, component querying, component updating, state synchronization, and scheduled execution. Based on a component-centric approach, this module fully decouples the original replay system, forming seven major component contracts: triggers, data sources, data processing, applications, transmitters, mocks, and assertions. Developers can flexibly extend corresponding business components based on these contracts. Furthermore, considering the different behaviors and attributes of various components, component contracts are further subdivided into two categories: configuration and scheduling. Configuration components only provide replay configuration data and have no actual behavior, such as triggers, data sources, and applications. Scheduling components, while possessing replay data configuration capabilities, also have corresponding abstract behaviors, such as data processing, transmitters, mocks, and assertions.

[0135] Figure 2 This is a visual design flowchart of an optional software test replay scheme according to an embodiment of the present invention, such as... Figure 2As shown, the software flow indicated by the above system includes four main steps: playback scheme initialization, scheme improvement, scheme verification, and scheme storage. In the scheme initialization phase, users can quickly create schemes by reusing playback templates, simplifying the creation process and improving efficiency. In the scheme improvement phase, the focus is on refining component pairings and parameters. Users drag and drop components from the component pool based on actual playback needs to complete component pairings and configure component parameters, such as triggers, data sources, transmitters, applications, simulators, and comparisons. If the currently reused scheme template meets the playback requirements, parameters can be directly improved. In the scheme verification phase, the completeness of the scheme, the compatibility between components, and the completeness of component parameters are verified. In the scheme storage phase, the data structure and component-related parameters of the scheme are stored. Through this process, playback schemes can be created quickly and visually, significantly improving creation efficiency.

[0136] Further as Figure 3 As shown, Figure 3 This is a visual design architecture diagram of an optional software test replay scheme according to an embodiment of the present invention, which can be described in detail from the following steps:

[0137] S301 initializes solutions by reusing solution templates in solution management. The system has built-in templates of various types to meet the playback needs of different users, such as blank templates, test case playback templates, link playback templates, scenario playback templates, and comparison-only templates. Users can preview solution templates; if no suitable template is found, a blank template can be used to create one.

[0138] S302 refines the initialized solution. After solution initialization, the solution visual design console is accessed. The console consists of four parts: [Component Pool], [Solution Design Panel], [Panel Menu], and [Panel Controls]. The component pool is a high-level abstraction of the replay business, forming an extensible component contract and containing a rich set of built-in business components. Users can select the corresponding components from the component pool according to the actual replay scenario and refine them in the solution by dragging and dropping, such as application sub-call interception and simulation component mounting. The replay data flow is shown between components through connections and arrows. Application components are presented as container components, which can realistically reflect the master and sub-call processes involved. Each component has highly abstracted component parameters, which need to be filled in according to the actual replay scenario, such as: test case tag information in the test case library, application configuration information (environment, interface, method), application master and sub-call information (sub-call configuration, interception and simulation information configuration, etc.), assertion rule configuration, etc. Users can adjust the presentation position of the solution in the solution design panel as needed, or adjust it adaptively through the panel menu. The improved solution's JSON format metadata will not be elaborated here.

[0139] S303, Solution Completeness and Integrity Verification. To ensure the effectiveness of the solution, the compatibility of components and the completeness of component parameters need to be verified; the components in the solution must be complete, and according to the solution type, a component integrity check should be performed to confirm whether any components are missing; there should be no isolated components in the solution; the required parameters of components need to be verified, and the combination between components should be reasonable, such as the data flow of the transmitter should be to the application, etc.; relevant verification prompts can be dynamically displayed in the visual panel alarm menu.

[0140] S304, Solution Saved. The solution data structure is in JSON format, and the data flow and solution composition are visualized in a flow-like format. The flow records in detail the components involved and their parameter configurations. Users can also set the solution as a template for easy and quick reuse later.

[0141] This implementation method selects an initial replay template from a pre-set solution template library based on software testing requirements and loads it into a visual design interface to form an initial process canvas. Then, by dragging and dropping, target components are selected from an abstract component library and deployed to designated locations on the canvas, constructing a graphical replay flowchart with clear data flow between components. This allows testers to intuitively identify the functional roles and data interaction paths of each component. Based on this, structured parameter configuration is performed on each component in the flowchart, generating precisely corresponding configuration data. All graphical processes and configuration data are then uniformly encapsulated into a complete software test replay solution, which is ultimately saved to the replay system or template library for reuse. Through graphical drag-and-drop and visual representation of data flow, the inefficient traditional method relying on textual and discrete configuration forms is completely eliminated. This significantly improves the readability, programmability, and traceability of the replay solution, effectively solving the technical problems of existing replay solutions lacking visual programmability and difficulty in intuitively expressing component relationships and data flow. It achieves efficient design, accurate configuration, and convenient reuse of the test process, greatly improving the efficiency and accuracy of software test replay.

[0142] The invention will now be described in conjunction with another alternative embodiment.

[0143] Example 2

[0144] The software test playback scheme generation device provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in Embodiment 1 above.

[0145] Figure 4 This is a schematic diagram of an optional software test replay scheme generation apparatus according to an embodiment of the present invention, such as... Figure 4 As shown, the device may include: a selection unit 41, a drag-and-drop unit 42, a configuration unit 43, and a packaging unit 44.

[0146] Among them, the selection unit 41 is used to select an initialization replay template from the preset scheme template library according to the software testing requirements, and load the initialization replay template into the visual design interface to obtain the initial process canvas.

[0147] The drag-and-drop unit 42 is used to select a target component from a preset abstract component library according to software testing requirements, and drag the target component to the target position in the initial process canvas to form a graphical playback flowchart with data flow between components.

[0148] Configuration unit 43 is used to configure the structured parameters of each component in the playback flowchart based on software testing requirements, and generate configuration data corresponding to each component.

[0149] The encapsulation unit 44 is used to encapsulate all configuration data and playback flowcharts into a software test playback scheme, and save the software test playback scheme to the playback system and / or scheme template library.

[0150] The above-mentioned software test replay scheme generation device can first select an initialization replay template from a preset scheme template library according to the software test requirements through the selection unit 41, and load the initialization replay template into the visual design interface to obtain an initial process canvas. Then, through the drag and drop unit 42, select a target component from a preset abstract component library according to the software test requirements, and drag the target component to the target position in the initial process canvas to form a graphical replay flowchart with data flow between components. Then, through the configuration unit 43, perform structured parameter configuration on each component in the replay flowchart based on the software test requirements to generate configuration data corresponding to each component. Finally, through the encapsulation unit 44, encapsulate all configuration data and replay flowchart into a software test replay scheme, and save the software test replay scheme to the replay system and / or scheme template library.

[0151] In this embodiment of the invention, a graphical drag-and-drop and component-based orchestration approach is adopted. By decoupling the replay function and initializing the process canvas based on a preset template, creating a graphical replay flowchart with a clear data flow direction, and establishing a structured configuration of parameter configurations and graphical nodes for each component, the original fragmented and textual replay configuration is transformed into a visual solution entity that can be intuitively expressed, dynamically adjusted, and fully reused. This achieves the technical effect of a systematic transformation of the replay solution from discrete parameter configuration to a structured, visual, and component-based object. Furthermore, it solves the technical problem in related technologies where software test replay solutions are mostly expressed in the form of discrete configuration files or code, lacking a structured, visual, and component-based abstraction of the test process, resulting in poor reusability of the replay process. This method uses a visual canvas to realistically map the business link, allowing testers to build the replay process according to business intent in a "building block" manner without understanding the underlying protocol or configuration syntax. This significantly improves the efficiency and consistency of solution design and provides a solution for automated testing in complex microservice environments.

[0152] The above-mentioned software test playback scheme generation device may also include a processor and a memory. The selection unit 41, drag-and-drop unit 42, configuration unit 43, packaging unit 44, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize the corresponding functions.

[0153] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, an initialization replay template is selected from a pre-defined scheme template library based on software testing requirements. This initialization replay template is then loaded into the visual design interface to obtain an initial flow canvas. Based on software testing requirements, target components are selected from a pre-defined abstract component library and dragged to their target positions on the initial flow canvas, forming a graphical replay flowchart with data flow between components. Structured parameter configurations are performed on each component in the replay flowchart based on software testing requirements, generating configuration data corresponding to each component. All configuration data and the replay flowchart are encapsulated into a software test replay scheme, and the software test replay scheme is saved to the replay system and / or scheme template library.

[0154] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0155] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: Based on software testing requirements, selecting an initialization replay template from a preset scheme template library and loading the initialization replay template into a visual design interface to obtain an initial flow canvas; based on software testing requirements, selecting a target component from a preset abstract component library and dragging the target component to the target position in the initial flow canvas to form a graphical replay flowchart with data flow between components; configuring structured parameters for each component in the replay flowchart based on software testing requirements to generate configuration data corresponding to each component; encapsulating all configuration data and the replay flowchart into a software test replay scheme and saving the software test replay scheme to the replay system and / or scheme template library.

[0156] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to execute the software test playback scheme generation method of any one of the above embodiments.

[0157] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the software test playback scheme generation method of any one of the above embodiments.

[0158] Figure 5 This is a structural block diagram of an electronic device for generating a software test playback scheme according to an embodiment of the present invention, such as... Figure 5 As shown, the electronic device may include: one or more ( Figure 5 (Only one is shown) processor 502, memory 504, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0159] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the software test playback scheme generation method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the above-mentioned software test playback scheme generation method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0160] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 5 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

[0161] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0162] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0163] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0164] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0165] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0166] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0167] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0168] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method of generating a software test playback scenario, characterized by, include: Based on the software testing requirements, an initialization replay template is selected from the preset solution template library, and the initialization replay template is loaded into the visual design interface to obtain the initial process canvas; According to the software testing requirements, a target component is selected from the preset abstract component library, and the target component is dragged and dropped to the target position in the initial process canvas to form a graphical playback flowchart with data flow between components; Based on the software testing requirements, structured parameter configurations are performed on each component in the playback flowchart to generate configuration data corresponding to each component. All the configuration data and the playback flowchart are encapsulated into a software test playback scheme, and the software test playback scheme is saved to the playback system and / or the scheme template library.

2. The method of claim 1, wherein, The preset abstract component library includes: trigger components, data source components, transmitter components, application components, Mock components, assertion components, and data processing components; The trigger component controls the playback triggering method, the data source component provides playback data, the transmitter component schedules the system under test, the application component defines the target software under test, the Mock component intercepts and simulates sub-call responses, the assertion component compares the playback response results, and the data processing component performs data format conversion and encoding / decoding.

3. The method of claim 2, wherein, According to the software testing requirements, the steps of selecting a target component from a preset abstract component library and dragging the target component to the target position in the initial process canvas to form a graphical playback flowchart with data flow between components include: Drag the trigger component to the starting position of the initial process canvas, drag the data source component downstream of the trigger component, and establish a one-way connection line from the trigger component to the data source component; Drag the transmitter component downstream of the data source component and establish a one-way connection from the data source component to the transmitter component; Drag the application component downstream of the transmitter component and establish a one-way connection from the transmitter component to the application component; Drag the assertion component downstream of the application component and establish a one-way connection from the application component to the assertion component.

4. The method of claim 2, wherein, The steps of configuring structured parameters for each component in the playback flowchart based on the software testing requirements, and generating configuration data corresponding to each component, include: Based on the software testing requirements, set the replay trigger timing and execution strategy for the trigger component, and set the data collection identifier or data source path for the data source component; Based on the software testing requirements, set the target system call method and communication parameters for the transmitter component, and set the tested system environment information, main call interface information and sub-call interception configuration for the application component. If the replay flowchart includes a Mock component, set request matching rules and response simulation content for the Mock component according to the software testing requirements; If the assertion component is included in the replay flowchart, set the result comparison logic and comparison data type for the assertion component according to the software testing requirements; If the playback flowchart includes the data processing component, set the data conversion method and encoding rules for the data processing component according to the software testing requirements.

5. The method of claim 1, wherein, Before encapsulating all the configuration data and the playback flowchart into a software test playback scheme, the method further includes: The configuration data and the playback flowchart are validated to obtain the validation results; If the verification result is satisfactory, encapsulation is allowed; otherwise, a verification error message is sent to the visual design interface.

6. The method of claim 1, wherein, The steps of performing verification on the configuration data and the playback flowchart to obtain the verification result include: Verify whether there are isolated components in the playback flowchart to obtain the first verification result; Verify whether the playback flowchart contains at least a trigger component, a data source component, a transmitter component, and an application component to obtain a second verification sub-result; Verify whether there are logical conflicts in the connection lines of each component in the playback flowchart, and obtain the third verification result; Verify whether the configuration data of each component in the playback flowchart is complete, and obtain the fourth verification sub-result; If all validation sub-results are found to be passed, the validation result is set to pass; otherwise, it is set to fail.

7. The method for generating a software test replay scheme according to claim 1, characterized in that, The steps of encapsulating all the configuration data and the playback flowchart into a software test playback scheme include: The node topology and connection relationships of the playback flowchart are encoded into graph structure data, wherein the graph structure data includes the node ID, connection edge ID and connection direction of all components; All the configuration data are categorized and aggregated to obtain a configuration data set; The graph structure data and the configuration data set are merged into a unified JSON format file, wherein the JSON format file contains process fields and configuration fields, the process fields store the flowchart structure, and the configuration fields store the configuration information of each component; Generate a scheme ID for the JSON format file, and bind the scheme ID to the JSON format file to generate the software test playback scheme.

8. A device for generating a software test playback scheme, characterized in that, include: The selection unit is used to select an initialization replay template from a preset solution template library according to software testing requirements, and load the initialization replay template into the visual design interface to obtain the initial process canvas. The drag-and-drop unit is used to select a target component from a preset abstract component library according to the software testing requirements, and drag the target component to the target position in the initial process canvas to form a graphical playback flowchart with data flow between components. The configuration unit is used to configure the structured parameters of each component in the playback flowchart based on the software testing requirements, and generate configuration data corresponding to each component. The encapsulation unit is used to encapsulate all the configuration data and the playback flowchart into a software test playback scheme, and save the software test playback scheme to the playback system and / or the scheme template library.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the method for generating a software test playback scheme according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method for generating a software test playback scheme according to any one of claims 1 to 7.

Images