既然选择远方,便只顾风雨兼程……
测试覆盖率之三——测试覆盖率100%相关的话题
上一篇 /
下一篇 2008-12-10 21:39:48
/ 个人分类:测试覆盖率系列
上一篇文章中,介绍了
测试覆盖率的意义之类的东西。测试覆盖率可以帮助我们检查测试质量,检查测试用例的有效率。如果有兴趣的话,可以阅读
测试覆盖率之二——测试覆盖率有什么用?tu4`.ibdfD0rEbX qB3o
zIKcv0 关于测试覆盖率,我个人的感觉是说的多,用的少。最近在网络上看到一篇文章,讨论一个问题“测试需要100%的覆盖率吗?”被
转载了很多次,有兴趣的同行可以找来看看。的确,一想到测试覆盖率,立马就有完美主义者跳出来说100%。100%的测试覆盖率有什么好处呢?
*['Zm:V7I'~/]%~o;u0 1, 100%的覆盖率表示我们的测试覆盖到了所有语句,分支,条件
51Testing软件测试网i3o9`csc1Vq 2, 100%的覆盖率表示我们测试考虑的很完全,我们可以回去睡大觉了~~
51Testing软件测试网e!dn u+l测试仿佛在这里变得不那么可怖了,但是我们至少遗漏了两个重要的地方:怎么达到100%的测试覆盖率或者说是否能够达到100%的测试覆盖率,另外一个就是100%的测试覆盖率到底能告诉我们什么信息。
#@]}-GnGHW0 首先来讲,我们是否可以达到100%的测试覆盖率?如果我们简单的将测试覆盖率理解为需求覆盖率,代码覆盖率,那么我想这是可以达到的,只要拥有足够的时间,我们的测试覆盖到每一个需求点,我们的测试覆盖到每一条语句,每一个条件,每一个分支,看起来的确没有问题。但是我们还要考虑另外一个问题,是否由我们未曾列入到需求分析中的需求呢,这种情况是存在的,如果我们计算需求覆盖率是根据Feature Spec来的(实际上如果我们需要计算的话,一般就是这样计算得来的),那么当我们有需求没有被写入Feature Spec并且我们也没有在测试中考虑相关的测试,那么我们实际的“需求覆盖率”就不是100%了。在实际开发过程中,是不可能在Feature Spec中将需求全部列出来的,所以我们得到的100%的需求覆盖率是存在水分的。
51Testing软件测试网m/sJjY3cP-|4d 另外,对于一个应用程序(除了一些极其简单的程序)来讲,要覆盖到所有的语句。条件,分支是极其困难的,甚至可以说是不可能的。笔者在经历的一个项目中花了一整天写一个模块的
单元测试,当我忙完一天并运行了所有的用例之后,我发现我的代码覆盖率仅仅增加了2%,而且是从35%到37%,不要说100%,连80%我当时都觉得是奢望。
Caj3O
{7q\@0 对于第二个问题,100%的测试覆盖率能代表什么?我在上面讲到,100%的测试覆盖率表示覆盖到了所有的语句,分支和条件,但是这又说明什么呢?这是否说明了我们做到了完全测试一个软件呢?很抱歉,答案是否定的。给出下面这一段代码:
(C5h#Rj%d([n0:k @)Cp Wq8q0private int add(int a,int b)
51Testing软件测试网i@x9QU[Hd/]{
51Testing软件测试网VO7J9?P return a+b;
0J0A/@2KL d5T!^0}
51Testing软件测试网2An0u1C-N#C[N1r