Database test case execution result analysis method and device, equipment and medium

Abstract

The invention is suitable for the technical field of testing, and relates to a database test case execution result analysis method and device, equipment and a medium. Target codes under different version numbers are obtained, target cases which fail to execute tests on all the target codes and execution results corresponding to all the target cases are obtained, and for any target case, associated codes associated with the target case are matched from an associated database; determining a version number of a target code used for retesting the target use case as a retest version number according to a detection result of whether the target code contains the associated code, calling the target code corresponding to the retest version number to retest the target use case to obtain a retest result, and executing the target use case according to the retest result and an execution result of the target use case. And determining the earliest target code which enables the test of the target case to fail. The analysis efficiency of the execution result of the test case is improved, and the earliest target code enabling the test of the target case to fail is positioned more quickly.

Description

Technical Field

[0001] This application is applicable to the field of testing technologies, and particularly relates to a method, apparatus, device, and medium for analyzing the execution results of database test cases. Background Art

[0002] When the development and operation integration (DevOps) model is applied to database products, due to daily continuous integration (i.e., providing the latest product package daily), continuous delivery, etc., it is necessary to test and verify the latest product package, and analyze the execution results of the test cases that failed during the test after the test is completed to identify the reasons for the failure. Currently, this process mainly relies on testers to manually analyze the results of the failed test cases one by one to find out the reasons for the failure, so that developers can make timely repairs accordingly. However, with the increase in the number and complexity of test cases, this manual analysis method is not only time-consuming and laborious, inefficient, but also prolongs the test cycle, increases the analysis cost, and is difficult to effectively handle numerous failure situations in large-scale testing. Therefore, how to improve the analysis efficiency of the execution results of test cases has become an urgent problem to be solved. Summary of the Invention

[0003] In view of this, the embodiments of this application provide a method, apparatus, device, and medium for analyzing the execution results of database test cases to solve the problem of how to improve the analysis efficiency of the execution results of test cases.

[0004] In a first aspect, the embodiments of this application provide a method for analyzing the execution results of database test cases, including: Obtaining target codes under different version numbers, and obtaining target test cases that failed during the execution on all target codes and the execution results corresponding to each target test case; For any target test case, matching the associated code related to the target test case from the associated database, where the associated database is used to store the mapping relationship between the target test case and the corresponding associated code; Detecting whether each target code contains the associated code to obtain a detection result, and according to the detection result, determining the version number of the target code for retesting the target test case as the retest version number, and calling the target code corresponding to the retest version number to retest the target test case to obtain a retest result; According to the retest result and the execution result of the target test case, determining the earliest target code that causes the target test case to fail.

[0005] In a second aspect, an apparatus for analyzing the execution result of a database test case provided by an embodiment of the present application includes: An acquisition module, configured to acquire target codes under different version numbers, and acquire target test cases that fail in the execution of all target codes and the execution result corresponding to each target test case; A matching module, configured to match, for any target test case, an associated code associated with the target test case from an associated database, where the associated database is used to store the mapping relationship between the target test case and the corresponding associated code; A first retest module, configured to detect whether each target code includes the associated code, obtain a detection result, and determine, according to the detection result, the version number of the target code for retesting the target test case as the retest version number, and call the target code corresponding to the retest version number to retest the target test case to obtain a retest result; A first analysis module, configured to determine the earliest target code that causes the target test case to fail according to the retest result and the execution result of the target test case.

[0006] In a third aspect, an embodiment of the present application provides a computer device, which includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the method for analyzing the execution result of a database test case as described in the first aspect is implemented.

[0007] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the method for analyzing the execution result of a database test case as described in the first aspect is implemented.

[0008] The beneficial effects of the embodiments of the present application compared with the prior art are as follows: By obtaining the target code under different version numbers, and obtaining the target test cases that failed in the execution of all target codes and the execution results corresponding to each target test case, for any target test case, the associated code associated with the target test case is matched from the associated database, and it is detected whether each target code contains the associated code to obtain the detection result. According to the detection result, the version number of the target code used to retest the target test case is determined as the retest version number, and the target code corresponding to the retest version number is called to retest the target test case to obtain the retest result. According to the retest result and the execution result of the target test case, the earliest target code that causes the target test case to fail is determined. It automatically realizes the intelligent analysis of the execution results of test cases, improves the analysis efficiency of the execution results of test cases, and narrows the analysis scope of the execution results of target test cases according to the associated code associated with the target test case, thus not only improving the analysis efficiency of the execution results of test cases, but also quickly locating the earliest target code that causes the target test case to fail. Brief Description of the Drawings

[0009] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained according to these drawings.

[0010] Figure 1 It is a schematic diagram of an application environment of a method for analyzing the execution results of database test cases provided in Embodiment 1 of the present application; Figure 2 It is a schematic flowchart of a method for analyzing the execution results of database test cases provided in Embodiment 2 of the present application; Figure 3 It is a schematic flowchart of a method for analyzing the execution results of database test cases provided in Embodiment 3 of the present application; Figure 4 It is a schematic flowchart of a method for analyzing the execution results of database test cases provided in Embodiment 4 of the present application; Figure 5 It is a schematic flowchart of a method for analyzing the execution results of database test cases provided in Embodiment 5 of the present application; Figure 6 It is a schematic flowchart of a method for analyzing the execution results of database test cases provided in Embodiment 6 of the present application; Figure 7 It is a schematic flowchart of a method for analyzing the execution results of database test cases provided in Embodiment 7 of the present application; Figure 8 It is a schematic flowchart of a method for analyzing the execution results of database test cases provided in the eighth embodiment of the present application; Figure 9 It is a schematic structural diagram of a device for analyzing the execution results of database test cases provided in the ninth embodiment of the present application; Figure 10 It is a schematic structural diagram of a computer device provided in the tenth embodiment of the present application. Detailed Description of the Invention

[0011] In the following description, specific details such as specific system architectures and technologies are presented for the purpose of illustration rather than limitation, so as to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid unnecessary details from interfering with the description of the present application.

[0012] It should be understood that when used in the specification and appended claims of the present application, the term "comprising" indicates the presence of the described features, wholes, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their combinations.

[0013] It should also be understood that the term "and / or" used in the specification and appended claims of the present application refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0014] As used in the specification and appended claims of the present application, the term "if" can be interpreted as "when", "once", "in response to determining", or "in response to detecting" depending on the context. Similarly, the phrase "if determined" or "if detected [the described condition or event]" can be interpreted as meaning "once determined", "in response to determining", "once detected [the described condition or event]", or "in response to detecting [the described condition or event]" depending on the context.

[0015] In addition, in the description of the specification and appended claims of the present application, the terms "first", "second", "third", etc. are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance.

[0016] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that a specific feature, structure, or characteristic described in connection with that embodiment is included in one or more embodiments of this application. Thus, statements such as "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized. The terms "comprising", "including", "having" and their variants all mean "including but not limited to", unless otherwise specifically emphasized.

[0017] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Among them, artificial intelligence is the theory, method, technology, and application system that uses a digital computer or a machine controlled by a digital computer to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use knowledge to obtain the best results.

[0018] Artificial intelligence basic technologies generally include technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technology, operation / interaction systems, mechatronics, etc. Artificial intelligence software technologies mainly include several major directions such as computer vision technology, robotics, biometric technology, speech processing technology, natural language processing technology, and machine learning / deep learning.

[0019] It should be understood that the magnitudes of the sequence numbers of the steps in the following embodiments do not mean the order of execution. The execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of this application.

[0020] In order to illustrate the technical solutions of this application, specific embodiments will be used for illustration below.

[0021] A method for analyzing the execution results of database test cases provided by the first embodiment of this application can be applied in an application environment such as Figure 1 where the server communicates with the client, the server provides an analysis service, and the client triggers an analysis task to the server. Among them, the client includes but is not limited to devices such as a palm computer, a desktop computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cloud computer device, and a personal digital assistant (PDA). The computer device corresponding to the server can be implemented by an independent server or a server cluster composed of multiple servers.

[0022] See Figure 2, which is a schematic flowchart of a method for analyzing the execution results of database test cases provided in the second embodiment of this application. This method is applied to Figure 1 the server in. The server is connected to the client to obtain the target code, target test cases, and the execution results corresponding to each target test case sent by the client. As Figure 2 shown, it may include the following steps: Step S201, obtain the target code under different version numbers, and obtain the target test cases that failed the test on all target codes and the execution results corresponding to each target test case.

[0023] Step S202, for any target test case, match the associated code related to the target test case from the associated database.

[0024] In this embodiment, the target code may refer to the source code constructed during the software development process. The version number may refer to the identifier used to identify different versions of the target code. The target test case may refer to the test case that failed the test on the target code. The execution result may refer to the output result of the target test case when performing the test on the target code.

[0025] For example, in the Git distributed version control system, the target code may refer to the source code committed and merged into the Git repository. Git generates a unique identifier (commit id) for each software code committed and merged into the Git repository to identify different commit versions. The version number can be the commit id used to identify different versions of the source code.

[0026] The associated code may refer to the source code associated with the target test case. The associated database is used to store the mapping relationship between the target test case and the corresponding associated code. Among them, for any target test case, the associated code stored in the associated database related to this target test case may include: 1) The source code file whose code coverage reaches the threshold after the execution of this target test case; 2) The source code file written to implement the features tested by the target test case; 3) The source code file modified corresponding to the historical failure of this target test case when performing the test.

[0027] Regarding the above 1), the code coverage is used to evaluate the coverage degree of the target test case on the source code. For example, when the code coverage is 50%, after the execution of the target test case, if more than 50% of a certain file or code segment is tested by this target test case, then this file or code segment is the associated code of this target test case; Regarding the above 2), the corresponding source code written by the developer to implement the specific software function or behavioral feature targeted by the target test case. These source codes are the associated code of this target test case; Regarding the above 3), when the historical execution of the target use case fails, in order to fix the failure, the corresponding source code is modified, and these source codes are recorded as the associated codes of the target use case.

[0028] Step S203: Detect whether each target code contains associated codes to obtain a detection result. According to the detection result, determine that the version number of the target code used for retesting the target use case is the retest version number, and call the target code corresponding to the retest version number to retest the target use case to obtain a retest result.

[0029] Step S204: Determine the earliest target code that causes the target use case to fail the test according to the retest result and the execution result of the target use case.

[0030] In this embodiment, the detection result may refer to the result of detecting whether all target codes contain associated codes, the retest version number may refer to the version number of the target code used for retesting the target use case, and the retest result may refer to the output result of retesting the target use case by calling the target code corresponding to the retest version number.

[0031] Specifically, for any target code, detect whether the target code contains associated codes to obtain the detection result of each target code. According to the detection result of each target code, determine the retest version number used for retesting the target use case, use the target use case to retest the target code corresponding to each retest version number to obtain a retest result, and compare the retest result with the execution result of the target use case to determine the earliest target code that causes the target use case to fail the test.

[0032] Among them, in the process of comparing the retest result with the execution result of the target use case, the comparison can be based on the MD5 (Message-Digest Algorithm 5) algorithm. Specifically, calculate the checksum of the retest result and the checksum of the execution result of the target use case respectively based on the MD5 algorithm, and compare the two generated checksums. If the checksums are the same, it is determined that the retest result and the execution result of the target use case are compared consistently. If the checksums are different, it is determined that the retest result and the execution result of the target use case are compared inconsistently.

[0033] Optionally, in the process of comparing the retest result with the execution result of the target use case, the comparison can also be based on the term frequency-inverse document frequency and cosine similarity. Specifically, calculate the term frequency-inverse document frequency of the retest result and the execution result of the target use case respectively, calculate the cosine similarity between the two term frequency-inverse document frequencies. If the calculated cosine similarity exceeds the threshold, it is determined that the retest result and the execution result of the target use case are compared consistently. If the calculated cosine similarity does not exceed the threshold, it is determined that the retest result and the execution result of the target use case are compared inconsistently.

[0034] In the embodiment of the present application, the intelligent analysis of the execution results of test cases is automatically realized, the analysis efficiency of the execution results of test cases is improved, and according to the associated code associated with the target case, the analysis scope of the execution results of the target case is narrowed, so that not only the analysis efficiency of the execution results of test cases is improved, but also the earliest target code that causes the target case test to fail is located faster.

[0035] See Figure 3 , which is a schematic flowchart of a method for analyzing the execution results of database test cases provided in the third embodiment of the present application. As Figure 3 shown, in the above step S203, according to the detection result, determining the version number of the target code for retesting the target case as the retest version number, and calling the target code corresponding to the retest version number to retest the target case to obtain the retest result may include the following steps: Step S301, if the detection result is that there is a target code containing the associated code, determine the version number of each target code containing the associated code as the retest version number.

[0036] Step S302, arrange the version numbers of all target codes in ascending order to obtain the first version number sequence.

[0037] Step S303, for any retest version number, take the retest version number as the initial retest version number, and according to the first version number sequence, determine the previous version number directly consecutive to the initial retest version number.

[0038] Step S304, use the target case to retest the target code corresponding to the initial retest version number to obtain the first retest result, and use the target case to retest the target code corresponding to the previous version number to obtain the second retest result.

[0039] In this embodiment, the first version number sequence may refer to the version number sequence obtained by arranging the version numbers of all target codes in ascending order, and the initial retest version number may refer to any retest version number, where the previous version number directly consecutive to the initial retest version number may be the retest version number of the target code containing the associated code or the version number of the target code not containing the associated code, and the first retest result may refer to the output result of using the target case to retest the target code corresponding to the initial retest version number, and the second retest result may refer to the output result of using the target case to retest the target code corresponding to the previous version number.

[0040] Specifically, if it is detected that there is a target code containing associated code among all target codes, determine the version number of each target code containing the associated code as the retest version number. Arrange the version numbers of all target codes in ascending order according to the size of the version numbers to obtain a first version number sequence. For any retest version number, use this target case to retest the target code corresponding to this initial retest version number to obtain a first retest result, and use this target case to retest the target code corresponding to the version number immediately preceding this retest version number to obtain a second retest result.

[0041] In the embodiment of the present application, by detecting whether each target code contains associated code, when it is detected that there is a target code containing associated code, determine the version number of each target code containing the associated code as the retest version number, sort the version numbers of all target codes, and retest the target case according to the initial retest version number and the version number immediately preceding the initial retest version number, which improves the analysis efficiency of the execution results of the test cases, so that the earliest target code that causes the target case to fail can be located more quickly.

[0042] See Figure 4 , which is a schematic flowchart of a method for analyzing the execution results of database test cases provided in the fourth embodiment of the present application. As Figure 4 shown, in the above step S203, according to the retest result and the execution result of the target case, determining the earliest target code that causes the target case to fail may include the following steps: Step S401, compare the first retest result with the execution result of the target case, and compare the second retest result with the execution result of the target case.

[0043] Step S402, if the comparison between the first retest result and the execution result of the target case is consistent, and the comparison between the second retest result and the execution result of the target case is inconsistent, determine that the target code corresponding to the initial retest version number is the earliest target code that causes the target case to fail.

[0044] Specifically, according to the content of comparing the retest result and the execution result of the target case in the above step S204, compare the first retest result with the execution result of this target case, and compare the second retest result with the execution result of this target case. If the comparison between the first retest result and the execution result of the target case is consistent, and the comparison between the second retest result and the execution result of the target case is inconsistent, that is, the execution result of this target case can be reproduced on the target code corresponding to this initial retest version number and cannot be reproduced on the target code corresponding to the version number immediately preceding this initial retest version number, it indicates that the target code corresponding to this initial retest version number is the earliest target code that causes this target case to fail.

[0045] In an embodiment of the present application, by using the MD5 checksum algorithm, term frequency-inverse document frequency, and cosine similarity, the first retest result and the second retest result are respectively compared with the execution result. According to the comparison result, the earliest target code that causes the target test case to fail is determined, which not only improves the analysis efficiency of the execution result of the test case, but also more quickly locates the earliest target code that causes the target test case to fail.

[0046] See Figure 5 , which is a schematic flowchart of a method for analyzing the execution result of a database test case provided in the fifth embodiment of the present application. As Figure 5 shown, after comparing the first retest result with the execution result of the target test case and comparing the second retest result with the execution result of the target test case in the above step S401, the following steps may further be included: Step S501, if the first retest result is consistent with the execution result of the target test case and the second retest result is consistent with the execution result of the target test case, then determine all retest version numbers before the initial retest version number according to the first version number sequence; Step S502, take any retest version number before the initial retest version number as the initial retest version number, and return to execute the step of determining the previous version number directly consecutive to the initial retest version number according to the first version number sequence until the earliest target code that causes the target test case to fail is determined.

[0047] Step S503, if the first retest result is inconsistent with the execution result of the target test case and the second retest result is inconsistent with the execution result of the target test case, then determine all retest version numbers after the initial retest version number according to the first version number sequence.

[0048] Step S504, take any retest version number after the initial retest version number as the initial retest version number, and return to execute the step of determining the previous version number directly consecutive to the initial retest version number according to the first version number sequence until the earliest target code that causes the target test case to fail is determined.

[0049] Specifically, if the first retest result is consistent with the execution result of the target use case, and the second retest result is consistent with the execution result of the target use case, that is, the execution result of the target use case can be reproduced on the target code corresponding to the initial retest version number and can also be reproduced on the target code corresponding to the version number before the initial retest version number, indicating that the version number of the target code that first causes the target use case to fail the test is before the initial retest version number, then any retest version number before the initial retest version number is used as the initial retest version number, and the step of determining the previous version number directly consecutive to the initial retest version number according to the first version number sequence in the above step S303 is returned until the earliest target code that causes the target use case to fail the test is determined; If the first retest result is inconsistent with the execution result of the target use case, and the second retest result is inconsistent with the execution result of the target use case, that is, the execution result of the target use case cannot be reproduced on the target code corresponding to the initial retest version number and cannot be reproduced on the target code corresponding to the version number before the initial retest version number, indicating that the version number of the target code that first causes the target use case to fail the test is after the initial retest version number, then any retest version number after the initial retest version number is used as the initial retest version number, and the step of determining the previous version number directly consecutive to the initial retest version number according to the first version number sequence in the above step S303 is returned until the earliest target code that causes the target use case to fail the test is determined.

[0050] In the embodiments of the present application, by comparing the first retest result and the second retest result with the execution result, the positioning range of the earliest target code that causes the target use case to fail the test is narrowed, so that the earliest target code that causes the target use case to fail the test can be located more quickly.

[0051] See Figure 6 , which is a schematic flowchart of a method for analyzing the execution result of a database test case provided in Embodiment VI of the present application. As Figure 6 shown, in the above step S203, according to the detection result, the version number of the target code used for retesting the target use case is determined as the retest version number, and the target code corresponding to the retest version number is called to retest the target use case to obtain the retest result. The following steps may also be included: Step S601, if the detection result is that all target codes do not contain the associated code, then the version number of each target code is determined as the retest version number.

[0052] Step S602, sort all the retest version numbers in ascending order to obtain a second version number sequence, and group the second version number sequence to obtain version number groups.

[0053] Step S603: For any version number group, determine the starting retest version number and the ending retest version number of the version number group. Use the target test case to retest the target code corresponding to the starting retest version number to obtain the third retest result, and use the target test case to retest the target code corresponding to the ending retest version number to obtain the fourth retest result.

[0054] In this embodiment, the second version number sequence may refer to the version number sequence obtained by arranging all retest version numbers in ascending order. The version number group may refer to the set of version numbers obtained by grouping all retest version numbers in the second version number sequence. The starting retest version number and the ending retest version number may refer to any retest version number in the version number group. For any version number group, when initially invoking the target code corresponding to the version number group to retest the target test case, the starting retest version number may refer to the first retest version number in the version number group, and the ending retest version number may refer to the last retest version number in the version number group. The third retest result may refer to the output result of using the target test case to retest the target code corresponding to the starting retest version number, and the fourth retest result may refer to the output result of using the target test case to retest the target code corresponding to the ending retest version number.

[0055] Specifically, if it is detected that none of the target codes contain the associated code, determine the version number of each target code as the retest version number. Arrange all retest version numbers in ascending order according to the size of the version numbers to obtain the second version number sequence. Determine the number of execution nodes for retesting the target test case. According to the number of execution nodes, group the second version number sequence to obtain the version number group, and distribute the version number group to all execution nodes. All execution nodes simultaneously invoke the target code corresponding to the version number group to retest the target test case. On each execution node, for any version number group distributed to the execution node, determine the starting retest version number and the ending retest version number of the version number group. Use the target test case to retest the target code corresponding to the starting retest version number to obtain the third retest result, and use the target test case to retest the target code corresponding to the ending retest version number to obtain the fourth retest result.

[0056] In the embodiment of the present application, by detecting whether each target code contains the associated code, when it is detected that none of the target codes contain the associated code, determine the version number of each target code as the retest version number, sort all retest version numbers, and group them according to the number of execution nodes to obtain the version number group. Simultaneously retest the target test case according to the starting retest version number and the ending retest version number on all execution nodes, which improves the analysis efficiency of the execution results of the test cases, and thus can more quickly locate the earliest target code that causes the target test case to fail.

[0057] See Figure 7, which is a schematic flowchart of a method for analyzing the execution result of a database test case provided in the seventh embodiment of the present application. As Figure 7 shown, in the above step S204, according to the retest result and the execution result of the target use case, determining the earliest target code that causes the target use case to fail in testing may further include the following steps: Step S701: Compare the third retest result with the execution result of the target use case, and compare the fourth retest result with the execution result of the target use case.

[0058] Step S702: If the comparison between the third retest result and the execution result of the target use case is inconsistent, and the comparison between the fourth retest result and the execution result of the target use case is consistent, then determine, according to the second version number sequence, the next retest version number that is directly consecutive with the starting retest version number.

[0059] Step S703: Use the next retest version number as the starting retest version number, and return to execute the step of retesting the target code corresponding to the starting retest version number using the target use case until the earliest target code that causes the target use case to fail in testing is determined.

[0060] Specifically, according to the content of comparing the retest result and the execution result of the target use case in the above step S204, compare the third retest result with the execution result of the target use case, and compare the fourth retest result with the execution result of the target use case. If the comparison between the third retest result and the execution result of the target use case is inconsistent, and the comparison between the fourth retest result and the execution result of the target use case is consistent, that is, the execution result of the target use case cannot be reproduced on the target code corresponding to the starting retest version number, but can be reproduced on the target code corresponding to the ending retest version number, it indicates that the version number of the target code that earliest causes the target use case to fail in testing is after the starting retest version number of this version number group. Then, according to the second version number sequence, determine the next retest version number that is directly consecutive with the starting retest version number, use the next retest version number as the new starting retest version number, and return to execute the step of retesting the target code corresponding to the starting retest version number using the target use case in the above step S603 until the comparison between the third retest result and the execution result of the target use case is consistent, and the comparison between the fourth retest result and the execution result of the target use case is consistent, and determine the target code corresponding to the starting retest version number of the third retest result as the earliest target code that causes the target use case to fail in testing; If the third retest result is inconsistent with the execution result of the target use case when the version number group is called for the first time to retest the target use case, and the fourth retest result is inconsistent with the execution result of the target use case, it is determined that there is no earliest target code in the version number group that causes the target use case to fail the test. A version number group with a retest version number greater than the version number of this version number group is determined, and the version number group with a retest version number greater than the version number of this version number group is retested according to the content in the above step S603, steps S701 to S703 until the earliest target code that causes the target use case to fail the test is determined; If the third retest result is consistent with the execution result of the target use case when the version number group is called for the first time to retest the target use case, and the fourth retest result is consistent with the execution result of the target use case, it is determined that there is no earliest target code in the version number group that causes the target use case to fail the test or the starting retest version number may be the earliest target code that causes the target use case to fail the test. A version number group with a retest version number less than the version number of this version number group is determined, and the version number group with a retest version number less than the version number of this version number group is retested according to the content in the above step S603, steps S701 to S703 until the earliest target code that causes the target use case to fail the test is determined.

[0061] In the embodiments of the present application, by respectively comparing the first retest result and the second retest result with the execution result based on the MD5 checksum algorithm, term frequency-inverse document frequency, and cosine similarity, according to the comparison results, the positioning range of the earliest target code that causes the target use case to fail the test is narrowed down, and the earliest target code that causes the target use case to fail the test is determined, which not only improves the analysis efficiency of the execution results of the test cases, but also locates the earliest target code that causes the target use case to fail the test faster.

[0062] See Figure 8 , which is a schematic flowchart of a method for analyzing the execution results of database test cases provided in the eighth embodiment of the present application. As Figure 8 shown, after obtaining the target use cases that fail the test on all target codes and the execution results corresponding to each target use case in the above step S201, it further includes: Step S801, for any target use case, use the target use case to retest each target code to obtain pre-retest results.

[0063] Step S802, determine the pre-retest results that fail to execute from all the pre-retest results. For any pre-retest result that fails to execute, compare the pre-retest result that fails to execute with the historical failure results in the historical database.

[0064] Step S803: If there is a historical failure result in the historical database that matches the pre-retest result that failed to execute, then based on the historical failure result, determine the earliest target code that caused the target use case to fail the test.

[0065] In this embodiment, the pre-retest result may refer to the output result of retesting each target code using the target use case before retesting the target use case according to the associated code. The historical failure result may refer to the output result of the target use case failing to execute during historical execution. The historical database is used to store the mapping relationship between the target use case and the corresponding historical failure result and the target code that caused the historical failure result.

[0066] Specifically, before retesting the target use case according to the content in the above steps S202 to S204, for any target use case, use the target use case to retest each target code to obtain the pre-retest result. If all the pre-retest results are that the target use case executes successfully, it is determined that the occasional execution failure of the target use case is caused by factors such as the test environment. If there is a pre-retest result that fails to execute, for any pre-retest result that fails to execute, according to the content in the above step S204, compare the pre-retest result that fails to execute with the historical failure results in the historical failure database. If there is a historical failure result in the historical database that matches the pre-retest result that fails to execute, then based on the historical failure result, determine the target code that caused the historical failure result, and determine the target code that caused the historical failure result as the earliest target code that caused the target use case to fail the test.

[0067] In the embodiment of the present application, by using the mapping relationship between the target use case stored in the historical database and the corresponding historical failure result and the target code that caused the historical failure result, a pre-judgment is made on the execution result of the target use case, and the target use cases that fail the test due to environmental problems and historical known problems are identified, reducing the number of target use cases to be retested subsequently and improving the analysis efficiency of the execution result of the test use case.

[0068] Corresponding to the method for analyzing the execution result of the database test use case in the above embodiment, Figure 9 The structural block diagram of the database test use case execution result analysis device provided in the ninth embodiment of the present application is shown. This device is applied to Figure 1 the server in. For the sake of convenience of description, only the parts related to the embodiment of the present application are shown.

[0069] See Figure 9 , the database test use case execution result analysis device includes: An acquisition module 91, configured to acquire target codes under different version numbers, and acquire target test cases that failed in the execution of all target codes and the execution results corresponding to each target test case; A matching module 92, configured to match, for any target test case, an associated code associated with the target test case from an associated database, where the associated database is used to store the mapping relationship between the target test case and the corresponding associated code; A first retest module 93, configured to detect whether each target code contains the associated code, obtain a detection result, and based on the detection result, determine that the version number of the target code for retesting the target test case is a retest version number, and call the target code corresponding to the retest version number to retest the target test case to obtain a retest result; A first analysis module 94, configured to determine the earliest target code that causes the target test case to fail based on the retest result and the execution result of the target test case.

[0070] Optionally, the first retest module 93 includes: A first determination unit, configured to, if the detection result is that there is a target code containing the associated code, determine that the version number of each target code containing the associated code is the retest version number; A first sorting unit, configured to sort the version numbers of all target codes in ascending order to obtain a first version number sequence; A second determination unit, configured to, for any retest version number, use the retest version number as an initial retest version number, and based on the first version number sequence, determine the previous version number that is directly consecutive with the initial retest version number; A second retest unit, configured to use the target test case to retest the target code corresponding to the initial retest version number to obtain a first retest result, and use the target test case to retest the target code corresponding to the previous version number to obtain a second retest result.

[0071] Optionally, the first analysis module 94 includes: A first comparison unit, configured to compare the first retest result with the execution result of the target test case, and compare the second retest result with the execution result of the target test case; A second analysis unit, configured to, if the comparison between the first retest result and the execution result of the target test case is consistent, and the comparison between the second retest result and the execution result of the target test case is inconsistent, determine that the target code corresponding to the initial retest version number is the earliest target code that causes the target test case to fail.

[0072] Optionally, the first analysis module 94 further includes: A third determination unit, configured to, if the first retest result is consistent with the execution result of the target use case and the second retest result is consistent with the execution result of the target use case, determine all retest version numbers before the initial retest version number according to the first version number sequence; A third analysis unit, configured to use any retest version number before the initial retest version number as the initial retest version number, and return to execute the step of determining the version number directly preceding the initial retest version number according to the first version number sequence until the earliest target code that causes the target use case to fail the test is determined; A fourth determination unit, configured to, if the first retest result is inconsistent with the execution result of the target use case and the second retest result is inconsistent with the execution result of the target use case, determine all retest version numbers after the initial retest version number according to the first version number sequence; A fourth analysis unit, configured to use any retest version number after the initial retest version number as the initial retest version number, and return to execute the step of determining the version number directly preceding the initial retest version number according to the first version number sequence until the earliest target code that causes the target use case to fail the test is determined.

[0073] Optionally, the first retest module 93 further includes: A fifth determination unit, configured to, if the detection result is that all target codes do not include the associated code, determine the version number of each target code as the retest version number; A second sorting unit, configured to perform ascending sorting on all retest version numbers to obtain a second version number sequence, and group the second version number sequence to obtain version number groups; A third retest unit, configured to, for any version number group, determine the starting retest version number and the ending retest version number of the version number group, use the target use case to retest the target code corresponding to the starting retest version number to obtain a third retest result, and use the target use case to retest the target code corresponding to the ending retest version number to obtain a fourth retest result.

[0074] Optionally, the first analysis module 94 further includes: A second comparison unit, configured to compare the third retest result with the execution result of the target use case, and compare the fourth retest result with the execution result of the target use case; A sixth determination unit, configured to, if the third retest result is inconsistent with the execution result of the target use case and the fourth retest result is consistent with the execution result of the target use case, determine, according to the second version number sequence, a next retest version number that is directly consecutive with the starting retest version number; A fourth retest unit, configured to use the next retest version number as the starting retest version number, and return to execute the step of retesting the target code corresponding to the starting retest version number by using the target use case, until the earliest target code that causes the target use case to test fail is determined.

[0075] It should be noted that, for the information interaction, execution process, etc. between the above modules, since they are based on the same concept as the method embodiment of the present application, for their specific functions and the technical effects brought, reference may be specifically made to the method embodiment part, and details are not described herein again.

[0076] Figure 10 This is a schematic structural diagram of a computer device provided in Embodiment X of the present application. As Figure 10 shown, the computer device of this embodiment includes: at least one processor ( Figure 10 only one is shown in the figure), a memory, and a computer program stored in the memory and executable on at least one processor. When the processor executes the computer program, the steps in any of the above method embodiments for analyzing the execution results of database test cases are implemented.

[0077] The computer device may include, but is not limited to, a processor and a memory. Those skilled in the art can understand that Figure 10 this is only an example of a computer device, and does not constitute a limitation on the computer device. The computer device may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include a network interface, a display screen, and an input device, etc.

[0078] The so-called processor may be a CPU, and this processor may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or this processor may also be any conventional processor, etc.

[0079] The memory includes a readable storage medium, an internal memory, etc. Among them, the internal memory can be the memory of a computer device, and the internal memory provides an environment for the operation of the operating system and computer-readable instructions in the readable storage medium. The readable storage medium can be the hard disk of a computer device, and in some other embodiments, it can also be an external storage device of the computer device. For example, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. equipped on the computer device. Further, the memory can also include both the internal storage unit of the computer device and the external storage device. The memory is used to store the operating system, application programs, a BootLoader, data, and other programs, such as the program code of a computer program. The memory can also be used to temporarily store the data that has been output or will be output.

[0080] Those skilled in the art can clearly understand that, for the convenience and conciseness of description, only the above-mentioned division of each functional unit and module is used as an example. In actual applications, the above-mentioned functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiments can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of this application. The specific working processes of the units and modules in the above-mentioned device can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein. If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, to implement all or part of the processes in the above-mentioned method embodiments of this application, a computer program can be used to instruct the relevant hardware to complete. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-mentioned method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file or some intermediate form, etc. The computer-readable medium can at least include: any entity or device that can carry the computer program code, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disc, etc. In some jurisdictions, according to legislation and patent practice, the computer-readable medium cannot be an electrical carrier signal and a telecommunication signal.

[0081] All or part of the processes in the above-mentioned method embodiments of this application can also be completed by a computer program product. When the computer program product runs on a computer device, it enables the computer device to execute and implement the steps in the above-mentioned method embodiments.

[0082] In the above embodiments, the descriptions of each embodiment have their own emphases. For the parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0083] Those of ordinary skill in the art will realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. A professional technician can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of this application.

[0084] In the embodiments provided in this application, it should be understood that the disclosed device / computer device and method can be implemented in other ways. For example, the device / computer device embodiments described above are merely illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of the device or unit can be in electrical, mechanical or other forms.

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

[0086] The above embodiments are only used to illustrate the technical solutions of this application, rather than to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features. And these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of each embodiment of this application, and should all be included in the protection scope of this application.

Claims

1. A method for analyzing the execution results of a database test case, characterized in that: include: Obtain target codes under different version numbers, as well as target use cases that failed to be tested on all target codes and the execution results of each target use case; For any target use case, an association code associated with the target use case is matched from an association database, wherein the association database is used to store a mapping relationship between the target use case and the corresponding association code; Detecting whether each target code contains the associated code to obtain a detection result, determining, based on the detection result, a version number of the target code used to retest the target use case as a retest version number, calling the target code corresponding to the retest version number to retest the target use case, and obtaining a retest result; The earliest target code that causes the target case test to fail is determined according to the retest result and the execution result of the target case.

2. The method for analyzing database test case execution results according to claim 1, characterized in that: The step of determining, according to the detection result, a version number of a target code used to retest the target use case as a retest version number, calling the target code corresponding to the retest version number to retest the target use case, and obtaining a retest result includes: If the detection result is that there is a target code containing the associated code, determining the version number of each target code containing the associated code as the retest version number; Arrange the version numbers of all target codes in ascending order to obtain a first version number sequence; For any retest version number, take the retest version number as the initial retest version number, and determine the previous version number that is directly continuous with the initial retest version number according to the first version number sequence; Using the target use case, the target code corresponding to the initial retest version number is retested to obtain a first retest result, and using the target use case, the target code corresponding to the previous version number is retested to obtain a second retest result.

3. The method for analyzing database test case execution results according to claim 2, characterized in that: The determining, according to the retest result and the execution result of the target use case, the earliest target code that causes the target use case test to fail, comprises: Comparing the first retest result with the execution result of the target use case, and comparing the second retest result with the execution result of the target use case; If the first retest result is consistent with the execution result of the target use case, and the second retest result is inconsistent with the execution result of the target use case, then the target code corresponding to the initial retest version number is determined to be the earliest target code that causes the target use case test to fail.

4. The method for analyzing database test case execution results according to claim 3, characterized in that: After comparing the first retest result with the execution result of the target use case, and comparing the second retest result with the execution result of the target use case, the method further includes: If the first retest result is consistent with the execution result of the target use case, and the second retest result is consistent with the execution result of the target use case, then determining all retest version numbers before the initial retest version number according to the first version number sequence; any retest version number before the initial retest version number is used as the initial retest version number, and returning to the step of determining the previous version number directly consecutive to the initial retest version number according to the first version number sequence, until the earliest target code that causes the target case test to fail is determined; If the first retest result is inconsistent with the execution result of the target use case, and the second retest result is inconsistent with the execution result of the target use case, then determining all retest version numbers after the initial retest version number according to the first version number sequence; Any retest version number after the initial retest version number is set as the initial retest version number, and the step of determining the previous version number directly consecutive to the initial retest version number according to the first version number sequence is returned to execute until the earliest target code that causes the target use case test to fail is determined.

5. The method for analyzing database test case execution results according to claim 1, characterized in that: The step of determining, according to the detection result, a version number of a target code used to retest the target use case as a retest version number, calling the target code corresponding to the retest version number to retest the target use case to obtain a retest result, further includes: If the detection result is that all target codes do not contain the associated code, then determining the version number of each target code to be the retest version number; Arrange all retested version numbers in ascending order to obtain a second version number sequence, and group the second version number sequence to obtain a version number group; For any version number group, determine the starting retest version number and the ending retest version number of the version number group, use the target use case to retest the target code corresponding to the starting retest version number to obtain a third retest result, and use the target use case to retest the target code corresponding to the ending retest version number to obtain a fourth retest result.

6. The method for analyzing database test case execution results according to claim 5, characterized in that: The determining, according to the retest result and the execution result of the target use case, the earliest target code that causes the target use case test to fail, further includes: Comparing the third retest result with the execution result of the target use case, and comparing the fourth retest result with the execution result of the target use case; If the third retest result is inconsistent with the execution result of the target use case, and the fourth retest result is consistent with the execution result of the target use case, then determining a subsequent retest version number that is directly continuous with the starting retest version number according to the second version number sequence; The latter retest version number is used as the starting retest version number, and the step of using the target use case to retest the target code corresponding to the starting retest version number is returned to execute until the earliest target code that causes the target use case test to fail is determined.

7. The method for analyzing database test case execution results according to claim 1, characterized in that: After acquiring the target use cases that failed to be tested on all target codes and the execution results of each target use case, the method further includes: For any target use case, retest each target code using the target use case to obtain a pre-retest result; Determine a pre-retest result of execution failure from all pre-retest results, and for any pre-retest result of execution failure, compare the pre-retest result of execution failure with a historical failure result in a historical database, wherein the historical database is used to store a mapping relationship between the target use case and the corresponding historical failure result and the target code causing the historical failure result; If there is a historical failure result in the historical database that is consistent with the pre-retest result of the failed execution, the earliest target code that causes the target use case test to fail is determined based on the historical failure result.

8. A database test case execution result analysis device, characterized in that: include: The acquisition module is used to obtain target codes under different version numbers, as well as to obtain target use cases that failed to be tested on all target codes and the execution results of each target use case; A matching module, used for matching, for any target use case, an association code associated with the target use case from an association database, wherein the association database is used for storing a mapping relationship between the target use case and the corresponding association code; A first retest module is used to detect whether each target code contains the associated code, obtain a detection result, determine the version number of the target code used to retest the target use case as the retest version number according to the detection result, call the target code corresponding to the retest version number to retest the target use case, and obtain a retest result; The first analysis module is used to determine the earliest target code that causes the target case test to fail according to the retest result and the execution result of the target case.

9. A computer device, characterized in that: The computer device includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the method for analyzing the execution results of a database test case as described in any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for analyzing the execution results of a database test case as described in any one of claims 1 to 7 is implemented.

Images