测试度量指标介绍
在CMMI4体系的测试过程中定义了四个度量指标：测试覆盖率、测试执行率、测试执行通过率、测试缺陷解决率。为了使专/兼职测试人员理解这四个度量指标，了解如何利用现有资源收集度量数据，本文介绍这四个指标的含义及数据收集方法。
1 测试覆盖率
测试覆盖率是指测试用例对需求的覆盖情况。
计算公式：已设计测试用例的需求数/需求总数。
测试覆盖率从纬度上说包括广度覆盖和深度覆盖；从内容上说包括用户场景覆盖、功能覆盖、功能组合覆盖、系统场景覆盖。
首先说广度，是否需求规格说明书中的每个需求项都在测试用例中得到设计。其次说深度，通俗的说，是不使我们的测试设计流于表面，是否能够透过客户需求文档，挖掘出可能存在问题的地方。例如：重复点击某个按钮10次，或者依次执行新增、删除、新增同一数据的记录、再次删除该记录操作。在笔者的实际工作中碰到过这么一个例子，一个使用PL/SQL编写的系统，在某个查询界面，重复点击《查询》按钮6次后，系统就会出现查询功能失效的问题。经调试，开发人员发现是由于gdi资源未完全释放的缘故。
在设计测试用例时，我们很少单独设计广度或深度方面的测试用例，而一般是结合在一起设计。为了从广度和深度上覆盖测试用例，我们需要考虑设计各种测试用例，如：用户场景（识别最常用的20%的操作）、功能点、功能组合、系统场景、性能、语句、分支等。在执行时，需要根据测试时间的充裕程度按照一定的顺序执行。通常是先执行用户场景的测试用例，然后再执行具体功能点、功能组合的测试。
测试覆盖率数据的收集，我们可以通过需求跟踪矩阵RTM来实现。在需求跟踪矩阵，测试人员填写的“系统测试用例”列的数据。测试人员通过计算RTM列出的需求数量，和已设计测试用例的需求数量，可以快速的计算出测试覆盖率。通过RTM，测试人员，包括项目组成员都可以很清楚的、快速的知道当前这个项目测试的测试覆盖情况。
注：本RTM例子中，笔者将“概要设计”、“详细设计”、“编码”等列隐藏，只显示与测试覆盖率计算有关的内容。
2测试执行率
执行率，顾名思义，就是指实际执行过程中确定已经执行的测试用例比率。
计算公式：已执行的测试用例数/设计的总测试用例数。
读者肯定觉得很奇怪了，我们设计的测试用例肯定都是要执行的，即使是按模块来执行测试，那该模块的测试执行率肯定是100%，为什么还要设置这个指标？
其实不然。在实际测试过程中，经常有如下这种情况发生。一种情况是，因为系统采用迭代方式开发，每次Build时都有不同的重点，包含不同的内容；第二种情况是，由于测试资源的有限，不可能每次将所有设计的测试内容都全部测试完毕。由于这两种情况的存在，所以在每次执行测试时，我们会按照不同的测试重点和测试内容来安排测试活动，所以就存在了“测试执行率”这个指标。
通常，我们的测试目标是确保100%的测试用例都得到执行，即执行率为100%。但是，如前面所提到的，实际中可能存在非100%的执行率。如果不能达到100%的测试执行率，那么我们需要根据不同的情况制定不同的测试执行率标准——主要考虑风险、重要性、可接受的测试执行率。在考虑可接受的测试执行率时，就涉及到了测试用例执行顺序的问题。
在设计测试用例时，我们需要从广度和深度上尽可能的覆盖需求，所以我们就需要设计各种测试用例，如正常的测试用例、异常的测试用例、界面的测试用例等。但是在执行时，测试人员需要根据项目进度和测试时间的充裕程度，参考测试执行率标准，将测试用例按照一定的顺序执行。通常是先执行用户场景对应的测试用例，然后再执行具体功能点、功能组合的测试，完成这些测试后，再进行其它测试，如系统场景、性能、语句等测试。
例如，某项目共设计了280个测试用例。该项目某一阶段的测试共分四个版本，其中有一个版本执行了134个测试用例，那么该版本的测试执行率为47.9%。
3测试执行通过率
介绍了执行结果定义后，我们来看测试执行通过率。测试执行通过率，指在实际执行的测试用例中，执行结果为“通过”的测试用例比率。
计算公式：执行结果为“通过”的测试用例数/实际执行的测试用例总数。
我们可以针对所有计划执行的测试用例进行衡量，可以细化到具体模块，用于对比各个模块的测试用例执行情况。
为了得到测试执行通过率数据，我们在测试执行时，需要在测试用例副本中记录下每个测试用例的执行结果，然后在当前版本执行完毕，或者定期（如每周）统计当前测试执行数据。通过原始数据的记录与统计，我们可以快速的得到当前版本或当前阶段的测试执行通过率。
4 缺陷解决率
缺陷解决率，指某个阶段已关闭缺陷占缺陷总数的比率。缺陷关闭操作包括以下两种情况：
正常关闭：缺陷已修复，且经过测试人员验证通过；
强制关闭：重复的缺陷；由于外部原因造成的缺陷；暂时不处理的缺陷；无效的缺陷。这类缺陷经过确认后，可以强制关闭。
计算公式：已关闭的缺陷/缺陷总数
在项目过程中，在开始时缺陷解决率上升很缓慢，随着测试工作的开展，缺陷解决率逐步上升，在版本发布前，缺陷解决率将趋于100%，如图二所示。一般来说，在每个版本对外发布时，缺陷解决率都应该达到100%。也就是说，除了已修复的缺陷需要进行验证外，其他需要强制关闭的缺陷必须经过确认，且有对应的应对措施。可以将缺陷解决率作为测试结束和版本发布的一个标准。如果有部分缺陷仍处于打开或已处理状态，那么原则上来说，该版本是不允许发布的。
缺陷关闭数据，可以通过缺陷跟踪工具定期（如每周）收集当前系统的缺陷数、已关闭缺陷数，通过这两个数据，即可绘制出整个项目过程或某个阶段的缺陷解决率曲线。
当然了，测试度量指标不仅仅只包括上述四个，在实际工作中，还会用到如：验证不通过率、缺陷密度等指标。收集这些数据目的是为了能对测试过程进行量化管理。但是，简单收集度量数据不是目的，通过对数据的分析、预防问题、对问题采取纠正措施，减少风险才是目的。
1 测试覆盖率
测试覆盖率是指测试用例对需求的覆盖情况。
计算公式：已设计测试用例的需求数/需求总数。
测试覆盖率从纬度上说包括广度覆盖和深度覆盖；从内容上说包括用户场景覆盖、功能覆盖、功能组合覆盖、系统场景覆盖。
首先说广度，是否需求规格说明书中的每个需求项都在测试用例中得到设计。其次说深度，通俗的说，是不使我们的测试设计流于表面，是否能够透过客户需求文档，挖掘出可能存在问题的地方。例如：重复点击某个按钮10次，或者依次执行新增、删除、新增同一数据的记录、再次删除该记录操作。在笔者的实际工作中碰到过这么一个例子，一个使用PL/SQL编写的系统，在某个查询界面，重复点击《查询》按钮6次后，系统就会出现查询功能失效的问题。经调试，开发人员发现是由于gdi资源未完全释放的缘故。
在设计测试用例时，我们很少单独设计广度或深度方面的测试用例，而一般是结合在一起设计。为了从广度和深度上覆盖测试用例，我们需要考虑设计各种测试用例，如：用户场景（识别最常用的20%的操作）、功能点、功能组合、系统场景、性能、语句、分支等。在执行时，需要根据测试时间的充裕程度按照一定的顺序执行。通常是先执行用户场景的测试用例，然后再执行具体功能点、功能组合的测试。
测试覆盖率数据的收集，我们可以通过需求跟踪矩阵RTM来实现。在需求跟踪矩阵，测试人员填写的“系统测试用例”列的数据。测试人员通过计算RTM列出的需求数量，和已设计测试用例的需求数量，可以快速的计算出测试覆盖率。通过RTM，测试人员，包括项目组成员都可以很清楚的、快速的知道当前这个项目测试的测试覆盖情况。
注：本RTM例子中，笔者将“概要设计”、“详细设计”、“编码”等列隐藏，只显示与测试覆盖率计算有关的内容。
2测试执行率
执行率，顾名思义，就是指实际执行过程中确定已经执行的测试用例比率。
计算公式：已执行的测试用例数/设计的总测试用例数。
读者肯定觉得很奇怪了，我们设计的测试用例肯定都是要执行的，即使是按模块来执行测试，那该模块的测试执行率肯定是100%，为什么还要设置这个指标？
其实不然。在实际测试过程中，经常有如下这种情况发生。一种情况是，因为系统采用迭代方式开发，每次Build时都有不同的重点，包含不同的内容；第二种情况是，由于测试资源的有限，不可能每次将所有设计的测试内容都全部测试完毕。由于这两种情况的存在，所以在每次执行测试时，我们会按照不同的测试重点和测试内容来安排测试活动，所以就存在了“测试执行率”这个指标。
通常，我们的测试目标是确保100%的测试用例都得到执行，即执行率为100%。但是，如前面所提到的，实际中可能存在非100%的执行率。如果不能达到100%的测试执行率，那么我们需要根据不同的情况制定不同的测试执行率标准——主要考虑风险、重要性、可接受的测试执行率。在考虑可接受的测试执行率时，就涉及到了测试用例执行顺序的问题。
在设计测试用例时，我们需要从广度和深度上尽可能的覆盖需求，所以我们就需要设计各种测试用例，如正常的测试用例、异常的测试用例、界面的测试用例等。但是在执行时，测试人员需要根据项目进度和测试时间的充裕程度，参考测试执行率标准，将测试用例按照一定的顺序执行。通常是先执行用户场景对应的测试用例，然后再执行具体功能点、功能组合的测试，完成这些测试后，再进行其它测试，如系统场景、性能、语句等测试。
例如，某项目共设计了280个测试用例。该项目某一阶段的测试共分四个版本，其中有一个版本执行了134个测试用例，那么该版本的测试执行率为47.9%。
3测试执行通过率
介绍了执行结果定义后，我们来看测试执行通过率。测试执行通过率，指在实际执行的测试用例中，执行结果为“通过”的测试用例比率。
计算公式：执行结果为“通过”的测试用例数/实际执行的测试用例总数。
我们可以针对所有计划执行的测试用例进行衡量，可以细化到具体模块，用于对比各个模块的测试用例执行情况。
为了得到测试执行通过率数据，我们在测试执行时，需要在测试用例副本中记录下每个测试用例的执行结果，然后在当前版本执行完毕，或者定期（如每周）统计当前测试执行数据。通过原始数据的记录与统计，我们可以快速的得到当前版本或当前阶段的测试执行通过率。
4 缺陷解决率
缺陷解决率，指某个阶段已关闭缺陷占缺陷总数的比率。缺陷关闭操作包括以下两种情况：
正常关闭：缺陷已修复，且经过测试人员验证通过；
强制关闭：重复的缺陷；由于外部原因造成的缺陷；暂时不处理的缺陷；无效的缺陷。这类缺陷经过确认后，可以强制关闭。
计算公式：已关闭的缺陷/缺陷总数
在项目过程中，在开始时缺陷解决率上升很缓慢，随着测试工作的开展，缺陷解决率逐步上升，在版本发布前，缺陷解决率将趋于100%，如图二所示。一般来说，在每个版本对外发布时，缺陷解决率都应该达到100%。也就是说，除了已修复的缺陷需要进行验证外，其他需要强制关闭的缺陷必须经过确认，且有对应的应对措施。可以将缺陷解决率作为测试结束和版本发布的一个标准。如果有部分缺陷仍处于打开或已处理状态，那么原则上来说，该版本是不允许发布的。
缺陷关闭数据，可以通过缺陷跟踪工具定期（如每周）收集当前系统的缺陷数、已关闭缺陷数，通过这两个数据，即可绘制出整个项目过程或某个阶段的缺陷解决率曲线。
当然了，测试度量指标不仅仅只包括上述四个，在实际工作中，还会用到如：验证不通过率、缺陷密度等指标。收集这些数据目的是为了能对测试过程进行量化管理。但是，简单收集度量数据不是目的，通过对数据的分析、预防问题、对问题采取纠正措施，减少风险才是目的。
