A method of automated testing software without coding

Abstract

The application discloses a kind of methods of no coding automation test software, belong to the technical field of automation testing, including execution flow chart drawing, node attribute configuration, edge attribute configuration, component configuration item test, flow configuration test, flow data test etc.Step.The application is verified by building constraint rule base with component type as index key to prepositive regular configuration item, and the mapping relationship of global unique identifier and execution method is established at edge and component level to reflect driving flow automatic operation, solve the problem of long development cycle and high labor cost caused by traditional software testing needs to write test script line by line;By setting data flow log containing input and output data snapshot at the end of each edge and component, and establishing the difference degree comparison and type consistency checking mechanism of upstream node output and current node input, the problem that traditional test log can only record as a whole and cannot locate specific node level data anomaly is solved.

Description

Technical Field

[0001] This invention belongs to the field of automated testing technology, specifically relating to a method for code-free automated testing software. Background Technology

[0002] As software systems become increasingly complex, software testing is playing a crucial role in ensuring system quality. Currently, script-based automated testing is the mainstream solution. However, due to the complexity of system functions and the semantic differences in component configurations, script development inevitably contains configuration errors and logical vulnerabilities. These errors propagate through the cascading testing process. If component configurations and data transmission are not effectively verified and tracked, test conclusions may be distorted or even critical defects may be missed, thus posing a potential risk to software quality.

[0003] To improve testing efficiency, researchers introduced visual process configuration and component-based assembly techniques. However, existing no-code testing methods still have several limitations; for example, they lack an automatic verification mechanism for component configuration items, making it difficult to intercept configuration errors in the early stages; secondly, existing test logs mostly focus on the overall execution results and fail to provide snapshots of data transfer at the edge and component levels, making it difficult to locate data anomalies; furthermore, existing methods are usually designed for testing a single flowchart, while data dependencies and parallel interference between multiple flowcharts in the user instance interface will affect the overall test results.

[0004] There is a lack of a no-code automated testing method in the existing technology that can achieve automatic configuration verification, node-level data tracing, and multi-flowchart collaborative testing without writing test code. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention aims to provide a method for no-code automated testing software. This method solves the problems of long development cycles and high labor costs caused by the need to write test scripts line by line in traditional software testing; it also solves the problem that traditional test logs can only record the overall data and cannot pinpoint specific node-level anomalies; and it resolves the issues of data interference and chaotic dependencies when multiple flowcharts are running collaboratively in the user instance interface. The specific solution is as follows: This application provides a method for no-code automated testing software, including the following steps: Draw the execution flowchart in the configuration interface and generate connecting edges between nodes that have control relationships; Configure the node attributes of each node, bind the component to the node and configure the basic and extended attributes of the component to obtain the node attribute data; Configure the edge attributes of each side, set the triggering event, data transmission and execution method of the edge, and obtain the edge attribute data; Set constraint rules for each configuration item of the component, obtain the configuration value of the configuration item and validate it through regular expressions to obtain the validated component configuration data; Based on the verified component configuration data, globally unique identifiers are set for the events and behaviors of edges and components. The corresponding execution methods are reflected and run according to the globally unique identifiers to obtain the execution results of the edges and components that have passed the execution. Based on the execution results of the edges and components that have passed the test, a data flow log is set at the end of each edge and component and the process execution data is recorded to obtain the process execution data log. Based on the process execution data logs, an overall test was performed on all execution flowcharts to obtain the software's no-code automated test results.

[0006] In one embodiment, an execution flowchart is drawn in the configuration interface, and connection edges are generated between nodes with control relationships, including: The configuration interface includes a flowchart drawing window, a node addition window, a property configuration window, and a debugging information window; The node addition window contains the nodes needed to draw the execution flowchart, and each node is bound to a mouse drag event; Bind click and mouse drag events to the edges of each node. When the edge of a node is clicked and dragged with the mouse, an edge pointing to the next node is generated along the direction of the mouse drag. When the edge of the next node is touched and the mouse is released to stop dragging, an edge connecting the first node to the next node is generated.

[0007] In one embodiment, node attributes are configured for each node, components are bound to the nodes, and the basic and extended attributes of the components are configured to obtain node attribute data, including: When a node is selected by clicking with the mouse, the attribute configuration window displays the attribute configuration options for that node; To bind a node to a component, configure the basic attributes of the bound component and the extended attributes defined according to the needs of the component, and obtain the node attribute data.

[0008] In one embodiment, edge attributes are configured for each side, and triggering events, data transmission, and execution methods for each edge are set to obtain edge attribute data, including: When an edge is selected by clicking the mouse, the attribute configuration window displays the attribute configuration options for that edge; Set the trigger event of the previous node of the edge, the data to be transmitted from the previous node to the next node, and the execution method of the next node to obtain the edge attribute data; The node attribute data and edge attribute data are encapsulated into a preset data format and saved to a database table. The required data is retrieved from the database table according to the control flow of the execution flowchart, the rule attributes configured in the node or edge are parsed, and the corresponding actions are executed according to the parsed rule attributes.

[0009] In one embodiment, constraint rules are set for each configuration item of the component, the configuration value of the configuration item is obtained and validated using a regular expression to obtain the validated component configuration data, including: Constraint rules are set for each configuration item and stored in the constraint rule library. The constraint rule library uses the component type as the index key. Each component type corresponds to a set of configuration item constraint entries. Each configuration item constraint entry includes the configuration item name, regular expression pattern, error message, and severity level. The regular expression pattern is used to limit the data type, value range, and format specifications of the configuration value. The configuration value of the configuration item is obtained and the corresponding constraint rule is retrieved from the constraint rule library. The regular expression engine is used to determine whether the configuration value conforms to the constraint rule. If the verification is successful, the component is marked as verified. If it is not successful, a differentiated error message is generated based on the severity level and displayed in the debug information window. At the same time, the component is blocked from entering the subsequent testing process until all configuration items pass the verification and the verified component configuration data is obtained.

[0010] In one embodiment, the regular expression pattern is used to limit the data type, value range, and format specifications of the configuration value, including: For the connection address configuration item, the corresponding regular expression pattern ensures that the connection address conforms to the standard connection format; For the color configuration item, the corresponding regular expression pattern limits the color value to the standard color code format; For the event type configuration item, the corresponding regular expression pattern limits the event type to one of the predefined enumeration values.

[0011] In one embodiment, based on the verified component configuration data, globally unique identifiers are set for the events and behaviors of edges and components. The corresponding execution methods are reflected and run according to these globally unique identifiers to obtain the execution results of the successfully executed edges and components, including: Set globally unique identifiers for events and behaviors of edges and components, and establish a correspondence between globally unique identifiers and execution methods; When executing any side or component, retrieve the corresponding execution method based on the globally unique identifier and run it. If the execution passes, proceed to the execution method of the next edge or component, until all edges and components in the execution flowchart have been executed. If the run fails, an error message will be generated and displayed to prompt the definer to make modifications.

[0012] In one embodiment, retrieving and running the corresponding execution method based on a globally unique identifier includes: If the execution method does not throw an exception during execution and the return value is of the expected type, the current edge or component will be automatically marked as successful and the execution method of the next edge or component will be executed. If the process fails, an error record containing a globally unique identifier and the name of the executed method is generated. The error record is displayed in the debug information window, and the corresponding edge or component is highlighted in the flowchart drawing window to quickly locate the faulty node.

[0013] In one embodiment, based on the execution results of the edges and components that have passed the process, a data flow log is set at the end of each edge and component to record the process execution data, resulting in a process execution data log, including: Set a data flow log at the end of each edge and component. The data flow log records the globally unique identifier of the current edge or component, the globally unique identifier of the upstream node, the globally unique identifier of the downstream node, the input data snapshot, the output data snapshot, and the execution status code. When running the execution flowchart, the input data snapshot and output data snapshot of the edge or component are extracted in real time and written to the data flow log at the end of the edge or component; By comparing the output data snapshot of the upstream node with the input data snapshot of the current node, it is determined whether the data was lost, tampered with, or mismatched in type during edge transmission. Based on this, the transmission data type configuration or transmission data field mapping configuration is corrected to obtain the process running data log.

[0014] In one embodiment, an overall test is performed on all execution flowcharts based on process execution data logs to obtain software no-code automated test results, including: According to the calling dependencies of each execution flowchart in the user instance interface, each execution flowchart is executed in sequence. The output data of the previous execution flowchart is used as the input data of the next execution flowchart. The data transmission link across flowcharts is tracked through the data flow log to verify the data consistency when multiple execution flowcharts run in collaboration. Simultaneously, multiple independent execution flowcharts in the user instance interface are triggered, parallel execution threads are allocated, and the running data of each execution flowchart is isolated by a globally unique identifier to prevent data interference during parallel testing. After the test is completed, the data flow logs of each execution flowchart are summarized to generate an overall test report. The overall test report includes the execution pass rate, error distribution statistics, data transmission accuracy and test coverage of each execution flowchart, and obtains the software no-code automated test results. Beneficial effects

[0015] (1) This invention performs pre-regular verification of configuration items by constructing a constraint rule library with component type as the index key, and establishes a mapping relationship between globally unique identifiers and execution methods at the edge and component level to drive the automatic operation of the process through reflection. This solves the problem of long development cycle and high manpower cost caused by the need to write test scripts line by line in traditional software testing, and realizes a no-code test closed loop that can perform automated and comprehensive testing of complex software systems without coding. (2) By setting a data flow log containing snapshots of input and output data at the end of each side and component, and establishing a mechanism for comparing the difference between the output of the upstream node and the input of the current node and verifying the consistency of the type, this invention solves the problem that traditional test logs can only record the whole and cannot locate specific node-level data anomalies, and realizes node-by-node tracking and rapid correction of defects such as loss, tampering or type mismatch during data transmission. (3) This invention verifies the data consistency between multiple execution flowcharts by using serial testing based on the calling dependency relationship, and allocates parallel execution threads through parallel testing to isolate the running context of each process. This solves the problem of data interference and chaotic dependency relationship when multiple flowcharts are running in collaboration in the user instance interface, and realizes the orderly scheduling of overall coverage testing and parallel testing resources for complex user instance interfaces. Attached Figure Description

[0016] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, and the advantages of the present invention in the above and / or other aspects will become clearer.

[0017] Figure 1 The process architecture diagram provided for this invention; Figure 2 The configuration interface and execution flowchart provided for this invention; Figure 3 The node attribute configuration and component structure diagram provided by this invention; Figure 4 This invention provides an edge attribute configuration and data encapsulation diagram; Figure 5 The component configuration item test and microcontroller collaborative working diagram provided by the present invention; Figure 6 A diagram illustrating the process configuration test reflection execution mechanism provided by this invention; Figure 7 This invention provides a schematic diagram of the process data test log tracking principle. Figure 8 This is a diagram illustrating the overall test strategy for user interface testing provided by the present invention. Detailed Implementation

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

[0019] This invention provides a method for no-code automated testing software, which includes steps one through seven, sequentially implementing the following steps: drawing the execution flowchart, configuring node attributes, configuring edge attributes, testing component configuration items, testing process configuration, testing process data, and testing the user instance interface. The specific implementation methods of each step are described in detail below with reference to the embodiments.

[0020] refer to Figure 1 This document presents a flowchart illustrating the method for the no-code automated testing software provided in Embodiment 1. The method includes steps one through seven, with each step working together to achieve the complete functions of process drawing, configuration verification, process execution, data tracking, and overall testing. The specific implementation method is as follows.

[0021] Step 1: Draw the execution flowchart in the configuration interface and generate connecting edges between nodes that have control relationships.

[0022] The configuration interface includes a flowchart drawing window, a node addition window, a property configuration window, and a debugging information window. The node addition window contains the nodes needed to draw the execution flowchart, and each node is bound to a mouse drag event. Click selection events and mouse drag events are bound to the edges of each node. When the edge of a node is clicked and dragged with the mouse, an edge pointing to the next node is generated along the direction of the mouse drag. When the edge of the next node is touched and the mouse is released to stop dragging, an edge connecting the first node to the next node is generated.

[0023] It should be noted that the node types in the node addition window include control component nodes and data source component nodes. The two types of nodes are distinguished by different icon shapes to avoid confusion for operators. The edge drawing method adopts an edge sensing mechanism. When the distance between the mouse drag trajectory and the edge of the next node is less than a preset pixel threshold, it automatically snaps to and generates a connecting edge to ensure the accuracy of the connection between the edge and the node.

[0024] refer to Figure 2 The diagram illustrates the configuration interface and the workflow of drawing the execution flowchart: the operator selects a node from the node addition window and drags it to the flowchart drawing window, generating connecting edges through the edge sensing mechanism to form a complete execution flowchart structure.

[0025] Step 2: Configure the node attributes of each node, bind the component to the node and configure the basic and extended attributes of the component to obtain the node attribute data.

[0026] When a node is selected by clicking the mouse, the property configuration window displays the node's property configuration options. You can bind a component to the node, configuring the basic properties of the bound component and the extended properties defined according to the component's usage needs, thus obtaining the node's property data. Basic properties cover the component identifier, data storage method, and data output method; extended properties cover the color, size, and position of the control component, or the data source type and connection parameters of the data source component.

[0027] The components bound to nodes include control components and data source components. Control components include rule object units, component event units, component behavior units, output data units, and state units. The rule object unit provides attribute configuration options for the control component, converts these options into an XML file, and saves them. These attribute configuration options are used by business definition personnel to configure the control component's attributes. The component event unit provides action configuration options that the control component can recognize. These action configuration options are used by business definition personnel to configure actions. The component behavior unit provides task configuration options for the control component to execute. These task configuration options are used by business definition personnel to configure tasks. When the action configured in the component event unit is triggered, the task configured in the component behavior unit is executed. The output data unit provides the data to be output by the control component and output configuration options. These output configuration options are used by business definition personnel to configure the data output method. The state unit provides state configuration options for the control component. By configuring the above units, business definition personnel can achieve custom development of the control components; that is, the functionality of the control components can be customized according to the needs of software development. The data source component includes input units, function units, and output units. The input unit is responsible for receiving data or extracting the required data from the received data according to the receiving rules configured by business personnel. The functional unit parses the data processing function configured by the business personnel, generates corresponding computer code, and then runs the computer code to obtain the data processing result. The output unit extracts the data processing result and then transmits it according to the calling command.

[0028] refer to Figure 3 This demonstrates the working logic of node attribute configuration and component structure: after selecting a node, the component type is bound, the attribute configuration window dynamically loads the attribute configuration options of the component bound to the node, and the node attribute data is obtained after the configuration is completed.

[0029] Step 3: Configure the edge attributes of each side, set the edge triggering events, data transmission and execution methods, and obtain the edge attribute data.

[0030] When an edge is selected by clicking the mouse, the attribute configuration window displays the attribute configuration options for that edge. You can set the trigger event of the edge's previous node, the data to be passed from the previous node to the next node, and the execution method of the next node to obtain the edge's attribute data.

[0031] The node attribute data and edge attribute data are encapsulated into a preset data format and saved to a database table to obtain the process configuration data. Based on the control flow of the execution flowchart, the required data is retrieved from the database table, the rule attributes configured in the nodes or edges are parsed, and the corresponding actions are executed based on the parsed rule attributes.

[0032] refer to Figure 4 This demonstrates the working logic of edge attribute configuration and data encapsulation: after selecting an edge, the system configures the trigger event, transmits data, and executes the method. The system encapsulates the node attribute data and edge attribute data into JSON format and persists them to a database table for subsequent testing.

[0033] Step 4: Set constraint rules for each configuration item of the component, obtain the configuration value of the configuration item and verify it through regular expressions to obtain the verified component configuration data.

[0034] It should be noted that if the value range and format specifications of component configuration items are not limited, it will directly lead to errors in the parameters during process execution, such as incorrect database connection address format, color values ​​exceeding the color gamut range, and undefined event types. Therefore, it is necessary to build a constraint rule base to perform pre-validation of configuration values.

[0035] A constraint rule base is constructed, using component type as the index key. Each component type corresponds to a set of configuration item constraint entries. Each configuration item constraint entry includes the configuration item name, regular expression pattern, error message, and severity level. The data structure of the constraint rule base is represented as follows: ;in, For the input component type, The name of the configuration item to be entered. The input regular expression pattern, The error message entered. The severity level is entered and , These are the constraint rule entries to be output. This is the set of constraint rules for the output.

[0036] Regular expression patterns are used to restrict the data type, value range, and format specifications of configuration values. For connection address configuration items, the corresponding regular expression pattern restricts the connection address to conform to the standard connection format. For color configuration items, the corresponding regular expression pattern restricts the color value to the standard color code format. For trigger event type configuration items, the corresponding regular expression pattern restricts the event type to one of the predefined enumerated values.

[0037] The system retrieves the configuration value of the configuration item and calls the corresponding constraint rule from the constraint rule library. A regular expression engine is then used to determine whether the configuration value conforms to the constraint rule. The validation function is expressed as follows: ;in, For the input configuration value, The input regular expression pattern, This is the output verification status value. A status value of 1 indicates that the verification passed, and a status value of 0 indicates that the verification failed.

[0038] If the verification status value is 1, it is marked as verified. If the verification status value is 0, differentiated error messages are generated according to the severity level and displayed in the debug information window. At the same time, the component is blocked from entering the subsequent testing process until all configuration items pass verification and the verified component configuration data is obtained.

[0039] The main component responsible for performing component configuration item testing, subsequent process configuration testing, and process data testing is the microcontroller. The microcontroller includes a rule parsing unit, a process execution control unit, a relationship control unit, a data extraction unit, and a component execution unit.

[0040] The rule parsing unit parses the rule objects of the components, generates code instructions to control the components, executes the code instructions, completes the component initialization, and thus achieves the function of controlling the components. The process execution control unit parses the process data, generates a process node graph, finds the start node, controls the process execution direction from the start node, and calls the relationship control unit to run the edges in the process node graph. The relationship control unit parses the two node objects connected by the upper edge of the process, determines the relationship between the two node objects, and then determines the next node object or the next edge to be run based on the relationship. When the process runs to a component node, the data extraction unit is responsible for extracting the data required by the component node, based on the transmission data recorded in the edge object of the upper edge connected to the component node. When the relationship control unit determines that the next node to be run is a component node, and the event of the edge start node triggering the process recorded on the edge object is triggered, the component execution unit calls the execution method of the edge end node according to the edge start node recorded on the edge object, uses the transmission data extracted by the data extraction unit as input data, runs the component on the component node, and notifies the process execution control unit after the execution is completed so that the process execution control unit can continue to control the process execution direction.

[0041] The rule parsing unit, process operation control unit, relationship control unit, data extraction unit, and component operation unit of the microcontroller work together in the following sequence to form a test pipeline.

[0042] The first step is for the rule parsing unit to read the node and edge attribute data encapsulated in the database table, parse the rule object of the component, generate code instructions to control the component, run the code instructions to complete the component initialization, and load the constraint rule library into the memory cache.

[0043] The second step is for the process execution control unit to parse the process data, generate a process node diagram, find the start node, and send a process direction query request to the relationship control unit starting from the start node.

[0044] The third step involves the relationship control unit parsing the two node objects connected in the process, determining the relationship between these two node objects, identifying the next node object or the next edge to be run based on the relationship, and returning the determination result to the process execution control unit.

[0045] Fourth, when the process reaches a component node, the process operation control unit sends a data extraction request to the data extraction unit. The data extraction unit extracts the data required by the component node based on the transmission data recorded in the edge object of the previous edge connected to the component node, and transmits the extracted data to the component operation unit.

[0046] Fifth, the component execution unit receives the input data transmitted by the data extraction unit. After the next node determined by the relationship control unit is the component node and the event of the edge start node triggering the process recorded on the edge object is triggered, the component execution unit calls the execution method of the edge end node according to the edge start node recorded on the edge object, and runs the component on the component node with the input data as the running parameters. After the operation is completed, the component execution unit writes the output data to the data flow log at the end of the component node and notifies the process execution control unit so that the process execution control unit can continue to control the process execution direction.

[0047] refer to Figure 5 This demonstrates the working logic of component configuration item testing and microcontroller collaboration: when configuring component attributes, the constraint rule library is automatically called for real-time verification, and the five microcontroller units collaboratively execute test tasks according to pipeline timing.

[0048] Step 5: Based on the verified component configuration data, set globally unique identifiers for the events and behaviors of edges and components, reflect the corresponding execution methods based on the globally unique identifiers and run them to obtain the execution results of the edges and components that have passed the execution.

[0049] It should be noted that the number of edges and components in the execution flowchart is large and the method call relationships are complex. If the traditional manual addressing method is used, method call errors or duplicate calls are very likely to occur. Therefore, it is necessary to establish a precise mapping relationship through a globally unique identifier.

[0050] Globally unique identifiers are assigned to the events and behaviors of edges and components. These globally unique identifiers are hexadecimal strings and are dynamically generated and assigned during the flowchart configuration phase. A mapping relationship is established between these globally unique identifiers and the executed methods. The data structure representing this mapping relationship is as follows: ;in, This is the globally unique identifier that is input. The execution method is the input. Given the set of globally unique identifiers as input. The set of execution methods is the input. This is the set of mapping relationships to be output.

[0051] When executing any side or component, the corresponding execution method is retrieved and run based on a globally unique identifier. The criterion for successful execution is that the execution method does not throw any exceptions during execution and its return value matches the expected type. The judgment function is expressed as follows: ;in, Throw a status for input exceptions. The actual return value of the input. The expected return value type of the input. For the input type matching function, This is the output running status.

[0052] If the execution status is "Pass", the current edge or component is automatically marked as successfully executed, and the execution method of the next edge or component is executed, until all edges and components in the execution flowchart have been executed. If the execution status is "Fail", an error record containing a globally unique identifier and the name of the execution method is generated and displayed in the debug information window. At the same time, the edge or component is highlighted in the flowchart drawing window to quickly locate the fault node and obtain the execution results of the edges and components that have passed the execution.

[0053] refer to Figure 6 This demonstrates the reflection execution mechanism of process configuration testing: it retrieves the mapping relationship based on a globally unique identifier, dynamically loads and executes the corresponding method, and continues to the next node after successful execution, and marks the fault location if it fails.

[0054] Step 6: Based on the execution results of the edges and components that have passed the run, set a data flow log at the end of each edge and component and record the process running data to obtain the process running data log.

[0055] It should be noted that during software testing, data is prone to loss, tampering, or type mismatch when it is passed along the edges. Traditional overall test logs cannot locate data anomalies at the specific edge or component level. Therefore, it is necessary to set up independent data flow logs at the end of each edge and component.

[0056] A data flow log is set at the end of each edge and component. The data flow log's data structure includes a unique log identifier, the identifier of the flowchart to which it belongs, a globally unique identifier for the current edge or component, a globally unique identifier for the upstream node, a globally unique identifier for the downstream node, an input data snapshot, an output data snapshot, and an execution status code. The data structure is represented as follows: ;in, Used as a unique identifier for the entered log. This is the identifier for the flowchart to which the input belongs. This is a globally unique identifier for the current edge or component. The input is a globally unique identifier for the upstream node. The input is a globally unique identifier for the downstream node. A snapshot of the input data. A snapshot of the input and output data. The input execution status code. This refers to the output data flow log entries.

[0057] Both input and output data snapshots are stored serially using a preset data format. When running the execution flowchart, input and output data snapshots of edges or components are extracted in real time and written to the data flow log at the end of the edge or component.

[0058] By comparing the snapshot of the output data from the upstream node with the snapshot of the input data from the current node, it can be determined whether data has been lost, tampered with, or mismatched in type during edge transmission. The data difference calculation function is expressed as: ;in, Output a data snapshot of the input upstream node. Enter a snapshot of the data for the current node. This represents the difference in the output data.

[0059] The type consistency check function is expressed as: ;in, Extract functions for the input data type. This ensures consistency in the output type.

[0060] If the data difference is not zero or the type consistency status is Inconsistent, it is determined that an anomaly has occurred during the data transmission process. Based on this, the transmission data type configuration or transmission data field mapping configuration is corrected to obtain the process running data log.

[0061] refer to Figure 7 This demonstrates the log tracking principle of process data testing: a snapshot of input and output data is recorded at the end of each edge and component, and the data transmission anomaly is located by comparing the difference between the upstream output and the current input.

[0062] Step 7: Perform an overall test on the execution flowchart based on the process operation data log to obtain the software's no-code automated test results.

[0063] It should be noted that the user instance interface contains multiple execution flowcharts, which have calling dependencies or parallel running relationships. If a single flowchart is tested independently, it is impossible to verify the data consistency across flowcharts and the data isolation during parallel running. Therefore, it is necessary to build both serial and parallel testing modes for overall testing.

[0064] The chain test executes each execution flowchart sequentially according to their call dependencies in the user instance interface, using the output data of the previous flowchart as the input data for the next. The chain test sequence is represented as follows: ;in, For the input of the first An execution flowchart, The total number of input execution flowcharts. This is the output cascaded test sequence.

[0065] The data transfer relationship is represented as follows: ;in, For the input of the first Output data of each execution flowchart For the input of the first Input data for each execution flowchart.

[0066] By tracing the data transfer links across flowcharts using data flow logs, the data consistency during collaborative runtime of multiple execution flowcharts is verified. The data consistency verification function is expressed as follows: ;in, The output data consistency status is set. A status value of Consistent indicates that the data is consistent, while a status value of Broken indicates that the data is broken.

[0067] Parallel testing simultaneously triggers multiple independent execution flowcharts in the user instance interface, allocates parallel execution threads, and isolates the runtime data of each execution flowchart using globally unique identifiers to prevent data interference during parallel testing. The set of parallel test flows is represented as follows: ;in, The number of flowcharts executed in parallel, as input. This is the set of parallel test cases for output, and any two flowcharts are independent of each other.

[0068] After testing, summarize the data flow logs for each execution flowchart and generate an overall test report. The execution pass rate is calculated using the following formula: ;in, The number of flowcharts that passed the test is the input. This represents the total number of input flowcharts. This is the execution pass rate output.

[0069] The formula for calculating data transmission accuracy is: ;in, To pass the correct number of flowcharts to the input data. This represents the total number of input flowcharts. This refers to the accuracy of the output data transmission.

[0070] The overall test report includes the execution pass rate, error distribution statistics, data transmission accuracy, and test coverage of each execution flowchart, yielding the results of no-code automated software testing.

[0071] refer to Figure 8 This demonstrates the overall testing strategy for user instance interface testing: verifying data consistency between flowcharts through serial testing, verifying data isolation during parallel operation through parallel testing, and finally summarizing and generating an overall test report.

[0072] To verify the technical effectiveness of the no-code automated testing software method described in this invention, comparative experiments were conducted using Comparative Example 1 and Example 1.

[0073] Comparative Example 1 uses traditional coding testing: Testers wrote test scripts for an enterprise resource management software system containing 20 functional modules one by one. Each functional module had an average of 350 lines of test code, for a total of 7,000 lines of test code. The test script development cycle was 14 working days. During the test execution, 23 configuration errors and 15 logic errors were found. The average time for error localization was 2.5 hours.

[0074] Example 1 uses the no-code automated testing software method described in this invention: Steps one through seven are executed sequentially. An execution flowchart is drawn through the configuration interface, component nodes and connecting edges corresponding to 20 functional modules are configured, constraint rules for component configuration items are set, and globally unique identifiers for edges and components are configured. Component configuration item testing, process configuration testing, process data testing, and user instance interface testing are automatically executed. The entire test configuration process requires no test code writing and takes 3 working days. During test execution, step four intercepts 21 configuration errors through constraint rule verification, step five discovers 14 logic errors through reflection execution using globally unique identifiers, and step six locates 2 data transmission errors through data flow logs. The average time for error location is 0.3 hours.

[0075] The comparison results show that, compared to Comparative Example 1, Example 1 reduced the test development cycle by: ;in, For the traditional test cycle of input, The input is the test cycle of this invention. This represents the output cycle shortening rate.

[0076] Configuration error interception rate: ;in, The number of interception errors is the input. The total number of input errors. This represents the error interception rate of the output.

[0077] The efficiency improvement rate for error location is: ;in, Traditional positioning takes time for input. The time taken to locate the input of this invention. The output is the improvement rate of positioning efficiency.

[0078] It completely eliminates the workload of writing test code, achieving the technical goal of no-code automated testing.

[0079] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

[0080] Finally, it should be noted that the above experimental examples are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred experimental examples, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for code-free automated testing software, characterized in that, Includes the following steps: Draw the execution flowchart in the configuration interface and generate connecting edges between nodes that have control relationships; Configure the node attributes of each node, bind the component to the node and configure the basic and extended attributes of the component to obtain the node attribute data; Configure the edge attributes of each side, set the triggering event, data transmission and execution method of the edge, and obtain the edge attribute data; Set constraint rules for each configuration item of the component, obtain the configuration value of the configuration item and validate it through regular expressions to obtain the validated component configuration data; Based on the verified component configuration data, globally unique identifiers are set for the events and behaviors of edges and components. The corresponding execution methods are reflected and run according to the globally unique identifiers to obtain the execution results of the edges and components that have passed the execution. Based on the execution results of the edges and components that have passed the test, a data flow log is set at the end of each edge and component and the process execution data is recorded to obtain the process execution data log. Based on the process execution data logs, an overall test was performed on all execution flowcharts to obtain the software's no-code automated test results.

2. The method for no-code automated testing software according to claim 1, characterized in that, Draw the execution flowchart in the configuration interface, and generate connecting edges between nodes with control relationships, including: The configuration interface includes a flowchart drawing window, a node addition window, a property configuration window, and a debugging information window; The node addition window contains the nodes needed to draw the execution flowchart, and each node is bound to a mouse drag event; Bind click and mouse drag events to the edges of each node. When the edge of a node is clicked and dragged with the mouse, an edge pointing to the next node is generated along the direction of the mouse drag. When the edge of the next node is touched and the mouse is released to stop dragging, an edge connecting the first node to the next node is generated.

3. The method for no-code automated testing software according to claim 2, characterized in that, Configure the node attributes for each node, bind components to the nodes, and configure the basic and extended attributes of the components to obtain the node attribute data, including: When a node is selected by clicking with the mouse, the attribute configuration window displays the attribute configuration options for that node; To bind a node to a component, configure the basic attributes of the bound component and the extended attributes defined according to the needs of the component, and obtain the node attribute data.

4. The method for no-code automated testing software according to claim 2, characterized in that, Configure the edge attributes for each side, set the edge's trigger events, data transmission, and execution methods, and obtain the edge attribute data, including: When an edge is selected by clicking the mouse, the attribute configuration window displays the attribute configuration options for that edge; Set the trigger event of the previous node of the edge, the data to be transmitted from the previous node to the next node, and the execution method of the next node to obtain the edge attribute data; The node attribute data and edge attribute data are encapsulated into a preset data format and saved to a database table. The required data is retrieved from the database table according to the control flow of the execution flowchart, the rule attributes configured in the node or edge are parsed, and the corresponding actions are executed according to the parsed rule attributes.

5. The method for no-code automated testing software according to claim 2, characterized in that, Set constraint rules for each configuration item of the component, obtain the configuration value of the configuration item, and validate it using regular expressions to obtain the validated component configuration data, including: Constraint rules are set for each configuration item and stored in the constraint rule library. The constraint rule library uses the component type as the index key. Each component type corresponds to a set of configuration item constraint entries. Each configuration item constraint entry includes the configuration item name, regular expression pattern, error message, and severity level. The regular expression pattern is used to limit the data type, value range, and format specifications of the configuration value. The configuration value of the configuration item is obtained and the corresponding constraint rule is retrieved from the constraint rule library. The regular expression engine is used to determine whether the configuration value conforms to the constraint rule. If the verification is successful, the component is marked as verified. If it is not successful, a differentiated error message is generated based on the severity level and displayed in the debug information window. At the same time, the component is blocked from entering the subsequent testing process until all configuration items pass the verification and the verified component configuration data is obtained.

6. The method for no-code automated testing software according to claim 5, characterized in that, Regular expression patterns are used to limit the data type, value range, and format specifications of configuration values, including: For the connection address configuration item, the corresponding regular expression pattern ensures that the connection address conforms to the standard connection format; For the color configuration item, the corresponding regular expression pattern limits the color value to the standard color code format; For the event type configuration item, the corresponding regular expression pattern limits the event type to one of the predefined enumeration values.

7. The method for no-code automated testing software according to claim 1, characterized in that, Based on the verified component configuration data, globally unique identifiers are set for the events and behaviors of edges and components. The corresponding execution methods are reflected and run based on these globally unique identifiers, yielding the execution results of the successfully executed edges and components, including: Set globally unique identifiers for events and behaviors of edges and components, and establish a correspondence between globally unique identifiers and execution methods; When executing any side or component, retrieve the corresponding execution method based on the globally unique identifier and run it. If the execution passes, proceed to the execution method of the next edge or component, until all edges and components in the execution flowchart have been executed. If the run fails, an error message will be generated and displayed to prompt the definer to make modifications.

8. The method for no-code automated testing software according to claim 7, characterized in that, Retrieve and execute the corresponding method based on the globally unique identifier, including: If the execution method does not throw an exception during execution and the return value is of the expected type, the current edge or component will be automatically marked as successful and the execution method of the next edge or component will be executed. If the process fails, an error record containing a globally unique identifier and the name of the executed method is generated. The error record is displayed in the debug information window, and the corresponding edge or component is highlighted in the flowchart drawing window to quickly locate the faulty node.

9. The method for no-code automated testing software according to claim 1, characterized in that, Based on the execution results of the edges and components that have passed the test, a data flow log is set at the end of each edge and component to record the process execution data, resulting in a process execution data log, including: Set a data flow log at the end of each edge and component. The data flow log records the globally unique identifier of the current edge or component, the globally unique identifier of the upstream node, the globally unique identifier of the downstream node, the input data snapshot, the output data snapshot, and the execution status code. When running the execution flowchart, the input data snapshot and output data snapshot of the edge or component are extracted in real time and written to the data flow log at the end of the edge or component; By comparing the output data snapshot of the upstream node with the input data snapshot of the current node, it is determined whether the data was lost, tampered with, or mismatched in type during edge transmission. Based on this, the transmission data type configuration or transmission data field mapping configuration is corrected to obtain the process running data log.

10. The method for no-code automated testing software according to claim 1, characterized in that, Based on the process execution data logs, a comprehensive test was performed on all execution flowcharts to obtain the software's no-code automated test results, including: According to the calling dependencies of each execution flowchart in the user instance interface, each execution flowchart is executed in sequence. The output data of the previous execution flowchart is used as the input data of the next execution flowchart. The data transmission link across flowcharts is tracked through the data flow log to verify the data consistency when multiple execution flowcharts run in collaboration. Simultaneously, multiple independent execution flowcharts in the user instance interface are triggered, parallel execution threads are allocated, and the running data of each execution flowchart is isolated by a globally unique identifier; After the test is completed, the data flow logs of each execution flowchart are summarized to generate an overall test report. The overall test report includes the execution pass rate, error distribution statistics, data transmission accuracy and test coverage of each execution flowchart, and obtains the software no-code automated test results.

Images