Test small notes (black \ White box test and difference, test case design)

• The concept of testing:

• White Box Test

• black box Test

• Comparison of white box test and black box test

• Design of test Cases

In general, the least efficient of all the methods is the random input test, which is the process of randomly selecting a subset of all possible input values to test the program.

White Box test method: 1) Statement overlay. 2) Decision coverage. 3) Condition coverage. 4) Judgment/condition coverage. 5) multiple conditional overrides.

1.> statement overrides: A weaker guideline to execute at least once for each statement in the program.

2.> to determine coverage or branch coverage: strong logic coverage criteria, it is necessary to write enough test cases, so that each judgment has at least one true and false output results. Which means that each branch must traverse at least once.

3.> conditional overrides: A stronger criterion than a decision, conditional overrides to write enough test cases to ensure that all possible results of each condition in a judgment are executed at least once.

4.> decision/Conditional override: Design sufficient test cases to execute at least once of all possible results for each condition in a judgment, execute at least once for each of the possible results of each judgment, and call each entry point at least once.

5.> multiple conditional overrides: Requires that you write enough test cases, combine all possible conditional results from each decision, and all entry points are executed at least once. In general, for a program that contains only one condition for each judgment, the simplest test criterion is to design a sufficient number of test cases to implement: 1) to execute at least once for all the results of each judgment, and 2 to call at least once for all program entries, such as entry points or on units. To ensure that all statements are executed at least once. The simplest test for a program with multiple conditional judgments is to design a sufficient number of test cases, combine all possible conditional results for each judgment, and all entry points are executed at least once (the "possible" word is added because some combinations are difficult to generate).

black Box test method: 1) Equivalence class division. 2) Boundary value analysis. 3) Causality diagram analysis. 4) False conjecture.

1.> Equivalence class Division: 1) Determine equivalence class, 2) generate test case.

Determine equivalence classes: Select each input condition (usually a sentence or phrase in the specification) and divide it into two or more groups. A valid equivalence class (representing a valid input to a program) is an invalid equivalence class (which represents any other possible input condition, i.e. an incorrect input value).

Build test Cases: 1) set a different number for each equivalence class. 2) write new test cases, overwriting as many valid equivalence classes as they are not overwritten, until all valid equivalence classes are overwritten (included) by the test case. 3) Write a new use case that overrides one and only one invalid equivalence class that has not been covered until all invalid equivalence classes are covered by the test case.

2.> Boundary value analysis: refers to States in the input and output equivalence classes that happen to be at or beyond the boundary, or below the boundary.

1) In contrast to the selection of any element from an equivalence class, the boundary value analysis needs to select one or more elements so that each boundary of the equivalence class is tested once.

2) It is also necessary to consider the design of test cases from the result space (output equivalence Class), which is different from just the input criteria (input space).

3.> Causality diagram: is a formal language, the specification described in natural language can be converted to cause and effect diagram. A causal diagram is actually a digital logic circuit (a combination of logical networks), but instead of using standard electronic symbols, a slightly simpler symbol is used.

1) Break the specification into an executable fragment.

2) Determine the causal relationship in the specification.

3) Analyze the semantic content of the specification and convert it to a Boolean graph that links causal relationships. The so-called causal diagram.

4) Add annotation symbols to the diagram, explaining the "cause" and "fruit" that cannot be linked due to grammatical or environmental constraints.

5) through careful tracking of state changes in the graph, the causality diagram is converted into a decision table of finite items. Each column in the table represents a test case.

6) Convert the columns in the decision table into test cases.

The causality diagram approach is a systematic approach to generating test cases based on a combination of conditions. The alternative to this method is a specially selected combination of conditions, but in this process it is possible to omit many of the "interesting" test cases that can be determined by the causality diagram method.

4.> error guessing: Use intuition and experience to guess the possible types of errors, and then write test cases to expose them.

Test Strategy: 1 If the specification contains a combination of input conditions, the causal diagram analysis method should be used first. 2) In any case, the boundary value analysis method should be used. 3) Valid and invalid equivalence classes should be determined for inputs and outputs, supplemented by the test cases identified above, if necessary. 4) Use error-guessing techniques to add more test cases. 5) The logical structure of the test case set checker for the above.

Test small notes (black \ White box test and difference, test case design)