Unit test method and device of business system, electronic equipment and storage medium

Abstract

The invention provides a unit testing method and device of a service system, electronic equipment and a storage medium, relates to the technical field of system testing, and is used for solving the technical problems of low unit testing efficiency and insufficient code coverage rate in the prior art. According to the specific technical scheme, the method comprises the steps of generating corresponding test data for each first type of to-be-tested object according to a first generation strategy corresponding to the first type of to-be-tested object; according to a second generation strategy corresponding to the to-be-tested objects of the second type, generating corresponding test data for each to-be-tested object of the second type; and for the target to-be-tested object of which the code coverage rate is smaller than a preset coverage rate threshold value, generating the corresponding unit test case for the target to-be-tested object again, and executing the unit test case until the code coverage rate of the target to-be-tested object is greater than or equal to the preset coverage rate threshold value. By implementing the scheme, the unit testing efficiency and the code coverage rate can be improved.

Description

Technical Field

[0001] This application relates to the field of system testing technology, and in particular to a unit testing method, apparatus, electronic device and storage medium for a business system. Background Technology

[0002] In current software development, unit testing is a crucial means of ensuring code quality and system stability. Its importance is even greater in the development of business systems. However, when business systems have complex business logic and a large amount of code, test code often has to be written manually by developers, leading to inefficiencies and insufficient code coverage in unit testing. Summary of the Invention

[0003] This application provides a unit testing method, apparatus, electronic device, and storage medium for a business system, which addresses the technical problems of low unit testing efficiency and insufficient code coverage in the prior art.

[0004] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: Firstly, a unit testing method for a business system is provided. This business system can be used to manage transaction data between multiple institutions, such as credit systems, payment systems, and other financial business systems. The unit testing method provided in this application can automate the testing of the source code of the business system.

[0005] Specifically, first, the test objects in the source code of the business system are identified. These test objects include classes and methods to be unit tested. Then, the test objects are categorized into either a first type or a second type. Specifically, the test object serving as the transaction entry point is classified as a first type, while the other test objects are classified as second type.

[0006] For the first type of test object, the transaction entry point is typically used to receive and parse incoming data packets from the outside, call internal system services, and return data. The second type of test object is usually a code unit that implements internal system functions. By distinguishing between these different types of test objects, the function of the code unit within the business system architecture can be identified, allowing for the adoption of different test data generation strategies to generate test data.

[0007] This method generates corresponding test data for each type of test object according to a first generation strategy, and generates corresponding test data for each type of test object according to a second generation strategy. The first and second generation strategies differ. Since the type of test object serves as the transaction entry point, the testing requirement is to verify the processing capability of input messages in various formats; therefore, it needs to generate test data with a complete structure and conforming to business specifications. The testing requirement for the type of test object is to verify the accuracy of the system's internal business logic and calculations; therefore, it needs to generate test data that covers various logical branches and boundary conditions.

[0008] By employing different test data generation strategies, more effective test data can be generated for different types of test objects, avoiding the problems of invalid or incomplete test data caused by the indiscriminate test data generation strategies in existing technologies, thereby improving the effectiveness of test data and the sufficiency of testing.

[0009] This method generates corresponding unit test cases for each test object based on a pre-defined unit test template and the corresponding test data. The pre-defined unit test template automates test case generation, reducing the workload of manually writing test cases. Then, the unit test cases for each test object are executed individually. Based on the execution results of all unit test cases for all test objects, the code coverage of the source code by the unit test cases is determined, and the degree to which the unit test cases cover the source code is evaluated. For target test objects with code coverage below a pre-defined coverage threshold, corresponding unit test cases are generated and executed again until the code coverage of the target test object is greater than or equal to the pre-defined coverage threshold. Through an iterative optimization mechanism, test cases are continuously added, gradually improving code coverage and ensuring the adequacy of testing.

[0010] By adopting this solution, the effectiveness of test data is improved by identifying the type of the object to be tested and using the corresponding test data generation strategy. The automated generation of test cases is also achieved, which improves the efficiency of unit testing. Furthermore, through the iterative optimization mechanism, the code coverage of the first test case is ensured to reach the preset coverage threshold, thus avoiding the problem of insufficient code coverage in unit testing.

[0011] In one possible implementation of the first aspect, the above-mentioned generation of corresponding test data for each second-type test object according to the second generation strategy for the second-type test object includes: analyzing the input type and output type of each second-type test object; generating first input data including normal values, boundary values, and outliers according to the input data range corresponding to the input type. Normal values ​​are values ​​other than the maximum and minimum values ​​within the input data range; boundary values ​​are the maximum and / or minimum values ​​within the input data range; and outliers are values ​​outside the input data range, or outliers whose data type is different from the input type. First output data corresponding to the first input data is generated according to the output data range corresponding to the output type. By generating test data containing normal values, boundary values, and outliers, the correctness of the second type of test object can be verified from multiple dimensions, thereby identifying problems such as improper boundary value handling and missing outlier handling, and improving the comprehensiveness of unit testing. Furthermore, by simultaneously generating input and output data, automated verification of the second type of test object can be achieved, increasing the automation level of unit testing.

[0012] In another possible implementation of the first aspect, the method further includes: obtaining multiple execution paths in the second type of test object; performing code analysis on the second type of test object to determine a first target execution path among the multiple execution paths, and generating second input data to cover the first target execution path and second output data corresponding to the second input data. Here, the first target execution path is the execution path not covered by the first input data, and the test data corresponding to the second type of test object also includes the second input data and the second output data corresponding to the second input data.

[0013] By analyzing the code's execution path, execution paths not covered by the initial input data can be identified, allowing for the generation of targeted supplementary test data. This path-coverage-based test data generation method reduces the omission of critical execution paths and improves code coverage during testing.

[0014] In another possible implementation of the first aspect, obtaining multiple execution paths in the second type of test object includes: obtaining multiple conditional statements in the second type of test object; and combining the conditional paths corresponding to the multiple conditional statements to obtain multiple execution paths in the second type of test object.

[0015] By adopting this approach, all possible execution paths can be determined by identifying all conditional statements and combining conditional paths, thereby improving the integrity of multiple execution paths.

[0016] In another possible implementation of the first aspect, the conditional statements include one or more of the following: branching conditional statements, looping conditional statements, and exception handling conditional statements. By identifying various types of conditional statements, the execution path of the code can be comprehensively analyzed, thereby improving the accuracy of path coverage analysis.

[0017] In another possible implementation of the first aspect, when the target test object includes a second type of test object, the above-mentioned generation of corresponding unit test cases for the target test object again includes: determining a second target execution path that has not been executed among the multiple execution paths of the target test object based on the execution result of the unit test cases corresponding to the target test object; generating third input data and third output data corresponding to the third input data to cover the second target execution path; and generating corresponding unit test cases for the target test object according to a preset unit test template and the test data corresponding to the target test object. The test data corresponding to the target test object further includes the third input data and the third output data corresponding to the third input data.

[0018] By analyzing the execution results of test cases, we can accurately locate unexecuted execution paths, thereby supplementing test data for those paths and improving code coverage.

[0019] In another possible implementation of the first aspect, the above-mentioned generation strategy, according to the first type of test object, generates corresponding test data for each first type of test object, including: obtaining historical transaction messages related to the first type of test object; parsing the message data in the historical transaction messages to obtain test data. By reusing historical transaction messages, real and valid test data can be obtained, avoiding the problem of request rejection due to test data not conforming to the message structure, and making full use of existing data resources, reducing the cost of test data generation, and improving the efficiency of test data generation.

[0020] Secondly, a unit testing apparatus for a business system is provided, the apparatus comprising: The object determination module is used to determine the test objects in the source code of the business system. The test objects include the classes and methods to be unit tested. The object recognition module is used to identify whether the object to be tested is a first type of object to be tested or a second type of object to be tested; wherein, the object to be tested that serves as the transaction entry point is a first type of object to be tested, and other objects to be tested are second type of objects to be tested; The data generation module is used to generate corresponding test data for each test object of the first type according to the first generation strategy corresponding to the test object of the first type; and to generate corresponding test data for each test object of the second type according to the second generation strategy corresponding to the test object of the second type; wherein the first generation strategy and the second generation strategy are different. The test case generation module is used to generate corresponding unit test cases for each test object according to the preset unit test template and the test data corresponding to each test object; The test execution module is used to execute the unit test cases corresponding to each object under test, and determine the code coverage of the source code by the unit test cases based on the execution results of the unit test cases corresponding to all objects under test. The test repetition module is used to generate and execute corresponding unit test cases for target test objects whose code coverage is less than a preset coverage threshold, until the code coverage of the target test object is greater than or equal to the preset coverage threshold.

[0021] Thirdly, an electronic device is provided, the method comprising: a memory and at least one processor. The memory is communicatively connected to the processor. The memory is used to store computer program code, the computer program code including computer instructions. When the processor executes the computer instructions, it causes the electronic device to perform the method of the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the method as described in the first aspect and any possible implementation thereof.

[0023] Fifthly, embodiments of this application provide a computer program product that, when running on a computer / executed by the computer's processor, implements the method described in the first aspect and any possible design thereof. The computer may be an electronic device as described in the third aspect and any possible implementation thereof.

[0024] Understandably, the beneficial effects that the unit testing apparatus for the business system of the second aspect, the electronic equipment of the third aspect, the computer-readable storage medium of the fourth aspect, and the computer program product of the fifth aspect can achieve can be referred to the beneficial effects of the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 A flowchart illustrating a unit testing method for a business system provided in an embodiment of this application; Figure 3 A flowchart illustrating another unit testing method for a business system provided in this application embodiment; Figure 4 A schematic diagram of the structure of a unit testing device for a business system provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] The collection, storage, use, processing, transmission, provision, and disclosure of information involved in the technical solutions provided in this application comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0029] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0030] In current software development processes, unit testing is a crucial means of ensuring code quality and system stability. Unit testing involves checking and verifying the smallest testable unit in the software to ensure that each unit functions correctly. In business system development, especially in credit and financial systems involving transactions with multiple institutions, the importance of unit testing is even greater due to the complexity of the business logic and the large volume of code.

[0031] Existing unit testing methods involve manually analyzing code to write test code, including the following steps: developers analyze system code and design test cases based on the analysis results to execute the test code to verify system functionality.

[0032] However, existing unit testing methods have the following problems: First, writing test code is time-consuming. For large systems, developers need to write test code for a large number of classes and methods, consuming a lot of time and manpower. Second, test coverage is insufficient. When developers write test code manually, they may miss some execution paths or boundary cases, resulting in test coverage failing to meet requirements. Third, the maintenance cost of test code is high. As business requirements change, the source code is constantly modified, and the test code also needs to be updated accordingly, increasing the maintenance burden.

[0033] Furthermore, because the objects under test in a business system have different functions within the system architecture, the testing requirements for each object also differ. Specifically, the objects under test in a business system can be divided into at least two categories.

[0034] The first category is the test object that serves as the system's data reception entry point. This type of test object is also called a transaction entry point, used to receive and parse data messages from outside the system, such as JSON or XML request messages.

[0035] The second category consists of test objects that implement specific internal functions of the system. These test objects are typically methods within the system, called by the entry point code, used to perform specific data processing tasks, such as calculating values ​​based on input parameters like amount and interest rate.

[0036] When testing these two types of test objects, developers typically use a unified test data design approach. However, if the same test data generation method is used for test objects with different functions, it may not fully meet the testing requirements and affect the reliability of the test results.

[0037] Based on this, embodiments of this application provide a unit testing method for a business system. This method can identify the type of the object to be tested and adopt different test data generation strategies for different types of objects to be tested, thereby improving the relevance of test data and test coverage. Simultaneously, this method can automatically generate and execute unit test cases, and automatically supplement test cases based on the execution results until the code coverage requirements are met, significantly reducing the time and maintenance costs of unit testing and improving the efficiency and quality of unit testing.

[0038] The unit testing method for the business system provided in this application can be applied to electronic devices with data processing capabilities, such as servers. Alternatively, the electronic device may include a personal computer (PC), tablet computer, laptop computer, portable computer (such as a mobile phone), wearable electronic device (such as a smartwatch), augmented reality (AR) / virtual reality (VR) device, in-vehicle computer, etc. The following embodiments do not impose special limitations on the specific form of the electronic device. The execution subject of the unit testing method for the business system provided in this application can be the aforementioned electronic device or the corresponding unit testing device for the business system. The unit testing device for the business system can be integrated into the electronic device or the processor of the electronic device. For ease of explanation, the following content of this application embodiment will be described using an electronic device as the execution subject.

[0039] Please refer to Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario provided by an embodiment of this application. The unit testing method for a business system provided by this embodiment is applied to a server 101 that includes the business system. This business system is used to manage multiple institutions 102 and transaction data between the multiple institutions 102.

[0040] In one embodiment, the business system may be a credit system, payment system, settlement system, or other financial business system. The business system includes multiple classes and methods, which constitute the source code of the business system. The electronic device is capable of accessing the source code of the business system and analyzing and processing it.

[0041] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a unit testing method for a business system provided in an embodiment of this application.

[0042] S201, Electronic device identifies the object to be tested in the source code of the business system.

[0043] The object to be tested includes classes and methods to be unit tested. In this embodiment, the electronic device needs to perform unit testing on the source code of the business system, and the unit of testing can be the object to be tested. The source code includes multiple classes, and each class includes multiple methods. The electronic device can determine the classes and methods to be tested from the source code.

[0044] In some embodiments, the electronic device can obtain the package path to be tested through a configuration file. This package path indicates the scope of code in the source code that needs to be unit tested. Specifically, the electronic device can use Java reflection to traverse all classes under the specified package path. Java reflection is used to obtain class information, including class name, method name, method parameter types, method return type, etc.

[0045] In some embodiments, the electronic device uses regular expressions to match class and method names from all acquired class and method names to filter out the test objects that need to be unit tested. For example, the electronic device can configure regular expression rules to specify that only classes ending with "abc" will be tested. Alternatively, the electronic device can select methods of a preset method type as the test objects to be unit tested, such as public methods.

[0046] Understandably, the object to be tested can be a class or a method. For each class to be tested, the electronic device can test the entire class; for each method to be tested, the electronic device can call the method for testing based on the class name to which the method belongs and the method name of the method.

[0047] In some embodiments, the electronic device can determine the object to be tested based on code comments. For example, developers can add specific comments to the source code for classes or methods that need to be unit tested, and the electronic device can identify the object to be tested by recognizing those specific comments.

[0048] By using one or more of the above identification methods, electronic devices can identify the test objects that need to be unit tested from the source code of the business system, thereby improving the accuracy of the test objects.

[0049] S202, the electronic device identifies the test object as either a first type of test object or a second type of test object.

[0050] Among them, the test object that serves as the entry point for the transaction is the first type of test object, and the other test objects are the second type of test objects.

[0051] In this embodiment, the electronic device needs to distinguish the type of the object to be tested. Objects to be tested in the business system can be categorized into different types based on their function within the system. This embodiment classifies the objects to be tested into a first type and a second type.

[0052] The first type of test object is the object that serves as a transaction entry point. A transaction entry point refers to the entry method in a business system used to receive external requests. For example, in a credit system, the loan application interface and repayment interface are transaction entry points. This entry point is used to receive data packets sent by external systems or clients and to parse and process these data packets. The second type of test object is other test objects besides transaction entry points. This type of test object can include internal system methods used to implement specific functions or business logic.

[0053] In some embodiments, the electronic device analyzes the comments of various classes and methods in the source code to identify the test objects that serve as transaction entry points, and determines them to be of the first type of test objects. Transaction entry points in the business system may be identified by specific comments, and the electronic device determines whether each object is a transaction entry point by checking whether each object has that specific comment.

[0054] Alternatively, electronic devices can identify transaction entry points by analyzing class and method names. Method names serving as transaction entry points can include specific keywords, or they can conform to preset naming conventions. In this way, electronic devices can also use regular expressions to match class and method names, identify keywords or preset naming conventions, and determine whether the object is a transaction entry point.

[0055] Alternatively, electronic devices can also identify transaction entry points by analyzing the parameter types of the method. Since transaction entry points need to receive specific types of parameters, such as request objects or message objects, electronic devices can determine whether a method is a transaction entry point by checking its parameter types.

[0056] Alternatively, the configuration file can store the transaction entry points specified by the developers. Electronic devices can read the configuration file and identify the transaction entry points based on the configuration information.

[0057] Electronic devices can identify transaction entry points in the source code through one or more of the methods described above to determine the first type of test object and improve the accuracy of the first type of test object.

[0058] After identifying the test object corresponding to the transaction entry point, the electronic device marks the test object corresponding to the transaction entry point as a first type of test object. For test objects that are not identified as transaction entry points, i.e., test objects that are not corresponding to transaction entry points, the electronic device can mark the test objects that are not corresponding to transaction entry points as second type of test objects.

[0059] S203, the electronic device generates corresponding test data for each first type of test object according to the first generation strategy corresponding to the first type of test object; and generates corresponding test data for each second type of test object according to the second generation strategy corresponding to the second type of test object.

[0060] In this embodiment, the electronic device employs different test data generation strategies for different types of test objects; that is, the first generation strategy and the second generation strategy are different. The first type of test object and the second type of test object have different functions in the business system, and their testing requirements also differ, thus requiring different strategies to generate test data.

[0061] In some embodiments, test data includes test input data and corresponding test output data. Test input data is data input into the object under test for executing its methods, and test output data is used to verify the output results of the object under test in response to the test input data.

[0062] The first generation strategy generates test data based on historical transaction data. Since the first type of test object is the transaction entry point, the data received by the first type of test object is usually externally sent transaction messages. The electronic device can obtain historical transaction messages from historical data and obtain test data based on the message content of the transaction messages.

[0063] Specifically, the first generation strategy may include the following steps: The electronic device acquires historical transaction messages related to the first type of test object. The business system includes a message platform. The message platform is used to collect request and response messages from various test environments and / or real environments. The electronic device can acquire historical transaction messages related to the transaction entry point to be tested from the message platform. It is understood that the historical transaction messages related to the first type of test object can refer to transaction messages input into the first type of test object from historical data.

[0064] Then, the electronic device parses the message data in the historical transaction messages, extracts specific data fields from the message data, and obtains the test data. In one embodiment, the electronic device determines the specific data fields to be extracted based on the method information of the transaction entry point. The method information includes the parameter type and parameter name of the method. The electronic device extracts the specific data fields corresponding to the parameter types and the specific data fields corresponding to the parameter names from the message to obtain the test input data in the test data.

[0065] The electronic device can also acquire response messages corresponding to historical transaction messages. These response messages include the output results after the transaction entry point processes the request. The electronic device parses the response messages and extracts the output results, which are then used as test output data in the test data set.

[0066] In the above manner, the electronic device can generate test data for the first type of test object to be tested based on historical transaction data, without the need to generate new test data, thereby improving the authenticity of the test data and the efficiency of generating the test data.

[0067] The second generation strategy generates test data based on the code analysis results. Since the second type of test object to be tested is a method inside the system, and the parameter types and return value types of the method are pre-set, the electronic device can generate corresponding test data according to the parameter types of the method and the business logic.

[0068] Specifically, for each second type of test object to be tested, the electronic device can analyze the input type and output type of the second type of test object to be tested. The output type is the parameter type of the method in the second type of test object to be tested, and the output type is the return value type of the method in the second type of test object to be tested. As an example, the electronic device can obtain the method information of the test object through the Java reflection mechanism. The method information can include the parameter list and the return value type of the method. Each parameter in the parameter list includes a parameter type and a parameter name. The parameter type is referred to as the input type in the embodiments of the present application, and the return value type is referred to as the output type in the embodiments of the present application.

[0069] The embodiments of the present application do not limit the input type and the output type, which can be one or more of the basic data type, the wrapper type, the string type, the date type, the collection type, and the custom object type.

[0070] Then, the electronic device can generate the first input data including normal values, boundary values, and abnormal values according to the input data range corresponding to the input type. Among them, the normal value is the value other than the maximum value and the minimum value within the input data range. The boundary value is one or both of the maximum value and the minimum value of the input data range. The abnormal value is the value outside the input data range, or the data type of the abnormal value is different from the input type.

[0071] For example, for the input data of the integer type, the normal values generated by the electronic device can be common integer values such as 0, 1, 100, etc. The boundary values can be the maximum value and the minimum value of the data range of the integer type. The abnormal value can be null, or the value exceeding the data range.

[0072] For another example, for the input data of the string type, the normal values generated by the electronic device can be strings containing letters, numbers, and Chinese characters, such as "test", "测试", "abc123". The boundary value can be an empty string. The abnormal value can be null, or a string containing special characters.

[0073] For example, for date type parameters, normal values ​​generated by electronic devices can be the current date, past date, future date, etc. Boundary values ​​can be the earliest and latest dates that the date type can represent. Abnormal values ​​can be null or malformed dates.

[0074] In this way, electronic devices can generate test data including normal values, boundary values, and outliers for the second type of test object, thereby improving the comprehensiveness of the test.

[0075] The electronic device generates the first output data corresponding to the first input data based on the output data range corresponding to the output type. Specifically, the electronic device calculates the expected output result for each first input data based on the business logic of the object under test, and uses this as the first output data. For example, for an addition method, the input data is two integers, and the output is the sum of the two integers. The electronic device calculates the expected sum based on the input integer values ​​and uses this as the first output data.

[0076] Thus, the test data corresponding to the second type of test object can include the first input data generated above and the first output data corresponding to the first input data.

[0077] In some embodiments, the second generation strategy further includes path coverage analysis. Path coverage analysis refers to the electronic device analyzing multiple execution paths in the second type of test object and generating test data that covers these multiple execution paths.

[0078] Specifically, the electronic device acquires multiple execution paths from the second type of test object. For example, the electronic device can acquire multiple execution paths from the second type of test object through static code analysis. Static code analysis refers to acquiring the execution path information of code by analyzing its structure and logic without running the code.

[0079] The execution path refers to the complete execution flow within a method, from start to finish. It's understandable that conditional statements within a method can cause branches in the execution path. For example, an `if` statement will produce two branch paths: one for when the condition is true, and the other for when the condition is false.

[0080] In some embodiments, the electronic device may acquire multiple conditional statements from a second type of test object. The conditional statements include one or more of branching conditional statements, looping conditional statements, and exception handling conditional statements.

[0081] Branching conditional statements are statements used to control branching in program execution, such as if-else statements and switch-case statements. Looping conditional statements are statements used to control the continuous execution of a program, such as for loops, while loops, and do-while loops. Exception handling conditional statements are statements used to handle exceptions, such as try statements, catch statements, and finally statements.

[0082] In some embodiments, the electronic device combines the conditional paths corresponding to multiple conditional statements to obtain multiple execution paths in a second type of test object. For example, the second type of test object includes two if statements. The first if statement generates two branch paths: an execution path where condition A is true and a branch path where condition A is false. The second if statement also generates two branch paths: a path where condition B is true and a path where condition B is false. The electronic device combines the branch paths of these two if statements to obtain four execution paths: an execution path where condition A is true and condition B is true, an execution path where condition A is true and condition B is false, an execution path where condition A is false and condition B is true, and an execution path where condition A is false and condition B is false.

[0083] In some embodiments, the electronic device performs code analysis on the second type of test object, determines the first target execution path among multiple execution paths, and generates second input data to cover the first target execution path and second output data corresponding to the second input data.

[0084] Here, the first target execution path refers to the execution path not covered by the first input data. In other words, through static code analysis of the source code, it is predicted that when testing with the first input data, some execution paths may not be executed. The electronic device needs to generate additional test data to cover these uncovered execution paths. In this embodiment, this additional test data is referred to as second input data and second output data.

[0085] For the first target execution path, the electronic device analyzes the conditional constraints on the first target execution path and solves for the input values ​​that can satisfy the conditional constraints, which are then used as the second input data. For example, if the conditional constraints on the first target execution path require the input data to be greater than 10 and less than 20, the electronic device can use 15 as the second input data.

[0086] Thus, the test data corresponding to the second type of test object also includes the second input data and the second output data corresponding to the second input data.

[0087] Through the path coverage analysis described above, electronic devices can generate test data that covers all execution paths in the second type of test object, thereby improving code coverage during testing.

[0088] In some embodiments, the second generation strategy further includes condition combination analysis. Condition combination analysis refers to analyzing the sub-conditions of the conditional expressions in the analysis method to generate test data covering all conditional combinations. Specifically, the electronic device analyzes the conditional expressions in the second type of test object and combines all sub-conditions in all conditional expressions to obtain conditional combinations. For example, the conditional expression in an if statement might be "x>0&&y<10", which includes two sub-conditions "x>0" and "y<10".

[0089] As an example, electronic devices use combinatorial test theory to generate test data that covers all combinations of conditions. Combinatorial test theory is a test design methodology that generates different combinations of parameters to cover all possible combinations of conditions.

[0090] Through the above condition combination analysis, electronic devices can generate test data for all condition combinations in the coverage method, thereby improving the logical coverage of the test.

[0091] In the embodiments of this application, by adopting different test data generation strategies, electronic devices can generate highly targeted and comprehensive test data for different types of test objects.

[0092] S204. The electronic device generates corresponding unit test cases for each object under test according to the preset unit test template and the test data corresponding to each object under test.

[0093] In this embodiment, the electronic device can generate unit test cases using a preset unit test template. The unit test template is a predefined test code framework that includes the basic structure of the test code and placeholders. The electronic device generates complete test code by filling in the placeholders.

[0094] The unit test template may include one or more placeholders from the following: method name placeholders, test input data placeholders, method call placeholders, expected output data placeholders, and assertion statement placeholders. The electronic device fills in the placeholders in the unit test template based on the test data, generating the test method code.

[0095] By using unit test templates, electronic devices can quickly generate well-structured and formatted unit test cases, improving the efficiency of test code generation.

[0096] S205, the electronic device executes the unit test cases corresponding to each object under test, and determines the code coverage of the source code by the unit test cases based on the execution results of the unit test cases corresponding to all objects under test.

[0097] Code coverage is an important indicator for measuring the completeness of unit tests, representing the coverage of the source code during the execution of test cases.

[0098] As an example, an electronic device can invoke the execution engine of a testing framework to execute unit test cases for each object under test. The testing framework executes the unit test cases for each object in the order they are executed. During the execution of the test cases, the electronic device can use code coverage tools to collect code coverage information, which serves as the execution result of the unit test cases for all objects under test. This code coverage information allows the electronic device to determine the code coverage of the source code by the unit test cases. Examples of code coverage tools include JaCoCo and Cobertura.

[0099] In some embodiments, code coverage includes line coverage, method coverage, and class coverage. Line coverage refers to the proportion of lines of code covered during test case execution to the total number of lines of source code. Method coverage refers to the proportion of methods called during test case execution to the total number of methods in the source code. Class coverage refers to the proportion of classes involved during test case execution to the total number of classes in the source code.

[0100] By executing unit test cases and calculating code coverage, electronic devices can evaluate test quality based on the code coverage and provide data support for subsequent test case optimization.

[0101] S206, for the target test object whose code coverage is less than the preset coverage threshold, the electronic device generates and executes the corresponding unit test cases for the target test object again until the code coverage of the target test object is greater than or equal to the preset coverage threshold.

[0102] The electronic device determines whether additional unit test cases are needed based on the statistical results of code coverage. If the code coverage of the object under test does not reach a preset coverage threshold, the electronic device needs to generate additional unit test cases for that object to improve code coverage. In this embodiment, the object under test whose code coverage does not reach the preset coverage threshold is referred to as the target object under test.

[0103] The electronic device iterates through all objects to be tested, obtaining the code coverage rate for each object. It then compares this code coverage rate with a preset coverage threshold, selecting objects whose code coverage is less than the threshold as target test objects.

[0104] In some embodiments, the electronic device analyzes the unexecuted content of the target object under test based on the execution results of the unit test cases corresponding to the target object under test. Unexecuted content refers to content that was not executed during the test execution process, including unexecuted lines of code, unexecuted execution paths, and unused condition combinations.

[0105] For example, an electronic device can determine a second, unexecuted execution path among multiple execution paths of the target object under test based on the execution results of the unit test cases corresponding to the target object. This second target execution path refers to an execution path that has not been executed during the execution of existing test cases. The electronic device can identify this second target execution path by analyzing code coverage information.

[0106] It is important to understand that the first target execution path is obtained by the electronic device through static code analysis of the source code. The electronic device can obtain the first target execution path before executing unit test cases. The second target instruction is obtained by the electronic device through analysis of the execution results. The electronic device can obtain the second target execution path after executing unit test cases.

[0107] According to the test data generation method in the above embodiments, the electronic device can generate third input data to cover the execution path of the second target and third output data corresponding to the third input data. The third input data refers to the input data that can trigger the execution path of the second target, and the third output data refers to the expected output result of the target object under test after receiving the third input data.

[0108] Then, the electronic device can generate corresponding unit test cases for the target object under test according to the preset unit test template and the test data corresponding to the target object under test. At this time, the test data corresponding to the target object under test may include first input data, first output data, second input data, second output data, third input data, and third output data.

[0109] After re-executing the regenerated unit test cases for the target object under test, the electronic device can determine whether the recalculated code coverage is greater than or equal to a preset coverage threshold. If so, the test cases for the target object under test are considered to meet the requirements, and the generation of test cases for that target object under test ends. If not, the device continues to analyze the uncovered code, generate new unit test cases for the target object under test, and repeats the above process until the code coverage is greater than or equal to the preset coverage threshold.

[0110] In some embodiments, the electronic device can set an upper limit on the number of iterations. If the number of iterations reaches this upper limit and the code coverage does not reach a preset coverage threshold, the electronic device can stop generating unit test cases and generate a report prompting developers to manually supplement the unit test cases.

[0111] By automatically supplementing test cases, electronic devices can continuously improve code coverage, ensuring the completeness and effectiveness of unit tests.

[0112] It should be noted that the electronic device performs the above process on all objects under test to ensure that the code coverage of each object under test reaches the preset coverage threshold.

[0113] The unit testing method for the business system provided in this application allows electronic devices to automatically identify the type of the object to be tested, adopt different test data generation strategies for different types of objects to be tested, automatically generate unit test cases and execute them, and automatically supplement test cases based on the execution results until the code coverage meets the requirements.

[0114] To more clearly illustrate the data processing procedure of the unit testing method for the business system provided in this application embodiment, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating another unit testing method for a business system provided in an embodiment of this application.

[0115] The electronic device can obtain each method of each class under the package path as the object to be tested and determine whether each method is a transaction entry point. For methods that are transaction entry points, the electronic device can obtain historical messages from the message platform to parse and obtain test data. For methods that are not transaction entry points, the electronic device can generate test data according to the parameter types and return value types of the methods through a data generator. Then, the electronic device can load unit test templates and generate test cases through the test data. The electronic device then executes the generated test cases and determines the code coverage, judging whether the code coverage of the test cases for each method is less than a preset coverage threshold. For methods with code coverage less than the preset coverage threshold, the electronic device can analyze the uncovered code, generate test data again, and generate test cases again for execution, repeating this process until the code coverage is greater than or equal to the preset coverage threshold. In this way, the electronic device can obtain unit test cases for all methods.

[0116] Specifically, the unit testing method for the business system provided in this application has the following technical effects: First, it reduces the time cost of unit testing. By automatically generating test data and test cases, developers no longer need to manually write large amounts of test code, significantly reducing the time and manpower required for unit testing. Especially in large business systems, automated test generation can greatly improve development efficiency.

[0117] Second, improve test coverage. Through path coverage analysis and condition combination analysis, electronic devices can identify all execution paths and condition combinations in the code, generating corresponding test data to ensure that tests cover various boundary and exception cases. Through an automatic test data supplementation mechanism, electronic devices can continuously improve code coverage until a preset coverage threshold is reached.

[0118] Third, it reduces the maintenance cost of test code. As business requirements change and source code is constantly modified, test code also needs to be updated accordingly. The method provided in this application can automatically generate and update test cases, ensuring that test code stays in sync with the source code and reducing the workload of manually maintaining test code.

[0119] Fourth, improve the relevance of test data. By differentiating between different types of test objects and adopting different test data generation strategies, electronic devices can generate test data that better meets testing requirements. For transaction entry points, using historical transaction messages as test data ensures authenticity and representativeness. For internal system methods, test data generated through code analysis can cover various input scenarios.

[0120] Fifth, it reduces dependence on the external environment. Test cases generated by electronic devices can run independently, without relying on external systems or resources. This improves the stability and repeatability of testing, and facilitates testing in various environments.

[0121] Sixth, improve the reusability of test code. By using preset unit test templates, the test code generated by electronic devices has a standardized structure and uniform format, avoiding repetitive and lengthy test code, and improving the readability and maintainability of the test code.

[0122] Figure 4 This is a schematic diagram of the structure of a unit testing device for a business system provided in an embodiment of this application. Figure 4 As shown, the unit testing device 400 of the business system includes: an object determination module 401, an object identification module 402, a data generation module 403, a test case generation module 404, a test execution module 405, and a test repetition module 406.

[0123] The object determination module 401 is used to determine the test objects in the source code of the business system to be tested. The test objects include classes and methods to be unit tested. The object recognition module 402 is used to identify whether the object to be tested is a first type of object to be tested or a second type of object to be tested; wherein, the object to be tested that serves as the transaction entry point is a first type of object to be tested, and the other objects to be tested are second type of objects to be tested; The data generation module 403 is used to generate corresponding test data for each test object of the first type according to the first generation strategy corresponding to the test object of the first type; and to generate corresponding test data for each test object of the second type according to the second generation strategy corresponding to the test object of the second type; wherein the first generation strategy and the second generation strategy are different. The test case generation module 404 is used to generate corresponding unit test cases for each test object according to the preset unit test template and the test data corresponding to each test object. The test execution module 405 is used to execute the unit test cases corresponding to each object under test, and to determine the code coverage of the source code by the unit test cases based on the execution results of the unit test cases corresponding to all objects under test. The test repetition module 406 is used to generate and execute corresponding unit test cases for the target test object whose code coverage is less than the preset coverage threshold, until the code coverage of the target test object is greater than or equal to the preset coverage threshold.

[0124] In other embodiments, the data generation module 403 is further configured to analyze the input type and output type of each test object of the second type; the output type is the parameter type of the method in the test object, and the output type is the return value type of the method in the test object; generate first input data including normal values, boundary values, and abnormal values ​​according to the input data range corresponding to the input type; the normal value is a value other than the maximum and minimum values ​​in the input data range, the boundary value is the maximum and / or minimum value in the input data range; the abnormal value is a value outside the input data range, or the data type of the abnormal value is different from the input type; generate first output data corresponding to the first input data according to the output data range corresponding to the output type; wherein, the test data corresponding to the test object of the second type includes the first input data and the first output data corresponding to the first input data.

[0125] In other embodiments, the data generation module 403 is further configured to acquire multiple execution paths in the test object of the second type; perform code analysis on the test object of the second type to determine a first target execution path among the multiple execution paths, and generate second input data to cover the first target execution path and second output data corresponding to the second input data; the first target execution path refers to the execution path not covered by the first input data; wherein, the test data corresponding to the test object of the second type also includes the second input data and the second output data corresponding to the second input data.

[0126] In other embodiments, the data generation module 403 is further configured to obtain multiple conditional statements in the test object of the second type; and combine the conditional paths corresponding to the multiple conditional statements to obtain multiple execution paths in the test object of the second type.

[0127] In other embodiments, the conditional statement includes one or more of the following: branching conditional statement, looping conditional statement, and exception handling conditional statement.

[0128] In other embodiments, the test case generation module 404 is further configured to: determine a second target execution path that has not been executed among the multiple execution paths of the target test object based on the execution result of the unit test case corresponding to the target test object; generate third input data for covering the second target execution path and third output data corresponding to the third input data; and generate corresponding unit test cases for the target test object according to a preset unit test template and the test data corresponding to the target test object; wherein the test data corresponding to the target test object further includes the third input data and the third output data corresponding to the third input data.

[0129] In other embodiments, the data generation module 403 is further configured to acquire historical transaction messages related to the test object of the first type; and parse the message data in the historical transaction messages to obtain test data.

[0130] The unit test device for the business system provided in this application embodiment can execute the method shown in the above method embodiment. Its implementation principle and beneficial effects can be referred to the relevant description in the method embodiment, and will not be repeated here.

[0131] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device includes: a memory 501, a transceiver 502, and at least one processor 503.

[0132] Transceiver 502 is used to interact with other devices to send and receive data.

[0133] The memory 501 is used to store computer program code, which includes computer instructions. These computer instructions run in the aforementioned electronic device to implement the method shown in the above-described method embodiments. For example, the memory may include high-speed random access memory (RAM), and may also include non-volatile memory (NVM), such as at least one disk storage device, or a USB flash drive, portable hard drive, read-only memory, magnetic disk, or optical disk, etc.

[0134] Processor 503 can be a general-purpose processor, including a Central Processing Unit (CPU), a network processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 503 can also be other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor.

[0135] The memory 501, transceiver 502, and processor 503 are communicatively connected. For example, the memory 501 and transceiver 502 can be connected to the processor 503 via a system bus and communicate with each other. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the figure, but this does not mean that there is only one bus or one type of bus.

[0136] Optionally, the memory 501 can be either standalone or integrated with the processor 503. When the memory 501 is set up independently, it is connected to the processor 503 via a system bus.

[0137] This application also provides a chip for executing instructions, which is used to execute the unit testing method of the business system in the above embodiments.

[0138] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the unit testing method of the business system described in the above embodiments. Specifically, when the computer instructions are executed by a processor, the electronic device can execute the unit testing method of the business system described in the above embodiments.

[0139] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, it can implement the technical solution of the unit testing method of the business system in the above embodiments.

[0140] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0141] An exemplary computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the computer-readable storage medium can exist as discrete components in an electronic control unit or main control device; this application does not limit this.

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

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

[0144] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0145] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0146] It should be understood that the steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0147] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0148] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A unit testing method for a business system, characterized in that, The business system is used to manage transaction data between multiple institutions; the method includes: Identify the test objects in the source code of the business system to be tested, the test objects including classes and methods to be unit tested; The test object is identified as either a first type of test object or a second type of test object; wherein, the test object that serves as the transaction entry point is a first type of test object, and the other test objects are second type of test objects; According to the first generation strategy corresponding to the first type of test object, corresponding test data is generated for each first type of test object; according to the second generation strategy corresponding to the second type of test object, corresponding test data is generated for each second type of test object; wherein, the first generation strategy and the second generation strategy are different; According to the preset unit test template, and based on the test data corresponding to each of the objects to be tested, corresponding unit test cases are generated for each of the objects to be tested; Execute the unit test cases corresponding to each of the objects to be tested, and determine the code coverage of the source code by the unit test cases based on the execution results of all the unit test cases corresponding to the objects to be tested. For a target test object whose code coverage is less than a preset coverage threshold, generate corresponding unit test cases for the target test object again and execute them until the code coverage of the target test object is greater than or equal to the preset coverage threshold.

2. The method according to claim 1, characterized in that, The step of generating corresponding test data for each test object of the second type according to the second generation strategy for the test object of the second type includes: For each test object of the second type, analyze the input type and output type of the test object of the second type; the output type is the parameter type of the method in the test object, and the output type is the return value type of the method in the test object; Based on the input data range corresponding to the input type, first input data including normal values, boundary values, and outliers is generated; the normal value is a value other than the maximum and minimum values ​​within the input data range, the boundary value is the maximum and / or minimum value within the input data range, and the outlier value is a value outside the input data range, or the data type of the outlier value is different from the input type. Based on the output data range corresponding to the output type, generate the first output data corresponding to the first input data; The test data corresponding to the second type of test object includes the first input data and the first output data corresponding to the first input data.

3. The method according to claim 2, characterized in that, The method further includes: Obtain multiple execution paths from the test object of the second type; Code analysis is performed on the second type of test object to determine the first target execution path among the multiple execution paths, and second input data and second output data corresponding to the second input data are generated to cover the first target execution path; the first target execution path refers to the execution path not covered by the first input data; The test data for the second type of test object also includes the second input data and the second output data corresponding to the second input data.

4. The method according to claim 3, characterized in that, The step of obtaining multiple execution paths from the second type of test object includes: Retrieve multiple conditional statements from the test object of the second type; The conditional paths corresponding to the multiple conditional statements are combined to obtain multiple execution paths in the test object of the second type.

5. The method according to claim 4, characterized in that, The conditional statements include one or more of the following: branching conditional statements, looping conditional statements, and exception handling conditional statements.

6. The method according to claim 3, characterized in that, The target test object includes the test object of the second type, and the step of generating corresponding unit test cases for the target test object again includes: Based on the execution results of the unit test cases corresponding to the target test object, determine the second target execution path that was not executed among the multiple execution paths of the target test object, and generate third input data to cover the second target execution path and third output data corresponding to the third input data; According to the preset unit test template, and based on the test data corresponding to the target test object, corresponding unit test cases are generated for the target test object; The test data corresponding to the target object to be tested also includes the third input data and the third output data corresponding to the third input data.

7. The method according to claim 1, characterized in that, The step of generating corresponding test data for each test object of the first type according to the first generation strategy includes: Obtain historical transaction messages related to the test object of the first type; The test data is obtained by parsing the message data in the historical transaction messages.

8. A unit testing device for a business system, characterized in that, The business system is used to manage multiple institutions and transaction data between the multiple institutions; the device includes: The object determination module is used to determine the test objects in the source code of the business system to be tested, and the test objects include classes and methods to be unit tested; The object recognition module is used to identify the test object as either a first type of test object or a second type of test object; wherein, the test object that serves as the transaction entry point is the first type of test object, and the other test objects are the second type of test objects; The data generation module is used to generate corresponding test data for each test object of the first type according to a first generation strategy corresponding to the test object of the first type; and to generate corresponding test data for each test object of the second type according to a second generation strategy corresponding to the test object of the second type; wherein the first generation strategy and the second generation strategy are different; The test case generation module is used to generate corresponding unit test cases for each of the test objects according to a preset unit test template and the test data corresponding to each test object. The test execution module is used to execute the unit test cases corresponding to each of the objects to be tested, and determine the code coverage of the source code by the unit test cases based on the execution results of the unit test cases corresponding to all the objects to be tested. The test repetition module is used to generate and execute corresponding unit test cases for the target test object whose code coverage is less than a preset coverage threshold, until the code coverage of the target test object is greater than or equal to the preset coverage threshold.

9. An electronic device, characterized in that, include: A memory and at least one processor; the memory is communicatively connected to the processor; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, When the computer program product is run on a computer / executed by the computer's processor, it implements the method as described in any one of claims 1-7.

Images