A white box anomaly testing method capable of achieving high coverage and high efficiency
By adding white box exception handling code logic to the database, high coverage and high efficiency white box exception testing is achieved, solving the problems of low testing efficiency and incomplete coverage in the existing technology, and simplifying the exception location and problem repair process.
Patent Information
- Application Number
- CN202111594973.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-12-23
- Publication Date
- 2025-03-28
- Estimated Expiration
- 2041-12-23
AI Technical Summary
The existing technology is difficult to achieve full coverage of database abnormality testing, and the testing efficiency is low, making it difficult for R&D personnel to determine the specific situation of the abnormality.
The white box exception testing method is used to add the white box exception handling code logic to the database, and all external exceptions in the program are automatically traversed and triggered by the test program, collecting and recording exception events, and achieving full coverage testing.
It realizes high coverage and high efficiency exception testing, can quickly traverse all call stacks that trigger exceptions in the database, record downtime exception information, and simplify the exception location and problem repair process.
Smart Images
Figure CN114328206B_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of database anomaly testing, and in particular relates to a white box anomaly testing method capable of achieving high coverage and high efficiency. Background Art
[0002] From the online operation of GBase 8a products, many crash or deadlock bugs are caused by external exceptions. For such problems, the current common means is to conduct exception testing by randomly triggering exceptions or randomly sending kill signals. However, since the entire test process is random, it is difficult to achieve complete coverage, and it is conducted in a black box. Even if a crash or deadlock problem is found, it is difficult for R&D personnel to know the internal details of the program, and it takes a lot of time to determine which exception caused the crash or deadlock.
[0003] For the above reasons, testing for exceptions has not been carried out smoothly. For example, if you want to test all memory applications in a program, the effect of covering them according to the original method is not ideal because memory applications in the program are almost everywhere. Therefore, there is an urgent need for a testing method that can automatically traverse and trigger all external exceptions in the program and thereby fix the problems in program processing. Summary of the invention
[0004] In view of this, the present invention aims to propose a white-box exception testing method that can achieve high coverage and high efficiency, so as to solve the problem that it is difficult to achieve full coverage in the existing testing process, and the test is performed in a black box, and R&D personnel need to spend a lot of time to determine the specific circumstances of the exception, which is inefficient.
[0005] To achieve the above object, the technical solution of the present invention is achieved as follows:
[0006] A white box anomaly testing method that can achieve high coverage and high efficiency, the specific steps are as follows:
[0007] S1. Add white-box exception handling code logic to database products;
[0008] S2. The tester specifies the database test target and starts the test program of all the use cases in the use case library; the test program executes each use case in turn, and collects the exception events caused by the database exception handling code being triggered when the use case is executed. The specific method is as follows: each time a use case is read, an empty stack pool is initialized for the use case under test; whenever the exception handling code in the database is triggered, a function call stack of the current execution point of the use case under test is generated through the database function, the function call stack is stored in the stack pool corresponding to the use case under test, and the stack pool information of the use case under test is stored in the temporary file corresponding to the use case under test;
[0009] S3. The test program performs an exception test on all the use cases in the use case library. The specific method of performing an exception test on each use case is as follows: the test program reads each use case and the stack pool information in the temporary file corresponding to the use case; performs an exception test on all function call stacks in the tested use case, and records the exception information corresponding to the function call stack that causes the database to fail to operate normally into the log;
[0010] S4. Locate the abnormal information based on the log.
[0011] Furthermore, in step S2, the tester specifies that the database test targets include memory exception test and kill process exception test.
[0012] Furthermore, the function call stack is stored in the stack pool corresponding to the test case. The specific method is as follows:
[0013] S21, converting the function call stack into a verification code through a hash algorithm;
[0014] S22, the test program determines whether the verification code generated in step S21 exists in the stack pool of the current test case, if it exists, the test case continues to be executed, if not, the verification code is stored in the stack pool, and then the test case continues to be executed;
[0015] S23, the test program repeats steps S21 and S22 until the current use case is executed;
[0016] Only non-duplicate check codes will be inserted into the stack pool of the current test case, so the file now contains all the function call stacks of the current test case exception handling action without duplicate call stacks, where each function call stack is called a unique call stack.
[0017] Furthermore, the stack pool information includes the number of function call stacks of the use case.
[0018] Further, in step S3, all function call stacks in the test case are tested for exceptions, and the exception information corresponding to the function call stacks that cause the database to fail to operate normally is recorded in the log. The specific method is as follows:
[0019] S31, the test program reads the test case, and when the exception handling code of the database is triggered, detects whether a corresponding function call stack appears, throws an exception only when the function call stack appears, and removes the function call stack from the stack pool corresponding to the test case;
[0020] S32. When an exception is thrown, the test program checks the database status. If the status is normal, the test program continues to execute. If a downtime occurs, the test program records the exception information, restarts the database, re-executes the current use case, but does not reload the stack pool corresponding to the test case.
[0021] S33. The test program repeats steps S31-S32 until the stack pool of the current use case is cleared, that is, all the situations in which the exception handling codes in the tested use case are triggered are covered.
[0022] Furthermore, in step S3, the exception information includes the use case name, SQL statement, the stack ID where the exception is thrown, and the downtime stack.
[0023] Compared with the prior art, the white box anomaly testing method capable of achieving high coverage and high efficiency described in the present invention has the following beneficial effects:
[0024] (1) The white-box exception testing method described in the present invention, which can achieve high coverage and high efficiency, achieves full coverage of the test, quickly traverses all call stacks that trigger exceptions in the database, throws the exceptions, and records the exception information of the crash when the database execution crashes, so as to prepare for the subsequent location and problem of the exception test based on the log. Full coverage ensures the accuracy and perfection of the test.
[0025] (2) In step S22 described in the present invention, the test program determines whether the verification code generated in step S21 exists in the stack pool of the current test case. If it exists, the test case continues to be executed. If it does not exist, the verification code is stored in the stack pool and then the test case continues to be executed. Only non-duplicate verification codes will be inserted into the stack pool of the current test case. Therefore, at this time, the file contains all the function call stacks of the current test case exception handling action and there are no duplicate call stacks, where each function call stack is called a unique call stack, which greatly reduces the number of function call stacks called during exception testing and achieves the purpose of high-efficiency testing. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] The accompanying drawings constituting a part of the present invention are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the accompanying drawings:
[0027] Figure 1 A schematic diagram of function call stack generation for a white box exception testing method capable of achieving high coverage and high efficiency as described in an embodiment of the present invention. DETAILED DESCRIPTION
[0028] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.
[0029] In the description of the present invention, it should be understood that the terms "center", "longitudinal", "lateral", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside" and the like indicate positions or positional relationships based on the positions or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and the like are only used for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, features defined as "first", "second", and the like may explicitly or implicitly include one or more of the features. In the description of the present invention, unless otherwise specified, "multiple" means two or more.
[0030] In the description of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood by specific circumstances.
[0031] The present invention will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.
[0032] like Figure 1 As shown, the present application describes a white-box exception testing method that can achieve high coverage and high efficiency. First, a white-box exception handling code logic is added to the GBase 8a database product. The exception content of the exception handling code includes memory allocation exception and kill process exception.
[0033] After having a GBase 8a database product that contains exception handling logic, we can start to execute the exception testing process of the product through the exception testing tool. The execution process is mainly divided into three stages:
[0034] 1. The first stage: the collection stage. The test tool normally executes the regression test cases in the test case library and records and saves the number of unique call stacks for each test case. The specific process is as follows:
[0035] 11) The tester specifies the target of this test as memory anomaly test through parameters in the database configuration file, starts the database, runs the test program, and starts the collection mode;
[0036] 12) The test program reads a use case from the use case library and initializes an empty stack pool for it;
[0037] 13) When the test program executes the use case read in step 12), whenever the exception handling code inside the database is triggered, the database function is called to generate a function call stack of the current execution point, and the call stack is converted into a unique verification code through a hash algorithm;
[0038] 14) The test program determines whether the verification code generated in step 13) exists in the stack pool of the current test case. If it exists, the test case will continue to be executed. If it does not exist, the verification code will be stored in the stack pool and then the test case will continue to be executed;
[0039] 15) The test program repeats steps 13) to 14) until the use cases in the current use case library are executed;
[0040] 16) The test program saves the stack pool information of the current test case into a temporary file. Since only unique and non-repeating check codes are inserted into the stack pool, each stack pool contains all the call stacks of the corresponding case exception handling action without duplicate items, and each call stack is called a unique call stack;
[0041] 17) The test program repeats steps 12) to 16) until all use cases in the use case library are executed;
[0042] 2. The second stage: the test stage. The test program loads the unique call stack generated in the first stage, and performs exception tests on all unique call stacks. The specific process is as follows:
[0043] 21) The tester runs the test program and starts to perform abnormal testing;
[0044] 22) The test program reads a use case from the use case library, loads the temporary file corresponding to the current test case generated in step 16) in the first phase, and reads the relevant stack pool information recorded in the file.
[0045] 23) The test program executes the use case read in step 22), detects the call stack when the exception handling code is triggered, throws an exception only when the "unique call stack" appears, and removes the "unique call stack" from the stack pool;
[0046] 24) If step 23) throws an exception, the test program checks the database status. If the status is normal, the test program continues to execute. If a downtime occurs, the test program records the relevant exception information, restarts the database, and re-executes the current use case without reloading the stack pool.
[0047] 25) The test program repeats steps 23) to 24) until the stack pool of the current test case is cleared, that is, all the situations in which the exception handling is triggered in the current test case are covered;
[0048] 26) The test program repeats steps 22) to 25) until all use cases in the use case library are executed.
[0049] Phase 3: Analysis phase. After the second phase of testing is completed, if the database crashes during the test, a corresponding result file will be generated in the log directory. The file stores the running status of the database when the crash occurs, and prints the use case name, SQL statement, exception stack ID, crash stack, and other information.
[0050] Stage 4: Combined with the downtime stack, users can locate the abnormal information.
[0051] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims
1. A white box anomaly testing method capable of achieving high coverage and high efficiency, characterized in that: The specific steps are as follows: S1. Add white-box exception handling code logic to database products; S2. The tester specifies the database test target and starts the test program of all the use cases in the use case library; the test program executes each use case in turn, and collects the exception events caused by the database exception handling code being triggered when the use case is executed. The specific method is as follows: each time a use case is read, an empty stack pool is initialized for the use case under test; whenever the exception handling code in the database is triggered, a function call stack of the current execution point of the use case under test is generated through the database function, the function call stack is stored in the stack pool corresponding to the use case under test, and the stack pool information of the use case under test is stored in the temporary file corresponding to the use case under test; S3. The test program performs an exception test on all the use cases in the use case library. The specific method of performing an exception test on each use case is as follows: the test program reads each use case and the stack pool information in the temporary file corresponding to the use case; performs an exception test on all function call stacks in the tested use case, and records the exception information corresponding to the function call stack that causes the database to fail to operate normally into the log; S4. Locate the abnormal information according to the log; Store the function call stack in the stack pool corresponding to the test case. The specific method is as follows: S21, converting the function call stack into a verification code through a hash algorithm; S22, the test program determines whether the verification code generated in step S21 exists in the stack pool of the current test case, if it exists, the test case continues to be executed, if not, the verification code is stored in the stack pool, and then the test case continues to be executed; S23. The test program repeats steps S21 and S22 until the current use case is completed.
2. A white box anomaly testing method capable of achieving high coverage and high efficiency according to claim 1, characterized in that: In step S2, the tester specifies database test targets including memory exception test and kill process exception test.
3. A white box anomaly testing method capable of achieving high coverage and high efficiency according to claim 1, characterized in that: The stack pool information includes the number of function call stacks of the use case.
4. A white box anomaly testing method capable of achieving high coverage and high efficiency according to claim 1, characterized in that: In step S3, an exception test is performed on all function call stacks in the test case, and the exception information corresponding to the function call stack that causes the database to fail to operate normally is recorded in the log. The specific method is as follows: S31, the test program reads the test case, and when the exception handling code of the database is triggered, detects whether a corresponding function call stack appears, throws an exception only when the function call stack appears, and removes the function call stack from the stack pool corresponding to the test case; S32. When an exception is thrown, the test program checks the database status. If the status is normal, the test program continues to execute. If a downtime occurs, the test program records the exception information, restarts the database, re-executes the current use case, but does not reload the stack pool corresponding to the test case. S33. The test program repeats steps S31-S32 until the stack pool of the current use case is cleared, that is, all the situations in which the exception handling codes in the tested use case are triggered are covered.
5. A white box anomaly testing method capable of achieving high coverage and high efficiency according to claim 4, characterized in that: In step S3, the exception information includes the use case name, SQL statement, the stack ID where the exception is thrown, and the downtime stack.