Low-code platform-based application rapid generation and automatic testing method and system

Abstract

This invention provides a method and system for rapid application generation and automated testing based on a low-code platform, relating to the field of code testing technology. The method includes: converting application logic descriptions into intermediate abstract representation models; constructing execution dependency graphs and deriving test input spaces through path analysis; mapping the models to executable code and generating test scripts; capturing execution trajectories to construct dynamic execution trace graphs; comparing dependency graphs to identify uncovered paths and automatically generating supplementary test cases. This invention improves test coverage, enhances the quality and reliability of low-code applications, and simplifies the testing process.

Description

Technical Field

[0001] This invention relates to code testing technology, and more particularly to a method and system for rapid generation and automated testing of applications based on a low-code platform. Background Technology

[0002] With the acceleration of digital transformation, enterprises' demand for application system development continues to grow, giving rise to low-code development platforms. Low-code development platforms enable non-professional developers to quickly build business applications through graphical interfaces, visual orchestration, and pre-built components, significantly lowering the development threshold and shortening the development cycle. Currently, low-code platforms are widely used in various fields such as enterprise internal systems, workflows, and data visualization. Low-code platforms typically provide drag-and-drop components, visual process design, data model definition, and business rule configuration functions, allowing users to define application logic through a graphical interface without writing large amounts of code.

[0003] Existing low-code platforms typically lack automated testing mechanisms, requiring developers to manually design and execute test cases. This is not only time-consuming and labor-intensive but also prone to overlooking critical test scenarios, making it difficult to guarantee application quality. Especially when application logic is complex and there are numerous component interactions, manual testing struggles to cover all execution paths and boundary conditions.

[0004] Existing low-code platforms suffer from a semantic gap between application logic and executable code. This means that the application logic defined by the user through a graphical interface lacks a clear mapping and tracing mechanism between the final generated code. Consequently, when application malfunctions, it becomes difficult to quickly locate the root cause and trace it back to the corresponding graphical configuration node, increasing the difficulty of debugging and fixing. Summary of the Invention

[0005] This invention provides a method and system for rapid application generation and automatic testing based on a low-code platform, which can solve the problems in the prior art.

[0006] A first aspect of this invention provides a method for rapid application generation and automated testing based on a low-code platform, comprising:

[0007] Obtain the application logic description defined by the user through the graphical orchestration interface, and convert the application logic description into an intermediate abstract representation model;

[0008] Based on the intermediate abstract representation model, a directed acyclic execution dependency graph is constructed. By performing path analysis and state space traversal on the execution dependency graph, the combination of variables that trigger state transitions and their constraint boundaries are identified. The constraint boundaries are then used to derive a test input space that can cover multiple path branches and boundary conditions.

[0009] The intermediate abstract representation model is mapped to executable code, and a test script set is generated based on the test input space. The executable code and the test script set are executed in the runtime environment to capture the evolution trajectory of state variables, the message passing sequence between components, and the exception triggering point during the execution process, and to construct a dynamic execution trace graph that reflects the actual running behavior.

[0010] The dynamic execution tracing graph is compared with the execution dependency graph to identify uncovered execution paths and state transition deviations. By tracing back the corresponding component configuration nodes in the intermediate abstract representation model, targeted supplementary test cases are automatically generated. The basis for generating the supplementary test cases is marked in the form of a dependency chain at the corresponding position in the graphical orchestration interface.

[0011] Based on the intermediate abstract representation model, a directed acyclic execution dependency graph is constructed. By performing path analysis and state space traversal on the execution dependency graph, the combinations of variables that trigger state transitions and their constraint boundaries are identified. Using the constraint boundaries, a test input space that can cover multiple path branches and boundary conditions is derived, including:

[0012] Evaluate the dependencies and state transition rules of components in the intermediate abstract representation model, construct the node representation of each component in the execution dependency graph, and depict the data flow and control flow dependencies between components as directed edges to generate a directed acyclic execution dependency graph that reflects the application execution logic.

[0013] Based on the nodes and directed edges in the execution dependency graph, a depth-first strategy is used to traverse and explore the paths, sort out all complete execution paths from the entry node to the exit node, and characterize the node sequence and edge condition sequence traversed by the complete execution path.

[0014] For the edge condition sequence, the set of variables affecting path reachability is summarized, and variable constraint expressions are derived based on the edge condition sequence. By analyzing the variable constraint expressions, the variable value boundaries of the complete execution path are determined.

[0015] The variable value boundaries are integrated and duplicates are excluded. The combination of variable critical values ​​and boundary values ​​that can trigger different path branches is selected. A test input space containing execution path coverage information is constructed based on the variable critical values ​​and boundary value combinations.

[0016] Based on the nodes and directed edges in the execution dependency graph, a depth-first search strategy is used to traverse and explore the paths, identifying all complete execution paths from the entry node to the exit node, and characterizing the node sequences and edge condition sequences traversed by all complete execution paths, including:

[0017] Identify the node with an in-degree of zero in the execution dependency graph as the entry node, push the entry node as the starting node onto the path traversal stack, and initialize the path record container to store the node sequence and edge condition sequence of the current exploration path.

[0018] Pop the top node from the path traversal stack as the current node, append the current node to the node sequence of the path record container, and query the execution dependency graph to obtain all outgoing edges starting from the current node and their pointing successor nodes.

[0019] For each outgoing edge, extract the edge conditions it carries, and append the edge conditions to the edge condition sequence of the path recording container in sequence. Then determine whether the successor node is an exit node with an outgoing degree of zero.

[0020] If the successor node is an exit node, the node sequence and edge condition sequence in the path record container are combined to form a complete execution path and stored in the path set. If the successor node is not an exit node, the successor node is pushed onto the path traversal stack and traversal continues until the path traversal stack is empty, thus obtaining all complete execution paths from the entry node to the exit node and their node sequences and edge condition sequences.

[0021] Mapping the intermediate abstract representation model to executable code, and simultaneously generating a test script set based on the test input space, includes:

[0022] The intermediate abstract representation model is parsed to define the components and state transition rules, map each component to a corresponding code module structure, map the data flow between components to the interface call relationship between code modules, and map the state transition rules to control flow logic, generating executable code containing data processing logic and control flow logic;

[0023] Extract each test input vector and its corresponding path coverage information from the test input space. The path coverage information identifies the execution path and state transition sequence that can be activated by the corresponding test input vector.

[0024] Based on the path coverage information, the intermediate abstract representation model is traced back to identify the component sequence and data constraints involved in the execution path. Based on the component sequence, the order of code module interfaces that the test script needs to call is determined. Based on the data constraints, assertion expressions are generated. The test input vector, the order of code module interfaces, and the assertion expressions are combined to form a test script. The test scripts corresponding to all test input vectors are summarized to form a test script set.

[0025] The executable code and the test script set are executed in the runtime environment, capturing the evolution trajectory of state variables, the message passing sequence between components, and the exception triggering points during the execution process, and constructing a dynamic execution trace graph that reflects the actual running behavior, including:

[0026] Load the executable code in the runtime environment, and insert probe instructions at the entry and exit points of the executable code's code module;

[0027] The test scripts in the test script set are executed sequentially. The probe instructions capture the value changes of the state variables during the execution of the executable code. The values ​​of each state variable at different execution times are recorded in timestamp order to generate the evolution trajectory of the state variables.

[0028] Monitor the interface call behavior between code modules in the executable code. When a call event is detected, obtain the caller module identifier and the callee module identifier through the probe instruction. Use the caller module identifier and the callee module identifier as the start and end points of the message passing event. Arrange all the message passing events according to the call time to form a message passing sequence between components.

[0029] During the execution of the executable code, abnormal signals are monitored. When the abnormal signal is captured, the value of the state variable corresponding to the abnormal trigger time is obtained from the evolution trajectory of the state variable, and the abnormal trigger point is determined by combining it with the module identifier recorded by the probe instruction.

[0030] Using code modules in the executable code as nodes and message passing events in the message passing sequence between components as directed edges, the evolution trajectory of the state variables is marked on the corresponding nodes, and the exception triggering points are marked on the exception attributes of the corresponding nodes to construct a dynamic execution tracing graph.

[0031] By performing a topological comparison between the dynamic execution tracing graph and the execution dependency graph, uncovered execution paths and state transition deviations are identified. Then, by tracing back the corresponding component configuration nodes in the intermediate abstract representation model, targeted supplementary test cases are automatically generated, including:

[0032] Analyze all nodes and directed edges in the execution dependency graph, construct an execution path set containing all theoretical execution paths, evaluate all nodes and directed edges in the dynamic execution tracing graph, construct a covered path set containing actual execution paths, calculate the difference between the execution path set and the covered path set, and obtain the uncovered execution paths.

[0033] Explore the uncovered execution paths, characterize the node sequence and edge condition sequence contained in each uncovered execution path, map and compare the node sequence with the executed node sequence in the dynamic execution tracing graph, and select the first unexecuted node as the coverage breakpoint.

[0034] From the coverage breakpoint, we extrapolate along the edge relationships of the execution dependency graph to the predecessor node, depict the triggering conditions carried by the edge relationships, perform constraint matching between the triggering conditions and the state variable evolution trajectory corresponding to the predecessor node, and analyze the state transition deviation that causes the coverage breakpoint not to be triggered.

[0035] Based on the state transition deviation study, the intermediate abstract representation model is confirmed, the component configuration node corresponding to the coverage breakpoint in the intermediate abstract representation model is identified, and the input parameter constraints and state transition rules associated with the component configuration node are summarized.

[0036] Based on the input parameter constraints, a test input vector that can satisfy the triggering condition is derived. Based on the state transition rules, a state sequence that makes the coverage breakpoint reachable is woven. The test input vector and the state sequence are combined to form a supplementary test case.

[0037] Based on the state transition deviation study of the intermediate abstract representation model, the component configuration node corresponding to the coverage breakpoint in the intermediate abstract representation model is confirmed, and the input parameter constraints and state transition rules associated with the component configuration node are summarized as follows:

[0038] The difference between the actual state value and the expected state value is evaluated from the state transition deviation. Component configuration nodes are explored in the intermediate abstract representation model and a candidate node set is established. For each candidate node in the candidate node set, the association between its predecessor node identifier and successor node identifier in the intermediate abstract representation model is described, and a local topology structure reflecting the relationship between nodes is constructed.

[0039] The predecessor node identifier and the successor node identifier are projected onto the intermediate abstract representation model. By calculating the structural matching degree between the local topology and the predecessor and successor identifiers of the coverage breakpoint, the candidate node with the optimal structural matching degree is determined as the component configuration node corresponding to the coverage breakpoint.

[0040] The state transition relationships of the component configuration nodes are analyzed, whereby the state transition relationships describe the mapping logic between the input parameter values ​​and the state variable values. The mapping logic is expanded into conditional judgment expressions and state update expressions, and the conditional judgment expressions and the state update expressions are integrated to form a systematic state transition rule.

[0041] A second aspect of this invention provides a system for rapid application generation and automated testing based on a low-code platform, comprising:

[0042] The conversion module is used to obtain the application logic description defined by the user through the graphical orchestration interface and convert the application logic description into an intermediate abstract representation model.

[0043] The derivation module is used to construct a directed acyclic execution dependency graph based on the intermediate abstract representation model. By performing path analysis and state space traversal on the execution dependency graph, it identifies the combination of variables that trigger state transitions and their constraint boundaries, and uses the constraint boundaries to derive a test input space that can cover multiple path branches and boundary conditions.

[0044] The execution module is used to map the intermediate abstract representation model into executable code, and generate a test script set based on the test input space; execute the executable code and the test script set in the runtime environment, capture the evolution trajectory of state variables, the message passing sequence between components and the exception triggering point during the execution process, and construct a dynamic execution trace graph that reflects the actual running behavior;

[0045] The annotation module is used to perform a topological comparison between the dynamic execution tracing graph and the execution dependency graph, identify uncovered execution paths and state transition deviations, automatically generate targeted supplementary test cases by tracing back the corresponding component configuration nodes in the intermediate abstract representation model, and annotate the basis for the generation of the supplementary test cases in the form of dependency chains at the corresponding positions in the graphical orchestration interface.

[0046] A third aspect of the present invention provides an electronic device, comprising:

[0047] processor;

[0048] Memory used to store processor-executable instructions;

[0049] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0050] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0051] The beneficial effects of this application are as follows:

[0052] By constructing a directed acyclic execution dependency graph and performing path analysis and state space traversal, the system can automatically identify the combination of variables that trigger state transitions and their constraint boundaries, thereby generating a test input space that can cover multiple path branches and boundary conditions, significantly improving test case coverage and reducing the blindness of manual testing.

[0053] This method constructs a dynamic execution trace graph by capturing the evolution trajectory of state variables, the message passing sequence between components, and the exception triggering points during the execution process. It then compares the graph with the expected execution dependency graph to accurately identify uncovered execution paths and state transition deviations, thereby achieving automatic test completion and optimization.

[0054] The system will mark the basis for generating supplementary test cases in the form of dependency chains in the corresponding positions of the graphical orchestration interface, providing developers with intuitive problem location and repair guidance, accelerating the development-testing-repair cycle, and reducing the quality risks of low-code applications.

[0055] By adopting a unified intermediate abstraction representation model, the system achieves integrated processing of application logic to executable code conversion and test script generation, improving the platform's scalability and compatibility, while providing a unified logical foundation for application upgrades and maintenance. Attached Figure Description

[0056] Figure 1 This is a flowchart illustrating the method for rapid application generation and automated testing based on a low-code platform according to an embodiment of the present invention.

[0057] Figure 2 This is a flowchart illustrating the component configuration determination and state transition based on node matching degree in an embodiment of the present invention. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0059] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0060] Figure 1 This is a flowchart illustrating the method for rapid application generation and automated testing based on a low-code platform according to an embodiment of the present invention. Figure 1 As shown, the method includes:

[0061] Obtain the application logic description defined by the user through the graphical orchestration interface, and convert the application logic description into an intermediate abstract representation model;

[0062] Based on the intermediate abstract representation model, a directed acyclic execution dependency graph is constructed. By performing path analysis and state space traversal on the execution dependency graph, the combination of variables that trigger state transitions and their constraint boundaries are identified. The constraint boundaries are then used to derive a test input space that can cover multiple path branches and boundary conditions.

[0063] The intermediate abstract representation model is mapped to executable code, and a test script set is generated based on the test input space. The executable code and the test script set are executed in the runtime environment to capture the evolution trajectory of state variables, the message passing sequence between components, and the exception triggering point during the execution process, and to construct a dynamic execution trace graph that reflects the actual running behavior.

[0064] The dynamic execution tracing graph is compared with the execution dependency graph to identify uncovered execution paths and state transition deviations. By tracing back the corresponding component configuration nodes in the intermediate abstract representation model, targeted supplementary test cases are automatically generated. The basis for generating the supplementary test cases is marked in the form of a dependency chain at the corresponding position in the graphical orchestration interface.

[0065] In one optional implementation, a directed acyclic execution dependency graph is constructed based on the intermediate abstract representation model. Path analysis and state space traversal are performed on the execution dependency graph to identify combinations of variables triggering state transitions and their constraint boundaries. The constraint boundaries are then used to derive a test input space that can cover multiple path branches and boundary conditions, including:

[0066] Evaluate the dependencies and state transition rules of components in the intermediate abstract representation model, construct the node representation of each component in the execution dependency graph, and depict the data flow and control flow dependencies between components as directed edges to generate a directed acyclic execution dependency graph that reflects the application execution logic.

[0067] Based on the nodes and directed edges in the execution dependency graph, a depth-first strategy is used to traverse and explore the paths, sort out all complete execution paths from the entry node to the exit node, and characterize the node sequence and edge condition sequence traversed by the complete execution path.

[0068] For the edge condition sequence, the set of variables affecting path reachability is summarized, and variable constraint expressions are derived based on the edge condition sequence. By analyzing the variable constraint expressions, the variable value boundaries of the complete execution path are determined.

[0069] The variable value boundaries are integrated and duplicates are excluded. The combination of variable critical values ​​and boundary values ​​that can trigger different path branches is selected. A test input space containing execution path coverage information is constructed based on the variable critical values ​​and boundary value combinations.

[0070] The intermediate abstract representation model construction phase performs static analysis on the application's source code or bytecode to extract structured information such as function modules, class definitions, method implementations, and variable declarations. The abstract representation model decomposes the program into functional components, each encapsulating specific computational logic or data processing functionality. Component definitions include a unique identifier, a list of input parameters, output return value types, a set of internal state variables, and state transition triggering conditions. State transition rules describe the component's behavioral changes under different input conditions, including conditional expressions, state update operations, and output value calculation methods. The model construction process uses a parser to parse the code structure and a semantic analyzer to extract data types and control flow information, generating a standardized intermediate representation format.

[0071] Component dependency assessment determines the interdependencies between components by analyzing function call relationships, variable passing paths, and data flow in the program. The data flow dependency identification algorithm traverses the input and output interfaces of components; when an output variable of component A is used as an input parameter by component B, a data dependency relationship from A to B is established. The control flow dependency identification algorithm analyzes conditional branch statements, loop control statements, and exception handling statements; when the execution result of component A determines whether component B is executed, a control dependency relationship is established. The execution dependency graph is represented using a directed graph data structure. Nodes in the graph correspond to program components, and node attributes include component identifier, component type, state variable definition, and a set of transition rules. Directed edges represent dependencies between components, and edge attributes include dependency type identifier, constraint expression, and execution priority weight. The graph construction process ensures that there are no circular dependencies; when a potential cycle is detected, the circular structure is eliminated through dependency decoupling or component refactoring.

[0072] The path traversal exploration employs a depth-first search algorithm, recursively visiting the entry node of the execution dependency graph. The algorithm maintains a path stack recording the sequence of nodes traversed, along with the constraint information for each edge. The entry node is determined by calculating the in-degree of each node in the graph; nodes with an in-degree of zero serve as the starting point for program execution. During traversal, the algorithm checks all outgoing edges of the current node and determines reachable successor nodes based on the edge constraints. When an exit node is reached, the sequence of nodes in the current path stack and the corresponding edge condition sequence are recorded as the complete execution path. The exit node is determined by calculating the out-degree of each node; nodes with an out-degree of zero serve as the termination point for program execution. Path information includes a sequence of node identifiers, a sequence of transition conditions between nodes, and the total number of steps executed. The algorithm uses a backtracking mechanism to handle multi-branch paths, ensuring that traversal covers all execution path combinations.

[0073] The edge condition sequence analysis process extracts key variables and variable constraints affecting path execution. The algorithm traverses the constraint expression of each edge on the path, identifying variable identifiers, comparison operators, and constant values ​​within the expression. Variable set aggregation collects all variables appearing on the path, establishing a mapping relationship between variable identifiers and variable types. Constraint expression derivation combines multiple edge conditions on the path according to logical AND operations, forming a composite constraint expression describing the execution conditions of the entire path. Expression simplification eliminates redundant constraints, merges similar constraint terms, and generates the simplest form of variable constraint relationships. Variable value boundary calculation determines the feasible value range for each variable by solving a system of constraint inequalities. The algorithm uses interval arithmetic to handle variable constraints, narrowing the variable value range through constraint propagation technology. When a constraint has no solution, the corresponding path is marked as an unreachable path.

[0074] The variable value boundary integration phase collects variable constraint results from all complete execution paths, constructing a global variable constraint information database. This database uses a hash table structure, with the key being the variable identifier and the value being the set of value boundaries for that variable across different paths. A duplicate elimination algorithm compares the value boundaries of the same variable across different paths, merging boundaries where they overlap or contain each other. A variable critical value identification algorithm analyzes the intersection points of constraint boundaries; these intersection points typically correspond to critical values ​​for conditional branches or loop boundary conditions. The algorithm calculates the boundary values ​​of adjacent constraint intervals, extracting key value points that can trigger different execution paths. Boundary value combination generation employs combinatorial mathematics, performing a Cartesian product operation on the critical values ​​of different variables to generate multidimensional variable value combinations. A combination filtering mechanism eliminates invalid combinations that do not meet global constraints, ensuring that the generated variable combinations correspond to actual executable program paths.

[0075] The test input space is constructed based on the calculation results of combinations of variable critical values ​​and boundary values, generating a set of test cases containing execution path coverage information. The test case data structure includes input variable assignment vectors, identifiers of the expected execution paths, types of covered boundary conditions, and expected results of path execution. Path coverage information records the program branches that the test cases can activate, the key control nodes they traverse, and the number of constraints satisfied. The test input space is organized using a hierarchical index structure: the first layer categorizes by path type, the second layer indexes by variable dimension, and the third layer stores the specific test case data and metadata. The space construction process ensures that the test case set covers the main execution paths and key boundary conditions of the program, while controlling the total number of test cases within a reasonable range to balance test coverage and execution efficiency.

[0076] In one optional implementation, based on the nodes and directed edges in the execution dependency graph, a depth-first strategy is used to traverse and explore the paths, identifying all complete execution paths from the entry node to the exit node, and characterizing the node sequence and edge condition sequence traversed by all complete execution paths, including:

[0077] Identify the node with an in-degree of zero in the execution dependency graph as the entry node, push the entry node as the starting node onto the path traversal stack, and initialize the path record container to store the node sequence and edge condition sequence of the current exploration path.

[0078] Pop the top node from the path traversal stack as the current node, append the current node to the node sequence of the path record container, and query the execution dependency graph to obtain all outgoing edges starting from the current node and their pointing successor nodes.

[0079] For each outgoing edge, extract the edge conditions it carries, and append the edge conditions to the edge condition sequence of the path recording container in sequence. Then determine whether the successor node is an exit node with an outgoing degree of zero.

[0080] If the successor node is an exit node, the node sequence and edge condition sequence in the path record container are combined to form a complete execution path and stored in the path set. If the successor node is not an exit node, the successor node is pushed onto the path traversal stack and traversal continues until the path traversal stack is empty, thus obtaining all complete execution paths from the entry node to the exit node and their node sequences and edge condition sequences.

[0081] The basic structure of the execution dependency graph is clearly defined. An execution dependency graph is a directed graph where nodes represent program execution units, edges represent execution dependencies, and conditions attached to the edges represent constraints for execution transfer. Based on this, the execution path exploration process is as follows:

[0082] When identifying entry nodes in the execution dependency graph, all nodes in the graph are scanned, and the in-degree of each node is counted. Nodes with an in-degree of zero are the entry nodes, and they are the starting point of program execution. Taking a program control flow analysis as an example, the initial basic block of a function is usually the entry node. The identified entry nodes are pushed onto a dedicated path traversal stack, and a path recording container is initialized. This container contains two sequences: a node sequence and an edge condition sequence, used to record the nodes and edge conditions traversed during the current exploration process.

[0083] After path exploration begins, the top node is popped from the path traversal stack as the current processing node. If the stack is empty, the exploration ends; otherwise, the popped node is appended to the node sequence of the path record container. Next, the execution dependency graph is queried to obtain all outgoing edges originating from the current node and their corresponding successor nodes. This process can be efficiently implemented using graph data structures such as adjacency lists or adjacency matrices.

[0084] For each outgoing edge originating from the current node, extract its associated edge conditions, which can be Boolean expressions, branch conditions, or function call constraints. These edge conditions are then appended sequentially to the edge condition sequence in the path record container, forming a constraint chain on the current exploration path. For example, in an if-else structure, the "if" branch corresponds to the condition "x>0", and the "else" branch corresponds to the condition "x≤0".

[0085] For each outgoing edge, determine if its successor node is an exit node (a node with an out-degree of zero). If the successor node is an exit node, it means a complete path from the entry point to the exit point has been found. At this point, combine the node sequence and edge condition sequence in the path record container to form a complete execution path and store it in the path set. If the successor node is not an exit node, push the successor node onto the path traversal stack and continue the depth-first traversal.

[0086] To avoid looping issues during path exploration, a set of visited nodes can be maintained in the path record, or a limit can be set on the number of visits. When a potentially infinite loop is detected, the exploration of the current path can be terminated in a timely manner. For programs containing loop structures, an upper limit can be set on the number of loop unrolls to ensure that the algorithm terminates within a finite amount of time.

[0087] In practical applications, the problem of path explosion arises, where the number of paths grows exponentially with the program size. In such cases, path pruning strategies can be employed, such as eliminating unreachable paths based on path availability analysis, or retaining only critical paths based on specific analysis objectives.

[0088] After the path traversal exploration of the dependency graph is completed, the resulting path set contains all execution sequences from the entry node to the exit node. Each path consists of a sequence of nodes and a corresponding sequence of edge conditions. This path information can be used in various application scenarios such as program behavior analysis, test case generation, and program optimization.

[0089] By employing the depth-first traversal strategy described above, all feasible paths in the execution dependency graph can be systematically explored, providing a comprehensive view of execution paths for program analysis and effectively supporting subsequent program understanding and optimization.

[0090] In one optional implementation, mapping the intermediate abstract representation model to executable code, and simultaneously generating a test script set based on the test input space, includes:

[0091] The intermediate abstract representation model is parsed to define the components and state transition rules, map each component to a corresponding code module structure, map the data flow between components to the interface call relationship between code modules, and map the state transition rules to control flow logic, generating executable code containing data processing logic and control flow logic;

[0092] Extract each test input vector and its corresponding path coverage information from the test input space. The path coverage information identifies the execution path and state transition sequence that can be activated by the corresponding test input vector.

[0093] Based on the path coverage information, the intermediate abstract representation model is traced back to identify the component sequence and data constraints involved in the execution path. Based on the component sequence, the order of code module interfaces that the test script needs to call is determined. Based on the data constraints, assertion expressions are generated. The test input vector, the order of code module interfaces, and the assertion expressions are combined to form a test script. The test scripts corresponding to all test input vectors are summarized to form a test script set.

[0094] In the process of mapping the intermediate abstract representation model to executable code, the component definitions and state transition rules in the intermediate abstract representation model are parsed. This step identifies each component defined in the model and its attributes by traversing the data structure of the intermediate abstract representation. For example, for a data processing system, components include a data input module, a data transformation module, a business logic processing module, and a data output module. During the parsing process, the identifier, input / output parameter types, internal state variables, and behavioral characteristics description of each component are extracted.

[0095] When mapping components to code module structures, the appropriate code template is selected based on the component type. For data input components, code related to data validation and parsing is generated; for data transformation components, code for data format conversion and cleaning is generated; and for business logic components, code implementing specific business rules is generated. Each component, after mapping, forms an independent class or function, maintaining the principle of modular design. For example, an XML parsing component can be mapped to a class containing DOM parsing methods, and a data validation component can be mapped to a validator class containing multiple validation rules.

[0096] When mapping data flow between components to interface call relationships between code modules, the connection relationships in the intermediate abstract representation are analyzed. Each connection defines the transfer of data from the source component to the target component. Based on these connection relationships, interface call code to the target component is added at the output point of the source component to ensure that data can be transferred according to the flow defined in the model. For example, if the output of component A needs to be passed to component B as input, then interface call code to component B is added in the processing part of component A, and the processing result is passed as a parameter.

[0097] In the process of mapping state transition rules to control flow logic, each state transition condition is converted into a conditional statement, and the state transition action is converted into a corresponding code block. For simple state machines, switch-case or if-else structures can be used; for complex state machines, the state design pattern can be used, creating a separate class for each state and implementing state transitions through switching state objects. For example, in a document processing workflow, a document may be in states such as "draft," "under review," and "published," with different allowed operations in each state. This can be achieved using the state pattern to implement different behaviors in different states.

[0098] In the stage of generating executable code containing data processing and control flow logic, the various code modules generated in the previous steps are integrated, and necessary exception handling, logging, and performance monitoring code are added. Based on the characteristics of the target platform, appropriate language features and library functions are selected to optimize the performance and maintainability of the generated code. The final generated code includes necessary components such as class definitions, function implementations, interface declarations, and configuration files, forming a complete executable program.

[0099] When extracting test input vectors from the test input space, it is necessary to analyze the data structure and semantics of each test input vector. A test input vector typically contains multiple parameter values, each corresponding to an input point in the system under test. For each test input vector, its corresponding path coverage information is extracted. This information records the code path that the test input vector should traverse and the triggered state transitions during execution. Path coverage information can be represented using a directed graph, where nodes represent program states and edges represent state transitions.

[0100] When backtracking the intermediate abstract representation model based on path coverage information, the corresponding components and state transition rules are located in the intermediate abstract representation model through the nodes and edges in the path information. This process establishes a mapping relationship between test inputs and abstract model elements, which helps to understand how test inputs affect system behavior. The sequence of components involved in the execution path is identified, determining the complete component call chain from input to output. Simultaneously, applicable data constraints during execution are collected, which determine the validation criteria for the test results.

[0101] When determining the order in which code module interfaces need to be called by the test script based on the component sequence, the abstract component sequence is converted into a specific API call sequence. Each component corresponds to one or more API calls, which are arranged according to the execution order of the components. For example, for a process that includes three components: user authentication, data query, and result display, the test script needs to call the login API, query API, and result verification API in sequence.

[0102] In the process of generating assertion expressions based on data constraints, the semantics and form of each data constraint are analyzed. Data constraints include value range restrictions, format requirements, business rules, etc. These constraints are then converted into assertion expressions in a programming language to verify whether the test execution results meet expectations. For simple constraints, they can be directly converted into equality or inequality expressions; for complex constraints, custom verification functions need to be written.

[0103] The stage of combining test input vectors, code module interface order, and assertion expressions to form a test script first involves creating a test script framework, including four parts: test environment setup, test data preparation, test execution, and result verification. Then, test input vectors are converted into test data preparation code, code module interface order into test execution code, and assertion expressions into result verification code. Finally, necessary test cleanup and report generation code are added to complete the construction of a single test script.

[0104] When a test script set is formed by aggregating all test input vectors, the test scripts can be categorized and organized according to dimensions such as functional modules, test types, or coverage targets. A test suite configuration file is added to define the test execution order, dependencies, and resource requirements. To improve testing efficiency, test data sharing and test precondition reuse mechanisms can be implemented to reduce repetitive environment preparation work. Finally, a test report template is generated to ensure that test results are clearly displayed and easy to analyze.

[0105] In one optional implementation, the executable code and the test script set are executed in a runtime environment, capturing the evolution trajectory of state variables, the message passing sequence between components, and the exception triggering points during the execution process, and constructing a dynamic execution trace graph reflecting the actual running behavior, including:

[0106] Load the executable code in the runtime environment, and insert probe instructions at the entry and exit points of the executable code's code module;

[0107] The test scripts in the test script set are executed sequentially. The probe instructions capture the value changes of the state variables during the execution of the executable code. The values ​​of each state variable at different execution times are recorded in timestamp order to generate the evolution trajectory of the state variables.

[0108] Monitor the interface call behavior between code modules in the executable code. When a call event is detected, obtain the caller module identifier and the callee module identifier through the probe instruction. Use the caller module identifier and the callee module identifier as the start and end points of the message passing event. Arrange all the message passing events according to the call time to form a message passing sequence between components.

[0109] During the execution of the executable code, abnormal signals are monitored. When the abnormal signal is captured, the value of the state variable corresponding to the abnormal trigger time is obtained from the evolution trajectory of the state variable, and the abnormal trigger point is determined by combining it with the module identifier recorded by the probe instruction.

[0110] Using code modules in the executable code as nodes and message passing events in the message passing sequence between components as directed edges, the evolution trajectory of the state variables is marked on the corresponding nodes, and the exception triggering points are marked on the exception attributes of the corresponding nodes to construct a dynamic execution tracing graph.

[0111] In one embodiment, a comprehensive technical solution combining probe instructions, status monitoring, and message tracing is employed to achieve dynamic behavior analysis of executable code. This solution first prepares a code analysis framework in the runtime environment, and then constructs a dynamic execution trace graph reflecting the actual runtime behavior of the program through a series of carefully designed steps.

[0112] When loading the executable code to be analyzed in the runtime environment, bytecode instrumentation technology is used to insert probe instructions at the entry and exit points of the code module. These probe instructions mainly include three types of functions: state variable collection, call event recording, and exception handling. In specific implementations, through techniques such as reflection or dynamic proxies, a pre-probe is inserted at the beginning of each method, and a post-probe is inserted at the return point and exception throwing point of each method. The pre-probe is responsible for recording method call parameters, execution start timestamp, and caller context information; the post-probe is responsible for recording return values, execution end timestamps, and method execution status.

[0113] After the probe commands are implanted, each test case in the test script set is executed sequentially. During execution, the probe commands automatically capture changes in state variables. For each monitored state variable, its value at different times is recorded, along with precise timestamp information. For example, when the variable "counter" in the program changes from 0 to 1, information like "Variable: counter, Value: 1, Timestamp: 1641036800123, Module: UserManager" is recorded. These records are organized in timestamp order, forming a complete evolution trajectory of the state variables. To reduce the amount of data, differential recording can be used, recording only the moments when the variable values ​​change.

[0114] The process of monitoring interface calls between code modules is achieved by intercepting method call events. When one module calls a method of another module, the caller module's identifier is obtained through a pre-probe, and the callee module's identifier is obtained through a probe on the called method. Each call is represented as a message passing event, containing data such as the starting module identifier, the ending module identifier, the call timestamp, the called method name, and parameter information. These message passing events are ordered by occurrence time to form a complete inter-component message passing sequence. For example, when module A calls module B's getUser method, it records "Starting point: ModuleA, Ending point: ModuleB, Method: getUser, Parameter: [id=123], Timestamp: 1641036800456".

[0115] During execution, the probe also monitors for exception signals. When the program throws an exception, the exception handling probe captures the exception and records relevant information. By accessing the exception object, it obtains data such as the exception type, exception message, and stack trace. Simultaneously, it extracts the values ​​of each state variable corresponding to the exception trigger moment from the previously recorded state variable evolution trajectory, providing crucial clues for subsequent analysis of the exception's root cause. Combined with the module identification information recorded by the probe, the exception trigger point can be precisely located, including the module, method, line number where the exception occurred, and the program state at that time.

[0116] Based on the collected data, a dynamic execution trace graph is constructed. In this graph, code modules are used as nodes, each containing static attributes such as module identifier and functional description, as well as dynamic attributes such as the evolution trajectory of state variables within the module. Message passing events are used as directed edges, with the direction of the edges indicating the call relationship, and information such as call time and method name is labeled on the edges. For nodes where exceptions occur, exception triggering information is specifically marked in their attributes, including exception type, triggering conditions, and associated state variables.

[0117] For example, in the order processing flow analysis of an e-commerce system, the above method can clearly show the entire execution path from when a user places an order to when payment is completed. When an order status anomaly occurs, the dynamic execution trace graph can intuitively show that the anomaly occurred in the inventory check module. The reason is that the inventory counter encountered a race condition under concurrent conditions, leading to an error in the inventory quantity calculation, which in turn triggered an insufficient quantity anomaly.

[0118] Dynamic execution trace graphs not only record program execution behavior but also reflect interaction patterns and data flow between modules. By analyzing the path characteristics in the graph, performance bottlenecks, concurrency issues, and exception handling defects in the program can be identified. Furthermore, the graph can support comparison of execution behavior differences under different test cases, providing a basis for regression testing and behavioral verification.

[0119] This dynamic execution tracing-based analysis method allows developers to gain a comprehensive view of the program's internal behavior, effectively pinpoint the root causes of complex problems, and optimize program structure and performance accordingly, thereby improving software quality and reliability.

[0120] In one optional implementation, the dynamic execution tracing graph is compared topologically with the execution dependency graph to identify uncovered execution paths and state transition deviations. Then, by tracing back the corresponding component configuration nodes in the intermediate abstract representation model, targeted supplementary test cases are automatically generated, including:

[0121] Analyze all nodes and directed edges in the execution dependency graph, construct an execution path set containing all theoretical execution paths, evaluate all nodes and directed edges in the dynamic execution tracing graph, construct a covered path set containing actual execution paths, calculate the difference between the execution path set and the covered path set, and obtain the uncovered execution paths.

[0122] Explore the uncovered execution paths, characterize the node sequence and edge condition sequence contained in each uncovered execution path, map and compare the node sequence with the executed node sequence in the dynamic execution tracing graph, and select the first unexecuted node as the coverage breakpoint.

[0123] From the coverage breakpoint, we extrapolate along the edge relationships of the execution dependency graph to the predecessor node, depict the triggering conditions carried by the edge relationships, perform constraint matching between the triggering conditions and the state variable evolution trajectory corresponding to the predecessor node, and analyze the state transition deviation that causes the coverage breakpoint not to be triggered.

[0124] Based on the state transition deviation study, the intermediate abstract representation model is confirmed, the component configuration node corresponding to the coverage breakpoint in the intermediate abstract representation model is identified, and the input parameter constraints and state transition rules associated with the component configuration node are summarized.

[0125] Based on the input parameter constraints, a test input vector that can satisfy the triggering condition is derived. Based on the state transition rules, a state sequence that makes the coverage breakpoint reachable is woven. The test input vector and the state sequence are combined to form a supplementary test case.

[0126] The topological comparison process between the dynamic execution tracing graph and the execution dependency graph utilizes a graph structure matching algorithm to align nodes and map edge relationships between the two directed graphs. The execution dependency graph analysis module traverses all nodes in the graph, extracting the identifier, component type, and state variable definition for each node. Simultaneously, it traverses all directed edges, extracting the starting node, ending node, and constraint information for each edge. The theoretical execution path set is constructed using a depth-first search algorithm, recursively traversing all node visit sequences starting from the entry node of the execution dependency graph until the exit node is reached, forming a complete execution path. Path representation uses a combination of node identifier sequences and edge condition sequences. Each path records the order of nodes it traverses and the combination of constraints that trigger path execution.

[0127] The dynamic execution trace graph analysis module uses the same data structure to process runtime information recorded during actual program execution. Nodes in the trace graph correspond to the actual component or function call points accessed during program execution; node attributes include execution timestamps, input parameter values, and output result values. Directed edges record the actual call relationships and data transfer processes between components; edge attributes include the number of calls, execution time, and the data type passed. The covered path set construction identifies the complete execution path actually triggered during program execution by analyzing the node access sequences in the trace graph. The path extraction algorithm arranges node access events in timestamp order and reconstructs the complete execution path sequence based on the call stack information.

[0128] The difference between the execution path set and the covered path set is calculated using a set operation algorithm, comparing each path in the theoretical execution path set with each path in the covered path set. Path comparison is based on exact matching of node sequences; when a theoretical path's node sequence cannot find a matching sequence in the covered path set, the theoretical path is marked as an uncovered execution path. The algorithm uses a hash table data structure to accelerate the path matching process, storing and retrieving path details using the hash value of the path's node sequence as the key and path information as the value. The uncovered path identification result includes the path identifier, path node sequence, path constraints, and the expected path execution complexity.

[0129] The uncovered execution path exploration process performs a detailed structural analysis of each uncovered path. The path node sequence characterization module extracts detailed information about each node on the path, including node type, input / output interface definitions, and internal state variables. The edge condition sequence characterization module analyzes the triggering conditions of each edge on the path, including variable references in conditional expressions, comparison operators, and threshold settings. The node sequence mapping and comparison algorithm compares the node sequence of the uncovered path with the executed node sequence in the dynamic execution trace graph, identifying the common prefix of the two sequences and the position of the first mismatched node. The coverage breakpoint filtering mechanism identifies the first mismatched node as a coverage breakpoint, which represents a critical control point that was not reached during program execution.

[0130] The predecessor node derivation process covering the breakpoint is analyzed by backtracking along the reverse edge relationships of the execution dependency graph. Starting from the breakpoint, the derivation algorithm searches for all incoming edges pointing to that node and identifies the starting nodes of these incoming edges as a candidate set of predecessor nodes. The edge relationship triggering condition description module extracts the constraint expression carried by each incoming edge and analyzes the state variables involved in the expression and the value constraints of these variables. The state variable evolution trajectory analysis reconstructs the numerical change process of the state variables corresponding to the predecessor node using historical data from the dynamic execution tracking graph. The constraint matching algorithm compares the variable constraints in the edge triggering conditions with the actual state variable evolution trajectory to identify the specific reasons why the triggering conditions are not met. The state transition deviation analysis results include the deviation type, deviation degree, and the direction of state adjustment required for correction.

[0131] The correlation analysis between state transition bias and intermediate abstract representation model establishes a correspondence between coverage breakpoints and model components through a model mapping mechanism. The model research module retrieves the corresponding component definition in the intermediate abstract representation model based on the node identifier of the coverage breakpoint. The component configuration node verification process verifies that the coverage breakpoint indeed corresponds to a specific component in the model and extracts the component's configuration parameters, input / output interfaces, and state transition rules. The input parameter constraint induction algorithm analyzes the component's input parameter definitions, extracting the parameter data type, value range, and validity check rules. The state transition rule induction algorithm extracts the component's state transition logic, including the triggering conditions for state transitions, state update operations, and output generation rules.

[0132] The supplementary test case generation process is based on the analysis results of input parameter constraints and state transition rules. The test input vector derivation algorithm calculates specific parameter value combinations that can satisfy the triggering conditions according to the input parameter constraints. The algorithm uses constraint solving techniques to handle complex parameter constraint relationships, and calculates the feasible solution space of parameters through linear programming or constraint satisfaction solvers. The state sequence weaving algorithm designs state evolution paths that make the coverage breakpoints reachable according to state transition rules. Starting from the current state, the algorithm gradually advances the state evolution according to the state transition rules until the target state that can trigger the coverage breakpoint is reached. The process of combining the test input vector and the state sequence pairs the parameter settings with the state evolution path to form a complete test case definition.

[0133] The supplementary test case data structure includes a test case identifier, input parameter vector, expected state sequence, target breakpoint coverage, and expected execution result. The test case verification mechanism verifies through simulated execution that the generated test cases can indeed trigger the target breakpoints, ensuring the validity of the test cases. The test case optimization algorithm filters and merges multiple generated candidate test cases, reducing the number of redundant test cases and improving test execution efficiency. Test case storage uses a structured format, supporting automated loading and execution by the test framework.

[0134] In one optional implementation, the intermediate abstract representation model is studied based on the state transition deviation to confirm the component configuration node corresponding to the coverage breakpoint in the intermediate abstract representation model, and the input parameter constraints and state transition rules associated with the component configuration node are summarized as follows:

[0135] The difference between the actual state value and the expected state value is evaluated from the state transition deviation. Component configuration nodes are explored in the intermediate abstract representation model and a candidate node set is established. For each candidate node in the candidate node set, the association between its predecessor node identifier and successor node identifier in the intermediate abstract representation model is described, and a local topology structure reflecting the relationship between nodes is constructed.

[0136] The predecessor node identifier and the successor node identifier are projected onto the intermediate abstract representation model. By calculating the structural matching degree between the local topology and the predecessor and successor identifiers of the coverage breakpoint, the candidate node with the optimal structural matching degree is determined as the component configuration node corresponding to the coverage breakpoint.

[0137] The state transition relationships of the component configuration nodes are analyzed, whereby the state transition relationships describe the mapping logic between the input parameter values ​​and the state variable values. The mapping logic is expanded into conditional judgment expressions and state update expressions, and the conditional judgment expressions and the state update expressions are integrated to form a systematic state transition rule.

[0138] like Figure 2 As shown, the method includes:

[0139] The state transition deviation analysis process calculates the specific differences between the actual and expected state values ​​through a difference feature assessment module. The difference feature assessment employs a multi-dimensional comparison algorithm to quantify the numerical, type, and range differences of the state variables. Numerical difference calculation combines absolute and relative differences; when the state variable is numerical, it calculates the absolute difference between the actual and expected values, while also calculating the percentage deviation relative to the expected value. Type difference analysis checks whether the data types of the actual and expected state variables match, including consistency checks for basic data types, composite data types, and custom data types. Range difference assessment determines whether the actual state value falls within the valid range of the expected state value, using an interval comparison algorithm to determine the specific degree to which it exceeds the range.

[0140] The intermediate abstraction represents the construction of the candidate node set in the model through a component configuration node exploration mechanism. This mechanism uses a depth-first traversal algorithm to scan all component nodes in the model, extracting the state variable definitions, input / output interfaces, and transformation rule configurations for each node. Candidate node selection is initially filtered based on state variable matching degree, calculating the degree of matching between the model node's state variable definitions and the state variables involved in the deviation analysis results. The matching degree calculation considers three dimensions: variable name similarity, data type compatibility, and value range overlap, using a weighted average method to generate a comprehensive matching score. Nodes with a matching score exceeding a preset threshold of 0.6 are included in the candidate node set. This threshold is based on empirical data statistics and can be adjusted within the range of 0.5 to 0.8 depending on the specific application scenario.

[0141] The local topology construction process analyzes the predecessor-successor relationships for each candidate node in the candidate node set. Predecessor node identification extraction identifies all upstream nodes that provide data or control signals to a candidate node by analyzing its input dependencies. The extraction algorithm traverses the set of directed edges in the intermediate abstract representation model, searching for edges ending at candidate nodes and recording the starting node identifiers and weights of these edges. Successor node identification extraction uses the same algorithm logic, searching for edges starting at candidate nodes and recording the ending node identifiers and corresponding edge attributes. Association characteristics are described in two types: direct association and indirect association. Direct association refers to direct edge connections between nodes, while indirect association refers to transitive relationships formed through intermediate nodes.

[0142] The local topology is represented using an adjacency matrix data structure. Rows and columns of the matrix correspond to node identifiers, and matrix elements represent the connection relationships and strengths between nodes. Connection strength is calculated by combining edge weights, data transmission frequency, and dependency tightness, with values ​​ranging from 0 to 1, where 0 represents no connection and 1 represents the strongest connection. The structure construction process maintains a node attribute hash table, recording the type identifier, state variable list, and transformation rule summary for each node. The topology also includes a path length matrix, recording the shortest path length between any two nodes, used for subsequent structure matching degree calculations.

[0143] The predecessor-successor identification projection process for covering breakpoints maps the position information of the covering breakpoints in the execution dependency graph to the node space of the intermediate abstract representation model. The projection algorithm establishes the correspondence between nodes in the execution dependency graph and nodes in the intermediate abstract representation model, determining the mapping relationship through three methods: node identifier matching, functional semantic matching, and interface signature matching. Node identifier matching uses a string matching algorithm to calculate the edit distance and common substring length of the identifiers. Functional semantic matching analyzes the functional description and annotation information of the nodes, using a text similarity algorithm to calculate the semantic matching degree. Interface signature matching compares the input and output parameter lists of the nodes, calculating the degree of matching in parameter type, parameter quantity, and parameter name.

[0144] The structural matching degree calculation employs a variant of the graph isomorphism detection algorithm to evaluate the matching between the local topology and the environment of the coverage breakpoint. The algorithm calculates the structural similarity between the local topology of candidate nodes and the predecessor and successor structures of the coverage breakpoint. The similarity calculation is based on three indicators: node degree distribution, path length distribution, and connection pattern matching. The node degree distribution compares the in-degree and out-degree distributions of each node in the local topology, calculating the degree of difference between this distribution and that in the coverage breakpoint environment. The path length distribution statistically analyzes the shortest path length distribution between each pair of nodes in the local topology and compares it with the path length distribution in the coverage breakpoint environment. Connection pattern matching detects whether the edge connection patterns of the local topology have similar topological features to the connection patterns in the coverage breakpoint environment.

[0145] The candidate node with the best structural matching degree is determined through a multi-index comprehensive scoring mechanism. This mechanism weights structural similarity, state variable matching degree, and functional semantic matching degree, with weights allocated as follows: structural similarity 0.5, state variable matching degree 0.3, and functional semantic matching degree 0.2. The candidate node with the highest comprehensive score is determined as the component configuration node corresponding to the coverage breakpoint. This node assumes the same functional role as the coverage breakpoint in the intermediate abstract representation model. The determination process also includes a rationality verification step, checking whether the input / output interfaces of the selected node are compatible with the interface requirements of the coverage breakpoint to ensure the correctness of the mapping relationship.

[0146] The component configuration node state transition relationship analysis delves into the internal state change logic of nodes through a relationship extraction module. The state transition relationship extraction algorithm scans the state variable definitions, transition trigger conditions, and state update operations in the node configuration to construct a complete state transition relationship graph. This graph is represented using a finite state machine model, where state nodes correspond to different operating states of the component, and state transition edges correspond to the trigger conditions and update operations for state changes. The mapping logic between input parameter values ​​and state variable values ​​is described through a function mapping table, which records the state variable update rules corresponding to specific combinations of input parameter values.

[0147] The mapping logic expansion process decomposes complex state transition relationships into executable conditional statements and state update expressions. The conditional statement extraction algorithm analyzes the triggering conditions of state transitions, converting the conditional logic into the standard form of Boolean expressions. These expressions include variable references, comparison operators, logical connectors, and constant values, supporting nested conditions and complex logic representations. The state update expression extraction algorithm analyzes the specific operations of state changes, including assignment operations, mathematical operations, function calls, and various update modes such as conditional assignment. The expressions employ a syntax structure similar to programming languages, ensuring their executableness and explicitness.

[0148] The integration process of conditional statements and state update expressions constructs a systematic set of state transition rules. This integration process employs a rule template approach, combining conditional statements and state updates into a standard "if condition, update" rule format. The rule set is prioritized, with higher-priority rules executed first in case of conflicts. Priority is determined based on a combination of condition complexity and update importance. The state transition rules also include precondition checks and postcondition verifications to ensure the legality and consistency of state transitions. Precondition checks verify whether the current state meets the basic requirements for transition, while postcondition verification confirms whether the updated state variable values ​​are within a valid range.

[0149] A second aspect of this invention provides a system for rapid application generation and automated testing based on a low-code platform, comprising:

[0150] The conversion module is used to obtain the application logic description defined by the user through the graphical orchestration interface and convert the application logic description into an intermediate abstract representation model.

[0151] The derivation module is used to construct a directed acyclic execution dependency graph based on the intermediate abstract representation model. By performing path analysis and state space traversal on the execution dependency graph, it identifies the combination of variables that trigger state transitions and their constraint boundaries, and uses the constraint boundaries to derive a test input space that can cover multiple path branches and boundary conditions.

[0152] The execution module is used to map the intermediate abstract representation model into executable code, and generate a test script set based on the test input space; execute the executable code and the test script set in the runtime environment, capture the evolution trajectory of state variables, the message passing sequence between components and the exception triggering point during the execution process, and construct a dynamic execution trace graph that reflects the actual running behavior;

[0153] The annotation module is used to perform a topological comparison between the dynamic execution tracing graph and the execution dependency graph, identify uncovered execution paths and state transition deviations, automatically generate targeted supplementary test cases by tracing back the corresponding component configuration nodes in the intermediate abstract representation model, and annotate the basis for the generation of the supplementary test cases in the form of dependency chains at the corresponding positions in the graphical orchestration interface.

[0154] A third aspect of the present invention provides an electronic device, comprising:

[0155] processor;

[0156] Memory used to store processor-executable instructions;

[0157] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0158] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0159] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0160] Finally, it should be noted that the above embodiments 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 the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for rapid application generation and automated testing based on a low-code platform, characterized in that, include: Obtain the application logic description defined by the user through the graphical orchestration interface, and convert the application logic description into an intermediate abstract representation model; Based on the intermediate abstract representation model, a directed acyclic execution dependency graph is constructed. By performing path analysis and state space traversal on the execution dependency graph, the combination of variables that trigger state transitions and their constraint boundaries are identified. The constraint boundaries are then used to derive a test input space that can cover multiple path branches and boundary conditions. The intermediate abstract representation model is mapped to executable code, and a test script set is generated based on the test input space. The executable code and the test script set are executed in the runtime environment to capture the evolution trajectory of state variables, the message passing sequence between components, and the exception triggering point during the execution process, and to construct a dynamic execution trace graph that reflects the actual running behavior. The dynamic execution tracing graph is compared with the execution dependency graph to identify uncovered execution paths and state transition deviations. By tracing back the corresponding component configuration nodes in the intermediate abstract representation model, targeted supplementary test cases are automatically generated. The basis for generating the supplementary test cases is marked in the form of a dependency chain at the corresponding position in the graphical orchestration interface.

2. The method according to claim 1, characterized in that, Based on the intermediate abstract representation model, a directed acyclic execution dependency graph is constructed. By performing path analysis and state space traversal on the execution dependency graph, the combinations of variables that trigger state transitions and their constraint boundaries are identified. Using the constraint boundaries, a test input space that can cover multiple path branches and boundary conditions is derived, including: Evaluate the dependencies and state transition rules of components in the intermediate abstract representation model, construct the node representation of each component in the execution dependency graph, and depict the data flow and control flow dependencies between components as directed edges to generate a directed acyclic execution dependency graph that reflects the application execution logic. Based on the nodes and directed edges in the execution dependency graph, a depth-first strategy is used to traverse and explore the paths, sort out all complete execution paths from the entry node to the exit node, and characterize the node sequence and edge condition sequence traversed by the complete execution path. For the edge condition sequence, the set of variables affecting path reachability is summarized, and variable constraint expressions are derived based on the edge condition sequence. By analyzing the variable constraint expressions, the variable value boundaries of the complete execution path are determined. The variable value boundaries are integrated and duplicates are excluded. The combination of variable critical values ​​and boundary values ​​that can trigger different path branches is selected. A test input space containing execution path coverage information is constructed based on the variable critical values ​​and boundary value combinations.

3. The method according to claim 2, characterized in that, Based on the nodes and directed edges in the execution dependency graph, a depth-first search strategy is used to traverse and explore the paths, identifying all complete execution paths from the entry node to the exit node, and characterizing the node sequences and edge condition sequences traversed by all complete execution paths, including: Identify the node with an in-degree of zero in the execution dependency graph as the entry node, push the entry node as the starting node onto the path traversal stack, and initialize the path record container to store the node sequence and edge condition sequence of the current exploration path. Pop the top node from the path traversal stack as the current node, append the current node to the node sequence of the path record container, and query the execution dependency graph to obtain all outgoing edges starting from the current node and their pointing successor nodes. For each outgoing edge, extract the edge conditions it carries, and append the edge conditions to the edge condition sequence of the path recording container in sequence. Then determine whether the successor node is an exit node with an outgoing degree of zero. If the successor node is an exit node, the node sequence and edge condition sequence in the path record container are combined to form a complete execution path and stored in the path set. If the successor node is not an exit node, the successor node is pushed onto the path traversal stack and traversal continues until the path traversal stack is empty, thus obtaining all complete execution paths from the entry node to the exit node and their node sequences and edge condition sequences.

4. The method according to claim 1, characterized in that, Mapping the intermediate abstract representation model to executable code, and simultaneously generating a test script set based on the test input space, includes: The intermediate abstract representation model is parsed to define the components and state transition rules, map each component to a corresponding code module structure, map the data flow between components to the interface call relationship between code modules, and map the state transition rules to control flow logic, generating executable code containing data processing logic and control flow logic; Extract each test input vector and its corresponding path coverage information from the test input space. The path coverage information identifies the execution path and state transition sequence that can be activated by the corresponding test input vector. Based on the path coverage information, the intermediate abstract representation model is traced back to identify the component sequence and data constraints involved in the execution path. Based on the component sequence, the order of code module interfaces that the test script needs to call is determined. Based on the data constraints, assertion expressions are generated. The test input vector, the order of code module interfaces, and the assertion expressions are combined to form a test script. The test scripts corresponding to all test input vectors are summarized to form a test script set.

5. The method according to claim 1, characterized in that, The executable code and the test script set are executed in the runtime environment, capturing the evolution trajectory of state variables, the message passing sequence between components, and the exception triggering points during the execution process, and constructing a dynamic execution trace graph that reflects the actual running behavior, including: Load executable code in the runtime environment, and insert probe instructions at the entry and exit points of the executable code's code module; The test scripts in the test script set are executed sequentially. The probe instructions capture the value changes of the state variables during the execution of the executable code. The values ​​of each state variable at different execution times are recorded in timestamp order to generate the evolution trajectory of the state variables. Monitor the interface call behavior between code modules in the executable code. When a call event is detected, obtain the caller module identifier and the callee module identifier through the probe instruction. Use the caller module identifier and the callee module identifier as the start and end points of the message passing event. Arrange all the message passing events according to the call time to form a message passing sequence between components. During the execution of the executable code, abnormal signals are monitored. When the abnormal signal is captured, the value of the state variable corresponding to the abnormal trigger time is obtained from the evolution trajectory of the state variable, and the abnormal trigger point is determined by combining it with the module identifier recorded by the probe instruction. Using code modules in the executable code as nodes and message passing events in the message passing sequence between components as directed edges, the evolution trajectory of the state variables is marked on the corresponding nodes, and the exception triggering points are marked on the exception attributes of the corresponding nodes to construct a dynamic execution tracing graph.

6. The method according to claim 1, characterized in that, By performing a topological comparison between the dynamic execution tracing graph and the execution dependency graph, uncovered execution paths and state transition deviations are identified. Then, by tracing back the corresponding component configuration nodes in the intermediate abstract representation model, targeted supplementary test cases are automatically generated, including: Analyze all nodes and directed edges in the execution dependency graph, construct an execution path set containing all theoretical execution paths, evaluate all nodes and directed edges in the dynamic execution tracing graph, construct a covered path set containing actual execution paths, calculate the difference between the execution path set and the covered path set, and obtain the uncovered execution paths. Explore the uncovered execution paths, characterize the node sequence and edge condition sequence contained in each uncovered execution path, map and compare the node sequence with the executed node sequence in the dynamic execution tracing graph, and select the first unexecuted node as the coverage breakpoint. From the coverage breakpoint, we extrapolate along the edge relationships of the execution dependency graph to the predecessor node, depict the triggering conditions carried by the edge relationships, perform constraint matching between the triggering conditions and the state variable evolution trajectory corresponding to the predecessor node, and analyze the state transition deviation that causes the coverage breakpoint not to be triggered. Based on the state transition deviation study, the intermediate abstract representation model is confirmed, the component configuration node corresponding to the coverage breakpoint in the intermediate abstract representation model is identified, and the input parameter constraints and state transition rules associated with the component configuration node are summarized. Based on the input parameter constraints, a test input vector that can satisfy the triggering condition is derived. Based on the state transition rules, a state sequence that makes the coverage breakpoint reachable is woven. The test input vector and the state sequence are combined to form a supplementary test case.

7. The method according to claim 6, characterized in that, Based on the state transition deviation study of the intermediate abstract representation model, the component configuration node corresponding to the coverage breakpoint in the intermediate abstract representation model is confirmed, and the input parameter constraints and state transition rules associated with the component configuration node are summarized as follows: The difference between the actual state value and the expected state value is evaluated from the state transition deviation. Component configuration nodes are explored in the intermediate abstract representation model and a candidate node set is established. For each candidate node in the candidate node set, the association between its predecessor node identifier and successor node identifier in the intermediate abstract representation model is described, and a local topology structure reflecting the relationship between nodes is constructed. The predecessor node identifier and the successor node identifier are projected onto the intermediate abstract representation model. By calculating the structural matching degree between the local topology and the predecessor and successor identifiers of the coverage breakpoint, the candidate node with the optimal structural matching degree is determined as the component configuration node corresponding to the coverage breakpoint. The state transition relationships of the component configuration nodes are analyzed, whereby the state transition relationships describe the mapping logic between the input parameter values ​​and the state variable values. The mapping logic is expanded into conditional judgment expressions and state update expressions, and the conditional judgment expressions and the state update expressions are integrated to form a systematic state transition rule.

8. A rapid application generation and automated testing system based on a low-code platform, used to implement the method of any one of claims 1-7, characterized in that, include: The conversion module is used to obtain the application logic description defined by the user through the graphical orchestration interface and convert the application logic description into an intermediate abstract representation model. The derivation module is used to construct a directed acyclic execution dependency graph based on the intermediate abstract representation model. By performing path analysis and state space traversal on the execution dependency graph, it identifies the combination of variables that trigger state transitions and their constraint boundaries, and uses the constraint boundaries to derive a test input space that can cover multiple path branches and boundary conditions. An execution module is used to map the intermediate abstract representation model into executable code, and at the same time generate a test script set based on the test input space; The executable code and the test script set are executed in the runtime environment to capture the evolution trajectory of state variables, the message passing sequence between components, and the exception triggering points during the execution process, and to construct a dynamic execution trace graph that reflects the actual running behavior. The annotation module is used to perform a topological comparison between the dynamic execution tracing graph and the execution dependency graph, identify uncovered execution paths and state transition deviations, automatically generate targeted supplementary test cases by tracing back the corresponding component configuration nodes in the intermediate abstract representation model, and annotate the basis for the generation of the supplementary test cases in the form of dependency chains at the corresponding positions in the graphical orchestration interface.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images