51Testing软件测试论坛

标题: 系统测试报告中测试充分性分析中的需求覆盖,测试覆盖如何写?（获奖名单公布） [打印本页]

作者: lsekfe 时间: 2012-12-3 11:17
标题: 系统测试报告中测试充分性分析中的需求覆盖,测试覆盖如何写?（获奖名单公布）
系统测试报告中测试充分性分析中的需求覆盖,测试覆盖如何写?
此话题由会员piaohuar2008提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
[attach]82594[/attach]

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	wheetle	50元移动充值卡	10#

作者: xiaonan 时间: 2012-12-3 12:26
测试报告中测试充分性分析,主要体现在一个静态分析,体现的数据指标是测试活动持续时间,执行用例数,发现缺陷总数,平均每小时用例数 ,平均每小时发现的缺陷数和千行代码用例数等用来对整个测试覆盖的一个总结

作者: liushuang8365 时间: 2012-12-3 14:06
如果需求定义已经写好，衡量需求覆盖和测试覆盖最直接的方法就是看有多少个需求功能测试点和需求性能测试点

作者: 土土的豆豆 时间: 2012-12-3 14:55
这个好些有专门的测试充分性算法或基于充分性测试的准则吧。
可以通过度量来权衡。
相对于白盒测试阶段中基本语句覆盖、路径覆盖、条件覆盖、及其组合覆盖，可以通过设计测试数据集合或离散上的谓词原理来分析。具体LZ可以查查相关资料。

作者: loho1968 时间: 2012-12-5 16:07
本帖最后由 loho1968 于 2012-12-5 16:08 编辑

覆盖一般用“覆盖率”来表示，“率”就是2个数字的比率。
要算出需求覆盖“率”，就必须有需求的“数量”，然后把测试用例和需求对应，一个需求至少有一个用例对应的时候，就算是需求被“覆盖”了。

测试覆盖就不好理解了，是测试覆盖什么？
所以说关键是现确定测试指标，在设计验证指标的方法。

作者: netwater 时间: 2012-12-6 10:22
关注，

作者: TesterChen 时间: 2012-12-7 14:30
系统测试报告中测试充分性分析中的需求覆盖,测试覆盖如何写?

需求覆盖率：（需求覆盖率=测试用例涵盖的需求数/项目所有需求数*100%）
方式一：如果需求已经定义好，衡量需求覆盖率的最直观的方式是我们有多少功能点，我们有多少性能点要求，这些将作为分母；我们写了多少测试用例，覆盖了多少模块，多少功能点，我们的性能测试用例考虑了待测程序多少性能点，这些作为分子。

如：我们系统一共有10个功能和性能点可测试，但我们测试用例只覆盖其中的9个功能点，那么我们的需求覆盖率为90%

方式二：可以通过测试用例评审会议来确定测试用例对需求的覆盖是否完全
测试用例评审通过这个标志，就表示我们的测试在目前能想到的情况下覆盖是100%的
而在实际的测试过程中我们也只能想当然的达到100%，但实际不可能
后续我们在执行过程中可能会发现有测试点的遗漏，会要进行补充，也就是说之前的覆盖是不全的，没有达到100%

如：
在某次回归测试报告中我们只对系统中共有的10个需求点中的5个进行回归测试，那么此次执行的需求覆盖率只有50%

测试覆盖率：
我暂时把他理解为测试用例执行率（测试用例执行率=当前执行的测试用例总各/该项目所有测试用例总各*100%）
全面的回归测试，测试用例执行率就是100%

我们的真正的测试过程中往往因为时间、人员、精力等原因不能100%的执行所有测试用例；同时小规模的改动，如果大规模的回归测试也很费精力、时间

在这个时候我们就需要有选择性的执行测试用例
如果整个项目有1000条测试用例，本次更新引起的变更需要测试其中的500条测试用例，我们就称此次的测试覆盖率（测试用例执行率）为50%

作者: 1290705624 时间: 2012-12-10 14:43
新手关注

作者: liulinzhu 时间: 2012-12-14 10:16
需求覆盖：
1.每个需求都会有相应的任务单，只要填上相应的测试标志即可，譬如Y，N。如果是部分测试(仅指需求)，那可以把其中的未测部分单独写到‘未测项’里。
2.编写测试报告时，只需按测试标志筛选汇总，同时汇总未测项即可。

测试覆盖：
1.正如#7童鞋所说，在有限的条件里往往不能做到充分测试，因此部分用例会没被执行。同样用例编写也会受到条件限制，应根据功能价值来区分用例设计的精细程度。
2.对编写的用例设定优先级，并按各自情况来定义执行覆盖通过的标准，譬如：等级高、中的必须100%完成，等级低的不低于50%。

以上两点，个人建议纳入到风险评估里，领导不一定理解测试的各个维度，所以还是合并反馈比较合适。

作者: wheetle 时间: 2012-12-17 14:30
本帖最后由 wheetle 于 2012-12-17 15:23 编辑

1.需求覆盖-------------

涉及到两个方面：需求覆盖率和具体的需求覆盖情况。

1.1. 需求覆盖率= 测试用例涵盖的需求数/所有需求数 * 100%。

更进一步，可以定义需求筒盖率和需求部分覆盖率。前者描述已经被充分测试的需求，后者描述已被覆盖但未充分测试的需求。“充分”的定义依据测试需求而定，依据具体情况而不同。比如一个用户登录的功能，当功能测试和性能测试都运行过后，可以认为被充分覆盖了。如果只做了功能测试，则是部分覆盖。一个项目的需求覆盖率描述可以像这样：
需求筒盖率： 80%
需求部分覆盖率： 15%
未覆盖需求：5%

另外当需求被充分细化后，有可能不再需要需求部分覆盖率，因为未覆盖的需求部分可以细化为新的需求条目。比如以上例子的用户登录需求可以细化为登录功能需求和登录性能需求两项。

需求覆盖率的确定可以有两种方式：精确统计和模糊评估。精确统计要求需求定义合理，条目清晰，能够精确知道需求点的数量。最好能够利用测试管理工具来管理需求，如HP的QC, TestDirector等。每个需求的覆盖情况都要记录而且能够追踪。那么需求点的数量就是覆盖率的分母，被覆盖（万部分）的需求数就是分子。

模糊评估通常是在管理条件没那么完善的情况下实施的，需求的条目可能不是特别清晰，需求的覆盖也没有精确定义。这种情况下对覆盖率的定期的评审和讨论就显得非常重要。项目组要通过定期评审，对需求覆盖率达成基本一致的意见。

关于需求覆盖的完美程度，在精确统计模式下，有可能实现100%的覆盖指标。但是这并不意味着系统被完美测试了。因为需求可能是不湍，对每个需求的测试用例设计也可能不是完美覆盖的。对于这点，测试团队领导要有清醒的认识。而在模糊评估的模式下，测试组尤其要注意是否有需求遗漏。

1.2. 具体需求覆盖

简单说，就是描述每个需求被哪些用例覆盖，以及每个需求整体被覆盖情况。流行的描述方式是利用Requirements Traceability Matrix(RTM，需求跟踪矩阵，我可能翻译得不好)。就是一个表格，记录每个需求被测试用例覆盖的情况。一个简单的RTM模板可参见下图。复杂的TRM可以记录更多更详细的信息。可参考 http://www.pmhut.com/requirements-traceability-matrix-rtm

[attach]82789[/attach]

总结：需求覆盖率是一个很方便直观的指标，特别是给管理层领导和客户进行概括性审阅的时候。而具体需求覆盖则有助于客户了解系统被测试到什么程度了。

2. 测试覆盖-------------

这个问题就有点大了，楼主是不是想问测试用例覆盖？不过为了慎重起见，我还是列出我所理解的各种不同测试覆盖，其中多说两句测试用例覆盖和缺陷修正覆盖。

2.1 缺陷覆盖率，通常是：已发现缺陷 /恳阎毕� * 100%。该指标在开发测试工具时经常用到，测试被植入特定缺陷的程序。可用来评估测试工具的效能。

2.2 测试环境覆盖：

* 被配置并使用的测试环境数 vs 计划的测试环境数，
* 测试开始后新增的测试环境数 vs 计划的测试环境数。

这两个指标可评估测试准备情况是否充分。

2.3 测试数据覆盖率：被使用的测试数据量 / 准备好的测试数据量 * 100%。该指标可评估测试准备情况是否充分。

2.4 测试用例覆盖：不同的用例覆盖率用来评估不同的情况：

2.4.1. 已运行的用例数 / 用例总数 * 100%: 评估测试执行的完整性

2.4.2. 通过的用例数 / 用例总数 * 100%，失败的用例数 / 用例总数 * 100%: 这里可以细化为一次通过的和多次通过的用例。可以用于评估测试难度，总结被测系统中的测试难点。

2.4.3. 重用的旧用例数 / 用例总数 * 100%，未来可重用的用例数 / 用例总数 * 100%: 可以评估测试用例的通用性和质量，以及评估公司开发的以往旧系统和现在的被测系统程序模块的重用性

2.4.4. 回归测试的用例数 / 用例总数 * 100%: 评估被测系统的更新情况，以及自动化测试的可行性

2.4.5. 自动化用例数 / 用例总数 * 100%: 评估测试自动化的情况

2.4.6. 废弃的用例数 / 用例总数 * 100%: 某些用例可能由于需求变更而不再需要。该指标也可评估评被测系统的更新情况。

用例覆盖还可以细化到针对不用级别的用例（例：不同优先级）计算不同的覆盖率。这里就不累述了。

2.5 缺陷用例覆盖：不同的覆盖率用来评估不同的情况。看看以下几个覆盖率：

2.5.1. 被修正的缺陷数 / 发现的缺陷总数 * 100%: 评估系统的QA质量

2.5.2. 不必修正的缺陷数 / 发现的缺陷总数 * 100%: 某些缺陷是可以接受的，不必修正，例如用户友好度的缺陷在项目紧张时可以不必修复。该指标可评估测试效率。

2.5.3. 废弃的缺陷数 / 发现的缺陷总数 * 100%: 废气的缺陷可能是由于相关的需求或相关程序模块被取消。该指标可评估被测系统的更新情况。

2.5.4. 未修复的缺陷数 / 发现的缺陷总数 * 100%: 应该修复，但是因为种种原因尚未被修复的缺陷。该指标可评估被测系统的当前质量。

缺陷覆盖还可以细化到针对不用类型的缺陷（例：不同的严重程度和岸别）计算不同的覆盖率。这里就不累述了。

总结：需求覆盖和测试覆盖的各项指标可以帮助测试的各个阶段评检查当前阶段是否结束，是否可以进入下一阶段。特别在测试执行和测试结束阶段起到很重要作用。具体如何利用这些指标则要根据项目的具体要求而定。比如测试某些柏键系统会要求所有缺陷都必须修复后测试才能结束。而某些系统的测试结束可能只要求没有严重缺陷。

作者: konnie 时间: 2012-12-21 15:42
测试用例针对每个需求进行覆盖，用例评审时就已经确定是否覆盖桶其覆盖率，系统测试报告中针对测试用例执行情况统计通过率，总通过数/用例总数为用例通过率，同步反应出需求覆盖率，在数字-率上给予一定说明。
报告中除说明每个需求对应的用例通过覆盖情况外，每项仍会给出：主体功能是否通过，存在的主要问题有哪些；并在每项中给出测试人员对此项功能实现的看法和建议说明。

作者: willyenillye 时间: 2012-12-26 10:40
回复 10# wheetle

这个说的还不错。
软件生命周期中，需求-》设计-》代码，逐步实现。

因此谈到覆盖率，至少应当包含：

功能对业务覆盖；
用例对功能覆盖；
用例对业务覆盖；
用例对接口覆盖；
用例对代码覆盖；
执行对用例覆盖；
缺陷对用例覆盖。

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