[2] 系统内部状态信息
为了保证存储的数据高可用，分布式系统会采取多机存储副本方法。即一个数据被N（>=2）个机器以一定的算法存储相同的数据副本。这个时候经常会遇到的问题：
a) 机器间的数据由于数据复制顺序的不同，会有数据差异。a、b、c三台机器，a、b机器可能已完成一次数据的更新到最新数据版本data1，c还处于老版本data0.
b) 由于版本差异，内部必须维护副本revision的版本号以进行数据同步和异常处理。
这种情况， 好的设计原则上要保证多机副本的必要状态信息被外部获取。
A. 数据的副本分布信息、副本的revision版本号等需要提供接口获得
B.由于机器宕机造成的副本分布变化要能够及时反映和更新。（比如带一定间隔周期的更新）
只有在这种必要信息被获取的情况下，测试人员才能更好的掌握系统状态并根据系统状态进行清晰的测试结果预期。
[3] 参数的热设定
参数的热设定是经常碰到的问题。一个系统越复杂、可定制，它可设定的参数就越多。一个好的设计应该能热设定其中的参数，然后执行重新加载动作。
举个实际的例子， 下面的配置文件是一个系统的存储节点配置文件截图。该截图仅展示了大约1/5的配置参数。
a. 如果参数不可重新热加载，那么测试用例执行过程中都必须进行进程的重启。
进程的重启势必造成单个测试用例的时间拉长，复杂系统成百+的测试用例会造成总体测试时间的拉长。每个多消耗1-2分钟，整体就是小时级别的时间消耗。这对Slow build或完整性测试集执行来说是个灾难。可测性也比较差。
b. 参数不可热加载会在系统运维期间失去热调整参数的机会，可能导致系统的间断性停服务。这对基础服务来说是个噩梦，上层依赖于基础服务的应用可能成百上千，停服的代价过于大。一些gdb强行attach进程进行等修改变量的临时方法由于进程状态的不确定性因素会带来不小的风险。作者负责的项目曾出现gdb热修改带来集群主控节点宕机停集群的惨痛经历。
参数的热设定和加载虽然增加了一定的逻辑复杂度，但对比带来的收益是值得付出并实践的。
[4] 系统使用信息统计
系统使用信息的统计在如下方面特别重要:
1) 产品线运营数据，为产品运营、后续产品改进等环节提供一手资料
2) 运用系统、集群状态信息监控以解决运维过程中发生的问题
3) 利用系统状态信息进行内部运行状态判定，以测试是否达预期
1和2虽然不直接涉及可测性，但测试人员在系统设计阶段需要进行这方面的考虑以防止系统开发后期进行的功能性重构带来测试整体架构重构。系统接近尾声进行的功能性重构对测试人员来说是个非常头疼的问题。测试用例依赖的统计信息等接口可能被大量使用，这类的更改带来不小的用例调整、更正工作。
测试人员在信息统计的设计阶段需要了解系统在现有的设计基础上可能衍生的二期、三期甚至更后期的功能，以提前影响当前的功能设计，提高数据、接口、操作方面的可扩展性。为以后可能产生的新功能打好可测性基础。少埋坑、多考虑场景适应性。
上面的场景是作者在实际测试项目中经常遇到的，因此抽取出来做个示例。实际的项目测试遇到的场景远比这些复杂、多样且不可预知。这个时候需要大家多思考场景，多根据已有的经验进行防御性准备。
那有没有通用的提供可测性的方法呢？
3 提高可测性的通用方法
摒弃原有的开发人员只进行单纯的代码单元测试的观念，让开发人员也进行系统级测试。
作者在实践过程中最推崇的方法就是此条。具体地说，开发人员进行的是系统级测试，禁止刷行覆盖率型的单纯函数覆盖UT。由系统级接口或者功能来驱动整个测试过程。无法直接进行驱动的测试行为需要撰写模拟器或者模拟模块进行。
这样开发人员会切身的感受到可控性和可观测性的重要性。进而推动系统在这两个方面的实现更易用和便于测试。由此而来的良性循环能让系统整体可测性始终处于较好水平。
测试人员深度了解被测系统，能够在可测性出现问题的时候及时指出问题所在。
只有深度了解被测系统，详细分析系统实现逻辑和代码，做到可黑盒、可白盒测试的程度，才能提前预测可测性薄弱环节，提前预防这样的事情发生。在可测性出现问题时，及时介入和提出建设性意见。在需要进行测试代码植入以方便测试流畅进行等方面亲自动手，协助开发人员解决问题。
可测性问题可能出现在系统的各个方面，但只要在系统生命周期的各个环节严格要求并辅以正确的方法，可测性问题就不会成为软件测试中不可攻破的难关。各位朋友，你遇到过哪样的可测性难题呢？如果让你从设计阶段就贯彻好的可测性要求并在整个流程中严格遵守，能否解决你的难题呢？
