Software testing – explain the basic concepts of white box testing, four white box testing methods

This is the third day of my participation in Gwen Challenge

In the last article, we talked about black box testing. Black box testing is relatively simple compared with white box testing. It does not need to understand the internal code of the program and has nothing to do with the internal implementation of the software. White box testing, like a transparent box, requires testers to design test cases using the logical structure inside the program, which is more difficult than black box testing.

In this article, we will explain the basic concepts of white box testing and the four commonly used white box testing methods.

I. Basic concepts of white box testing

1. Definition of white box testing

White box testing, also known as structural testing or logic-driven testing, regards the test object as a transparent box. It allows testers to design test cases using the logical structure inside the program and test all the logical paths of the program.

2. Test object of white box test

White-box testing is based on the source code of the program being tested, not the requirements specification of the software.

When using the white-box test method, the tester must have a comprehensive understanding of the internal logic structure of the program, check the internal structure of the program, start from checking the logic of the program, test the relevant logical path, and finally get the test result.

3. Principles of white box testing

The following principles must be followed when using the white-box test method:

  • Ensure that all independent paths in a module are tested at least once.
  • All logical decisions are tested for both true and false.
  • Run all loops within upper and lower boundaries and operable ranges.
  • Check the internal data structure of the program to ensure its structure is valid.

4. Classification of white box tests

White-box testing methods fall into two categories: static testing methods and dynamic testing methods.

Static test: do not require the actual execution of the test program on the computer, mainly with some artificial simulation technology to analyze and test the software, such as code inspection method, static structure analysis, etc.;

Dynamic testing: it is the process of discovering program errors by entering a group of actual data constructed in accordance with certain test criteria in advance to dynamically run the program. The dynamic analysis techniques in white box test mainly include logic cover method and basic path test method. (★ ★ ★)

Two white-box testing methods are described below.

Two, static white box test

1, code inspection method

(1) Definition of code review

Code Review refers to the systematic Review of computer source Code to find and correct errors not found in the early stage of software development and improve the quality of software and developers.

(2) Purpose of code review

The purpose of code review is to produce qualified code, check whether the source code conforms to the coding requirements of the detailed design, and ensure the consistency and traceability between code and design.

(3) Method of code review

Code review includes desktop review, code review, and walk – through.

1) Desktop check (check by programmers themselves)

This is a traditional method of checking, in which programmers check their own programs. After the program is compiled, the programmer analyzes the source code, checks it, and adds relevant documents to find errors in the program.

2) Code review (the review team checks by reading procedures and checking against error checklists)

Code review is the process by which a review team of programmers and testers performs a static analysis of a program through reading, discussion, and controversy. The specific process is as follows:

The first step is to distribute the design specifications, control flow chart, program text and relevant requirements and norms to the team members in advance as the basis for review. After fully reading the material, the group members proceed to the next step of the review.

The second step is to convene a procedural review meeting. Each member of the team will review the materials handed out, but the programmer will explain the structure, logic and source code of the program. During this process, team members can ask their own questions; As programmers explain their programs, they can discover problems that they might not have noticed before.

Note: Requirements document, program design document, program source code list, code coding standards, code defect checklist and flow chart should be prepared before code inspection.

3) Walkthroughs (the review team needs to prepare representative test cases to run along the program logic)

Walkthroughs are basically the same as code reviews, and the process is divided into two steps:

Step 1: Distribute the materials to each member of the walk-through team and let them study the program carefully.

Step 2: Have a meeting.

In contrast to code review, having review team members “act” as computers means that test team members first prepare a representative set of test cases for the program under test and submit them to the review team. The walkthrough team meeting, the group plays the role of the computer, let the test case run along the logic of the program, record the trace of the program at any time, provide for the final stage of analysis and discussion.

(4) Code inspection rules

In code inspection, appropriate standards and rules should be selected according to the characteristics of the software under test.

(5) Code inspection items

  • Directory file organization
  • Check the function
  • Data types and variables
  • Check the conditional statement
  • Inspection cycle system
  • Review code comments
  • Desktop check
  • Other tests

2, static structure analysis

(1) Definition

In static structure analysis, the testers are often through the use of the system structure of the test tool analysis program source code, data structure, data interface, internal structure, such as internal control logic diagram, module control flow graph generation function call, internal documents called diagrams and graphs, charts, clearly identify the composition of the whole software structure.

(2) Purpose

By analyzing these diagrams, including control flow analysis, data flow analysis, interface analysis, expression analysis, etc., to make them easy to read and understand, and then by analyzing these diagrams, check for software defects or errors.

(3) Two methods of static structure analysis

1) Generate various charts to help with static analysis of the source program

Commonly used various reference tables are: ① label cross reference table; ② Variable cross-reference table; (3) subroutine (macro, function) reference table; (4) Equivalent table; ⑤ Table of constants.

The commonly used diagrams and control flow diagrams mainly include:

① Function call diagram: list all functions, with a line to represent the call relationship, through the application between the functions of the call relationship to show the structure of the system.

(2) Module control flow diagram: a graph composed of many nodes and the edges connecting nodes, in which each node represents one or more statements, the edge represents the control flow between nodes, used to display the internal logical structure of the function. (★ ★ ★)

2) Error static analysis

Static error analysis is mainly used to determine whether there is some kind of error or “dangerous” structure in the source program.

Type and unit analysis: data type errors and unit inconsistencies.

② Reference analysis: reference exception, variable assignment is referenced first, or assignment is not referenced.

③ Expression analysis: expression error, incorrect use of parentheses, array subscript out of bounds, etc.

(4) Interface analysis: module interface, parameter consistency.

Dynamic white box test

1. Logical coverage method

(1) Definition

Logical coverage is a test technology that designs test cases based on the internal logical structure of the program and realizes program coverage by traversing the internal logical structure of the program. It is one of the dynamic testing techniques in white box testing.

(2) Six logical coverage methods

From the analysis of the detail degree of covering source program statements, logical coverage includes the following six coverage standards:

  • Statement coverage (SC);
  • Decision coverage (DC);
  • Conditional coverage (CC);
  • Decision – conditional coverage (CDC);
  • Conditional combination coverage (MCC);
  • Path coverage.

Each of the six logical override methods will be explained in the following sections.

1) Statement coverage (SC)

Statement Coverage means that enough test cases are designed so that each Statement in the program under test is executed at least once. Also known as line coverage, segment coverage, basic block coverage, it is the most common coverage.

② Examples:

Question:

The following C language program statements and corresponding program flow chart:

int function(int x,int y,int z)   
{
  if(y>1 && z==0)           
   {
      x=(int)(x/y)
   }
  if(y==2 || x>1)
   {
     x=x+1
   }
 return x;
}

Copy the code

Use statement coverage to design test cases for this program.

Answer:

To make each statement execute at least once, we can construct the following test cases:

Input: x=4, y=2, z=0

The execution path is sacbed

Statement coverage tests whether the execution statement has been executed, but it does not test for logical errors in the program. Therefore, statement coverage is a weak coverage.

For example, if the first of the above program logic symbol “&” mistakenly wrote “| |”, using test cases also can cover all the statement execution sacbed path, but not found error. Also, if the second logic symbol “| |” mistakenly wrote “&”, using the same test cases can be executed all sacbed path statements, but can’t find the above logic errors.

③ Purpose of statement coverage:

The purpose of statement coverage is to test whether the code in the program is executed. It only tests the execution statements in the code, which do not include header files, comments, blank lines, and so on.

Statement coverage in a multi-branch program, only one path can be covered, so that each statement in the path can be executed at least once, but various branch combinations are not considered.

2) Decision coverage (DC)

(1) definition:

  • Decision Coverage is also known as branch Coverage. The principle of Decision Coverage is to design enough test cases so that the true-and-false branches of each Decision statement in the program are executed at least once.
  • In addition to double-valued decision statements, there are also multi-valued decision statements, such as case statements, so the more general meaning of decision coverage is to make every decision get every possible result at least once.

② Examples:

Question:

The following C language program statements and corresponding program flow chart:

int function(int x,int y,int z)   
{
  if(y>1 && z==0)           
   {
      x=(int)(x/y)
   }
  if(y==2 || x>1)
   {
     x=x+1
   }
 return x;
}

Copy the code

Use decision override to design test cases for this program.

Answer:

Taking the above code as an example, the following test cases can be constructed to determine the coverage criteria:

Input: ① x=1,y=3,z=0, the execution path is SACbd

(The judgment results are T and F respectively)

Enter: ② x=3,y=1,z=1, and run sabed

(The judgment results are F and T respectively)

The above two groups of test cases not only satisfy decision coverage, but also satisfy statement coverage, which shows that decision coverage is stronger than statement coverage. Therefore, as long as the decision coverage is satisfied, statement coverage must be satisfied, otherwise it is not.

Determine coverage is still as can’t find logic judgment and statement covering the symbol “&” mistakenly wrote “| |” logic errors.

Decision coverage only judges the final result of decision statement execution and ignores the value of each condition, so it also belongs to weak coverage.

3) Conditional coverage (CC)

(1) definition:

Condition Coverage refers to designing enough test cases so that each logical Condition in a decision statement is true and false at least once.

For example, if there are two logical conditions a>1 and C <0 in the decision statement if(A >1 OR C <0), ensure that the “true” and “false” values of A >1 and C <0 appear at least once when designing the conditions to cover the test cases.

② Examples:

Question:

The following C language program statements and corresponding program flow chart:

int function(int x,int y,int z)   
{
  if(y>1 && z==0)           
   {
      x=(int)(x/y)
   }
  if(y==2 || x>1)
   {
     x=x+1
   }
 return x;
}

Copy the code

Use conditional overrides to design test cases for this program.

Answer:

To make each condition of each judgment in the program true and false at least once, we can construct the following test cases:

Input: ① x=1,y=2,z=0, the execution path is sacbed

(The results of the conditions are TTTF respectively)

Enter: ② x=2,y=1,z=1, and run sabed

(The results of the conditions are FFFT respectively)

It can be seen from the test cases of conditional coverage that the truth value and false value of each logical condition appear at least once when two test cases are used. However, judging coverage still cannot be satisfied under the condition of conditional branch coverage, that is, bd path is not covered. Compared with statement coverage and decision coverage, conditional coverage reaches the maximum coverage of logical conditions, but cannot guarantee decision coverage.

4) Determination – Conditional coverage (CDC)

(1) definition:

  • It is required to design enough test cases so that the possible values of all conditions in a decision statement occur at least once, and the possible results of all decision statements occur at least once.
  • For example, for decision statementsif(a>1 AND c<1), the decision statement hasA > 1, c < 1Two conditions, when designing test cases, to ensureA > 1, c < 1Both conditions take “true” and “false” values at least once, and at the same time, judge the statementif(a>1 AND c<1)“True” and “false” also appear at least once.

② Examples:

Question:

The following C language program statements and corresponding program flow chart:

int function(int x,int y,int z)   
{
  if(y>1 && z==0)           
   {
      x=(int)(x/y)
   }
  if(y==2 || x>1)
   {
     x=x+1
   }
 return x;
}

Copy the code

Use decision condition overrides to design test cases for this program.

Answer:

To satisfy the decider-condition coverage principle, we can construct the following test cases:

Input: ① x=4,y=2,z=0, sacbed

(The results of judgment were TT, and the results of conditions were TTTT)

Input: ② x=1,y=1,z=1, overlay path: sabd

(The judgment results are FF, and the condition results are FFFF)

Decision – conditional coverage satisfies both decision coverage criteria and conditional coverage criteria, and makes up for their shortcomings. But decider-conditional coverage is not necessarily more logical than conditional coverage.

③ Disadvantages of decision – condition coverage: the combination of conditions is not considered.

5) Conditional Combination Coverage (MCC)

(1) definition:

Multiple Condition Coverage refers to designing enough test cases so that all possible combinations of conditions in each decision are performed at least once. The criteria of decision coverage, conditional coverage and decision – conditional coverage are satisfied.

② Examples:

Question:

The following C language program statements and corresponding program flow chart:

int function(int x,int y,int z)   
{
  if(y>1 && z==0)           
   {
      x=(int)(x/y)
   }
  if(y==2 || x>1)
   {
     x=x+1
   }
 return x;
}

Copy the code

Use conditional composite coverage to design test cases for this program.

Answer:

To satisfy the conditional combined coverage principle, we can construct the following test cases:

X =4,y=2,z=0, sacBED (TTTT)

Input: ② x=1,y=2,z=1, overlay path: sabed (condition result: TFTF)

Input: ③ x=2,y=1,z=0, overlay path: sabed

4 x=1,y=1,z=1, sabd (FFFF)

Since each of the four conditions has two values of “true” and “false”, there are 24=16 combinations of the results of all the conditions. However, when there are more decision statements in a program, there are more combinations of conditional values. The number of test cases that need to be designed will also increase, which will reduce the efficiency of testing.

6) Path coverage

(1) definition:

Path coverage refers to designing enough test cases so that every possible combination of paths in a program is executed at least once.

② Examples:

Question:

The following C language program statements and corresponding program flow chart:

int function(int x,int y,int z)   
{
  if(y>1 && z==0)           
   {
      x=(int)(x/y)
   }
  if(y==2 || x>1)
   {
     x=x+1
   }
 return x;
}

Copy the code

Use path coverage to design test cases for this program.

Answer:

To satisfy the path coverage principle, we can construct the following test cases:

Input: ① x=4,y=2,z=0, sacbed

(The results of judgment are: TT)

Input: ② x=1,y=2,z=1, overlay path: sabed

(The judgment results were: FT)

Input: ③ x=1,y=3,z=0, overlay path: sacbd

(The results of judgment are: TF)

Input: ④ x=1,y=1,z=1, overlay path: sabd

(The judgment results are: FF)

2. Basic path test method

(1) Independent path

A stand-alone path is a path that contains a set of statements or conditions that have not been processed before.

From the perspective of the control flow diagram, an independent path is one that contains at least one edge that has never existed in other independent paths.

(2) Program control flow diagram

1) Definition of program control flow diagram

A control flow chart is a graphical representation of the control flow of a program. (Directed graph)

2) Two graphical symbols for control flow diagrams

  • Each circle in the diagram is called a node of the flow diagram and represents one or more statements without branches or source program statements.
  • The arrows in a flow diagram are called edges or connections and represent lines of control flow.

3) Five basic structures of program control flow diagram

4) Description of program control flow diagram

  • The program control flow diagram is actually a simplified program flow diagram.
  • In the control flow diagram, only the flow of the program is concerned, not the details of each processing box.
  • Therefore, each processing frame (including statement frame, judgment frame, input/output frame, etc.) in the original program flow chart is simplified to nodes, which are generally represented by circles, while the control flow with arrows in the original program flow chart becomes directed edges in the control flow chart.

5) Give me a chestnut.

The following figure shows a typical program flow chart transformed into its corresponding flow diagram. Simplify the program flow chart shown in Figure (a) and get the flow chart shown in Figure (b).

6) Matters needing attention

When simplifying program flow diagrams into control flow diagrams, the following points should be noted:

  • A set of sequential structures can be mapped to a single node.
  • When selecting an aggregation of branches in a multi-branch structure, an aggregation node should be added even if no statement is executed.
  • The range delineated by edges and nodes is called a region, and when counting regions, the region outside the figure should also be remembered as a region (open region).
  • If the conditional expression in the judgment is defined by multiple logical operators (OR, AND…) Concatenated compound condition expressions need to be replaced with a series of nested judgments with a single condition.

(3) Software complexity

  • Software complexity refers to how easy it is to understand and process software.
  • Program complexity is an important part of software measurement.
  • Measurement method: McCabeMetric method (loop metric)

(4) Program complexity

Loop complexity, also known as cyclomatic complexity, is a software metric that provides a quantitative measure for the complexity of program logic. It can provide the number of independent paths for a program’s base path set, which is the minimum number of test cases necessary to ensure that all statements are executed at least once. Often used for basic path testing.

(5) Loop complexity

There are three McCabe complexity measures as follows:

V (G) = {count edge area – junction points + 2 nodes + 1 \ the begin {cases} area number \ \ edge nodes + 2 + 1 \ \ \ \ \ decision nodes end {cases} ⎩ ⎪ ⎪ ⎨ ⎪ ⎪ ⎧ area number number of edges – junction points + 2 nodes + 1 :star::star::star:

1) Calculate by controlling the number of areas in the flow diagram

Formula: V(G) = number of regions

The loop complexity of the program is the number of regions in the control flow diagram (i.e., the number of closed regions +1).

As can be seen in the figure below, there are two closed regions, 1 and 2, so the loop complexity V(G) = 2 + 1 = 3.

(2 closed areas +1 open area)

2) Calculate by controlling the number of edges and nodes in the flow diagram

Formula: V(G) = e – n + 2

Where, e is edge, which represents the number of edges in the graph; N stands for node, indicating the number of nodes.

In the following figure, V(G)= E-n + 2 = 7-6 nodes + 2 = 3.

Thus, loop complexity V(G) = 3.

3) Calculate by the number of decision nodes in the control flow diagram

Formula: V(G) = P + 1

Where, P represents the number of decision nodes. The number of nodes to determine is a node with multiple branches, such as node 2 in the figure below. It can go 3 or 5, at which point it needs to make a judgment. So, 2 is a decision node. Similarly, node 3 below is analyzed like node 2.

Therefore, in the figure, V(G)=2 decision nodes +1 = 3, so the complexity of the loop is 3.

With that said, let’s summarize the complexity of the loop. In fact, the loop complexity of a program gives the number of independent paths in the program’s basic path set, which is an upper bound on the number of test cases necessary to ensure that the executable statement is executed at least once.

Through the above three examples, I believe you have a new understanding of the three ways to solve the complexity of the loop. With that in mind, let’s start with basic path testing.

(4) Basic path test method

1) What is the basic path test

Path testing is the complete process of executing each statement experienced from the entry point of a program. In a broad sense, any test of path analysis can be called a path test.

The ideal situation for path testing is to do path coverage, but it is not possible for a complex program to do all path coverage (test all executable paths).

If every single path of a program is executed, in the case that not all path coverage is possible, then every statement in the program is considered checked and statement coverage is achieved. This test method is commonly known as the base path test.

The basic path test method is a method to design test cases by deriving the set of basic executable paths through analyzing the loop complexity of control structure based on the program control flow diagram. Design test cases to ensure that each executable statement of the program is executed at least once during the test.

2) Four steps of the basic path test method

The basic path test method consists of the following four steps:

  • Based on detailed design or source code, draw the control flow diagram of the program.
  • The loop complexity V (G) of control flow graph G is calculated.
  • Identifies a collection of independent paths. The basic path set is exported through the program control flow diagram to list the independent paths of the program. An independent path is a path that contains at least one new edge, that is, some statements that are not included in the previous path. When all statements are included, the base path set is sufficient. (Linearly independent path)
  • Design test cases to ensure execution of each path in the base path set.

1) Chestnut:

According to the following code, with the basic path test method, the design of the program test cases.

if(a>8 && b>10)   / / 1, 2
    m=m+1;       / / 3
if(a=10 || c>5)  / / 4, 5
   m=m+5;       / / 6
Copy the code

Answer:

① Draw the program control flow diagram, as shown below.

② Calculate the complexity of the loop

V(G)=4 (3 closed areas +1 open area)

③ Determine linearly independent paths:

Paths 1:1, 4, 6

Paths 2:1, 4, 5, 6

Path 3:1, 2, 4, 5, 6

Path 4:1, 2, 3, 4, 5, 6

④ Design test cases

Serial number The input data The expected output Coverage path
1 a=2,b=3,c=4 m=0 One, four, six
2 a=2,b=3,c=8 m=5 One, four, five, six
3 a=10,b=6,c=8 m=5 One, two, four, five, six
4 a=10,b=15,c=8 m=6 One, two, three, four, five, six

1) I have no idea what to do.

According to the following code, with the basic path test method, the design of the program test cases.

static void permute_args(int panonopt_start, int panonopt_end, int opt_eng, int ncycle){
    int cstart, cycle, i, j, nnonopts, nopts, pos; / / 1
    
    nnonopts = panonopt_end - panonopt_start;
    nopts = opt_end - panonopt_end;
    cyclelen = (opt_end - panonopt_start)/ncycle;
    
    for(i = 0; i < ncycle; i++){ / / 2
        cstart = panonopt_end + i; / / 3
        pos = cstart;
        for(j = 0; j < cyclelen; j++){ / / 4
            if(pos >= panonopt_end){ / / 5
                pos -= nnonopts; / / 6
            }else{
                pos += nopts; / / 7}}}}/ / 8
Copy the code

[Q1] Please give the logical conditions required to satisfy 100%DC (decision coverage) for the above C program.

[Question 2] Please draw the control flow diagram of the above program and calculate the loop complexity V(G) of the control flow diagram.

[Question 3] Please give the linearly independent path of the control flow diagram of question 2.

Answer:

【 Question 1】

The logical conditions for meeting the 100% determination are:

i<ncycle;
i>=ncycle;
j<cyclelen;
j>=yclelen;
pos>=panonopt_end;
pos<panonopt_end; 
Copy the code

【 Question 2】

Control flow diagram is shown in the figure below, V(G)=4.

【 Question 3】

Linearly independent path:

Paths 1:1, 2, 8

Paths 2:1, 2, 3, 4, 2…

Path 3:1, 2, 3, 4, 5, 6, 4…

Path 4:1, 2, 3, 4, 5, 7, 4…

Write at the end

🙋 ♀ ️ 🙋 ♀ ️ 🙋 ♀ ️

For white box testing in software testing, the main need to understand the basic concepts of white box testing, static and dynamic white box testing methods, the content of black box testing will be more logical. At the same time, it is worth noting that in the basic path test method of dynamic test, the identification of linearly independent path should be especially careful, and it is easy to appear the problem of overwriting in the calculation process. Therefore, on this basis, we can find a few more related topics to practice, draw inferences by analogy.

So much for white box testing! If you need to know other content related to software testing, you can go to the “Software Testing” section to view and learn ~

At the same time, do not understand or wrong place also welcome to comment section comments or private letter I exchange ~

  • Concern about the public number Monday laboratory, do not regularly share learning dry goods, learning on the way not lost ~
  • If this article is useful to you, be sure to like it and follow it