Test case library generation method, device, equipment and storage medium
By executing the stubbing program in the test environment and replaying the recorded traffic, a test case library is generated, which solves the problem of inaccurate testing caused by excessive high-frequency traffic, realizes the filtering of test traffic and the accumulation of low-frequency traffic, and improves the accuracy of program testing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- TENCENT TECHNOLOGY (SHENZHEN) CO LTD
- Filing Date
- 2020-10-09
- Publication Date
- 2026-06-23
AI Technical Summary
In existing technologies, the test traffic obtained through traffic replay contains too much high-frequency traffic and too little low-frequency traffic, resulting in inaccurate program testing.
By acquiring the recorded traffic and stubbed program of the test program, executing the stubbed program and replaying the recorded traffic, a test case library is generated, low-frequency traffic is filtered and accumulated, and excess high-frequency traffic is discarded.
It improves the accuracy of program testing by filtering and accumulating low-frequency traffic, thereby enhancing the comprehensiveness and accuracy of the tests.
Smart Images
Figure CN114328171B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer and program testing technology, and in particular to a method, apparatus, device and storage medium for generating a test case library. Background Technology
[0002] During the development and maintenance of programs, it is often necessary to test the programs.
[0003] In related technologies, test programs are executed in a test environment by recording traffic and then replaying the traffic. The test traffic obtained from the traffic replay is then analyzed to obtain test results. Among them, the test traffic with a large quantity obtained through traffic replay is called high-frequency traffic, and the test traffic with a small quantity is called low-frequency traffic.
[0004] In the aforementioned related technologies, since the test traffic obtained from traffic playback is analyzed directly, there is too much high-frequency traffic and too little low-frequency traffic in the test traffic to be analyzed, so that a sufficient amount of low-frequency traffic cannot be obtained to test the test program, resulting in inaccurate program testing. Summary of the Invention
[0005] This application provides a method, apparatus, device, and storage medium for generating a test case library, which can improve the accuracy of program testing. The technical solution is as follows:
[0006] According to one aspect of the embodiments of this application, a method for generating a test case library is provided, the method comprising:
[0007] Acquire multiple recorded traffic data from the first version of the test program, as well as the post-stubbing program from the second version of the test program. The post-stubbing program is used to acquire the program modules triggered during traffic playback and their triggering order.
[0008] Execute the piling program in the test environment and replay the recorded traffic to obtain the test traffic corresponding to the recorded traffic, as well as the program modules and triggering order triggered by the test traffic;
[0009] A test case library is generated based on the program modules and triggering order of the test traffic, and the test case library is used to test the test program.
[0010] According to one aspect of the embodiments of this application, a test case library generation apparatus is provided, the apparatus comprising:
[0011] The first acquisition module is used to acquire multiple recorded traffics of the first version of the test program and the post-stubbing program of the second version of the test program. The post-stubbing program is used to acquire the program modules triggered during the traffic playback process and the triggering order.
[0012] The traffic replay module is used to execute the piling program in the test environment and replay the recorded traffic to obtain the test traffic corresponding to the recorded traffic, as well as the program module and triggering order triggered by the test traffic.
[0013] The test case library generation module is used to generate a test case library based on the program modules triggered by the test traffic and the triggering order. The test case library is used to test the test program.
[0014] In some embodiments, the post-pile program includes multiple program modules and pile points corresponding to each program module; the flow playback module is used for:
[0015] The step of executing the staking program in the test environment and replaying the recorded traffic to obtain the test traffic corresponding to the recorded traffic, as well as the program modules and triggering order triggered by the test traffic, includes:
[0016] Based on the program modules and triggering order of the test traffic, generate the execution stub sequence corresponding to the test traffic;
[0017] The execution stub sequence includes multiple stubs arranged in sequence, and the execution stub sequence is used to indicate the program module triggered by the test traffic and the triggering order.
[0018] In some embodiments, the use case library generation module is configured to:
[0019] The test traffic is classified according to the corresponding execution stub sequence to obtain at least one type of test traffic, and the execution stub sequence corresponding to the same type of test traffic is the same.
[0020] For the same type of test traffic, if the number of test traffic exceeds the threshold, the test traffic exceeding the threshold will be discarded, and the test traffic exceeding the threshold will be retained in the test case library.
[0021] For the same type of test traffic, if the number of test traffic is less than the threshold number, then the test traffic less than the threshold number is retained in the test case library.
[0022] In some embodiments, the apparatus further includes: a sequence determination module and a sequence alignment module;
[0023] The sequence determination module is used to determine the sequence of execution pile points to be triggered in the post-pile driving program based on the post-pile driving program.
[0024] The sequence comparison module is used to compare the triggered execution stub sequences with the execution stub sequences to be triggered, and to determine the execution stub sequences to be triggered that have not yet been triggered.
[0025] The traffic replay module is also used to continue executing the post-pile program and replay the recorded traffic in the test environment until the sequence of execution pile points to be triggered has been triggered at least n times, where n is a positive integer.
[0026] In some embodiments, the first acquisition module includes: a stub point determination submodule and a code insertion submodule;
[0027] The pile point determination submodule is used to determine the pile points in the second version of the test program;
[0028] The code insertion submodule is used to insert monitoring code at the staking point to obtain the post-staking program. The monitoring code is used to monitor the program module and triggering order triggered by the test traffic.
[0029] In some embodiments, the pile point determination submodule is used for:
[0030] Scan the source code of the second version of the test program to obtain its logical structure;
[0031] Based on the logical structure of the source code of the second version of the test program, the identifier of the stake points and the order of the stake points are determined.
[0032] In some embodiments, the code insertion submodule is used for:
[0033] The monitoring code is inserted into the stubs of the source code of the second version of the test program to obtain the source code after stubbing;
[0034] The source code after piling is compiled to obtain the piling program.
[0035] In some embodiments, the second version of the test program is the same version of the first version of the test program; or, the second version of the test program is a program obtained by modifying the first version of the test program.
[0036] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, the at least one program, the code set or instruction set being loaded and executed by the processor to implement the above-described method for generating a test case library.
[0037] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein at least one instruction, at least one program, code set, or instruction set is stored in the computer-readable storage medium, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the above-described method for generating a test case library.
[0038] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the above-described method for generating a test case library.
[0039] The technical solutions provided in this application embodiment may have the following beneficial effects:
[0040] By executing the stubbing program in the test environment and replaying the recorded traffic, and generating a test case library based on the obtained test traffic, the traffic replay technology and stubbing technology are combined to filter the test traffic. This allows for the discarding of redundant high-frequency traffic in the test traffic, while low-frequency traffic is accumulated through multiple traffic replays, thereby improving the accuracy of program testing.
[0041] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description
[0042] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0043] Figure 1 This is a flowchart of a method for generating a test case library according to an embodiment of this application;
[0044] Figure 2 This is a flowchart of a method for generating a test case library provided in another embodiment of this application;
[0045] Figure 3 This is a flowchart of a method for generating a test case library provided in another embodiment of this application;
[0046] Figure 4 This is a flowchart of a method for generating a test case library provided in another embodiment of this application;
[0047] Figure 5 This is a schematic diagram of the logical structure of a post-pile program provided in one embodiment of this application;
[0048] Figure 6 This is a block diagram of a test case library generation apparatus provided in one embodiment of this application;
[0049] Figure 7 This is a block diagram of a test case library generation apparatus provided in another embodiment of this application;
[0050] Figure 8 This is a block diagram of a computer device provided in one embodiment of this application. Detailed Implementation
[0051] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of methods consistent with some aspects of this application as detailed in the appended claims.
[0052] First, a brief introduction to the terms used in the embodiments of this application:
[0053] 1. Stubbing: By scanning the program's source code, the logical branches of the program are identified, and stubs are set in the program. After stubbing, the program can record the statements triggered during its execution, i.e., the triggering order.
[0054] 2. Traffic replay: A testing technique that involves recording traffic in one environment and then replaying that traffic in another environment. By analyzing the traffic replay results (such as test traffic), vulnerabilities in a program can be identified or the program's performance can be determined.
[0055] The method provided in this application can be executed by a computer device, which refers to an electronic device with data computing, processing, and storage capabilities. This computer device can be a terminal such as a PC (Personal Computer), tablet computer, smartphone, wearable device, or intelligent robot; or it can be a server. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.
[0056] The technical solution of this application will be described and illustrated below through several embodiments.
[0057] Please refer to Figure 1This document illustrates a flowchart of a method for generating a test case library according to an embodiment of this application. In this embodiment, the method is illustrated by applying it to the computer device described above. The method may include the following steps (101-103):
[0058] Step 101: Obtain multiple recorded traffic data from the first version of the test program, as well as the post-study program data from the second version of the test program.
[0059] The post-piping program is used to obtain the program modules triggered and their triggering order during traffic replay. In some embodiments, the test program is a program used for testing, and the recorded traffic is traffic recorded in a real business scenario using a first version of the test program. Optionally, the test program can be an application, such as a social application, video application, music application, game application, antivirus application, reading application, etc.
[0060] In some embodiments, the second version of the test program is the same version as the first version of the test program; in other embodiments, the second version of the test program is a program obtained by modifying the first version of the test program.
[0061] In some instances, the test program is an application, such as a social networking application, email application, game application, video application, music application, lifestyle service application, payment application, news application, shopping application, and so on. In other embodiments, the test program is a portal website. Optionally, the target portal website includes: game website, social networking website, shopping website, payment website, video website, music website, news website, and so on.
[0062] Step 102: Execute the stubbing program in the test environment and replay the recorded traffic to obtain the test traffic corresponding to the recorded traffic, as well as the program modules and triggering order triggered by the test traffic.
[0063] The test environment refers to the environment in which the stubbing program executes, such as the device on which the stubbing program resides, the devices that interact with the stubbing program, and the network environment in which the stubbing program resides. The stubbing program comprises multiple program modules, which can be used to process various data and / or program logic to achieve various program functions. Optionally, a program module can be a single program statement or a program processing unit composed of multiple program statements. In this step, by executing the stubbing program in the test environment and replaying the recorded traffic, the test traffic generated by the stubbing program, the triggered program modules, and the order in which the program modules are triggered can be obtained. In some examples, the test traffic and the corresponding recorded traffic can be the same; in other examples, due to differences in the test environment and / or the program version of the test program, the program modules triggered by the test traffic or the triggering order can be different, i.e., the test traffic and the corresponding recorded traffic can be different.
[0064] Step 103: Generate a test case library based on the program modules triggered by the test traffic and the triggering order.
[0065] The test case library is used to test the test program. It stores multiple sets of test traffic, each set constituting a test case. Based on the program modules triggered by the test traffic and the triggering order, the test traffic is organized and categorized, then filtered. The filtered test traffic is stored in the test case library, thus generating the test case library.
[0066] In summary, the technical solution provided in this application combines traffic replay and stubbing techniques by executing a stubbing program in a test environment, replaying and recording traffic, and generating a test case library based on the obtained test traffic. This allows for the filtering of test traffic, discarding redundant high-frequency traffic, and accumulating low-frequency traffic through multiple traffic replays, thereby improving the accuracy of program testing.
[0067] Please refer to Figure 2 This document illustrates a flowchart of a method for generating a test case library according to an embodiment of this application. In this embodiment, the method is illustrated by applying it to the computer device described above. The method may include the following steps (201-205):
[0068] Step 201: Obtain multiple recorded traffic data from the first version of the test program, as well as the post-study program data from the second version of the test program.
[0069] The details of step 201 can be found in the text above. Figure 1 Step 101 of the embodiment will not be repeated here.
[0070] In some embodiments, step 201 further includes the following sub-steps (2011-2012):
[0071] Step 2011: Determine the stubs in the second version of the test program.
[0072] By analyzing the information and structure of the second version of the test program, the stubs in the second version of the test program can be identified.
[0073] Optionally, this step 2011 also includes the following sub-steps:
[0074] 1. Scan the source code of the second version of the test program to obtain its logical structure;
[0075] 2. Based on the logical structure of the source code of the second version of the test program, determine the identifier and order of the stubs.
[0076] Source code (also known as source program) refers to an uncompiled text file written according to a specific programming language specification; source code is human-readable text. By acquiring and scanning the source code of the second version of the test program, the logical structure of the source code can be obtained. Based on the logical structure of the source code of the second version of the test program, the location of the stubs and related information such as stub identifiers and stub order can be determined. Optionally, the information related to the stubs also includes the variable values corresponding to the stubs.
[0077] Optionally, the stubs are located on some or all logical branches of the source code of the second version of the test program. In some embodiments, depending on the location of the stub, the corresponding covered test traffic includes: function coverage, statement coverage, decision coverage, condition coverage, condition / decision coverage, multiple condition coverage, and path coverage.
[0078] Step 2012: Insert monitoring code at the pile point to obtain the post-pile driving program.
[0079] After determining the stubs, monitoring code can be inserted at the stubs to stub the second version of the test program, resulting in a stubbed program. The monitoring code is used to monitor the program modules triggered by test traffic and the triggering order. The monitoring codes for each stub can be the same or different; this embodiment does not limit this.
[0080] Optionally, this step 2012 also includes the following sub-steps:
[0081] 1. Insert monitoring code into the stubs of the source code of the second version of the test program to obtain the source code after stubbed.
[0082] 2. Compile the source code after piling to obtain the piling program.
[0083] Compilation is the process of translating human-readable text into binary instructions that a computer can execute. This process can be accomplished by a compiler. Monitoring code is inserted into the stubs of the source code in the second version of the test program, and the stubbed source code is compiled into computer-executable instructions, thus obtaining the stubbed program.
[0084] The second version of the test program can automate the piling process, thereby saving time and labor costs and improving piling efficiency.
[0085] Step 202: Generate the execution stub sequence corresponding to the test traffic based on the program module triggered by the test traffic and the triggering order.
[0086] The post-stubbing program includes multiple program modules and corresponding stubbing points for each module. The execution stubbing sequence consists of multiple sequentially arranged stubbing points, used to indicate the program modules triggered by the test traffic and their triggering order. During traffic replay, the program modules and triggering order triggered by the test traffic are obtained, allowing the determination of the stubbing points traversed by the test traffic and their order, thus enabling the generation of the execution stubbing sequence corresponding to the test traffic.
[0087] Step 203: Classify the test traffic according to the corresponding execution stub sequence to obtain at least one type of test traffic. Test traffic of the same type corresponds to the same execution stub sequence.
[0088] In some embodiments, test traffic with the same execution piling sequence is divided into the same type of test traffic, thereby obtaining at least one type of test traffic.
[0089] Step 204: For the same type of test traffic, if the number of test traffic exceeds the threshold, the test traffic exceeding the threshold will be discarded, and the test traffic exceeding the threshold will be retained in the test case library.
[0090] In some embodiments, if the number of test traffic of the same type exceeds a threshold, it indicates that there is too much test traffic of that type, and it can be considered high-frequency traffic. During program testing, the test results corresponding to test traffic exceeding the threshold are not significantly different from those corresponding to test traffic within the threshold; instead, they increase testing costs and lead to waste. Therefore, in this embodiment, test traffic exceeding the threshold is discarded, while test traffic within the threshold is retained in the test case library. This ensures that the number of test traffic of that type in the test case library is neither too high nor too low, saving storage resources and testing costs.
[0091] Step 205: For the same type of test traffic, if the number of test traffic is less than the threshold number, then the test traffic with a number less than the threshold number is retained in the test case library.
[0092] In some embodiments, for the same type of test traffic, if the number of test traffic is less than a threshold value, but the existence of this type of test traffic is sufficient to obtain relatively accurate program test results, then the test traffic less than the threshold value can be retained in the test case library, without needing to acquire new test traffic. In other embodiments, for the same type of test traffic, if the number of test traffic is less than a threshold value, then traffic replay continues until the number of test traffic of the same type reaches the threshold value.
[0093] In the above steps 204 and 205, the threshold values can be 1, 2, 3, 4, 5, 6... The specific values of the threshold values shall be set by relevant technical personnel according to the actual situation, and this application embodiment does not limit them.
[0094] It should be noted that the execution order of steps 204 and 205 is not limited in the embodiments of this application. Step 204 can be executed first and then step 205; or step 205 can be executed first and then step 204; or steps 204 and 205 can be executed simultaneously; or only step 204 or only step 205 can be executed.
[0095] In some embodiments, the method provided in this application further includes the following steps:
[0096] 1. Based on the post-pile driving program, determine the sequence of execution pile points to be triggered in the post-pile driving program;
[0097] 2. Compare the triggered execution stub sequences with the execution stub sequences to be triggered, and determine the execution stub sequences to be triggered that have not yet been triggered.
[0098] 3. Continue executing the post-staking program in the test environment and replay the recorded traffic until all the execution staking sequence to be triggered has been triggered at least n times, where n is a positive integer.
[0099] Based on the distribution of stubs in the post-stubling program and the program test content, the sequence of execution stubs to be triggered in the post-stubling program can be determined, i.e., the sequence of execution stubs to be triggered. By comparing the already triggered sequence of execution stubs with the sequence of execution stubs to be triggered, it can be determined which execution stub sequences have been triggered and which have not yet been triggered. If there are still untriggered execution stub sequences, the post-stubling program continues to be executed in the test environment and the recorded traffic is replayed until all the execution stub sequences to be triggered have been triggered at least n times. By identifying the execution stub sequences that have not yet been triggered and continuing to replay the traffic, it is ensured that all the execution stub sequences to be triggered can be triggered, thereby improving the comprehensiveness and accuracy of the program test. Here, n can be 1, 2, 3..., and the specific value of n is set by relevant technical personnel according to the actual situation. This application embodiment does not limit this.
[0100] In some embodiments, the execution stub sequence to be triggered is all stub execution sequences that can be formed by the aforementioned stubs. The execution stub sequence to be triggered can also be an execution stub sequence set by relevant technical personnel according to actual conditions. In other embodiments, if there are still untriggered execution stub sequences after k traffic replays, then traffic replay is stopped, where k is a positive integer. Specifically, k can be 30, 50, 100, 300… The specific value of k is set by relevant technical personnel according to actual conditions, and this application embodiment does not limit this.
[0101] In summary, the technical solution provided in this application identifies which execution stub sequences have been triggered and which have not yet been triggered. If there are still untriggered execution stub sequences, the program continues to be executed in the test environment and the recorded traffic is replayed until all pending execution stub sequences are triggered. This ensures that all pending execution stub sequences can be triggered, thereby improving the comprehensiveness and accuracy of program testing.
[0102] In some embodiments, such as Figure 3As shown, the test case library generation system includes a source code version control cluster 31, an automatic stubbing service cluster 32, a traffic data service cluster 33, a test service cluster 34, and a test case library generation cluster 35. Specifically, the source code version control cluster 31 is used to generate and control the version of the test program; the automatic stubbing service cluster 32 is used to automatically stub the second version of the test program to obtain the stubbled program; the stubbled program is deployed in the test service cluster 34, which is used to replay the recorded traffic in the traffic data service cluster 33 to obtain test traffic; and the test case library generation cluster 35 is used to filter the test traffic and then automatically generate the test case library. Optionally, the test traffic in the test case library is sent to the traffic data service cluster 33, and the test traffic is used as recorded traffic for further traffic replay.
[0103] In some embodiments, such as Figure 4 As shown, the method for generating a test case library provided in this application includes the following steps (401-405):
[0104] Step 401: Modify the source code of the first version of the test program to obtain the second version of the test program;
[0105] Step 402: Pitting the second version of the test program to obtain the pitting program;
[0106] Step 403: Deploy the piling-up program in the test environment;
[0107] Step 404: Perform a test. Execute the piling program in the test environment and replay the recorded traffic to obtain the test traffic and the corresponding execution piling sequence.
[0108] Step 405: Generate a test case library based on the execution stub sequence corresponding to the test traffic.
[0109] Please refer to Figure 5 This illustrates a schematic diagram of the logical structure of a post-piling program provided in one embodiment of this application. Figure 5 As shown, the first-level logic structure of this test program includes processing logic 1, the second-level logic structure includes judgment logic A, the third-level logic structure includes processing logic 2-1, processing logic 2-2, processing logic 2-3, and processing logic 2-4, the fourth-level logic structure includes judgment logic B, and the fifth-level processing logic includes processing logic 3-1, processing logic 3-2, and processing logic 3-3. Stubs are set in each processing logic, namely stub 1, stub 2-1, stub 2-2, stub 2-3, stub 2-4, stub 3-1, stub 3-2, and stub 3-3. The execution stub sequence in this test program includes:
[0110] (1) Stake 1, Stake 2-1, end;
[0111] (2) Stake 1, Stake 2-2, end;
[0112] (3) Stake 1, Stake 2-3, Stake 3-1, end;
[0113] (4) Stake 1, Stake 2-3, Stake 3-2, end;
[0114] (5) Stake 1, Stake 2-3, Stake 3-3, end;
[0115] (6) Stake 1, Stake 2-4, end.
[0116] In one example, if the threshold for the number of test traffic of each type is set to 1, then:
[0117] For test traffic A, its execution stub sequence is: stub 1, stub 2-1, end; since the number of test traffic corresponding to this execution stub sequence in the test case library is 0 at this time, which is less than the threshold value 1, test traffic A is stored in the test case library;
[0118] For test traffic B, its execution stub sequence is: stub 1, stub 2-1, end; since this type of test traffic already exists in the test case library, that is, this type of test traffic has reached the threshold, test traffic B is discarded.
[0119] For test traffic C, its execution stub sequence is: stub 1, stub 2-3, stub 3-1, end; since this type of test traffic does not exist in the test case library, that is, this type of test traffic has not reached the threshold value, test traffic C is stored in the test case library.
[0120] In another example, the threshold for the number of test traffic for each type is set to 3. For the above 6 execution stub sequences (1), (2), (3), (4), (5), and (6), the number of test traffic already obtained are 16, 13, 23, 0, 9, and 6, respectively. Then, traffic replay continues for this test program until the number of test traffic corresponding to execution stub sequence (4) also reaches the threshold of 3. After that, the test traffic exceeding 3 groups from the test traffic corresponding to each of these 6 execution stub sequences is discarded. That is, for the test traffic corresponding to each stub execution sequence, only 3 groups of test traffic are retained in the test case library. Alternatively, when the number of test traffic corresponding to the execution stub sequence (1), (2), (3), (5), (6) in the test case library reaches the threshold value 3, and the number of test traffic corresponding to the execution stub sequence (4) in the test case library is 0, all subsequent test traffic corresponding to the execution stub sequence (1), (2), (3), (5), (6) is discarded and no longer retained in the test case library; traffic replay continues until the number of test traffic for the execution stub sequence (4) in the test case library reaches the threshold value 3.
[0121] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.
[0122] Please refer to Figure 6 This diagram illustrates a block diagram of a test case library generation apparatus according to an embodiment of this application. The apparatus has the functionality to implement the above-described test case library generation method example; this functionality can be implemented in hardware or by hardware executing corresponding software. The apparatus can be the computer device described above, or it can be mounted on a computer device. The apparatus 600 may include: a first acquisition module 610, a traffic playback module 620, and a test case library generation module 630.
[0123] The first acquisition module 610 is used to acquire multiple recorded traffic from the first version of the test program and the post-stubbing program of the second version of the test program. The post-stubbing program is used to acquire the program modules triggered during the traffic playback process and the triggering order.
[0124] The traffic playback module 620 is used to execute the piling program in the test environment and play back the recorded traffic to obtain the test traffic corresponding to the recorded traffic, as well as the program module and triggering order triggered by the test traffic.
[0125] The test case library generation module 630 is used to generate a test case library based on the program modules triggered by the test traffic and the triggering order. The test case library is used to test the test program.
[0126] In summary, the technical solution provided in this application combines traffic replay and stubbing techniques by executing a stubbing program in a test environment, replaying and recording traffic, and generating a test case library based on the obtained test traffic. This allows for the filtering of test traffic, discarding redundant high-frequency traffic, and accumulating low-frequency traffic through multiple traffic replays, thereby improving the accuracy of program testing.
[0127] In some embodiments, the post-pile program includes multiple program modules and pile points corresponding to each program module; the flow playback module 620 is used for:
[0128] The step of executing the staking program in the test environment and replaying the recorded traffic to obtain the test traffic corresponding to the recorded traffic, as well as the program modules and triggering order triggered by the test traffic, includes:
[0129] Based on the program modules and triggering order of the test traffic, generate the execution stub sequence corresponding to the test traffic;
[0130] The execution stub sequence includes multiple stubs arranged in sequence, and the execution stub sequence is used to indicate the program module triggered by the test traffic and the triggering order.
[0131] In some embodiments, the use case library generation module 630 is configured to:
[0132] The test traffic is classified according to the corresponding execution stub sequence to obtain at least one type of test traffic, and the execution stub sequence corresponding to the same type of test traffic is the same.
[0133] For the same type of test traffic, if the number of test traffic exceeds the threshold, the test traffic exceeding the threshold will be discarded, and the test traffic exceeding the threshold will be retained in the test case library.
[0134] For the same type of test traffic, if the number of test traffic is less than the threshold number, then the test traffic less than the threshold number is retained in the test case library.
[0135] In some embodiments, such as Figure 7 As shown, the device 600 further includes a sequence determination module 640 and a sequence alignment module 650.
[0136] The sequence determination module 640 is used to determine the sequence of execution pile points to be triggered in the post-pile driving program based on the post-pile driving program.
[0137] The sequence comparison module 650 is used to compare the triggered execution stub sequence with the execution stub sequence to be triggered, and to determine the execution stub sequence that has not yet been triggered in the execution stub sequence to be triggered.
[0138] The traffic playback module 620 is also used to continue executing the post-pile program and replay the recorded traffic in the test environment until the sequence of execution pile points to be triggered has been triggered at least n times, where n is a positive integer.
[0139] In some embodiments, such as Figure 7 As shown, the first acquisition module 610 includes: a stub point determination submodule 611 and a code insertion submodule 612.
[0140] The pile point determination submodule 611 is used to determine the pile points in the second version of the test program.
[0141] The code insertion submodule 612 is used to insert monitoring code at the pile point to obtain the post-pile program. The monitoring code is used to monitor the program module and triggering order triggered by the test flow.
[0142] In some embodiments, such as Figure 7 As shown, the pile point determination submodule 611 is used for:
[0143] Scan the source code of the second version of the test program to obtain its logical structure;
[0144] Based on the logical structure of the source code of the second version of the test program, the identifier of the stake points and the order of the stake points are determined.
[0145] In some embodiments, such as Figure 7 As shown, the code insertion submodule 612 is used for:
[0146] The monitoring code is inserted into the stubs of the source code of the second version of the test program to obtain the source code after stubbing;
[0147] The source code after piling is compiled to obtain the piling program.
[0148] In some embodiments, the second version of the test program is the same version of the first version of the test program; or, the second version of the test program is a program obtained by modifying the first version of the test program.
[0149] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.
[0150] Please refer to Figure 8 This diagram illustrates the structural block diagram of a computer device according to an embodiment of this application. The computer device is used to implement the method for generating a test case library provided in the above embodiments. Specifically:
[0151] The computer device 800 includes a CPU (Central Processing Unit) 801, a system memory 804 including RAM (Random Access Memory) 802 and ROM (Read-Only Memory) 803, and a system bus 805 connecting the system memory 804 and the central processing unit 801. The computer device 800 also includes a basic I / O (Input / Output) system 806 that facilitates information transfer between various components within the computer, and a mass storage device 807 for storing the operating system 813, application programs 814, and other program modules 815.
[0152] The basic input / output system 806 includes a display 808 for displaying information and an input device 809 for user input, such as a mouse or keyboard. Both the display 808 and the input device 809 are connected to the central processing unit 801 via an input / output controller 810 connected to the system bus 805. The basic input / output system 806 may also include the input / output controller 810 for receiving and processing input from multiple other devices such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 810 also provides output to a display screen, printer, or other types of output devices.
[0153] The mass storage device 807 is connected to the central processing unit 801 via a mass storage controller (not shown) connected to the system bus 805. The mass storage device 807 and its associated computer-readable media provide non-volatile storage for the computer device 800. That is, the mass storage device 807 may include computer-readable media (not shown) such as a hard disk or a CD-ROM (Compact Disc Read-Only Memory) drive.
[0154] Without loss of generality, the computer-readable medium may include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include RAM, ROM, EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), flash memory or other solid-state storage technologies, CD-ROM, DVD (Digital Video Disc) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Of course, those skilled in the art will recognize that the computer storage media are not limited to the above-mentioned types. The system memory 804 and mass storage device 807 described above can be collectively referred to as memory.
[0155] According to various embodiments of this application, the computer device 800 can also be connected to a remote computer on a network, such as the Internet. That is, the computer device 800 can be connected to a network 812 via a network interface unit 811 connected to the system bus 805, or the network interface unit 811 can be used to connect to other types of networks or remote computer systems (not shown).
[0156] In an exemplary embodiment, a computer-readable storage medium is also provided, the storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set, when executed by a processor, implements the above-described method for generating the test case library.
[0157] Optionally, the computer-readable storage medium may include: ROM (Read-Only Memory), RAM (Random-Access Memory), SSD (Solid State Drives), or optical disc, etc. The random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).
[0158] In an exemplary embodiment, a computer program product or computer program is also provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the above-described method for generating the test case library.
[0159] It should be understood that "multiple" as used in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.
[0160] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A method for generating a test case library, characterized in that, The method includes: The test program acquires multiple recorded traffic data from the first version of the test program and the post-study program from the second version of the test program. The post-study program is used to acquire the program modules triggered during the traffic playback process and the triggering order. The post-study program includes multiple program modules and study points corresponding to each program module. Execute the stub program in the test environment and replay the recorded traffic to obtain the test traffic corresponding to the recorded traffic and the execution stub sequence corresponding to the test traffic; wherein, the execution stub sequence includes multiple stubs arranged in order, and the execution stub sequence is used to indicate the program module triggered by the test traffic and the triggering order; The test traffic is classified according to the corresponding execution stub sequence to obtain at least one type of test traffic, and the execution stub sequence corresponding to the same type of test traffic is the same. For the same type of test traffic, if the number of test traffic exceeds a threshold, the test traffic exceeding the threshold will be discarded, and the test traffic exceeding the threshold will be retained in the test case library, which is used to test the test program. For the same type of test traffic, if the number of test traffic is less than the threshold number, then the test traffic less than the threshold number is retained in the test case library.
2. The method according to claim 1, characterized in that, The method further includes: Based on the post-pile driving procedure, determine the sequence of execution pile points to be triggered in the post-pile driving procedure; By comparing the already triggered execution stub sequences with the execution stub sequences to be triggered, the execution stub sequences to be triggered that have not yet been triggered are identified. The program continues to execute after staking in the test environment and the recorded traffic is replayed until the sequence of execution staking points to be triggered has been triggered at least n times, where n is a positive integer.
3. The method according to claim 1, characterized in that, The process of obtaining the stubbing program of the second version of the test program includes: Identify the stubs in the second version of the test program; The monitoring code is inserted at the piling point to obtain the post-piling program. The monitoring code is used to monitor the program modules and triggering order triggered by the test traffic.
4. The method according to claim 3, characterized in that, The process of determining the stubs in the second version of the test program includes: Scan the source code of the second version of the test program to obtain its logical structure; Based on the logical structure of the source code of the second version of the test program, the identifier of the stake points and the order of the stake points are determined.
5. The method according to claim 3, characterized in that, The step of inserting monitoring code at the pile point to obtain the post-pile driving program includes: The monitoring code is inserted into the stubs of the source code of the second version of the test program to obtain the source code after stubbing; The source code after piling is compiled to obtain the piling program.
6. The method according to any one of claims 1 to 5, characterized in that, The second version of the test program is the same version as the first version of the test program; or, The second version of the test program is a modified version of the first version of the test program.
7. A test case library generation device, characterized in that, The device includes: The first acquisition module is used to acquire multiple recorded traffics of the first version of the test program and the post-study program of the second version of the test program. The post-study program is used to acquire the program modules triggered during the traffic playback process and the triggering order. The post-study program includes multiple program modules and study points corresponding to each program module. The traffic replay module is used to execute the stubbed program in the test environment and replay the recorded traffic to obtain the test traffic corresponding to the recorded traffic and the execution stub sequence corresponding to the test traffic; wherein, the execution stub sequence includes multiple stubs arranged in sequence, and the execution stub sequence is used to indicate the program module triggered by the test traffic and the triggering order; The test case library generation module is used to classify the test traffic according to the corresponding execution stub sequence to obtain at least one type of test traffic, and the execution stub sequence corresponding to the test traffic of the same type is the same. The test case library generation module is also used to, for the same type of test traffic, if the number of test traffic exceeds a threshold value, discard the test traffic exceeding the threshold value and retain the test traffic exceeding the threshold value in the test case library, the test case library being used to test the test program; The test case library generation module is also used to retain test cases with a smaller number of test traffic than the threshold value in the test case library if the number of test traffic of the same type is less than the threshold value.
8. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one instruction, at least one program, a code set, or an instruction set, the at least one instruction, the at least one program, the code set, or the instruction set being loaded and executed by the processor to implement the method for generating a test case library as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the method for generating a test case library as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, The computer program product includes computer instructions that are executed by a processor to implement the method for generating a test case library as described in any one of claims 1 to 6.