Software testing method, device, computer equipment and readable storage medium

By performing static and dynamic analysis of error codes, generating code coverage information, optimizing test case library, and recommending regression test cases, it solves the problem that traditional software testing methods are difficult to fully cover complex software, and achieves more efficient software testing effects.

CN118779234BActive Publication Date: 2025-09-02RURAL CREDIT BANKS FUNDS CLEARING CENT CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202410892707.1
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-07-04
Publication Date
2025-09-02
Estimated Expiration
2044-07-04

AI Technical Summary

Technical Problem

Traditional software testing methods are difficult to fully cover all code paths of complex software, resulting in some errors and defects being missed.

Method used

By locating error codes with basic test cases, perform static and dynamic analysis to obtain call chains and dependencies, generate code coverage information, optimize test case library, and recommend regression test cases.

Benefits of technology

Significantly improve the coverage and efficiency of software testing, ensuring software quality and stability.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118779234B_ABST
    Figure CN118779234B_ABST
Patent Text Reader

Abstract

The present invention discloses a software testing method, apparatus, computer device, and readable storage medium, comprising: first, performing preliminary testing on the software to be tested using basic test cases to locate and display error codes. Next, performing in-depth static and dynamic analysis on the error codes to obtain their call chains and dependencies. Based on this information, detailed code coverage information is generated, and the test case library is optimized. Finally, regression test cases for the software to be tested are recommended and executed from the optimized test case library to ensure the quality and stability of the software. This design significantly improves the coverage and efficiency of software testing through intelligent analysis and optimization of test cases.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of software testing, and in particular to a software testing method, apparatus, computer equipment, and readable storage medium. Background Art

[0002] During the software development process, testing is a critical step in ensuring software quality. Traditional software testing methods often rely on a fixed set of test cases, but this approach often fails to fully cover all code paths when dealing with complex software, resulting in some errors and defects being missed. Summary of the Invention

[0003] The object of the present invention is to provide a software testing method, apparatus, computer equipment and readable storage medium.

[0004] In a first aspect, an embodiment of the present invention provides a software testing method, comprising:

[0005] Use basic test cases to test the software to be tested, locate and display error codes;

[0006] Perform static and dynamic analysis on the error code to obtain the corresponding call chain and dependency relationship;

[0007] Generate code coverage information according to the error code, the call chain and the dependency relationship;

[0008] A test case library is optimized according to the code coverage information, the call chain and the dependency relationship, and regression test cases for the software to be tested are recommended and executed from the optimized test case library.

[0009] In a possible implementation, using basic test cases to test the software to be tested, and locating and displaying error codes, includes:

[0010] Use basic test cases to test the software to be tested and collect data to achieve forward and reverse tracing;

[0011] Based on the code execution information collected by the data, the error code is located and displayed.

[0012] In a possible implementation, performing static and dynamic analysis on the error code to obtain a corresponding call chain and dependency relationship includes:

[0013] Perform static analysis of method call relationships, call chains of modified methods, bridge interfaces and implementation classes, and optimization analysis results based on the code execution information and the defect location results of the error code;

[0014] Dynamic analysis through Javaagent;

[0015] Collect relevant business link topology diagrams, obtain the upstream and downstream services of the changed interface and the impact on the interface, and perform upstream and downstream dependency analysis;

[0016] The call chain and the dependency relationship are obtained according to the static analysis, the dynamic analysis and the upstream and downstream dependency analysis.

[0017] In a possible implementation, generating code coverage information according to the error code, the call chain, and the dependency relationship includes:

[0018] According to the code execution information, the call chain and the dependency relationship, collecting and acquiring original code coverage information from the software to be tested by probe instrumentation;

[0019] Performing preliminary aggregation on the original code coverage information to obtain a preliminary aggregation result;

[0020] Determine the statistical scope according to the preset statistical request;

[0021] The preliminary aggregation results are re-aggregated based on the statistical range to generate the final code coverage information.

[0022] In one possible implementation, optimizing a test case library based on the code coverage information, the call chain, and the dependency relationship, and recommending and executing regression test cases for the software to be tested from the optimized test case library includes:

[0023] Optimizing a test case library according to the code coverage information, the call chain, and the dependency relationship;

[0024] Obtaining a pre-trained test case and code function relationship model, wherein the test case and code function relationship model is used to determine a mapping relationship between a single test case and code;

[0025] Obtain the difference between the change code and the production code and determine the target change code;

[0026] Combining the test case and the code function relationship model and the call chain analysis result of the software to be tested, recommending and executing regression test cases for the target changed code;

[0027] The uncovered incremental code is obtained according to the call chain analysis, and the test is notified to complete the regression case.

[0028] In a possible implementation, the test case library further includes historical test cases targeting historical defects, and the historical test cases are used to enhance code areas with historical problems in regression testing.

[0029] In a possible implementation, the recommending and executing regression test cases for the software to be tested on the target changed code includes:

[0030] Prioritized regression test cases are recommended and executed for the target changed code.

[0031] In a second aspect, an embodiment of the present invention provides a software testing device, comprising:

[0032] The test module is used to test the software to be tested using basic test cases, locate and display error codes; perform static and dynamic analysis on the error codes to obtain corresponding call chains and dependency relationships; generate code coverage information based on the error codes, the call chains and the dependency relationships; optimize the test case library based on the code coverage information, the call chains and the dependency relationships, and recommend and execute regression test cases for the software to be tested from the optimized test case library.

[0033] In a third aspect, an embodiment of the present invention provides a computer device, comprising a processor and a non-volatile memory storing computer instructions. When the computer instructions are executed by the processor, the computer device executes the method described in at least one possible implementation of the first aspect.

[0034] In a fourth aspect, an embodiment of the present invention provides a readable storage medium, wherein the readable storage medium includes a computer program, and when the computer program runs, it controls the method described in at least one possible implementation of the first aspect of the computer device where the readable storage medium is located.

[0035] Compared with the prior art, the beneficial effects provided by the present invention include: using a software testing method, apparatus, computer equipment and readable storage medium disclosed in the present invention, preliminary testing is performed on the software to be tested using basic test cases to locate and display error codes. Next, in-depth static and dynamic analysis of the error code is performed to obtain its call chain and dependency relationships. Based on this information, detailed code coverage information is generated, and the test case library is optimized. Finally, regression test cases for the software to be tested are recommended and executed from the optimized test case library to ensure the quality and stability of the software. This design significantly improves the coverage and efficiency of software testing through intelligent analysis and optimization of test cases. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly describes the drawings required for use in the embodiments. It should be understood that the following drawings illustrate only certain embodiments of the present invention and should not be construed as limiting the scope of the present invention. Those skilled in the art can, without inventive effort, derive other relevant drawings from these drawings.

[0037] Figure 1 A schematic diagram of the steps of the software testing method provided by an embodiment of the present invention;

[0038] Figure 2 A schematic block diagram of the structure of a software testing device provided in an embodiment of the present invention;

[0039] Figure 3 A schematic block diagram of the structure of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0040] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings of the embodiments of the present invention. It should be understood that the described embodiments are only a portion of the embodiments of the present invention, not all of them. Generally, the components of the embodiments of the present invention described and illustrated in the drawings herein may be arranged and designed in a variety of different configurations.

[0041] The specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0042] In order to solve the technical problems in the above background technology, Figure 1 The following is a flowchart of a software test method provided by an embodiment of the present disclosure.

[0043] Step S201: Use basic test cases to test the software to be tested, locate and display error codes;

[0044] Step S202: statically and dynamically analyze the error code to obtain the corresponding call chain and dependency relationship;

[0045] Step S203: Generate code coverage information according to the error code, the call chain, and the dependency relationship;

[0046] Step S204: optimizing a test case library according to the code coverage information, the call chain, and the dependency relationship, and recommending and executing regression test cases for the software to be tested from the optimized test case library.

[0047] In an exemplary embodiment of the present invention, the server executes a series of predefined basic test cases that cover the main functions and boundary conditions of the software under test. During execution, the server detects an exception in a functional module. Using logs and error tracking mechanisms, the server locates the code segment that caused the error and displays the specific error code and error location on the interface. The server conducts an in-depth analysis of the located error code. First, using static code analysis tools, the server analyzes the dependencies between the error code and other code modules and constructs a code dependency graph. Next, using dynamic analysis techniques, the server traces the execution path of the error code at runtime, obtaining complete call chain information, including which functions or methods are called and the order in which they are called. Based on the error code, call chain, and dependency relationships, the server generates detailed code coverage information. This information includes which lines of code are executed, which are not executed, and the execution frequency. The server also compares this information with the expected code coverage target to identify deficiencies in the test. The server optimizes the existing test case library using code coverage information, call chains, and dependency relationships. It removes outdated or no longer applicable test cases and adds new ones for newly discovered bugs and uncovered code. After optimization, the server recommends a set of regression test cases from the test case library for the software under test and executes them. During execution, the server continuously monitors the test results to ensure that all critical functions and code paths are fully tested. Through these steps, the server effectively and comprehensively tests the software under test, locates and fixes bugs, and ensures the continuous update and optimization of the test case library, improving software quality and stability.

[0048] In the embodiment of the present invention, the aforementioned step S201 can be implemented through the following example.

[0049] Use basic test cases to test the software to be tested and collect data to achieve forward and reverse tracing;

[0050] Based on the code execution information collected by the data, the error code is located and displayed.

[0051] In an embodiment of the present invention, the server exemplarily executes a series of predefined basic test cases designed to cover the main functions and boundary conditions of the software under test. During the testing process, the server not only monitors the test results but also conducts comprehensive data collection, including key information such as the code execution path, function call relationships, and variable value changes. This data is recorded for subsequent forward and reverse tracing. Forward tracing refers to the server's ability to trace the code execution path and function call relationships based on the test case execution process, thereby understanding the software's behavior under specific inputs. Reverse tracing, on the other hand, means that when an error or anomaly is discovered, the server can use the collected data to reverse-engineer the code segment that caused the error. During the testing process, the server detected an exception during the execution of a functional module. Using the reverse tracing mechanism, the server used previously collected code execution information to locate the code segment that caused the error. Specifically, the server analyzed the function call stack at the time of the exception, identified the function that caused the exception, and further traced the error code within that function. Finally, the server displayed the specific error code and error location on the user interface, along with related code execution information and function call relationships. This enables developers to quickly understand the context in which the error occurred and take appropriate remedial measures. Through the above steps, the server not only comprehensively tests the software under test, but also quickly locates and displays error codes through data collection and tracing mechanisms, greatly improving the efficiency and accuracy of software testing.

[0052] In the embodiment of the present invention, the aforementioned step S202 can be implemented through the following example.

[0053] Perform static analysis of method call relationships, call chains of modified methods, bridge interfaces and implementation classes, and optimization analysis results based on the code execution information and the defect location results of the error code;

[0054] Dynamic analysis through Javaagent;

[0055] Collect relevant business link topology diagrams, obtain the upstream and downstream services of the changed interface and the impact on the interface, and perform upstream and downstream dependency analysis;

[0056] The call chain and the dependency relationship are obtained according to the static analysis, the dynamic analysis and the upstream and downstream dependency analysis.

[0057] In an embodiment of the present invention, after locating the error code, the server, for example, begins in-depth static and dynamic analysis of the code to obtain its call chain and dependencies. First, the server performs static analysis using previously collected code execution information and the defect location results for the error code. During this process, the server analyzes the call relationships between methods, focusing specifically on the call chains that call the modified method (i.e., the method containing the error code). The server also analyzes the relationship between the bridge interface and the implementation class, optimizing the analysis results to more comprehensively understand the position and impact of the error code in the software architecture. Next, the server performs dynamic analysis using Javaagent technology. Javaagent is a bytecode manipulation technology at the JVM level that allows the server to dynamically monitor and modify the behavior of Java classes at runtime. Using this technology, the server can track the execution path of the error code in real time, including key information such as which methods are called, the order of calls, and the parameters passed. Furthermore, the server collects relevant service chain topology diagrams to obtain information about the upstream and downstream services of the modified interface. By analyzing this information, the server can understand the position of the interface containing the error code in the service chain and its impact on other interfaces and services. This step is crucial for understanding the business context and potential impact of the error code. Finally, the server combines the results of static analysis, dynamic analysis, and upstream and downstream dependency analysis to obtain a complete call chain and dependency relationships. This information includes key details such as which methods the error code is called from, the order in which they are called, and which other code or services it depends on. This information enables developers to gain a deeper understanding of the error code's context and impact, enabling more effective remediation and optimization efforts.

[0058] In the embodiment of the present invention, the aforementioned step S203 can be implemented through the following example.

[0059] According to the code execution information, the call chain and the dependency relationship, collecting and acquiring original code coverage information from the software to be tested by probe instrumentation;

[0060] Performing preliminary aggregation on the original code coverage information to obtain a preliminary aggregation result;

[0061] Determine the statistical scope according to the preset statistical request;

[0062] The preliminary aggregation results are re-aggregated based on the statistical range to generate the final code coverage information.

[0063] In an embodiment of the present invention, the server, for example, begins generating code coverage information after obtaining error codes, call chains, and dependency relationships. First, the server uses previously collected code execution information, call chains, and dependency relationships to collect raw code coverage information from the software under test through probe instrumentation. Probe instrumentation is a technique that inserts specific code snippets into software to collect runtime information. In this case, the server inserts probes that can trace the code execution path and record which lines of code were executed. Next, the server performs preliminary aggregation on the collected raw code coverage information. Aggregation refers to the process of combining multiple data points into a higher-level data point. In this step, the server combines the execution information recorded by the probes into preliminary coverage data, such as which functions or methods were executed and how often. The server then determines the statistical scope based on a pre-defined statistical request. The statistical request may include a specific code module, functional area, or test case set. The server uses this information to define which code should be included in the final coverage statistics. Finally, the server re-aggregates the preliminary aggregation results based on the determined statistical scope to generate the final code coverage information. This step involves calculating the coverage percentage for each code module or functional area and identifying which lines of code were not exercised. The server also compares this information with the expected code coverage target to identify testing gaps. Through these steps, the server generates detailed code coverage information, which is invaluable for assessing test completeness, identifying untested code areas, and guiding subsequent testing activities.

[0064] In the embodiment of the present invention, the aforementioned step S204 can be implemented through the following example.

[0065] Optimizing a test case library according to the code coverage information, the call chain, and the dependency relationship;

[0066] Obtaining a pre-trained test case and code function relationship model, wherein the test case and code function relationship model is used to determine a mapping relationship between a single test case and code;

[0067] Obtain the difference between the change code and the production code and determine the target change code;

[0068] Combining the test case and the code function relationship model and the call chain analysis result of the software to be tested, recommending and executing regression test cases for the target changed code;

[0069] The uncovered incremental code is obtained according to the call chain analysis, and the test is notified to complete the regression case.

[0070] In an embodiment of the present invention, after obtaining code coverage information, call chains, and dependencies, the server illustratively begins optimizing the test case library and recommending regression test cases. First, the server optimizes the existing test case library using code coverage information, call chains, and dependencies. It analyzes which test cases cover critical code paths and dependencies and which do not. Based on this information, the server removes outdated or no longer applicable test cases and adds new test cases targeting newly discovered bugs and uncovered code. Next, the server obtains a pre-trained model of the relationship between test cases and code functions. This model determines the mapping between individual test cases and code, specifically, which test cases cover which code functions. The server uses this model to help identify and optimize test cases in the test case library. The server then extracts the differences between the modified code and the production code and identifies target modified code. These target modified code are recent code changes, which may include bug fixes, new feature additions, or performance optimizations. The server ensures that these modified code are fully tested. Next, the server combines the test cases with the code function relationship model and the call chain analysis results of the software under test to recommend and execute regression test cases for the target changed code. The server selects test cases from the optimized test case library that cover the target changed code and executes these test cases to ensure the correctness of the changed code. Finally, the server identifies uncovered incremental code based on the call chain analysis and notifies the tester to complete the regression test cases. These uncovered incremental code are new or changed code paths that are not yet covered by any test cases. The server provides this information to the tester so that they can add new test cases to cover these code paths, ensuring the completeness of the test and the quality of the software. Through the above steps, the server can effectively optimize the test case library, recommend and execute regression test cases for the software under test, and ensure that all key functions and code paths are fully tested.

[0071] In an embodiment of the present invention, the test case library further includes historical test cases for historical defects, and the historical test cases are used to enhance code areas with historical problems in regression testing.

[0072] In an embodiment of the present invention, the server, for example, pays special attention to the importance of historical defects when maintaining a test case library. To enhance coverage of code areas with historical issues during regression testing, the server incorporates historical test cases targeting these historical defects into the test case library. Specifically, the server first analyzes past software versions and associated defect reports to identify code areas with recurring issues. It then finds historical test cases corresponding to these historical defects, which have already successfully discovered and fixed them in previous versions. The server then adds these historical test cases to the existing test case library, ensuring coverage of these code areas with historical issues in subsequent regression testing. This allows developers to verify the correctness of these modifications or add new features to these code areas by running these historical test cases, preventing the recurrence of previously fixed defects. For example, suppose that in a previous software version, the server discovered a historical defect related to database connectivity. This defect prevented the software from properly connecting to the database under certain conditions. To fix this defect, the developer wrote the corresponding fix code and created a historical test case to verify the effectiveness of the fix. Now, during subsequent regression testing, the server will run this historical test case to ensure that changes to the database connection have not introduced new problems and that previously fixed defects have not reappeared. By including historical test cases for historical defects, the server can perform regression testing more effectively, increase coverage of code areas with historical problems, and improve the overall quality and stability of the software.

[0073] In an embodiment of the present invention, the aforementioned step of recommending and executing regression test cases for the software to be tested for the target changed code can be implemented through the following example.

[0074] Prioritized regression test cases are recommended and executed for the target changed code.

[0075] In an embodiment of the present invention, after the server identifies the target code changes, it illustratively recommends and executes regression test cases for these code changes. To improve testing efficiency, the server does not simply randomly select test cases, but rather prioritizes them. First, the server analyzes the nature and importance of the target code changes. It considers the type of change (such as feature enhancement, bug fix, or performance optimization), the scope of the change (the amount of code and number of modules affected), and the potential risks of the change (such as potential instability or compatibility issues). Next, the server prioritizes the regression test cases based on the analysis results. It assigns higher priority to test cases that cover critical functionality, fix serious bugs, or verify performance optimizations. Meanwhile, the server assigns lower-priority test cases to changes that affect only a small amount of code or carry lower risks. The server then executes these regression test cases in order of priority. It first runs high-priority test cases to ensure that key functionality and fixes are fully verified. After confirming that these high-priority test cases have passed, the server moves on to lower-priority test cases. For example, suppose the server recently fixed a serious bug in the user login function. In this case, the server first recommends and executes regression tests that verify the correct functioning of user login functionality to ensure the fix is ​​effective. Only after these high-priority test cases pass will the server proceed to execute lower-priority test cases, such as those verifying user registration or password reset functionality. By prioritizing and executing regression test cases, the server can more effectively verify the correctness of the targeted code changes, ensuring that critical features and fixes are fully tested, thereby improving the overall quality and stability of the software.

[0076] In order to more clearly describe the solution provided by the embodiments of the present application, a relatively complete implementation method is provided below.

[0077] 1. Defect location:

[0078] Integrating software acquisition into the testing process provides both forward and reverse tracing. Defect location utilizes forward tracing, where the software collects the code logic and test data executed during the test process. Through probe capture, developers can visualize the execution details of the test case, including interface input parameters, logic processing, and output parameters. Code with execution errors is captured and displayed, and test data directly informs development and debugging, enabling rapid defect location and repair.

[0079] 2 Intelligent analysis and processing:

[0080] (1) Code static analysis

[0081] For bytecode scanning, there are currently many bytecode manipulation tasks that can be implemented by ASM, Javassist, and BCEL. Among them, ASM has better overall performance; Javassist provides a richer API, which is easier to read and use.

[0082] Analyze all method call relationships: By analyzing the bytecode, we can obtain the call relationships between classes and methods. During the analysis process, we may need to exclude unnecessary classes or methods to reduce interference or improve analysis efficiency.

[0083] Analyze the call chain of the changed method: By analyzing the differences in bytecode instructions between different versions, further analyze the changed method and recursively search the top-level call relationship from the changed method upwards;

[0084] Bridging interfaces and implementation classes: In a call relationship chain, if a method of an interface implementation class is called, it is also necessary to find the implemented interface class through the interface implementation class for bridging, otherwise the call relationship chain will be interrupted here;

[0085] Bridging inner classes: Find the upper-level calling method or class of the anonymous inner class method according to the EnclosingMethod field in the bytecode file;

[0086] Optimize analysis results: The analysis results may contain call relationships that are not necessary for business purposes, such as logs, boilerplate code generated by third-party tool libraries, and interceptors. These can be matched and excluded based on their package names, class names, and method names.

[0087] (2) Dynamic analysis and static combination

[0088] Static analysis cannot effectively resolve the related calls implemented by technologies such as AOP, reflection, and polymorphism used in the code. However, by using Javaagent for dynamic analysis, bytecode embedding of class files during project runtime, and then performing a series of functional tests or automated tests, the complete call chain of each call can be obtained. The actual business logic methods called by technologies such as AOP, reflection, and polymorphism will also be reflected in the call chain, effectively making up for the weaknesses of static analysis.

[0089] (3) Upstream and downstream dependency analysis

[0090] Using various tracking tools, we gather a topology of the company's business chain, identifying upstream and downstream services and the impact of the interface changes. It's important to note that inter-application call chain data is reported in batches by each application. Each request reported at each node includes information about the top-level caller interface, the upper-level caller interface, and the current interface. After aggregation and deduplication, this information reflects the details of the entire inter-application call.

[0091] 3. Test adequacy metrics:

[0092] Coverage metrics are derived from test case scenarios. Statistics can be generated based on the following process:

[0093] During the collection phase, code coverage information is collected from the application under test using probe instrumentation. The collection logic is instrumented based on code blocks. The collected information is sent back to the server via MQ.

[0094] In the pre-aggregation phase, the server will perform preliminary aggregation on the original code coverage information received from MQ to improve efficiency when generating reports later;

[0095] During the report generation phase, after receiving the statistical request, the server will first determine the statistical range based on the denominator, and then re-aggregate the coverage pre-aggregation results to generate the final coverage information.

[0096] Coverage is an effective means of measuring test adequacy. It can effectively assist in discovering missed codes during daily testing, supplement test scenarios, and prevent missed tests.

[0097] 4.Return recommended cases:

[0098] As application iterations increase, regression test cases gradually increase. After code changes, the selection pipeline for regression test cases must ensure optimal coverage using the minimum number of test cases. In many cases, the number of test cases represents workload but cannot be used as a measure of code quality. Precision testing's ability to recommend regression tests can help focus on the most valuable test cases.

[0099] The overall ideas and steps of regression recommendation:

[0100] Innovative test case library;

[0101] Train a single test and code functional relationship model;

[0102] Provide diff capabilities between changed code and production code;

[0103] Combine call chain analysis and use case function relationship model to make intelligent recommendations for use cases corresponding to code changes;

[0104] After executing the use case, the uncovered incremental code is obtained based on the call chain analysis, and the test is notified to complete the regression use case.

[0105] The effects it brings are as follows: adapting to fast version iteration cycles and large engineering projects;

[0106] During regression testing, test cases are automatically screened, greatly reducing the time and risk of regression testing; reducing the testing blind spots caused by traditional manual regression analysis; and accurately calculating the weights of regression cases, so that testers can focus on regressing the cases most affected by the changes when time is limited.

[0107] Trends in precision testing scenarios include: precise problem location; precise change analysis; precise test coverage; precise process regression; precise traffic playback; and precise fault injection. As more companies mature in the quality assurance field, new approaches to precision testing are being explored. Through continuous experimentation and exploration, more and more application scenarios are emerging.

[0108] Please refer to Figure 2 , Figure 2 A software testing device 110 provided in an embodiment of the present invention includes:

[0109] Testing module 1101 is used to test the software to be tested using basic test cases, locate and display error codes; perform static and dynamic analysis on the error codes to obtain corresponding call chains and dependencies; generate code coverage information based on the error codes, the call chains and the dependencies; optimize the test case library based on the code coverage information, the call chains and the dependencies, and recommend and execute regression test cases for the software to be tested from the optimized test case library.

[0110] It should be noted that the implementation principles of the aforementioned software testing device 110 can be referenced from the implementation principles of the aforementioned software testing method and will not be elaborated upon here. It should be understood that the division of the various modules of the aforementioned device is merely a division of logical functions. In actual implementation, they may be fully or partially integrated into a single physical entity or physically separated. Furthermore, these modules may be implemented entirely in the form of software invoked by a processing element; or entirely in the form of hardware; or, alternatively, some modules may be implemented in the form of software invoked by a processing element, while others may be implemented in the form of hardware. For example, the software testing device 110 may be a separate processing element, or may be integrated into a chip of the aforementioned device. Furthermore, it may be stored in the form of program code in the memory of the aforementioned device, invoked by a processing element of the aforementioned device, and execute the functions of the aforementioned software testing device 110. The implementation of the other modules is similar. Furthermore, these modules may be fully or partially integrated together, or implemented independently. The processing element described herein may be an integrated circuit with signal processing capabilities. During implementation, the steps of the aforementioned method or the modules above may be performed by hardware integrated logic circuits in the processor element or by software instructions.

[0111] For example, the above modules may be one or more integrated circuits configured to implement the above methods, such as one or more application specific integrated circuits (ASICs), one or more digital signal processors (DSPs), or one or more field programmable gate arrays (FPGAs). For another example, when a module is implemented by scheduling program code on a processing element, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call program code. For another example, these modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0112] The embodiment of the present invention provides a computer device 100, which includes a processor and a non-volatile memory storing computer instructions. When the computer instructions are executed by the processor, the computer device 100 executes the aforementioned software testing device 110. Figure 3 As shown, Figure 3 This is a structural block diagram of a computer device 100 provided in an embodiment of the present invention. The computer device 100 includes a software testing device 110 , a memory 111 , a processor 112 , and a communication unit 113 .

[0113] To achieve data transmission or interaction, the memory 111, processor 112, and communication unit 113 are electrically connected to each other directly or indirectly. For example, these components can be electrically connected to each other through one or more communication buses or signal lines. The software testing device 110 includes at least one software function module that can be stored in the memory 111 in the form of software or firmware or solidified in the operating system (OS) of the computer device 100. The processor 112 is used to execute the software testing device 110 stored in the memory 111, such as the software function modules and computer programs included in the software testing device 110.

[0114] An embodiment of the present invention provides a readable storage medium, which includes a computer program. When the computer program is executed, the computer device where the readable storage medium is located is controlled to execute the aforementioned software testing method.

[0115] For illustrative purposes, the foregoing description has been made with reference to specific embodiments. However, the above illustrative discussion is not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed. Numerous modifications and variations are possible in light of the above teachings. These embodiments have been selected and described in order to best illustrate the principles of the present disclosure and its practical application, thereby enabling those skilled in the art to best utilize the present disclosure and to utilize various embodiments with various modifications as appropriate for the specific application contemplated.

Claims

1. A software testing method, characterized in that: include: Use basic test cases to test the software to be tested, locate and display error codes; Perform static and dynamic analysis on the error code to obtain the corresponding call chain and dependency relationship; Generate code coverage information according to the error code, the call chain and the dependency relationship; Optimizing a test case library according to the code coverage information, the call chain, and the dependency relationship, and recommending and executing regression test cases for the software to be tested from the optimized test case library; The use of basic test cases to test the software to be tested, locate and display error codes, includes: Use basic test cases to test the software to be tested and collect data to achieve forward and reverse tracing; Locating and displaying the error code based on the code execution information collected by the data; Generating code coverage information according to the error code, the call chain, and the dependency relationship includes: According to the code execution information, the call chain and the dependency relationship, collecting and acquiring original code coverage information from the software to be tested by probe instrumentation; Performing preliminary aggregation on the original code coverage information to obtain a preliminary aggregation result; Determine the statistical scope according to the preset statistical request; Re-aggregating the preliminary aggregation results based on the statistical range to generate the final code coverage information; Optimizing a test case library according to the code coverage information, the call chain, and the dependency relationship, and recommending and executing regression test cases for the software to be tested from the optimized test case library, includes: Optimizing a test case library according to the code coverage information, the call chain, and the dependency relationship; Obtaining a pre-trained test case and code function relationship model, wherein the test case and code function relationship model is used to determine a mapping relationship between a single test case and code; Obtain the difference between the change code and the production code and determine the target change code; Combining the test case and the code function relationship model and the call chain analysis result of the software to be tested, recommending and executing regression test cases for the target changed code; The uncovered incremental code is obtained according to the call chain analysis, and the test is notified to complete the regression case.

2. The method according to claim 1, characterized in that The static and dynamic analysis of the error code to obtain the corresponding call chain and dependency relationship includes: Perform static analysis of method call relationships, call chains of modified methods, bridge interfaces and implementation classes, and optimization analysis results based on the code execution information and the defect location results of the error code; Dynamic analysis through Javaagent; Collect relevant business link topology diagrams, obtain the upstream and downstream services of the changed interface and the impact on the interface, and perform upstream and downstream dependency analysis; The call chain and the dependency relationship are obtained according to the static analysis, the dynamic analysis and the upstream and downstream dependency analysis.

3. The method according to claim 1, characterized in that The test case library also includes historical test cases for historical defects, and the historical test cases are used to enhance code areas with historical problems in regression testing.

4. The method according to claim 1, wherein The recommending and executing regression test cases for the target changed code for the software to be tested includes: Prioritized regression test cases are recommended and executed for the target changed code.

5. A software testing device, characterized in that: include: The test module is used to test the software under test using basic test cases, locate and display error codes; Perform static and dynamic analysis on the error code to obtain the corresponding call chain and dependency relationship; Generate code coverage information based on the error code, the call chain, and the dependency relationship; optimize a test case library based on the code coverage information, the call chain, and the dependency relationship, and recommend and execute regression test cases for the software to be tested from the optimized test case library; The test module is specifically used to: Use basic test cases to test the software to be tested and collect data to achieve forward and reverse tracing; locate and display the error code based on the code execution information collected from the data; According to the code execution information, the call chain and the dependency relationship, collecting and acquiring original code coverage information from the software to be tested by probe instrumentation; Performing preliminary aggregation on the original code coverage information to obtain a preliminary aggregation result; determining a statistical range according to a preset statistical request; and re-aggregating the preliminary aggregation result based on the statistical range to generate the final code coverage information; Optimizing a test case library based on the code coverage information, the call chain, and the dependency relationship; obtaining a pre-trained test case and code function relationship model, wherein the test case and code function relationship model is used to determine a mapping relationship between a single test case and code; Obtain the difference between the change code and the production code and determine the target change code; Combining the test case and the code function relationship model and the call chain analysis result of the software to be tested, recommending and executing regression test cases for the target changed code; The uncovered incremental code is obtained according to the call chain analysis, and the test is notified to complete the regression case.

6. A computer device, characterized in that: The computer device includes a processor and a non-volatile memory storing computer instructions. When the computer instructions are executed by the processor, the computer device executes the method according to any one of claims 1 to 4.

7. A readable storage medium, characterized in that: The readable storage medium includes a computer program, and when the computer program is executed, the computer device where the readable storage medium is located is controlled to execute the method according to any one of claims 1 to 4.

Citation Information

Patent Citations

  • Code testing method and device

    CN117891732A