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

lvkai

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

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

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

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

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

yolander

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

lvkai

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

mentgmery

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

lvkai

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

Jackc

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

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

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

期待LZ的进一步分享~

willyenillye

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

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

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

给你，也给楼主：

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

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

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

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

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

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

yzwangxf

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

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

oac

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

chengning

yanxiudeng

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

yxd2006

不太明白，关注中……

1595819808

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

1977fx1250

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

vi_2010

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

061001

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

inny100

好专业啊

wzc

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

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

lmyn

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

annie_xfz

给你，也给楼主：

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

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