Test method, computer program product, equipment and medium

Abstract

The invention provides a test method, a computer program product, equipment and a medium, and relates to the technical field of computers, the test method comprises the following steps: analyzing target annotation information to determine test decision information according to an analysis result; the target annotation information is a code change description text conforming to a preset format; based on the test decision information and a pre-defined target mapping relationship, screening out a test case subset required to be used in the test process from a test case set to realize batch selection of test cases; the pre-defined target mapping relationship is a mapping relationship between the code change and the test case; triggering test execution of the test case subset on the target test equipment; and after the test execution is finished, generating a test execution result and multi-dimensional coverage rate data, and constructing a corresponding test case optimization strategy based on the test execution result and the multi-dimensional coverage rate data. According to the method and the device, batch efficient selection of the test cases is realized, the test efficiency is effectively improved, and the test time is shortened.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a testing method, computer program product, device and medium. Background Art

[0002] With the rapid development of internet technology, the complexity of software systems is also rapidly increasing. From early monolithic applications to today's microservice architectures and distributed systems, software systems are becoming increasingly large, and the dependencies between modules are becoming extremely complex. Distributed testing largely solves the problem of test execution speed, but it indiscriminately executes all test cases in all situations. This is not only time-consuming and labor-intensive, but also difficult to fully cover all potential issues in practice. For example, in a system containing millions of lines of code, if a full testing approach is adopted, the entire system needs to be tested after each code update. This not only consumes a lot of time and resources, but also test results are often not fed back to the development team in a timely manner, which prolongs the development cycle and thus affects the speed of product release. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a testing method, computer program product, device and medium, which realize the efficient batch selection of test cases, effectively improve test efficiency, shorten test time, and reduce resource consumption. It is particularly suitable for large-scale software systems with complex module dependencies, and solves the disadvantages of full testing being time-consuming and labor-intensive, and having difficulty in fully covering potential problems. The specific solution is as follows: In a first aspect, the present application discloses a testing method, comprising: Obtain target annotation information, parse the target annotation information, and determine test decision information based on the parsing result; wherein the target annotation information is code change description text that conforms to a preset format; Based on the test decision information and pre-defined target mapping relationships, a subset of test cases required for this test process is filtered from the test case set to achieve batch selection of test cases. The pre-defined target mapping relationships are mapping relationships between code changes and test cases. Triggering test execution of a subset of test cases on the target test device; After the test execution is completed, the test execution results and multi-dimensional coverage data are generated, and the corresponding test case optimization strategy is constructed based on the test execution results and multi-dimensional coverage data.

[0004] Optionally, the preset format includes a header component, a body component, and a footer component; wherein the header component is a required option, and the body component and the footer component are both optional options.

[0005] Optionally, the header components include a first identification field value, a second identification field value, and a third identification field value; the first identification field value is used to represent the type of code change, the second identification field value is used to represent the specific module affected by the code change, and the third identification field value is used to summarize the core content of the code change.

[0006] Optionally, the target annotation information is parsed to determine test decision information based on the parsing results, including: Extracting a first identification field value, a second identification field value, and a third identification field value from a header component of the target annotation information; Map the first identification field value to the test type identifier, map the second identification field value to the target module identifier, and map the third identification field value to the core content of the code change; Based on the test type identifier, target module identifier, and the core content of the code changes, test decision information including test case screening rules and test case execution order is generated.

[0007] Optionally, the predefined target mapping relationship is established through a test case management file. The test case management file classifies the test cases in a module name manner, and different module names correspond to different module identifiers.

[0008] Optionally, based on the test decision information and predefined target mapping relationships, a subset of test cases required for this test process is filtered from the test case set to implement batch selection of test cases, including: Obtain target module identification from test decision information; Find the corresponding module name in the test case management file according to the target module identifier; According to the found module name, a subset of test cases required for this test process is filtered out from the test case set to achieve batch selection of test cases.

[0009] Optionally, trigger the execution of a subset of test cases on the target test device, including: According to the trigger mechanism of continuous integration or continuous deployment, the test case subset is sent to the target test device, and the test execution of the test case subset on the target test device is triggered.

[0010] Optionally, the multi-dimensional coverage data includes code structure execution coverage, program logic condition coverage, and program execution path coverage.

[0011] Optionally, build corresponding test case optimization strategies based on test execution results and multi-dimensional coverage data, including: If the test execution results show that there are test cases that have failed, the code structure corresponding to the test cases that have failed is analyzed, and corresponding repair verification test cases are generated; Alternatively, if the code structure execution coverage is lower than a first preset threshold, the code structure corresponding to the uncovered test case is analyzed, and a corresponding repair verification test case is generated.

[0012] Optionally, build corresponding test case optimization strategies based on test execution results and multi-dimensional coverage data, including: If the program logic condition coverage is lower than a second preset threshold, the program logic conditions corresponding to the uncovered test cases are analyzed, and corresponding repair verification test cases are generated.

[0013] Optionally, build corresponding test case optimization strategies based on test execution results and multi-dimensional coverage data, including: If the program execution path coverage is lower than a third preset threshold, the program execution path corresponding to the uncovered test case is analyzed, and a corresponding repair verification test case is generated.

[0014] Optionally, the test method also includes: Mark test cases that repeatedly cover the same code as inefficient test cases; Redundant merging of inefficient test cases.

[0015] In a second aspect, the present application discloses a computer program product, comprising a computer program, which implements the steps of the aforementioned disclosed testing method when executed by a processor.

[0016] In a third aspect, the present application discloses an electronic device, comprising: Memory, used to store computer programs; The processor is used to execute the computer program to implement the aforementioned testing method.

[0017] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the aforementioned disclosed testing method is implemented.

[0018] It can be seen that the present application proposes a testing method, including: obtaining target annotation information, parsing the target annotation information, and determining test decision information based on the parsing results; wherein the target annotation information is a code change description text that conforms to a preset format; based on the test decision information and a predefined target mapping relationship, a subset of test cases required for this test process is screened out from a test case set to achieve batch selection of test cases; wherein the predefined target mapping relationship is a mapping relationship between code changes and test cases; triggering the test execution of the subset of test cases on the target test device; after the test execution is completed, generating test execution results and multi-dimensional coverage data, and constructing a corresponding test case optimization strategy based on the test execution results and multi-dimensional coverage data.

[0019] Beneficial effects: By obtaining and parsing target annotation information that conforms to the preset format to determine the test decision information, and combining the pre-defined mapping relationship between code changes and test cases, it is possible to batch filter out the subset of use cases required for this test from the test case set, changing the traditional full-scale test mode of indiscriminately executing all use cases, avoiding indiscriminate testing of every module and every code in the system, and greatly reducing the number of test cases, thereby achieving efficient batch selection of test cases, effectively improving test efficiency, shortening test time, and reducing resource consumption. It is especially suitable for large-scale software systems with complex module dependencies, and solves the disadvantages of full-scale testing that is time-consuming and labor-intensive and difficult to fully cover potential problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0021] Figure 1 A flow chart of a testing method disclosed in this application; Figure 2 This is a schematic structural diagram of a testing device disclosed in this application; Figure 3 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0022] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only 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 making creative efforts are within the scope of protection of the present invention.

[0023] With the rapid development of internet technology, the complexity of software systems is also rapidly increasing. From early monolithic applications to today's microservice architectures and distributed systems, software systems are becoming increasingly large, and the dependencies between modules are becoming extremely complex. Distributed testing largely solves the problem of test execution speed, but it indiscriminately executes all test cases in all situations. This is not only time-consuming and labor-intensive, but also difficult to fully cover all potential issues in practice. For example, in a system containing millions of lines of code, if a full testing approach is adopted, the entire system needs to be tested after each code update. This not only consumes a lot of time and resources, but also test results are often not fed back to the development team in a timely manner, which prolongs the development cycle and thus affects the speed of product release.

[0024] To this end, the embodiment of the present application proposes a testing solution that realizes efficient batch selection of test cases, effectively improves testing efficiency, shortens testing time, and reduces resource consumption. It is particularly suitable for software systems with large scale and complex module dependencies, and solves the disadvantages of full testing being time-consuming and labor-intensive, and difficult to fully cover potential problems.

[0025] The present application discloses a test method, see Figure 1 As shown, the method includes: Step S11: Obtain target annotation information, parse the target annotation information, and determine test decision information according to the parsing result; the target annotation information is a code modification description text that complies with a preset format.

[0026] In this embodiment, the preset format includes a header component, a body component, and a footer component; the header component is required, while the body component and footer component are optional. The header component includes a first identification field value, a second identification field value, and a third identification field value; the first identification field value is used to indicate the type of code change, the second identification field value is used to indicate the specific module affected by the code change, and the third identification field value is used to summarize the core content of the code change.

[0027] For example, the preset format is as follows: <header> / * blank line * / / * blank line * / <footer>; Header is the header component, body is the main component, and Footer is the footer component.

[0028] For example, the main components are as follows: <type> ( <scope> ):_ <summary>.

[0029] Among them, type is the value of the first identification field, scope is the value of the second identification field, and summary summarizes the core content of the code change.

[0030] For example, feat(read): add new feature read.

[0031] Among them, feat indicates the change of function, read indicates the change of read function module, and add new feature read indicates the core content of code change.

[0032] It's important to note that the body and footer are optional fields that can be used to supplement detailed information not covered in the header, adapting to change scenarios of varying complexity. This structured code change record format combines standardization with flexibility by dividing information into header, body, and footer components. Specifically, the header, as a mandatory field, includes a first identifier field value that indicates the type of code change, a second identifier field value that identifies the affected modules, and a third identifier field value that summarizes the core content, ensuring that each change contains essential key information. For example, in "feat(read): add newfeature read," "feat" specifies the change type as a new feature, "read" identifies the affected modules, and "add new featureread" concisely describes the core content. The body and footer are optional fields that can be supplemented with detailed information based on the complexity of the change, meeting the needs of lightweight documentation for simple changes while providing complete context for complex ones. This format not only improves readability through clear field semantics, allowing developers to quickly understand the nature and scope of the change, but also reduces communication costs during team collaboration through unified standards, making code reviews and historical tracking more efficient.

[0033] In this embodiment, after receiving a new branch submission through Gerrit (an open source code management and review software), Jenkins (an open source continuous integration and continuous delivery deployment tool) is automatically triggered to execute the verification process, and the relevant information of the branch, such as the branch number, branch content, code, and assistant messages, is passed to the Jenkins platform, which then triggers the automatic parsing of the target annotation information.

[0034] In this embodiment, the target annotation information is parsed to determine test decision information based on the parsing results, including: extracting the first identification field value, the second identification field value, and the third identification field value from the header component of the target annotation information; mapping the first identification field value to a test type identifier, mapping the second identification field value to a target module identifier, and mapping the third identification field to the core content of the code change; generating test decision information including test case screening rules and test case execution order based on the test type identifier, the target module identifier, and the core content of the code change.

[0035] For example, when parsing the target annotation information to determine the test decision information, the first identification field value, the second identification field value, and the third identification field value are first extracted from the header component of the target annotation information. <header> feat(read): add new feature read< / header> " as an example, first extract the first identification field value "feat", the second identification field value "read", and the third identification field value "add new feature read" from the header. Then map "feat" to the test type identifier "feature-test" (corresponding to "map the first identification field value to the test type identifier"), map "read" to the target module identifier "read - module" (corresponding to "map the second identification field value to the target module identifier"), and map "add new feature read" to the core content of the code change "new - read -feature" (corresponding to "Map the third identification field to the core content of the code change"); then, based on the test type identifier, target module identifier, and the core content of the code change, the generated filtering rules are: including test cases related to "read-module" and "new-read-feature" (new read functionality), and excluding test cases related to "user-auth-module" and other modules; the execution order is: first execute "unit / read-service.test.js" (reads the service unit test file to verify the basic logic of the service layer in the read function module), then execute "integration / read-api.test.js" (reads the interface integration test file to verify the interaction logic between the read module and external interfaces), and finally execute "e2e / read-flow.test.js" (reads the process end-to-end test file to verify the complete user flow from initiating a read request to obtaining the result).

[0036] In this way, this application provides a clear basis for the subsequent batch screening of the subset of use cases required for this test from the test case set by fully executing the process of parsing the target annotation information header field and generating test decision information according to the instruction mapping, thereby realizing efficient selection and execution planning of test cases.

[0037] Step S12: Based on the test decision information and the predefined target mapping relationship, a subset of test cases required for this test process is screened from the test case set to achieve batch selection of test cases; wherein the predefined target mapping relationship is a mapping relationship between code changes and test cases.

[0038] In this embodiment, the predefined target mapping relationship is established through the test case management file, and the test case management file classifies the test cases in the form of module names, and different module names correspond to different module identifiers. Furthermore, based on the test decision information and the predefined target mapping relationship, a subset of test cases required for this test process is filtered out from the test case set, including: obtaining the target module identifier from the test decision information; searching for the corresponding module name in the test case management file according to the target module identifier; and filtering out a subset of test cases required for this test process from the test case set according to the found module name, so as to realize batch selection of test cases. It should be pointed out that the predefined target mapping relationship is a mapping relationship between code changes and test cases.

[0039] For example, the contents of the test case management file are as follows: #Read Read_01_512RandRead.py Read_02_4kRandRead.py Read_03_512seqRead.py Read_04_4kSeqRead.py Read_05_512RandReadBs.py Read_06_512+8Read.py Read_07_4k+8RandRead.pyf #Write Read_01_512RandRead.py Write_02_4kRandwrite.py Write_03_512segwrite.py Write_04_4ksegwrite.py Write_05_512RandwriteBs.py Write_06_512+8write.py Write_07_4k+8Randwrite.py #Trim Trim_01_512Randtrim.py Trim_02_4kRandtrim.py Trim_03_512segtrim.py Trim_04_4ksegtrim.py Trim_05_512RandtrimBs.py Trim_06_512+8trim.py Trim_07_4k+8Randtrim.py.

[0040] Read (a module used for reading files or data), Write (a module used for writing files or data), and Trim (a module used for data formatting or string trimming) all represent module names. Read_01_512RandRead.py, Read_01_512RandRead.py, and Trim_01_512Randtrim.py are test cases for the corresponding modules.

[0041] For example, if the target module identifier obtained from the test decision information is Read, the following test case is used as a subset of test cases: Read_01_512RandRead.py Read_02_4kRandRead.py Read_03_512seqRead.py Read_04_4kSeqRead.py Read_05_512RandReadBs.py Read_06_512+8Read.py Read_07_4k+8RandRead.pyf.

[0042] For another example, if the target annotation message is: test(WRITE): add 2 write unit test cases Unit test cases: Write_01_512RandWrite.py Write_02_4kRandWrite.py.

[0043] Note: This change involves two unit test case scripts. Write_01_512RandWrite.py and Write_02_4kRandWrite.py are directly obtained from the target annotation information. There is no need to run other scripts.

[0044] By establishing a target mapping relationship through the test case management file and filtering test cases accordingly, the test cases can be standardized and classified with the help of module names, so that different module names correspond to unique module identifiers, forming a clear management structure that is easy to maintain and update. When the module function changes, only the corresponding content in the management file needs to be adjusted, which reduces maintenance costs. During the testing process, the target module identifier can be obtained from the test decision information, and the corresponding module name can be quickly located in the management file. The subset of use cases required for this test can be accurately filtered out to avoid executing test cases of irrelevant modules, greatly reducing the number of test cases and improving testing efficiency. At the same time, this mapping relationship establishes a two-way association between code changes and test cases. When problems occur in the test, the corresponding code changes can be quickly traced back through the module identifier, accelerating problem location.

[0045] Step S13: triggering the test execution of the test case subset on the target test device.

[0046] In this embodiment, according to a trigger mechanism of continuous integration (CI) or continuous deployment (CD), a subset of test cases is delivered to a target test device, and test execution of the subset of test cases on the target test device is triggered.

[0047] Step S14: After the test execution is completed, the test execution results and multi-dimensional coverage data are generated, and a corresponding test case optimization strategy is constructed based on the test execution results and the multi-dimensional coverage data.

[0048] In this embodiment, the multi-dimensional coverage data includes code structure execution coverage (such as function coverage, method coverage), program logic condition coverage (such as branch coverage, statement coverage) and program execution path coverage (such as path coverage). Among them, function coverage is used to measure the execution of functions in the code, and method coverage focuses on the call coverage of class or object methods. Both are coverage indicators at the code structure level; branch coverage is used to count the execution ratio of conditional branches in the program, and statement coverage measures the execution coverage of code statements. Both reflect the coverage of program logic conditions; path coverage is used to evaluate the coverage of different execution paths in the program, and belongs to the coverage indicator at the program execution path level. These multi-dimensional coverage data can comprehensively reflect the test coverage of the code.

[0049] In this embodiment, a corresponding test case optimization strategy is constructed based on the test execution results and multi-dimensional coverage data, which mainly includes the following three aspects: On the one hand, if the test execution results show that there are test cases that failed to execute, the code structure corresponding to the test cases that failed to execute is analyzed, and the corresponding repair verification test cases are generated; or, if the code structure execution coverage is lower than the first preset threshold, the code structure corresponding to the uncovered test cases is analyzed, and the corresponding repair verification test cases are generated.

[0050] For example, if the test execution results show that unit / read-service.test.js (read service unit test file) failed, analysis shows that the readFile() function (read file function) has a logical error when handling the exception path, then unit / read-service-exception-path.test.js (read service exception path unit test file) is generated to specifically verify the code processing logic under the exception path.

[0051] For example, if the coverage of the batchWrite() function (batch write function) of the write-module (write module) only reaches 60% (the first preset threshold is 80%), then integration / batch-write-timeout.test.js (batch write timeout integration test file) is generated to supplement the test cases for the timeout scenario.

[0052] Secondly, if the program logic condition coverage is lower than a second preset threshold, the program logic conditions corresponding to the uncovered test cases are analyzed, and corresponding repair verification test cases are generated.

[0053] For example, if the branch coverage of the dataTrim() function (data trimming function) in the trim-module (trim module) is 75% (the second preset threshold is 90%), then unit / data-trim-special-chars.test.js (data trimming special characters unit test file) is generated to verify the branch logic.

[0054] Thirdly, if the program execution path coverage is lower than a third preset threshold, the program execution path corresponding to the uncovered test case is analyzed, and a corresponding repair verification test case is generated.

[0055] For example, if the path "Account locked → Enter correct password" in the login process of the user-auth-module is not covered and the path coverage rate is 85% (the third preset threshold is 90%), then e2e / auth-locked-account.test.js (account locked end-to-end test file) is generated to simulate the login process under the account locked scenario to cover the missing execution path.

[0056] Furthermore, test cases that repeatedly cover the same code are marked as inefficient and redundantly merged. This effectively identifies and eliminates redundant coverage within test cases, reducing the need for repeated, ineffective testing. For example, when multiple test cases verify the same code logic within the same function, marking them as inefficient and merging their test logic can avoid wasted resources, improve test execution efficiency, ensure effective test coverage, and reduce maintenance costs.

[0057] This application proposes an intelligent testing solution that integrates advanced technologies such as static and dynamic code analysis and impact analysis, aiming to dynamically and accurately execute tests and provide quality assurance for complex systems and agile development environments. This solution captures the system execution path and coverage data at runtime through dynamic code analysis, accurately identifies the triggered code segments to guide the test scope and focus, and monitors the code coverage of test cases in real time to assist test engineers in locking down uncovered high-risk code areas. With the help of intelligent analysis methods, it optimizes the execution of test cases, significantly improves test efficiency and quality, reduces test costs and resource consumption, and achieves improved test efficiency, reduced costs, resource conservation, accelerated feedback, and a leap in test quality, reducing the risk of missed tests and optimizing test resource allocation. In addition, this solution fully supports continuous integration and continuous delivery processes, improves team collaboration efficiency, and is not only suitable for traditional software development scenarios, but also fits modern development models such as agile development and continuous delivery, becoming a key tool for improving the overall effectiveness of software development and testing.

[0058] This application also proposes a related test fixture, which can implement the above-mentioned test method.

[0059] In addition, this application can also design a dynamic scheduling algorithm based on the risk level of code changes. Specifically, test cases are assigned priorities based on dimensions such as module change frequency and historical defect rate. For example, for read-modules with high frequency changes and high risks, their test case execution priority is automatically increased, taking precedence over low-risk modules. At the same time, combined with test execution history data, the execution weight of frequently failed cases is increased to form an adaptive test priority queue. In this way, the efficiency of test resource allocation can be optimized.

[0060] It can be seen that the present application proposes a testing method, including: obtaining target annotation information, parsing the target annotation information, and determining test decision information based on the parsing results; wherein the target annotation information is a code change description text that conforms to a preset format; based on the test decision information and a predefined target mapping relationship, a subset of test cases required for this test process is screened out from a test case set to achieve batch selection of test cases; wherein the predefined target mapping relationship is a mapping relationship between code changes and test cases; triggering the test execution of the subset of test cases on the target test device; after the test execution is completed, generating test execution results and multi-dimensional coverage data, and constructing a corresponding test case optimization strategy based on the test execution results and multi-dimensional coverage data.

[0061] Beneficial effects: By obtaining and parsing target annotation information that conforms to the preset format to determine the test decision information, and combining the pre-defined mapping relationship between code changes and test cases, it is possible to batch filter out the subset of use cases required for this test from the test case set, changing the traditional full-scale test mode of indiscriminately executing all use cases, avoiding indiscriminate testing of every module and every code in the system, and greatly reducing the number of test cases, thereby achieving efficient batch selection of test cases, effectively improving test efficiency, shortening test time, and reducing resource consumption. It is especially suitable for large-scale software systems with complex module dependencies, and solves the disadvantages of full-scale testing that is time-consuming and labor-intensive and difficult to fully cover potential problems.

[0062] Correspondingly, the present application also discloses a testing device, see Figure 2 As shown, the device includes: The annotation parsing module 11 is used to obtain target annotation information, parse the target annotation information, and determine test decision information according to the parsing result; wherein the target annotation information is a code modification description text that complies with a preset format.

[0063] The subset screening module 12 is used to screen out the subset of test cases required for this test process from the test case set based on the test decision information and the pre-defined target mapping relationship, so as to realize batch selection of test cases; wherein the pre-defined target mapping relationship is the mapping relationship between code changes and test cases.

[0064] The test execution module 13 is used to trigger the test execution of a subset of test cases on a target test device.

[0065] The report generation module 14 is used to generate test execution results and multi-dimensional coverage data after the test execution is completed, and to build corresponding test case optimization strategies based on the test execution results and multi-dimensional coverage data.

[0066] Among them, for more specific working processes of the above modules, please refer to the corresponding contents disclosed in the aforementioned embodiments, which will not be repeated here.

[0067] It can be seen that the present application proposes a testing method, including: obtaining target annotation information, parsing the target annotation information, and determining test decision information based on the parsing results; wherein the target annotation information is a code change description text that conforms to a preset format; based on the test decision information and a predefined target mapping relationship, a subset of test cases required for this test process is screened out from a test case set to achieve batch selection of test cases; wherein the predefined target mapping relationship is a mapping relationship between code changes and test cases; triggering the test execution of the subset of test cases on the target test device; after the test execution is completed, generating test execution results and multi-dimensional coverage data, and constructing a corresponding test case optimization strategy based on the test execution results and multi-dimensional coverage data.

[0068] Beneficial effects: By obtaining and parsing target annotation information that conforms to the preset format to determine the test decision information, and combining the pre-defined mapping relationship between code changes and test cases, it is possible to batch filter out the subset of use cases required for this test from the test case set, changing the traditional full-scale test mode of indiscriminately executing all use cases, avoiding indiscriminate testing of every module and every code in the system, and greatly reducing the number of test cases, thereby achieving efficient batch selection of test cases, effectively improving test efficiency, shortening test time, and reducing resource consumption. It is especially suitable for large-scale software systems with complex module dependencies, and solves the disadvantages of full-scale testing that is time-consuming and labor-intensive and difficult to fully cover potential problems.

[0069] Furthermore, an embodiment of the present application also provides an electronic device. Figure 3 The structure diagram of the electronic device 20 is shown according to an exemplary embodiment. The content in the diagram should not be considered as any limitation to the scope of application of the present application.

[0070] Figure 3 The present invention provides a schematic diagram of the structure of an electronic device 20 provided in an embodiment. The electronic device 20 may include: at least one processor 21, at least one memory 22, a display 23, an input / output interface 24, a communication interface 25, a power supply 26, and a communication bus 27. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the test method disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may be a computer.

[0071] In this embodiment, the power supply 26 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 25 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 24 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0072] In addition, the memory 22, as a carrier for storing resources, can be a read-only memory, random access memory, a magnetic disk, or an optical disk, etc. The resources stored thereon can include a computer program 221, which can be stored in a temporary or permanent manner. In addition to including a computer program capable of performing the test method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 221 can further include a computer program capable of performing other specific tasks.

[0073] Furthermore, an embodiment of the present application also discloses a computer program product, including a computer program, which implements the steps of the aforementioned testing method when executed by a processor.

[0074] Furthermore, an embodiment of the present application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the aforementioned disclosed testing method is implemented.

[0075] For the specific steps of this method, please refer to the corresponding contents disclosed in the aforementioned embodiments, which will not be repeated here.

[0076] The various embodiments in this application are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method part.

[0077] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0078] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0079] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprise," "include," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not preclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0080] The above is a detailed introduction to a test method, computer program product, device and medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core ideas. At the same time, for those skilled in the art, according to the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, it can be seen that the content of this specification should not be understood as a limitation on the present application.< / summary> < / scope> < / type> < / footer> < / header>

Claims

1. A testing method, characterized in that: include: Obtain target annotation information, and parse the target annotation information to determine test decision information based on the parsing result; wherein the target annotation information is a code change description text that conforms to a preset format; Based on the test decision information and the predefined target mapping relationship, a subset of test cases required for the current test process is screened from the test case set to achieve batch selection of test cases; wherein the predefined target mapping relationship is a mapping relationship between code changes and test cases; triggering the test execution of the subset of test cases on the target test device; After the test execution is completed, the test execution results and multi-dimensional coverage data are generated, and a corresponding test case optimization strategy is constructed based on the test execution results and the multi-dimensional coverage data.

2. The testing method according to claim 1, wherein: The preset format includes a header component, a body component, and a footer component; wherein the header component is a required option, and the body component and the footer component are both optional options.

3. The testing method according to claim 2, wherein: The header components include a first identification field value, a second identification field value, and a third identification field value; the first identification field value is used to represent the type of code change, the second identification field value is used to represent the specific module affected by the code change, and the third identification field value is used to summarize the core content of the code change.

4. The testing method according to claim 3, wherein: The parsing of the target annotation information to determine the test decision information according to the parsing result includes: Extracting the first identification field value, the second identification field value, and the third identification field value from the header component of the target annotation information; Mapping the first identification field value to a test type identifier, mapping the second identification field value to a target module identifier, and mapping the third identification field to the core content of the code change; The test decision information including test case screening rules and test case execution order is generated according to the test type identifier, the target module identifier and the core content of the code change.

5. The testing method according to claim 4, characterized in that: The predefined target mapping relationship is established through a test case management file. The test case management file classifies test cases in the form of module names, and different module names correspond to different module identifiers.

6. The testing method according to claim 5, characterized in that: The step of screening out a subset of test cases required for the current test process from a test case set based on the test decision information and the predefined target mapping relationship to achieve batch selection of test cases includes: Obtaining the target module identifier from the test decision information; Searching for a corresponding module name in the test case management file according to the target module identifier; According to the found module names, the test case subset required for this test process is filtered out from the test case set to achieve batch selection of test cases.

7. The testing method according to claim 1, wherein: Triggering the test execution of the subset of test cases on the target test device includes: According to a trigger mechanism of continuous integration or continuous deployment, the subset of test cases is sent to the target test device, and the test execution of the subset of test cases on the target test device is triggered.

8. The testing method according to claim 1, wherein: The multi-dimensional coverage data includes code structure execution coverage, program logic condition coverage, and program execution path coverage.

9. The testing method according to claim 8, characterized in that: The constructing a corresponding test case optimization strategy based on the test execution results and the multi-dimensional coverage data includes: If the test execution result shows that there are test cases that failed to execute, then analyze the code structure corresponding to the test cases that failed to execute and generate corresponding repair verification test cases; Alternatively, if the code structure execution coverage is lower than a first preset threshold, the code structure corresponding to the uncovered test case is analyzed, and a corresponding repair verification test case is generated.

10. The testing method according to claim 8, characterized in that: The constructing a corresponding test case optimization strategy based on the test execution results and the multi-dimensional coverage data includes: If the program logic condition coverage is lower than a second preset threshold, the program logic conditions corresponding to the uncovered test cases are analyzed, and corresponding repair verification test cases are generated.

11. The testing method according to claim 8, characterized in that: The constructing a corresponding test case optimization strategy based on the test execution results and the multi-dimensional coverage data includes: If the program execution path coverage is lower than a third preset threshold, the program execution path corresponding to the uncovered test case is analyzed, and a corresponding repair verification test case is generated.

12. The testing method according to claim 8, characterized in that: Also includes: Mark test cases that repeatedly cover the same code as inefficient test cases; Redundancy merging is performed on the inefficient test cases.

13. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the testing method according to any one of claims 1 to 12 are implemented.

14. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the testing method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that Used to store a computer program; wherein, when the computer program is executed by a processor, the testing method according to any one of claims 1 to 12 is implemented.

Images