A software automated testing method and system

Abstract

This application proposes a software automated testing method and system, relating to the field of software testing technology. The method includes: constructing a directed acyclic graph (DAG), identifying call path fragments, and constructing test input data; driving the software system under test to execute a test run and generating new function call information; converting the new function call information into a sequence of new nodes, and performing structural difference analysis with historical test run records to generate a cumulative composite difference value; if the cumulative composite difference value is greater than a preset threshold, storing the test input data in a pre-constructed test case library as a new test case, forming an updated test case library; and executing multiple rounds of test runs on the software system under test based on the updated test case library. This allows potential defect paths that were previously continuously uncovered to be systematically discovered, reproduced, and solidified, fundamentally alleviating the dilemma of insufficient accuracy and resource waste caused by the non-evolving nature of testing behavior.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a software automated testing method and system. Background Technology

[0002] In the context of increasingly complex and rapidly iterating software systems, the core technical bottleneck facing automated testing lies in the fact that mainstream testing methods heavily rely on static, pre-built test case sets. They cannot dynamically generate and evolve test inputs based on the actual function call behavior during program execution, resulting in significantly limited testing accuracy and efficiency. Specifically, existing testing frameworks typically generate a batch of fixed inputs (such as interface specification-based examples, historical defect reproduction cases, etc.) manually or semi-automatically before testing and repeatedly use these static test cases in subsequent execution. However, these test cases only cover the pre-defined call paths during design and cannot detect new function call sequences generated by changes in parameter combinations, environmental states, or external dependencies during actual system operation. Even with probes or log monitoring, existing technologies lack the ability to transform the collected function call information into a structured execution graph, thus failing to systematically identify "which consecutive function call chains have not yet been triggered by any static test cases." Consequently, it is impossible to reverse-engineer replayable test inputs from newly discovered call paths, nor can high-value behaviors be automatically precipitated into effective test cases. This leaves a large number of potential defect paths continuously uncovered, further exacerbating the dilemma of insufficient testing accuracy and wasted resources. Summary of the Invention

[0003] This application aims to at least partially address one of the technical problems in the related art.

[0004] To achieve the above objectives, this application proposes a software automated testing method and system, comprising the following steps: Step 1: Based on the software system under test, obtain the function call information for each function call event in real time: call identifier, input parameters, actual values ​​of input parameters, and return value; Step 2: Construct a directed acyclic graph based on the function call information. The directed acyclic graph includes several nodes and directed edges. Each node corresponds to a function call event. The node includes the call identifier, the actual value of the input parameters, and the return value. The directed edges represent the execution order of the function call events corresponding to adjacent nodes. Step 3: Identify call path segments based on the directed acyclic graph; Step 4: Based on the call path fragment, construct test input data according to the actual values ​​of the input parameters; Step 5: Drive the software system under test to perform a test run based on the test input data, and generate new function call information; Step 6: Convert the new function call information into a sequence of new nodes, and perform structural difference analysis with historical test run records to generate a cumulative composite difference value. If the cumulative composite difference value is greater than a preset threshold, store the test input data into a pre-built test case library as a new test case to form an updated test case library. Perform multiple rounds of test runs on the software system under test based on the updated test case library.

[0005] Identifying call path segments based on the directed acyclic graph includes the following steps: Step 31: Calculate the out-degree and in-degree of each node in the directed acyclic graph; Step 32: Traverse the directed acyclic graph, identify all nodes with an in-degree of zero as entry nodes, and identify all nodes with an out-degree of zero as exit nodes. Step 33: Based on the entry node as the starting point and the exit node as the ending point, construct several complete call paths according to the starting point and the ending point; define each complete call path as a sequence of node identifiers arranged in the execution order, wherein each node identifier is a unique identifier composed of the call identifier of the corresponding node and the actual value of the input parameter. Step 34: Based on each test case in the pre-built test case library, obtain the first function call information in the historical test execution, and construct the covered node identifier sequence according to the first function call information; Step 35: Identify continuous subsequences based on the node identifier sequence, and determine whether the continuous subsequence contains the covered node identifier sequence. If so, define the covered node identifier sequence as a continuous sequence; otherwise, define the continuous subsequence as an uncovered call path fragment.

[0006] Based on the aforementioned call path fragment, test input data is constructed according to the actual values ​​of the input parameters, including the following steps: Step 41: Based on the call path fragment, extract the input parameters and actual values ​​of the first node as the initial parameter assignment set; Step 42: Check whether the actual value of the input parameter in the initial parameter assignment set is empty. If so, determine the corresponding input parameter based on the actual value of the input parameter corresponding to the empty value. Step 43: Obtain historical records, determine the frequency of actual values ​​of input parameters based on historical records and input parameters, and use the highest value of the frequency of actual values ​​of input parameters as the padding value; Step 44: Replace the empty values ​​in the initial parameter assignment set with the padded values, and use the input parameters and their corresponding actual and padded values ​​as test input data.

[0007] The new function call information is converted into a sequence of new nodes, and structural difference analysis is performed with historical test run records to generate a cumulative composite difference value. If the cumulative composite difference value is greater than a preset threshold, the test input data is stored in a pre-built test case library as a new test case, including the following steps: Step 61: Convert the new function call information into a sequence of new nodes, wherein each new node includes a call identifier, input parameters, actual values ​​of the input parameters, a return value, and an exception flag; wherein the exception flag includes true or false. Step 62: Obtain the set of historical node sequences, and filter out a subset of candidate historical sequences based on the set of historical node sequences, where the call identifier of the starting node is the same as the call identifier of the starting node of the new node sequence, and the call identifier of the ending node is the same as the call identifier of the ending node of the new node sequence. Step 63: Obtain the cumulative value of composite difference; Step 64: Calculate the cumulative composite difference value for each historical sequence in the subset of candidate historical sequences, based on the cumulative composite difference value, the call identifier, the input parameters, and the actual values ​​of the input parameters. Step 65: If the cumulative value of the composite difference is greater than the preset threshold and the abnormal flag of the newly added node in the new node sequence is true, then the test input data is stored in the pre-built test case library as a new test case; otherwise, the process ends.

[0008] The calculation of the cumulative composite difference value includes the following steps: Step 641: Initialize the cumulative composite difference value to zero; initialize the parameter difference value list to empty; Step 642: Traverse the newly added node sequence and the candidate historical sequence subset to call the mapping node pairs with the same identifier, and determine the input parameter set based on the mapping node pairs; Step 643: Determine the cumulative value of composite difference and the number of effective parameters based on the data type of the actual values ​​of the input parameters in the input parameter set; Step 644: Extract the call identifier combination of all adjacent newly added node pairs in the newly added node sequence to form the first call transfer sequence; extract the call identifier combination of all adjacent node pairs in the candidate historical sequence subset to form the second call transfer sequence. Step 645: If the lengths of both the first call transfer sequence and the second call transfer sequence are greater than or equal to the target length, then the first occurrence frequency of the call identifier combination of adjacent newly added node pairs in the first call transfer sequence is counted, and a first frequency distribution is constructed based on the first occurrence frequency; simultaneously, the second occurrence frequency of the call identifier combination of adjacent node pairs in the second call transfer sequence is counted, and a second frequency distribution is constructed based on the second occurrence frequency; and the KL divergence between the first frequency distribution and the second frequency distribution is calculated, and the KL divergence is accumulated to the cumulative composite difference value; otherwise, skip this step. Step 646: If there is a first newly added node with an anomaly flag set to true in the newly added node sequence, record the number of newly added nodes from the first first newly added node to the end of the newly added node sequence as the first anomaly propagation length; if there is a first node with an anomaly flag set to true in the candidate historical sequence subset, record the number of nodes from the first first node to the end of the candidate historical sequence as the second anomaly propagation length; calculate the normalized anomaly difference value based on the difference between the first anomaly propagation length and the second anomaly propagation length, and accumulate the normalized anomaly difference value to the composite difference cumulative value; otherwise, skip this step.

[0009] Determining the cumulative composite difference value and the number of valid parameters based on the data type of the actual values ​​of the input parameters in the input parameter set includes the following steps: Step 6431: Based on each input parameter in the set of input parameters, determine whether the actual values ​​of the input parameters of the mapping node pair are all numerical. If so, calculate the relative error value based on the actual values ​​of the input parameters of the mapping node pair. Add the relative error value to the parameter difference value list and increment the number of valid parameters by one. If the actual values ​​of the input parameters of the mapping node pair are all strings, then the normalized edit distance value is calculated based on the actual values ​​of the input parameters of the mapping node pair, the normalized edit distance value is added to the parameter difference value list, and the number of valid parameters is incremented by one; Otherwise, skip; Step 6431: If the number of valid parameters is greater than zero, calculate the arithmetic mean of the normalized edit distance value and the relative error value in the parameter difference value list, and add the arithmetic mean to the cumulative composite difference value; otherwise, skip this step.

[0010] The present invention also includes determining the priority weight of the updated test case library, which is used to filter test cases for each round of test execution.

[0011] This invention also discloses a software automated testing system, comprising the following modules: Data acquisition module: Used to acquire function call information for each function call event in real time based on the software system under test; Data processing module: used to construct a directed acyclic graph based on the function call information; Identification module: used to identify call path segments based on the directed acyclic graph; Data reconstruction module: used to construct test input data based on the actual values ​​of the input parameters according to the call path fragment; Test module: Used to drive the software system under test to perform a test run using the test input data and generate new function call information; The update module is used to convert the new function call information into a sequence of new nodes and perform structural difference analysis with historical test run records to generate a cumulative composite difference value. If the cumulative composite difference value is greater than a preset threshold, the test input data is stored in a pre-built test case library as a new test case to form an updated test case library. Based on the updated test case library, multiple rounds of test runs are performed on the software system under test.

[0012] Compared with existing technologies, the software automation testing method and system provided in this application transforms the dynamic execution process of a program into a structured sequence of nodes by collecting function call information during runtime in real time. Based on this, it systematically identifies continuous sub-sequences of nodes and, by comparing them with historical coverage paths in a pre-built test case library, accurately locates call path fragments that have not been fully triggered by any static test cases, precisely identifying "which continuous function call chains have not yet been triggered by any static test cases." Subsequently, it constructs executable structured test inputs based solely on the parameter values ​​of the first node of this fragment, enabling the reverse generation of replayable and driveable test input data from newly discovered call paths, ensuring that new test cases can directly drive the system to reproduce the target path. After execution, if the new run exhibits behavior significantly different from historical trajectories and exposes anomalies, its corresponding input is stored in the test case library as a newly added high-value test case. It directly solves the problem of broken chains in existing technologies, such as the inability to identify uncovered call chains, construct corresponding inputs, and accumulate effective test cases. It enables potential defect paths that were previously in an uncovered state to be systematically discovered, reproduced, and solidified. It fundamentally alleviates the dilemma of insufficient accuracy and waste of resources caused by the non-evolvability of testing behavior, and significantly improves the deep coverage capability and defect exposure efficiency of automated testing in complex software systems. Attached Figure Description

[0013] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 A flowchart illustrating a software automated testing method provided in an embodiment of this application; Figure 2 This is a structural diagram of a software automated testing system provided in an embodiment of this application; Figure 3 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0015] The following description, with reference to the accompanying drawings, illustrates an embodiment of a software automated testing method and system.

[0016] like Figure 1 As shown, a software automated testing method includes the following steps: Step 1: Based on the software system under test, obtain the function call information for each function call event in real time: call identifier, input parameters, actual values ​​of input parameters, and return value.

[0017] In this embodiment, a probe module is deployed in the software system under test. This probe module is configured to automatically intervene in every function call event during program execution and record the corresponding function call information in real time. Specifically, when the program execution flow reaches the entry point of a function and an actual call occurs (i.e., function execution is dynamically triggered at runtime), the probe module captures this call behavior through low-level instrumentation mechanisms (such as bytecode injection, dynamic link library interception, or runtime hooks), without manual intervention or modification of the source code. The recorded function call information includes: a call identifier that uniquely identifies the function (e.g., composed of the function name, its module, and parameter types), the names of each input parameter passed in the call (input parameters) and their corresponding actual values ​​(i.e., the specific data values ​​passed at runtime), and the return value generated after the function execution (including normal return results or exception objects). This information comprehensively characterizes the behavioral features of the function in the real execution context. By continuously collecting such data during program execution, the probe module provides the basic material for the subsequent construction of a directed acyclic graph (DAG) that reflects the actual execution path. This enables the system to identify uncovered behavioral segments based on the real call sequence and further generate test inputs that can reproduce the path, thereby supporting the dynamic evolution and accurate coverage of automated testing.

[0018] Step 2: Construct a directed acyclic graph based on the function call information. The directed acyclic graph includes several nodes and directed edges. Each node corresponds to a function call event. The node includes the call identifier, the actual value of the input parameters, and the return value. The directed edges represent the execution order of the function call events corresponding to adjacent nodes.

[0019] This embodiment constructs a directed acyclic graph (DAG) to structurally represent the actual execution behavior of the program. Specifically, each recorded function call event is mapped to a node in the DAG. This node contains complete context information: a call identifier (used to uniquely identify the called function), the actual values ​​of each input parameter (i.e., the specific data passed in at runtime), and the return value generated by the call. Simultaneously, based on the chronological order of function call events on the timeline, adjacent call events are connected by a directed edge, with the arrow direction indicating the execution flow, thus forming a DAG that reflects the actual call dependencies. For example, if the program executes function A → function B → function C in a single run, three nodes will be generated in the DAG, connected by directed edges A→B and B→C, forming a path of length 3. Unlike existing technologies that rely solely on static control flow graphs or isolated coverage statistics, the DAG constructed in this scheme deeply integrates dynamic execution context (parameter values, return values) and call sequence relationships, not only depicting "which functions were called," but also precisely expressing "under what parameter conditions and in what order they were called." It can identify semantic-level behavioral differences. For example, even with the same call sequence A→B→C, if the input parameters or return value of B are different, they are considered different path segments. Therefore, compared to traditional methods that cannot distinguish context-sensitive call chains, this solution provides a solid data foundation for accurately identifying uncovered behaviors, generating targeted test inputs, and quantifying behavioral differences by constructing a directed acyclic graph based on real-world execution trajectories. This fundamentally improves the ability of automated testing to perceive complex interaction logic and its coverage depth.

[0020] Step 3, identifying call path segments based on the directed acyclic graph, includes the following steps: Step 31: Calculate the out-degree and in-degree of each node in the directed acyclic graph.

[0021] In this embodiment, topological analysis is performed on each node in the directed acyclic graph (DAG), specifically including calculating the in-degree and out-degree of each node. The in-degree refers to the number of directed edges pointing to that node, reflecting how many preceding function calls triggered the function call event; the out-degree refers to the number of directed edges originating from that node, indicating how many subsequent function calls were directly triggered after the function call.

[0022] Step 32: Traverse the directed acyclic graph, identify all nodes with an in-degree of zero as entry nodes, and identify all nodes with an out-degree of zero as exit nodes.

[0023] In this embodiment, all nodes are scanned. Nodes with an in-degree of zero are marked as entry nodes. These nodes are not preceded by any other function calls and represent the starting point of a call chain. They usually correspond to entry functions triggered by external requests (such as API interface processing functions, main program entry points, or event callbacks). At the same time, nodes with an out-degree of zero are marked as exit nodes. These nodes do not trigger any subsequent function calls and represent the ending point of the call chain. They may correspond to underlying I / O operations, return responses, or abnormal termination.

[0024] Step 33: Based on the entry node as the starting point and the exit node as the ending point, construct several complete call paths according to the starting point and the ending point; define each complete call path as a sequence of node identifiers arranged in the execution order, wherein each node identifier is a unique identifier composed of the call identifier of the corresponding node and the actual value of the input parameter.

[0025] In a directed acyclic graph, a depth-first search (DFS) or breadth-first search (BFS) is performed to traverse all reachable paths from any entry node to any exit node, thus constructing several complete call paths. Each complete call path represents the end-to-end function call sequence that the program may experience in a single execution. Furthermore, each complete call path is represented as a sequence of node identifiers strictly arranged in execution order, where each node identifier is a unique identifier generated by concatenating the call identifier corresponding to that node with the actual value of the input parameter. This ensures that even if the same function is called multiple times, as long as its input parameter values ​​are different, it is considered a different node identifier, thus accurately distinguishing semantically different execution contexts. By structuring complete call paths into a sequence of node identifiers containing parameter contexts, the dynamic semantics of program behavior can be accurately characterized, providing a high-fidelity, comparable data foundation for subsequent identification of uncovered continuous sub-path segments.

[0026] Step 34: Based on each test case in the pre-built test case library, obtain the first function call information in the historical test execution, and construct the covered node identifier sequence according to the first function call information.

[0027] In this embodiment, the pre-built test case library initially contains only a set of executable test input data (e.g., API request parameters, command-line parameters, or configuration files), and does not directly contain any node identifier sequences. These test cases can originate from unit tests, interface test scripts, historical defect reproduction cases written by developers, or seed inputs initially generated through fuzzing. To support path coverage analysis, the system needs to re-execute each test case in the test case library: in a controlled environment, the input data of the test case is used to drive the software system under test to run, while the probe module records all function call events generated during this run, forming the first function call information. Subsequently, following the same rules as the current analysis process, for each function call event, its call identifier and the actual values ​​of each input parameter are extracted, combined to generate a unique node identifier, and arranged according to the execution sequence, converting all call behaviors triggered by this run into a covered node identifier sequence. This sequence is temporarily or persistently associated with the corresponding test case as its behavior fingerprint. By traversing all test cases in the test case library and repeating the above process, a complete set of covered node identifier sequences is finally constructed.

[0028] Step 35: Identify continuous subsequences based on the node identifier sequence, and determine whether the continuous subsequence contains the covered node identifier sequence. If so, define the covered node identifier sequence as a continuous sequence; otherwise, define the continuous subsequence as an uncovered call path fragment.

[0029] In this embodiment, a sliding window traversal is performed on each node identifier sequence to generate all continuous subsequences with a length of not less than three. For example, if a complete path is [N1, N2, N3, N4, N5], the generated continuous subsequences include [N1,N2,N3], [N2,N3,N4], [N3,N4,N5], [N1,N2,N3,N4], [N2,N3,N4,N5], and [N1,N2,N3,N4,N5]. For each such continuous subsequence S, all test cases in the pre-built test case library are traversed, and the covered node identifier sequences corresponding to each test case in historical execution are queried. For each historical covered sequence H, the system determines whether S appears as a continuous subsequence in H, that is, whether there exists a node identifier segment in H that is exactly the same as S and in the same order. If there is at least one test case whose corresponding H contains S, it means that the behavior segment has been covered by existing tests, and S is marked as "covered"; otherwise, if none of the historical covered sequences contain S, S is determined to be an uncovered call path segment.

[0030] This embodiment, through steps 31-35, addresses the inability to accurately identify and cover context-sensitive unexecuted program behavior paths. By modeling the execution trajectory as a sequence of node identifiers that integrate call identifiers and actual parameter values, and using the inclusion relationship of continuous subsequences as the coverage criterion, it achieves, for the first time, quantifiable identification of semantically complete behavioral fragments. This enables the system to accurately discover deep call paths that are truly not covered by any historical test cases, thereby avoiding the waste of testing resources on repetitive or shallow behaviors. It not only overcomes the semantic limitations of traditional coverage metrics but also establishes a technical roadmap from "behavior awareness" to "path coverage" and then to "test case generation," significantly improving the ability of automated testing to detect high-risk interaction defects and the efficiency of resource utilization in complex software systems.

[0031] Step 4: Based on the call path fragment, construct test input data according to the actual values ​​of the input parameters, including the following steps: Step 41: Based on the call path fragment, extract the input parameters and actual values ​​of the first node as the initial parameter assignment set.

[0032] When this embodiment identifies an uncovered call path segment (e.g., a sequence of three consecutive nodes: [N1, N2, N3]), the first node N1 of that segment is used as the starting point for constructing the test input. Specifically, all input parameter names and their corresponding actual values ​​are extracted from N1. These key-value pairs of parameter names and values ​​are combined to form an initial parameter assignment set. This set fully preserves the entry context required to trigger the uncovered path, serving as the basis for subsequently constructing executable test inputs. Since this parameter set directly originates from the initial conditions that led to the path's occurrence during actual operation, it possesses high feasibility and specificity, effectively driving the system under test to reproduce the entire target call chain, avoiding blind searching in irrelevant parameter spaces, and significantly improving the hit efficiency of test inputs.

[0033] Step 42: Check whether the actual value of the input parameter in the initial parameter assignment set is empty. If so, determine the corresponding input parameter based on the actual value of the input parameter corresponding to the empty value.

[0034] In this embodiment, an integrity check is performed on the initial parameter assignment set, determining whether the actual value of each input parameter is empty (e.g., null, an empty string "", a default placeholder such as "N / A", or a missing field). If an actual value of a parameter is found to be empty, the input parameter corresponding to that empty value is marked as an item to be completed. By analyzing the function context (i.e., the call identifier) ​​associated with the input parameter, the specific parameter identity that needs to be completed is identified, thus providing a clear target for retrieving reasonable values ​​from historical data. This step ensures that all test inputs to be constructed have a complete parameter structure, avoiding test execution failure or unreproducible paths due to missing key fields.

[0035] Step 43: Obtain historical records, determine the frequency of actual values ​​of input parameters based on historical records and input parameters, and use the highest value of the frequency of actual values ​​of input parameters as the padding value.

[0036] In this embodiment, for null parameters, all records with the same call identifier as the first node of the current call path segment are retrieved from the historical function call information database. This filters out all historical function call events recorded by the probe that call the same method. Within this subset, the focus is on the input parameter to be completed. The actual value of the input parameter in each record is traversed, and the frequency of each value is counted. Subsequently, null values ​​or invalid placeholders are excluded, and the value with the highest frequency among the non-null values ​​is selected as the completion value. In this way, common patterns in real historical behavior are used to assign high-probability valid values ​​to missing parameters, ensuring the executability of the test input while maintaining the rationality of the original path context to the greatest extent, thereby improving the success rate of reproducing the target's uncovered call path.

[0037] Step 44: Replace the empty values ​​in the initial parameter assignment set with the padded values, and use the input parameters and their corresponding actual and padded values ​​as test input data.

[0038] In this embodiment, the padding values ​​are filled back into the corresponding empty positions in the initial parameter assignment set to complete the construction of the test input data.

[0039] This embodiment, through steps 41-44, addresses the core issue of the inability to automatically generate high-fidelity, executable test cases based on real, uncovered behaviors. This solution directly extracts the real parameters of the first node from the identified uncovered call path fragments as the starting point for construction, and intelligently completes missing fields based on historical high-frequency values, ensuring that the generated test input is both semantically accurate (reflecting actual operating conditions) and structurally complete (without missing key parameters). It reliably transforms newly discovered behavioral paths into replayable and schedulable test assets, significantly improving the effectiveness of test cases and the success rate of path reproduction. It greatly reduces invalid execution caused by input distortion, allowing limited testing resources to focus on scenarios that truly have the potential to expose defects, thereby achieving more efficient and in-depth automated coverage in complex software systems.

[0040] Step 5: Drive the software system under test to perform a test run based on the test input data and generate new function call information.

[0041] In this embodiment, test input data is used as a driving signal and injected into the entry point of the software system under test to execute a complete test run. Specifically, if the system under test is a web service, the test input data is encapsulated into an HTTP request conforming to the interface specification (such as a POST request body in JSON format) and sent to the target API endpoint through an automated testing client; if it is a command-line program, it is converted into the corresponding command-line parameters or configuration file. During this test run, the probe module deployed inside the system monitors and records all function call events in real time, capturing the call identifier, the name and actual value of each input parameter, the return value, and the exception flag for each call, ultimately forming a complete and sequential set of new function call information. This information not only reflects the program behavior trajectory triggered by this test but also preserves the parameter context and exception state.

[0042] Step 6: Convert the new function call information into a sequence of new nodes, and perform structural difference analysis with historical test run records to generate a cumulative composite difference value. If the cumulative composite difference value is greater than a preset threshold, store the test input data into a pre-built test case library as a new test case to form an updated test case library. Perform multiple rounds of test runs on the software system under test based on the updated test case library.

[0043] Step 61: Convert the new function call information into a sequence of new nodes, wherein each new node contains a call identifier, input parameters, actual values ​​of the input parameters, return value, and an exception flag; wherein the exception flag includes true or false.

[0044] In this embodiment, new function call information is processed one by one according to the execution sequence, transforming it into a sequence of new nodes. Specifically, each function call record is mapped to a structured new node, which contains five core fields: call identifier, input parameters, the corresponding actual values ​​of the input parameters, return value, and a Boolean exception flag. When the probe detects that an uncaught exception is thrown, a crash occurs, or an error code is returned during the call, the flag is set to true; otherwise, it is false. For example, if a call terminates due to a null pointer exception, the exception flag in its node is true, and the exception type is recorded as part of the return value. This sequence of new nodes strictly maintains the original execution order of function calls, forming a linear trajectory. Although this sequence itself is linear, it is closely related to a Directed Acyclic Graph (DAG): a DAG is a global aggregated view of all call events and their dependencies across multiple runs, while the sequence of new nodes is a specific path instance corresponding to this single run in the DAG. In other words, this sequence can be regarded as a candidate for a new path from the entrance to the exit in the DAG, which will be used to compare with historical paths to determine whether it brings new structural or behavioral differences.

[0045] Step 62: Obtain the set of historical node sequences, and based on the set of historical node sequences, filter out a subset of candidate historical sequences in which the call identifier of the starting node is the same as the call identifier of the starting node of the new node sequence, and the call identifier of the ending node is the same as the call identifier of the ending node of the new node sequence.

[0046] In this embodiment, the system first loads a set of all stored historical node sequences from the historical test execution database. Each historical sequence represents a complete function call trajectory triggered by a past test execution. Then, for the newly generated node sequence, the entire historical set is traversed, and historical sequences that meet the following two conditions are selected: first, the call identifier of the first node in the historical sequence is exactly the same as the starting call identifier of the newly generated node sequence; second, the call identifier of the last node in the historical sequence is exactly the same as the ending call identifier of the newly generated node sequence. Only historical sequences that simultaneously meet these two endpoint matching conditions are included in the candidate historical sequence subset. This selection mechanism effectively narrows the comparison scope, ensuring that subsequent structural difference analysis focuses on execution paths with the same entry and exit contexts, thereby improving the semantic relevance and computational efficiency of difference calculation and avoiding meaningless comparisons of semantically unrelated paths (such as completely different business processes).

[0047] Step 63: Obtain the cumulative value of composite difference.

[0048] Step 64: Calculate the cumulative composite difference value for each historical sequence in the subset of candidate historical sequences, based on the cumulative composite difference value, the call identifier, the input parameters, and the actual values ​​of the input parameters. Step 641: Initialize the cumulative composite difference value to zero; initialize the parameter difference value list to empty.

[0049] In this embodiment, before calculating the behavioral differences between the newly added node sequence and each candidate historical sequence, the system first performs an initialization operation: setting the cumulative composite difference value to 0 and creating an empty list of parameter difference values. Here, the "cumulative composite difference value" is not the final result, but an intermediate variable used to gradually accumulate multi-dimensional difference scores—its initial value is 0, indicating that no differences have been included yet; it will be incrementally updated subsequently through three independent but weighted fused dimensions.

[0050] Step 642: Traverse the newly added node sequence and the candidate historical sequence subset to call the mapping node pairs with the same identifier, and determine the input parameter set based on the mapping node pairs.

[0051] In this embodiment, each historical sequence in the newly added node sequence is compared bit-by-bit with each historical sequence in the subset of candidate historical sequences. Only nodes in the two sequences that are at the same position (i.e., execution time alignment) and have the same call identifier constitute a valid mapping node pair. For each mapping node pair, the set of input parameter names common to both nodes is further extracted, i.e., input parameters that appear in both the newly added node and the historical node. This serves as the basis for subsequent parameter difference calculations, ensuring that only semantically consistent parameters are compared, avoiding invalid comparisons due to inconsistent parameter structures (such as added or missing fields). While maintaining call context alignment, this approach precisely focuses on comparable parameters, providing a reliable foundation for subsequent quantification of behavioral differences.

[0052] Step 643: Determine the cumulative value of composite difference and the number of effective parameters based on the data type of the actual values ​​of the input parameters in the input parameter set.

[0053] Step 6431: Based on each input parameter in the set of input parameters, determine whether the actual values ​​of the input parameters of the mapping node pair are all numerical. If so, calculate the relative error value based on the actual values ​​of the input parameters of the mapping node pair. Add the relative error value to the parameter difference value list and increment the number of valid parameters by one.

[0054] In this embodiment, for each input parameter common to the mapping node pair, it is first determined whether its actual value in the new node and the historical node is both numerical data (such as integers or floating-point numbers). If both are numerical, the relative error calculation process begins. The relative error value is calculated as follows: first, the absolute value of the difference between the two values ​​is calculated, and then divided by the maximum of the absolute values ​​of the two values ​​to obtain the relative error value. If both values ​​are zero, the denominator is zero. In this case, a preset small constant is used as the denominator to avoid division by zero errors and ensure calculation stability. The calculated relative error value is appended to the parameter difference value list, and the global effective parameter count counter is incremented by one.

[0055] If the actual values ​​of the input parameters of the mapping node pair are all strings, then the normalized edit distance value is calculated based on the actual values ​​of the input parameters of the mapping node pair, the normalized edit distance value is added to the parameter difference value list, and the number of valid parameters is incremented by one; Otherwise, skip it.

[0056] In this embodiment, when the actual values ​​of the input parameters of the common parameters in the mapping node pair are all string types, the normalized edit distance value is calculated. Specifically, firstly, the minimum number of single-character insertion, deletion, or replacement operations required to convert one string into another is determined, i.e., the edit distance; then, the maximum value of the two string lengths is taken as the normalization denominator, and the edit distance is divided by this maximum value to obtain the normalized edit distance value. This value is added to the parameter difference value list, and the number of valid parameters is incremented by one. If both string lengths are zero, the normalized edit distance value is considered 0; if the parameter types are inconsistent, or any value is not a string type, the parameter is skipped and does not participate in subsequent difference calculations. This normalization mechanism effectively eliminates the influence of string length on difference measurement, allowing strings of different sizes to be semantically similar under a uniform scale, thereby more accurately reflecting the true changes in parameter behavior.

[0057] Step 6432: If the number of valid parameters is greater than zero, calculate the arithmetic mean of the normalized edit distance value and the relative error value in the parameter difference value list, and add the arithmetic mean to the cumulative composite difference value; otherwise, skip this step.

[0058] In this embodiment, if the number of valid parameters is zero (i.e., there are no comparable numerical or string parameters), the accumulation of differences in the parameter dimension is skipped. If the number is greater than zero, the arithmetic mean of all relative error values ​​(from numerical parameters) and normalized edit distance values ​​(from string parameters) collected in the parameter difference value list is calculated as the overall difference at the parameter level for this path comparison. This average is then directly added to the cumulative composite difference value as a component of the multidimensional difference assessment. This ensures that the contribution of parameter differences is incorporated into the final judgment in a holistic and balanced manner, avoiding the dominance of individual extreme values ​​in the results. Furthermore, this dimension is introduced only when there are valid comparable parameters, guaranteeing the rationality and robustness of the difference measurement.

[0059] Step 644: Extract the call identifier combination of all adjacent newly added node pairs in the newly added node sequence to form the first call transfer sequence; extract the call identifier combination of all adjacent node pairs in the candidate historical sequence subset to form the second call transfer sequence.

[0060] In this embodiment, each candidate historical sequence of the newly added node sequence and the candidate historical sequence subset is traversed, and the call identifier of each pair of adjacent nodes is extracted in turn and combined into an ordered tuple to form the first call transfer sequence and the second call transfer sequence.

[0061] Step 645: If the lengths of both the first call transfer sequence and the second call transfer sequence are greater than or equal to the target length, then the first occurrence frequency of the call identifier combination of adjacent newly added node pairs in the first call transfer sequence is counted, and a first frequency distribution is constructed based on the first occurrence frequency; simultaneously, the second occurrence frequency of the call identifier combination of adjacent node pairs in the second call transfer sequence is counted, and a second frequency distribution is constructed based on the second occurrence frequency; and the KL divergence between the first frequency distribution and the second frequency distribution is calculated, and the KL divergence is accumulated to the cumulative composite difference value; otherwise, skip this step. In this embodiment, the system first determines whether the lengths of the first call transfer sequence and the second call transfer sequence are both not less than a preset target length (e.g., 3). If the condition is met, frequency statistics are performed on the two sequences respectively: For the first call transfer sequence (composed of call identifier combinations of all adjacent nodes in the new node sequence), the system counts the occurrence frequency of each unique call identifier combination and divides it by the total length of the sequence to obtain its probability of occurrence in the new path. All combinations and their probabilities constitute the first frequency distribution; similarly, the same operation is performed on the second call transfer sequence (from a candidate historical node sequence) to obtain the second frequency distribution. Subsequently, the system calculates the KL divergence between the two frequency distributions: specifically, it iterates through all call identifier combinations in the first frequency distribution, and for each combination, it uses its probability in the first distribution as a weight, multiplies it by the logarithm of the ratio of that probability to the corresponding probability in the second distribution (if there is no such combination in the second distribution, a very small positive value is assigned through smoothing to avoid calculation abnormalities), and sums all the results to obtain the KL divergence value. This value reflects the novelty of the new path in terms of function call jump structure relative to the historical path. Finally, the KL divergence is multiplied by a preset second weighting coefficient (as a system configuration parameter used to adjust the proportion of structural differences in the overall evaluation) and accumulated into the cumulative value of composite divergence. The frequency statistics, normalization, smoothing, and KL divergence calculation described above are all well-known information theory methods in the field, and the solutions are fully disclosed and can be directly implemented by technical personnel.

[0062] Step 646: If there is a first newly added node with an anomaly flag set to true in the newly added node sequence, record the number of newly added nodes from the first first newly added node to the end of the newly added node sequence as the first anomaly propagation length; if there is a first node with an anomaly flag set to true in the candidate historical sequence subset, record the number of nodes from the first first node to the end of the candidate historical sequence as the second anomaly propagation length; calculate the normalized anomaly difference value based on the difference between the first anomaly propagation length and the second anomaly propagation length, and accumulate the normalized anomaly difference value to the composite difference cumulative value; otherwise, skip this step.

[0063] In this embodiment, the system first checks if any nodes in the newly added node sequence have a true anomaly flag. If so, it locates the first anomalous node (i.e., the position where the anomaly first appears) and calculates the total number of nodes from that node to the end of the sequence (including that node), which is taken as the first anomaly propagation length. For example, if the newly added node sequence is [N1, N2, N3, N4, N5], where N3 is the first anomalous node, then the first anomaly propagation length is 3 (corresponding to N3→N4→N5). Similarly, it checks if any nodes in the currently compared candidate historical sequences have a true anomaly flag; if so, it also locates the first anomalous node and calculates the number of nodes from that node to the end of the sequence, which is taken as the second anomaly propagation length. Subsequently, it calculates the absolute value of the difference between the two lengths and divides it by the maximum value of the two lengths (if the maximum value is 0, it is skipped) to obtain the normalized anomaly difference value, which ranges from [0,1] and is used to quantify the relative change in the scope of the anomaly's influence. The normalized anomaly difference value is accumulated into the composite difference cumulative value to reflect whether the degree of diffusion of the anomalous behavior in the latter half of the execution path has changed significantly. If no abnormal nodes are found in the newly added sequence or the historical sequence, this step is skipped. It can not only identify whether an anomaly has occurred, but also assess the depth of the anomaly's impact on subsequent call chains, thus more precisely distinguishing high-risk new behaviors.

[0064] The difference components calculated in each of the above steps are sequentially accumulated into the same cumulative composite difference value variable, which is initialized to 0 before the calculation begins and used as a global accumulator throughout the alignment process. Specifically, first, parameter difference calculation is performed (step 643): if comparable numerical or string parameters exist, the arithmetic mean of the parameter difference value list is accumulated to this cumulative value; then, call transfer structure difference calculation is performed (step 645): if the lengths of the two call transfer sequences meet the target length requirement, the KL divergence (weighted by the second weighting coefficient) is accumulated to the same cumulative value; finally, anomaly propagation difference calculation is performed (step 646): if there are anomaly nodes in the new or historical sequences, the normalized anomaly difference value is accumulated again to this cumulative value. Therefore, the final cumulative composite difference value is not the result of a single dimension, but the sum of the contributions of the three dimensions: parameter difference, call transfer structure difference, and anomaly propagation difference. This final value comprehensively reflects the combined behavioral differences between the new and historical runs in three key aspects: input parameter values, function call jump patterns, and the scope of anomaly impact.

[0065] This application calculates the cumulative composite difference value through the aforementioned multi-dimensional, step-by-step accumulation method, primarily addressing the problem in existing testing techniques that rely solely on a single indicator, which cannot comprehensively and accurately measure differences in program behavior. Traditional methods struggle to distinguish between execution trajectories that are "superficially identical but with different parameters," "similar in structure but with different anomaly propagation depths," or "slightly different call order but drastically different logic," leading to many high-value new behaviors being misjudged as repetitions, while truly redundant executions are repeatedly performed. This solution, however, integrates three orthogonal dimensions—parameter value differences (relative numerical error and string edit distance), call transfer structure differences (control flow distribution deviation based on KL divergence), and anomaly propagation range differences (normalized anomaly impact length variation)—and uniformly accumulates them into a single cumulative composite difference value, achieving fine-grained, semantically sensitive quantitative evaluation of dynamic program behavior. This ensures that only when a new execution significantly differs from historical behavior in at least one key dimension is it considered exploratory. It significantly improves the accuracy and defect orientation of test case selection, avoiding "false coverage" caused by ignoring parameter context, and capturing deep interaction defects caused by anomaly propagation or call chain reorganization. Thus, with limited test resources, it prioritizes and schedules truly high-risk and highly novel test inputs, significantly improving the defect detection efficiency and behavioral coverage depth of automated testing in complex systems.

[0066] Step 65: If the cumulative value of the composite difference is greater than the preset threshold and the abnormal flag of the newly added node in the new node sequence is true, then the test input data is stored in the pre-built test case library as a new test case; otherwise, the process ends.

[0067] In this embodiment, after completing the multi-dimensional difference analysis between the newly added node sequence and the candidate historical sequence, the final calculated cumulative value of the composite difference is compared with a dynamically adjusted preset threshold. The preset threshold is automatically adjusted according to the output trend of high-value test cases during the testing process to maintain a balance between the sensitivity and effectiveness of the test exploration.

[0068] Specifically, a sliding window is maintained to record the high-value ratio in each of the most recent test cycles (e.g., the last 10 rounds): that is, the proportion of test cases that are stored in the test case library because they meet the conditions in each round out of the total number of test runs in that round. For example, if a round executes 200 tests, and 30 of them are judged as high-value and stored in the library, then the high-value ratio for that round is 15%. The system continuously tracks the trends of these ratios: if the proportion of high-value transactions shows a significant downward trend in recent rounds (e.g., the decline exceeds a preset negative sensitivity boundary for multiple consecutive rounds), it indicates that the current threshold may be too high, causing many potentially new behaviors to be filtered out. In this case, the threshold will be appropriately lowered (by multiplying the preset threshold by a preset first amplification factor to obtain a dynamic threshold, where the first amplification factor is less than 0) to improve sensitivity to new paths. Conversely, if the proportion of high-value transactions continues to rise, it indicates that the current exploration efficiency is high, and the threshold will be moderately increased (by multiplying the preset threshold by a preset second amplification factor to obtain a dynamic threshold, where the second amplification factor is greater than 0) to prevent a large influx of low-value test cases that are slightly above the old threshold, causing redundancy. If the ratio fluctuates smoothly, the preset threshold remains unchanged. This dynamic adjustment mechanism ensures that the threshold always adapts to the actual needs of the current testing phase.

[0069] When the cumulative composite difference value exceeds the currently dynamically determined preset threshold / dynamic threshold, further checks are performed to see if any node in the newly added node sequence has an anomaly flag that is true. Only when both conditions are met—"the behavior is sufficiently novel" (the cumulative composite difference value exceeds the preset threshold / dynamic threshold) and "potential defects are exposed" (anomalies exist)—is the test input data used in this test stored as a new test case in the pre-built test case library, forming an updated test case library.

[0070] This embodiment also includes determining the priority weight of the updated test case library, used to filter test cases for each round of test execution: When a new test case is added to the pre-built test case library, an initial priority weight is generated for the test case. The initial priority weight is the number of nodes with the exception flag bit set to true in the new node sequence corresponding to the new test case. In this embodiment, once a test run meets the inclusion criteria, the corresponding test input data is stored as a new test case in a pre-built test case library, and an initial priority weight is assigned to it. This initial priority weight is directly equal to the number of nodes with true anomaly flags in the new node sequence corresponding to the new test case. For example, if the new node sequence triggered in this run is [N1, N2, N3, N4], where the anomaly flags of N2 and N4 are true, then the number of anomaly nodes is 2, and therefore the initial priority weight of this test case is set to 2. This ensures that the initial priority of the included test case is proportional to its ability to expose defects; the more anomaly nodes, the more likely the path is to involve high-risk logic, and the more worthy it is of priority scheduling in subsequent test rounds. This initial weight serves as the starting point for subsequent dynamic adjustments, ensuring that test resources are tilted towards high-risk scenarios from the very beginning of inclusion, thereby improving overall defect detection efficiency.

[0071] In subsequent test rounds, based on each test case, step 5 is executed to generate the new function call information and convert it into a sequence of newly added nodes. It is then determined whether there exists a newly added node sequence where the call identifier and the actual value of the input parameter of at least one newly added node do not appear in the historical node sequence set. If so, the priority weight of the current test case is increased by ΔW to obtain an optimized priority weight, where ΔW is equal to the number of newly appearing nodes in this run. The optimized priority weight is used for scheduling decisions in subsequent test rounds. In this embodiment, in subsequent test rounds, an existing test case is scheduled from the test case library, and step 5 is executed based on the test input data of the test case to drive the software system under test to run, thereby generating new function call information corresponding to this run; subsequently, the new function call information is converted into a new node sequence. Each node in the new node sequence is traversed, and its node identifier (uniquely determined by the call identifier and the actual value of the input parameter) is extracted, and compared with the historical node sequence set one by one. If it is found that the identifier of at least one node does not appear in the historical set, it means that a new program behavior state has been explored in this run. At this time, the number of newly appearing nodes in this run (i.e., the total number of nodes that do not appear in the historical set) is counted and denoted as ΔW, and the current priority weight of the test case is increased by ΔW to obtain the optimized priority weight. For example, if the current weight of the test case is 3, and 2 new nodes are found in this run, the updated weight is 5. The optimized priority weight is then used for scheduling and sorting in subsequent test rounds to ensure that high-potential test cases that can continuously discover new behaviors receive higher execution priority, significantly improving the efficiency of test coverage of unknown defect paths.

[0072] Before each test round begins, the test cases in the test case library are sorted from high to low based on the priority weight or optimization priority weight of each test case at present, and the top L test cases are selected for execution in this round; for test cases in the test case library that are not selected in this round, their priority weight is multiplied by a decay factor to obtain the decayed priority weight.

[0073] In this embodiment, before each test round begins, the current priority weights of all test cases in the test case library are first obtained. For newly added test cases, this value is their initial priority weight; for already executed test cases, it is their dynamically adjusted optimized priority weight. All test cases are sorted from highest to lowest according to these weight values, and the top L test cases (L is the preset test capacity per round, e.g., L=50) are selected as the execution candidate set for this round. These selected test cases will be used sequentially to drive the operation of the software system under test. Simultaneously, for the remaining test cases not selected in this round, a decay mechanism is applied to their current priority weights: they are multiplied by a decay factor to obtain decayed priority weights. This effectively suppresses dormant test cases that have not triggered new behavior for a long time from occupying scheduling resources, ensuring that the testing focus is always concentrated on recently active or high-potential test cases, thereby maintaining the efficiency and adaptability of the testing process.

[0074] In this embodiment, multiple rounds of testing are performed on the software system under test based on the updated test case library. Before each round of testing begins, L test cases are selected from the test case library as the execution set for that round. Subsequently, the test input data corresponding to each selected test case is injected into the entry point of the software system under test, driving it to execute a complete run. During this process, a probe module deployed inside the system monitors and records all function call events in real time, generating new function call information corresponding to that run for subsequent analysis or comparison. By repeating the above execution process multiple times, high-quality, high-potential test inputs can be continuously used to deeply probe the software, thereby effectively covering complex operation paths and interaction scenarios.

[0075] like Figure 2 As shown, this embodiment also discloses a software automated testing system, including the following modules: Data acquisition module: Used to acquire function call information for each function call event in real time based on the software system under test; Data processing module: used to construct a directed acyclic graph based on the function call information; Identification module: used to identify call path segments based on the directed acyclic graph; Data reconstruction module: used to construct test input data based on the actual values ​​of the input parameters according to the call path fragment; Test module: Used to drive the software system under test to perform a test run using the test input data and generate new function call information; The update module is used to convert the new function call information into a sequence of new nodes and perform structural difference analysis with historical test run records to generate a cumulative composite difference value. If the cumulative composite difference value is greater than a preset threshold, the test input data is stored in a pre-built test case library as a new test case to form an updated test case library. Based on the updated test case library, multiple rounds of test runs are performed on the software system under test.

[0076] To implement the above embodiments, this application also proposes an electronic device. Please see [link to relevant documentation]. Figure 3 , Figure 3 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 500 includes: a processor 501 and a memory 502 communicatively connected to the processor 501; the memory 502 stores computer-executable instructions; the processor 501 executes the computer-executable instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0077] To implement the above embodiments, this application also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0078] To implement the above embodiments, this application also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0079] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A software automated testing method, characterized in that, Includes the following steps: Step 1: Based on the software system under test, obtain the function call information for each function call event in real time: call identifier, input parameters, actual values ​​of input parameters, and return value; Step 2: Construct a directed acyclic graph based on the function call information. The directed acyclic graph includes several nodes and directed edges. Each node corresponds to a function call event. The node includes the call identifier, the actual value of the input parameters, and the return value. The directed edges represent the execution order of the function call events corresponding to adjacent nodes. Step 3: Identify call path segments based on the directed acyclic graph; Step 4: Based on the call path fragment, construct test input data according to the actual values ​​of the input parameters; Step 5: Drive the software system under test to perform a test run based on the test input data, and generate new function call information; Step 6: Convert the new function call information into a sequence of new nodes, and perform structural difference analysis with historical test run records to generate a cumulative composite difference value. If the cumulative composite difference value is greater than a preset threshold, store the test input data into a pre-built test case library as a new test case to form an updated test case library. Perform multiple rounds of test runs on the software system under test based on the updated test case library.

2. The software automated testing method according to claim 1, characterized in that, Identifying call path segments based on the directed acyclic graph includes the following steps: Step 31: Calculate the out-degree and in-degree of each node in the directed acyclic graph; Step 32: Traverse the directed acyclic graph, identify all nodes with an in-degree of zero as entry nodes, and identify all nodes with an out-degree of zero as exit nodes. Step 33: Based on the entry node as the starting point and the exit node as the ending point, construct several complete call paths according to the starting point and the ending point; define each complete call path as a sequence of node identifiers arranged in the execution order, wherein each node identifier is a unique identifier composed of the call identifier of the corresponding node and the actual value of the input parameter. Step 34: Based on each test case in the pre-built test case library, obtain the first function call information in the historical test execution, and construct the covered node identifier sequence according to the first function call information; Step 35: Identify continuous subsequences based on the node identifier sequence, and determine whether the continuous subsequence contains the covered node identifier sequence. If so, define the covered node identifier sequence as a continuous sequence; otherwise, define the continuous subsequence as an uncovered call path fragment.

3. The software automated testing method according to claim 2, characterized in that, Based on the aforementioned call path fragment, test input data is constructed according to the actual values ​​of the input parameters, including the following steps: Step 41: Based on the call path fragment, extract the input parameters and actual values ​​of the first node as the initial parameter assignment set; Step 42: Check whether the actual value of the input parameter in the initial parameter assignment set is empty. If so, determine the corresponding input parameter based on the actual value of the input parameter corresponding to the empty value. Step 43: Obtain historical records, determine the frequency of actual values ​​of input parameters based on historical records and input parameters, and use the highest value of the frequency of actual values ​​of input parameters as the padding value; Step 44: Replace the empty values ​​in the initial parameter assignment set with the padded values, and use the input parameters and their corresponding actual and padded values ​​as test input data.

4. The software automated testing method according to claim 3, characterized in that, The new function call information is converted into a sequence of new nodes, and structural difference analysis is performed with historical test run records to generate a cumulative composite difference value. If the cumulative composite difference value is greater than a preset threshold, the test input data is stored in a pre-built test case library as a new test case, including the following steps: Step 61: Convert the new function call information into a sequence of new nodes, wherein each new node includes a call identifier, input parameters, actual values ​​of the input parameters, a return value, and an exception flag; wherein the exception flag includes true or false. Step 62: Obtain the set of historical node sequences, and based on the set of historical node sequences, filter out a subset of candidate historical sequences in which the call identifier of the starting node is the same as the call identifier of the starting node of the new node sequence, and the call identifier of the ending node is the same as the call identifier of the ending node of the new node sequence. Step 63: Obtain the cumulative value of composite difference; Step 64: Calculate the cumulative composite difference value for each historical sequence in the subset of candidate historical sequences, based on the cumulative composite difference value, the call identifier, the input parameters, and the actual values ​​of the input parameters. Step 65: If the cumulative value of the composite difference is greater than the preset threshold and the abnormal flag of the newly added node in the new node sequence is true, then the test input data is stored in the pre-built test case library as a new test case; otherwise, the process ends.

5. The software automated testing method according to claim 4, characterized in that, The calculation of the cumulative composite difference value includes the following steps: Step 641: Initialize the cumulative composite difference value to zero; initialize the parameter difference value list to empty; Step 642: Traverse the newly added node sequence and the candidate historical sequence subset to call the mapping node pairs with the same identifier, and determine the input parameter set based on the mapping node pairs; Step 643: Determine the cumulative value of composite difference and the number of effective parameters based on the data type of the actual values ​​of the input parameters in the input parameter set; Step 644: Extract the call identifier combination of all adjacent newly added node pairs in the newly added node sequence to form the first call transfer sequence; extract the call identifier combination of all adjacent node pairs in the candidate historical sequence subset to form the second call transfer sequence. Step 645: If the lengths of both the first call transfer sequence and the second call transfer sequence are greater than or equal to the target length, then the first occurrence frequency of the call identifier combination of adjacent newly added node pairs in the first call transfer sequence is counted, and a first frequency distribution is constructed based on the first occurrence frequency; simultaneously, the second occurrence frequency of the call identifier combination of adjacent node pairs in the second call transfer sequence is counted, and a second frequency distribution is constructed based on the second occurrence frequency; and the KL divergence between the first frequency distribution and the second frequency distribution is calculated, and the KL divergence is accumulated to the cumulative composite difference value; otherwise, skip this step. Step 646: If there is a first newly added node with an anomaly flag set to true in the newly added node sequence, record the number of newly added nodes from the first first newly added node to the end of the newly added node sequence as the first anomaly propagation length; if there is a first node with an anomaly flag set to true in the candidate historical sequence subset, record the number of nodes from the first first node to the end of the candidate historical sequence as the second anomaly propagation length; calculate the normalized anomaly difference value based on the difference between the first anomaly propagation length and the second anomaly propagation length, and accumulate the normalized anomaly difference value to the composite difference cumulative value; otherwise, skip this step.

6. The software automated testing method according to claim 5, characterized in that, Determining the cumulative composite difference value and the number of valid parameters based on the data type of the actual values ​​of the input parameters in the input parameter set includes the following steps: Step 6431: Based on each input parameter in the set of input parameters, determine whether the actual values ​​of the input parameters of the mapping node pair are all numerical. If so, calculate the relative error value based on the actual values ​​of the input parameters of the mapping node pair. Add the relative error value to the parameter difference value list and increment the number of valid parameters by one. If the actual values ​​of the input parameters of the mapping node pair are all strings, then the normalized edit distance value is calculated based on the actual values ​​of the input parameters of the mapping node pair, the normalized edit distance value is added to the parameter difference value list, and the number of valid parameters is incremented by one; Otherwise, skip; Step 6431: If the number of valid parameters is greater than zero, calculate the arithmetic mean of the normalized edit distance value and the relative error value in the parameter difference value list, and add the arithmetic mean to the cumulative composite difference value; otherwise, skip this step.

7. The software automated testing method according to claim 1, characterized in that, It also includes determining the priority weights of the updated test case library, which is used to filter test cases for each round of test execution.

8. A software automated testing system, used to execute the software automated testing method according to any one of claims 1-7, characterized in that, Includes the following modules: Data acquisition module: Used to acquire function call information for each function call event in real time based on the software system under test; Data processing module: used to construct a directed acyclic graph based on the function call information; Identification module: used to identify call path segments based on the directed acyclic graph; Data reconstruction module: used to construct test input data based on the actual values ​​of the input parameters according to the call path fragment; Test module: Used to drive the software system under test to perform a test run using the test input data and generate new function call information; The update module is used to convert the new function call information into a sequence of new nodes and perform structural difference analysis with historical test run records to generate a cumulative composite difference value. If the cumulative composite difference value is greater than a preset threshold, the test input data is stored in a pre-built test case library as a new test case to form an updated test case library. Based on the updated test case library, multiple rounds of test runs are performed on the software system under test.

Images