Related concepts
Unit Testing: unit Testing is a test of the basic constituent units in the software, such as a module, a process, and so on. It is the most basic part of software dynamic testing, and one of the most important parts, and its purpose is to verify the correctness of the basic composition unit of software. The correctness of a software unit is relative to the specification of the unit. Therefore, unit tests are based on the specifications of the unit being tested. The main methods of unit testing include control flow test, data flow test, error testing, domain testing and so on.
Integration testing: integration testing is a test performed during the integration of software systems, and its main purpose is to check that the interfaces between the software units are correct. It combines modules or other software units into an increasingly larger system based on an integrated test plan, running the system to analyze whether the system is correct and whether the components are in tune. The strategy of integration testing mainly has top-down and bottom-up two kinds.
System testing: system testing is the integrated software system is thoroughly tested to verify the correctness and performance of the software system to meet the requirements specified in its specification, check the software's behavior and output is not a simple task, it is called the test "prophet problem." Therefore, the system test should be carried out according to the test plan, and its input, output and other dynamic operation behavior should be compared with the software specification. Software system testing methods are many, mainly functional testing, performance testing, random testing and so on.
Acceptance Testing: Acceptance testing is intended to demonstrate to the purchaser of the software that the software system meets the needs of its users. Its test data is usually a subset of the test data of the system test. The difference is that the acceptance test often has a software system buyer representative on site, or even in the field of software installation use. This is the final test before the software is put into use.
Regression testing: regression testing is a test that is performed after the software has been modified during the software maintenance phase. The purpose is to verify that the modifications to the software are correct. Here, the correctness of the modification has two meanings: first, the modification achieves the intended purpose, such as correcting errors, adapting to the new operating environment, and so on, and second, it does not affect the correctness of other functions of the software.
Reference books
English title:continuous delivery:reliable software releases through Build, Test, and Deployment Automation
Chinese title: Continuous Delivery: A systematic approach to releasing reliable software
Awards:2011 Jolt Shock Award
Puzzle One: Automated acceptance testing vs manual acceptance Testing
By properly creating and maintaining an automated acceptance test suite, the cost is much lower than the cost of frequent manual acceptance and regression testing:
- Manual testing is usually done at the end of the project, when the software is about to be released, and the entire team is under pressure;
- The time reserved in the original plan was not sufficient to repair the defects found in the manual acceptance test;
- New regression problems are likely to be introduced when more complex modifications are needed to fix newly discovered defects.
Conclusion: The automatic acceptance test is very necessary.
Confusion two: The cost of creating and maintaining automated acceptance tests is too high
It is possible to reduce the cost of automated acceptance testing to input-output than acceptable levels. Two ways to implement automated acceptance testing:
- Perform tests directly based on the business layer. The premise is that the presentation layer is only responsible for presentation, not the business domain or application logic. such as: MVC-based controller for testing.
- The application-based GUI runs. You need to use hierarchies to decouple acceptance tests from the UI.
Conclusion: Automated acceptance testing If the cost is high because the design is not good enough.
Puzzle Three: How to decouple the test from the GUI when accepting tests based on the GUI
level of acceptance testing:
- acceptance Conditions . "If ... When...... So ... ".
- test the implementation layer . The code uses the domain language and does not reference UI elements.
- application-driven layer . understand how to interact with the application to perform a series of actions and return the results.
"Case" acceptance criteria"case" test implementation layer"Case" application driver layer
The confusion about acceptance testing