Software testability requirement DesignAuthor: Vince Source: http://blog.csdn.net/vincetest
I. Introduction
1. Purpose
Improve software testability, speed up testing progress, and improve testing efficiency.
2. Scope
The scope described in this article is mainly the characteristics of testability design, considering the direction and design method.
3. target readers
System analysts, designers, and developers. [Source: Vince Testing Technology Research Center: http://blog.csdn.net/vincetest]
Ii. documents required for testing
1. Requirement Specification
2. Summary Design Specification
3. Detailed Design Instruction
4. List of system functions
5. System Operation Environment Construction Guide
6. System Operation Guide
Iii. testability design requirements
Testability mainly refers to the following characteristics of the tested entity: controllability, decomposition, stability, comprehensibility, and Observability, this feature mainly involves setting up observation points, control points, and observation devices. Note that when designing testability, you must ensure that it does not affect any function of the software system, and that additional activities or additional tests are not allowed. [Source: Vince Testing Technology Research Center: http://blog.csdn.net/vincetest4101.controllable design requirements
1) controllable design requirements for global variables
You can use appropriate means to directly or indirectly control the variable, including obtaining and modifying the value of the variable. You can classify global variables and encapsulate them into interfaces.
2) controllable design requirements for interfaces
Each interface can be directly called to operate on the interface by using appropriate external means. The so-called appropriate means mainly include using test tools and adding additional code. for external interface contact areas, such as constructing a test environment simulated interface connection, the open interface mentioned here is mainly relative to the tested system, it is an interface provided outside the tested system. The conditions and required parameters required by each interface can be easily met and provided by the interface contact personnel.
3) controllable design requirements of the module
For each relatively independent module, the required driver and pile can be independently designed as test cases to test the corresponding functions. When the module is abnormal during the test, the module can be isolated without affecting the test.
4) controllable design requirements for business processes
When the test environment is met, any individual business process can be controlled, and each business process is fluent.
5) testability design requirements for scenarios
Integrate the services and interfaces involved in a scenario into a unified interface so that it can operate on this scenario separately. 2. decomposition design requirements
1) Business process design requirements for decomposition
For complex business processes, the decomposition points should be reasonably set and can be decomposed during testing.
2) testability design requirements for scenarios
For complex scenarios, the decomposition points should be reasonably set and can be decomposed during testing. 3. Stability design requirements
The release of the test module is reasonable, and new unnecessary test activities cannot be introduced for the modules tested in the early stage. 4. Easy to understand design requirements
1) ease of understanding of design documents
Design Reference Standards
The content description should be distinguished between primary and secondary
Clear dependency description
2) ease of understanding of interfaces
Clear interface functions
Parameters are meaningful.
3) Ease of business understanding
4) ease of understanding of scenarios [Source: Vince Testing Technology Research Center http://blog.csdn.net/vincetest】5.observability design requirements
1) business execution status and process observability design requirements
2) observability design requirements for abnormal situations 6. test drive and pile settings
Reserved test drive and pile access points for a single test interface, Test Service, and test scenario. 7. testability design suitable for incremental development
In the incremental development process, the difficulty and authenticity of the Test Pile and test-driven implementation must be prioritized. 8. queryable Design
Interface for setting query of system-level global variables or statuses;
API call for a service or scenario to set API path query. 9. Auto-healing
In a certain scenario, when a local fault occurs, you can set multiple options or other interference to perform the jump so that it has a normal logic function. 10. output results
Any operation must produce the expected output, whether correct or wrong, or even abnormal. the test results can be represented by data and phenomena. No matter how the results are presented, they must be traceable and described in the design documents. The test results are easy to judge and can be analyzed and acquired. The results of various control points or observation points are easy to query and modify. 11. provides a unified operation execution panel
The Operation Panel elements are mainly composed of input and output elements, such as the operations performed and the corresponding outputs. However, the tested system may be a complicated system, it consists of multiple modules that can be independent, involving many operations and outputs, and the association between operations is also complicated. An operation panel is designed to be an independent module that can perform operations on the entire tested system. One is to execute operations in the form of commands, you can directly view the output in the form of a printf statement, and the other is in the form of a GUI. The input (executed operation) output is executed and reflected on the interface, which is intuitive. As shown in:
[Source: Vince Testing Technology Research Center: http://blog.csdn.net/vincetest]
In particular, when executing a scenario, we need to track the key processes and output parameters of the scenario, and provide a series of data that can be analyzed. This scenario can be monitored in stages during execution, output data within the monitoring scope for analysis by testers. [Source: Vince Testing Technology Research Center: http://blog.csdn.net/vincetest.pdf welcome to download this article, please refer to the Article below: wenstest Technology Research Center http://blog.csdn.net/vincetest
