Software testing method and device, computer equipment and storage medium

Abstract

The invention relates to a software testing method and device, computer equipment and a storage medium. The method comprises the steps that a calling link of codes corresponding to software to be tested is obtained, the codes comprise incremental codes and stock codes, the influence range of the incremental codes on the stock codes is determined according to the calling link, a target test task is determined according to the influence range, and the software to be tested is tested according to the target test task. The key indexes comprise an increment index and a stock index, the increment index is used for representing the coverage condition of the increment code, the stock index is used for representing the regression condition of the stock code, and a test result is obtained according to the index value of the key test index. By adopting the method, the test of the code increment part and the test of the code stock part can be combined to form closed-loop management, and the risk of missing test is reduced.

Description

Technical Field

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

[0002] As software system architectures become more complex and business logic becomes more refined, projects are placing higher demands on the verification and delivery of interfaces, code, links, and business scenarios. This requires not only ensuring correct code logic and syntax, and stable interface functionality, but also ensuring smooth system call links and complete implementation of business scenarios. Traditional verification methods are no longer able to meet the high-quality delivery demands of modern projects.

[0003] Traditional software testing methods mostly rely on extensive manual labor, relying on the experience and capabilities of testers. However, this reliance on testers' experience and technical skills increases labor costs and risks. Furthermore, due to differences in tester capabilities and experience, the quality of test delivery is inconsistent, making it prone to missed tests or inadequate testing. Furthermore, traditional techniques often separate incremental testing from regression testing of existing software, making missed tests more likely. Summary of the Invention

[0004] Based on this, it is necessary to provide a software testing method, device, computer equipment and storage medium that can combine the testing of the incremental part of the code with the testing of the existing part of the code to form a closed-loop management and reduce the risk of missed tests in response to the above technical problems.

[0005] In a first aspect, a software testing method is provided, comprising:

[0006] Obtain the call link of the code corresponding to the software to be tested, including incremental code and existing code;

[0007] Determine the impact of incremental code on existing code based on the call chain;

[0008] Determine target testing tasks based on the scope of impact;

[0009] Test the software to be tested according to the target test task and determine the index values ​​of key test indicators. Key indicators include incremental indicators and stock indicators. Incremental indicators are used to represent the coverage of incremental code, and stock indicators are used to represent the regression of stock code.

[0010] The test results are obtained according to the indicator values ​​of the key test indicators.

[0011] In one embodiment, the impact scope includes affected modules in the existing code, and the target test task is determined based on the impact scope, including:

[0012] Determine additional testing tasks based on the affected modules in the stock code;

[0013] Determine target test tasks based on supplementary test tasks and pre-configured benchmark test tasks.

[0014] In one embodiment, the incremental indicator includes any one or more of the following:

[0015] Incremental code line coverage, incremental interface coverage, incremental query statement coverage, test task pass rate, and call link coverage;

[0016] Stock indicators include any one or more of the following:

[0017] Active interface coverage, key test task pass rate, and key business scenario coverage.

[0018] In one embodiment, the software testing method further includes:

[0019] Determine the number of active interfaces called in the incremental code based on the call chain;

[0020] Determine the weight of incremental code line coverage and incremental interface coverage based on the number of interfaces;

[0021] The process of obtaining the test results based on the indicator value of the incremental code line coverage and the indicator value of the incremental interface coverage includes:

[0022] According to the weight of the incremental code line coverage and the weight of the incremental interface coverage, a weighted sum is performed on the incremental code line coverage and the incremental interface coverage to obtain the test result.

[0023] In one embodiment, the software testing method further includes:

[0024] Perform quality inspection on the software to be tested to obtain the unit test coverage and static scanning results of the software to be tested;

[0025] When the unit test coverage is lower than a first preset value or the number of code problems in the static scan result is greater than a second preset value, a prompt message for repairing the code is generated.

[0026] In one embodiment, obtaining a call link of a code corresponding to the software to be tested includes:

[0027] Extract the calling relationships between classes, functions, and methods in the code corresponding to the software to be tested;

[0028] Determine the call link based on the call relationship.

[0029] In one embodiment, the software testing method further includes:

[0030] Detect slow SQL issues through the slow SQL detection plug-in;

[0031] Add detected slow SQL issues to the test report.

[0032] In a second aspect, a software testing device is provided, comprising:

[0033] The acquisition module is used to obtain the call link of the code corresponding to the software to be tested, including incremental code and stock code;

[0034] A first determination module is used to determine the impact range of the incremental code on the existing code based on the call link;

[0035] The second determination module is used to determine the target test task according to the impact range;

[0036] The test module is used to test the software to be tested according to the target test task and determine the index values ​​of key test indicators. Among them, the key indicators include incremental indicators and stock indicators. Incremental indicators are used to represent the coverage of incremental code, and stock indicators are used to represent the regression of stock code.

[0037] The processing module is used to obtain test results according to the indicator values ​​of key test indicators.

[0038] In a third aspect, the present application provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the software testing method provided in any embodiment of the present application in the first aspect are implemented.

[0039] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the software testing method provided in any embodiment of the first aspect of the present application.

[0040] The above-mentioned software testing method, device, computer equipment and storage medium can determine the scope of influence of incremental code on stock code by obtaining the code call link, and can accurately locate which stock code will be affected by the incremental code, improve the pertinence of the test, avoid indiscriminate testing of the entire software, and save testing time and resources. In addition, the test coverage of the incremental part is combined with the regression test of the stock part to ensure that the newly added or modified part of the software (incremental part) is fully tested, and it is also verified whether the stock code still works normally after the introduction of the incremental code, avoiding the situation where the impact on the stock code is ignored due to only focusing on the incremental part, thereby comprehensively improving the integrity of the test. It can be seen that the present application can combine the test coverage of the incremental part with the regression test of the stock part to form a closed-loop management and reduce the risk of missed tests. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 Schematic diagram of the flow of software testing methods in some embodiments;

[0042] Figure 2 Schematic diagram of the flow of software testing methods in other embodiments;

[0043] Figure 3 is a structural block diagram of a software testing device in some embodiments;

[0044] Figure 4 1 is a diagram of the internal structure of a computer device in some embodiments. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0046] In a first aspect, the present application provides a software testing method, such as Figure 1 As shown, the method is applied to a server as an example for description, and includes the following steps:

[0047] Step S11: Obtain the call link of the code corresponding to the software to be tested, where the code includes incremental code and stock code.

[0048] A code call chain refers to the complete path in a software system, starting from a starting function, method, or code block to other functions, methods, or code blocks that it directly or indirectly calls. It describes the calling relationships and execution order between code blocks. By analyzing the call chain, we can understand the execution flow of the code and the dependencies between its components. For example, in a program, if function A calls function B, and function B calls function C, then "A->B->C" constitutes a simple code call chain.

[0049] Incremental code refers to the code that is newly added, modified or deleted during a software update, modification or development iteration.

[0050] Stock code, as opposed to incremental code, refers to the code that existed in the software before the current update, modification, or development iteration. It is the original code base of the software system. In each iteration, all code except the incremental code is considered stock code.

[0051] Specifically, the present application can use code analysis tools, such as static code analysis tools or specialized code call link analysis tools, to scan and parse the code and identify the calling relationships between functions and methods. Specifically, the entire code of the software to be tested (including incremental code and stock code) can be imported into the corresponding tool to ensure that the tool can access and parse the code so that the tool can correctly analyze the code.

[0052] Furthermore, the code is scanned using the appropriate tools, which traverse the various functions and methods in the code and record the call relationships between them. During the scanning process, function call statements are identified based on the syntax and logical structure of the code and incorporated into the construction of the call chain.

[0053] Furthermore, based on pre-made markings or records, determine which code is incremental code and which is existing code. Based on the scanning and differentiation of the code, a complete code call chain is constructed based on the recorded call relationships. For the incremental code portion, focus on its call relationship with other code (including between incremental code and between incremental code and existing code); for the existing code, analyze the changes in its call chain after the introduction of the incremental code.

[0054] Step S12: Determine the impact of the incremental code on the existing code based on the call link.

[0055] The scope of impact refers to the portion of existing code in a software system that may be directly or indirectly affected by the introduction or modification of incremental code. This impact can include changes in code execution paths, data flow, function call relationships, and inter-module dependency adjustments, potentially impacting software functionality, performance, and stability.

[0056] Specifically, this application can determine the direct calling relationship between functions, methods, and other elements in the incremental code and the existing code based on the code call chain. For example, it can check whether new functions in the incremental code call functions in the existing code, or whether the calling parameters or calling frequency of functions in the existing code have been changed.

[0057] Furthermore, the incremental code is checked to see if it changes the source, flow, or processing of data in the existing code. It is also checked to see if the incremental code alters external resources, modules, or libraries that the existing code depends on. If the incremental code introduces new dependencies or updates existing dependencies, the parts of the existing code affected by these dependencies are considered affected.

[0058] Based on the above detection results, determine which modules, functions, or code blocks in the existing code may be affected by the changes in the incremental code. These affected parts can be classified and marked to determine the scope of the impact of the incremental code on the existing code.

[0059] Step S13: determine the target test task according to the impact range.

[0060] A target test task is a task used to test the software under test. A test task is a series of specific testing activities and their associated requirements, specifically designed to verify that a software system or its functionalities meet specific requirements and quality standards. It typically includes elements such as the test objective, scope, methods, steps, expected results, and schedule.

[0061] Specifically, this application can further subdivide the impact scope into specific, actionable units or modules. Test the affected units or modules to ensure their functionality remains normal despite the incremental code. Specific target testing tasks are determined based on the different test types and affected units.

[0062] Step S14: Test the software to be tested according to the target test task and determine the index values ​​of key test indicators, where the key indicators include incremental indicators and stock indicators. The incremental indicators are used to characterize the coverage of incremental codes, and the stock indicators are used to characterize the regression of stock codes.

[0063] Incremental metrics are a set of indicators used to measure and characterize the coverage and quality of incremental code in software during testing. They reflect the extent to which newly added, modified, or deleted code is executed and verified during testing. Common incremental metrics include code coverage of incremental code and the pass rate of test tasks for new features. These metrics can help assess the effectiveness and reliability of incremental code.

[0064] Stock metrics are primarily used to measure and characterize the regression of existing code after the introduction of incremental code. This means assessing whether the original code maintains its original functionality, performance, and stability after a software update or modification. Common stock metrics include the regression test pass rate of existing code and the number of new defects discovered in the existing code. These metrics reflect the quality status of the existing code under the influence of new changes.

[0065] Specifically, when testing the software to be tested according to the test task, this application first builds a test environment that meets the requirements to ensure the normal operation of the software; then the tester strictly performs the test task, inputs test data and operates the software, and records the actual test results in detail, compares them with the expected results, and determines whether the test task has passed. If an abnormality occurs, collect information and try to reproduce it; then carry out multiple rounds of testing as planned, and organize the test data after completion.

[0066] Furthermore, this application can collect, classify and organize various test data generated during the test process, including the execution results (pass or fail) of each test task, test logs, error messages, etc., to ensure the integrity and accuracy of the data.

[0067] From the organized test data, filter out the parts related to the incremental code. Based on the definition of the incremental indicator and the filtered incremental code test results, calculate the corresponding indicator value.

[0068] Similarly, find the parts of the test data that are related to the stock code, especially the results generated during regression testing. Based on the definition of the stock indicator and the stock code test results, calculate the corresponding indicator value.

[0069] Step S15: obtaining test results according to the indicator values ​​of the key test indicators.

[0070] Specifically, the test result can be a test report. This application can generate a test report based on the indicator values ​​of key test indicators. When generating a test report, first determine the report framework covering sections such as title and key indicator analysis, and collect basic information such as test time and environment. Furthermore, present the incremental and stock key indicator values ​​in the form of charts, tables, etc., and conduct in-depth analysis of their meaning and achievement. Furthermore, summarize the test results, record the problems found in the test and corresponding suggestions.

[0071] In addition, the software testing method of the present application can be applied to SaaS (Software as a Service) platforms. By using this application, the impact range of incremental code on stock code can be quickly located, target test tasks can be determined, test efficiency can be improved, and the time cost of SaaS platform software development and updates can be saved. In addition, SaaS platforms usually support multiple tenants. By analyzing the code call link and determining the impact range, the impact of software updates on different tenants can be more accurately evaluated to ensure stability and compatibility in a multi-tenant environment. Moreover, in SaaS platforms, resources are usually shared. Unnecessary testing can be avoided by accurately determining the test scope and evaluating key indicators.

[0072] In one embodiment, the impact scope includes affected modules in the stock code, and determining the target test task based on the impact scope includes: determining a supplementary test task based on the affected modules in the stock code, and determining the target test task based on the supplementary test task and a pre-configured benchmark test task.

[0073] Supplementary testing tasks are additional tests specifically designed for modules within the existing code base that are affected by the incremental code. Their purpose is to further verify the functional correctness, stability, and interaction with other modules of these affected modules after the incremental code is introduced, thereby addressing any deficiencies in conventional testing and ensuring the software quality of the affected components.

[0074] A benchmark task is a preconfigured set of basic testing tasks, typically covering core software functionality, common usage scenarios, and basic performance metrics. It serves as the foundation for comprehensive software testing and ensures basic quality under normal conditions.

[0075] The target test task is the final set of test tasks determined by combining supplementary and benchmark tests. It encompasses both benchmark testing to verify the overall foundational quality of the software and supplementary testing to deeply examine the impact of incremental code. It represents the complete and targeted testing content defined for this software testing activity.

[0076] Specifically, this application can determine the scope of the incremental code's impact on the existing code by analyzing the code call chain, and then identify the specific modules in the existing code that are affected. For example, it is found that the incremental code modifies the user permission-related logic, resulting in the user login module and data access control module in the existing code being affected.

[0077] Furthermore, for the identified affected modules, corresponding supplementary testing tasks are determined based on their functional characteristics, interaction with the incremental code, etc. For example, for the affected user login module, some supplementary testing tasks are determined, such as supplementary testing tasks for scenarios such as logins by users with different permissions and abnormal login attempts.

[0078] Furthermore, the benchmark test task is retrieved from the pre-configured test task library, and the supplementary test task is merged and optimized with the benchmark test task to remove duplicate parts and form the target test task.

[0079] The beneficial effect of this embodiment is that by supplementing the test tasks to specifically cover the affected modules of the existing code, combined with the benchmark test tasks to ensure the basic functions of the software, it can fully cover the testing requirements of the software after the code is changed, avoid missed tests due to focusing only on routine tests or only testing the affected parts, and improve the comprehensiveness of the overall test.

[0080] In one embodiment, the stock code includes multiple affected modules, and the software testing method may further include: determining the degree of influence of the incremental code on each module in the stock code based on the call link, and determining the execution priority of the test task corresponding to each module in the stock code based on the degree of influence. The process of testing the stock code based on the test task may include: executing the test task corresponding to each module in the stock code based on the execution priority to test the software to be tested.

[0081] Among them, this application can determine the calling relationship, data interaction, and other situations between the incremental code and each module in the stock code based on the code call chain. For example, if the incremental code frequently calls a module in the stock code, or causes significant changes to the data input and output of the module, then the impact of the module is higher; conversely, if it is only occasionally involved or the impact is small, then the impact is lower. Through quantitative means, the impact of each affected module is clearly defined.

[0082] Furthermore, rules are developed to prioritize test execution based on the impact of each module. Generally speaking, test tasks corresponding to modules with high impact receive higher priority, as these modules are more likely to experience issues, and any issues that occur will have a more severe impact on the overall functionality of the software. For example, modules with high impact are marked as high priority and tested first, while modules with low impact are marked as low priority and tested later as resources allow.

[0083] Furthermore, when testing existing code, the test tasks corresponding to each module are executed in sequence according to the determined execution priority. During the execution process, the execution status and results of each test task are recorded for subsequent analysis and processing.

[0084] This embodiment has the beneficial effect of focusing testing resources on modules with the greatest impact on software functionality by determining the impact of each module and prioritizing test tasks. This avoids wasting excessive time and effort on modules with lower impact. Prioritizing high-priority modules allows for faster discovery and resolution of potential serious issues, accelerating testing progress and improving overall testing efficiency.

[0085] In one embodiment, incremental indicators may include any one or more of the following: incremental code line coverage, incremental interface coverage, incremental query statement coverage, test task pass rate, and call link coverage; stock indicators may include any one or more of the following: active interface coverage, key test task pass rate, and key business scenario coverage.

[0086] Incremental code line coverage refers to the ratio of the number of incremental code lines executed by the tested task to the total number of incremental code lines during the software testing process. It measures the degree of test coverage of the newly added code and reflects the extent to which the test task traverses the incremental code logic.

[0087] Specifically, incremental code line coverage = number of executed incremental code lines / total number of incremental code lines×100%.

[0088] The incremental code is the number of lines of code that the code submitted this time has more than the master branch. In a version control system, the master branch is usually regarded as the main branch or default branch of the project, representing the main development line of the project.

[0089] Incremental interface coverage is the ratio of the number of incremental interfaces called during testing to the total number of incremental interfaces. This metric primarily examines the testing of newly added interfaces and reflects the extent to which the test task verifies the functionality of the incremental interfaces.

[0090] Specifically, incremental interface coverage = tested interfaces / total number of incremental interfaces×100%.

[0091] Among them, the tested interfaces refer to the tested interfaces among the newly added interfaces, and the incremental interfaces refer to the newly added interfaces.

[0092] Incremental query coverage refers to the percentage of incremental query statements executed during testing compared to the total number of incremental query statements. It is used to assess the test coverage of newly added query statements and reflects the degree to which the test task verifies the incremental query logic.

[0093] The query statement may be SQL (Structured Query Language), and the specific calculation formula may be: incremental SQL coverage = tested SQL / total number of incremental SQLs×100%.

[0094] Among them, tested SQL refers to the tested SQL in the newly added SQL, and incremental SQL refers to the newly added SQL.

[0095] The call link coverage is used to measure the test coverage of the call relationship between incremental codes, reflecting the degree to which the test task traverses the entire incremental code logic link.

[0096] Specifically, call link coverage = tested system call links / total number of links × 100%;

[0097] The "tested system call links" refers to the tested system call links involved in this incremental code. The "total links" refers to the total number of links involved in this incremental code.

[0098] The test task pass rate refers to the ratio of the number of tasks designed for incremental code that pass the test to the total number of test tasks. It directly reflects the performance of the incremental code in each test task and shows whether the incremental code meets the expected functional and quality requirements.

[0099] Specifically, the test plan pass rate = the number of test tasks that passed execution / the total number of test tasks executed × 100%.

[0100] In addition, the incremental indicators may also include incremental scenario coverage. Specifically, incremental scenario coverage = number of tested business scenarios / number of business scenarios defined in the requirements × 100%.

[0101] Furthermore, the stock indicators of this application may include the following indicators:

[0102] Active interface coverage refers to the ratio of the number of active existing interfaces called during testing to the total number of active existing interfaces. This metric primarily examines test coverage of existing interfaces and reflects the degree to which the test tasks verify the functionality of existing interfaces. Active interfaces are those that are actually called and active during software system operation, making a real contribution to the implementation of system functions.

[0103] Specifically, the active interface pass rate = the number of executed and passed operations / the total number of active interfaces × 100%.

[0104] The number of executed and successful executions may refer to the number of executed and successful executions among active interfaces with online visits within a preset number of months (e.g., 3). The total number of active interfaces refers to the total number of active interfaces within a preset number of months.

[0105] The key test task pass rate refers to the ratio of key test tasks that passed to the total number of key test tasks for existing code. Key test tasks are typically related to core software functions, important business processes, or high-risk areas. This metric reflects the stability and correctness of the existing code in terms of key functions and business operations.

[0106] Specifically, key test tasks = number of executed key tasks / total number of key test tasks × 100%.

[0107] The number of executed key tasks refers to the number of executed key tasks in the business segments affected by this code. The total number of key test tasks refers to the total number of key test tasks in the business segments affected by this code.

[0108] Key business scenario coverage is the ratio of the number of key business scenarios covered during testing to the total number of key business scenarios. Key business scenarios refer to the important business processes and operational scenarios involved in actual software use. This metric measures the extent to which tests cover the key business scenarios supported by existing code, reflecting the software's reliability in real-world business applications.

[0109] Specifically, key business scenario coverage = number of key business scenarios tested / total number of key business scenarios × 100%

[0110] The number of tested key business scenarios refers to the number of tested key business scenarios in the business segments affected by this code. The total number of key business scenarios refers to the total number of key business scenarios in the business segments affected by this code.

[0111] The beneficial effect of this embodiment is that the indicator values ​​of key indicators including incremental indicators and stock indicators are determined based on the test results, which can evaluate both the coverage of incremental code and the regression of stock code, comprehensively evaluate the status of the software, and help to promptly discover problems in the software.

[0112] In one embodiment, the software testing method may also include: determining the number of active interfaces called in the incremental code based on the call link, determining the weight of the incremental code line coverage and the weight of the incremental interface coverage based on the number of interfaces, and obtaining the test results based on the index value of the incremental code line coverage and the index value of the incremental interface coverage, including: performing weighted summation of the incremental code line coverage and the incremental interface coverage based on the weight of the incremental code line coverage and the weight of the incremental interface coverage to obtain the test results.

[0113] Specifically, this application analyzes the code call chain and traverses all interface call statements involved in the incremental code. Combined with the actual software operation or test scenario, it determines whether each called interface is in an active state. The number of all active interfaces is counted to obtain the number of active interfaces called in the incremental code.

[0114] Furthermore, based on the determined number of active interfaces, the weight of the incremental code line coverage and the weight of the incremental interface coverage are determined separately according to pre-set rules or algorithms. Generally speaking, when there are more active interfaces, it means that the interfaces play a more important role in the incremental code. In this case, the weight of the incremental interface coverage may be relatively high; conversely, the weight of the incremental code line coverage may be relatively high. For example, when the number of active interfaces exceeds a certain threshold, the weight of the incremental interface coverage is set to 0.6, and the weight of the incremental code line coverage is set to 0.4.

[0115] Furthermore, the specific values ​​of the calculated incremental code line coverage and incremental interface coverage are obtained. Based on the determined weights, these two coverage metrics are weighted and summed. The specific calculation method can be: weighted result = incremental code line coverage × incremental code line coverage weight + incremental interface coverage × incremental interface coverage weight. The result of this weighted sum is then added to the test results.

[0116] The beneficial effect of this embodiment is that by comprehensively considering the incremental code line coverage and incremental interface coverage, and dynamically adjusting the weights according to the number of active interfaces for weighted summation, the test coverage of the incremental code can be more comprehensively reflected. It avoids the one-sidedness of the evaluation caused by focusing only on a single coverage indicator, and makes the evaluation results more accurately reflect the quality status of the software in the incremental code part. By adding the results of the weighted summation to the test report, developers, testers and other relevant personnel can more intuitively understand the test coverage and quality level of the incremental code based on this comprehensive indicator, so that subsequent development, testing and optimization work can be more targeted.

[0117] In one embodiment, the software testing method may further include: performing quality inspection on the software to be tested to obtain the unit test coverage and static scanning results of the software to be tested, and when the unit test coverage is lower than a first preset value or the number of code problems in the static scanning results is greater than a second preset value, generating a prompt message for repairing the code.

[0118] Among them, quality inspection refers to the use of specific tools and methods to comprehensively inspect and evaluate software products during the testing phase to determine whether they meet the specified quality standards and requirements.

[0119] Unit test coverage refers to the proportion of the executed parts of the tested code (such as code lines, functions, branches, etc.) in the total code during the unit testing process.

[0120] Static scanning is a technique that analyzes a program's source code, bytecode, or other related files to detect potential issues (such as syntax errors, security vulnerabilities, coding standards violations, and potential logic errors) without actually running the program. Static scanning tools can identify these issues early in the software development process so they can be fixed promptly. Static scanning results can include the number of issues detected.

[0121] Specifically, in this application, when the software to be tested enters the testing phase, a unit test plug-in is used to perform unit testing on the software to be tested. During the test process, the plug-in records the execution status of each unit test task and counts the executed code parts. After the test is completed, the plug-in calculates the unit test coverage based on the recorded data. For example, when calculating statement coverage, the ratio of the number of executed code lines to the total number of code lines is counted.

[0122] Furthermore, a static scanning plug-in is used to scan the software source code or related files. The plug-in will analyze the code structure, syntax, and semantics based on preset rules and algorithms, find various problems in the code, and count the number of problems scanned.

[0123] Furthermore, the calculated unit test coverage is compared with a first preset value, and the number of code issues in the static scan results is compared with a second preset value. If the unit test coverage is lower than the first preset value, it means that the unit test is not comprehensive enough and there may be code modules that have not been tested; or when the number of code issues in the static scan results is greater than the second preset value, it indicates that there are many potential problems in the code. If either of these two situations does not meet the standards, a prompt message indicating that the quality inspection has failed is generated, and a prompt message for repairing the code is generated, notifying the developer to check and repair the code so that it can be resubmitted after repair, and triggering the next quality inspection.

[0124] The beneficial effect of this embodiment is that quality testing during the testing phase can promptly identify insufficient unit test coverage and potential problems in the code before the software enters higher-level testing or is officially released. This prevents problems from being amplified in subsequent stages, reducing the cost and risk of repairs.

[0125] In one embodiment, obtaining the call link of the code corresponding to the software to be tested may include: extracting the call relationship between classes, functions, and methods in the code corresponding to the software to be tested, and determining the call link according to the call relationship.

[0126] Specifically, the present application can use static code analysis tools to parse scripts to extract call relationships in the code. For example, the code can be parsed into an abstract syntax tree, where the nodes in the tree represent various elements in the code (such as class definitions, function definitions, method calls, etc.).

[0127] The parsed code structure is then traversed to find the definitions of classes, functions, and methods, as well as the calling statements between them. When traversing the abstract syntax tree, nodes representing function and method calls are identified, and the relationship between the caller and the callee is recorded.

[0128] Furthermore, the call relationships found during the traversal process are recorded in a data structure. Based on the data structure of the call relationships, the complete call chain is determined through an algorithm.

[0129] The beneficial effect of this embodiment is that by determining the call chain, the execution order and call relationships of various classes, functions, and methods in the code can be intuitively viewed. During the testing process, the call chain can guide the design and execution of test tasks. It also helps analyze test results. When a problem occurs during the test, the call chain can be used to quickly locate the code section that may have the problem.

[0130] In one embodiment, the software testing method may further include: detecting slow SQL issues using a slow SQL detection plug-in, and adding the detected slow SQL issues to a test report.

[0131] Slow SQL refers to SQL statements that execute slowly and take a long time to complete during database operations. These statements are often caused by poorly written SQL statements (such as missing indexes, complex join queries, and large amounts of data scans), improper database configuration, or other performance-related factors, resulting in inefficient execution and impacting overall system performance and responsiveness. The specific "slow" criteria can be set based on actual business needs and system performance requirements. For example, a SQL statement that takes more than one second to execute is considered slow SQL.

[0132] A slow SQL detection plugin is a tool or software component specifically designed to detect slow SQL statements in a database. It's typically integrated with the database system to monitor the execution of SQL statements, collect relevant performance data such as execution time, and then determine which SQL statements are slow based on pre-set rules and thresholds. This plugin can help developers and database administrators quickly locate and analyze performance bottlenecks for optimization.

[0133] Specifically, this application can install a slow SQL detection plug-in. After the plug-in is started, it begins to monitor the execution of SQL statements in the database. It records the execution time, execution plan, tables and fields involved, and other information of each SQL statement. The plug-in determines which SQL statements are slow SQL based on the preset threshold and the collected SQL statement execution time data. When it is found that the execution time of a certain SQL statement exceeds the set threshold, it is marked as a slow SQL problem, and further detailed information of the statement is collected, such as the specific SQL text, execution times, etc.

[0134] Furthermore, the detected slow SQL problems and their detailed information are stored in a data structure or log file for subsequent processing and analysis. The recorded information may include the SQL statement text, execution time, and the fields involved.

[0135] Furthermore, when generating a test report, relevant information is extracted from the data structure or log file that records the slow SQL problem, organized into a suitable format, and added to the corresponding section of the test report. The report can briefly describe the slow SQL problem and provide possible optimization suggestions.

[0136] The beneficial effect of this embodiment is that it can quickly and accurately detect slow SQL problems in the database, helping developers and database administrators locate the root causes of system performance bottlenecks. By solving these slow SQL problems, the overall performance and response speed of the system can be significantly improved.

[0137] In order to further illustrate the software testing method of this application, it is provided Figure 2 ,like Figure 2 As shown, the software testing method of the present application may include:

[0138] During the R&D testing phase and each code deployment: This application automatically analyzes code changes, identifies affected modules and functions, and checks whether unit test coverage and static scan results meet preset standards, such as whether coverage is greater than 80% and whether the number of issues in the static scan results is less than 1. If any metric does not meet the corresponding requirements, R&D will be prompted to fix and resubmit.

[0139] Testing phase: Execute tests according to the target test tasks.

[0140] Test network exit phase: Automatically collect test data from the test process, such as the execution of SQL statements, the execution of test tasks, incremental code coverage, and the test status of key business scenarios. Calculate the index values ​​of the corresponding key test indicators and compare the relationship between the index value of each indicator and the corresponding expected value. If any indicator does not meet the corresponding expected value, a prompt message is generated to prompt the tester to perform additional testing. When all indicators meet the standards, the operation can be exited. For example, if the target value of the incremental interface coverage is 100% and the actual value is 90%, a corresponding prompt message will be generated. The content of the prompt message may include: the incremental interface coverage is 90%, which does not meet the standard, and it will carry detailed information, including the 10% of interface content that is not covered.

[0141] Test report output stage: Generate a test report based on the indicator values ​​of key test indicators. The test report displays the indicator values ​​of each key indicator, whether the indicators are met, and other detailed information.

[0142] In a second aspect, the present application provides a software testing device, such as Figure 3 As shown, the software testing device includes: an acquisition module 31, a first determination module 32, a second determination module 33, a testing module 34 and a processing module 35, wherein:

[0143] The acquisition module 31 is used to obtain the call link of the code corresponding to the software to be tested, and the code includes incremental code and stock code;

[0144] A first determining module 32 is configured to determine the impact of the incremental code on the existing code based on the call link;

[0145] A second determination module 33 is used to determine the target test task according to the impact range;

[0146] The testing module 34 is used to test the software to be tested according to the target test task and determine the index values ​​of key test indicators, where the key indicators include incremental indicators and stock indicators. The incremental indicators are used to represent the coverage of incremental code, and the stock indicators are used to represent the regression of stock code.

[0147] The processing module 35 is used to obtain the test results according to the indicator values ​​of the key test indicators.

[0148] In one embodiment, the impact range includes affected modules in the stock code, and the second determination module 33 can determine the supplementary test tasks based on the affected modules in the stock code, and determine the target test tasks based on the supplementary test tasks and the pre-configured benchmark test tasks.

[0149] In one embodiment, the incremental indicators include any one or more of the following: incremental code line coverage, incremental interface coverage, incremental query statement coverage, test task pass rate, and call link coverage; the stock indicators include any one or more of the following: active interface coverage, key test task pass rate, and key business scenario coverage.

[0150] In one embodiment, the first determination module 32 can also determine the number of active interfaces called in the incremental code based on the call link, determine the weight of the incremental code line coverage and the weight of the incremental interface coverage based on the number of interfaces, and perform weighted summation of the incremental code line coverage and the incremental interface coverage based on the weight of the incremental code line coverage and the weight of the incremental interface coverage, and add the result of the weighted summation to the test report.

[0151] In one embodiment, the first determination module 32 can also perform quality inspection on the software to be tested to obtain the unit test coverage and static scanning results of the software to be tested. When the unit test coverage is lower than a first preset value or the number of code problems in the static scanning results is greater than a second preset value, a prompt message for repairing the code is generated.

[0152] In one embodiment, the acquisition module 31 may extract the calling relationships among classes, functions, and methods in the code corresponding to the software to be tested, and determine the calling links according to the calling relationships.

[0153] In one embodiment, the processing module 35 may further detect slow SQL issues through a slow SQL detection plug-in, and add the detected slow SQL issues to the test report.

[0154] In a third aspect, the present application provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the software testing method provided in any embodiment of the present application in the first aspect are implemented.

[0155] In one embodiment, the computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, a network interface, and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, it implements the software testing method.

[0156] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the software testing method provided in any embodiment of the first aspect of the present application.

[0157] The computer readable storage medium may be Figure 4 A computer-readable storage medium in the computer device shown.

[0158] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the above-mentioned computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0159] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0160] The above embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A software testing method, characterized in that: The method comprises: Obtaining a call link of the code corresponding to the software to be tested, wherein the code includes incremental code and stock code; Determining the impact scope of the incremental code on the stock code according to the call link; Determine target test tasks based on the impact scope; Testing the software to be tested according to the target test task and determining the index values ​​of key test indicators, wherein the key indicators include incremental indicators and stock indicators, the incremental indicators are used to characterize the coverage of the incremental code, and the stock indicators are used to characterize the regression of the stock code; A test result is obtained according to the indicator value of the key test indicator.

2. The method according to claim 1, characterized in that The impact scope includes affected modules in the stock code, and determining a target test task according to the impact scope includes: Determining supplementary testing tasks based on the affected modules in the stock code; The target test task is determined according to the supplementary test task and a pre-configured benchmark test task.

3. The method according to claim 1, characterized in that The incremental indicators include any one or more of the following: Incremental code line coverage, incremental interface coverage, incremental query statement coverage, test task pass rate, and call link coverage; The stock indicators include any one or more of the following: Active interface coverage, key test task pass rate, and key business scenario coverage.

4. The method according to claim 3, characterized in that The method further comprises: Determine the number of active interfaces called in the incremental code according to the call link; Determining a weight of the incremental code line coverage and a weight of the incremental interface coverage according to the number of interfaces; The process of obtaining the test result according to the indicator value of the incremental code line coverage and the indicator value of the incremental interface coverage includes: According to the weight of the incremental code line coverage and the weight of the incremental interface coverage, a weighted sum is performed on the incremental code line coverage and the incremental interface coverage to obtain the test result.

5. The method according to claim 1, characterized in that The method further comprises: Performing quality inspection on the software to be tested to obtain unit test coverage and static scanning results of the software to be tested; When the unit test coverage is lower than a first preset value or the number of code problems in the static scan result is greater than a second preset value, a prompt message for repairing the code is generated.

6. The method according to claim 1, characterized in that The step of obtaining the code call link corresponding to the software to be tested includes: Extracting the calling relationships among classes, functions, and methods in the code corresponding to the software to be tested; The call link is determined according to the call relationship.

7. The method according to claim 1, characterized in that The method further comprises: Detect slow SQL issues through the slow SQL detection plug-in; Add detected slow SQL issues to the test report.

8. A software testing device, characterized in that: The device comprises: An acquisition module is used to obtain the call link of the code corresponding to the software to be tested, wherein the code includes incremental code and stock code; A first determining module is configured to determine, based on the call link, a scope of influence of the incremental code on the stock code; A second determination module is used to determine a target test task according to the impact range; a testing module, configured to test the software to be tested according to the target test task and determine the index values ​​of key test indicators, wherein the key indicators include incremental indicators and stock indicators, the incremental indicators are used to characterize the coverage of the incremental code, and the stock indicators are used to characterize the regression of the stock code; The processing module is used to obtain the test result according to the indicator value of the key test indicator.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images