一次跟客户做测试交流，被问到一个关于软件可测试性的问题，一时间竟无语，以前了解过，却没有真正的关注过，项目马上要做客户需求书和产品需求书了，这个阶段需要做一些把握了，网上搜罗到了好东东，收藏在坛子了，也与各位同仁共享

 

软件可测试性设计
Author: Vince     

1  概述
    随着软件行业的迅猛发展，软件测试也逐渐受到越来越多的软件公司所重视，然而开发出来的软件直接就可以拿出来做测试吗？根据近几年来的实践证明，在设计软件时事先没有对软件的可测试性进行周密设计和部署的软件在测试时总是很难于进行，直到测试无法进行下去为止。被测软件在编码时需要考虑给测试和后期的产品维护提供必要的手段和接口支持，即要求软件具有可测试性。基于可测试性的目标考虑，良好的架构设计，完备的接口，使得软件测试更加高效和可行，同时产品维护也更加便利。 【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】

    本文描述的范围：可测试性定义、可测试性特征、可测试性设计。

    读者对象：系统分析和设计人员、开发人员、测试人员。
 
    参考文献：
    1.《软件可测试性需求设计》               Vince
    2.《高质量C++/C编程指南》              林锐
    3.《软件工程思想》                          林锐

 

2  软件可测试性定义
2.1  可测试性定义
    软件的可测试性是指在一定的时间和成本前提下，进行测试设计、测试执行以此来发现软件的问题，以及发现故障并隔离、定位其故障的能力特性。简单的说，软件的可测试性就是一个计算机程序能够被测试的容易程度。
    一般来说可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件，而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。】

2.2  可测试性特征
  1.可操作性：“运行得越好，被测试的效率越高。”
    1)系统的错误很少；
    2)没有阻碍测试执行的错误；
    3)产品在功能阶段的演化(允许同时的开发和测试)。
   
  2.可观察性：“你所看见的就是你所测试的。”
    1)每个输入有唯一的输出；
    2)系统状态和变量可见，或在运行中可查询；
    3)过去的系统状态和变量可见，或在运行中可查询(例如：事务日志)；
    4)所有影响输出的因素都可见；
    5)容易识别错误输出；
    6)通过自测机制自动侦测内部错误；
    7)自动报告内部错误；
    8)可获取源代码。

  3.可控制性：“对软件的控制越好，测试越能够被自动执行与优化。”
    1)所有可能的输出都产生于某种输入组合；
    2)通过某种输入组合，所有的代码都可能被执行；
    3)测试工程师可直接控制软件和硬件的状态及变量；
    4)输入和输出格式保持一致且有结构；
    5)能够便利地对测试进行说明、自动化和再生；
    6)接口和模块易控制；
    7)业务流程和场景易控制。

  4.可分解性：“通过控制测试范围，能够更快地分解问题，执行更灵巧的再测试。”
    1)软件系统由独立模块构成；
    2)能够独立测试各软件模块；
    3)业务流程和场景易分解。

  5.简单性：“需要测试的内容越少，测试的速度越快。”
    1)功能简单性(例如：特性集是满足需求所需的最小集合)；
    2)结构简单性(例如：将体系结构模块化以限制错误的繁殖)；
    3)代码简单性(例如：采用代码标准为检查和维护提供方便)。

  6.稳定性：“改变越少，对测试的破坏越小。”
    1)软件的变化是不经常的；
    2)软件的变化是可控制的；
    3)软件的变化不影响已有的测试；
    4)软件失效后能得到良好恢复和隔离。

  7.易理解性：“得到的信息越多，进行的测试越灵巧。”
    1)设计能够被很好地理解并遵循行业规范；
    2)内部、外部和共享构件之间的依赖性能够被很好地理解；
    3)设计的改变被通知；
    4)可随时获取技术文档；
    5)技术文档组织合理；
    6)技术文档明确详细；
    7)技术文档精确性稳定；
    8)相关环境配置说明与操作指导。

 【文章来源：文斯测试技术研究中心 3软件可测试性设计
3.1可测试性设计
    软件的可测试性特征主要表现是设立观察点、控制点、观察装置、驱动装置、隔离装置。需要注意的是可测试性设计时必须要保证不能对软件系统的任何功能有影响，不能产生附加的活动或者附加的测试，采取合适的设计模式对软件进行设计。
  1.坚持测试驱动设计（测试先行）的方法。
    优先编写测试代码，这是标准的XP方法。不是说应该一次性编写全部测试代码后，再一次性全部实现。先写验收测试，再写单元测试，编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展；在实现阶段捕捉错误并在下一组测试中改正它，以这种方式编写测试也更少会使人畏缩。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】

  2.尽量做到每个操作对应一个函数，使函数小型化。
    使用小型函数说明和重载带缺省参数的函数将使在测试中调用这些函数变的愉快的多。否则，在测试这些函数时将不得不构造额外参数，如果参数很大，那么将很快导致代码膨胀。更糟的是，它会诱使你编写比在其它情况下更少的测试。

  3. 数据的显示与控制分离
    把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。这样，对GUI测试者来说，通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。

  4.可控制性设计【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
   1)全局变量的可控制性设计
     I.在外界使用适当的手段能够直接或间接控制该变量,包括获取、修改变量值等；
     II. 可以将全局类型的变量进行分类并封装到一个个接口中操作。
   2)接口的可控制性设计
     各接口在外界使用适当的手段能够直接调用对该接口进行操作,这里所谓的适当的手段主要包括使用测试工具和增加额外代码. 对于向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接口对接，这里所指的开放接口主要是指相对于整个被测系统，即为被测系统以外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。
   3)模块的可控制性设计
     对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。
   4)业务流程的可控制性设计
     在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。
   5)场景的可测试性设计
     将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。

  5.可分解性设计
    1)业务流程的可分解性设计
      对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。
    2)场景的可分解性设计
      对于复杂的场景需合理设定分解点，在测试时能够对其进行分解。

  6.稳定性设计
    测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】

  7.易理解性设计
    1)设计文档的易理解性
      I.设计参考标准
      II.内容描述主次要分清
      III.依赖关系描述明确
    2)接口的易理解性
      I.接口功能明确
      II.参数有意义
    3)业务的易理解性
    4)场景的易理解性

  8.可观察性设计
    1)业务执行状态和过程可观察性设计
    2)异常情况可观察性设计

  9.测试驱动和桩的设置
    为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。

  10.适合增量式开发的可测试性设计
    在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。

  11.可查询设计【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
    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.系统操作指导书

来源：中国IT实验室

　　功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。针对Web应用的常用测试方法如下：

　　1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
　
　　2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
　
　　3. 检查按钮的功能是否正确：如update， cancel， delete， save等功能是否正确。
　
　　4. 字符串长度检查： 输入超出需求所说明的字符串长度的内容， 看系统是否检查字符串长度，会不会出错。
　
　　5. 字符类型检查： 在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型），看系统是否检查字符类型，会否报错。
　
　　6. 标点符号检查： 输入内容包括各种标点符号，特别是空格，各种引号，回车键。看系统处理是否正确。
　
　　7. 中文字符处理： 在可以输入中文的系统输入中文，看会否出现乱码或出错。
　
　　8. 检查带出信息的完整性： 在查看信息和update信息时，查看所填写的信息是不是全部带出。，带出信息和添加的是否一致9. 信息重复： 在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。
　
　　10. 检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按“delete”，看系统如何处理，会否出错；然后选择一个和多个信息，进行删除，看是否正确处理。
　
　　11. 检查添加和修改是否一致： 检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。
　
　　12. 检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理，报错。同时，也要注意，会不会报和自己重名的错。
　
　　13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
　
　　14. 检查多次使用back键的情况： 在有back的地方，back，回到原来页面，再back，重复多次，看会否出错。
　
　　15. search检查： 在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确。
　
　　16. 输入信息位置： 注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。
　
　　17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
　
　　18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加* 19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
　
　　20. 回车键检查： 在输入结束后直接按回车键，看系统处理如何，会否报错。

Usability Testing - 可用性测试

UI Testing - 用户界面测试。UI这个词其实范围很宽。什么样的东西是UI呢？VISTA那样炫的是UI，DOS窗口也是UI。以前古老电脑上的LED也是UI的一部份，其实一句话，UI就是用户跟计算机交互的界面。什么样是一个好的用户界面？书上归纳了7点。

Follows Standards and Guidelines - 遵循标准和指引。这两个东西在书上都出现了好多次了，呵呵，反正就是说标新立异的东西都是有风险的，因为标准已经是被前人证明是好的，至少是合理的嘛~所以遵守这些标准来做出来的东西一般来说会有一个好的UI。大家发现没有，WINDOWS跟LINUX的UI规范是不同的，WINDOWS里面，左边的是OK，Cancle在OK的右边，而linux里面就是相反的：）

Intuitive - 直观。什么是直观，如果你看到的这些文字他不是文字，而是0100010010101001010，你吐血不？不过这只是一个极端的例子。一个好的UI就是让用软件的人根本就感觉不到UI的存在~UI要求是简洁的而且布局是合理的，没有不必要的功能的。这里我觉得还是去看看竞争对手的产品，就知道我们需要有什么改进了：）

Consistent - 一致性。例如一个软件把复制的快捷键定义为CTRL+X，剪切的快捷键是CTRL+V……那么估计用户鼻子都气歪了吧。创造性是好的，不过有些时候还是循规蹈矩比较好。

Flexible - 灵活。就好像计算器的例子，WINDOWS的计算器有2种模式，可以给用户选择，不过这种灵活性是有代价的，就是投入更加多的人力物力。

Comfortable - 舒适。通俗点说就是这个软件用的爽不爽。正所谓人要有人样，一个财务软件不应该出现很多卡通的配图吧~然后就是错误处理，软件很难避免错误，这时候需要处理这些错误，那么就需要好好处理这些错误提示哦。然后就是性能，慢成马的软件谁用啊。

Correct - 正确性。保证软件里面的内容，功能是没有错误的。例如不要有拼写错误。还有是否有一些功能，是我们的软件产品所没有但是却又是在这个市场是有需求的呢？（这个要求有点高了吧？）

Useful - 可用性。一个软件是不是有用通常都是由客户说了算，不过这里存在一个问题，是不是某些功能对于我们的软件来说是没有用的呢？这个我觉得也是很难做到测试，这些通常都是产品经理负责。

另一个大的主题就是 - Accessibility Testing 易访问性。这个通常都是针对残疾人的。当中有几个，例如视力上有缺陷的人，听觉有阻碍的人，行动不便的人等……然后我发现，对于这些，在美国是有法律来保障残疾人的权益的，看来还是人家的法律够健全啊！