Black box test La la la la

Because this week's experiment is the black box test ~ So here is the black box test related content and the method to generate test cases to summarize ~ ~

1. the basic meaning of the black box test :

Black-Box testing is also known as functional testing, and it is tested to see if each feature is working properly. is to consider the program as a black box can not be opened, without considering the internal structure and internal characteristics of the program, in the program interface testing, it only checks whether the program function in accordance with the requirements of the specification of the normal use, the program can properly receive input data and produce the correct output information. Black box testing focuses on the external structure of the program, regardless of the internal logical structure, mainly for the software interface and software function testing.

2. The role of black box testing :

Black box testing focuses on testing the functional requirements of the software, mainly trying to find the following types of errors.

(1) The detection software function can be in accordance with the requirements of the specification of the normal work, whether there is a function omission;

(2) Detection of human-computer interaction errors, whether there is data structure and external database access errors, the program can properly receive input data and produce the correct output results, and maintain external information (such as database or file) integrity;

(3) detection behavior, performance and other characteristics to meet the requirements, etc.;

(4) Detection program initialization and termination errors and so on.

3. test method :

Equivalence class Partitioning method

Boundary Value Analysis method

Causality Diagram method

Equivalence class Partitioning method:

The input fields of the program are divided into several parts (subsets), and then a few representative data are selected from each section as test cases. The role of each class of representative data in testing is equivalent to other values in this category. This method is an important and common black box test case design method.

Equivalence classes are divided into valid equivalence classes and invalid equivalence classes

(1) Effective equivalence class: Refers to the program specification is reasonable, meaningful input data composition of the set. The effective equivalence class can be used to verify whether the program implements the functions and performance specified in the specification. Does the inspection program implement the pre-defined functionality and performance of the specification.

(2) Invalid equivalence class: In contrast to the definition of an effective equivalence class, check whether the implementation of software functions and performance has a place that does not meet the specification requirements.

When designing test cases, consider both of these equivalence classes. Because the software is not only able to receive reasonable data, but also to withstand the unexpected test, such testing to ensure that the software has a higher reliability.

Boundary Value Analysis Method:

The boundary value analysis method is a black box test method to test the boundary value of input or output. The boundary value analysis method is usually used as a supplement to the equivalence class partitioning method, in which case the test case comes from the boundary of the equivalence class.

A large number of software testing practices have shown that failures often occur on the boundary of a defined field or range, rather than within it. Designing test cases specifically for processing near the boundary of the detection is usually a good test result. Therefore, the boundary value analysis method is a very useful black box test case method, it has a strong ability to find fault. Therefore, to design test cases for various boundary conditions, more errors can be detected.

Using the Boundary value analysis method to design test cases, the boundary condition should be determined first. Usually the boundary of the input and output equivalence classes is the boundary condition where the test should be emphasized. Instead of picking a typical or arbitrary value in an equivalence class as test data, you should select a value that is exactly equal to, just above or below the boundary as the test data.

The principle of selecting test cases based on the method of boundary value analysis: (1) If the input conditions specify the range of values, then the values of the boundaries that have just reached this range should be taken, as well as the values just beyond the bounds of this range as test input data. (2) If the input conditions specify the number of values, then the maximum number, the minimum number, less than the minimum number of one, than the maximum number of Taichi as the test data. (3) Use the preceding principle (1) According to each output condition of the specification. (4) Apply the preceding principle (2) according to each output condition of the specification. (5) If the program's specification indicates that the input field or output field is an ordered set, the first and last element of the collection should be selected as the test case. (6) If an internal data structure is used in the program, the value on the boundary of the internal data structure should be selected as the test case. (7) Analyze the specification and find out other possible boundary conditions. Causality Diagram method:The equivalence class partitioning method and the boundary value analysis method are all focused on the input conditions, and if there is no connection between program input, equivalence class partitioning and boundary value analysis are the effective methods. If there is a relationship between inputs, such as constraint relationships, combinatorial relationships, which are difficult to describe with equivalence class partitioning and boundary value analysis, the test results are difficult to guarantee, so you must consider a test method that is suitable for describing a combination of multiple conditions, resulting in multiple corresponding actions. Focus on the dependencies between input and output in the test specification. The causality diagram method ultimately generates a decision table, which is suitable for checking the various combinations between the program input conditions. basic steps for generating test cases:

(1) Determine the causes and results of the software specifications (requirements)

(2) Determining the logical relationship between cause and result

(3) Determining the individual constraints in the causality diagram (constraints)

(4) Draw a causal diagram and convert it into a decision table

(5) Design test cases according to the decision table

The test cases (local, combined relationships) generated from the causality diagram include the fact that all input data is true and false, and the number of test cases is minimized, and the number of test cases increases linearly with the number of input data.

The decision table is already used in the preceding causality diagram method. The decision table (decision table) is a tool for analyzing and expressing different operations under multiple logic conditions. In the early stages of programming development, the decision table was used as a tool for programming. Because it can be a complex logical relationship and a combination of multiple conditions to express the situation is both specific and clear.

A decision table is usually made up of four parts. ：

Conditional pile (Condition Stub): Lists all the conditions for the problem. The order of the listed conditions is generally considered to be irrelevant.

Action stub: Lists the actions that may be taken by the problem rule. The order of these operations is not constrained.

Condition Item (Condition Entry): Lists the values that are for its left column condition. The true and false values in all possible cases.

Action Item (Action Entry): Lists the actions that should be taken in case of various values of the condition item.

Rule: The specific value of any combination of conditions and the corresponding action to be taken. A column that runs through the condition and action items in a decision table is a rule. Obviously, how many sets of criteria are listed in the decision table, and how many rules are there, and how many columns are there for both conditional and action items.

4 basic relationships in the causality diagram:

In the basic symbol of causality diagram, the left node CI denotes the input state (or reason), and the right node EI represents the output state (or result). CI and ei value 0 or 1,0 indicates that a state does not appear, and 1 indicates that a state appears.

Identity: If C1 is 1, then E1 is also 1, otherwise E1 is 0.

Non: If C1 is 1, then E1 is 0, otherwise E1 is 1.

Or: If C1 or C2 or C3 is 1, then E1 is 1, otherwise E1 is 0.

With: If C1 and C2 are all 1, then E1 is 1, otherwise E1 is 0.

Steps to establish a decision table:

(1) List all the condition piles and action piles.

(2) Determine the number of action rules (condition items).

(3) Fill in the conditions.

(4) Fill in the action item and get the initial decision table.

(5) Simplifying decision tables and merging similar rules.

Black box test La la la la