Software testability design

Software testability design
Author: Zhang yuanli

Http://blog.csdn.net/vincetest

1 Overview
With the rapid development of the software industry, more and more software companies are attaching importance to software testing. However, can the developed software be used directly for testing? According to the practice in recent years, it has been proved that software that has not been thoroughly designed and deployed for software testability is always difficult to perform during testing, until the test fails. When coding the tested software, you must consider providing necessary means and Interface Support for testing and subsequent product maintenance, that is, the software must be testable. Based on testability goals, sound architecture design and complete interfaces make software testing more efficient and feasible, and product maintenance more convenient. [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]

The scope of this article is: testability definition, testability characteristics, and testability design.

Intended audience: system analysts and designers, developers, and testers.
 
References:
1. Software testability demand design Vince
2. Lin Rui, high quality c ++/C Programming Guide
3. "Software Engineering thoughts" Lin Rui

[Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]

2 software testability Definition
2.1 testability Definition
The testability of Software refers to the design and execution of testing to discover software problems at a certain time and cost, and the ability to discover, isolate, and locate faults. Simply put, the testability of software is the degree to which a computer program can be tested.
Generally, software with good testability must be a software with strong cohesion, weak coupling, clear interfaces, and clear intentions, software that is not testable often has strong coupling and chaotic logic.

[Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]

 

2.2 Testability
1. Operability: "The better the operation, the higher the efficiency of the test ."
1) Few system errors;
2) There are no errors hindering test execution;
3) evolution of products in the function phase (simultaneous development and testing are allowed ).

2. observability: "What you see is what you test ."
1) Each input has a unique output;
2) The system status and variables are visible or can be queried during running;
3) The past system status and variables are visible, or can be queried during running (for example, transaction logs );
4) all factors that affect the output are visible;
5) easy to identify error output;
6) Automatically detects internal errors through the self-testing mechanism;
7) automatically reports internal errors;
8) source code can be obtained.

3. controllability: "The better the control over the software, the more automatically the test can be executed and optimized ."
1) all possible outputs come from some input combination;
2) through some input combination, all code may be executed;
3) test engineers can directly control the status and variables of software and hardware;
4) the input and output formats are consistent and structured;
5) convenient description, automation and regeneration of tests;
6) easy control of interfaces and modules;
7) business processes and scenarios are easy to control.

4. destructibility: "by controlling the test scope, you can break down problems faster and perform more agile retest ."
1) The software system is composed of independent modules;
2) ability to independently test various software modules;
3) Business Processes and scenarios are easy to break down.

5. Simplicity: "The less content you need to test, the faster the test ."
1) simple functions (for example, a feature set is the minimum set required to meet requirements );
2) simplified structure (for example, modularized architecture to limit the reproduction of errors );
3) code simplicity (for example, using code standards to facilitate inspection and maintenance ).

6. Stability: "The fewer changes, the smaller the damage to the test ."
1) software changes are not frequent;
2) software changes are controllable;
3) software changes do not affect existing tests;
4) The software can be well restored and isolated after it fails.

7. comprehensibility: "The more information you get, the more agile you will be in the test ."
1) design can be well understood and follow industry specifications;
2) dependencies between internal, external, and shared components can be well understood;
3) design changes are notified;
4) technical documents can be obtained at any time;
5) reasonable technical documents;
6) The technical documents are clear and detailed;
7) accurate and stable technical documents;
8) related environment configuration instructions and operation instructions.

[Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]

3 software testability design
3.1 testability design
The main characteristics of software testability are the establishment of observation points, control points, observation devices, driving devices, isolation devices. It should be noted that the testability design must be guaranteed that it cannot affect any function of the software system, and no additional activities or additional tests can be produced, design the software in an appropriate design mode.
1. Adhere to the test-driven design (test first) method.
Write the test code first. This is the standard XP method. This is not to say that you should write all the test code at one time and then implement it all at one time. It is a better way to write acceptance tests, unit tests, test code, test code, and test code. Design advances in this way; capturing errors in the implementation phase and correcting them in the next set of tests will also make it less daunting to write tests in this way. [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]

2. Try to correspond to a function for each operation to make the function smaller.
Using a small function description and a function with default parameters will make it much easier to call these functions during testing. Otherwise, you will have to construct additional parameters when testing these functions. If the parameters are large, the code will soon expand. Worse, it will trick you into writing less tests than in other cases.

3. data display and control separation
Move the code outside the GUI view. Then various GUI actions can be called as simple methods in the model. In this way, it is much easier for GUI testers to call the test function by method than to indirectly test the function. Another advantage is that it makes it easier to modify program functions without affecting the view.

4. Controllable design [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]
1) controllable design of global variables
I. Use appropriate external means to directly or indirectly control the variable, including obtaining and modifying the variable value;
Ii. global variables can be classified and encapsulated into interfaces.
2) controllable Design of 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. the contact points of the interfaces provided externally can be manually docked. For example, to construct a simulated interface connection in the test environment, the open interface mentioned here mainly refers to the comparison with the entire 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 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 of business processes
When the test environment is met, any individual business process can be controlled, and each business process is fluent.
5) scenario testability design
Integrate the services and interfaces involved in a scenario into a unified interface so that it can operate on this scenario separately.

5. factorization Design
1) Business process decomposition Design
For complex business processes, the decomposition points should be reasonably set and can be decomposed during testing.
2) scenario factorization Design
For complex scenarios, the decomposition points should be reasonably set and can be decomposed during testing.

6. Stability Design
The release of the test module is reasonable, and new unnecessary test activities cannot be introduced for the modules tested in the early stage. [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]

7. Understandable Design
1) ease of understanding of design documents
I. Design Reference Standards
II. The content description should be separated from the primary and secondary
Iii. Clear dependency description
2) ease of understanding of interfaces
I. Clear interface functions
Ii. parameters are meaningful
3) Ease of business understanding
4) ease of understanding

8. observability Design
1) business execution status and process observability Design
2) observability Design for abnormal situations

9. test driver and pile settings
Reserved test drive and pile access points for a single test interface, Test Service, and test scenario.

10. testable 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.

11. querydesign [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]
1) set the query interface for system-level global variables or statuses;
2) call an interface in a business or scenario to set an interface path Query

12. Self-healing function
In a certain scenario, when a local fault occurs, multiple options or other interference are set to jump to the execution climate, which has the normal logic function.

13. 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.

14. 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 operate the entire system under test, and an operation is executed 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:

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: Zhang yuanli's blog http://blog.csdn.net/vincetest]

3.2 testability code
1. The annotations must be detailed. The functions, implementations, and parameters must be clearly described for interfaces;
2. the modular method is used to encode low coupling and high cohesion;
3. Prepare the commissioning switch and corresponding printing function for Integrated Testing and system joint debugging, and provide detailed instructions;
4. Select appropriate test points for unit tests, carefully construct test code and test cases, and provide clear comments. The test code should be used as a sub-module in the module to facilitate the installation and disassembly of the test code in the module (through the commissioning switch );
5. Use assertions to discover software problems and improve code testability;
6. Use assertion to check whether the program is normal but may occur during commissioning;
7. Provide specific "hooks" required for testing automation tools )";
8. For each function, interfaces for accessing and modifying "status" variables are provided, including interfaces for querying and modifying upper-layer software, software and hardware interfaces, and interfaces and printing of underlying hardware statuses;
9. interfaces for querying system status are provided. Such as memory usage and number of processes used by the program;
10. Provide interfaces to simulate the software implementation process for functions that may not be tested due to environment and other factors;
11. interfaces for modifying function parameter units are provided to facilitate testing of software performance;
12. keep records of errors and exception handling. The records have detailed attributes and are in uniform format and clear meaning;
13. When a program exception occurs, in addition to retaining logs, external methods for observation and recovery are also required;
14. provides query methods for global variables and special structures.

[Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]

3.3 testability debugging and positioning
1. the variables involved in the program can be queried and modified during debugging as much as possible;
2. Set a debugging point for each key business or relatively independent business during the entire software system execution process to facilitate system integration and problem locating;
3. Visually output the processed Business Output Data and global data at the set debugging points to facilitate analysis of the test results.

[Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]

3.4 documentation required for testing
1. specification
2. Summary Design Specification
3. Detailed Design Instruction
4. List of system functions
5. System Operation Environment Setup Guide
6. System Operation Guide

[Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]

Welcome to repost this article, reprinted please indicate the source of the article: Zhang yuanli's blog http://blog.csdn.net/vincetest