Divided from the test phase
| name | concept | test method | Planning period |
|---|---|---|---|
| Unit testing (module testing) | Check whether the module implements the functions and algorithms specified in the detailed specification. Unit testing mainly finds errors in variable programming and detailed design | The programmers self-test the modules written by themselves | The unit test plan should be developed during the detailed design stage |
| Integration test (assembly test) | Test the program assembled from each module, mainly to find the interface and communication problems between the modules | Integration testing mainly finds errors in the design phase | The integration test plan should be developed during the summary test phase |
| System test (the last and most complete test) | Look at the performance and functions of the software system from a global perspective | The system test plan should be developed during the requirements analysis stage |
System test includes confirmation test and acceptance test
Confirmation test : Check whether the function, performance and other features of the software are consistent with the user's needs based on the software manual
Acceptance test is divided into (Alpha) test and (Beta) test
(Alpha) Testing : It is carried out by the user at the developer's premises, and the test is carried out under the knowledge of the developer. The developer is responsible for recording errors found and problems encountered during use. In other words, testing is conducted in a "controlled" environment.
(Beta) Testing : It is implemented by the end user of the software at the site of one or more users. The developer is usually not on site. The user is responsible for recording the errors found and the problems encountered during use and reporting these problems to the developer . That is, the test is conducted in an "uncontrolled" environment.
Regression testing : The purpose is to test the correctness of the changed part and the composite type of the changed requirements after the software is changed, as well as the original and correct functions, performance and other requirements of the software.
Divided from the test method
White box testing : (structural testing) is mainly used in the unit testing phase. Its premise is that the program can be regarded as loaded in a transparent white box, and the tester fully knows the structure and processing algorithm of the program. This method designs test cases according to the internal logic of the program, and detects whether the main execution paths in the program can work normally according to the predetermined requirements.
Commonly used techniques: logic coverage, that is, the coverage of the program logic when the test data of the test case is used to run the program under test. The
main coverage criteria of the program : statement coverage, judgment coverage, condition coverage, judgment/condition coverage, combined condition coverage, path coverage
Black box testing : (functional testing) is mainly used for integration testing and confirmation testing phases. It opaque software as a black box, and the structure does not consider internal processing algorithm (or understand) software, only check whether the software can function in accordance with software requirements specification for normal use, and whether the software can receive an appropriate input Data and generate correct output information, whether the integrity of external information (such as files and databases) can be maintained during the running of the software.
Commonly used techniques: equivalence class division, boundary value analysis, misspeculation and causality diagrams, etc.