51Testing软件测试论坛

标题: 你的测试覆盖率到底是多少？ [打印本页]

作者: lvkai 时间: 2009-11-23 14:09
标题: 你的测试覆盖率到底是多少？
我做软件功能测试和测试自动化有6年了。在每个项目中，我都会被人问这样两个问题，“你现在的测试覆盖率是多少？”， “自动化率是多少？”。每次我都按照惯例来回答这两个问题。但我内心一直对这两个问题非常困惑。因为分子还好统计，但是分母呢？用我们当前的测试用例总数做分母真的是合理的吗？我们当前的测试用例都是有效的吗？我们当前的测试用例能代表100%吗？实际上，对我经历过的很多项目而言，当前的测试用例代表的覆盖率经常相当低。因为我们总是能在测试用例之外发现很多新的defect，L2也总能开出没被我们覆盖到的APAR.

那么，这个代表100%的测试用例集合，我们能做出来吗？能否把它标准化呢。

我现在考虑的方向是，通过标准化的功能描述（可能用XML），通过一个生成测试用例的引擎，按照我们设定的一些规则,来生成测试用例。

可以通过两种方法来不断的完善这个引擎和规则的集合。
1. 通过和人工设计的测试用例比较，逐步提高这个引擎的智能。
2. 研究每个测试用例之外的defect, 进一步提高这个引擎的智能。

http://blog.sina.com.cn/s/blog_406a3c480100g03n.html

作者: yolander 时间: 2009-11-23 15:14
很好的想法，可惜我现在上不去sina网站，看不到你的全文，如果能放在51testing的blog里就好了
测试用例覆盖率，通常是统计测试用例对需求的覆盖率，这时测试用例数是要做分子的，分母应该为需求的条数
自动化测试比率，倒是可以用测试用例数做分母，将能够实现自动测试的用例数做分子来进行统计
我想LZ的问题一定不是不会计算这个比率，而是如何提高这个比率的问题，而LZ所说的引擎，倒是可以考虑一下，针对不同风险或者说重要等级的需求，采取不同的测试策略，也就是LZ谈到的用例生成规则，不要一撮而就，否则用例数是无穷大的

作者: lvkai 时间: 2009-11-23 16:17
测试用例数量是非常大的，下一步是确定一些规则来选取测试用例，初步的想法是引入优先级和重要程度两个参数，另外，还可以根据历史测试结果来选取测试用例。

作者: mentgmery 时间: 2009-11-23 17:03
开发代码的覆盖率是很有意义的,是很好的度量工具
但是测试用例的覆盖率感觉不是那么科学,或者说不如代码的覆盖率来的直接些,效率太低了

作者: lvkai 时间: 2009-11-24 10:17
同意，现在做手工全回归的，肯定是当前的测试用例设计的很不充分。

作者: Jackc 时间: 2009-11-26 15:51
看了LZ的想法，挺佩服的，在N多人还在追求怎样套用公式的时候，LZ已经开始尝试用工具参与风险分析的构造了

如果偶能在一个公司干个10年、8年的，偶也许也会尝试LZ的道路。

不过就如今就业不稳定的IT界来说，偶也许找不到那么多的时间去进行风险分析工具的开发了

期待LZ的进一步分享~

作者: willyenillye 时间: 2009-12-7 17:15

原帖由 Jackc 于 2009-11-26 15:51 发表
看了LZ的想法，挺佩服的，在N多人还在追求怎样套用公式的时候，LZ已经开始尝试用工具参与风险分析的构造了

如果偶能在一个公司干个10年、8年的，偶也许也会尝试LZ的道路。

不过就如今就业不稳定的IT界来说， ...

给你，也给楼主：

这个很正常。在开始思考测试理论的时候，总会去追求一个理想型。问题是，现在谈测试的理想型，有意义么？

当你在开始设计理想的测试用例的时候，你会发现，开发出来的代码千变万化，开发工程师的设计不是理想的，会产生理想的测试用例么？

那么粗略些，使用概要设计去做理想的测试用例，你会发现，设计师的设计也是漏洞百出，逻辑自相矛盾，会产生理想的测试用例么？

那么再粗略些，直接使用需求去做理想的测试用例，你会发现，客户需求本身几乎没什么逻辑，或者有些公司能够独立出需求分析人员对需求进行逻辑化标准化，但是很多客户都不知道自己到底要什么，需求的各个部分相互掺杂，相互矛盾，会产生理想的测试用例么？

这个世界本来就是不完美的，每个项目都会是独特的，逻辑非常复杂。事实上，大多数的，由逻辑产生的测试用例都是无用的，用户不关心的，徒劳无功的。

如果单纯的做测试，做十年，你还在梦想这样完美的项目，那么你也只能做到测试经理这一块，质量控制你都无法胜任，更别说项目的总体把握，总监一类的职务了。

作者: yzwangxf 时间: 2009-12-16 13:02
标题: 关键在于分解的粒度。
粒度的问题，涉及到水平和资源，
换句话说，你要的覆盖率真实有多高，代表了你们的水平有多高，投入的资源有多少。

我们在实际写用例也好，分解需求也好，真正意义上的全覆盖，是不可能的。
采用对需求功能点的分析法，得到基本的业务需求，然后测试用例对业务需求实现数量上的全覆盖，
接下来，采用合适的测试方法，对用例进一步在内容上提高覆盖程度，后者才是真实的覆盖。

作者: oac 时间: 2010-3-4 13:32
很有同感，很多管理人员对自动化测试的应用在理解上存在误区，不能够为自动化测试在项目中寻找到合适的位置，所以执行自动化测试的人员就困惑了。一场艰难的搏弈

作者: chengning 时间: 2010-3-4 15:59

作者: yanxiudeng 时间: 2011-3-23 16:37
我觉得这个覆盖率很难说的好,重点是设计出来的用例是否确实有效.不然光用例一大堆,而没什么真实意义的话也没有用.

作者: yxd2006 时间: 2011-9-16 10:31
不太明白，关注中……

作者: 1595819808 时间: 2011-9-25 19:15
覆盖率一直我觉得都是一个很重要的东西这个是个整体逻辑思维的东西有人会说如果太过于纠结覆盖率会导致自己的目标缺失但是我觉得万丈高楼平地起楼主的意见很好做测试的要对自己负责大的方向自然要走对但是如果不注重细节所有的一切都可能会毁掉虽然客户是不太看重这些但是如果作为专业的人员也不看重的话一旦出错失去的就是客户的信任对公司对企业造成的损失将不可度量

作者: 1977fx1250 时间: 2011-9-28 10:46
测试覆盖率。这个分母应该是需求矩阵，分子是你案例的分类数吧？

作者: vi_2010 时间: 2011-10-18 15:32
大家都讲得好专业啊，看来测试经验丰富啊，学习，关注中

作者: 061001 时间: 2011-10-18 15:49
太专业啦，离这个层次还有很长的路要走

作者: inny100 时间: 2011-10-18 17:35
好专业啊

作者: wzc 时间: 2011-10-26 14:23
首先，测试覆盖率的概念，个人认为只应在白盒测试中运用。可以通过工具读取代码，从而分析得出总量作为分母，这样可以得到相对准确的覆盖率。但如果是黑盒测试的话，精确的覆盖率是几乎不可能得到的。

所以，在黑盒测试的覆盖率一说，基本上可以认定为，在制定测试策略时，所划定的测试范围究竟完成了多少的完成率而已。

作者: lmyn 时间: 2011-10-26 14:59
我们只能尽可能的提高覆盖率，但是说不出来覆盖率是多少了，或者根据长期观察出bug的情况，得出一i个相对的覆盖率。。

作者: annie_xfz 时间: 2011-11-1 10:36

给你，也给楼主：

这个很正常。在开始思考测试理论的时候，总会去追求一个理想型。问题是，现在谈测 ...
willyenillye 发表于 2009-12-7 17:15

说的很对呀。在我们公司就是一个典型的需求随时变更，技术不按照需求实现功能的团队。我写出来的用例，有一大半是废的。很多东西还是要结合实际啊！

作者: andy_wangyt 时间: 2011-12-6 22:09
测试覆盖率一是个比较难确定的量，我觉得还是用是否覆盖了所有的功能来判断比较好

作者: 949758911 时间: 2012-2-7 16:00
学习

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)