1. BVT – build verification test
A brief test run on daily builds to determine if anything major is broken
Does not do deep functionality checking
Gets more stringent as the dev cycle goes on
If the BVT passes, the build is accepted into testing
If the BVT fails, the build is declared “Failed” and is not accepted for testing
Purpose is to automatically figure out if the build is worth testing
2. Acceptance test
A variable length test run to determine if a minimum level of functionality is available after changes by dev
Between brief BVT and deep functionality
If it passes, code can be checked in
If it fails, dev needs to do more work before checking in
3. Functionality test
A longer comprehensive test of all functionality available in a test area
Goal is:
100% function coverage
>75% branch coverage
But NOT 100% code coverage
Boundary conditions and equivalence class partitioning may be used
These tests often form the basis of stress tests
4. Unit testing
Unit = smallest functional block of code
Functionality testing
5. Component testing
Component = units of code interacting
Integration testing
6. System testing
System = components interacting. End to end or system testing
7. Stress test
A test that runs until the code fails
Does not necessarily provide user equivalence
Scalable; stress level from easy to very difficult
Scopable; can be used from unit to system level
Standard, essential metric to determine for ship quality
Metric is checked over time to spot stability degradation
72 hours’ work as a benchmark
8. Configuration test
A test to check compatibility with hardware and software
Uses a test matrix to manage large numbers of systems, devices and target platforms
Designed to catch major classes of incompatible devices
9. Regression testing
Regress all critical bugs on critical milestones. To see the new changes’ impacts
10. Documentation and help file test
11. Security test
12. Installation test
Blah, blah, blah……
扫一扫
61
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
