White Box test method

White Box test , English is the testing. Also known as structural testing or logic-driven testing.

The white box test is to think of the test object as an open box. When using the White-box test method for dynamic testing, it is necessary to test the internal structure and processing process of software products without testing the function of software products.

The coverage standard of the White box test method is logic overlay, loop overlay and basic path test. The logic overrides include statement overlay, decision overlay, conditional override, decision/condition overlay, conditional combination override, and path overlay.

White box testing is to know the internal work process, can be tested to detect whether the internal action of the product according to the specifications of the normal, according to the procedures within the structure of the test procedures, the test procedures in each path is able to work according to the predetermined requirements, regardless of its function, The main methods of white box testing are logic-driven, base-path test, etc., which are mainly used for software verification.

White box test common tools are: Jtest, Vcsmith, jcontract, C + + Test, Codewizard, Logiscope.

In White-box testing , testing can be done using a variety of test methods. However, the following 5 questions should be considered when testing:

1) Try to use the automated tools for static structural analysis in the test.

2) testing is recommended to start with static testing , such as: static structure Analysis , code walking and static quality measurement, and then dynamic testing , such as: coverage testing.

3) The results of static analysis are used as the basis, and then the static analysis results are further confirmed by code checking and dynamic testing, which improves the test efficiency and accuracy.

4) Coverage testing is an important means of white box testing, in the test report can be used as a basis for quantitative indicators, for the focus of the software module, you should use a variety of coverage standards to measure the coverage of the code.

5) in different testing stages, the focus of testing is different.

In the unit testing phase: The program syntax check, program logic check, code check, logical overwrite is the main.

During the integration test phase: static structural analysis, static quality measurement, and interface testing are required.

In the system testing phase: In the real system working environment by comparing with the system requirements definition, verify whether the complete software configuration item can connect with the system correctly, and find out that the software and the System/subsystem design document and the software development contract stipulation does not conform to or contradicts with it Verifying that the system satisfies the definition of requirement specification, finds out the inconsistency or contradiction with the requirement specification, and proposes a more perfect plan to ensure that the final software system meets the requirements of the product and conforms to the standards and regulations of the system design.

Acceptance testing Phase: according to the requirements of development, experience whether the product can meet the requirements of the use of the original design level, the completion of the function, whether it meets the needs of users, in order to achieve the intended purpose.

1. Code Check

Code checking is the main method of static testing, which includes code walking, desktop checking, flowchart review , and so on. The following points describe the code review.

(1) Overview

Code inspection mainly check the consistency of code and flow graph design, the rationality of code structure, the standard of code writing, readability, and the correctness of the logical expression of code. It includes variable checking, naming and type review, Program logic Review, program grammar Check, and program structure check.

The most common static test is to find out the syntax errors of the source code, which can be done by the compiler .

(2) Purpose of code checking

The code check is for the following purposes:

Check whether a program is written according to a standard or specification.

Discovery of procedural defects.

The error that the program generated was found.

Check that the code is not a flowchart requirement.

Check that there are no missing items.

Make your code portable because your code often needs to run on different hardware or compile with a different compiler.

Make your code easy to read, understand, and maintain.

(3) Documentation required for code inspection

Before conducting the code review, you should prepare the requirements documentation, the program design documentation, the source code list of the programs, Code coding standards, code defect checklists, and flowcharts.

2, code check the way

There are 3 ways to check your code, as described below.

1) Desktop Check

Desktop inspection is the process by which programmers analyze, test, and supplement the source code to find errors in the program.

Since programmers are familiar with their own programs, they can be examined by programmers themselves, which can save a lot of time, but be careful to avoid their own subjective judgment.

2) go to check

Walk-through is a programmer and tester composed of the review team through the logic of running the program , found the problem. Team members should read the design specifications, program text and other related documents in advance, and use test cases to make the program logic run.

Walk-through can be divided into the following two steps:

The head of the ① group sends the material to each member and then the team members to identify the problem.

② through the records, the team members of the program logic and function to raise their own questions, meeting to discuss the problems found and solutions.

3) Code Review

Code review is the process by which a review team composed of programmers and testers makes static analysis of a program by reading, discussing, and analyzing technology.

Code review can be divided into the following two steps:

① team leader to the program text, specifications, related requirements, flow chart and design instructions to each member.

② Each member takes the material as a basis for review, but the programmer explains the structure, logic, and source of the program . In the process, the team members can ask their own questions, and the programmer will be able to explain their own procedures, but also found that they did not notice the problem.

In order to improve efficiency, the panel may prepare a common list of errors to be provided to participating members in a cross-examination before the review session.

In real-world applications, code inspection can quickly find 20%~30% coding flaws and logical design flaws, and code checks see the problem itself rather than the symptoms of the problem. Code walk-through is time consuming and requires knowledge and experience to accumulate.

3. Code Inspection Project

The Code review project is described below.

1. directory File Organization

　　The directory file organization adheres to the following guidelines:

1) All the filenames are simple and clear, see the name of the idea.

2) Clear grouping of files and modules.

3) Each line of code is within 80 characters.

4) Each file contains only one complete module of code .

2. Check function

Check the function to follow these guidelines:

1) The function head clearly describes the functions of the function.

2) The name of the function clearly defines what it is going to do.

3) the definition and sequencing of each parameter follow a specific order.

4) All the parameters are useful.

5) function parameter interface relationship is clear and unambiguous.

6) The algorithm used by the function should be described.

3. data types and variables

The following principles apply to data types and variables:

1) Each data type has its own explanation.

2) Each data type has the correct value.

3) data structure as simple as possible, reduce complexity.

4) The name of each variable is a clear representation of what it represents.

5) All the variables are coat them?

6) The description of all variables should be clear.

4. Check the conditional Judgment statement

Check the conditional judgment statement to follow these guidelines:

1) Condition checks and code are clearly disclosed in the program.

2) The use ofif/else is correct.

3) numbers, characters and pointers are clearly judged.

4) The most common situation is the first judgment.

　　5. Check the cycle system

Check the loop system to follow these guidelines:

1) Any loop must not be empty.

2) The circulation system is clear and understandable.

3) Use a For loop when there are clear multiple loop operations.

4) Circular naming should be meaningful.

5) The cyclic termination condition is clear.

　6. Check code comments

Follow these guidelines when reviewing code comments:

1) There is a simple description of the code structure.

2) Each file and module should have a corresponding explanation.

3) Source code can be self-explanatory, and easy to understand.

4) The explanation of each code explicitly expresses the meaning of the code.

5) All comments should be specific and clear.

6) All useless code and comments to delete.

7. Desktop Inspection

Be aware of the following issues when you perform a desktop check:

1) Check the consistency of the code and design.

2) code to follow the standards, readability.

3) The correctness of the code logic expression.

4) The rationality of the code structure.

5) The conformity of the program writing and writing standards.

6) unsafe, ambiguous and ambiguous parts of the program.

7) Programming style issues and so on.

8. Other Checks

　　Other checks include the following:

1) Extended character, encoding, compatibility, warning/prompt information of the software.

2) Check the cross-reference table of variables: Check for unspecified variables and variables that violate the type specification, as well as the reference and usage of variables.

3) Check the cross-reference table of the labels: Verify the correctness of all the labels.

4) Check subroutines, macros, functions: Verify that each call and the location being called are correct, that the calling subroutine, macro, function exists, and the parameters are consistent.

5) Equivalence check: Check the consistency of the types of all equivalent variables.

6) Constant check: Confirm the value and number of constants, data type.

7) Standard check: Check whether there is a violation of standards in the program.

8) style check: Check the design style of the program.

9) Compare control Flow: Compare design control flow graph and actual program generated control flow graph difference.

10) Select, activate the path: Select a path in the design control flow graph, then activate the path in the actual program, or the program may be wrong if it cannot be activated.

11) Supplemental Documentation: According to the above inspection project, code rules, specifications and checklists can be compiled as test cases.

12) control the specifications of the program, read the source code in detail, compare the actual code, from the differences found in the program problems and errors.

13) Check the coding requirements of the syntax format and rules (such as typography, annotations, identifier naming, readability, variables, functions, procedures, testability, program efficiency, quality assurance, code editing, compilation, review, code testing, maintenance, macros) that must be followed by the prescribed code.

In the manual code inspection, you can make code to go through the defect table. In the Defect checklist, we list typical errors encountered in the work, as follows:

(1) Format section

If the nested if is indented correctly.

Comments are accurate and meaningful.

Whether the symbols used are meaningful.

Whether the code is basically consistent with the module pattern at the beginning.

Compliance with the full set of programming standards.

(2) connection of inlet and outlet

The initial entry and final exit are correct.

Whether the transferred parameter value is set correctly.

Whether the unexpected condition of the critical called module is handled (such as loss, confusion).

For each invocation of another module, all required parameters are passed to each called module.

(3) Memory problems

Whether each domain is initialized correctly before the first use.

The specified domain is correct.

Whether each domain has the correct variable type declaration.

(4) Judgment and transfer

Used to determine if the variable is correct.

Whether the right conditions have been judged.

Each transfer target is executed correctly and at least once.

(5) Performance

Performance is optimal.

(6) maintainability

Whether the manifest format is suitable for improved readability.

The logical meaning of the code between each block.

(7) logic

Whether all designs have been implemented.

What the code does is design-defined content.

Whether each loop has performed the correct number of times.

(8) Reliability

Whether the data collected from the external interface has been confirmed.

(9) Memory design

Whether the subscript of an array or pointer is out of bounds.

Whether to modify the contents of a pointer to a constant.

Whether the memory exhaustion problem is handled effectively.

If there is an irregular pointer (the pointer variable is not initialized, the memory is freed with free or delete, and the pointer is forgotten to be set to null).

Whether to forget to assign an initial value to arrays and dynamic memory.

Checks whether the pointer value is null immediately after requesting memory with malloc or new.

(10) Advanced features about classes

Whether the rules of inheritance and composition are violated

2.2.4 Static Structure Analysis

Static structure analysis mainly graphically shows the internal structure of the program, such as function call graph, function internal control flow graph.

Static structure analysis is a test tool to analyze the program source code of the system structure, data structure, data interface, internal control logic and other internal structures, generate function call graph, module control flow graph, internal file call graph and other graphic diagrams, clearly identify the entire software composition structure, easy to understand, Examine the software for defects or errors by analyzing these diagrams, including control flow analysis, Data flow analysis, interface analysis, and expression analysis.

The structure of the system is demonstrated through the invocation relationship between the functions of the application, which can be implemented by listing all functions, using lines to represent call relationships and functions. The static structure mainly analyzes the following content:

1) Check that the function's calling relationship is correct.

2) Whether there is an orphaned function that is not called.

3) The frequency with which the function is called is defined, and the function that is called frequently can be examined emphatically.

White Box test method