《各种覆盖率方法介绍》由会员分享，可在线阅读，更多相关《各种覆盖率方法介绍（3页珍藏版）》请在金锄头文库上搜索。
1、各种覆盖率方法介绍(3) 3 其它度量 这里介绍一些其它的基本的很少使用的度量的益处和弱点。 3.1 函数覆盖（Function Coverage ） 这个度量报告是否你调用了每个函数或过程。对于初步的测试来保证至少在所有的软件没有总的不足非常有用。 大多数覆盖率工具都支持。 3.2 函数出入口覆盖（Function Exits Coverage） 报告对函数的入口、出口和终止指令.覆盖情况统计。 据我所知，TestRT 支持此覆盖。 3.3 调用覆盖（Call Coverage ） 这个度量报告是否你执行每个函数调用。前提是缺陷一般发生在模块的接口处。 也称呼为调用对覆盖（call pair
2、 coverage） 。 据我所知，TestRT 支持此覆盖。 3.4 线性代码顺序及跳转覆盖（Linear Code Sequence and Jump (LCSAJ) Coverage ） 这个是路径覆盖（path coverage ）的一个变更。考虑到在源代码中只有子路径可以被容易的替，不需要一个流程图。一个 LCSAJ 是一系列源代码线执行的序列。 优点是这个度量比判定覆盖测试的更彻底，而且避免了路径覆盖的指数级的难度。缺点是它不能避免不可实行的路径。 据我所知，LDRA TestBed 支持此覆盖。 3.4.1 覆盖率的计算公式： 如下图所示： 一个 LCSAJ 是由以下四个特征的数
3、量决定的。 A Start Point：可以是程序的开始或任何控制流跳转的目标的线。 A Linear Code Sequence：通过可以系列处理的控制流的代码体。可以由几个连续的基本块组成。 An End Point：The first line encountered from which a jump is made which has been reached from the start point by the unbroken linear sequence of code. A Target Point： The point to which the End Points c
4、ontrol flow jump is made. This will be the Start Point of the next LCSAJ. Therefore, since the start point of the linear code sequence is a line which is the target of another jump, these fragments are also called jump-to-jump paths. 这个例子的计算此 LCSAJ 覆盖的分母就是 11。 3.5 数据流覆盖（Data Flow Coverage ） 这是 path
5、coverage 的一个变种，只是考虑到从变量的分配到后来的变量的引用的子分支。 好处是直接适当的报告程序处理的数据。一个缺点是不包含判定覆盖，另一个缺点是太复杂。很多的变量，用于计算的、用于判定的、局部的、全局的，如果有指针就更复杂。 3.6 目标代码分支覆盖（Object Code Branch Coverage ） 这个度量报告是否机器语言条件分支通过了分支。 这个度量给出的报告更多的是依赖编译器而不是程序结构。因为目标代码的结构和源程序的结构很不相似。而且，分支破坏了指令通道，编译起有时候避免产生一个分支，而替换为一个系列的无分支指令。 3.7 循环覆盖（Loop Coverage ）
6、 这个度量报告你是否执行了每个循环体零次、只有一次还是多余一次（连续地） 。对于 do-while 循环，循环覆盖报告是否执行了每个循环体只有一次还是多余一次（连续地） 。 这个度量的有价值的方面是确定是否对于 while 循环和 for 循环执行了多于一次，这个信息在其它的覆盖率报告中是没有的。 据我所知，GCT 和 rational TestRT 可以执行这个度量。 3.8 竞争覆盖（Race Coverage） 这个度量报告是否多个线程在同一时间执行了同一块代码。它帮助检测资源的同步失败问题。对于多线程的程序例如操作系统程序非常有用。 据我所知，GCT 可以执行这个度量。 3.9 比较操
7、作符覆盖（Relational Operator Coverage） 这个度量报告是否对于比较操作符(, =)是否发生了边界条件。假设边界条件测试用例发现了 off-by-one errors ，并且 错误使用了比较操作符，例如把 用作了=。例如，考虑如下的 C/C+ 代码： if (a b) statement; 比较操作符报告是否发生了条件 a=b。如果 If a=b 发生了而且程序执行正常，那么。 。 。 。 。 据我所知，GCT 可以执行这个度量。 3.10 弱变化覆盖（Weak Mutation Coverage） 这个度量和 relational operator coverage
8、 相似，但是更普遍 Howden1982。它报告是否测试用例发生了错误的引用了操作符和操作数。 据我所知，GCT 可以执行这个度量。 3.11 表覆盖（Table Coverage） 这个度量显示是否一个特殊的数组的每个入口都被引用。这个度量对于一个通过有限状态机来控制的程序非常有用。 4 比较各种覆盖 Decision coverage 包含 statement coverage， Condition/decision coverage 包含 decision coverage 和 condition coverage Path coverage 包含 decision coverage.
9、Predicate coverage 包含 path coverage 和 multiple condition coverage Academia 说强的覆盖率度量包含了弱的覆盖率度量。 各种覆盖率度量结果不能从数量上比较。 4.1 对 Release 版本的覆盖目标 每个项目都要选择一个最低的覆盖率目标，对安全标准严格要求的软件应该制定一个高的目标。单元测试的目标应该比系统测试的高，因为一个在低水平代码的 failure 可以影响到多个高水平代码的调用者。 用 statement coverage, decision coverage 或 condition/decision covera
10、ge ，在发行版本前 80 -90 或更多的覆盖率。可能有人觉得制定的目标少于 100 的覆盖率不能保证软件质量，但是你耗在覆盖率技术上的时间如果用于其它测试技术，例如代码走读等，将会发现更多的faults，要避免制定的目标少于 80 。 4.2 中间版本的覆盖目标 选择一个好的中间的覆盖率目标可以很大的提高测试的生产力。 当你发现最多的 failures 用了最少的努力， 那你就有最高的测试生产力。努力怎么测量呢？创建测试用例，把它们加入到你的测试套并运行它们的总时间就是。 5 总结 覆盖分析是一种结构化测试技术，帮助弥补测试套中的缝隙。对缺少具体的、没有更新需求定义项目帮助很多。分支条件组
11、合覆盖（Condition/Decision Coverage ）技术我觉得是对于 C, C+和 Java 语言的最好的。 设置一个目标 100 的覆盖率(对于任一种覆盖率) 都将阻止测试的生产力，在发放版本之前，定一个 80 -90 或更多的目标对于语句、分支、条件覆盖率较好。 6 参考 Beizer1990 Beizer, Boris, Software Testing Techniques, 2nd edition, New York: Van Nostrand Reinhold, 1990 Chilenski1994 John Joseph Chilenski and Steven P
12、. Miller, Applicability of Modified Condition/Decision Coverage to Software Testing, Software Engineering Journal, September 1994, Vol. 9, No. 5, pp.193-200. RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification, RCTA, December 1992, pp.31, 74. Howden1982 Weak Mutatio
13、n Testing and Completeness of Test Sets, IEEE Trans. Software Eng., Vol.SE-8, No.4, July 1982, pp.371-379. McCabe1976 McCabe, Tom, A Software Complexity Measure, IEEE Trans. Software Eng., Vol.2, No.6, December 1976, pp.308-320. Morell1990 Morell, Larry, A Theory of Fault-Based Testing, IEEE Trans.
14、Software Eng., Vol.16, No.8, August 1990, pp.844-857. Ntafos1988 Ntafos, Simeon,A Comparison of Some Structural Testing Strategies, IEEE Trans. Software Eng., Vol.14, No.6, June 1988, pp.868-874. Roper1994 Roper, Marc, Software Testing, London, McGraw-Hill Book Company, 1994 7 术语表 Fault A bug. A defect 。一个臭虫，一个过失。 Error 一个人为的错误，结果是一个 fault。 Failure fault 的一个实时运行时的表现。
