Automatic test scheme generation method, equipment and medium

Abstract

The invention relates to the technical field of automatic testing, and discloses an automatic testing scheme generation method and device and a medium, and the method comprises the steps: matching a demand action in a test demand with a code entry name corresponding to a code segment, and determining a code risk level of a current demand code block; analyzing the code change frequency and the code dependency degree of the current demand code block according to historical test records in the test domain knowledge base, and determining the test dynamic priority of the current demand code block; constructing a control flow diagram and a data flow diagram of the current demand code block, and detecting risk nodes in the control flow diagram and the data flow diagram; generating a test scene of the current demand code block according to the risk node, and generating a boundary value test rule according to a key constraint condition in the data flow diagram; and querying an environment simulation rule of the current demand code block, and packaging the test scene, the boundary value test rule and the environment simulation rule into an automatic test scheme. According to the invention, the code coverage when the test scheme is generated can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of automated testing, and particularly to a method, device and medium for generating an automated testing scheme. Background Art

[0002] Modern software systems usually consist of multiple modules, components and services, with complex relationships among them. In the context of agile development and continuous integration, software updates and iterations are very frequent. In order to improve the efficiency of software testing, it is necessary to optimize the testing scheme.

[0003] The existing testing scheme generation technology relies on manual analysis of requirement documents and writing of test scripts, which is inefficient and prone to missing complex scenarios. That is, test cases are generated through predefined rules, with poor flexibility and difficulty in adapting to dynamic business requirements, resulting in a mismatch between business requirements and test cases and difficulty in comprehensively covering test paths, thus leading to low code coverage when generating a testing scheme. Summary of the Invention

[0004] The present invention provides a method, device and medium for generating an automated testing scheme, and its main purpose is to solve the problem of low accuracy when making product recommendations.

[0005] To achieve the above object, an automated testing scheme generation method provided by the present invention includes: Extract the requirement actions in the pre-acquired test requirements, match the requirement actions with the code entry names corresponding to the pre-acquired code segments to obtain the current requirement code block; Determine the code risk level of the current requirement code block according to the code defect distribution in the pre-constructed test domain knowledge base; Analyze the code change frequency and code dependency of the current requirement code block according to the historical test records in the test domain knowledge base, and determine the test dynamic priority of the current requirement code block according to the code change frequency, the code dependency and the code risk level; Construct a control flow graph and a data flow graph of the current requirement code block through the test dynamic priority, and detect risk nodes in the control flow graph and the data flow graph by using the test domain knowledge base; Generate test scenarios for the current requirement code block according to the risk nodes, and generate boundary value test rules according to the key constraint conditions in the data flow graph; Query the environment simulation rules of the current requirement code block by using the test domain knowledge base, and encapsulate the test scenarios, the boundary value test rules and the environment simulation rules into an automated testing scheme.

[0006] Optionally, matching the required action with the code entry name corresponding to the pre-acquired code segment to obtain the current required code block includes: Identifying the action semantics of the required action and vectorizing the action semantics to obtain an action semantics vector; Vectorizing the code entry name corresponding to the code segment to obtain a code entry vector; Calculating the semantic similarity between the action semantics vector and the code entry vector; When the semantic similarity is less than or equal to a preset similarity threshold, marking the code entry vector as an unmatched vector and storing the unmatched vector in a preset database; When the semantic similarity is greater than the preset similarity threshold, using the code entry name corresponding to the code entry vector as the target code entry name; Determining the code block corresponding to the target code entry name as the current required code block.

[0007] Optionally, determining the code risk level of the current required code block according to the code defect distribution in the pre-constructed test domain knowledge base includes: Counting the defect occurrence frequency of the current required code block according to the code defect distribution; When the defect occurrence frequency is greater than or equal to a preset first frequency threshold, determining the code risk level of the current required code block as a high level; When the defect occurrence frequency is less than the preset first frequency threshold and greater than a preset second frequency threshold, determining the code risk level of the current required code block as a medium level; When the defect occurrence frequency is less than or equal to the preset second frequency threshold, determining the code risk level of the current required code block as a low level.

[0008] Optionally, analyzing the code change frequency and code dependency of the current required code block according to the historical test records in the test domain knowledge base includes: Filtering the code change submission records of the current required code block in the historical test records according to a preset time range; Calculating the code change frequency of the current required code block according to the submission times of the code change submission records and the time range; Constructing a code dependency graph of the current required code block by using the code blocks in the test domain knowledge base; Counting the call times of the current required code block according to the code dependency graph; Determining the code dependency of the current required code block through the call times.

[0009] Optionally, determining the test dynamic priority of the current required code block according to the code change frequency, the code dependency degree, and the code risk level includes: Quantify the levels of the code change frequency, the code dependency degree, and the code risk level respectively to obtain a code frequency quantization value, a code dependency quantization value, and a risk level quantization value; Superimpose the code frequency quantization value, the code dependency quantization value, and the risk level quantization value to obtain a superimposed quantization value; Compare the superimposed quantization value with a preset quantization level condition to obtain the test dynamic priority of the current required code block.

[0010] Optionally, constructing the control flow graph and data flow graph of the current required code block through the test dynamic priority includes: Sort the test dynamic priorities in descending order; Identify the basic blocks of the current required code block one by one according to the sorted test dynamic priorities; Use the basic blocks as control nodes, and determine the connection relationship between the control nodes according to the control transfer statements in the current required code block; Generate the control flow graph of the current required code block according to the control nodes and the connection relationship; Identify the variable parameters of the current required code block, and use the variable parameters as data nodes; Determine the data connection relationship according to the data flow direction of the variable parameters, and generate the data flow graph of the current required code block according to the data nodes and the data connection relationship.

[0011] Optionally, detecting the risk nodes in the control flow graph and data flow graph by using the test domain knowledge base includes: Extract the test risk patterns in the test domain knowledge base according to the test requirements; Extract the matching rule features in the test risk patterns; Detect whether the matching rule features exist in the control nodes of the control flow graph. When the matching rule features exist, determine the control nodes as risk nodes; Detect whether the matching rule features exist in the data nodes of the data flow graph. When the matching rule features exist, determine the data nodes as risk nodes.

[0012] Optionally, generating the test scenario of the current required code block according to the risk nodes includes: Identify the target positions and node patterns of each risk node; Judge the test type of the current requirement code block according to the node pattern and the target position; Determine the test strategy according to the test type and the code risk level; Generate the test scenario of the current requirement code block through the test strategy.

[0013] To solve the above problems, the present invention also provides an electronic device, which includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the above-mentioned automated test scenario generation method.

[0014] To solve the above problems, the present invention also provides a computer-readable storage medium, in which at least one computer program is stored, and the at least one computer program is executed by a processor in an electronic device to implement the above-mentioned automated test scenario generation method.

[0015] In the embodiment of the present invention, by matching the requirement actions in the test requirements with the code entry names, the code blocks related to specific requirements can be accurately found; the code risk level is determined according to the code defect distribution in the test domain knowledge base, and the possible risk degree of the current requirement code block can be clarified; by comprehensively considering the code change frequency, code dependency and code risk level to determine the test dynamic priority, the test order can be reasonably arranged according to the actual situation of the code; the control flow graph and data flow graph can intuitively display the logical structure and data flow of the code, which helps to discover potential problems in the code and improve the comprehensiveness of the test; generating test scenarios according to risk nodes can ensure that the tests cover the risky parts of the code and improve the sufficiency of the test; encapsulating the test scenarios, boundary value test rules and environment simulation rules into an automated test scenario can automatically execute the tests through an automated test tool, greatly reducing the workload of manual testing, improving the test efficiency, and saving time and cost. Therefore, the automated test scenario generation method, device and medium proposed by the present invention can solve the problem of low code coverage when generating a test scenario. Description of the Drawings

[0016] Figure 1 It is a schematic flowchart of an automated test scenario generation method provided by an embodiment of the present invention; Figure 2 It is a comparison diagram of test effects provided by an embodiment of the present invention; Figure 3Schematic diagram of the structure of an electronic device for implementing the automated test scenario generation method provided by an embodiment of the present invention.

[0017] The realization, functional features, and advantages of the present invention will be further described with reference to the embodiments and the accompanying drawings. Detailed implementation manners

[0018] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0019] An embodiment of the present application provides an automated test scenario generation method. The execution subject of the automated test scenario generation method includes, but is not limited to, at least one of electronic devices such as a server, a terminal, etc. that can be configured to execute the method provided by the embodiment of the present application. In other words, the automated test scenario generation method can be executed by software or hardware installed on a terminal device or a server device, and the software can be a blockchain platform. The server includes, but is not limited to: a single server, a server cluster, a cloud server, or a cloud server cluster, etc. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, Content Delivery Network (CDN), and big data and artificial intelligence platforms.

[0020] Refer to Figure 1 As shown, it is a flowchart of the automated test scenario generation method provided by an embodiment of the present invention. In this embodiment, the automated test scenario generation method includes: S1. Extract the required actions in the pre-acquired test requirements, match the required actions with the code entry names corresponding to the pre-acquired code segments, and obtain the current required code block.

[0021] In an embodiment of the present invention, the required action is a specific behavior or operation described in the requirement, such as user login. Among them, the requirement text corresponding to the pre-acquired test requirement is split into independent sentences according to the syntax rules, and each sentence can be used as an independent analysis unit. For each split requirement sentence, according to the pre-determined test requirement intention (for example, functional test intention, performance test intention, or security test intention, etc.), key information is extracted from it, and the key information includes the required action.

[0022] Further, in order to ensure that the test party can fully cover the critical path, it is necessary to achieve an accurate mapping between the requirement items of the test requirements and the code blocks.

[0023] In the embodiment of the present invention, the current requirement code block refers to the code block matched with the test requirement in the pre-acquired code segment.

[0024] In the embodiment of the present invention, the matching of the requirement action with the code entry name corresponding to the pre-acquired code segment to obtain the current requirement code block includes: Identifying the action semantics of the requirement action and vectorizing the action semantics to obtain an action semantics vector; Vectorizing the code entry name corresponding to the code segment to obtain a code entry vector; Calculating the semantic similarity between the action semantics vector and the code entry vector; When the semantic similarity is less than or equal to a preset similarity threshold, marking the code entry vector as an unmatched vector and storing the unmatched vector in a preset database; When the semantic similarity is greater than the preset similarity threshold, taking the code entry name corresponding to the code entry vector as the target code entry name; Determining the code block corresponding to the target code entry name as the current requirement code block.

[0025] Specifically, the action semantics of the requirement action are extracted based on natural language processing technology. For example, if the requirement action is user login, the action semantics are the operations for the user to log in. Then, the semantics are converted into a vector form that can be processed by a computer. Through vectorization technology, the action semantics are represented as a numerical vector, that is, the action semantics vector. The vectorization conversion model includes word embedding (such as Word2Vec, GloVe, etc.). For each code segment, there is a corresponding code entry name, such as a function name, a class name, etc. Similarly, using the vectorization conversion model, the code entry name is converted into a vector form to obtain a code entry vector. Then, each code entry name can be represented by a vector to represent its semantic information.

[0026] Specifically, semantic similarity is an indicator that measures the degree of semantic proximity between an action semantic vector and a code entry vector. The methods for calculating semantic similarity include, but are not limited to, cosine similarity and Euclidean distance. The calculated semantic similarity is compared with a preset similarity threshold. For example, if the similarity threshold is 0.8, when the semantic similarity is less than or equal to the preset similarity threshold, it indicates that the semantic matching degree between the required action and the code entry name is relatively low and does not meet the expected similarity standard. In the code, a specific flag bit (such as a boolean value False indicating non - matching and True indicating matching) is used, and the marked code entry vector is stored in a dedicated list or data structure for subsequent unified processing, such as manual review or automatic triggering of other matching strategies. If the semantic similarity is greater than 0.8, the code entry name corresponding to the code entry vector is determined as the target code entry name. Then, the corresponding code segment is matched according to the target code entry name, and the matched code segment is added to the end of the list. A new field is added to the dictionary representing a single requirement entry, and the matched code entry name is assigned to the new field, thereby obtaining an updated requirement entry field, and further realizing the precise mapping between the requirement entry and the code block.

[0027] Furthermore, to ensure that resources are focused on high - risk areas, it is necessary to analyze the risk level of the code block and preferably generate a test plan for high - risk modules.

[0028] S2. Determine the code risk level of the current requirement code block according to the code defect distribution in the pre - constructed test domain knowledge base.

[0029] In the embodiment of the present invention, the code risk level is a quantitative evaluation index for the possible defects and problems in the current requirement code block, reflecting the likelihood of errors or failures occurring in this code block during actual operation.

[0030] In the embodiment of the present invention, the determining the code risk level of the current requirement code block according to the code defect distribution in the pre - constructed test domain knowledge base includes: Count the defect occurrence frequency of the current requirement code block according to the code defect distribution; When the defect occurrence frequency is greater than or equal to a preset first frequency threshold, determine the code risk level of the current requirement code block as a high level; When the defect occurrence frequency is less than the preset first frequency threshold and greater than a preset second frequency threshold, determine the code risk level of the current requirement code block as a medium level; When the defect occurrence frequency is less than or equal to the preset second frequency threshold, determine the code risk level of the current requirement code block as a low level.

[0031] Specifically, the test domain knowledge base stores various code defect information accumulated during the historical code testing process, including the occurrence of different types of defects in different code blocks, etc., such as null pointers and resource leaks. For the current requirement code block, the frequency of defects occurring in the historical data is statistically analyzed, that is, the ratio of the number of times a specific type of defect occurs in the current requirement code block to the total number of times the code block is tested in the past is calculated.

[0032] Specifically, when the defect occurrence frequency of the current requirement code block is greater than or equal to the preset first frequency threshold, it indicates that the code block often has defects in historical tests and has a relatively high risk. Therefore, its code risk level is determined to be a high level; when the defect occurrence frequency is less than the preset first frequency threshold and greater than the preset second frequency threshold, it shows that the situation of the code block having defects is relatively moderate and the risk is at a medium level. So, its code risk level is determined to be a medium level; when the defect occurrence frequency is less than or equal to the preset second frequency threshold, it means that the code block rarely has defects in historical tests and the risk is relatively low. Thus, its code risk level is determined to be a low level, where both the first frequency threshold and the second frequency threshold can be custom-set.

[0033] Furthermore, in order to better formulate test strategies and allocate test resources, it is necessary to dynamically adjust the test priority based on the code change frequency (Git commit history) and module dependency, and achieve intelligent priority sorting driven by the knowledge base. Compared with traditional coverage-driven, the test efficiency is increased by more than 50%.

[0034] S3. Analyze the code change frequency and code dependency of the current requirement code block according to the historical test records in the test domain knowledge base, and determine the test dynamic priority of the current requirement code block according to the code change frequency, the code dependency, and the code risk level.

[0035] In the embodiment of the present invention, the code change frequency refers to the frequency at which the current requirement code block is modified or updated within a certain time range; the code dependency refers to the degree of dependency between the current requirement code block and other code blocks.

[0036] In the embodiment of the present invention, the analyzing the code change frequency and code dependency of the current requirement code block according to the historical test records in the test domain knowledge base includes: Filter the code change submission records of the current requirement code block in the historical test records according to the preset time range; Calculate the code change frequency of the current requirement code block according to the number of submissions of the code change submission records and the time range; Construct a code dependency graph of the current requirement code block by using code blocks in the test domain knowledge base; Count the number of calls of the current requirement code block according to the code dependency graph; Determine the code dependency degree of the current requirement code block based on the number of calls.

[0037] Specifically, based on a pre-customized time range (such as one week, one day), in the historical test records of the test domain knowledge base, for the current requirement code block, query the code change submission records within the set time range. The code change submission records contain relevant information such as the time of submission, the submitter, and the content of the modification. Then, count the number of code change submission records of the current requirement code block within the preset time range, and divide the number of submissions by the length of the time range to obtain the code change frequency.

[0038] Specifically, the test domain knowledge base contains detailed information about each code block, including the call relationship between code blocks, etc. According to the detailed information of each code block, construct a code dependency graph for the current requirement code block. The code dependency graph is a graphical representation, where nodes represent code blocks and edges represent the dependency relationship between code blocks. For example, if code block A calls code block B, then there will be a directed edge from A to B in the code dependency graph. In the constructed code dependency graph, query the number of edges where the current requirement code block is the called party. This number is the number of calls of the code block. For example, if code block B has three incoming edges from code blocks A, C, and D respectively, then the number of calls of code block B is 3 times. Determine the number of calls as the code dependency degree of the current requirement code block. The more the number of calls, the higher the degree to which the code block is depended on by other code blocks, and the higher its code dependency degree. Usually, the code dependency degree can be divided into different levels according to the number of calls. For example, the number of calls from 0 to 5 times is low dependency, 6 to 10 times is medium dependency, and more than 10 times is high dependency.

[0039] Furthermore, based on the code change frequency (Git commit history) and module dependency degree, dynamically adjust the test priority, and construct a real-time feedback mechanism for the code change hot zone to ensure that resources are focused on high-risk areas.

[0040] In the embodiments of the present invention, the test dynamic priority refers to the test sequence and importance determined for the current requirement code block according to dynamically changing factors such as code change frequency, code dependency degree, and code risk level. It is not fixed and will be adjusted in real time as the code is continuously updated, modified, and the project environment changes.

[0041] In the embodiments of the present invention, determining the test dynamic priority of the current requirement code block according to the code change frequency, the code dependency degree, and the code risk level includes: Quantify the levels of the code change frequency, the code dependency degree, and the code risk level respectively to obtain a code frequency quantization value, a code dependency quantization value, and a risk level quantization value; Superimpose the code frequency quantization value, the code dependency quantization value, and the risk level quantization value to obtain a superimposed quantization value; Compare the superimposed quantization value with a preset quantization level condition to obtain the test dynamic priority of the current requirement code block.

[0042] Specifically, different levels are divided according to the numerical range of the code change frequency. For example, it can be set to three levels: low frequency (few change times), medium frequency (moderate change times), and high frequency (many change times). A corresponding quantization value is assigned to each level. For example, low frequency corresponds to 1, medium frequency corresponds to 2, and high frequency corresponds to 3. If a current requirement code block has very few change times in the past month, the code frequency quantization value is 1; the levels are divided according to the level of code dependency, such as low dependency, medium dependency, and high dependency. Similarly, a quantization value is assigned to each level. For example, low dependency is 1, medium dependency is 2, and high dependency is 3. If a current requirement code block is called by other code blocks very few times, its code dependency quantization value is 1; the code risk level (usually divided into high, medium, and low) is quantified. For example, high risk level corresponds to 3, medium risk level corresponds to 2, and low risk level corresponds to 1. If a current requirement code block is evaluated as a high risk level, its risk level quantization value is 3.

[0043] Specifically, add the code frequency quantization value, the code dependency quantization value, and the risk level quantization value to obtain a comprehensive superimposed quantization value. Compare the superimposed quantization value of the current requirement code block with these conditions to determine its test dynamic priority. Then, preset different quantization level conditions. For example, when the superimposed quantization value is 3 or 4, it is a low priority; when the superimposed quantization value is between 5 and 7, it is a medium priority; when the superimposed quantization value is 8 or 9, it is a high priority. Since the code frequency and risk level are dynamically changing, the priority is dynamically changing, thereby determining that the priority of each requirement code is a dynamic priority.

[0044] Furthermore, in order to accurately analyze the code blocks that are frequently changed, have a high degree of dependency, and have a high risk level, it is necessary to present the logical structure and data flow of the code in a visual manner.

[0045] S4. Construct a control flow graph and a data flow graph of the current requirement code block through the test dynamic priority, and use the test domain knowledge base to detect risk nodes in the control flow graph and the data flow graph.

[0046] In an embodiment of the present invention, the control flow graph is a graphical representation describing the program control flow, with basic blocks as nodes and control transfer relationships as edges, showing the execution order and jump relationships between basic blocks during program execution. The data flow graph is a graphical representation describing the flow and processing of data in a program, with variable parameters as data nodes and data flow directions as edges, showing the process of data generation, transmission, processing, and use in the code.

[0047] In an embodiment of the present invention, constructing the control flow graph and data flow graph of the current requirement code block through the test dynamic priority includes: Sorting the test dynamic priorities in descending order; Identifying the basic blocks of the current requirement code block one by one according to the sorted test dynamic priorities; Taking the basic blocks as control nodes and determining the connection relationships between the control nodes according to the control transfer statements in the current requirement code block; Generating the control flow graph of the current requirement code block according to the control nodes and the connection relationships; Identifying the variable parameters of the current requirement code block and taking the variable parameters as data nodes; Determining the data connection relationships according to the data flow directions of the variable parameters, and generating the data flow graph of the current requirement code block according to the data nodes and the data connection relationships.

[0048] Specifically, sorting the test dynamic priorities in descending order can clarify which code blocks need to be analyzed and processed first. Since high-priority code blocks usually have higher risks or are more critical to the test software and need to be focused on first, for each current requirement code block, starting from the highest priority, the code is divided into basic blocks. A basic block is a continuous region in the code where code execution proceeds sequentially without branches or jumps (except at the entry and exit of the basic block). Taking the basic blocks as control nodes, then analyzing the control transfer statements in the code, such as if - else statements, switch statements, loop statements, and goto statements, etc. These statements determine that the program execution flow will transfer between different basic blocks. According to the control transfer statements, the connection relationships between the control nodes can be determined, that is, which basic blocks will jump to other basic blocks under specific conditions. After determining the control nodes and the connection relationships, the control flow graph is generated.

[0049] Specifically, analyze the variable parameters in each current requirement code block. Variable parameters are elements used to store and transfer data in the code. These variable parameters are used as data nodes, representing the storage and operation locations of data in the code. Analyze the usage of variable parameters in the code to determine the data flow direction. For example, a variable may be assigned a value in one place and then used in other places, thus forming a data flow. The data flow direction can determine the connection relationship between data nodes, that is, the data connection relationship. Then, generate a data flow diagram based on the data nodes and the data connection relationship.

[0050] Furthermore, as important tools for describing the software code structure and data flow, the control flow diagram and the data flow diagram can analyze the running logic and data processing process. By combining the test risk patterns in the test domain knowledge base with the control flow diagram and the data flow diagram, it is possible to more specifically identify the areas in the software that may have risks.

[0051] In the embodiments of the present invention, the risk node refers to a control node or a data node that may have potential risks identified in the control flow diagram or the data flow diagram according to the test risk patterns and their matching rule characteristics in the test domain knowledge base.

[0052] In the embodiments of the present invention, the detection of risk nodes in the control flow diagram and the data flow diagram by using the test domain knowledge base includes: Extract the test risk patterns in the test domain knowledge base according to the test requirements; Extract the matching rule characteristics in the test risk patterns; Detect whether the matching rule characteristics exist in the control nodes in the control flow diagram. When the matching rule characteristics exist, determine the control node as a risk node; Detect whether the matching rule characteristics exist in the data nodes in the data flow diagram. When the matching rule characteristics exist, determine the data node as a risk node.

[0053] Specifically, test risk patterns corresponding to the test requirements are extracted from the test domain knowledge base. The test risk patterns are the summary and induction of various risk situations that have occurred in previous software test projects. For example, there may be some common risk patterns, such as errors caused by uninitialized variables, null pointer references, array out-of-bounds, etc. These patterns are sorted out based on previous test experience and actual software defect situations. For each extracted test risk pattern, the matching rule features are analyzed. The matching rule features are the key elements for identifying whether a risk exists. For example, for the risk pattern of uninitialized variables, its matching rule features include that the variable is not assigned an initial value before use, or the variable may be used without being initialized under a specific code path. By clarifying the matching rule features, risks can be detected more accurately in the control flow graph and data flow graph.

[0054] Specifically, each control node in the control flow graph is traversed. The control node represents a basic block in the code. By analyzing the code corresponding to the control node, it is checked whether there is a situation that conforms to the matching rule features in the test risk pattern. If the code of a certain control node appears a situation that conforms to the risk pattern features such as the use of an uninitialized variable or a null pointer reference, then this control node is marked as a risk node. Similarly, each data node in the data flow graph is matched. The data node represents a variable parameter in the code. According to the situation of the variable represented by the data node during the data flow process, it is judged whether there is a situation that conforms to the matching rule features of the test risk pattern. For example, if it is found that the variable represented by a certain data node may be uninitialized, there is a data conflict, or does not meet the requirements of a specific data type during the data flow process, which conforms to the corresponding risk pattern features, then this data node is determined as a risk node.

[0055] Furthermore, different risk nodes require different test methods and test focuses. In order to test the code targeted, improve the test efficiency and quality, different test scenarios need to be generated to comprehensively test the current requirement code block.

[0056] S5. Generate test scenarios for the current requirement code block according to the risk nodes, and generate boundary value test rules according to the key constraint conditions in the data flow graph.

[0057] In the embodiment of the present invention, the test scenario is a series of specific operation steps and condition combinations designed to verify whether the software system meets specific requirements or whether there are potential risks, simulating various situations that the software may encounter during actual use, including user input, system state, influence of the external environment, etc.

[0058] In the embodiments of the present invention, the test scenario for generating the current requirement code block according to the risk node includes: Identifying the target location and node pattern of each risk node; Judging the test type of the current requirement code block according to the node pattern and the target location; Determining a test strategy according to the test type and the code risk level; Generating a test scenario for the current requirement code block through the test strategy.

[0059] Specifically, in the control flow graph and data flow graph, each risk node corresponds to a specific location in the current requirement code block. Identifying the target location is to clarify the specific line numbers, function names, class names, etc. of the risk node in the code, so as to accurately locate the part of the code that may have risks; the node pattern refers to the characteristic pattern presented by the risk node, and different risk patterns will have different manifestation forms, such as the "use of uninitialized variables" pattern, the "null pointer reference" pattern, etc. Furthermore, different node patterns and target locations will correspond to different test types, and the test types include functional testing, performance testing, security testing, etc. For example, if the pattern of the risk node is SQL injection and the target location is in the code part interacting with the database, then the corresponding test type may be security testing because SQL injection is a security risk; if the node pattern is that the algorithm complexity is too high and the target location is in the algorithm implementation part of the core business logic, then performance testing may be required to ensure that the algorithm can run efficiently under different data scales.

[0060] Specifically, a test strategy (such as the combined ratio of white box / black box / grey box testing) is automatically selected based on the test type (functional / performance / security) and the code risk level. For example, if a high-concurrency module (such as a multi-thread lock) is detected in the code, the proportion of performance testing is automatically increased and a deadlock detection probe is injected. Then, based on the strategy matrix of the requirement type and risk weight, if the test type is functional testing and the code risk level is high risk, the test strategy is that the proportion of white box testing is 60%, the proportion of exception injection testing is 30%, and the proportion of regression testing is 10%; if the test type is performance testing and the code risk level is medium risk, the test strategy is that the proportion of stress testing is 70%, the proportion of static analysis is 20%, and the proportion of competitor comparison is 10%. Thus, based on the determined test strategy, combined with the target location and node pattern of the risk node, a specific test scenario is generated. For example, for a code block with a risk node of "use of uninitialized variables", the test scenario can be described as: under specific input conditions, call the function containing this risk node and observe whether the program will have an exception due to the uninitialized variable.

[0061] Further, in the data flow diagram, data nodes may restrict the value range of data. Then, boundary values are determined for different types of constraint conditions. For constraints with a clear value range, the boundary values usually include the minimum value, the maximum value of the range, and values slightly less than the minimum value and slightly greater than the maximum value; for length format constraints, such as a mobile phone number requiring 11 digits, the boundary values can be 10 digits, 11 digits, and 12 digits; for character type format constraints, such as a password requiring to contain letters and numbers, the boundary values can be cases of containing only letters, containing only numbers, and containing both letters and numbers. Furthermore, the determined boundary values are organized into test rules according to a certain logic, and the test rules can be classified according to different data nodes and constraint types. For example, all test rules related to the grade data node are grouped into one category, and test rules related to the mobile phone number data node are grouped into another category.

[0062] Furthermore, external dependencies are automatically identified through code analysis and Mock services are generated to realize the lightweight of complex system testing. Therefore, it is also necessary to determine the environmental rules of the requirement code.

[0063] S6. Query the environmental simulation rules of the current requirement code block by using the test domain knowledge base, and encapsulate the test scenario, the boundary value test rules, and the environmental simulation rules into an automated test solution.

[0064] In the embodiment of the present invention, the test domain knowledge base is a repository storing a large amount of historical test data and rules, which includes Mock rules for various external APIs. For each external API (Application Programming Interface), the knowledge_base.query method is called, and "MOCK_RULES" and the current external API are passed in as parameters. Here, "MOCK_RULES" is used as an identifier to inform the knowledge base that the Mock rules need to be queried; the current external API is used to precisely match the Mock rules corresponding to this API, and the corresponding Mock rules are queried from the test domain knowledge base, that is, the code analysis engine extracts external API calls (such as database queries, third-party services).

[0065] Specifically, by matching historical Mock rules in the knowledge base, a virtual service container (Docker) is automatically generated. Docker is a commonly used containerization technology that can package an application and its dependencies into an independent container to achieve environment isolation and rapid deployment. During this process, a virtual service container is automatically generated according to the matched Mock rules. The main function of the virtual service container is to simulate the behavior of external APIs. It will receive API requests from the software system according to the Mock rules and return corresponding responses, thereby injecting exception response templates (such as timeouts, error codes) to construct a full-link exception test scenario. The exception response template is a predefined response format for a series of exception situations, such as timeouts, error codes, etc. The template is used to simulate the exception situations that may occur during the actual operation of external APIs. By injecting the exception response template into the virtual service container, when the software system calls an external API, the virtual service container can return these exception responses as needed to simulate various exception scenarios. By injecting the exception response template, various exception situations that may occur during the external API call process can be simulated, thereby constructing a full-link exception test scenario.

[0066] Furthermore, the generate_test_plan function comprehensively utilizes the code analysis results to generate a complete test plan from multiple aspects such as risk nodes, constraint conditions, and external API calls, including test scenarios, environment simulation rules, and test data generation rules. That is, a suitable data structure or format is used to represent the encapsulated automated test plan. For example, in the JSON format, a test scenario can be represented as an array, and each element is a specific test step; the boundary value test rule can be an object containing information such as data nodes, boundary values, and expected results; the environment simulation rule can also be presented in the form of an object, including the type of simulated environment, related parameters, etc. Furthermore, the parameters required by the test tool are configured, such as the source of test data, the setting of the test environment, etc. At the same time, according to the test scenario and rules, corresponding test scripts or codes are written so that the automated test tool can automatically execute tests according to the encapsulated plan.

[0067] Even further, as Figure 2As shown, it is a comparison chart of the test effects of the present invention and the traditional solution. The test effects of the present invention and the traditional solution are significantly improved. For example, the integrity of the test solution of the present invention automatically covers code risks, while the integrity of the test solution of the traditional solution is manually defined, and the improvement effect is to reduce omissions by 80%; the environment preparation time of the present invention is 15 minutes, while the environment preparation time of the traditional solution is 4 hours, and the improvement effect is to increase the efficiency by 16 times, which means that in the software testing or development link, the required test environment can be quickly built, greatly reducing the time consumption of waiting for the environment to be ready. The software and hardware resources required for the test environment are automatically configured and deployed through automated scripts or tools, without relying on manual installation and configuration of various components one by one as in the traditional solution; the pre-built test field knowledge base plays an important role. The knowledge base stores various environmental configuration information, historical experience data, etc. When preparing the environment, you can quickly determine the required resources and configuration steps based on the relevant rules and data in the knowledge base, avoid duplication of work and misconfiguration, and achieve efficient environment preparation. The cross-system abnormal scenario coverage of the present invention is 95%, while the cross-system abnormal scenario coverage of the traditional solution is 20%, and the improvement effect is a 375% increase in coverage, which means that it can more comprehensively detect various abnormal situations that may occur in the cross-system interaction process of the software system. High coverage means that the potential defects and risks of the software in a complex cross-system operating environment can be more fully exposed. The risk pattern and matching rule features in the historical test data are extracted through the test domain knowledge base to detect risk patterns in the control flow graph and data flow graph. Risk nodes are generated based on test scenarios, and boundary value test rules are generated in combination with key constraints of data flow diagrams. This can accurately locate potential risk points in cross-system interactions and design test cases in a targeted manner, thereby greatly improving the coverage of abnormal scenarios. Test scenarios, boundary value test rules and environmental simulation rules are encapsulated into automated test solutions. Automated testing can quickly and comprehensively execute a large number of test cases according to preset rules. Compared with traditional manual testing, it can cover more abnormal scenarios. Moreover, through operations such as automatically injecting abnormal response templates and constructing full-link abnormal test scenarios, it can simulate a variety of abnormal situations, ensuring extensive coverage of cross-system abnormal scenarios, and making the coverage rate increase by 375%.

[0068] like Figure 3 FIG. 1 is a schematic diagram of the structure of an electronic device for implementing an automated test solution generation method provided by an embodiment of the present invention.

[0069] The electronic device may include a processor 10 , a memory 11 , a communication bus 12 , and a communication interface 13 , and may also include a computer program stored in the memory 11 and executable on the processor 10 , such as an automated test solution generation program.

[0070] Among them, in some embodiments, the processor 10 may be composed of an integrated circuit. For example, it may be composed of a single packaged integrated circuit, or may be composed of multiple packaged integrated circuits with the same or different functions, including one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and combinations of various control chips, etc. The processor 10 is the control core (Control Unit) of the electronic device, connecting various components of the entire electronic device through various interfaces and circuits. By running or executing programs or modules stored in the memory 11 (such as executing an automated test scenario generation program, etc.), and by calling data stored in the memory 11, it performs various functions of the electronic device and processes data.

[0071] The memory 11 includes at least one type of readable storage medium. The readable storage medium includes flash memory, mobile hard disks, multimedia cards, card-type memories (such as SD or DX memories, etc.), magnetic memories, magnetic disks, optical discs, etc. In some embodiments, the memory 11 may be an internal storage unit of the electronic device, such as the mobile hard disk of the electronic device. In some other embodiments, the memory 11 may also be an external storage device of the electronic device, such as a plug-in mobile hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc., equipped on the electronic device. Further, the memory 11 may also include both an internal storage unit and an external storage device of the electronic device. The memory 11 can be used not only to store application software installed on the electronic device and various types of data, such as the code of an automated test scenario generation program, etc., but also to temporarily store data that has been output or will be output.

[0072] The communication bus 12 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. The bus is configured to enable connection communication between the memory 11 and at least one processor 10, etc.

[0073] The communication interface 13 is used for communication between the above-mentioned electronic device and other devices, including a network interface and a user interface. Optionally, the network interface may include a wired interface and / or a wireless interface (such as a WI-FI interface, a Bluetooth interface, etc.), which is generally used to establish a communication connection between this electronic device and other electronic devices. The user interface may be a display (Display), an input unit (such as a keyboard (Keyboard)). Optionally, the user interface may also be a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch liquid crystal display, and an OLED (Organic Light-Emitting Diode) toucher, etc. Among them, the display may also be appropriately referred to as a display screen or a display unit, which is used to display the information processed in the electronic device and to display a visual user interface.

[0074] Only the electronic device with components is shown in the figure. Those skilled in the art can understand that the structure shown in the figure does not constitute a limitation on the electronic device, and it may include fewer or more components than shown in the figure, or combine certain components, or have different component arrangements.

[0075] For example, although not shown, the electronic device may further include a power source (such as a battery) for supplying power to each component. Preferably, the power source may be logically connected to the at least one processor 10 through a power management device, so as to implement functions such as charge management, discharge management, and power consumption management through the power management device. The power source may also include any components such as one or more DC or AC power sources, a recharge device, a power failure detection circuit, a power converter or an inverter, and a power status indicator. The electronic device may also include a variety of sensors, a Bluetooth module, a Wi-Fi module, etc., which will not be elaborated here.

[0076] It should be understood that the above embodiments are only for illustration purposes and are not limited by this structure in the scope of the patent application.

[0077] The automated test scenario generation program stored in the memory 11 of the electronic device is a combination of multiple instructions. When running in the processor 10, it can implement: Extract the required actions in the previously obtained test requirements, match the required actions with the code entry names corresponding to the previously obtained code segments, and obtain the current required code block; Determine the code risk level of the current required code block according to the code defect distribution in the previously constructed test domain knowledge base; Analyze the code change frequency and code dependency of the current requirement code block based on the historical test records in the test domain knowledge base, and determine the test dynamic priority of the current requirement code block according to the code change frequency, the code dependency, and the code risk level; Construct a control flow graph and a data flow graph of the current requirement code block through the test dynamic priority, and use the test domain knowledge base to detect risk nodes in the control flow graph and the data flow graph; Generate test scenarios for the current requirement code block based on the risk nodes, and generate boundary value test rules based on the key constraint conditions in the data flow graph; Query the environment simulation rules of the current requirement code block using the test domain knowledge base, and encapsulate the test scenarios, the boundary value test rules, and the environment simulation rules into an automated test solution.

[0078] Specifically, the specific implementation method of the above instructions by the processor 10 can refer to the description of the relevant steps in the corresponding embodiments of the accompanying drawings, which will not be elaborated here.

[0079] Further, if the modules / units integrated in the electronic device are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. The computer-readable storage medium can be volatile or non-volatile. For example, the computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disc, a computer memory, a read-only memory (ROM, Read-Only Memory).

[0080] The present invention also provides a computer-readable storage medium, where the readable storage medium stores a computer program, and when the computer program is executed by a processor of an electronic device, it can implement: Extract the requirement actions in the pre-obtained test requirements, match the requirement actions with the code entry names corresponding to the pre-obtained code segments to obtain the current requirement code block; Determine the code risk level of the current requirement code block according to the code defect distribution in the pre-constructed test domain knowledge base; Analyze the code change frequency and code dependency of the current requirement code block based on the historical test records in the test domain knowledge base, and determine the test dynamic priority of the current requirement code block according to the code change frequency, the code dependency, and the code risk level; Construct a control flow graph and a data flow graph of the current requirement code block through the test dynamic priority, and use the test domain knowledge base to detect risk nodes in the control flow graph and the data flow graph; Generate a test scenario for the current requirement code block based on the risk nodes, and generate boundary value test rules according to the key constraint conditions in the data flow diagram; Query the environment simulation rules for the current requirement code block using the test domain knowledge base, and encapsulate the test scenario, the boundary value test rules, and the environment simulation rules into an automated test solution.

[0081] In several embodiments provided by the present invention, it should be understood that the disclosed devices, media, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules is only a logical function division, and there may be other division methods in actual implementation.

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

[0083] In addition, in each embodiment of the present invention, the functional modules can be integrated in one processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated unit can be implemented in the form of hardware, or in the form of a hardware plus software functional module.

[0084] For those skilled in the art, it is obvious that the present invention is not limited to the details of the above exemplary embodiments, and without departing from the spirit or basic characteristics of the present invention, the present invention can be implemented in other specific forms.

[0085] Therefore, from any point of view, the embodiments should be regarded as exemplary and non-limiting. The scope of the present invention is not limited only by the above description. Therefore, it is intended to include all changes within the meaning and scope of equivalent elements falling within the protection scope in the present invention.

[0086] The embodiments of the present application can acquire and process relevant data based on artificial intelligence technology. Among them, artificial intelligence (AI) is to use a digital computer or a machine controlled by a digital computer to simulate, extend, and expand human intelligence, sense the environment, acquire knowledge, and use knowledge to obtain the best results in theory, methods, technologies, and application systems.

[0087] In addition, it is obvious that the term "including" does not exclude other units or steps, and the singular does not exclude the plural. A plurality of units or devices stated in the system can also be implemented by one unit or device through software or hardware. Terms such as first and second are used to denote names and do not denote any particular order.

[0088] 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 preferred embodiments, those of ordinary skill in the art should understand that the technical solutions of the present invention can be modified or equivalently replaced without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. An automated test scenario generation method, characterized in that, The method includes: Extracting the requirement actions in the pre-acquired test requirements, matching the requirement actions with the code entry names corresponding to the pre-acquired code segments to obtain the current requirement code block; Determining the code risk level of the current requirement code block according to the code defect distribution in the pre-constructed test domain knowledge base; Analyzing the code change frequency and code dependency of the current requirement code block according to the historical test records in the test domain knowledge base, and determining the test dynamic priority of the current requirement code block according to the code change frequency, the code dependency and the code risk level; Constructing a control flow graph and a data flow graph of the current requirement code block through the test dynamic priority, and detecting risk nodes in the control flow graph and the data flow graph by using the test domain knowledge base; Generating a test scenario for the current requirement code block according to the risk nodes, and generating boundary value test rules according to the key constraint conditions in the data flow graph; Querying the environment simulation rules of the current requirement code block by using the test domain knowledge base, and encapsulating the test scenario, the boundary value test rules and the environment simulation rules into an automated test plan.

2. The method for generating an automated test scenario according to claim 1, wherein, The matching the requirement actions with the code entry names corresponding to the pre-acquired code segments to obtain the current requirement code block includes: Identifying the action semantics of the requirement actions, and vectorizing the action semantics to obtain an action semantics vector; Vectorizing the code entry names corresponding to the code segments to obtain a code entry vector; Calculating the semantic similarity between the action semantics vector and the code entry vector; When the semantic similarity is less than or equal to a preset similarity threshold, marking the code entry vector as an unmatched vector and storing the unmatched vector in a preset database; When the semantic similarity is greater than the preset similarity threshold, taking the code entry name corresponding to the code entry vector as the target code entry name; Determining the code block corresponding to the target code entry name as the current requirement code block.

3. The automated test scenario generation method according to claim 1, characterized in that The determining the code risk level of the current requirement code block according to the code defect distribution in the pre-constructed test domain knowledge base includes: Counting the defect occurrence frequency of the current requirement code block according to the code defect distribution; When the defect occurrence frequency is greater than or equal to a preset first frequency threshold, determining the code risk level of the requirement code block as a high level; When the defect occurrence frequency is less than the preset first frequency threshold and greater than a preset second frequency threshold, determining the code risk level of the current requirement code block as a medium level; When the defect occurrence frequency is less than or equal to the preset second frequency threshold, determining the code risk level of the current requirement code block as a low level.

4. The automated test scenario generation method according to claim 1, wherein The analyzing the code change frequency and code dependency of the current requirement code block according to the historical test records in the test domain knowledge base includes: Filtering the code change submission records of the current requirement code block in the historical test records according to a preset time range; Calculate the code change frequency of the current requirement code block according to the number of submissions of the code change submission record and the time range; Construct a code dependency graph of the current requirement code block by using the code blocks in the test domain knowledge base; Count the number of calls of the current requirement code block according to the code dependency graph; Determine the code dependency degree of the current requirement code block through the number of calls.

5. The method for generating an automated test scenario according to claim 1, wherein, The determining the test dynamic priority of the current requirement code block according to the code change frequency, the code dependency degree and the code risk level includes: Quantify the levels of the code change frequency, the code dependency degree and the code risk level respectively to obtain a code frequency quantization value, a code dependency quantization value and a risk level quantization value; Superimpose the code frequency quantization value, the code dependency quantization value and the risk level quantization value to obtain a superimposed quantization value; Compare the superimposed quantization value with a preset quantization level condition to obtain the test dynamic priority of the current requirement code block.

6. The method for generating an automated test scenario according to claim 1, wherein The constructing a control flow graph and a data flow graph of the current requirement code block through the test dynamic priority includes: Sort the test dynamic priorities in descending order; Identify the basic blocks of the current requirement code block one by one according to the sorted test dynamic priorities; Use the basic blocks as control nodes and determine the connection relationship between the control nodes according to the control transfer statements in the current requirement code block; Generate a control flow graph of the current requirement code block according to the control nodes and the connection relationship; Identify the variable parameters of the current requirement code block and use the variable parameters as data nodes; Determine the data connection relationship according to the data flow direction of the variable parameters, and generate a data flow graph of the current requirement code block according to the data nodes and the data connection relationship.

7. The method for generating an automated test scenario according to claim 1, wherein The detecting risk nodes in the control flow graph and the data flow graph by using the test domain knowledge base includes: Extract the test risk patterns in the test domain knowledge base according to the test requirements; Extract the matching rule features in the test risk patterns; Detect whether the matching rule features exist in the control nodes of the control flow graph. When the matching rule features exist, determine the control nodes as risk nodes; Detect whether the matching rule features exist in the data nodes of the data flow graph. When the matching rule features exist, determine the data nodes as risk nodes.

8. The method for generating an automated test scenario according to claim 1, wherein, The generating a test scenario of the current requirement code block according to the risk nodes includes: Identify the target positions and node patterns of each risk node; Judge the test type of the current requirement code block according to the node pattern and the target position; Determine a test strategy according to the test type and the code risk level; Generate a test scenario of the current requirement code block through the test strategy.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and when the computer program is executed by the at least one processor, the at least one processor is enabled to execute the automated test scenario generation method according to any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the automated test scenario generation method according to any one of claims 1 to 8.

Images