软件测试学习体会Vol10.doc

软件测试学习体会Vol 10 ? 浅谈测试覆盖率 从理论上讲测试是永无止境的，只要不断测试就一定能不断发现问题。那究竟如何度量测试的进度，如何判断测试可以完结，这些，可以依靠测试覆盖率的分析来实现。 一、什么是测试覆盖 测试覆盖，是对测试完全程度的评测，是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。通过覆盖指标，就可以回答测试的完全程度如何这一问题。 二、最常用的覆盖评测 目前最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简单的说，测试覆盖是就需求(基于需求的)或代码的设计/实施标准(基于代码的)而言的完全程度的任意评测，如已设定测试用例的核实(基于需求的)或所有代码行的执行(基于代码的)。 1、基于需求的测试覆盖 如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了75%的性能测试需求。基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识(如已计划的、已实施的、已执行的和成功的测试覆盖)。 测试覆盖通过以下公式计算： 测试覆盖=T(p，i，x，x)/RfT 其中： T是用测试过程或测试用例表示的测试(Test)数(已计划的、已实施的或成功的)。 RfT是测试需求(Requirement for Test)的总数。 在制订测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算方法如下： 测试覆盖(已计划的)=Tp/RfT 其中： Tp是用测试过程或测试用例表示的已计划测试(Test)数。 RfT是测试需求(Requirement for Test)的总数。 在实施测试活动中，由于测试过程正在实施中(按照测试脚本)，在计算测试覆盖时使用以下公式： 测试覆盖(已执行的)=Ti/RfT 其中： Ti是用测试过程或测试用例表示的已执行的测试(Test)数 RfT是测试需求(Requirement for Test)的总数。 在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖(即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试)。 这些覆盖评测通过以下公式计算： 测试覆盖(已执行的)=Tx/RfT 其中： Tx是用测试过程或测试用例表示的已执行的测试(Test)数。 RfT是测试需求(Requirement for Test)的总数。 成功的测试覆盖(已执行的)=Ts/RfT Ts是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试(Test)数。 RfT是测试需求(Requirement for Test)的总数。 如将以上比率转换为百分数，则以下基于需求的测试覆盖的陈述成立： x%的测试用例(上述公式中的T(p，i，x，x))已经覆盖，成功率为y% 2、基于代码的测试覆盖 基于代码的测试覆盖，评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。具体而言代码覆盖率分析是这样一个过程： ●找出程序经过一系列测试而没有执行的部分代码 ●创建一个附加的测试用例来增加覆盖率 ●决定代码覆盖的定量度量。 针对代码的测试覆盖率有许多种度量方式，例如： 语句覆盖(Statement Coverage)：也称为行覆盖(line coverage)，段覆盖(segment coverage)和基本块覆盖(basic block coverage)。它度量每一个可执行语句是否被执行到了，这个覆盖度量的主要好处是它可以直接应用在目标代码上，不需要对源代码进行处理，主要缺点是对一些控制结构很迟钝。 判定覆盖(Decision Coverage)：也被称为分支覆盖(branch coverage)，所有边界覆盖(all-edges coverage)，基本路径覆盖(basis path coverage)，C2覆盖，判定路径覆盖(decision-decision-path或DDP testing)。它度量是否每个BOOL型的表达式取值true和false在控制结构中都被测试到了。这个度量有语句覆盖的简单性，但是没有语句覆盖的问题，缺点是忽略了在BOOL型表达式内部的BOOL取值。 条件覆盖(Condition Coverage)：它独立的度量每一个子表达式，报告每一个子表达式的结果的true或false。这个度量和判定覆盖(decision coverage)相似，但是对控制流更敏感。不过，完全的条件覆盖并不能保证完全的判定覆盖。 路径覆盖(Path Coverage)：也称为断言覆盖(predicate coverage)，它度量了是否函数的每一个可能的分支都被执行了。路径覆盖的一个好处是：需要彻底的测试。