这里没有软件测试的泛泛理论,只有博主的最佳实践。 博主的研究方向为静态分析和性能测试,致力于各种测试工具的引入、评估和开发。 本博的测试文章均为作者原创,转载请务必注明出处。

代码覆盖率的价值以及不足

上一篇 / 下一篇  2009-09-03 14:57:26 / 个人分类:感悟

版权声明:本文出自huior的51Testing软件测试博客:hhttp://www.51testing.com/?10851

原创作品,转载时请务必以超链接形式标明文章原始出处、作者信息和本声明,否则将追究法律责任。

The Value of Code Coverage

1 测试过程中不可缺少的一个步骤,可以揭示没有测试的代码
 
  确定代码达到的覆盖率(覆盖程度)是测试过程中不可缺少的一步。代码覆盖率的度量是软件质量度量中非常重要的一个指标,因为它可以揭示哪些代码/代码块从没有执行过,这通常是“死代码”或者“不完备测试”的指示信号。

  如果测试活动中不仅考虑了达到的覆盖率程度,还研究了单个测试用例,如该用例的执行是按照预期的路径执行的吗?,这样做的话,代码覆盖率的价值可能还会增加。

2 表示项目的进展

  如果项目总体的覆盖率一直在被监控,它在一定程度上可以表示项目的进展程度。举例:

  如果项目总体的覆盖率持续增长,表明测试进度没有落下,正在赶上;
  如果项目总体的覆盖率正在下降,可能意味着新加入的代码没有进行适当的测试。

Two Weaknesses of Code Coverage

即便是达到了要求的覆盖率,你也要时刻提醒自己,代码覆盖率还存在以下两个不足。

1 不能检测代码遗漏

例如,假设需求是这样的:“最大输入的值是500,如果输入值大于500,则将会当做500来处理”。

如果函数的实现遗漏了对输入值的检查,当然也遗漏了正确的处理方式,如果输入值大于500。代码覆盖率的检查不能发现这个问题。即便是“输入值为501”的测试用例也执行过了。

2 代码覆盖率度量对“计算”类单元“反应迟钝”

如下代码举例
long double sin(long double x_deg)
{
 int i;
  long double temp, x_rad;
  int sign = -1;
 
  x_rad = x_deg / 180 * pi ;
  temp = x_rad;
 
  for(i=3; i<=(MAX_FAC-2); i+=2)
 {
    temp += sign * pot(x_rad,i) / fac(i);
    sign *= -1; 
 } 
 return(temp);
}

执行一个测试用例(输入值x_deg = 0),输出返回0 是符合预期的结果,它是正确的。该用例的覆盖率度量指标为:

100%的分支覆盖,100%的 MC/DC覆盖,100%的MCC覆盖。

虽然你达到了100%的各种指标,但你对该函数的计算结果是正确的,还是没有信心。

另外一个完全不同的函数是signum(),它同样是输入0,返回0。

以上的例子表明,100%的代码覆盖率还远不够。


TAG:

shtesting的个人空间 引用 删除 shtesting   /   2009-11-20 12:02:20
“最大输入的值是500,如果输入值大于500,则将会当做500来处理”。这本身是一个不完整的需求,只包含原因,缺乏结果。函数的单元动态测试至少包含两个方面,一、功能测试,对于上例提及的需求,如果是正确的需求,完全可以用因果图产生相应测试用例的全集。二、白盒测试,覆盖率分析,确切地讲是对功能测试的补充,以防冗余代码的产生,代码应该是需求和设计的正向反映,如果功能测试充分,相应的覆盖率应该达到100%。
 

评分:0

我来说两句

Open Toolbar