Code change test method and system based on test case screening

Abstract

The invention relates to a code change test method and system based on test case screening, and the method comprises the following steps: S1, obtaining code data of a new version and a baseline version, and calculating to obtain code change data; s2, screening a to-be-tested use case based on the change data and a use case-coverage code mapping relationship corresponding to the baseline version; s3, executing the to-be-tested use case to obtain a use case-overlay code mapping relation corresponding to the new version; and S4, based on the change data and the use case-cover code mapping relationship between the baseline version and the new version, calculating to obtain the cover data of the changed code, and realizing the code change test. Compared with the prior art, the method has the advantages that according to the code change condition between versions and the historical use case execution condition, the mapping relation between the use case and the coverage code is established, and then the use case is recommended to achieve testing.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to a code change testing method and system based on test case screening. Background Art

[0002] Testing activities are important quality assurance procedures in software engineering, which are usually divided into unit testing, integration testing, etc. Unit testing is a basic test conducted in the development stage, emphasizing the quality of a single code block, and running in the developer's IDE or a specific environment; integration testing is usually the responsibility of testers, usually running in a dedicated test environment and deploying complete system modules, emphasizing that software quality can meet requirements from a business perspective and verifying that the connection and operation of each system module are as expected.

[0003] With the continuous iteration of software development activities, there are more and more test cases. Especially for integration testing, when the code changes, there are some limitations in manually analyzing the impact scope and manually selecting use cases, such as high labor costs, possible omissions in manual analysis, and the inability to directly observe the coverage of the changed code in the system test environment.

[0004] In summary, there is currently a lack of a code change testing method and system to solve or partially solve the above-mentioned problems. Summary of the invention

[0005] The purpose of the present invention is to overcome the defects of the above-mentioned prior art and to provide a code change testing method and system based on test case screening. According to the code changes between versions and the historical test case execution, a mapping relationship between the test case and the covered code is established, and then the test case is recommended for implementation.

[0006] The purpose of the present invention can be achieved by the following technical solutions:

[0007] One aspect of the present invention provides a code change testing method based on test case screening, comprising the following steps:

[0008] Step S1, obtaining code data of the new version and the baseline version, and calculating the code change data;

[0009] Step S2, screening the use cases to be tested based on the change data and the use case-coverage code mapping relationship corresponding to the baseline version;

[0010] Step S3, executing the test case to be tested to obtain a test case-coverage code mapping relationship corresponding to the new version;

[0011] Step S4, based on the change data and the use case-coverage code mapping relationship between the baseline version and the new version, calculate the coverage data of the changed code to implement code change testing.

[0012] As a preferred technical solution, it also includes:

[0013] Step S5, judging whether the coverage data meets a preset coverage rate threshold, if so, executing step S6, if not, executing step S7;

[0014] Step S6, ending the code change test;

[0015] Step S7, for the parts not covered by the changed code, prompt manual or AI to supplement the use cases, and perform the next round of testing based on the supplemented use cases.

[0016] As a preferred technical solution, the step S1 includes:

[0017] Step S101, based on the code data of the new version and the baseline version, a comparison tool is used to calculate a data set of changed lines in the code;

[0018] Step S102, filtering the changed row data set based on a preset filtering string pattern;

[0019] Step S103, for the filtered changed row data set, obtain structured data of the code data through code lexical syntax analysis, and identify the method to which the changed row belongs;

[0020] Step S104, traverse the filtered changed row data set, and obtain the change method data through conversion;

[0021] Step S105, integrating the traversed changed method data as code changed data.

[0022] As a preferred technical solution, the step S104 includes:

[0023] Step S1041, obtaining changed row data;

[0024] Step S1042, based on the change row data, determine whether the change row belongs to a method and the change type is an increase, if so, execute step S1043, if not, execute step S1044;

[0025] Step S1043, taking all the changed rows in the changed row corresponding method as newly added rows;

[0026] Step S1044, based on the changed row data, determine whether the changed row belongs to a method and the change type is deletion, if so, execute step S1045, if not, execute step S1046;

[0027] Step S1045, treating all changed rows in the change row corresponding method as deleted rows;

[0028] Step S1046, grouping all the change rows under the method corresponding to the change row according to the change type, and integrating them to obtain the change method data.

[0029] As a preferred technical solution, step S102 includes:

[0030] The string pattern is used to match the content of the code line. If the match is successful, the current line is ignored.

[0031] As a preferred technical solution, the step S2 includes:

[0032] Step S201, obtaining the method change data and the use case-coverage code mapping relationship corresponding to the baseline version;

[0033] Step S202, determine if the change data type of the method is increase, if so, execute step S203, if not, execute step S204;

[0034] Step S203, ignoring the changed data of the method of adding the type;

[0035] Step S204, determine if the changed data type of the method is deletion, if so, execute step S205, if not, execute step S206;

[0036] Step S205, facilitating the use case-coverage code mapping relationship corresponding to the baseline version, and screening use cases containing methods;

[0037] Step S206, determine whether there is a new row, if yes, execute step S205, if no, execute step S207;

[0038] Step S207 , based on the use case-coverage code mapping relationship corresponding to the baseline version, filter use cases including deleted rows and modified rows.

[0039] As a preferred technical solution, the step S3 includes:

[0040] Step S301, obtaining a use case to be executed;

[0041] Step S302, setting an exclusive lock for the test environment, and determining whether the setting is successful, if so, executing step S304, if not, executing step S303;

[0042] Step S303, executing step S302 after waiting for a preset time;

[0043] Step S304, executing the use case and calculating the code coverage;

[0044] Step S305, using the coverage probe to obtain code coverage data, and performing steps S306 and S307 simultaneously or separately;

[0045] Step S306, generating a mapping relationship between the current use case and the covered code based on the code coverage data and the use case information;

[0046] Step S307, releasing the exclusive lock of the test environment;

[0047] Step S308, determine whether there are any unexecuted use cases, if so, execute step S301, if not, execute step S309;

[0048] Step S309, based on the generated mapping relationship between the use case and the coverage code, a new version of the use case-coverage code mapping relationship is obtained.

[0049] As a preferred technical solution, the change data includes the file name of the code change, the method name of the code change, the method change type, the newly added code line number set, the deleted code line number set and the modified code line number set.

[0050] As a preferred technical solution, the use case-coverage code mapping relationship includes the global number of the use case, the code version and the code information set, wherein the code information includes the files covered by the use case, the method names covered by the use case and the line numbers covered by the use case.

[0051] Another aspect of the present invention provides a code change testing system based on test case screening, which is used to implement the aforementioned code change testing method based on test case screening, and the code change testing system includes:

[0052] Statistics and log module, used to record the process data of version code comparison and use case screening, record the resource consumption during the operation of the device, and record user requests in the log;

[0053] The use case management module is used to store use cases, initiate use case execution, and record execution results;

[0054] The test environment module is used to implement the provision and management of the test environment, deploy coverage probes, obtain code coverage data, and maintain the test environment lock status;

[0055] The code change calculation module is used to call the code comparison tool, generate code change data, and cache the calculated data to speed up the response;

[0056] The use case recommendation module is used to filter the use cases to be tested.

[0057] Compared with the prior art, the present invention has at least one of the following beneficial effects:

[0058] (1) Through use case demarcation, ensure that the use case and the code it covers form an accurate mapping relationship.

[0059] (2) Exclusive guarantee of the test environment during the execution of the use case, ensuring that the code covered by the use case is not interfered with by other use cases.

[0060] (3) Automatically filter test cases based on code changes, effectively reducing repeated testing while ensuring test coverage of the changed code.

[0061] (4) The problem of inaccurate sample selection caused by method renaming was solved through process orchestration. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Figure 1 A flowchart of a code change testing method based on test case screening in an embodiment;

[0063] Figure 2 A schematic diagram of a flow chart for calculating code changes in an embodiment;

[0064] Figure 3 A schematic diagram of a process for selecting a test case to be tested in an embodiment;

[0065] Figure 4 A schematic diagram of executing a use case in an embodiment;

[0066] Figure 5 Schematic diagram of a code change testing system based on test case screening in an embodiment;

[0067] Figure 6 Schematic diagram of an electronic device in an embodiment. DETAILED DESCRIPTION

[0068] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0069] The relevant terms in this application are defined as follows:

[0070] Probe: Probes can monitor and modify the context of a program when it is running. Probes are implemented differently in different programming languages. For example, when running a jar package in Java, you can specify a JavaAgent (i.e., a Java probe). The JavaAgent can monitor all information of the jar package when it is running, including information such as executed classes, methods, and lines, and can modify the bytecode of the program when it is running, thereby changing the program behavior. Probes are widely used in practice, such as observing and recording program running conditions, and counting program running indicators.

[0071] Example 1

[0072] In response to the problems existing in the aforementioned prior art, this embodiment provides a code change testing method based on test case screening, which establishes a mapping relationship between use cases and covered codes according to the code changes between versions and historical use case execution, and then recommends use cases for implementation testing.

[0073] This method can be started after submitting a new version of the code (such as V2) and determining its baseline version (such as V1), see Figure 1 , the method comprises the following steps:

[0074] Step S1, calculate the code changes based on the new version and the baseline version. This step has two inputs: the new version number and the baseline version number, and one output: the code changes (Set <methoddiff>). This step is described in detail in "Calculating Code Changes" below. After execution is complete, execute S2.

[0075] Step S2: Based on the code changes and the mapping relationship between the use case and the coverage code (baseline version), <casecovcode>), filter out the use cases to be tested. This step is described in detail in the "Filter Use Cases to be Tested" process below. After completion, execute step S3.

[0076] Step S3, execute the test case. This method can ensure the exclusivity of the test environment during execution and achieve the automatic decomposition effect of the test case. Generate a mapping relationship between the test case and the coverage code (new version) (Set <casecovcode>). See the "Execution Use Case" section below for details. After completion, proceed to step S4.

[0077] Step S4: Summarize the Sets generated in the previous steps <casecovcode>, combined with the code change data, calculate the coverage of the changed code. After completion, execute step S5.

[0078] Step S5: If the coverage of the changed code meets the set threshold (such as the coverage rate reaches 90%), or is manually marked as verified, execute step S6; otherwise, execute step S7.

[0079] Step S6, ending the code change test.

[0080] Step S7: For the part not covered by the changed code, prompt the human or AI to supplement the use case for the next round of use case execution. After completion, execute step S3.

[0081] Preferably, in step S1, the code change calculation process calculates the line change status (Set <linediff>), ignore the changes that do not need to be paid attention to according to the user's configuration, and then use the parsing tool to parse the file where the changed code is located, obtain the method where the changed line is located, and finally calculate the changes in the methods and lines of the two versions (Set <methoddiff>), in preparation for the subsequent screening of test cases. Figure 2 The flowchart for calculating code changes includes the following steps:

[0082] Step S201, using a comparison tool (such as GitDiff) to calculate the code changes based on the input baseline version number (such as V1) and the new version number (such as V2). Usually, the format generated by the comparison tool includes the changed file, the line number of the newly added line in the file, the line number of the deleted line, and the line number of the modified line. Among them, the newly added line is for the new version code, while the deleted line and the modified line are for the baseline version code. This step saves the comparison result as Set <linediff>After completion, execute step S202.

[0083] Step S202, based on user configuration, identify and ignore unnoticed line changes. Code comments, blank lines, debug tracking points, print logs, observable tracking points, etc. will not affect the business logic of the code, and can be marked as unnoticed changes and ignored in subsequent steps. In this device, the user can achieve the above effect by configuring the string pattern to be filtered (such as the regular expression ^\s*$ can represent a blank line). When filtering, the code line content (lineContent) in the LineDiff structure is read and matched with the string pattern. If the match is successful, the line is ignored. This step outputs the filtered Set <linediff>, after completion, execute step S203.

[0084] Step S203: This step parses the method of the changed row. Process Set one by one <linediff>, use the code lexical syntax parsing tool (such as JavaParser) to obtain the structured information of the code file in the file (source file) in LineDiff, and then identify the method to which the changed line belongs.

[0085] Step S204: This step is the core step. <linediff>Convert to Set <methoddiff>The specific conversion logic is described in steps S2041-S2046.

[0086] Step S2041, conversion starts, input LineDiff.

[0087] Step S2042, determine whether the changed line in LineDiff is a method signature and lineChgType is add. If yes, it means that the changed line is a newly added method signature, and the method should be identified as a newly added method, and step S2043 is executed; otherwise, step S2044 is executed.

[0088] Step S2043, create MethodDiff, set methodChgType to add, and determine all changed lines of the method in the previous step as newly added lines and put them into addLines.

[0089] Step S2044, determine whether the changed line in LineDiff is a method signature and lineChgType is del. If so, it means that the changed line is a deletion method signature, and the method should be identified as a deletion method, and step S2045 is executed; otherwise, step S2046 is executed.

[0090] Step S2045, create MethodDiff, set methodChgType to del, and determine all changed lines of the method in the previous step as deleted lines and put them into delLines.

[0091] Step S2046, create MethodDiff, set methodChgType to edit, and put all changed lines of the method in the previous step into different positions according to lineChgType: put addLines if lineChgType is add, put editLines if lineChgType is edit, and put delLines if lineChgType is del.

[0092] Step S205, summarize the MethodDiff generated in the previous step and output Set <methoddiff>.

[0093] Preferably, the process of screening the test cases to be tested is based on the changed code to filter out the ones that should be executed. The input is Set <methoddiff>and the baseline version (such as V1) of Set <casecovcode>, where Set <methoddiff>Records the change code information, Set <casecovcode>Records the code information covered by the test cases, and the output is a set of test cases to be executed. For details, see Figure 3 This process traverses Set <methoddiff>, execute S301-S307 for each MethodDiff:

[0094] Step S301, screening starts, input MethodDiff.

[0095] Step S302, determine whether methodChgType is add. If so, it means that the method is newly added in the new version of the code (or the method is renamed), and a use case needs to be added in the subsequent steps. It can be ignored here and execute S303. If not, execute step S304.

[0096] Step S303: Ignore the code change.

[0097] Step S304, determine whether methodChgType is del. If so, it means that the method has been deleted in the new version of the code (or the method has been renamed), and the relevant use cases need to be screened out for execution. There are two purposes: one is to determine whether the use case is invalid later, and the other is that if it is caused by method renaming, the relationship between the use case and the renamed method is re-established by executing the use case, and step S305 is executed. If not, step S306 is executed.

[0098] Step S305, traverse Set <casecovcode>, filter out the use cases whose covedCodes contain this method.

[0099] Step S306: Executing to this step indicates that methodChgType is edit, that is, the method exists in both the new version and the baseline version code and has been modified. This step determines whether addLines has a value. If so, it indicates that the method has new lines, and the overall logic of the code may change. The use cases that cover the method should be filtered out, and step S305 should be executed. Otherwise, it indicates that the method only has deletion or editing lines, and step S307 should be executed.

[0100] Step S307, traverse Set <casecovcode>, filter out the use cases where covedCodes contains delLines and editLines line numbers.

[0101] Preferably, the process of executing the use case executes the use case to be tested generated by the previous process, and generates the code coverage data Set of the use case of the new version (such as V2) code <casecovcode>, which can be used when developing the next version (such as V3). During the execution process, it is necessary to ensure the exclusivity of the test environment to avoid executing multiple use cases at the same time. This process provides a special mechanism to ensure this requirement. In addition, it is necessary to split the execution process of each use case to avoid confusing the code coverage. This process provides a special mechanism to ensure the reliability of automatic decomposition of use cases. See Figure 4 , the process of executing the use case includes the following steps:

[0102] Step S401, prepare to execute the use case, obtain the use case data and execution environment data. After completion, execute step S402.

[0103] Step S402, detect the test environment and try to obtain the exclusive lock of the test environment, which is a device to ensure the exclusivity of the test environment when the use case is executed. If the exclusive lock fails to be obtained, step S403 is executed, and if the exclusive lock fails to be obtained, step S404 is executed.

[0104] Step S403, wait for 1 second, and then execute step S402.

[0105] Step S404, execute the use case. If the use case assertion ends (such as an automated use case) or a user clicks to execute the next / complete test (such as a manual use case), the use case is considered to be completed. At this time, before executing the next use case, it is necessary to collect and calculate the code coverage. This step is a device to ensure the automatic decomposition of the use case. After completion, execute step S405.

[0106] Step S405, export code coverage data from the test environment module. Usually, a coverage probe tool (such as JacocoAgent) is used as a probe when the test environment is running. After sending the export command, the coverage probe tool generates a coverage data file. These files can be parsed to obtain the covered code lines and method conditions. After completion, step S406 and step S407 are executed respectively, and the two can be performed in parallel.

[0107] Step S406: Generate CaseCovCode according to the use case information and code coverage data.

[0108] Step S407, release the test environment lock, and then execute step S408

[0109] Step S408, if there are use cases to be executed, execute step S401, otherwise, execute step S409.

[0110] Step S409, collect the CaseCovCode generated in the previous step and generate Set <casecovcode>.

[0111] The attached table shows the data structure used in this embodiment.

[0112] Table 1 LineDiff data structure

[0113]

[0114] Table 2 MethodDiff data structure

[0115]

[0116] Among them, the MethodDiff data structure describes the code differences between the new code version and its baseline version code.

[0117] Table 3 CovCodeDetail data structure

[0118] file Files covered by the use case method The method name covered by the use case covLines Integer collection. Line numbers covered by the use case.

[0119] Table 4 CaseCovCode data structure

[0120] caseUid Global ID of the use case codeVersion Code version, usually git commit id covedCodes A collection of CovCodeDetail, which indicates the code details covered by this use case.

[0121] Example 2

[0122] Based on Example 1, this example provides a code change testing system based on test case screening, which is used to implement the code change testing method based on test case screening in Example 1. For details, see Figure 5 , the code change testing system includes:

[0123] The statistics and log module records data such as version code comparison and use case screening process, records the memory and other resource consumption during the operation of the device for performance analysis, etc., and records user requests in the log.

[0124] The use case management module is responsible for storing use cases, initiating use case execution, and recording execution results.

[0125] The test environment module is responsible for the supply and management of the test environment, the deployment of coverage probes, the acquisition of code coverage data, and the maintenance of the test environment lock status.

[0126] The code change calculation module is responsible for calling the code comparison tool, generating the change line data structure required by this device, providing a cache function, and storing the calculated data in the cache to speed up the response.

[0127] Use case recommendation module, calculates recommended use cases.

[0128] The process of executing use cases involves two parts: the use case management module and the test environment module. The use case management module stores use cases and initiates test activities, while the test environment module manages the properties of the test environment, such as exclusive lock configuration and exporting code coverage data.

[0129] The present invention has the following characteristics:

[0130] (1) Automatic demarcation of use cases. Ensure that use cases and the code they cover are accurately mapped.

[0131] (2) Exclusive guarantee of the test environment during the execution of the use case. Ensure that the code covered by the use case is not interfered with by other use cases.

[0132] (3) Automatically filter the test cases based on code changes.

[0133] (4) Method renaming is solved through process orchestration.

[0134] Example 3

[0135] This embodiment provides an electronic device, including: one or more processors and a memory, wherein the memory stores one or more programs, and the one or more programs include instructions for executing the code change testing method based on test case screening as in Example 1.

[0136] See also Figure 6 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include other hardware required for the business. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it to achieve the above Figure 1 The code change testing method based on test case screening. Of course, in addition to the software implementation, the present invention does not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0137] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0138] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0139] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.< / casecovcode> < / casecovcode> < / casecovcode> < / casecovcode> < / methoddiff> < / casecovcode> < / methoddiff> < / casecovcode> < / methoddiff> < / methoddiff> < / methoddiff> < / linediff> < / linediff> < / linediff> < / linediff> < / methoddiff> < / linediff> < / casecovcode> < / casecovcode> < / casecovcode> < / methoddiff>

Claims

1. A code change testing method based on test case screening, characterized in that: The steps include: Step S1, obtaining code data of the new version and the baseline version, and calculating the code change data; Step S2, screening the use cases to be tested based on the change data and the use case-coverage code mapping relationship corresponding to the baseline version; Step S3, executing the test case to be tested to obtain a test case-coverage code mapping relationship corresponding to the new version; Step S4, based on the change data and the use case-coverage code mapping relationship between the baseline version and the new version, calculate the coverage data of the changed code to implement code change testing.

2. A code change testing method based on test case screening according to claim 1, characterized in that: Also includes: Step S5, judging whether the coverage data meets a preset coverage rate threshold, if so, executing step S6, if not, executing step S7; Step S6, ending the code change test; Step S7, for the parts not covered by the changed code, prompt manual or AI to supplement the use cases, and perform the next round of testing based on the supplemented use cases.

3. A code change testing method based on test case screening according to claim 1, characterized in that: The step S1 comprises: Step S101, based on the code data of the new version and the baseline version, a comparison tool is used to calculate a data set of changed lines in the code; Step S102, filtering the changed row data set based on a preset filtering string pattern; Step S103, for the filtered changed row data set, obtain structured data of the code data through code lexical syntax analysis, and identify the method to which the changed row belongs; Step S104, traverse the filtered changed row data set, and obtain the change method data through conversion; Step S105, integrating the traversed changed method data as code changed data.

4. A code change testing method based on test case screening according to claim 3, characterized in that: The step S104 includes: Step S1041, obtaining changed row data; Step S1042, based on the change row data, determine whether the change row belongs to a method and the change type is an increase, if so, execute step S1043, if not, execute step S1044; Step S1043, taking all the changed rows in the changed row corresponding method as newly added rows; Step S1044, based on the changed row data, determine whether the changed row belongs to a method and the change type is deletion, if so, execute step S1045, if not, execute step S1046; Step S1045, treating all changed rows in the change row corresponding method as deleted rows; Step S1046, grouping all the change rows under the method corresponding to the change row according to the change type, and integrating them to obtain the change method data.

5. A code change testing method based on test case screening according to claim 3, characterized in that: The step S102 includes: The string pattern is used to match the content of the code line. If the match is successful, the current line is ignored.

6. A code change testing method based on test case screening according to claim 1, characterized in that: The step S2 comprises: Step S201, obtaining the method change data and the use case-coverage code mapping relationship corresponding to the baseline version; Step S202, determine if the change data type of the method is increase, if so, execute step S203, if not, execute step S204; Step S203, ignoring the changed data of the method of adding the type; Step S204, determine if the changed data type of the method is deletion, if so, execute step S205, if not, execute step S206; Step S205, facilitating the use case-coverage code mapping relationship corresponding to the baseline version, and screening use cases containing methods; Step S206, determine whether there is a new row, if yes, execute step S205, if no, execute step S207; Step S207 , based on the use case-coverage code mapping relationship corresponding to the baseline version, filter use cases including deleted rows and modified rows.

7. A code change testing method based on test case screening according to claim 1, characterized in that: The step S3 comprises: Step S301, obtaining a use case to be executed; Step S302, setting an exclusive lock for the test environment, and determining whether the setting is successful, if so, executing step S304, if not, executing step S303; Step S303, executing step S302 after waiting for a preset time; Step S304, executing the use case and calculating the code coverage; Step S305, using the coverage probe to obtain code coverage data, and performing steps S306 and S307 simultaneously or separately; Step S306, generating a mapping relationship between the current use case and the covered code based on the code coverage data and the use case information; Step S307, releasing the exclusive lock of the test environment; Step S308, determine whether there are any unexecuted use cases, if so, execute step S301, if not, execute step S309; Step S309, based on the generated mapping relationship between the use case and the coverage code, a new version of the use case-coverage code mapping relationship is obtained.

8. A code change testing method based on test case screening according to claim 1, characterized in that: The change data includes the file name of the code change, the method name of the code change, the method change type, the newly added code line number set, the deleted code line number set and the modified code line number set.

9. A code change testing method based on test case screening according to claim 1, characterized in that: The use case-covered code mapping relationship includes the global number of the use case, the code version, and a code information set, wherein the code information includes the files covered by the use case, the method names covered by the use case, and the line numbers covered by the use case.

10. A code change testing system based on test case screening, characterized in that: Used to implement the code change testing method based on test case screening according to any one of claims 1 to 9, the code change testing system comprises: Statistics and log module, used to record the process data of version code comparison and use case screening, record the resource consumption during the operation of the device, and record user requests in the log; The use case management module is used to store use cases, initiate use case execution, and record execution results; The test environment module is used to implement the provision and management of the test environment, deploy coverage probes, obtain code coverage data, and maintain the test environment lock status; The code change calculation module is used to call the code comparison tool, generate code change data, and cache the calculated data to speed up the response; Use case recommendation module, used to filter use cases to be tested.

Images