覆盖率

1.需求覆盖-------------涉及到两个方面：需求覆盖率和具体的需求覆盖情况。1.1.需求覆盖率=测试用例涵盖的需求数/所有需求数*100%。更进一步，可以定义需求筒盖率和需求部分覆盖率。前者描述已经被充分测试的需求，后者描述已被覆盖但未充分测试的需求。“充分”的定义依据测试需求而定，依据具体情况而不同。比如一个用户登录的功能，当功能测试和性能测试都运行过后，可以认为被充分覆盖了。如果只做了功能测试，则是部分覆盖。一个项目的需求覆盖率描述可以像这样：需求筒盖率：80%需求部分覆盖率：15%未覆盖需求：5%另外当需求被充分细化后，有可能不再需要需求部分覆盖率，因为未覆盖的需求部分可以细化为新的需求条目。比如以上例子的用户登录需求可以细化为登录功能需求和登录性能需求两项。需求覆盖率的确定可以有两种方式：精确统计和模糊评估。精确统计要求需求定义合理，条目清晰，能够精确知道需求点的数量。最好能够利用测试管理工具来管理需求，如HP的QC,TestDirector等。每个需求的覆盖情况都要记录而且能够追踪。那么需求点的数量就是覆盖率的分母，被覆盖（万部分）的需求数就是分子。模糊评估通常是在管理条件没那么完善的情况下实施的，需求的条目可能不是特别清晰，需求的覆盖也没有精确定义。这种情况下对覆盖率的定期的评审和讨论就显得非常重要。项目组要通过定期评审，对需求覆盖率达成基本一致的意见。关于需求覆盖的完美程度，在精确统计模式下，有可能实现100%的覆盖指标。但是这并不意味着系统被完美测试了。因为需求可能是不湍，对每个需求的测试用例设计也可能不是完美覆盖的。对于这点，测试团队领导要有清醒的认识。而在模糊评估的模式下，测试组尤其要注意是否有需求遗漏。1.2.具体需求覆盖简单说，就是描述每个需求被哪些用例覆盖，以及每个需求整体被覆盖情况。流行的描述方式是利用RequirementsTraceabilityMatrix(RTM，需求跟踪矩阵，我可能翻译得不好)。就是一个表格，记录每个需求被测试用例覆盖的情况。一个简单的RTM模板可参见下图。复杂的TRM可以记录更多更详细的信息。可参考总结：需求覆盖率是一个很方便直观的指标，特别是给管理层领导和客户进行概括性审阅的时候。而具体需求覆盖则有助于客户了解系统被测试到什么程度了。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%:应该修复，但是因为种种原因尚未被修复的缺陷。该指标可评估被测系统的当前质量。缺陷覆盖还可以细化到针对不用类型的缺陷（例：不同的严重程度和岸别）计算不同的覆盖率。这里就不累述了。总结：需求覆盖和测试覆盖的各项指标可以帮助测试的各个阶段评检查当前阶段是否结束，是否可以进入下一阶段。特别在测试执行和测试结束阶段起到很重要作用。具体如何利用这些指标则要根据项目的具体要求而定。比如测试某些柏键系统会要求所有缺陷都必须修复后测试才能结束。而某些系统的测试结束可能只要求没有严重缺陷。