8、可观察性设计
1）业务执行状态和过程可观察性设计
2）异常情况可观察性设计
9、测试驱动和桩的设置
为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。
10、适合增量式开发的可测试性设计
在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。
11、可查询设计
1）对系统级别的全局变量或者状态设置查询接口；
2）某一业务或场景调用接口设置接口路径查询
12、自愈合功能
在某一场景中的局部出现故障时设置多路选择或者其他干涉进行跳转执行气候的具有正常逻辑的功能。
13、输出结果
对于任何一项操作都要能产生预期的输出，不管是正确的还是错误的甚至是异常的。测试结果的表现形式可以是数据、现象等，不管是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测试结果易于判断，具有可分析性、可获得性。在设置的各个控制点或观察点的结果易于查询、修改等。
14、提供统一的操作执行面板
操作面板元素主要由输入和输出元素组成，如所执行的操作和对应的输出，但可能被测系统是一个比较复杂的系统，由多个可以独立的模块组成，涉及到的操作和输出比较多，各操作之间的关联也比较复杂。在设计时统一的做一个操作面板，该操作面板成为一个可以操作整个被测系统的独立模块，一种是以命令的形式执行操作，直接以printf语句的形式输出查看，另一种是以GUI的形式，输入（执行的操作）输出均在界面上执行和体现，这样比较直观。如下图所示：
特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数，给出一系列可以分析的数据，该场景可以以执行过程分阶段监控，将监控范围内的数据输出以供测试人员分析。
3.2 可测试性编码
1、注释需要详尽。特别对于接口，要描述清楚功能、实现及参数；
2、使用模块化方法，编码低耦合、高内聚；
3、为集成测试与系统联调准备调测开关及相应打印函数，并且要有详细的说明；
4、为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中的安装与拆卸（通过调测开关）；
5、使用断言来发现软件问题，提高代码可测试性；
6、用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况；
7、为测试自动化工具提供所需要的特定“钩子（hook）”；
8、对于每个功能，提供访问、修改“状态”变量的接口，包括提供查询、修改上层软件、软硬件接口、底层硬件状态的接口及打印；
9、提供查询系统状态的接口。比如内存使用、程序使用进程数等；
10、对于测试因为环境等因素而可能无法测试的功能，提供接口模拟软件实现该功能的过程；
11、对于修改功能，提供修改功能参数单位的接口，以便于进行如软件性能等的测试；
12、出错及异常处理保存记录，记录具有详细的属性，并且格式统一、意义明确；
13、在程序异常时，除了保留日志，还需要提供观察、恢复的外部方法；
14、对全局变量、特殊结构，提供查询的方法。
3.3 可测试性调试与定位
1、对于程序中所涉及到的变量尽可能的在调试过程中可以查询及修改；
2、在整个软件系统执行过程中为每个关键业务或相对独立的业务设定一个调试点，便于系统集成和问题范围的定位；
3、在设定好的调试点处对处理的业务输出数据和全局数据进行可视化输出，便于测试结果的分析。
3.4 测试所需文档
1、需求规格说明书
2、概要设计说明书
3、详细设计说明书
4、系统功能清单
5、系统运行环境搭建指导书
6、系统操作指导书
相关阅读：
