Application program testing method and device, equipment, storage medium and program product

Abstract

The invention provides an application program testing method and device, equipment, a storage medium and a program product. The method comprises the steps of resetting first coverage rate data of an application program; executing a test task of the application program, and obtaining second coverage rate data of the test task and a data file corresponding to the second coverage rate data of the test task; and resetting the second coverage rate data according to the data file. Through the method and the device, the coverage rate data in the test task of the application program can be efficiently and accurately determined.

Description

Technical Field

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

[0002] When executing the test task of the application, the increase in iteration requirements makes it impossible to accurately locate the code that the test case needs to cover in the test task during the test process. As the number of test cases gradually increases, the data of historical test tasks will confuse the statistics of coverage data during the test case execution process. It is difficult to efficiently and accurately execute the test task for the application in the related technology. Summary of the invention

[0003] The embodiments of the present application provide a method, apparatus, device, storage medium and program product for testing an application program, which can efficiently and accurately determine the coverage data in the test task of the application program.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] The present application provides a method for testing an application program, the method comprising:

[0006] Reset the first coverage data of the application;

[0007] Execute a test task of the application program, and obtain second coverage data of the test task and a data file corresponding to the second coverage data of the test task;

[0008] The second coverage data is reset according to the data file.

[0009] The present application embodiment provides a testing device for an application program, including:

[0010] A first coverage resetting module, used for resetting first coverage data of the application program;

[0011] The second coverage resetting module is used to execute the test task of the application, obtain the second coverage data of the test task and the data file corresponding to the second coverage data of the test task; and reset the second coverage data according to the data file.

[0012] An embodiment of the present application provides an electronic device, the electronic device comprising:

[0013] A memory for storing computer executable instructions or computer programs;

[0014] The processor is used to implement the application program testing method provided in the embodiment of the present application when executing the computer executable instructions or computer program stored in the memory.

[0015] An embodiment of the present application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing a method for testing an application program provided in an embodiment of the present application when executed by a processor.

[0016] An embodiment of the present application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, the test method of the application provided in the embodiment of the present application is implemented.

[0017] The embodiments of the present application have the following beneficial effects:

[0018] By resetting the first coverage data in the application to be tested, the test task of the application is executed after the reset, that is, a separate coverage data reset is performed before the test task starts, thereby improving the accuracy of the subsequent determination of the test case coverage data. In the process of cyclically executing the test task, the second coverage data and the corresponding data file corresponding to the test task are obtained, and the second coverage data is reset based on the information in the data file. Based on the data file, the second coverage data to be reset can be accurately obtained, eliminating interference with the subsequent coverage data determination. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a schematic diagram of an application mode of a test method for an application program provided in an embodiment of the present application;

[0020] Figure 2 It is a schematic diagram of the structure of the server provided in the embodiment of the present application;

[0021] Figure 3A It is a first flow chart of the application program testing method provided in the embodiment of the present application;

[0022] Figure 3B It is a second flow chart of the application program testing method provided in the embodiment of the present application;

[0023] Figure 3C It is a third flow chart of the application program testing method provided in the embodiment of the present application;

[0024] Figure 4 It is a fourth flow chart of the application program testing method provided in the embodiment of the present application;

[0025] Figure 5 is a fifth flow chart of the application program testing method provided in the embodiment of the present application;

[0026] Figure 6 is a sixth flow chart of the application program testing method provided in the embodiment of the present application;

[0027] Figure 7 This is the seventh flow chart of the application program testing method provided in the embodiment of the present application.

[0028] It should be pointed out that the above-mentioned "first" and "second" are only used to distinguish different solutions, and do not represent the degree of superiority or inferiority of the solutions or the priority in the implementation process. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0030] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0031] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0032] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0033] Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meanings as those commonly understood by those skilled in the art. The terms used in the embodiments of the present application are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0034] The relevant data collection and processing (for example, manually written test cases) in the embodiments of this application should be strictly in accordance with the requirements of relevant laws and regulations when applied in examples, and the informed consent or separate consent of the personal information subject should be obtained, and subsequent data use and processing should be carried out within the scope of authorization of laws and regulations and the personal information subject.

[0035] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0036] 1) Code Coverage: It is a key metric in the software testing process, which is used to measure the execution ratio of the code in the tested program when the test case is executed. By evaluating different levels of code coverage, such as line coverage, branch coverage, and function coverage, the comprehensiveness and effectiveness of software testing can be ensured, and untested code areas can be discovered in a timely manner, thereby improving the quality and reliability of the software.

[0037] 2) Java Code Coverage (JaCoCo): is a tool for detecting and analyzing the code coverage of Java applications. As a plug-in of the integrated development environment or a component of the build tool, it can display the code coverage in real time and generate corresponding reports to feedback which code lines and branches in the application are executed by the test cases. It is hereinafter referred to as JaCoCo.

[0038] 3) MeterSphere: It is a one-stop open source continuous testing platform that provides a series of functions to help developers and administrators perform software testing, including: test framework integration, test report visualization, metric analysis, etc.

[0039] 4) Trajectory file: The test case execution trajectory is the execution status of the test case during the test process, including the execution results of the test case, the problems encountered, the time consumed and other information. The trajectory file is used to record this information, usually in the form of text, table or log.

[0040] 5) Webhook: It is a server-side callback mechanism that allows a website to send notifications to the front-end. When a specific event occurs in the back-end system, it sends a Hypertext Transfer Protocol (HTTP) request to a pre-defined Uniform Resource Locator (URL), which is usually the server address of the front-end application. Webhook can be used in a variety of scenarios, such as: integration of social media platforms, real-time updates of applications, email notifications, etc.

[0041] 6) Java-Agent: It is a special Java program that runs as an agent inside the virtual machine of the target Java application. The agent can intercept and modify the creation of Java objects, the calling of methods and properties, so as to monitor, debug or modify the behavior of the application.

[0042] 7) JGit: It is a lightweight pure Java class library that provides a complete set of Git functions, including cloning, pulling, pushing, merging, committing, branch management, tag management, etc. It supports all commands of the Git protocol and provides local and remote operations on Git repositories. It is used to implement access to Git's version control system and provides the core version control algorithm.

[0043] 8) Probe: A tool used to collect and record various information during the test execution process. In the computer field, a probe can be understood as a special test script or code snippet used to capture data, status, events and other information during the test process. Probes can be integrated into test tools or test frameworks to achieve automated test data collection and recording. Through probes, the test team can better understand the behavior and performance of the system under test, discover potential problems and defects, and thus improve the quality and stability of the software.

[0044] 9) Initial label status: The initial label or status assigned to a test case or test object during software testing. These labels or statuses are usually used to identify important attributes of the test case, such as test level, priority, test object type, etc. The initial label status helps testers better organize and manage test cases so that they can better track and identify the progress of testing activities. In some testing tools or frameworks, the initial label status can be used to automatically mark test results to improve testing efficiency and quality.

[0045] 10) Assertion: It is a debugging method in programming languages, which is used to check whether a certain condition is true during the program running process. If the condition is not true, an exception is thrown or some other operation is performed.

[0046] 11) Interface assertion: refers to the assertion in programming that an object or component follows a specific interface. In object-oriented programming, an interface is an abstract type that defines the methods that an object should implement. When an operation is performed on an instance, the interface assertion ensures that the instance does implement all the methods declared in the interface. If this condition is not met, the program may throw an exception or error.

[0047] 12) Data assertion: refers to the process of verifying the correctness of data during software testing, including: checking whether the data value is within the expected range, whether the type is correct, whether the structure conforms to the specification, etc. Data assertion is used to ensure that the data processing logic in the program is correct and that the data remains consistent under specific conditions.

[0048] In the related technology, as the iteration of test requirements increases and the number of test cases increases, the data of historical test tasks will interfere with the execution of test cases. After submitting the test, it is impossible to accurately locate the code that the test cases in the test tasks need to cover. When executing the test tasks in the application to be tested, the accuracy and efficiency of determining the test case coverage data are low.

[0049] Embodiments of the present application provide a method for testing an application, a testing device for an application, an electronic device, a computer-readable storage medium, and a computer program product, which can efficiently and accurately determine coverage data in a test task of an application.

[0050] The following describes an exemplary application of the electronic device provided in the embodiments of the present application. The device provided in the embodiments of the present application can be implemented as various types of terminals such as a laptop computer, a tablet computer, a desktop computer, a set-top box, a smart phone, a smart speaker, a smart watch, a smart TV, and a vehicle-mounted terminal, and can also be implemented as a server. The following describes an exemplary application when the device is implemented as a terminal or a server.

[0051] See also Figure 1 , Figure 1 Schematic diagram of the application mode of the application test method provided in the embodiment of the present application, for implementing a test application supporting an application, for example, Figure 1 The system involves a server 200, a network 300, a terminal device 400 and a database 500. The terminal device 400 is connected to the server 200 via the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0052] In some embodiments, the user is a tester, the server 200 is a server that executes the testing method of the application, the terminal device 400 can be the tester's computer or mobile phone, the terminal device 400 is used to send pre-configuration instructions and configuration information related to the test task, and the database 500 stores data files of test cases and coverage data after parsing the data files.

[0053] For example, the terminal device 400 is used to send pre-configuration instructions and configuration information related to the test task. The server 200 calls the pre-configuration instructions to clean up the coverage data in the application to be tested before executing the test task. The terminal device 400 transmits the pre-configuration instructions and the configuration information related to the test task to the server 200 through the network 300. The server 200 executes the test cases in the application test task, and stores the data files generated by executing the test cases and the parsed coverage data in the database 500. The server 200 determines the test cases for recommendation based on the information in the query database 500, creates a new executable test task, and feeds it back to the terminal device 400 through the network 300.

[0054] In some embodiments, the testing method of the application of the embodiment of the present application can also be applied in the following application scenarios: the test task of the application to be tested, for example: to perform tests on the test cases included in the test tasks in the application. Since the test requirements will increase iteratively, the number of test cases for the application to be tested will also gradually increase, resulting in an increase in the difficulty of the test task. The testing method of the application of the embodiment of the present application can call preconfigured instructions to clean up the coverage data in the application to be tested before executing the test case, and realize independent coverage data cleaning. After the coverage data cleaning is completed, the coverage data of the executed test case is converted and stored as a data file, thereby improving the accuracy of determining the coverage data of subsequent test cases and accurately locating the code that needs to be covered.

[0055] The embodiments of the present application can be implemented through database technology. In short, a database can be regarded as an electronic file cabinet where electronic files are stored. Users can add, query, update, delete, etc. data in the files. The so-called "database" is a collection of data that is stored together in a certain way, can be shared with multiple users, has as little redundancy as possible, and is independent of the application program.

[0056] Database Management System (DBMS) is a large-scale software for manipulating and managing databases. It is used to establish, use and maintain databases. Databases are managed and controlled in a unified manner to ensure the security and integrity of the database. Users access data in the database through the database management system, and database administrators also maintain the database through the database management system. It can support multiple applications and users to establish, modify and query the database in different ways at the same time or at different times. It provides data definition language and data manipulation language for users to define the database model structure and permission constraints, and implement operations such as appending and deleting data.

[0057] The embodiments of the present application can also be implemented through cloud computing, which is a type of distributed computing that decomposes a huge data computing program into countless small programs through the network "cloud", and then processes and analyzes these small programs through a system composed of multiple servers to obtain results and return them to users. Cloud computing is a system with extremely high computing power formed by a computer network, which can store and aggregate related resources and can be configured on demand to provide personalized services to users.

[0058] In some embodiments, the server 200 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. The terminal and the server may be directly or indirectly connected via wired or wireless communication, which is not limited in the embodiments of the present application.

[0059] See also Figure 2 , Figure 2 is a schematic diagram of the structure of the server provided in the embodiment of the present application, Figure 2 The server 200 shown includes: at least one processor 410, a memory 450 and at least one network interface 420. The various components in the server 200 are coupled together via a bus system 440. It is understood that the bus system 440 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 440 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 440 is not described in detail. Figure 2 Various buses are labeled as bus system 440 .

[0060] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0061] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices that are physically remote from the processor 410.

[0062] The memory 450 includes a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 450 described in the embodiments of the present application is intended to include any suitable type of memory.

[0063] In some embodiments, memory 450 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplarily described below.

[0064] Operating system 451, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0065] The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420. Exemplary network interfaces 420 include: Bluetooth, Wireless Authentication (WiFi), and Universal Serial Bus (USB).

[0066] In some embodiments, the device provided in the embodiments of the present application can be implemented in software. Figure 2 The test device 455 of the application program stored in the memory 450 is shown, which can be software in the form of a program and a plug-in, etc., including the following software modules: a first coverage reset module 4551 and a second coverage reset module 4552. These modules are logical, so they can be arbitrarily combined or further split according to the functions implemented. The functions of each module will be explained below.

[0067] In some embodiments, the terminal or server can implement the test method of the application provided in the embodiment of the present application by running various computer executable instructions or computer programs. For example, computer executable instructions can be commands, machine instructions or software instructions at the microprogram level. The computer program can be a native program or software module in the operating system; it can be a local (Native) application (APPlication, APP), that is, a program that needs to be installed in the operating system to run, such as a live broadcast APP or an instant messaging APP; it can also be a small program that can be embedded in any APP, that is, a program that can be run only by downloading it to a browser environment. In short, the above-mentioned computer executable instructions can be instructions in any form, and the above-mentioned computer program can be an application, module or plug-in in any form.

[0068] The testing method of the application provided in the embodiment of the present application will be explained in combination with the exemplary application and implementation of the electronic device provided in the embodiment of the present application.

[0069] The following describes the application testing method provided by the embodiment of the present application. As mentioned above, the electronic device that implements the application testing method of the embodiment of the present application may be a server. Therefore, the execution subject of each step will not be repeatedly described below.

[0070] See also Figure 3A , Figure 3A is a first flow chart of the test method of the application provided in the embodiment of the present application, which will be combined with Figure 3A The steps shown are explained.

[0071] In step 301, first coverage data of an application is reset.

[0072] For example, code coverage is a key metric in the software testing process. It is used to measure the execution ratio of the code in the application when the test case is executed. The coverage data is generated by executing the test case and detecting the actual execution of the tested code. After the test case is executed, the test coverage is analyzed based on a professional code coverage tool. By analyzing the different coverage indicators in the generated coverage report, the execution code that has not been tested is determined. In the process of executing the test, after creating a test task in the application to be tested, the test cases in the test task are executed in a loop. Before starting to execute the test task, the pre-configured instructions are called to reset the first coverage data in the application. Resetting is to clear the coverage data. In an embodiment of the present application, resetting can be to set the first coverage data or the second coverage data to a null value (null), or to set the initial state of the corresponding probe data to false.

[0073] For example, the Java-Agent configuration is added when executing application deployment. The Java-Agent configuration contains pre-configured instructions. The continuous integration deployment automatically binds the application to the Jacoco-Agent.jar package. The Jacoco-Agent.jar package contains pre-configured instructions. JaCoCo is a tool for detecting and analyzing the code coverage of Java applications, as a plug-in for the integrated development environment or a component of the build tool. The Jacoco-Agent.jar package contains the core functions of JaCoCo: tracking class loading and bytecode execution, and generating coverage reports. It supports a variety of different test runners and environments, and provides command-line tools to easily generate and use coverage reports, enabling testers to detect the test coverage of the code.

[0074] After completing the binding with the application, the startup application package information is given through Webhook, and the test tasks are automatically created and the continuously integrated Jacoco-Agent.jar package is obtained and stored in the server. Webhook is a server-side callback mechanism that allows a website to send notifications to the front end.

[0075] In some embodiments, Figure 3A Step 301 in the method can be implemented by: calling a first pre-configuration instruction to determine the address of the application; establishing a remote connection with the application; and calling a second pre-configuration instruction to reset the first coverage data of the application through the remote connection.

[0076] For example, an automated test task is associated, and after obtaining the test task, a pre-configuration instruction is called to perform a reset operation. The first pre-configuration instruction (reset) in the pre-configuration instruction is called to determine the address (IP) of the application to be tested and bind it, connect remotely through the port (socket), and send the second pre-configuration instruction (BLOCK_CMDREST) ​​to the application. Based on the address of the application and the pre-configuration cleanup instruction (BLOCK_CMDREST), the reset method of the second pre-configuration instruction (BLOCK_CMDREST) ​​is triggered to reset the first coverage. The first pre-configuration instruction is an instruction for resetting or initializing a system, application, or test environment, and the second pre-configuration instruction is an instruction for cleaning and resetting relevant data in the test environment, that is, an instruction for resetting the first coverage data.

[0077] For example, the address binding of the application to be tested is implemented through the Jacoco-Agent.jar package. After the application is remotely connected through the port, the second pre-configuration instruction (BLOCK_CMDREST) ​​is sent to the application to be tested. When the remote connection is initialized, the information of the second pre-configuration instruction (BLOCK_CMDREST) ​​is read, and the first coverage data stored in the probe is set to false in a loop, or the first coverage data is set to null (null) to achieve the reset operation of the first coverage data. The probe is a tool for collecting and recording various information during the test execution process, which is used to capture data, status, events and other information during the test process. The coverage data of the application during the test process can be stored in the probe. The initial label state is the initial label or state assigned to the test case or test object, which is used to identify the important attributes of the test case. For example: the state of the probe data is true, indicating that the first coverage data exists in the application. When the pre-configuration instruction is called to perform the reset, the initial state of the reset probe data is false, indicating that the corresponding first coverage data is cleared.

[0078] In some embodiments, see Figure 5 , Figure 5 is a fifth flow chart of the application program testing method provided in the embodiment of the present application; Figure 3A Step 301 in can be Figure 5 The steps in are implemented. After obtaining the test task in step 501, the pre-configured instruction 5031 is called to clean up the first coverage data. After the first coverage data is cleaned up, the test task in the application to be tested is started to be executed, and the execution results of the test case are stored.

[0079] In an embodiment of the present application, before executing the test task in the application to be tested, the preconfigured instructions are called to perform a cleanup and reset operation on the first coverage data, thereby eliminating the interference of the coverage data of the historical test tasks on the execution of subsequent test tasks and improving the accuracy of the test task execution. By configuring the Jacoco-Agent.jar package to implement the preconfigured instructions, it is possible to more conveniently generate and use coverage reports, assist testers in detecting the test coverage of the executed code in the test task, and ensure that all parts of the code are fully tested. As part of the automated testing, the continuous integration process can ensure that newly introduced code changes do not reduce the existing code coverage.

[0080] Continue to see Figure 3A In step 302, the test task of the application is executed to obtain the second coverage data of the test task and the data file corresponding to the second coverage data of the test task.

[0081] For example, after the first coverage data in the application to be tested is reset, the test task of the application is started, multiple test cases in the test task are looped to obtain and execute, the corresponding second coverage data is obtained, and the second coverage data corresponding to the test task is converted into a data file.

[0082] Here, data files are used to characterize the test results of the application.

[0083] For example, call the preconfigured instruction (dump) to extract the second coverage data in the test task, convert the second coverage data into a data file, and the data file includes the execution track information of the test case. Call the preconfigured instruction (dump) in JaCoCo to obtain coverage data, based on the address (IP) bound to the application by the Jacoco-Agent.jar package, remotely connect to the application through the port, and generate a data file storing the test case execution track information based on the obtained second coverage data. The data file contains the class name, class ID and probe information in the test case.

[0084] For example, when testing an online shopping application, the test tasks may be functional testing, security testing, or user experience testing of the online shopping application. The corresponding multiple test cases may be test cases corresponding to the following events: whether the product search is accurate, whether the password retrieval function is normal, whether the test user is stuck during the login process, etc.

[0085] In some embodiments, see Figure 3B , Figure 3B It is a second flow chart of the application program testing method provided in the embodiment of the present application; Figure 3A In step 302, the test task of executing the application program is performed to obtain the second coverage data of the test task, which can be obtained by Figure 3B Steps 3021 to 3023 in are implemented as described in detail below.

[0086] In step 3021, for each test case, a test task is performed on the application based on the test case to obtain a test result of the test case.

[0087] For example, when the test task starts to be executed, the test cases in the test task are obtained cyclically. The test task contains multiple test cases. For each test case, the application to be tested is called to test and the test result of the test case is obtained.

[0088] For example, during the test execution, some code defects may not be tested. High coverage usually means that the test for the application is more comprehensive, while low coverage may indicate that there are test blind spots and further test cases are needed. When the test cases fail to test out the defects in the application, the code coverage can provide a basis for locating the defects, that is, locating the defects of the application from the code data that has not been tested.

[0089] For example, during the execution of a test case, there are success and failure situations. When the execution of a test case fails, the test is repeated for a preconfigured number of times. After repeating the test for the preconfigured number of times, if the execution of the test case still fails, the failure information is stored.

[0090] In step 3022, when the test result of the test case is the preset test result, the proportion of the application code tested during the test process is used as the sub-coverage data of the test case.

[0091] Here, the code tested ratio is the ratio between the code tested by the test cases and the total amount of code in the application.

[0092] For example, when the test result of the test case is a preset test result, the proportion of the application code executed during the test case test, that is, the coverage of the test case for the application, is used as the sub-coverage data corresponding to the test case. In the embodiment of the present application, the preset test result is that the interface assertion and the data assertion are successful, that is, the test result of the test case meets the expected conditions.

[0093] When the test result of the test case is the preset test result, it indicates that the result of the test case at this time meets the expected adjustment, the test case is executed successfully, and the coverage data can be calculated. When an interface assertion performs an operation on an instance, it ensures that the instance actually implements all the methods declared in the interface. If this condition is not met, an exception or error may be thrown. Data assertion is the process of verifying the correctness of data during software testing, including checking whether the data value meets the expected range, whether the type is correct, whether the structure meets the specifications, etc. It is used to ensure that the data processing logic in the program is correct and that the data remains consistent under specific conditions.

[0094] In step 3023, second coverage data corresponding to the test task is composed based on each sub-coverage data.

[0095] For example, a test task involves multiple test cases. When the test results of the test cases are preset test results, the sub-coverage data corresponding to each test case is determined, and the sub-coverage data corresponding to each test case is combined to obtain the second coverage data corresponding to the test task.

[0096] In an embodiment of the present application, a retry operation is performed on the test case that failed to execute. After successful execution, the corresponding execution trajectory information is stored and the second coverage information is cleared to improve the accuracy of determining the coverage of subsequent test cases and avoid interference from historical coverage data. If the execution still fails, the failure information is stored to provide a basis for testers to modify the test cases.

[0097] In step 303, the second coverage data is reset according to the data file.

[0098] For example, a data file storing the execution trajectory of the test case is called, and the pre-configured conversion instruction (dump to case) in the Jacoco-Agent.jar package is called to parse the data file to obtain the parsed second coverage data, the parsed second coverage data is stored in the database, and the original second coverage data corresponding to the parsed second coverage data is reset. The reset operation can be achieved by deleting the original second coverage data.

[0099] In some embodiments, see Figure 6 , Figure 6is a sixth flow chart of the application program testing method provided in the embodiment of the present application; Figure 3A Step 303 in can be Figure 6 The steps in are implemented by calling the coverage collection instruction 6091, that is, calling the pre-configured conversion instruction (dump to case), to parse the data file and store the parsed second coverage data.

[0100] In an embodiment of the present application, by recording and parsing the trajectory information of the executed test case, while obtaining the coverage information of the test case, the code that needs to be covered by the test case in the application submitted for testing is accurately located.

[0101] In some embodiments, when all test cases in the test task of the application are executed, the preconfigured conversion instruction (dump to case) is called to parse the data file corresponding to each test case to obtain the code coverage corresponding to each test case; when the code coverage corresponding to the test case is greater than the code coverage threshold, the mapping relationship between the test case and the code covered by the test case is stored.

[0102] For example, the application periodically obtains the execution results of the test task, and when all test cases are executed, the mapping relationship is determined in the following way: the pre-configured conversion instruction (dump to case) is called to parse the data file corresponding to each test case to obtain the corresponding code coverage, and the mapping relationship between the test case and the covered code is stored according to the relationship between the code coverage and the preset code coverage threshold. The mapping relationship between the test case and the code covered by the test case can be a mapping relationship of one test case corresponding to a line of execution code, or a mapping relationship of multiple test cases corresponding to a line of execution code.

[0103] In some embodiments, before determining the mapping relationship between test cases and the codes covered by the test cases, a code coverage threshold is also obtained in the following manner: determining the total number of code lines of the application; determining the number of execution code lines corresponding to each test case of the application; and taking the ratio between the average number of execution code lines and the total number of code lines as the code coverage threshold.

[0104] For example, when all test cases are executed, the coverage threshold judgment of the executed code lines is added, and the test cases are executed to obtain the average code line execution ratio of all test cases in the test task. The total number of code lines of the application and the number of execution code lines corresponding to each test case are determined, and the ratio between the average number of execution code lines and the total number of code lines is obtained. According to the average ratio, a minimum threshold is obtained as a preset code coverage threshold. When the code coverage corresponding to the test case is greater than the code coverage threshold, the mapping relationship between the test case and the code covered by the test case is stored.

[0105] For example: the preset code coverage threshold is 30%. When the coverage of the set code line is greater than 30%, there is an association between the test case and the execution code. Assuming that the code coverage corresponding to the current test case is 10%, the mapping relationship of the test case cannot be stored; if it is assumed that the code coverage corresponding to the current test case is 70%, the mapping relationship of the test case is stored.

[0106] In some embodiments, see Figure 6 , Figure 6 It is the sixth flow chart of the application testing method provided in the embodiment of the present application; the splicing execution instruction (dump) 6112 and the judgment operation on the mapping relationship between the test case and the code covered by the test case can be implemented through the code line weight judgment module 6111.

[0107] In an embodiment of the present application, the data files of all executed test cases are parsed through pre-configured conversion instructions (dump to case), and the mapping relationship between the test cases and the codes covered by the test cases is determined, providing a basis for subsequent recommendation of test cases according to the mapping relationship.

[0108] In some embodiments, the original created test tasks and the execution results of the test tasks are stored in the automation database, the data files of the test case execution traces and the information of the execution failure are stored in the test platform database, and the mapping relationship between the first coverage data, the parsed second coverage data, the test cases, and the codes covered by the test cases is stored in the coverage database. The above database can be a database with different parts storing corresponding data, or multiple databases can store corresponding data respectively.

[0109] In some embodiments, see Figure 3C , Figure 3C is a third flow chart of the test method for an application provided in an embodiment of the present application; after determining the mapping relationship between the test case and the code covered by the test case, execute Figure 3C Steps 3041 to 3045 in are described in detail below.

[0110] In step 3041 , in case of a version update of the application, a preconfiguration tool is called to determine the difference code data between the first version and the second version of the application.

[0111] Here, the difference code data includes a plurality.

[0112] For example, after the tester submits the requirements for testing, the incremental coverage task is automatically created through continuous integration. When the execution code version in the application is updated, the difference code data between different versions of the execution code is determined based on the pre-configured tool, that is, the difference code data between the first version and the second version of the application is determined. The difference code data includes: modifications to the execution code between different versions, added types of package class methods, and changes.

[0113] For example, the difference code data is obtained through the pre-configured tool JGit-diff. JGit is a lightweight pure Java class library that provides a complete set of Git functions, supports all commands of the Git protocol, and provides access to the version control system and core version control algorithms. JGit-diff is a tool and application programming interface (API) in the JGit library for processing Git repository differences. It compares the differences between different versions by calling JGit's diff method. JGit-diff loops through the information in the database that stores the mapping relationship, and determines the difference code data between the current version of the application and the original version by comparing the obtained package class methods and the corresponding parameters of the methods.

[0114] In step 3042, each difference code data is mapped to the same code as the target code.

[0115] For example, the difference code data is compared with the code in the mapping relationship, and the covered target code is determined based on the same portion of the code in the difference code data and the mapping relationship.

[0116] In step 3043, multiple candidate test cases corresponding to each target code are determined based on the mapping relationship.

[0117] For example, the mapping information stored in the database is queried based on the difference information of the target code, and the candidate test cases corresponding to each segment of the target code are determined based on the mapping relationship. A segment of code may correspond to multiple candidate test cases.

[0118] In step 3044, multiple candidate test cases are deduplicated to obtain target test cases.

[0119] For example, based on the difference code data and mapping relationships, the information in the database storing the mapping relationships is queried cyclically, multiple candidate test cases are deduplicated, and the target test cases stored in the database are determined by comparing the obtained package class methods and the corresponding parameters of the methods.

[0120] In step 3045, a new test task is created according to the target test case.

[0121] For example, according to the determined multiple target test cases, a corresponding target test case list is determined, a new executable test task is automatically created according to the corresponding list, and a test case is recommended to perform the test according to the determined test task.

[0122] In an embodiment of the present application, code version modification information is obtained through a pre-configuration tool to achieve rapid coverage statistics when the code version changes. By deduplicating candidate test cases, the problem of test cases being unable to be reused when iteration requirements and historical test cases increase is solved.

[0123] In the embodiment of the present application, before starting to execute the test task, the first coverage data in the application to be tested is reset by calling the pre-configured instruction, which eliminates the interference of the coverage data of the historical test task on the execution of the subsequent test task, and improves the accuracy of the code coverage determination when the test task is executed. Through the pre-configured instruction, it is more convenient to generate and use the coverage report, assist the tester to detect the test coverage of the execution code in the test task, and ensure the full test of the application execution code. In the process of executing the test, the continuous integration process is introduced to ensure that the newly introduced code changes do not reduce the existing code coverage. The trajectory information of the executed use case is recorded and parsed, and the accurate positioning of the code that the test case needs to cover is realized while obtaining the coverage information. The test cases that have been executed are parsed by pre-configured conversion instructions, and the mapping relationship between the test case and the code covered by the test case is determined, which provides a basis for the recommendation of subsequent test cases. Based on the pre-configured tool, the code version modification information is obtained, and the coverage rate is quickly counted when the code version changes, and the candidate test cases are deduplicated, which solves the problem that the test cases cannot be reused when the iteration requirements and historical test cases increase.

[0124] The following describes an exemplary application of the application program testing method provided in an embodiment of the present application in an actual application scenario.

[0125] Test cases are an important part of software testing. During the application test execution process, the quality of test task execution is judged by measuring the coverage of test cases on requirements and code. Code coverage can assist testers in evaluating test cases. The analysis of coverage by related technologies usually relies on the analysis and interpretation of testers on the obtained reports, and is highly dependent on the code foundation and testing experience of testers, resulting in insufficient testing of test tasks, high time cost of analyzing coverage reports, low testing efficiency, and increased risk of human errors. The continuous iteration and update of business and requirements have also caused changes in code structure and test cases. Related technologies are unable to optimize test cases in a timely and accurate manner, and the accuracy and efficiency of determining coverage data are low.

[0126] The related technology deals with code coverage results. Usually, the obtained code coverage report is manually analyzed after the test is executed, and test cases are supplemented for the code that is not covered or not fully covered. Relying on the code knowledge and experience of the tester, the test of the program code is not sufficient, the manpower cost and time cost are increased, and the code coverage of the test case cannot be determined efficiently and accurately.

[0127] The application testing method provided in the embodiment of the present application performs a cleanup operation on the coverage data in the application to be tested through pre-configured instructions before the test task starts, thereby avoiding the one-sidedness of the code coverage data analysis and solving the interference of the historical test task coverage data on subsequent tasks. The coverage data corresponding to the test task is converted into a data file and stored, so as to realize the accurate positioning of the code covered by the test case in the test task, improve the accuracy of the coverage data determination and improve the test efficiency of the test case execution.

[0128] The following is a description with reference to the accompanying drawings. Figure 4 , Figure 4 4 is a schematic diagram of a fourth flow chart of a method for testing an application program provided in an embodiment of the present application. The execution subject may be a terminal device, a server, or a combination of the two. In the embodiment of the present application, the server is used as the execution subject as an example. Figure 4 The steps shown are explained in detail.

[0129] In step 401, a reset instruction is called to clear the coverage data in the application program to be tested.

[0130] For example, a test task is created on the test platform of the application to be tested, and the corresponding test case is obtained according to the requirements of the test task. Before starting to execute the test task, a preconfigured reset instruction (reset) is called to perform a cleanup operation to clean up the coverage data in the application (equivalent to the first coverage data mentioned above). After the cleanup operation is completed, the test task is started.

[0131] The Java-Agent configuration added when executing application deployment contains pre-configuration instructions (equivalent to the above-mentioned pre-configuration reset instructions). Continuous integration deployment automatically binds the application to the Jacoco-Agent.jar package. JaCoCo is a tool for detecting and analyzing the code coverage of Java applications. As a plug-in for an integrated development environment or a component of a build tool, it can display code coverage in real time and generate corresponding reports. The Jacoco-Agent.jar package contains the core functions of JaCoCo: tracking class loading and bytecode execution to determine which code is executed; generating coverage reports, usually in Hypertext Markup Language (HTML), Extensible Markup Language (XML) or Plain Text File (CSV) format; supporting a variety of different test runners and environments, and providing command line tools to easily generate and use coverage reports. It enables testers to detect the test coverage of the code and ensure that all parts of the code are fully tested. In the continuous integration process, as part of the automatic testing, ensure that the newly introduced code changes do not reduce the existing code coverage.

[0132] After binding with the application, the startup application package information is given through Webhook, and the application coverage task is automatically created and the continuous integration jar package is obtained and stored in the server. Code coverage is a key metric in the software testing process, which is used to measure the execution ratio of the code in the tested program when the test case is executed. Webhook is a server-side callback mechanism that allows a website to send notifications to the front end.

[0133] In some embodiments, see Figure 5 , Figure 5 is a fifth flow chart of the application program testing method provided in the embodiment of the present application, Figure 4 Step 401 in can be Figure 5 The steps in are implemented as follows.

[0134] In step 501, a test task is obtained.

[0135] For example, the virtual test platform 512 in the application to be tested creates a test task, obtains the original test plan 5011 in the continuous testing platform 511 and the full coverage task 5012 of the Super-jacoco module 513, the original test plan 5011 is an automated task that has been created by the continuous testing platform 511, and the full coverage task 5012 is a full task created in advance by each business line in the application to be tested. The virtual test platform is a platform that provides a virtual test environment or a simulation test. In the embodiment of the present application, the test execution is based on the continuous testing platform (MeterSphere), which is a one-stop open source continuous testing platform that provides a series of functions to help developers and administrators perform software testing, including: test framework integration, test report visualization, metric analysis, etc.

[0136] In step 502, a temporary plan is generated based on a single use case under the cyclic test plan.

[0137] For example, after obtaining the test task, the test cases in the test task are executed in a loop, and a temporary test plan is generated based on a single test case. A single test case refers to a basic unit in the test process, which describes a specific test scenario, including input conditions, execution steps, expected results, and actual results. Each test case is independent and is used to verify a specific function or condition. A temporary test plan is a specific execution plan generated after obtaining the test task to execute a single test case. It is a detailed description based on a single test case, including how to set up the test environment, prepare test data, execute test steps, and how to record and analyze test results.

[0138] In step 503, a reset instruction is called to clear the coverage data.

[0139] For example, a reset instruction (reset) 5031 (equivalent to the above-mentioned pre-configured reset instruction) is called, and the coverage data of the application to be tested is cleaned up based on the reset instruction (reset) 5031.

[0140] In the virtual test platform 512, enter the task configuration page, associate the automated test task, and after obtaining the test task, call the reset instruction (reset) 5031 to perform the cleanup operation. Bind to the address on the application through the Jacoco-Agent.jar package in the Jacoco-Agent module 515, connect remotely through the port socket, and send the cleanup operation instruction (BLOCK_CMDREST) ​​to the executing application to clean up the coverage data on the application. The cleanup operation instruction (equivalent to the above-mentioned pre-configured cleanup instruction) is a newly added instruction. The instruction information is read when the socket connection is initialized, and the probe array storing the coverage data is set to false in a loop to achieve the cleaning of the coverage data.

[0141] In step 504, the test task begins to be executed.

[0142] For example, after the coverage data in the application program is cleaned up, the virtual test platform 512 starts to execute the test task.

[0143] By starting to execute the test task in step 504, the test plan is executed in step 505.

[0144] After step 505 is completed, step 506 is executed to store the execution result.

[0145] For example, the execution results obtained by executing the test plan are stored in the automation database 507. After the coverage data is cleaned up, the test task execution module 508 is entered to implement the specific execution process of the test case, and the test case is recommended through the recommendation module 509.

[0146] Continue to see Figure 4 , in step 402, the test task is obtained and executed, and the trace file of the test case is generated and parsed.

[0147] For example, after the coverage data in the application is cleaned up, the test tasks in the test plan are obtained in a loop, and the test cases in the test tasks are executed. When the test case fails to execute, the failed data is stored, the failed test case is repeatedly executed, and after the test case is successfully re-executed, the failed test case data is cleaned up, the pre-configured splicing instructions are called, the coverage data of the application is obtained, and the track file of the test case (equivalent to the above-mentioned data file) is generated. The test case execution track is the execution of the test case during the test process, including the execution results of the test case, the problems encountered, the time consumed, and other information. The track file is a file used to record this information, usually in the form of text, table or log. The track file in the embodiment of the present application includes: class name, probe information and class ID. After storing the track file, the coverage data executed by the current application is cleaned up.

[0148] In step 403, the preconfigured coverage collection instruction is called to parse the trace file, and the parsed coverage data is stored in the coverage database.

[0149] For example, the preconfigured coverage collection instruction (equivalent to the above-mentioned preconfigured conversion instruction dump tocase) is called to parse the trajectory file, and the newly added coverage collection instruction parses the test case ID, trajectory information and other data to obtain the true coverage data of each test case (equivalent to the sub-coverage data of the test case), and stores the parsed coverage data (equivalent to the above-mentioned second coverage data) in the coverage database, that is, the coverage data of each class is associated with the test case ID and the executed test task ID, and the parsed data is stored in the coverage database.

[0150] In step 404, after all test cases are executed, coverage collection instructions are called to parse the test case information and store it in the coverage database.

[0151] For example, the test cases in the test task are acquired and executed cyclically. When all the test cases are executed, the parsing instructions in the test platform are read, and the pre-configured coverage collection instructions (equivalent to the above-mentioned pre-configured conversion instructions dump to case) are called to perform parsing operations on the executed test cases. The code line data of the execution code in the test case obtained by parsing is used to judge the association between the test case and the code covered by the test case. Based on the coverage data weight threshold of the preset value, the coverage data between the test case and the execution code that is greater than the weight threshold is stored in the coverage database. In the case of failure of the parsing operation, the failed parsing status and the reason for the failure are stored.

[0152] For example, the average code line coverage data of the executed code in the test task obtained by executing the test case is obtained, and the lowest threshold is determined as the weight threshold (equivalent to the above code coverage threshold) according to the average coverage value. The test cases with storage coverage data greater than the weight threshold have an association relationship with the execution code (equivalent to the mapping relationship between the above test cases and the code covered by the test cases), and the association information is stored in the coverage database. For example: if the weight range is set to be greater than 30%, then when the coverage data of the execution code line in the test case is greater than 30%, it is considered that there is an association relationship between the test case and the execution code, and the coverage data of the current code line is set to 10%. At this time, the coverage data of the current code line is not within the set weight range, and the 10% code coverage cannot be stored in the coverage database.

[0153] In some embodiments, see Figure 6 , Figure 6is a sixth flow chart of the application program testing method provided in the embodiment of the present application; Figure 4 Steps 402 and 404 in the above example can be accomplished by Figure 6 The steps in are implemented as follows.

[0154] In step 601, after completing coverage data cleaning, the test task begins to be executed.

[0155] For example, in the cleaning module 6011, after the test task is created in the virtual test platform 622, the original test plan 6012 is obtained and stored in the automation database 6031. After the cleaning module 6011 completes the cleaning operation of the coverage data, it starts to execute the test task.

[0156] In step 602, the test plan is executed.

[0157] In step 603, the execution result is stored.

[0158] The principles of steps 602 to 603 are the same as those of steps 502 to 503. The cleaning operation performed by the cleaning module 6011 is the same as that of the above steps. Figure 5 The same cleanup operation is implemented in Figure 6 Automation database 6031 in Figure 5 The same is true for the automation database 507 in , and will not be repeated here.

[0159] In step 604, the execution result is obtained at a fixed time.

[0160] For example, the test platform periodically obtains the execution results of the test cases from the automation database 6031.

[0161] In step 605, it is determined whether all test cases have been executed.

[0162] When the judgment result of step 605 is no, the process returns to step 604 and continues to obtain the execution result at a regular interval.

[0163] When the judgment result of step 605 is no, the judgment of step 606 is also performed. In step 606, it is judged whether the execution fails.

[0164] When the judgment result of step 606 is yes, step 607 is executed. In step 607, the failed test case is retried.

[0165] When the judgment result of step 606 is yes, step 608 is further executed to store the failure data.

[0166] For example, the data of the test cases that failed to execute and the reasons for the failure are stored in the test platform database 6081.

[0167] When the judgment result of step 606 is no, step 609 is executed. In step 609, the execution track of the test case when the execution is successful is obtained.

[0168] For example, after the retry execution of the test case is successful, the execution trace information when the execution is successful is obtained and the corresponding trace file is generated.

[0169] In step 610, the coverage collection instruction is called to parse the trace file.

[0170] For example, the Super-jacoco module 623 and the Jacoco-cli module 624 call the coverage collection instruction (equivalent to the above-mentioned pre-configured conversion instruction dump to case) 6091 to parse the trajectory file, obtain the parsed coverage data, and store the parsed real coverage data in the coverage database 6101. The principle of generating and parsing the trajectory file is the same as step 402 to step 403, which will not be repeated here.

[0171] When the judgment result of step 605 is yes, step 611 is executed. In step 611, the execution trace of all the test cases after execution is completed is obtained.

[0172] For example, when all test cases are executed, the judgment module 6111 based on the weight of the code line judges the weight of the code line in the test case, and calls the splicing execution instruction (dump) 6112 to parse the completed test case. The implementation principle of the parsing is the same as step 403, which will not be repeated here. After the parsing is completed, the recommendation module 6013 can recommend the test case.

[0173] Continue to see Figure 4 In step 405, the pre-configuration tool is called to obtain the execution code changes of the test case, and the coverage database is cyclically queried based on the execution code changes to determine the test case recommended tasks.

[0174] For example, the coverage database stores test cases and execution code data with associated relationships, as well as coverage data after parsing the trace file. After the test is submitted, the tester automatically creates an incremental coverage task through continuous integration, and obtains the changes between different versions of the execution code in the test case based on the pre-configured tool JGit-diff, including comparing code version modifications, and adding types of package class methods and changes. JGit is a lightweight pure Java class library that provides a complete set of Git functions to support all commands of the Git protocol, and provides local and remote operations on Git repositories, implements access to Git's version control system and provides core version control algorithms. JGit-diff is a tool and application programming interface (API) in the JGit library for processing Git repository differences, and compares the differences between different versions by calling JGit's diff method. Based on the changes between the execution codes, the information stored in the coverage database is queried cyclically, and the test case ID stored in the coverage database is obtained through the compared package class methods and the corresponding parameters of the methods. The obtained test case ID is deduplicated, and the corresponding test case ID list is obtained. An executable test task is automatically created through the corresponding list, and test cases are recommended for execution based on the determined test task.

[0175] In some embodiments, see Figure 7 , Figure 7 is a seventh flow chart of the method for testing an application program provided in an embodiment of the present application; Figure 4 Step 405 in Figure 7 The recommendation module 711 in is implemented as described in detail below.

[0176] In step 701, an incremental coverage task is created.

[0177] For example, after the tester submits the test requirements, the test platform automatically creates tasks to increase or decrease coverage, which are used to analyze code changes in different versions and recommend test cases.

[0178] In step 702, delta information is calculated based on the delta configuration tool.

[0179] For example, the incremental information (equivalent to the above-mentioned difference code data) between different versions of the execution code in the test case is calculated based on the incremental configuration tool JGit-diff, including comparing code version modifications, and adding types of package class methods and changes.

[0180] In step 703, the use case information affected by the increment is queried.

[0181] For example, the calculated incremental information is queried in the coverage database 7011 to determine the use case to be recommended.

[0182] In step 704, prompt information of the test case is generated.

[0183] For example, the test platform sends message reminders to the tester based on the message reminder module 7041 according to the use case to be recommended, for example: the progress of the current test execution and the coverage information of the test case.

[0184] In step 705, a test case recommendation report is generated.

[0185] For example, according to the determined information of the use cases to be recommended, after deduplication operation is performed on the test cases to be recommended, a test case recommendation report is generated, and the test tasks are determined according to the test case recommendation report to make use of the use case recommendation.

[0186] The application testing method provided in the embodiment of the present application has the following beneficial effects:

[0187] Call the pre-configuration instruction to clean up the first coverage data in the application to be tested before starting the test task, eliminating the interference of the coverage data of the historical test tasks on the execution of subsequent test tasks, and improving the accuracy of code coverage determination. Record and parse the trajectory information of the executed test cases, and accurately locate the code that the test cases need to cover while obtaining the coverage information. Parse the completed test cases, determine the mapping relationship between the test cases and the code covered by the test cases, and provide a basis for the recommendation of subsequent test cases. Obtain code version modification information based on the pre-configuration tool, realize rapid statistics of coverage when the code version changes, deduplicate candidate test cases, and solve the problem that test cases cannot be reused when there are more iteration requirements and historical test cases.

[0188] The following continues to describe an exemplary structure of the application program testing device 455 provided in the embodiment of the present application implemented as a software module. In some embodiments, Figure 2 As shown, the software modules in the testing device 455 of the application stored in the memory 450 may include: a first coverage reset module 4551, used to reset the first coverage data of the application; a second coverage reset module 4552, used to execute the test task of the application, obtain the second coverage data of the test task and the data file corresponding to the second coverage data of the test task; and reset the second coverage data according to the data file.

[0189] In some embodiments, the first coverage reset module 4551 is further used to call a first pre-configuration instruction to determine the address of the application; establish a remote connection with the application based on the address; and call a second pre-configuration instruction through the remote connection to reset the first coverage data of the application.

[0190] In some embodiments, the second coverage reset module 4552 is also used to perform a test task on the application based on the test case for each test case to obtain a test result of the test case; when the test result of the test case is a preset test result, determine the proportion of the application's code that has been tested, and use the proportion of the code that has been tested as sub-coverage data of the test case, where the proportion of the code that has been tested is the ratio of the code tested by the test case to the total amount of code in the application; and compose the second coverage data corresponding to the test task based on each sub-coverage data.

[0191] In some embodiments, when all test cases in the test task of the application are executed, the second coverage reset module 4552 is also used to call the preconfigured conversion instructions, parse the data file corresponding to each test case, and obtain the code coverage corresponding to each test case; when the code coverage corresponding to the test case is greater than the code coverage threshold, determine the mapping relationship between the test case and the code covered by the test case.

[0192] In some embodiments, before determining the mapping relationship between test cases and the codes covered by the test cases, the second coverage reset module 4552 is also used to determine the total number of code lines of the application; determine the number of execution code lines corresponding to each test case of the application; and use the ratio between the average number of execution code lines and the total number of code lines as the code coverage threshold.

[0193] In some embodiments, after determining the mapping relationship between the test case and the code covered by the test case, the second coverage reset module 4552 is also used to call the pre-configuration tool to determine the difference code data between the first version and the second version of the application when the version of the application is updated, and the difference code data includes multiple; taking each difference code data and the same code in the mapping relationship as the target code; determining multiple candidate test cases corresponding to each target code based on the mapping relationship; deduplicating multiple candidate test cases to obtain target test cases; and creating new test tasks based on the target test cases.

[0194] The embodiment of the present application provides a computer program product, which includes a computer program or a computer executable instruction, and the computer program or the computer executable instruction is stored in a computer-readable storage medium. The processor of the electronic device reads the computer executable instruction from the computer-readable storage medium, and the processor executes the computer executable instruction, so that the electronic device executes the test method of the application program described above in the embodiment of the present application.

[0195] The present application embodiment provides a computer-readable storage medium, in which computer executable instructions or computer programs are stored. When the computer executable instructions or computer programs are executed by a processor, the processor will execute the test method of the application program provided by the present application embodiment, for example, Figure 3A Shown is the testing methodology for the application.

[0196] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

[0197] In some embodiments, computer executable instructions may be in the form of a program, software, software module, script or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0198] As an example, computer-executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions).

[0199] As an example, computer executable instructions may be deployed to be executed on one electronic device, or on multiple electronic devices located at one site, or on multiple electronic devices distributed at multiple sites and interconnected by a communication network.

[0200] In summary, by the testing method of the application provided by the embodiment of the present application, the coverage data is reset before executing the test task, the interference of the historical test task coverage data is eliminated, and the accuracy of determining the coverage data of subsequent test cases is improved. The trajectory information of the executed test case is parsed, and the code that the test case needs to cover is accurately located based on the data file information. The mapping relationship between the test case and the code covered by the test case is determined to provide a basis for the recommendation of subsequent test cases.

[0201] The above is only an embodiment of the present application and is not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A method for testing an application, characterized in that: The method comprises: Reset the first coverage data of the application; Execute a test task of the application program, and obtain second coverage data of the test task and a data file corresponding to the second coverage data of the test task; The second coverage data is reset according to the data file.

2. The method according to claim 1, characterized in that The first coverage data of the reset application program includes: Calling a first pre-configuration instruction to determine the address of the application program; establishing a remote connection with the application based on the address; Through the remote connection, a second preconfiguration instruction is called to reset the first coverage data of the application.

3. The method according to claim 1, characterized in that The executing the test task of the application program and obtaining the second coverage data of the test task includes: For each test case, executing a test task on the application based on the test case to obtain a test result of the test case; When the test result of the test case is a preset test result, determine the tested code ratio of the application program, and use the tested code ratio as sub-coverage data of the test case, wherein the tested code ratio is the ratio between the code tested by the test case and the total code quantity in the application program; The second coverage data corresponding to the test task is composed based on each of the sub-coverage data.

4. The method according to claim 1, characterized in that When all the test cases in the test task of the application are executed, the method further includes: Calling a preconfigured conversion instruction, parsing a data file corresponding to each of the test cases, and obtaining a code coverage rate corresponding to each of the test cases; When the code coverage rate corresponding to the test case is greater than a code coverage rate threshold, a mapping relationship between the test case and the code covered by the test case is determined.

5. The method according to claim 4, characterized in that Before determining the mapping relationship between the test case and the code covered by the test case, the method further includes: Determining the total number of lines of code for the application; Determine the number of execution code lines of the application corresponding to each of the test cases; The ratio between the average number of executed code lines and the total number of code lines is used as the code coverage threshold.

6. The method according to claim 4, characterized in that After determining the mapping relationship between the test case and the code covered by the test case, the method further includes: In case of a version update of the application, calling a preconfiguration tool to determine difference code data between a first version and a second version of the application, the difference code data comprising a plurality of; Taking each of the difference code data and the same code in the mapping relationship as the target code; Determine multiple candidate test cases corresponding to each of the target codes based on the mapping relationship; Deduplication is performed on the plurality of candidate test cases to obtain a target test case; Create a new test task based on the target test case.

7. A testing device for an application, characterized in that: The device comprises: A first coverage resetting module, used for resetting first coverage data of the application program; The second coverage resetting module is used to execute the test task of the application, obtain the second coverage data of the test task and the data file corresponding to the second coverage data of the test task; and reset the second coverage data according to the data file.

8. An electronic device, characterized in that: The electronic device comprises: A memory for storing computer executable instructions or computer programs; A processor, configured to implement the test method for the application program according to any one of claims 1 to 6 when executing the computer executable instructions or computer program stored in the memory.

9. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that: When the computer executable instructions or computer program are executed by a processor, the test method of the application program according to any one of claims 1 to 6 is implemented.

10. A computer program product comprising computer executable instructions or a computer program, characterized in that: When the computer executable instructions or computer program are executed by a processor, the method for testing the application program according to any one of claims 1 to 6 is implemented.

Images