为了保证后续在功能设计阶段可以提高产品整体的可测试性，已达到更好的提升产品的易用性、可维护性以及可测试性等方面的后期效率和降低成本的目标，故针对产品的可测试性方面进行一些常规化的梳理，同时针对一些项目中常见的可测试性方面的案例进行了对应的分析，便于大家在实践中能够更好的实践和提高在可测试性方面的意识。

可测试性的定义

软件测试中的可测性一般是指对系统的可控性、可观测性进行的评估，借以反映系统设计、实现对测试的友好程度和相应的测试成本。

可测性在测试阶段会对系统的测试成本及后期产品使用过程中的易用性、维护成本等会产生重大影响。如何提高可测性成为软件生命周期特别是前期（设计阶段、coding阶段）重要的一环。

可测试性的常用指标

可测试性的最佳切入时间

    新项目的设计阶段；

    已有项目新功能、新策略的提测阶段。

可测试性的常用分析维度

一般来说，我们可以从以下几个方面来评价软件的整体可测试性：

   可观测性

   可控制性

   可追踪性

   可理解性

各部分指标的具体分析

可观察（能否容易的观察程序的行为、输入和输出）

任何一项操作或输入都应该有预期的、明确的响应或输出，不管是正确的还是错误的甚至是异常的，这样软件才是可测的；

当前、过去的系统状态和变量应可见或可查询，“可见”是指运行时可见、维护时可见或者调试时可见，“不可见”就“不可发现”，可测试性就低；

所有影响输出的因素可见；

可自动检测、报告内部错误；

错误输出易于识别，无论通过日志自动分析还是界面高亮显示的方式，要能有助于发现；

增加输出参数、减少变量重用，包括打印内部信息、将局部变量作为输出、增加断言、增加局部变量等。

可控制（能否容易的控制程序的行为、输入和输出）

提供适当的手段，在外界直接或间接的控制系统的状态及变量，例如对于某些全局类型的变量、特殊结构等，可以进行分类并封装到接口中；

采用模块化设计，各模块支持独立测试，对于每个相对独立的模块设计专用的测试驱动和测试桩，模块异常时不影响其他模块的测试（控制测试范围，就能更快地分解、定位问题）；

业务流程和场景易于分解，可以针对单独业务流程进行测试；

提供对外接口，便于构造测试环境模拟外部系统；（如单独针对测试的一些配置/开关等）

定时触发、固定大小/空间触发等

提供适当的手段，可以打开或关闭调试输出或打印函数。

测试人员、维护人员能够控制程序的流程、场景、输入和输出，才能有针对性的执行各种用例或实验。通过接口开放流程控制、参数读写功能，也是支持实现自动化测试的基础。

可追踪（能否容易的跟踪程序的操作、状态、性能、错误、GUI事件以及通信情况）

跟踪记录关键函数的持续时间、外部库调用；

跟踪记录关键流程的函数执行过程、输入输出参数；

严格遵从日志规范，正确设置日志级别，输出日志格式标准统一的，便于自动查询和分析；

定义日志类别，区分安全类、业务类、性能类日志，便于问题分析；

约定不同类别、不同级别日志的作用及意义；

日志文件至少保存 15 天，以便对以“周”为频次发生的异常分析。

追踪的目的是可见。日志是一种维护性可见的方式；运行时以及调试时可见，可以通过专门的追踪回显代码或者各种追踪工具软件实现，这儿就不详细说了。

可理解（是否提供了足够的信息，易于获取、易于理解、易于使用）

遵循行业的标准及规范；

提供用户文档（使用手册等）、工程师文档（设计文档等）、程序资源（软件源代码等）以及质量信息（测试报告等）；

文档、接口、流程、代码、注释、提示信息易于理解。

待测模块是否可以/易于自动化测试

针对自动化测试关键环节的一些接口、权限设计等

具体的可测试性典型案例

可控制性

案例1（文件控制）

当某文件存在的时候，该模块自动退出；

当某pid.lock文件存在时，该模块不能启动，即使启动也退出。

上面的状态改变都是由一个外部的文件控制，拥有可控性。

案例2（参数/配置控制）

nvs云主机的单节点的disable特性，可通过配置disable的属性控制节点是否外部可见/可用

上面的状态由配置/参数控制，拥有可控性

案例3：nlb网关

nlb的网关部分，目前不具有disable的特性，故该部分网关新增时，实际上有一定的风险，如果该网关有问题的话，可能业务就会直接受损了

上面的状态，由于nlb网关没有针对节点外部使用的可控性，导致无法控制新增节点阶段的网关从上线到验证ok阶段的外部使用控制，所以缺少从部分来看，不具有可控性

可观测性

案例1

老云neutron实现中，svlan的扩容网段功能，因创建ip部分无法指定具体的vlan网段，故新增的网段从测试层面，是无法保证新建的ip会创建在新增的网段中的，所以该部分从可测试性角度来说，是有一定的不足的（目前通过bridge检查以及dhcp namespace层面的互通性检查等方式来完成覆盖）

案例2

zk与数据库之间的数据一致性，前期该部分没有单独的接口进行检测判断数据库和zk中的数据是否一致，所以对测试和运维来说，进行某次操作以后，就很难观测到对应的一致性情况是否完好，在目前提供了该部分的接口以后，该部分的可观测性就有了很好的保障

案例3

为了保证存储的数据高可用，分布式系统会采取多机存储副本方法。即一个数据被N（>=2）个机器以一定的算法存储相同的数据副本。这个时候经常会遇到的问题：

机器间的数据由于数据复制顺序的不同，会有数据差异。a、b、c三台机器，a、b机器可能已完成一次数据的更新到最新数据版本data1，c还处于老版本data0.

由于版本差异，内部必须维护副本revision的版本号以进行数据同步和异常处理。

这种情况， 好的设计原则上要保证多机副本的必要状态信息被外部获取。

数据的副本分布信息、副本的revision版本号等需要提供接口获得

由于机器宕机造成的副本分布变化要能够及时反映和更新。（比如带一定间隔周期的更新）

只有在这种必要信息被获取的情况下，测试人员才能更好的掌握系统状态并根据系统状态进行清晰的测试结果预期。