Software testing method, device, equipment, medium and product

Abstract

The invention provides a software testing method and device, equipment, a medium and a product, relates to the field of software engineering, and can improve the software testing quality. According to the specific scheme, code execution information of to-be-tested software is obtained; and processing the code execution information according to the test index of the to-be-tested service to obtain structured information of the target code segment. And based on test parameters and scene parameters associated with the to-be-tested business in the intelligent agent, analyzing the structural information of each target code segment to obtain test reference cases and called frequencies of the target code segments. And according to the test reference case, testing the target code segment in the target calling scene to obtain a test result of the to-be-tested software. According to the method, on one hand, the test parameters and the scene parameters of the intelligent agent are strongly associated with the to-be-tested service, so that the accuracy of the test result is improved; and on the other hand, under the double constraints of the scene frequency and the test dimension, the global code does not need to be tested, and the test efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of software engineering, and more particularly to a software testing method, apparatus, device, medium, and product. Background Technology Before a software project is officially launched, it is often necessary to test the software. Software testing is an indispensable part of the software development process and is used to confirm whether the functions or performance of the software meet the requirements specified in the development requirements document.

[0002] In traditional techniques, the compilation data is read, and the software's runtime logs and compilation data are compared on preset dimensions to generate a full comparison report. The software is then tested globally based on the comparison report. However, this testing approach still suffers from low test quality and efficiency. Summary of the Invention

[0003] This application provides a software testing method, apparatus, device, medium, and product, which are used to / can solve the above-mentioned problems.

[0004] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: Firstly, a software testing method is provided, which includes: During the operation of the software under test (SDT), code execution information for multiple target code segments is acquired. Obtaining this information during software runtime provides a basis for dynamic testing, improving overall testing efficiency. Based on the test metrics of the business logic being tested, the code execution information is analyzed to obtain the code coverage and execution rate for each target code segment. This detailed coverage and execution rate provides an accurate data source for subsequent agent analysis, improving testing accuracy. For each target code segment, the code coverage and execution rate are processed to obtain structured information containing these metrics. This structured information is easy to save and retrieve, improving the efficiency of retesting and the accuracy of code saving during testing. Based on the test parameters associated with the business under test in the code analysis agent, test case analysis is performed on the structured information of each target code segment to obtain test reference cases for the software under test under the target test dimension. Based on the scenario parameters associated with the business under test in the code analysis agent, call frequency analysis is performed on the structured information of each target code segment to obtain the call frequency of each target code segment under each code call scenario. Based on the test parameters and scenario parameters in the code analysis agent, the structured information is processed to obtain test reference cases for the software under test under the target test dimension, and the call frequency of each target code segment under each code call scenario. According to the test reference cases and call frequencies, target code segments under target call scenarios that meet the call scenario filtering conditions are tested to obtain the test results of the software under test. The call scenario filtering conditions are configured based on the call frequency. Global testing of the software is unnecessary, saving testing time and improving software testing efficiency.

[0005] This method, on the one hand, obtains structured information including code coverage and execution rate, ensuring the accuracy of the test data and providing a basis for test accuracy. Furthermore, it improves the efficiency and accuracy of subsequent software retesting. On the other hand, it filters call scenarios according to call frequency, which, compared to traditional methods that only filter interfaces by frequency, provides deeper filtering and finer-grained testing of business logic, thus improving test accuracy. Furthermore, by processing the structured information through a code analysis agent, reference test cases are obtained under the target test dimensions, eliminating the need for full-dimensional, global software testing and improving testing efficiency. Finally, by testing target code segments under the target call scenarios that meet the call scenario filtering conditions, the test results of the software under test are obtained, narrowing the scope of testing and further improving testing efficiency.

[0006] In one possible implementation of the first aspect, obtaining the code execution information of multiple target code segments in the software under test includes: parsing the code files in the software under test according to the folder structure to obtain multiple candidate code segments and their respective descriptive comments; obtaining the key logical structure of the business under test to which the software under test belongs; filtering multiple target descriptive comments that meet the comment filtering conditions from each descriptive comment according to the key logical structure matching filtering method; determining the candidate code segments corresponding to the target descriptive comments as target code segments; and monitoring the execution status of each target code segment according to the descriptive comment matching monitoring method to obtain the code execution information of each target code segment, wherein the code execution information includes code execution time, code context information, and code parameters.

[0007] This solution focuses on the key logical structure of the business under test, filtering out target descriptive comments from various descriptive annotations to reduce the scope of subsequent software testing and improve testing efficiency. Furthermore, by monitoring the execution of each target code segment according to descriptive comment matching, it obtains individual code execution information for each target code segment, thereby improving the accuracy of software testing.

[0008] In one possible implementation of the first aspect, the test metrics include a coverage threshold and an execution frequency threshold. Based on the test metrics of the business under test to which the software under test belongs, the code execution information is analyzed and processed to obtain the code coverage and execution rate corresponding to each target code segment in the software under test. This includes: synchronizing the code execution information to the database; extracting the code execution information from the database after the software under test has been deployed; performing data preprocessing on the code execution information according to the data preprocessing method matched to the database to obtain the preprocessed execution information for each target code segment; and for each target code segment, based on the coverage threshold of the business under test to which the software under test belongs... The code coverage of each line of code within the target code segment is analyzed to obtain the code coverage of the target code segment in the software under test. The coverage is used to represent the ratio of the number of executed lines of code in the target code segment to the total number of lines of code. The code coverage of the target code segment is greater than or equal to the coverage threshold. For each target code segment, based on the execution frequency threshold of the business under test to which the software under test belongs, frequency analysis is performed on the target code segment to obtain the code execution rate of the target code segment in the software under test. The code execution rate is used to represent the ratio of the number of times the target code segment is executed to the total number of times the target code segment is executed. The execution frequency of the target code segment is greater than or equal to the execution frequency threshold.

[0009] This solution synchronizes code execution information to a database. Once the software under test is deployed, the database is used to extract this information, ensuring both security and speed of data retrieval. Preprocessing of the code execution information improves data quality and provides a basis for enhancing software testing accuracy. Analysis based on coverage and execution frequency thresholds quantitatively determines code execution frequency and coverage. Compared to traditional qualitative analysis of code testing parameters, this method yields more accurate results, thus improving the accuracy of subsequent software testing.

[0010] In one possible implementation of the first aspect, the test parameters include dimension parameters and test case parameters. Based on the test parameters associated with the business under test in the code analysis agent, test case analysis is performed on the structured information of each target code segment to obtain test reference test cases for the software under test under the target test dimension. This includes: extracting multiple historical test cases that match the test parameters from the historical test case library based on the test case parameters associated with the business under test in the code analysis agent; analyzing and processing the structured information of each target code segment based on the dimension parameters associated with the business under test in the code analysis agent to obtain the target test dimension of the software under test; and selecting test reference test cases whose test dimension is the target test dimension from the historical test cases.

[0011] This solution analyzes and processes the structured information of each target code segment by filtering dimension parameters related to the business under test in the code analysis agent, thereby obtaining the target test dimensions for the accuracy of the software under test. The historical test cases are highly stable, and the test reference test cases for the target test dimensions can be selected from the historical test cases to ensure close relevance to the business while improving the accuracy of software testing.

[0012] In one possible implementation of the first aspect, the target code segment under the target call scenario that meets the call scenario filtering conditions is tested according to the test reference cases and the call frequency to obtain the test results of the software under test. This includes: obtaining the frequency range of the code call frequency configured for each code call scenario; for each target code segment, filtering the target call scenarios whose call frequency is within the frequency range from the multiple code call scenarios corresponding to the target code segment; and testing the target code segment under the target call scenario according to the test reference cases to obtain the test results of the software under test.

[0013] This solution obtains the frequency range of code calls configured for each code call scenario. For each target code segment, it filters out target call scenarios whose call frequency falls within the specified frequency range from among multiple code call scenarios corresponding to that target code segment. This filtering of code call scenarios reduces the scope of software testing and improves software testing efficiency.

[0014] In another possible implementation of the first aspect, the code testing method further includes: generating a test report for the target code segment under the target call scenario that meets the call scenario filtering conditions, based on the test reference cases and the descriptive comments corresponding to the target code segment; obtaining the question information for the test report in response to the terminal's questioning operation on the test report; inputting the question information and the test report into the question-answering model configured for the business under test, and outputting the updated test report.

[0015] This solution generates test reports for target code segments within target call scenarios that meet the call scenario filtering criteria, based on test reference cases and descriptive comments corresponding to the target code segments. Responding to terminal queries about the test report, it retrieves the query information. The query information and test report are then input into a question-and-answer model configured for the business under test, outputting an updated test report. By acquiring personalized prompts input by testers, the accuracy of the test reports is improved, secondary development costs are reduced, and ultimately, the efficiency and accuracy of software testing are enhanced.

[0016] In another possible implementation of the first aspect, the code testing method further includes: obtaining the coverage color code configured for code coverage, the execution rate code configured for code execution rate, and the chart configured for the business under test; encoding each code coverage according to the coverage color code to obtain the coverage color corresponding to each coverage; encoding each code execution rate according to the execution rate color code to obtain the execution rate color corresponding to each execution rate; and for each target code segment, writing the coverage color and execution rate color corresponding to the target code segment into the chart.

[0017] This solution obtains coverage color codes and execution rate codes that reflect the correspondence between colors and values. The colors strictly correspond to code coverage and code execution rate, respectively, improving the accuracy of subsequent color labeling for target code segments, avoiding color confusion during actual testing, improving chart readability, and reducing the workload of developers. For each target code segment, the server can write the corresponding coverage and execution rate colors into the chart. This allows for an intuitive display of the code coverage and execution rate of each target code segment. Not only can the code coverage and execution rate of a single target code segment be read, but the chart also displays the color distribution of the corresponding code coverage and execution rate for each target code segment. The chart is highly readable, reducing the time developers spend reading charts and improving overall software testing efficiency.

[0018] Secondly, a software testing apparatus is provided, the apparatus comprising: The system comprises four modules: execution information acquisition, analysis and processing, structured processing, test case analysis, frequency analysis, and code segment testing. The execution information acquisition module acquires code execution information for multiple target code segments within the software under test during runtime. The analysis and processing module analyzes this information according to the test metrics of the business being tested, yielding code coverage and execution rate for each target code segment. The structured processing module performs structured processing on the code coverage and execution rate of each target code segment, providing structured information containing these metrics. The test case analysis module analyzes test parameters associated with the business being tested within the code analysis agent. The test module performs test case analysis on the structured information of each target code segment to obtain test reference cases for the software under test in the target test dimension. The frequency analysis module is used to perform call frequency analysis on the structured information of each target code segment based on the scenario parameters associated with the business under test in the code analysis agent to obtain the call frequency of each target code segment in each code call scenario. The code segment testing module is used to test the target code segments in the target call scenarios that meet the call scenario filtering conditions according to the test reference cases and the call frequency to obtain the test results of the software under test. The call scenario filtering conditions are configured based on the call frequency.

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

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

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

[0022] It is understood that the beneficial effects that the software testing apparatus described in the second aspect, the software testing equipment described in the third aspect, the computer-readable storage medium described in the fourth aspect, and the computer program product described in the fifth aspect can achieve can be referred to the beneficial effects in the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the structure of a software testing system provided in an embodiment of this application; Figure 2 A flowchart illustrating a software testing method provided in an embodiment of this application; Figure 3 A flowchart illustrating a method for obtaining code execution information provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a data preparation module provided in an embodiment of this application; Figure 5 A flowchart illustrating a method for analyzing and processing code execution information provided in an embodiment of this application; Figure 6 A flowchart illustrating an analysis report generation method provided in this application embodiment; Figure 7 This application provides a schematic diagram of the structure of a code analysis workflow. Figure 8 This is a schematic diagram of the structure of a software testing device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a software testing device provided in an embodiment of this application. Detailed Implementation

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

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

[0026] The technical solutions provided in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data, comply with relevant laws and regulations and do not violate public order and good morals.

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

[0028] The software testing method provided in this application embodiment can be applied to, for example, Figure 1The software testing system shown includes a software testing device 102, a terminal 104, and a data storage system 106. During the operation of the software under test (SDT), the software testing device 102 acquires code execution information for multiple target code segments from the terminal 104 or the data storage system 106. The software testing device 102 analyzes and processes the code execution information according to the test metrics of the business under test to which the SDT belongs, obtaining the code coverage and code execution rate corresponding to each target code segment. For each target code segment, the software testing device 102 performs structured processing on the code coverage and code execution rate, obtaining structured information containing both the code coverage and code execution rate. Based on the test parameters associated with the business under test in the code analysis agent, the software testing device 102 performs test case analysis on the structured information of each target code segment, obtaining test reference cases for the SDT under the target test dimensions. The software testing device 102 analyzes the call frequency of each target code segment based on the scenario parameters associated with the business under test in the code analysis agent, obtaining the call frequency of each target code segment in each code call scenario. The software testing device 102 then tests the target code segments in target call scenarios that meet the call scenario filtering conditions according to the test reference cases and the call frequency, obtaining the test results of the software under test. The call scenario filtering conditions are configured based on the call frequency.

[0029] The software testing device 102 can be a server, which can be a standalone server or a server cluster consisting of multiple servers. The terminal 104 can be a processor with computing capabilities, and the data storage system 106 can be a processor or server with data storage capabilities. The data storage system can be a single server or a server cluster consisting of multiple servers.

[0030] Before a software project is officially launched, it is often necessary to test the software. Software testing is an indispensable part of the software development process and is used to confirm whether the functions or performance of the software meet the requirements specified in the development requirements document.

[0031] In traditional techniques, the compilation data is read, and the software's runtime logs and compilation data are compared on preset dimensions to generate a full comparison report. The software is then tested globally based on the comparison report. However, this testing approach still suffers from low test quality.

[0032] To address the aforementioned issues, this solution proposes the following approach: Obtain the code execution information of the software under test. Based on the test metrics of the business under test, the code execution information is processed to obtain the structured information of the target code segments. Using the test parameters and scenario parameters associated with the business under test within the agent, the structured information of each target code segment is analyzed to obtain test reference cases and the call frequency of the target code segment. According to the test reference cases, the target code segments under the target call scenarios are tested to obtain the test results of the software under test. This method, on the one hand, improves the accuracy of test results because the test parameters and scenario parameters of the agent are strongly correlated with the business under test. On the other hand, under the dual constraints of scenario frequency and test dimensions, it eliminates the need to test the entire code, thus improving testing efficiency.

[0033] The software testing method provided in this application can be applied to the fields of software testing, automated testing, or integrated testing, etc., and is not limited thereto.

[0034] In one embodiment, such as Figure 2 As shown, a software testing method is provided that can be applied to... Figure 1 The method can be implemented on servers, cloud computing platforms with data processing capabilities, edge computing devices, chips, or other computing devices. This application does not limit the specific form of the device executing the method; taking the application of the method to a server as an example, the method specifically includes: S202: During the operation of the software under test, obtain the code execution information of each of the multiple target code segments in the software under test.

[0035] In this context, "software under test" can refer to software currently in the testing phase. The testing phase can be an intermediate stage in the entire software lifecycle. The entire software lifecycle can include requirements analysis, design, coding, testing, deployment, and maintenance. Specifically, the requirements analysis phase involves reviewing the testability of requirements and developing a test plan. The design phase involves writing test cases and designing test strategies. The coding phase includes unit testing and integration testing. The testing phase includes system testing, acceptance testing, defect tracking, and remediation. The deployment phase verifies the consistency of the deployment environment versions. The maintenance phase involves regression testing and remediation verification.

[0036] The target code segment can be a specific line of code to be tested in the software under test, such as lines X to X of code in a code file within the software under test. A target code segment can contain one or more lines of code. A target code segment can also be called a code block.

[0037] The code execution information can represent the execution information when a code segment is executed. Specifically, the execution information can be execution log information. More specifically, the execution information can include execution time, context, input and output parameters, etc.

[0038] Execution time, in this context, refers to the total time required for a program to run from start to finish, including the time spent on all processing logic, database queries, file operations, etc. For example, PHP code execution time typically includes server response time and database query latency.

[0039] The context refers to the environment in which code is executed, including variable scope, scope chain, and execution context object (such as the variable object and `this` binding at the time of function call). For example, the function uses the context to determine the source and execution permissions of variables.

[0040] Input and output parameters can be the raw data received by the system or function and the return results. For example, system input parameters include the data type and format of the user input; output parameters define the format of the returned results (such as text or charts).

[0041] There are several ways to obtain execution information. Specifically, the server can read the execution information of the target code segment from the runtime log.

[0042] The server can monitor and record the execution of code snippets during software application runtime to obtain code execution information. This information includes execution time, context, input / output parameters, etc., ensuring the comprehensiveness and accuracy of the data.

[0043] More specifically, the server can parse the code files in the software under test according to the folder structure, obtaining multiple candidate code segments and their respective descriptive comments. The server can obtain the key logical structure of the business logic to which the software under test belongs. Based on a filtering method matching the key logical structure, the server can filter out multiple target descriptive comments that meet the filtering criteria; the candidate code segments corresponding to the target descriptive comments are then identified as target code segments. The server can monitor the execution status of each target code segment according to a monitoring method matching the descriptive comments, obtaining the code execution information for each target code segment, including code execution time, code context information, and code parameters.

[0044] S204. Based on the test metrics of the business to which the software under test belongs, analyze and process the execution information of each code segment to obtain the code coverage and code execution rate of each target code segment in the software under test.

[0045] Here, the task to be tested can refer to the job configured for the software under test during the testing phase. The task to be tested can include test metrics from the test plan in the requirements analysis phase.

[0046] Test metrics can be conditions configured to assess execution performance. Understandably, if the execution of a piece of code meets a condition, its execution information can be further analyzed. If the execution of a piece of code does not meet a condition, its execution information cannot be further analyzed. For example, a test metric could be a condition that the execution time is less than a time threshold; it could also be a condition indicating whether the code context information contains a specific function; or it could be a type condition indicating whether the type of a code parameter is a specific parameter type.

[0047] Test metrics can also include coverage thresholds and execution frequency thresholds.

[0048] Among them, the coverage threshold can be a threshold condition configured for code coverage, and the execution frequency threshold can represent a threshold condition configured for code execution rate.

[0049] Code coverage can be represented as the ratio of the number of lines of code executed in the target code segment to the total number of lines of code in the target code segment.

[0050] Among them, code execution rate can be expressed as the ratio of the number of times a target code segment is executed to the total number of times all target code segments are executed.

[0051] There are various methods for analysis and processing. Specifically, test metrics can include at least one of time threshold conditions, judgment conditions, and type conditions. Taking test metrics including time threshold conditions, judgment conditions, and type conditions as an example: The server can analyze and process the execution information of each code according to the time threshold conditions, judgment conditions, and type conditions of the business being tested to which the software under test belongs. This yields the condition judgment results for whether the target code segment meets the time threshold conditions, judgment conditions, and type conditions. If the condition judgment results for the target code segment include at least one failed condition, the code coverage and code execution rate corresponding to that target code segment can be set to 0. If all conditions in the condition judgment results for the target code segment pass, the code coverage and code execution rate of the target code segment can be extracted based on the code execution time, code context information, code parameters, and code log information.

[0052] Specifically, the test metrics include coverage threshold and execution frequency threshold. The server can also synchronize the execution information of each code segment to the database. After the software under test is deployed, the server can also extract the execution information of each code segment from the database. The server can also preprocess the execution information of each code segment according to the data preprocessing method matched to the database, obtaining the preprocessed execution information of each target code segment. For each target code segment, the server can also analyze the coverage of each line of code within the target code segment based on the coverage threshold of the business under test to which the software under test belongs, obtaining the code coverage corresponding to the target code segment in the software under test. The coverage rate is used to represent the ratio of the number of executed lines of code in the target code segment to the total number of lines of code. The code coverage corresponding to the target code segment is greater than or equal to the coverage threshold. The server can also perform frequency analysis on each target code segment based on the execution frequency threshold of the business under test to which the software under test belongs, obtaining the code execution rate corresponding to the target code segment in the software under test. The code execution rate is used to represent the ratio of the number of times the target code segment is executed to the total number of times the target code segment is executed. The execution frequency corresponding to the target code segment is greater than or equal to the execution frequency threshold.

[0053] S206. For each target code segment, the code coverage and code execution rate corresponding to the target code segment are processed in a structured manner to obtain structured information of the target code segment containing code coverage and code execution rate.

[0054] Structured information can be data stored in a fixed format with clearly defined fields and rules. Common types include tables, CSV files, JSON documents, and database forms.

[0055] Methods for structuring data can include: converting data formats, cleaning and transforming data, and using structuring tools to process data in a structured manner.

[0056] Data format conversion can involve transforming unstructured data, such as images and PDF documents, into editable semi-structured data, such as Word documents. Data cleaning can include removing duplicate records and outliers, correcting errors, standardizing data formats, converting data types, converting text information into tabular form, and ensuring that data types and column names are clearly defined. Using structured tools can include using libraries such as Pandas and NumPy for data cleaning and transformation.

[0057] Specifically, for each target code segment, the server can sequentially perform data format conversion, data cleaning and transformation on the code coverage and code execution rate corresponding to the target code segment to obtain structured information of the target code segment containing code coverage and code execution rate.

[0058] Specifically, for each target code segment, the server can use a structuring tool to perform structuring processing on the code coverage and code execution rate corresponding to the target code segment, thereby obtaining structuring information of the target code segment containing code coverage and code execution rate.

[0059] S208, based on the test parameters associated with the business under test in the code analysis agent, performs test case analysis on the structured information of each target code segment to obtain test reference cases for the software under test under the target test dimension.

[0060] The code analysis agent can be an AI program developed based on a large language model, capable of understanding complex programming instructions, analyzing code logic, and generating optimization solutions. It possesses autonomous planning capabilities and can automatically complete tasks such as code completion and logic correction by invoking development tools.

[0061] The test parameters can be model parameters related to testing in the code analysis agent.

[0062] The target testing dimension can be a model dimension related to testing within the code analysis agent. Specifically, the target testing dimension can be the testing dimension that the business under test is concerned with among multiple preset testing dimensions. These testing dimensions can include software functional testing dimensions, software performance testing dimensions, and tool invocation dimensions, etc.

[0063] The test reference cases can be the better test cases among multiple pre-stored test cases in the code analysis agent. Each test case should include at least a test case title, preconditions, test steps, and expected results.

[0064] Specifically, the server can analyze the test parameters associated with the business under test in the intelligent agent's code, perform test case analysis on the structured information of each target code segment, and obtain test reference cases for the software under test in the functional testing dimension. Similarly, the server can analyze the test parameters associated with the business under test in the intelligent agent's code, perform test case analysis on the structured information of each target code segment, and obtain test reference cases for the software under test in the performance testing dimension.

[0065] Specifically, the server can also extract multiple historical test cases that match the test parameters from the historical test case library based on the test case parameters associated with the business under test in the code analysis agent. The server can also analyze and process the structured information of each target code segment based on the dimension parameters associated with the business under test in the code analysis agent to obtain the target test dimension of the software under test. Finally, the server can filter test reference cases from the historical test cases whose test dimension matches the target test dimension.

[0066] S210, based on the scenario parameters associated with the business under test in the code analysis agent, performs call frequency analysis on the structured information of each target code segment to obtain the call frequency of each target code segment in each code call scenario.

[0067] The scene parameters can be scene-related model parameters in the code analysis agent.

[0068] The calling scenario can be a scenario involving a specific interface in the business operations of the software. For example, if business 1 needs to call interface 1 and business 2 also needs to call interface 1, then the calling scenarios are business 1-interface 1 and business 2-interface 1, respectively. Furthermore, if the number of calls to business 1-interface 1 is much greater than the number of calls to business 2-interface 1, then the calling scenario of business 1-interface 1 is a high-frequency scenario, and the calling scenario of business 2-interface 1 is a low-frequency scenario.

[0069] The call frequency can be the number of times the target code segment is called in a specific code call scenario, plus the total number of calls. The total number of calls can be the total number of times the corresponding interface is called in that code call scenario. Continuing with the previous example, if interface 1 is called 1000 times, and the code call scenario of business 1 - interface 1 is called 700 times, then the call frequency is 0.7.

[0070] There are several ways to analyze call frequency. Specifically, the server can identify multiple candidate call scenarios based on scenario parameters associated with the business under test in the code analysis agent. The server can then filter code call scenarios from these candidate scenarios according to the selected criteria.

[0071] Specifically, the server can extract multiple code call scenarios from the runtime log information. These code call scenarios can be scenarios set up during the software development phase. Based on the scenario parameters associated with the business under test in the code analysis agent, the server can perform call frequency analysis on the structured information of each target code segment to obtain the call frequency of each target code segment in each code call scenario. Within each code call scenario, the server can filter out target code call scenarios with high call frequencies (greater than a first preset frequency threshold) or low frequency frequencies (less than a second preset frequency threshold, where the first preset frequency threshold is greater than the second preset frequency threshold), thus obtaining the corresponding call frequency of each target code segment in each target code call scenario.

[0072] Specifically, the server can also determine the calling scenarios of the code of interest based on the scenario parameters associated with the business under test in the code analysis agent. The server can then perform call frequency analysis on the structured information of each target code segment based on the scenario parameters to obtain the call frequency of each target code segment under the calling scenarios of the code of interest.

[0073] S212, based on the test reference cases and the frequency of invocation, test the target code segments under the target invocation scenarios that meet the invocation scenario filtering conditions, and obtain the test results of the software under test.

[0074] The scenario filtering condition is configured based on the frequency of the code call. Specifically, the scenario filtering condition can be that the frequency of the code call scenario is greater than a first preset frequency threshold, or it can be that the frequency of the code call scenario is less than a second preset frequency threshold, where the first preset frequency threshold is greater than the second preset frequency threshold.

[0075] The test results can include software test results corresponding to target code segments within target call scenarios that meet the call scenario filtering criteria. On one hand, filtering by both call scenarios and code segments increases testing efficiency compared to traditional methods. On the other hand, filtering call scenarios by call frequency provides deeper filtering depth and finer granularity for the tested business logic, improving accuracy while maintaining testing efficiency.

[0076] Specifically, the server can obtain the frequency range of code calls configured for each code call scenario. For each target code segment, the server can filter target call scenarios whose call frequencies fall within the specified frequency range from among multiple code call scenarios corresponding to that target code segment. The server can then test the target code segment under the target call scenarios based on the test reference cases to obtain the test results of the software under test.

[0077] Specifically, the server can also perform agent analysis on the target code segment in the target call scenario based on the test reference cases to obtain test strategy information for the software under test, including test points and common test problems. The server can also send the test strategy information to the terminal. In response to the terminal's input operation on the test strategy information, the server can also test the target code segment in the target call scenario to obtain the test results for the software under test.

[0078] In this embodiment, firstly, structured information including code coverage and code execution rate is obtained, ensuring the accuracy of the test data and providing a basis for test accuracy. Furthermore, it improves the efficiency and accuracy of subsequent software retesting. Secondly, calling scenarios are filtered according to their frequency of invocation. Compared to traditional filtering based solely on frequency, this method offers deeper filtering and finer granularity of test business, improving test accuracy. Thirdly, the structured information is processed by a code analysis agent to obtain reference test cases under the target test dimension. This eliminates the need for full-dimensional, global software testing, improving testing efficiency. Furthermore, testing is performed on target code segments under the target calling scenarios that meet the filtering conditions, yielding test results for the software under test. This narrows the testing scope and further improves testing efficiency.

[0079] In one embodiment, such as Figure 3 As shown, in step S202 above, obtaining the code execution information of each of the multiple target code segments in the software under test can specifically include: S302-S310, including: S302, according to the folder structure, parse the code files in the software under test to obtain multiple candidate code segments and their respective descriptive comments.

[0080] The folder structure can be the file structure of the software under test. This structure can include parent file levels, child file levels, intermediate file levels, and the hierarchical relationships between parent, child, and intermediate files. Analyzing the code files in the software under test based on the folder structure provides a clearer understanding of the function and role of each part.

[0081] In this context, a candidate code segment can be a specific line of code to be tested in the software under test, such as lines X to Y in a code file within the software. A candidate code segment can contain one or more lines of code. A candidate code segment can also be referred to as a code block.

[0082] Descriptive comments can be explanations of specific logic or the purpose of variables in the code, mainly used to improve code readability and help developers understand the code design intent.

[0083] S304: Obtain the key logical structure of the business to which the software under test belongs.

[0084] The key logical structure can be the logical structure corresponding to the key business processes in the business under test. For example, the software architecture and its key components.

[0085] S306. Based on the filtering method of matching key logical structures, multiple target descriptive annotations that meet the annotation filtering conditions are obtained from each descriptive annotation.

[0086] The filtering methods for matching key logical structures can include key code paths, key code variables, key functions, etc.

[0087] The target descriptive annotation can be a descriptive annotation that meets the annotation selection criteria.

[0088] The annotation filtering criteria can include key code path criteria, key code variable criteria, key function criteria, etc.

[0089] Specifically, the server can filter multiple target descriptive comments that meet the comment filtering conditions from each descriptive comment by using at least one of the following filtering methods: key code path, key code variable, and key function.

[0090] S308, the candidate code segment corresponding to the target descriptive annotation is determined as the target code segment.

[0091] The candidate code segments corresponding to the target descriptive annotations can directly affect whether the critical logic of the business under test is correctly closed. Other candidate code segments besides those with target descriptive annotations can indirectly affect whether the critical logic of the business under test is correctly closed.

[0092] S310, according to the monitoring method of descriptive annotation matching, monitor the execution status of each target code segment and obtain the code execution information of each target code segment. The code execution information includes code execution time, code context information and code parameters.

[0093] Execution time, in this context, refers to the total time required for a program to run from start to finish, including the time spent on all processing logic, database queries, file operations, etc. For example, PHP code execution time typically includes server response time and database query latency.

[0094] The context refers to the environment in which the code is executed, including variable scope, scope chain, and execution context object (such as the variable object and `this` binding at the time of function call). For example, the function uses the context to determine the source of variables and execution permissions.

[0095] The code parameters can include input parameters and output parameters. Input and output parameters can be the raw data received by the system or function and the return results. For example, system input parameters include the data type and format of the user input; output parameters define the format of the returned results (such as text or charts).

[0096] There are several ways to monitor the execution of a target code segment, such as monitoring parameters for descriptive comments.

[0097] Specifically, the server can monitor the execution of each target code segment using code path monitoring based on descriptive comments, obtaining the code context information for each target code segment. The server can also monitor the execution of each target code segment using time monitoring tools based on descriptive comments, obtaining the execution time for each target code segment. Finally, the server can monitor the execution of each target code segment using parameter monitoring based on descriptive comments, obtaining the code parameters for each target code segment.

[0098] Reference Figure 4 The diagram illustrates the structure of the data preparation module. More specifically, the server can divide the code project according to a folder structure, categorizing the code into different sub-projects or modules. This provides a clearer understanding of the function and role of each part. The server can also divide a single code file into several functionally related code blocks based on its internal logical structure, enabling more precise tracking of code changes. Furthermore, the server can focus on specific methods and lines of code, paying particular attention to critical parts involving core business logic, ensuring these important nodes are accurately recorded. Finally, the server can use a large model to automatically generate descriptive comments based on the code structure and logic, the functional descriptions at the time of Git commits, and the functionally related requirements, helping to understand the code's function and purpose.

[0099] In this embodiment, by focusing on the key logical structure of the business under test, target descriptive comments are obtained by filtering from various descriptive comments, reducing the scope of subsequent software testing and improving software testing efficiency. On the other hand, by monitoring the execution status of each target code segment according to the descriptive comment matching monitoring method, the code execution information of each target code segment is obtained, improving the accuracy of software testing.

[0100] In one embodiment, the test metrics include a coverage threshold and an execution frequency threshold; such as Figure 5 As shown, in step S204 above, the code execution information is analyzed and processed according to the test indicators of the service to which the software under test belongs, to obtain the code coverage and code execution rate corresponding to each target code segment in the software under test. Specifically, this may include: S502-S510, specifically including: S502 synchronizes the execution information of each code to the database.

[0101] The database can be a synchronous database, which synchronizes the execution information of each code to the database, ensuring the security and accessibility of the data.

[0102] Specifically, the server can synchronize the execution information of each code to the database in real time to ensure the security and accessibility of the data.

[0103] S504 extracts code execution information from the database after the software under test has been deployed.

[0104] Among them, the deployment of the software under test can refer to the process of collecting, packaging, installing, configuring, and publishing the configuration files, user manuals, help documents, etc. of the software under test.

[0105] Specifically, the server can periodically clean and archive the execution data in the database to maintain its efficient operation. Once the software under test has been deployed, the server can extract execution information from the database.

[0106] S506, according to the data preprocessing method of database matching, performs data preprocessing on the execution information of each code segment to obtain the preprocessed execution information of each target code segment.

[0107] Data preprocessing methods can include data supplementation, outlier handling, data standardization, and data normalization.

[0108] The preprocessing execution information may include the preprocessed code execution time, code context information, and code parameters.

[0109] S508, for each target code segment, based on the coverage threshold of the business under test to which the software under test belongs, analyzes the coverage of each line of code in the target code segment to obtain the code coverage of the target code segment in the software under test. The coverage is used to represent the ratio of the number of executed lines of code in the target code segment to the total number of lines of code. The code coverage of the target code segment is greater than or equal to the coverage threshold.

[0110] Here, a line of code can represent each line of code within a code segment. Higher code coverage indicates higher utilization of the code segment, and vice versa.

[0111] The number of lines of code executed can represent the number of lines of code executed in the target code segment.

[0112] The total number of lines of code represents the total number of lines of code in the target code segment. For example, if the total number of lines of code is 100 and the number of lines of code executed is 85, the code coverage is 0.85.

[0113] S510, for each target code segment, based on the execution frequency threshold of the business under test to which the software under test belongs, frequency analysis is performed on the target code segment to obtain the code execution rate corresponding to the target code segment in the software under test. The code execution rate is used to represent the ratio of the number of times the target code segment is executed to the total number of times the target code segment is executed. The execution frequency corresponding to the target code segment is greater than or equal to the execution frequency threshold.

[0114] The total number of times each target code segment is executed represents the sum of the number of times each target code segment is executed.

[0115] Specifically, the server can generate visual charts based on the code coverage and execution rate of the target code segments in the software under test. More specifically, the server can obtain the coverage color codes configured for code coverage, the execution rate codes configured for code execution rates, and the charts configured for the business under test. The server can encode each code coverage separately using the coverage color codes to obtain the corresponding coverage color for each coverage level. The server can also encode each code execution rate separately using the execution rate color codes to obtain the corresponding execution rate color for each execution rate. For each target code segment, the server can write the corresponding coverage and execution rate colors into the charts. This allows for a visually intuitive display of the code coverage and execution rate of each target code segment.

[0116] Specifically, the server can also generate code coverage reports and code execution frequency reports based on the code coverage and code execution rate of the target code segment in the software under test. These reports can be used as a reference by developers during testing.

[0117] In this embodiment, by synchronizing the code execution information to a database, the information is extracted from the database after the software under test has been deployed, ensuring the security and speed of the code execution information. Data preprocessing of the code execution information improves data quality and provides a basis for improving the accuracy of software testing. Analysis based on coverage and execution frequency thresholds quantitatively determines the code execution frequency and code coverage. Compared to the qualitative analysis of code testing parameters in traditional methods, the obtained code execution frequency and code coverage are more accurate, thereby improving the accuracy of subsequent software testing.

[0118] In one embodiment, test parameters include dimension parameters and test case parameters. Based on the test parameters associated with the business under test in the code analysis agent, test case analysis is performed on the structured information of each target code segment to obtain test reference test cases for the software under test under the target test dimension. This includes: extracting multiple historical test cases matching the test parameters from the historical test case library based on the test case parameters associated with the business under test in the code analysis agent; analyzing and processing the structured information of each target code segment based on the dimension parameters associated with the business under test in the code analysis agent to obtain the target test dimension of the software under test; and selecting test reference test cases whose test dimension matches the target test dimension from the historical test cases.

[0119] The code analysis agent can be an AI program developed based on a large language model, capable of understanding complex programming instructions, analyzing code logic, and generating optimization solutions. It possesses autonomous planning capabilities and can automatically complete tasks such as code completion and logic correction by invoking development tools.

[0120] Here, the dimension parameters can be model parameters related to dimensions in the code analysis agent. The test case parameters can be model parameters related to test cases in the code analysis agent.

[0121] The historical test case library can be used to store multiple historical test cases. Historical test cases are those that have been used by developers and are more stable than new test cases. Understandably, using historical test cases for software testing is more accurate and efficient than using new test cases.

[0122] Among them, the testing dimensions can be software functional testing dimensions, software performance testing dimensions, tool calling dimensions, etc.

[0123] The test reference cases can be the better test cases among multiple pre-stored test cases in the code analysis agent. Each test case should include at least a test case title, preconditions, test steps, and expected results.

[0124] The target testing dimension can be the testing dimension that the business under test is concerned with from multiple preset testing dimensions. This testing dimension can be a software functional testing dimension, a software performance testing dimension, a tool invocation dimension, etc. For example, for a certain structured information, the target dimension can be a software functional testing dimension, a software performance testing dimension, or a composite dimension composed of both.

[0125] In this embodiment, by filtering the dimension parameters associated with the business under test in the code analysis agent, the structured information of each target code segment is analyzed and processed to obtain the target test dimension for the accuracy of the software under test. The historical test cases have high stability. By filtering the test reference test cases for the target test dimension from the historical test cases, we can ensure that the test is close to the business while improving the accuracy of software testing.

[0126] In one embodiment, based on test reference cases and call frequencies, target code segments in target call scenarios that meet the call scenario filtering conditions are tested to obtain the test results of the software under test. This includes: obtaining the frequency range of code call frequencies configured for each code call scenario; for each target code segment, selecting target call scenarios whose call frequencies fall within the frequency range from among multiple code call scenarios corresponding to the target code segment; and testing the target code segments in the target call scenarios based on test reference cases to obtain the test results of the software under test.

[0127] The code invocation scenario can be a scenario involving a specific interface in the business operations of the software. For example, if business 1 needs to call interface 1 and business 2 also needs to call interface 1, then the code invocation scenarios correspond to business 1-interface 1 and business 2-interface 1, respectively. Furthermore, if the number of calls to business 1-interface 1 is much greater than the number of calls to business 2-interface 1, then the business 1-interface 1 invocation scenario is a high-frequency scenario, and the business 2-interface 1 invocation scenario is a low-frequency scenario.

[0128] The call frequency can be the number of times the target code segment is called in a specific code call scenario, plus the total number of calls. The total number of calls can be the total number of times the corresponding interface is called in that code call scenario. Continuing with the previous example, if interface 1 is called 1000 times, and the code call scenario of business 1 - interface 1 is called 700 times, then the call frequency is 0.7.

[0129] The frequency range can be a range configured for each code call scenario. The frequency range can include high-frequency and low-frequency ranges. The high-frequency range can be greater than 0.5, and the low-frequency range can be less than 0.02. The range of the frequency range is not limited here and can be flexibly selected according to the actual situation.

[0130] For example, considering code call scenarios including Business 1 - Interface 1, Business 2 - Interface 1, and Business 3 - Interface 1, where Interface 1 is called 1000 times, the call frequency for Business 1 - Interface 1 is 0.8 (800 calls), the call frequency for Business 2 - Interface 1 is 0.19 (190 calls), and the call frequency for Business 3 - Interface 1 is 0.01 (800 calls). This indicates that Business 1 - Interface 1 falls within the high-frequency range, while Business 3 - Interface 1 falls within the low-frequency range. Specifically, the server can obtain the frequency range configured for each code call scenario, which includes both high-frequency and low-frequency ranges (the lower limit of the high-frequency range is greater than the upper limit of the low-frequency range). For each target code segment, the server can filter target call scenarios whose call frequencies fall within the frequency range (including both high-frequency and low-frequency ranges) from among the multiple code call scenarios corresponding to the target code segment. Based on the test reference cases, the target code segments under the target call scenarios are tested to obtain the test results of the software under test. In this embodiment, the frequency range of code call frequency configured for each code call scenario is obtained. For each target code segment, among the multiple code call scenarios corresponding to the target code segment, target call scenarios whose call frequency falls within the frequency range are selected. This filtering of code call scenarios reduces the scope of software testing and improves software testing efficiency.

[0131] In one embodiment, the software testing method further includes: generating a test report for the target code segment under a target call scenario that meets the call scenario filtering conditions, based on test reference cases and descriptive comments corresponding to the target code segment; obtaining question information for the test report in response to a terminal's questioning action on the test report; inputting the question information and the test report into a question-and-answer model configured for the service under test, and outputting an updated test report.

[0132] The test reference cases can be the better test cases among multiple pre-stored test cases in the code analysis agent. Each test case should include at least a test case title, preconditions, test steps, and expected results.

[0133] Descriptive comments can be explanations of specific logic or the purpose of variables in the code. They are mainly used to improve code readability and help developers understand the code design intent.

[0134] A test report can be used to provide testers with a reference for their testing. A test report may include areas for improvement, key points of the test, potential problems that may arise during testing, and the distribution of high-frequency and low-frequency services.

[0135] The terminal can be a device held by the tester.

[0136] The question-asking function can be used by testers to raise questions on the terminal regarding any points of doubt in the test report.

[0137] The prompt information can be information such as prompts obtained from the terminal, and the prompt information can be prompts that reflect the tester's personalization.

[0138] Among them, the question-answering model can be a large language model trained for software testing.

[0139] Specifically, the server can train the large language model based on historical software test sample data until the large language model completes the iteration conditions, resulting in a well-trained large language model for software testing.

[0140] Specifically, such as Figure 6The flowchart shown illustrates the analysis report generation method. The server can transform raw data (code coverage and code execution rate corresponding to the target code segment) into structured data. The server can then use a code analysis agent to perform multi-faceted analysis on the structured data, obtaining test analysis results, high-frequency scenario analysis results, business analysis results, and other analysis results. Based on the test analysis results, high-frequency scenario analysis results, business analysis results, and other analysis results, the server can generate a comprehensive analysis result.

[0141] This involves using intelligent agents to conduct in-depth analysis of structured report data, including but not limited to the following: Test Analysis: This section proposes how the system should be tested, what the key testing points are, which parts should be tested, and what areas might be overlooked. High-Frequency Scenario Analysis: This section identifies the system's high-frequency scenarios and predicts potential problems in these scenarios, providing a basis for preventative maintenance. Business Analysis: This section analyzes the system's high-frequency and low-frequency business processes, exploring the underlying reasons and analyzing the specific context to understand why this business distribution occurs. Based on the above analysis, specific improvement suggestions are provided, resulting in a comprehensive analysis report. The comprehensive analysis report may include the test analysis report.

[0142] More specifically, such as Figure 7 The diagram illustrates the code analysis workflow. The server can generate a test report for the target code segment within a target call scenario that meets the call scenario filtering criteria, based on the test reference cases and descriptive comments corresponding to the target code segment. The server can respond to terminal queries regarding the test report and obtain the query information. The server can then input the query information and the test report into a question-and-answer model configured for the business under test, and output an updated test report.

[0143] In this embodiment, based on the test reference cases and descriptive comments corresponding to the target code segments, a test report is generated for the target code segments under the target call scenarios that meet the call scenario filtering conditions. Responding to the terminal's questioning operation regarding the test report, the question information is obtained. The question information and test report are input into the question-and-answer model configured for the business under test, and an updated test report is output. Personalized prompts input by testers improve the accuracy of the test report, reduce secondary development costs, and thus improve the efficiency and accuracy of software testing. Multi-angle statistics on application code coverage and execution frequency are provided. Simultaneously, comments on code snippets are generated based on a large model, providing data support for subsequent analysis. Utilizing intelligent agent technology, combined with previously collected code coverage data, diverse analysis content can be generated. Personalized analysis content can be added simply by adjusting the prompts, reducing secondary development costs. Workflow-based report data analysis can provide better analysis results for specific analysis content.

[0144] In one embodiment, the software testing method further includes: obtaining coverage color codes configured for code coverage, execution rate codes configured for code execution rates, and charts configured for the business under test. Each code coverage is encoded according to the coverage color code to obtain its corresponding coverage color. Each code execution rate is encoded according to the execution rate color code to obtain its corresponding execution rate color. For each target code segment, the coverage color and execution rate color corresponding to the target code segment are written into the chart.

[0145] Color coding can be encoded information that records the correspondence between numerical values ​​and colors. For example, color coding could be 0~0.2 corresponding to white, 0.2~0.8 corresponding to green, and 0.8~1 corresponding to red.

[0146] The charts configured for the business under test have preset tables, with corresponding pop-up positions for information such as color, value, target code segment identifier, execution rate and coverage of each target code segment.

[0147] In this embodiment, coverage color codes and execution rate codes reflecting the correspondence between colors and values ​​are obtained. The colors strictly correspond to code coverage and code execution rate, respectively, improving the accuracy of subsequent color identification for target code segments, avoiding color confusion during actual testing, improving chart readability, and reducing the workload of developers. For each target code segment, the server can write the corresponding coverage and execution rate colors into the chart. This allows for an intuitive display of the code coverage and execution rate of each target code segment. Not only can the code coverage and execution rate of a single target code segment be read, but the chart also displays the color distribution of the corresponding code coverage and execution rate for each target code segment. The chart is highly readable, reducing developers' chart reading time and improving overall software testing efficiency. Figure 8 This is a schematic diagram of the structure of a software testing device 800 provided in an embodiment of this application. Figure 8 As shown, the software testing device 800 includes: an execution information acquisition module 802, an analysis and processing module 804, a structured processing module 806, a test case analysis module 808, a frequency analysis module 810, and a code segment testing module 812.

[0148] The execution information acquisition module 802 is used to acquire the code execution information of each of the multiple target code segments in the software under test during the operation of the software under test. The analysis and processing module 804 is used to analyze and process the code execution information according to the test indicators of the business under test to which the software under test belongs, and to obtain the code coverage and code execution rate corresponding to each target code segment in the software under test. The structured processing module 806 is used to perform structured processing on the code coverage and code execution rate of each target code segment to obtain structured information of the target code segment containing code coverage and code execution rate. The test case analysis module 808 is used to analyze the test case of each target code segment based on the test parameters associated with the business under test in the code analysis agent, and obtain the test reference test cases of the software under test under the target test dimension. The frequency analysis module 810 is used to perform call frequency analysis on the structured information of each target code segment based on the scenario parameters associated with the business under test in the code analysis agent, so as to obtain the call frequency of each target code segment in each code call scenario. The code segment testing module 812 is used to test the target code segment under the target call scenario that meets the call scenario filtering conditions based on the test reference cases and the call frequency, and to obtain the test results of the software under test. The call scenario filtering conditions are conditions configured for the call frequency.

[0149] In other embodiments, the execution information acquisition module 802 is further configured to parse the code files in the software under test according to the folder structure to obtain multiple candidate code segments and their respective descriptive comments; acquire the key logical structure of the business under test to which the software under test belongs; select multiple target descriptive comments that meet the comment selection conditions from each descriptive comment according to the key logical structure matching filtering method; determine the candidate code segment corresponding to the target descriptive comment as the target code segment; and monitor the execution status of each target code segment according to the descriptive comment matching monitoring method to obtain the code execution information of each target code segment, wherein the code execution information includes code execution time, code context information and code parameters.

[0150] In other embodiments, the test metrics include a coverage threshold and an execution frequency threshold. The analysis and processing module 804 is further configured to synchronize the execution information of each code segment to the database; extract the execution information of each code segment from the database after the software under test has been deployed; perform data preprocessing on the execution information of each code segment according to the data preprocessing method matched by the database to obtain the preprocessed execution information of each target code segment; for each target code segment, analyze the coverage of each line of code in the target code segment based on the coverage threshold of the service under test to which the software under test belongs, to obtain the code coverage of the target code segment in the software under test, where the coverage is used to represent the ratio of the number of executed lines of code in the target code segment to the total number of lines of code, and the code coverage of the target code segment is greater than or equal to the coverage threshold; for each target code segment, perform frequency analysis on the target code segment based on the execution frequency threshold of the service under test to which the software under test belongs, to obtain the code execution rate of the target code segment in the software under test, where the code execution rate is used to represent the ratio of the number of times the target code segment is executed to the total number of times the target code segment is executed, and the execution frequency of the target code segment is greater than or equal to the execution frequency threshold.

[0151] In other embodiments, the aforementioned use case analysis module 808 is further configured to: extract multiple historical test cases that match the test parameters from the historical use case library based on the use case parameters associated with the business under test in the code analysis agent; analyze and process the structured information of each target code segment based on the dimension parameters associated with the business under test in the code analysis agent to obtain the target test dimension of the software under test; and select test reference cases whose test dimension is the target test dimension from among the historical test cases.

[0152] In other embodiments, the code segment testing module 812 is further configured to obtain the frequency range of the code call frequency configured for each code call scenario; for each target code segment, select target call scenarios whose call frequency is within the frequency range from the multiple code call scenarios corresponding to the target code segment; and test the target code segment under the target call scenario according to the test reference test cases to obtain the test results of the software under test.

[0153] In other embodiments, the software testing apparatus 800 may further include a test report question-and-answer module, which is used to generate a test report corresponding to the target code segment under the target call scenario that meets the call scenario filtering conditions, based on the test reference cases and the descriptive comments corresponding to the target code segment; to obtain the question information for the test report in response to the terminal's question operation; to input the question information and the test report into the question-and-answer model configured for the service under test, and to output the updated test report.

[0154] In other embodiments, the software testing apparatus 800 may further include a chart writing module, used to acquire coverage color codes configured for code coverage, execution rate codes configured for code execution rates, and charts configured for the service under test; encode each code coverage according to the coverage color codes to obtain the coverage color corresponding to each coverage; encode each code execution rate according to the execution rate color codes to obtain the execution rate color corresponding to each execution rate; and write the coverage color and execution rate color corresponding to each target code segment into the chart for each target code segment.

[0155] The software testing apparatus 800 provided in this application embodiment can execute the method shown in the above method embodiment. Its implementation principle and beneficial effects can be referred to the relevant description in the method embodiment, and will not be repeated here.

[0156] Figure 9 This is a schematic diagram of the structure of a software testing device provided in an embodiment of this application. Figure 9 As shown, the software testing device includes: a memory 901, a transceiver 902, and at least one processor 903.

[0157] The transceiver 902 is used to interact with other devices to send and receive data. For example, in this embodiment, the transceiver 902 can specifically be used to send and receive data such as code coverage data, code execution rate data, and structured information.

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

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

[0160] The memory 901, transceiver 902, and processor 903 are communicatively connected. For example, the memory 901 and transceiver 902 can be connected to the processor 903 via a system bus to complete communication between them. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the figure, but this does not mean that there is only one bus or one type of bus.

[0161] Optionally, the memory 901 can be either standalone or integrated with the processor 903. When the memory 901 is set up independently, it is connected to the processor 903 via the system bus.

[0162] This application also provides a chip for executing instructions, which is used to execute the technical solution of the software testing method in the above embodiments.

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A software testing method characterized by, The method includes: During the operation of the software under test, the code execution information of each of the multiple target code segments in the software under test is obtained; According to the test indicators of the test service to which the software under test belongs, the code execution information of each code is analyzed and processed to obtain the code coverage and code execution rate corresponding to each target code segment in the software under test; For each target code segment, the code coverage and code execution rate corresponding to the target code segment are processed in a structured manner to obtain structured information of the target code segment containing code coverage and code execution rate; Based on the test parameters associated with the business under test in the code analysis agent, test case analysis is performed on the structured information of each target code segment to obtain test reference cases for the software under test under the target test dimension. Based on the scenario parameters associated with the business under test in the code analysis agent, the call frequency analysis is performed on the structured information of each target code segment to obtain the call frequency of each target code segment in each code call scenario. Based on the test reference cases and the call frequency, the target code segment under the target call scenario that meets the call scenario filtering conditions is tested to obtain the test results of the software under test. The call scenario filtering conditions are conditions configured for the call frequency.

2. The method of claim 1, wherein, The step of obtaining the code execution information of each of the multiple target code segments in the software under test includes: The code files in the software under test are parsed according to the folder structure to obtain multiple candidate code segments and descriptive comments for each candidate code segment. Obtain the key logical structure of the business to which the software under test belongs; According to the filtering method of matching the key logical structure, multiple target descriptive annotations that meet the annotation filtering conditions are obtained from each of the descriptive annotations. The candidate code segment corresponding to the target descriptive annotation is determined as the target code segment; According to the monitoring method of matching descriptive annotations, the execution status of each target code segment is monitored to obtain the code execution information of each target code segment, wherein the code execution information includes code execution time, code context information and code parameters.

3. The method of claim 1, wherein, The test metrics include coverage threshold and execution frequency threshold; The step of analyzing and processing the code execution information according to the test metrics of the service to which the software under test belongs, to obtain the code coverage and code execution rate corresponding to each target code segment in the software under test, includes: Synchronize the execution information of each code to the database; Once the software under test has been deployed, the execution information of each code is extracted from the database. According to the data preprocessing method matched by the database, the execution information of each code segment is preprocessed to obtain the preprocessed execution information of each target code segment. For each target code segment, based on the coverage threshold of the test service to which the software under test belongs, the coverage of each line of code in the target code segment is analyzed to obtain the code coverage of the target code segment in the software under test. The coverage is used to represent the ratio of the number of executed lines of code in the target code segment to the total number of lines of code. The code coverage of the target code segment is greater than or equal to the coverage threshold. For each target code segment, frequency analysis is performed on the target code segment based on the execution frequency threshold of the test service to which the software under test belongs, to obtain the code execution rate corresponding to the target code segment in the software under test. The code execution rate is used to represent the ratio of the number of times the target code segment is executed to the total number of times each target code segment is executed. The execution frequency corresponding to the target code segment is greater than or equal to the execution frequency threshold.

4. The method of claim 1, wherein, The test parameters include dimension parameters and test case parameters; The test parameters associated with the business under test in the code analysis agent are used to perform test case analysis on the structured information of each target code segment to obtain test reference cases for the software under test under the target test dimension, including: Based on the test case parameters associated with the business under test in the code analysis agent, multiple historical test cases that match the test parameters are extracted from the historical test case library. Based on the dimension parameters associated with the business under test in the code analysis agent, the structured information of each target code segment is analyzed and processed to obtain the target test dimensions of the software under test. Among the historical test cases, select the test reference cases whose test dimension is the target test dimension.

5. The method of claim 1, wherein, The step of testing the target code segment under the target call scenario that meets the call scenario filtering conditions according to the test reference cases and the call frequency, and obtaining the test results of the software under test, includes: Obtain the frequency range of the code call frequency configured for each of the aforementioned code call scenarios; For each target code segment, among the multiple code calling scenarios corresponding to the target code segment, target calling scenarios whose calling frequency is within the frequency range are selected; Based on the test reference cases, the target code segment under the target calling scenario is tested to obtain the test results of the software under test.

6. The method of claim 2, wherein, The method further includes: Based on the test reference cases and the descriptive comments corresponding to the target code segments, a test report is generated for the target code segments under the target call scenarios that meet the call scenario filtering conditions. In response to a terminal's query on the test report, obtain the query information for the test report; The question information and the test report are input into the question-answering model configured for the service to be tested, and the updated test report is output.

7. The method of claim 1, wherein, The method further includes: Obtain the coverage color code configured for the code coverage, the execution rate code configured for the code execution rate, and the preset chart configured for the service under test; Each code coverage is encoded according to the coverage color encoding to obtain the coverage color corresponding to each coverage; The execution rate of each code is encoded according to the execution rate color encoding to obtain the execution rate color corresponding to each execution rate. For each target code segment, the coverage color and execution rate color corresponding to the target code segment are written into the preset chart.

8. A software testing apparatus, characterized by comprising: include: The execution information acquisition module is used to acquire the code execution information of each of the multiple target code segments in the software under test during the software under test operation. The analysis and processing module is used to analyze and process the code execution information according to the test indicators of the test service to which the software under test belongs, and to obtain the code coverage and code execution rate corresponding to each target code segment in the software under test. The structured processing module is used to perform structured processing on the code coverage and code execution rate corresponding to each target code segment, so as to obtain structured information of the target code segment containing code coverage and code execution rate; The test case analysis module is used to perform test case analysis on the structured information of each target code segment based on the test parameters associated with the business under test in the code analysis agent, so as to obtain the test reference test cases of the software under test under the target test dimension. The frequency analysis module is used to perform call frequency analysis on the structured information of each target code segment based on the scenario parameters associated with the business under test in the code analysis agent, so as to obtain the call frequency of each target code segment in each code call scenario. The code segment testing module is used to test the target code segment under the target call scenario that meets the call scenario filtering conditions according to the test reference cases and the call frequency, and to obtain the test results of the software under test. The call scenario filtering conditions are conditions configured for the call frequency.

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

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

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

Images