软件可测试性

软件可测试性(Software testability)是指一个软件工件(软件系统、模组、需求文件或设计文件等)在一给定的测试环境下,可支援测试的程度。

许多软件系统是不可测试的,或是无法立即测试。例如Google的ReCAPTCHA,若没有任何有关图的元资料,则无法成为可测试的系统。不过若针对每一张图,都有对应说明应有结果的标签,就可以测试此一系统。因此软件工件的可测试性不是内在英语Intrinsic and extrinsic properties性质,不像软件大小一様可以直接量测。软件可测试性是外在性质,由待测试的软件及测试目标、方法及测试资源(测试环境)之间的相互关系来决定。

“可测试性”和设计良好程度的相关性可由以下现象看出:低内聚性、高耦合力、存在多余程式码,以及缺乏封装的程式往往也是不容易测试的程式[1]。若软件的可测试性低,可能会造成测试工作的增加。在一些极端的情形下,缺乏可测试性可能会使部分甚至全部的测试或对软件需求英语Software requirements的评估无法进行。

为了要找到可测试性以及利用测试找到系统中潜在错误(假设有错误时)的难度的关系,有一种评估可测试性的相对指标,是每一次需要多少的测试用例才能形成完整的测试套件(在测试了所有测试用例后,所得到的结果可以确定此系统符合某规格,或不符合某规格,不会有模糊地带)。若数量不大,表示程式的可测试性高。依照此方式,已有提出可测性等级(testability hierarchy)[2][3]

背景知识

依照实证的假设,软件测试的工作量及有效性和以下几个因素有关:

  • 软件需求英语Software requirements的性质。
  • 软件本身的性质(像大小、复杂度及可测试性)。
  • 测试方法的的性质。
  • 开始及测试流程的性质。
  • 和测试流程有关人员的资格和动机。

软件元件的可测试性

软件元件(模组或类别)的可测试性和以下因素有关:

  • 可控制性:是否可以将待测元件的状态控制到如测试条件要求。
  • 可观察性:是否可以观察(中间或最后的)测试结果。
  • 可隔离性:待测元件是否可以隔离测试。
  • 关注点分离:待测元件是否有单一且清楚定义的任务。
  • 易懂性:待测元件是否有说明文档,或是本身可读性很高。
  • 可自动化性:待测元件是否可以自动测试。
  • 异质性:是否需要不同的测试方法及工具平行测试。

软件元件的可测试性可以用以下方式提升:

需求的可测试性

具有测试性的软件需求英语Software requirements需求要符合以下的条件:

  • 一致性
  • 完整性
  • 明确不含糊
  • 可量化(像“反应时间快”的需求是无法被验证的)
  • 实务上的软件验证及确认(不只是理论上可行,在有限资源下也是可实现的)

相关条目

参考资料

  1. ^ Shalloway, Alan; Trott, Jim. Design Patterns Explained, 2nd Ed . 2004: 133. ISBN 978-0321247148. 
  2. ^ Rodríguez, Ismael; Llana, Luis; Rabanal, Pablo. A General Testability Theory: Classes, properties, complexity, and testing reductions. IEEE Transactions on Software Engineering. 2014, 40 (9): 862–894 [2020-09-15]. ISSN 0098-5589. doi:10.1109/TSE.2014.2331690. (原始内容存档于2021-04-17). 
  3. ^ Rodríguez, Ismael. A General Testability Theory. CONCUR 2009 - Concurrency Theory, 20th International Conference, CONCUR 2009, Bologna, Italy, September 1–4, 2009. Proceedings: 572–586. 2009. ISBN 978-3-642-04080-1. doi:10.1007/978-3-642-04081-8_38.