你的测试覆盖率到底是多少？

lvkai · 发表于 2009-11-23 14:09:21

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

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

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

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

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

949758911 · 发表于 2012-2-7 16:00:54

学习

andy_wangyt · 发表于 2011-12-6 22:09:38

测试覆盖率一是个比较难确定的量，我觉得还是用是否覆盖了所有的功能来判断比较好

annie_xfz · 发表于 2011-11-1 10:36:31

给你，也给楼主：

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

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

lmyn · 发表于 2011-10-26 14:59:29

我们只能尽可能的提高覆盖率，但是说不出来覆盖率是多少了，或者根据长期观察出bug的情况，得出一i个相对的覆盖率。。

wzc · 发表于 2011-10-26 14:23:37

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

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

inny100 · 发表于 2011-10-18 17:35:04

好专业啊

061001 · 发表于 2011-10-18 15:49:29

太专业啦，离这个层次还有很长的路要走

vi_2010 · 发表于 2011-10-18 15:32:39

大家都讲得好专业啊，看来测试经验丰富啊，学习，关注中

1977fx1250 · 发表于 2011-9-28 10:46:28

测试覆盖率。这个分母应该是需求矩阵，分子是你案例的分类数吧？

1595819808 · 发表于 2011-9-25 19:15:11

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

yxd2006 · 发表于 2011-9-16 10:31:37

不太明白，关注中……

yanxiudeng · 发表于 2011-3-23 16:37:27

我觉得这个覆盖率很难说的好,重点是设计出来的用例是否确实有效.不然光用例一大堆,而没什么真实意义的话也没有用.

chengning · 发表于 2010-3-4 15:59:30

oac · 发表于 2010-3-4 13:32:32

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

yzwangxf · 发表于 2009-12-16 13:02:52

粒度的问题，涉及到水平和资源，
换句话说，你要的覆盖率真实有多高，代表了你们的水平有多高，投入的资源有多少。

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

willyenillye · 发表于 2009-12-7 17:15:54

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

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

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

给你，也给楼主：

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

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

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

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

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

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

Jackc · 发表于 2009-11-26 15:51:28

看了LZ的想法，挺佩服的，在N多人还在追求怎样套用公式的时候，LZ已经开始尝试用工具参与风险分析的构造了

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

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

期待LZ的进一步分享~

lvkai · 发表于 2009-11-24 10:17:17

同意，现在做手工全回归的，肯定是当前的测试用例设计的很不充分。

mentgmery · 发表于 2009-11-23 17:03:09

开发代码的覆盖率是很有意义的,是很好的度量工具
但是测试用例的覆盖率感觉不是那么科学,或者说不如代码的覆盖率来的直接些,效率太低了

		自动登录	找回密码
密码			(注-册)加入51Testing

[讨论] 你的测试覆盖率到底是多少？

相关帖子

关键在于分解的粒度。

站长推荐 /1