Summary of unit test and white box test

I. Software Testing Methods

1. software testing methods include white box testing, black box testing, gray box testing, static testing, and dynamic testing.

2. white-box testing: it is a test case design method. Here the box refers to the software to be tested, and the white box, as the name suggests, is visible, you can understand what is inside the box and how it works. Therefore, white box testing requires you to have a clear understanding of the internal structure and working principle of the system, design your use cases based on this knowledge.

Blackbox exporter

White box testing technology can be divided into static analysis and dynamic analysis.

Blackbox exporter modules

Static analysis includes control flow analysis, data flow analysis, and information flow analysis.

Dynamic analysis mainly includes logical coverage testing (branch testing, path testing, etc.) and program plug-in.

Advantages of white-box testing: it forces testers to think carefully about the implementation of software, detect every branch and path in the code, reveal errors hidden in the code, and thoroughly test the code; optimized.

Disadvantages of white-box testing: expensive; failure to detect missing paths and data sensitivity errors in the Code; failure to verify the correctness of specifications.

3.Black box testing is also called function testing.This is because the Black Box test focuses on the function implementation of the tested software, rather than the internal logic. In the black box test, the internal structure and operation of the tested object are invisible to the testers. The tester verifies the tested product based on its specifications, verify its consistency with the specifications.

Most of the Black Box tests that are not attended by users are: functional testing, Capacity Testing, security testing, load testing, prometheus blackbox exporter  restoration testing, Benchmark Testing, stability testing, and reliability testing.

4. Gray-box testing: white-box testing and black-box testing are often not separated. Generally, the black-box testing method is used in white-box testing and the white-box testing method is used in black-box testing. Gray-box testing is a test between white-box testing and black-box testing.

The most common gray-box testing is integration testing..

5. static testing: a technology that does not pass the execution of a program. Its key function is to check whether the representation and description of the software are consistent, blackbox exporter docker without conflict or ambiguity.

6. Dynamic Testing: contains specific expected results for the program to run in a controlled environment. It shows whether a system is in the correct or incorrect status.

Unit testing belongs to the white-box testing category; integration testing belongs to the gray-box testing category; and system testing belongs to the black-box testing category..

Ii. Unit Test

1. concept:Unit testing is a test of the basic components of the software, such as functions or methods of a class. The unit here is the minimum unit of software design.

Two steps of unit test: Manual Static check and dynamic execution tracing.

Manual Static check is the first step in testing. This phase ensures the logic correctness of the code algorithm (try to discover the logic errors of the Code through manual check), clarity, standardization, consistency, algorithm efficiency, and as much as possible to discover errors not found in the program.

The second step is to design a test case and execute the program to be tested to track and compare the actual results with the expected results to find errors.

2. Manual check: blackbox exporter tcp example

(1) Check the logic correctness of the algorithm: Determine whether the written code algorithm and data structure definition (such as queue and stack) have implemented the functions required by the module or method.

(2) Check the correctness of the Module Interface: Determine whether the number of formal parameters, data type, and order are correct; Determine the correctness of the return value type and return value.

(3) check whether the input parameter is correct: If the parameter is not correct, check whether the parameter is correct. Otherwise, add the parameter correctness check.

(4) Correctness of calling other method interfaces: Check whether the real parameter type is correct, whether the input parameter value is correct, and whether the number is correct, especially the method with polymorphism. Whether the returned value is correct or not. Do you misunderstand the meaning indicated by the returned value. It is best to use the display code to check the correctness of the returned values of each called method. If an exception or error occurs in the called method, feedback should be given and appropriate error handling code should be added.

Blackbox exporter tcp

(5) error handling: the module code must be able to anticipate error conditions and set appropriate error handling so that once a program fails, it can reschedule the program, to ensure the correctness of its logic, such error handling should be part of the module function. If one of the following conditions occurs, it indicates that the module's error handling function contains errors or defects: the error description is difficult to understand; the error description is insufficient to locate the error and determine the cause of the error; the displayed error information is inconsistent with the actual error cause; the error conditions are not correctly handled; Before the error is handled, the error conditions have caused system intervention.

(6) Ensure expression and SQL statement correctness: Check the syntax and logic of the compiled SQL statement. The expressions should not include ambiguity. For expressions or operators that are prone to ambiguity, the priority (such as <, =,>, &, ||, ++, and) you can use the "()" operator to avoid ambiguity. This ensures the correctness and reliability of the code and improves the readability of the Code.

(7) Check the correctness of constants or global variables: Determine the values, values, and Data Types of the constants or global variables used; ensure the consistency of each constant reference with its values, values, and types.

(8) standard consistency of the definition of the symbol: ensure that the variable name can be known and concise, but not too long or too short, standardized, easy to remember, it is best to be able to spell. Make sure that the same token is used to represent the same function. Do not use the same token to represent different functions. Do not use the same token to represent different functions.

(9) Consistency and standardization of the program style: the Code must be in line with enterprise specifications, and ensure that the Code style of all members is consistent, standardized, and neat. For example, to loop the array, do not use the subscript variable from bottom to top (for example: for (I = 0; I ++; I <10 )), later, we will use the top-down mode (for example, for (I = 10; I --; I> 0). We should try to use the unified method, or use the unified bottom-up mode, or unified from top to bottom. We recommend that you use the for loop and while loop instead of the do {} while loop.

(10) check whether the mysterious numbers used in the program are defined using the specifiers: mysterious numbers include constants, array sizes, character locations, conversion factors, and other numeric values written in text in the program. In the program source code, a number with the original form does not provide any indicative information about its importance or function, which also makes it difficult for the program to understand and modify. This type of mysterious number must be represented by a corresponding scalar. If this number may be used throughout the system, be sure to define it as a global constant; if this mysterious number is used in a class, it can be defined as the attribute of the class ), if this mysterious number appears in only one method, be sure to define it as a local variable or constant.

(11) check whether the code can be optimized and the algorithm efficiency is the highest: for example, whether SQL statements can be optimized, and whether one SQL statement can be used to replace Multiple SQL statements in the program, whether the loop is necessary and whether the statements in the loop can be extracted out of the loop.

(12) Check whether your program is clear, concise, and easy to understand: Note: lengthy programs are not necessarily clear.

(13) check whether the internal comments of the method are complete: whether the annotations are clear and concise; whether the code functions are correctly reflected; whether the comments with errors are worse than those without comments; and whether redundant comments are made; there is no need to comment out the code that is easy to understand.

(14) check whether the annotation documents are complete: whether the annotations for packages, classes, attributes, method functions, parameters, and return values are correct and easy to understand; whether a parameter is commented out, whether the parameter type is correct, and whether the parameter's limit value is correct. Especially for comments about mysterious values in the form parameters and return values, such as: type parameters should indicate what 1 represents, 2 represents, and 3 represents. Comments to the returned result set should contain the fields, field types, and field sequence in the result set.

3. Dynamic execution tracking: dynamic execution testing is usually divided into black box testing and white box testing. For unit tests, the white box testing method should be used to perform internal tracking and inspection tests for each module. For unit white box testing, the program module should be checked as follows: (1) test all independent execution paths in the module at least once; (2) determine all logic, take "true" and "false" at least once. (3) execute the loop body within the loop boundary and operation boundary. (4) test the effectiveness of internal data.

4. Unit Testing aims to discover various internal errors of each module, mainly based on white box testing.

The purpose of unit testing is to verify the consistency between the unit code and the detailed design document, track the implementation of the design in the detailed design document, and find errors in the detailed design document; errors introduced during encoding are found.

5. common Errors of a unit: (1) Unit Interface; (2) local data structure; (3) independent path; (4) error handling; (5) boundary condition.

6. unit test strategies: There are three independent unit test strategies: top-down unit test policies and bottom-up unit test policies.

Independent Test Strategy: design the pile module and drive module for each module without considering the relationship between each module and other modules. Each module performs independent unit tests.

Top-down test strategy: first test the top-level unit, and make the unit called by the top-level unit into the pile module. The second layer is tested, and the units tested above are used as the driver module. And so on until all modules are tested.

Test from bottom up: first, perform unit tests on the modules at the lowest layer on the module call Hierarchy Diagram, and simulate the modules that call this module as the driver module. Then, perform unit tests on the previous layer and use the tested modules below as the pile module. And so on until all modules are tested.

7. unit test process: four stages: Plan (what to test), design (test plan, strategy), implementation (write test cases, code), and execution (test report.

8. unit test principles: (1) Conduct Unit Tests on brand-new code or modified code; (2) Conduct Unit Tests according to unit test plans and solutions to eliminate testing randomness; (3) The unit test plan, unit test plan, and unit test cases must be reviewed. (4) when the test results of the test cases are inconsistent with the expected results, the execution personnel of the unit test should truthfully record the actual test results; (5) the unit test can be completed only when the end criteria in the test plan are met; (6) and code coverage requirements for tested units.

Iii. Test Cases

1. Introduction:Test Case)Is a set of test inputs, execution conditions, and expected results for a specific purpose to test a program path or verify whether a specific requirement is met. It also refers to the description of a testing task for a specific software product, reflecting the testing scheme, method, technology and strategy. The content includes the test objectives, test environment, input data, test steps, expected results, test scripts, and other documents.

Different types of software have different test cases.

2. Overview: test cases constitute the foundation of the design and development of the test process. The "depth" of the test is proportional to the number of test cases. Because each test case reflects different scenarios, conditions, or product event streams, as the number of test cases increases, you will have more confidence in the product quality and test process.

One of the main evaluation methods for determining whether the test is complete is requirement-based coverage.This is based on the number of test cases that are determined, implemented, and/or executed.

The test workload is proportional to the number of test cases. The best solution is to prepare at least two test cases for each test requirement. A test case is used to prove that the requirement has been met. It is usually called a positive test case. Another test case reflects an unacceptable, abnormal, or unexpected condition or data used to demonstrate that this requirement can be met only under the required conditions. This test case is called a negative test case.

3. Design Method:

(1) white box technology:The white-box test is a structure test, so the tested object is basically a source program. The test case is designed based on the internal logic of the program..

White-box test case design: generally usedLogical coverageAndBasic Path MethodDesign.

Logic coverage is a test case design technology based on the internal logic structure of the program. This method requires the tester to have a clear understanding of the logical structure of the program. Logical coverage can be divided into statement coverage, decision coverage, condition coverage, Decision-condition coverage, condition combination coverage, and path coverage.

Statement coverage: During the test, a number of test cases are designed first, and then the tested program is run so that each executable statement in the program can be executed at least once.

Decision coverage: During the test, a number of test cases are designed first, and then the tested program is run, so that each of the true branches and false branches in the program will go through at least once, that is, the true or false values are satisfied.

Conditional coverage: in the test, a number of test cases are designed first, and then the tested program is run. The possible values of each condition in each judgment must be met at least once.

Determination Condition coverage method: During the test, several test cases are designed first, and then the tested program is run, so that all conditions in the judgment may appear at least once, in addition, each judgment result may appear at least once.

Path coverage: During the test, several test cases are designed first, and then the tested program is run, which requires that all possible paths in the program be overwritten.

Basic path coverage method: Based on the control flow diagram of the program, this method analyzes the loop complexity of the control structure, exports the set of basic executable paths, and designs test cases. This method compresses the Number of Covered paths to a certain limit, and the loop body in the program can be executed only once at most. The designed test cases must ensure that each executable statement of the program is executed at least once during the test.

Cyclic path test: the basic path coverage method limits the number of loops at most once. This greatly reduces the number of paths to be overwritten, but does not fully test the loop, therefore, you also need to test the circular path. Cyclic path testing includes simple cyclic testing and nested loop testing.

Each method has its own advantages and disadvantages. Generally, when designing test cases, we should select the coverage method based on the complexity of the Code module. The complexity of the general code is directly proportional to the complexity of the test case design. Therefore, the designer must be single and highly cohesive in the module or method functions to make the method or function code as simple as possible. This will greatly improve the ease of test case design, improve the coverage of test cases.

The basic path test method is based on the control flow diagram of the program. By analyzing the loop complexity of the control structure, the basic executable path set is exported to design the test case method. The designed test case should ensure that each executable statement of the program in the test should be executed at least once. The basic path test includes the following five aspects: (1) control flow diagram of the program: A graphical method describing the control flow of the program; (2) Complexity of the program environment: McCabe complexity measurement; from the loop complexity of the program, you can export the number of independent paths in the set of program basic paths, which is the upper bound of the number of test cases required for each executable statement in the program to be executed at least in sequence. (3) export test cases; (4) Prepare test cases to ensure the execution of each path in the basic path set; (5) graphic matrix: it is a software tool that assists in basic path testing. It can be used to automatically determine a basic path set.

In addition to meeting the selected coverage (or coverage criteria), the selection of test cases also requires the use of common design methods such as the Boundary Value Analysis Method and the error inference method. The boundary value analysis method is used to design reasonable and unreasonable input conditions. The condition boundary test case should include the input parameter boundary and condition boundary (if, while, for, switch, SQL WHERE clause ). The error inference method lists all possible errors and special circumstances that are prone to errors in the program, and selects test cases based on them; many common and suspected errors can be found in the coding and unit test phases. These errors should be tested with emphasis and corresponding test cases should be designed.

(2) Black Box Technology: equivalent classification, Boundary Value Analysis, error speculation, cause and effect, and comprehensive strategy

4. design of the test class: a module or method is not an independent program. When considering testing it, consider its connection with the outside world, use auxiliary modules to simulate other modules associated with the tested modules. These auxiliary modules are divided into two types:

(1) DRIVER: equivalent to the main program of the tested module. It receives test data, transmits the data to the tested module, and then outputs the actual test results;

(2) pile module (stub): used to replace the sub-module called by the tested module. The pile module can perform a small amount of data operations without bringing all the functions of the sub-module, but it does not allow or do anything.

Piling: During unit or integration testing, if an external function to be called for a certain statement of a program Unit has not been designed, encoded, or debugged, you can simply let it return several values that support test cases. In this state, external functions are generally called "piling ".

The measurement module and its related driver module and pile module constitute a "test environment ".

Writing the driver module and the pile module brings additional overhead to the test. Because they are not delivered together as part of the product during software delivery, and their compilation requires a certain amount of work. In particular, the pile module cannot simply provide the information "once entered. In order to be able to correctly test the software, the pile module may need to simulate the functions of the actual sub-module, so that the establishment of the pile module is not very easy.

It is difficult and time-consuming to compile the pile module. In fact, you can avoid writing the pile module. You only need to compile the code of the actual pile module before the tested module in Project Progress Management. In this way, the test efficiency can be improved, and the testing frequency of the actual pile module can be improved to ensure the product quality more effectively. However, in order to ensure a stable and reliable practical pile module can be provided at the upper level and lay a good foundation for subsequent module tests, the driver module is still indispensable.

For each package or sub-system, we can compile a test module class based on the test cases to implement the driver module for all the modules to be tested in the test package. Instead of using a method to test the function in each class, we recommend that you test all methods in the class. The advantages are: (1) Being able to test all methods or modules in the package at the same time, or easily test and track the specified modules or methods; (2) can use all test cases to perform tests on the same piece of code and discover problems. (3) perform regression tests. After a module is modified, all tested modules or methods can be executed as long as the test class is executed. This not only makes it easy to check and track the modified Code, but also checks the impact of the modification on the related modules or methods in the package, so that the introduced modification errors can be promptly discovered; (4) Reuse the test method to ensure the durability of the test unit, and use existing tests to write related tests. (5) Separate the test code from the product code, make the code clearer and concise; Improve the maintainability of the test code and tested code.

5. Tracking and debugging: it is the best way to track debugging, but not to thoroughly test the code. It is also a good tool for program debugging to find the root cause of errors. After the test class is designed, it is best to use the code troubleshooting tool to track and debug the code segment to be tested to thoroughly check the logic errors of the Code. Existing Code development tools (such as JBuilder) are generally integrated with such troubleshooting tools. Troubleshooting tools are generally composed of execution control programs, execution status query programs, and tracing programs. The execution control program includes breakpoint definition, breakpoint revocation, one-step execution, breakpoint execution, and conditional execution. Execution status query programs include registers, stack status, variables, code, and other state information related to the program. A tracing program is used to track the sequence of events (for example, branches and subprograms) experienced during program execution ). Programmers can identify, locate, and correct program errors by identifying various States during program execution.

It is best to perform unit tracking and debugging for the module: after each module is modified, all test cases are tracked and executed once to eliminate all possible or introduced errors. In case of limited time, the driver module must also be called to execute all test cases once and trace and execute test cases with errors or exceptions once to find the root cause of the problem.

Troubleshooting is often a difficult process, especially for modules with complicated algorithms and many sub-modules. It is not easy to locate errors. Although troubleshooting is not a studious technique (sometimes people prefer to call it art), there are still a number of effective methods and strategies. The following describes the methods and strategies used in troubleshooting: (1), breakpoint settings, Set breakpoint to implement breakpoint tracking for the source program will greatly improve the efficiency of troubleshooting. In general, in addition to settings based on experience and error information, you should also focus on the following types of statements: A. function call statements. The Calling statement of a sub-function is the focus of the test. On the one hand, the interface reference error may occur when the sub-function is called, and on the other hand, the sub-function error may occur. On the other hand, the transfer/loop statement is determined. A judgment statement may often cause errors or failures due to boundary values and comparison priorities. Therefore, it is also an important test point for determining transfer/loop statements; C and SQL statements. For database applications, SQL statements often occupy more important business logic in the module and are complex. Therefore, it is also a statement that is prone to errors. D. It is a complex algorithm segment. The error probability is often proportional to the complexity of the algorithm. Therefore, the more complex an algorithm, the more important it needs to be tracked, such as recursion and rollback. (2) view suspicious variables. When the program stops executing a statement, you can view the current value of the variable and the current attribute of the object. By comparing the current value and the expected value of these variables, you can easily locate the root cause of the program problem. (3) Check the SQL statement execution, print the SQL statements that are suspected to be incorrect during tracking execution or running, and then re-query the analyzer (such as Oracle SQL plus) in the Database SQL query) SQL statement errors can be checked and corrected efficiently during tracking and execution. (4) Pay attention to the cluster phenomenon, experience shows that the number of residual errors in the program after testing is proportional to the number of errors found in the program or the error detection rate. According to this rule, the program segments of the wrong cluster should be tested to improve the efficiency of the test investment. If you find that a code segment seems more prone to errors than other program modules, you should spend a lot of time and cost testing this program module.

6. basic Principles of test case design: (1) a good test case can be used to discover errors that have not yet been found; (2) the test case should be composed of the test input data and the expected output results. (3) during the design of the test case, it should contain reasonable input conditions and unreasonable input conditions.

7. Specific test case practices:

(1) test case document: the preparation of the test case document should have a document template that must comply with internal specifications.

(2) Test Case settings: Use Cases are set by function, use cases are set by path, and use cases are set by function and Path in hybrid mode;

(3) design test cases: test cases can be divided into basic events, alternative events, and exception events.

Iv. white box testing

1. white box testing generally includes the following items:

(1) Purpose: ensure that the classes and interfaces created by the program are complete and correct, and that the program module runs properly independently. This ensures the functional completeness, correctness, and stability of local modules.

(2) test item: class to be tested.

(3) test basis: A. Requirement Specification and case description list; B. design documents; C. coding specifications; D. Development naming standards.

(4) guidelines for adoption: the created classes, interfaces, methods, and attributes should be consistent with the design document; various naming, comments, and code line formats of programs must comply with the program development naming standards and coding specifications. program modules can run independently and stably.

(5) test environment configuration: A. test tools; B. software environment.

2. Test procedure:

(1) configure the test environment;

(2) compile test cases;

(3) static testing and lookup code;

(4) dynamic testing;

(5) Determining problem attributes: errors, defects, failures, and faults are classified into four categories.

Errors refer to calculation between values, observed values, measured values, or between conditions and true values, which do not conform to specified or theoretically correct values or conditions.

A defect is a deviation from the expected value or feature value.

Failure means that functional components cannot perform the required functions. Faults may be caused by errors, defects, or failures.

Failure refers to the loss of the ability of a functional component to execute its functions, and the ability of a system or system component to execute the required functions within the prescribed limits.

(6) determine the problem category;

(7) Fill in the test report.

3. differences between white-box testing and unit testing: (1) Purpose: one is to test the overall logic of the program, the other is to test an independent module in the program; (2) generally, the executors are different: White boxes are generally completed by dedicated white-box testers, and unit tests are generally completed by programmers themselves.

Routine:

# Include "gtest/gtest. H "# include <iostream> using namespace STD; int fun (int A, int B, int X) {if (a> 1 & B = 0) {x = x/a;} else {} if (a = 2 | x> 1) {x = x + 1;} else {} return X ;} // statement overwrite: each executable statement in the program executes test (testcase1, case1) {expect_eq (2, fun (2, 0, 3) at least once )); // goodexpect_eq (4, fun (2, 1, 3); // bad} // decision overwrite method: so that each of the true and false branches in the program will go through at least one time, that is, the true and false values of the judgment have been met by test (testcase1, case2) {expect_eq (4, fun (1, 0, 3); Objective C T_eq (1, fun (1, 0, 1);} // condition overwriting method: Make sure that the possible values of each condition in each judgment meet at least one test (testcase1, case3) {expect_eq (2, fun (2, 0, 3); expect_eq (1, fun (1, 0, 1); expect_eq (2, fun (2, 1, 1);} // Method of Determining Condition coverage: this means that all conditions in the judgment may appear at least once, and each judgment result may appear at least once test (testcase1, case4) {expect_eq (2, fun (2, 0, 3); expect_eq (2, fun (2, 1, 1); expect_eq (4, fun (1, 0, 3); expect_eq (1, fun (1, 1, 1);} // path overwrite method: overwrite all possible paths in the program test (testcase1, case5) {expect_eq (2, Fu N (2, 0, 3); expect_eq (1, fun (1, 0, 1); expect_eq (2, fun (2, 1, 1 )); expect_eq (0, fun (3, 0, 1);} int main (INT argc, char ** argv) {: Testing: initgoogletest (& argc, argv ); return run_all_tests (); cout <"OK! "<Endl; return 0 ;}

Summary of unit test and white box test