如何提高软件的可重用性_软件可测试性

从这一篇开始，我将开始分享软件的诸多质量特性的知识。内容有的来源于书本，有的来源于网络，当然也有很多自己的心得，希望能够对大家有帮助。

---

一、测试性

测试性的概念最早是在 20 世纪 70 年代初针对硬件测试提出来的。

标准中对测试性的定义如下：

1. 《GB/T 9414.5-2018 维修性 第5部分：测试性和诊断测试》：确定产品在规定条件下能够被测试的程度的设计特性。
2. 《GJB 2547A-2012 装备测试性工作通用要求》：产品能及时准确地确定其状态（可工作、不可工作或性能下降），并隔离其内部故障的一种设计特性。
3. 《GJB 451A-2005 可靠性维修性保障性术语》：产品能及时准确地确定其状态（可工作、不可工作或性能下降），并隔离其内部故障的能力。

从定义中可以看出，测试性是一种设计特性。这意味着必须从研制初期就开始考虑产品的测试性，要经过充分的需求分析、设计、开发、试验以后，才能保证产品的测试性要求。

测试性评价指标

评价测试性的指标有很多，最常用的主要包括故障检测率、故障隔离率以及虚警率。

测试性评价指标

• 故障检测率：在规定的时间内，用规定的方法正确检测到的故障数与被测单元发生的故障总数之比。（有故障能否检测出来？）
• 故障隔离率：在规定的时间内，用规定的方法正确隔离到不大于规定的可更换单元数的故障树与同一时间内检测到的故障数之比。（有故障能否准确的定位？）
• 虚警率：在规定的工作时间，发生的虚警数与同一时间内的故障指示总数之比。（没故障能否不要瞎报？）

硬件的测试性指标对于软件是不适合的。

例如，由于硬件设备故障后，需要快速定位究竟是哪个零件失效造成的，这样在现场维修时直接替换失效零件即可，可以减少维修时间（失效通常意味着不可修理，后面到可靠性时再详细说），因此故障隔离的准不准确、快不快对于排故是很重要的。而对于软件，虽然定位到某个模块也是有意义的，但是无论是定位到哪个模块，都是需要修改代码解决问题的，不存在换一个新模块就好使的情况，因此这个指标对于软件来说虽然也有用，但重要性就没那么高了。

再例如，硬件设备受环境、空间等使用条件的影响，有时可能会发生误报，也就是虚警，虚警过多自然也是会影响设备正常使用的，而且可能会掩盖掉真实的故障。而对于软件，行为是不受外界环境影响的，因此如果是仅针对由软件本身引起的故障，最多是原因不明无法复现，而不可能出现所谓的虚警。

那么软件的测试性应该如何评价呢？

二、软件测试性

我暂时也未找到权威的国内外标准中有解释软件测试性的，因此借用下面两位大神的解释吧。一位是IEEE Fellow，一位是测试业界的大师，不详细介绍了，大家知道很牛就ok了。

软件测试性

通俗的说，软件测试性代表了软件能否容易的被测试。

软件测试性评价指标

James Bach认为可以从可控制性、可观察性、有效性、简单性、稳定性、信息化几个方面评价软件的测试性。因为稳定性、信息化等与后面我想讲的其他软件非功能特性重复了，所以我想参照另外一位大牛的观点来讲如何评价软件的测试性。

引用Jerry Gao博士在“Component Testability and Component Testing Challenges”一文中的观点，从可观察、可追踪、可控制、可理解四个方面分析软件测试性设计中应该注意的问题。

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

1. 任何一项操作或输入都应该有预期的、明确的响应或输出，不管是正确的还是错误的甚至是异常的，这样软件才是可测的；
2. 当前、过去的系统状态和变量应可见或可查询，“可见”是指运行时可见、维护时可见或者调试时可见，“不可见”就“不可发现”，可测试性就低；
3. 所有影响输出的因素可见；
4. 可自动检测、报告内部错误；
5. 错误输出易于识别，无论通过日志自动分析还是界面高亮显示的方式，要能有助于发现；
6. 增加输出参数、减少变量重用，包括打印内部信息、将局部变量作为输出、增加断言、增加局部变量等。

最后一条尤其重要，看见的前提是输出，而且为了容易测试还要多多输出。这里需要给大家介绍一下DRR的概念。

DRR（Domain/Range Ratio），是定义域和值域的比率，也可以理解成输入个数和输出个数的比率。DRR用于度量信息的丢失程度。DRR越大，信息越容易丢失，错误越容易隐藏，测试性也就越低。（输入个数多于输出个数，多个输入只能得到相同的输出，意味着信息丢失）

因此要降低DRR，在输入个数不变的条件下，就要增加输出个数，输出参数越多，能获取的信息越多，也就越容易发现错误。

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

1. 提供适当的手段，在外界直接或间接的控制系统的状态及变量，例如对于某些全局类型的变量、特殊结构等，可以进行分类并封装到接口中；
2. 采用模块化设计，各模块支持独立测试，对于每个相对独立的模块设计专用的测试驱动和测试桩，模块异常时不影响其他模块的测试（控制测试范围，就能更快地分解、定位问题）；
3. 业务流程和场景易于分解，可以针对单独业务流程进行测试；
4. 提供对外接口，便于构造测试环境模拟外部系统；
5. 提供适当的手段，可以打开或关闭调试输出或打印函数。

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

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

1. 跟踪记录关键函数的持续时间、外部库调用；
2. 跟踪记录关键流程的函数执行过程、输入输出参数；
3. 严格遵从日志规范，正确设置日志级别，输出日志格式标准统一的，便于自动查询和分析；
4. 定义日志类别，区分安全类、业务类、性能类日志，便于问题分析；
5. 约定不同类别、不同级别日志的作用及意义；
6. 日志文件至少保存 15 天，以便对以“周”为频次发生的异常分析。

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

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

1. 遵循行业的标准及规范；
2. 提供用户文档（使用手册等）、工程师文档（设计文档等）、程序资源（软件源代码等）以及质量信息（测试报告等）；
3. 文档、接口、流程、代码、注释、提示信息易于理解。

这个特性就不说了，以后到易用性时还会大讲特讲。

---

感觉结束的有点仓促，再说两句吧。

设备的测试性理论已经比较完备了，测试性设计技术包括了固有测试性（即产品设计本身方便测试的特性）、机内测试（BIT）、外部自动测试、人工测试等等。而这一篇讨论的仅仅局限于软件的固有测试性，对于软件自检（BIT）、软件自动化测试等都没有涉及，这些应该也都属于软件测试性设计的范畴。

考虑采用何种自动化测试工具，或者开展自研测试工具的设计开发，都应该属于软件测试性设计工作的内容。

另外仅针对软件的自检方面的研究还是比较少的。大家有兴趣的也可以去查查相关的论文。