"Software Testing Basics" Reading report: fourth chapter input Space division

"Software Testing Basics" Reading report

Fourth Chapter input Space division

In order to make the set of values for the same test requirements more straightforward, it is appropriate to divide the input space directly by defining the input fields based on the parameters of the input values. The input parameters may be the parameters and global variables of the method, or it may be the current performance state of the system, or simply a given input at the user level, which should be divided according to the actual situation. A number of regions are divided into the total input field, and some values are selected from these areas for testing.

Starting with the domain of the parameter, the possible values of each field are drawn into the block, and the process of selecting the appropriate values from the block to compose the test case is the process of entering the domain model. For the input and the division, is generally based on the program corresponding to a certain week characteristics, program input, program environment and so on.

When a domain is partitioned for an attribute, two conditions are generally required:

1. Integrity, partitioning must cover the entire domain
2. Separation, there can be no overlap between blocks

For example, in the order of "input F", a partition that looks valid and actually invalid might be:

• Divide by the sort of f

  B1 = ascending order

  B2 = descending order

  B3 = any order

This does not satisfy the completeness or the separation, ascending or descending order can be considered as any order of the sub-block, and when the F length is 0 or 1, F can satisfy three blocks at the same time. This problem occurs because the two concepts of ascending and descending are placed in the same attribute and should be separated. The result is the following effective division:

• File F Ascending

B1 = True

B2 = False

• File F Descending

B1 = True

B2 = False

When the F length is 0 or 1, the two properties are true.

The Division of completeness and separation is to make the partitioning of blocks more appropriate and to lay the groundwork for selecting the appropriate values from the blocks.

Input domain Modeling

Input domain modeling is divided into three steps.

1. Identify the functions that can be tested. Public functions can be independently tested for functions in a system, and for several methods they may have the same characteristics, so that a common set of features can be designed for a class, and a specific test for each individual function is developed, and for a large system, You might be able to extract tests when you design a use case in UML.
2. Identify all parameters. As mentioned earlier, the parameter can be an explicit function parameter or a global variable, or the state of the current system, the key is to see whether the given parameter has an effect on the behavior of the function. All parameters of the measured function form the input field.
3. Model the previous steps. By definition, the test input strictly belongs to each block of each attribute, which shows that if there are n attributes, each attribute is divided into B (n) blocks, then to cover it all, at least B (1) *...*b (n) test, each additional feature I, will have B (i) Multiple growth. More features, the number of tests will explode, so you have to control the number of combinations. In addition, inevitably, some values are invalid, and it is necessary to identify and remove invalid combinations of words.

In modeling, there are two modeling methods based on interface and function.

interface-based modeling testing

Looking at each parameter in isolation, the results of this mechanical approach are really good, easy to identify, and abstract work is simple. However, not all of the information available is reflected in the interface domain model, which means that the IdM is not complete, and the other is that an isolated analysis of each parameter causes some important sub-combinations to be omitted.

Function-based modeling testing

The idea of function-based modeling is to apply the corresponding domain knowledge to the IDM by identifying the function of the system under test. In this case, the conversion from the specification semantics to the IdM is more likely to produce the expected results for the test case. Also, since the creation of IDM does not depend on the specific implementation of the parameter list, only the specification and domain knowledge required, so early in the development of the design can begin to test.

Of course, based on the function of the sub-method, it is more difficult to identify the characteristics and values, when the system is relatively large, this point is more obvious. Moreover, the functional requirements rely heavily on the specification, if the specification is incomplete or imperfect, the design of reasonable features is more difficult.

Portfolio Policy Criteria

• Full combination overrides: All blocks from all features must be used

  If this is the case, the number of tests will explode. It is certain that some of the choices in each block are equivalent, so there are some combination strategies that make the test less

• Each selection overrides: For each feature, one value in each block is used in at least one test case

  The flexibility to meet such standards is so great that some combinations of Chinese medicine may be missed

• Paired overrides: One value per fast from each feature that must be combined with a value from each block for other characteristics
• T-wise coverage: One value per fast from T features must be combined
• Basic selection Overrides
• Multiple basic selection criteria

|--->t-wise-----> pair-wise cover---------|

Full Combination Coverage------| |------> Overlay per Selection

|---> Multiple basic selection Overrides---> basic selection override--------|

"Software Testing Basics" Reading report: fourth chapter input Space division