1. Equivalence Classes
Common Software Testing Interview Questions Classifying Equivalence Classes: An equivalence class is a subset of an input field. In this subset, each input is equivalent in terms of revealing errors in the program. It is reasonable to assume that testing a representative value of an equivalence class is equivalent to testing other values of that class. Therefore, it is possible to divide all input data into several equivalence classes, and take one data in each equivalence class as the input condition for testing, so that a small amount of representative test data can be used to achieve better test results. Achieve better test results with a small amount of representative test data. Equivalence class can be divided into two different cases: valid equivalence class and invalid equivalence class.
2. Boundary value analysis
Boundary value analysis is a complementary method of equivalence class division. My testing experience has shown me that a large number of errors occur at the boundaries of the input or output ranges, rather than within the input and output ranges. Therefore, by designing test cases for various boundary cases, more errors can be detected.
The first step in designing test cases using boundary value analysis is to determine the boundary cases. Usually the boundaries of input and output equivalence classes are the boundary cases that should be emphasized for testing. You should select values that are exactly equal to, just greater than, or just less than the boundary as the test data, rather than selecting typical or arbitrary values in the equivalence class as the test data.
3. Bug speculation
A method of designing test cases based on empirical and intuitive speculation of all possible bugs in a program.
The basic idea of the bug speculation method is to list all the possible bugs in the program and the special cases that are prone to bugs, and select test cases based on them. For example, many of the common errors found in modules are listed in unit tests. For example, many of the common errors found in modules during unit testing, errors found in previous product testing, etc., are summarized from experience. There are also cases where the input data and output data are zero. Input forms with spaces or input forms with only one line. These are all cases where errors are likely to occur. These cases can be selected as test cases.
4. Cause and Effect Diagram Methods
The Equivalence Class Classification and Boundary Value Analysis methods introduced earlier focus on the input conditions, but do not consider the connection between the input conditions, the inter-combination, and so on. Considering the combination of input conditions, some new situations may arise. However, it is not easy to check the combinations of input conditions, and there are many combinations of input conditions even if all of them are divided into equivalence classes. Therefore, it is important to consider designing test cases in a form that is suitable for describing multiple combinations of conditions that result in multiple actions. This requires the use of causal diagrams (logic models). The causal diagram approach results in a decision table. It is suitable for examining various combinations of program input conditions.
5. Orthogonal table analysis
Sometimes, there may be a surge in the number of test cases due to a large number of parameter combinations, and at the same time, there is no clear priority gap between these test cases, and testers are not able to complete such a large number of tests, so you can use the orthogonal table to narrow down the number of test cases, so as to achieve the possibility of covering as much as possible the scope of the fewest possible cases. of possibilities.
6. Scenario analysis method
This refers to modeling user steps based on user scenarios, which is more similar to causal diagrams, but may be executed with better depth and feasibility.
The key to white-box test case design is to cover as much of the internal program logic as possible with fewer cases
The key to black-box case design is also to cover the module output and input interfaces with fewer cases. It is not possible to do complete testing with the least number of use cases to find the most problems in a reasonable amount of time
Describe in detail the complete process of a testing activity. 1. The project manager completes the requirements document by communicating with the customer and the developers and testers*** complete the review of the requirements document, which includes the following: the requirements are not clear and there may be obvious conflicts or failure to realize the function of the project. The review includes: unclear description of the requirements and possible obvious conflicts or failure to realize the function