级别： 中级 Michael Kelly, 咨询顾问, www.MichaelDKelly.com
2009 年 2 月 23 日 本文深入地介绍了利用 IBM® Rational® Quality Manager (RQM) 进行测试分析和生成报表，并且涵盖了测试经理可能提出的常见问题。您还可以了解到如何使用 RQM 辅助您对测试工程进行定性和定量分析，并提供分析数据。
 |
作者的注释：
本文是基于运行在 Microsoft® Windows® XP Professional SP3 服务器上的 IBM ® Rational® Quality Manager Open Beta Version 1.0.0.20080919_1011 和带有 Mozilla FireFox 3.0.2 浏览器的 Microsoft Windows 64-bit Vista™ Business SP1 而写成的。另外，本文参考了 www.BookPool.com，版本是撰写本文时可用的。 |
|
IBM® Rational® Quality Manager 是为完整的软件开发生命周期提供集成的测试计划和测试资产的协作的，基于 Web 的质量管理软件。Rational Quality Manager 基于 Jazz™ 平台，并且可以被任何规模的测试团队使用。它支持各种各样的用户角色，例如，测试经理、测试架构师、测试领导、测试人员，和实验室经理，以及测试组织之外的角色。
本文深入地介绍了利用 IBM Rational Quality Manager 进行测试分析和报告，并且涵盖了测试经理可能提出的普遍问题。您还会了解到如何使用为了辅助您对测试工程进行定性定量分析而提供的数据。
报告的计划
就像使用任何工具一样，您从 Rational Quality Manager 中获得的信息仅仅与您输入的内容一样好。当您考虑您的公司、项目，以及您需要报告的信息时，还要考虑您需要如何安装并使用 Rational Quality Manager 来获得该信息。问自己以下这些问题：
- 我们当前的测试的创建速度是多少，以及在项目过程中曾经是多少？创建速度如何跨测试区域或者测试用例优先级？
- 我们当前的测试的执行速度是多少，以及在项目过程中曾经是多少？执行速度如何跨测试区域或者测试用例优先级突发？
- 我们有多少测试是专注于基本功能的（基本需求，主要功能，简单数据），而不是公共的用例（用户、场景、基本数据、状态，和错误覆盖率），而不是压力测试（强大的数据、状态、错误覆盖率、加载，以及限定的环境）？
- 我们有多少测试是专注于性能，而不是其他类型的质量标准（性能、安全性、可伸缩性、可测试性、可维护性，等等）？
- 我们找到了多少问题，他们的安全性是什么，我们在哪里找到的，以及我们如何找到它们？
Rational Quality Manager 不会回到所有这些问题，但它可以解决其中的许多问题，并且它可以提供一些回答其他问题所需的信息。
设立并管理您的需求
在许多公司，需求覆盖或需求可溯性是测试过程的大焦点。有时候，是要支持受管制行业中的应用程序开发需求。其他时候，是测定团队是否做了足够的测试的标准。不管您为什么对需求覆盖感兴趣，如果您希望 Rational Quality Manager 可以在此方面提供帮助，那么您就要设立您需要做的工作。
管理并追溯需求
如果在外部工具中管理您的需求，例如 IBM® Rational® RequisitePro®，那么您可以将该需求链接到测试计划中。如果您没有使用外部工具，那么您需要在测试计划中管理需求。不论什么情况，当您进入了需求之后，您可以将它们与测试用例相关联，从而将测试脚本一直追溯到您的需求。
当需求变更或删除时，Rational Quality Manager 中需求的状态被更新为显示最新的状态。包含变更或删除的需求的测试用例被标记了，以便您可以快速并且准确地调整测试计划和测试用例，从而响应需求变更。
评定安全性等级
当您有许多针对应用程序中甚至最小的功能的测试时，很难向项目团队说明您在获得什么类型的覆盖率。即使当谈论需求覆盖（一种可能的量度）时，知道哪些需求比其他的更重要也是有帮助的，这样您就可以适当地计划测试。较高的安全性需求可能保证更多的测试用例，或者被更多测试人员的回顾，或者更详细的测试文档。
了解需求的安全性可以让您回答特定的问题，举例来说：
- 相对于低安全性需求来说，我们涵盖的高安全性需求的百分比是多少？
- 相对于其他领域，我们针对那些需求所拥有的测试用例有多少？
- 我们在哪里找到缺陷？（在高安全性需求的测试用例中或其他地方？）
首先，您可能想要用一些时间来为需求定义安全性方案，然后视图确保您遵照该方案。这不仅在确保您专注于正确的事情上是有用的，而且还在您完成项目后考虑不断的改进时是有用的。图 1 LINK 显示了为需求设置安全性等级的实例。
使用标签
除了安全性，每个需求包含一个 Tags 字段。Tags 是可以帮助您管理测试的关键字。您可以使用它们来将需求、测试用例，以及缺陷按应用程序的不同区域，以及测试的不同类型分类。举例来说（不管用什么工具）：
-
应用程序的区域：核心平台、报告、客户端界面、内部工具、外部工具、语音，等等
-
质量标准：功能性、可用性、安全性、性能、兼容性、可测试性、可支持性，等等
利用 Rational Quality Manager，您可以用自己的关键字给需求设定标签。这可以让您能够生成报告，从而回答以下这样的问题：
- 多少测试用例是用于 报告（或另一个方面）？
- 多少需求规定了安全性测试（或者另一个质量标准）？
- 专注于功能性，安全性，性能上的需求百分比是多少？
这些向您展示了您在哪里用去了测试时间，以及您正在寻找什么类型的关注点。您可以参见图 1 中为需求定义标签的实例。
图 1. 在需求中使用 Severity 和 Tags 的实例
设立并管理测试用例
另一个您可以在其中做一些最先的工作，从而在后面获得很大好处的关键区域是在您的测试用例中。测试用例中有两个重要的区域可以帮助您管理您的测试：
-
测试用例的权重，它虑及了更多粒度的诚实的结果报告，因而提高了数据结果的价值
-
测试用例的范畴，像标签那样，让您能够为更详细的报告将测试用例拆分
指定测试用例的权重
当您创建测试案例时，您可以选择向测试用例分配权重。这背后的思想是并非所有的测试用例都是相等的 —— 一些比其他的更重要。IBM 建议使用 1 到 100 的范围。当您运行测试时，您可以使用权重来分配您的结果。如果测试“稍稍”通过（举例来说，一些部分没有完全工作，或者在某些配置下不工作，而在其他配置下工作），那么您可以通过使用权重滑尺来表达 70% 通过而 30% 失败。权重 1 是不可能的。参见图 2，定义测试用例权重的实例。
权重 概念是 Rational Quality Manager 中的重要特性。它超越了“通过”或“失败”限定词的范畴。运行一个测试用例或许可证（不是自动的）而说其 100% 通过是不寻常的。在过去，您没法选择说“很好，大部分 可以工作，但有一些问题”。现在，通过指定测试用例的权重，您就可以了。
分配测试用例范畴
就像对于需求的标签一样，测试用例的范畴对于切割测试数据以便决定到底发生了什么来说是无价的。您有三个默认的选择：Category、Function，和 Theme，并且您可以添加、删除，或编辑它们。在默认的安装中，这些下拉菜单可能是空的。然而，有很多空间可以向其中添加值（作为 Admin，或者简单地单击在测试计划和测试用例中的“Manage Test Case Categories”图标）。
就像对需求那样，您可以使用 范畴 和 功能 来指定 在哪里 测试（举例来说，报告、核心平台、语音、内部工具、外部工具，或管理）并且用 主题 来指定为什么测试（功能、性能、安全性、可测试性、可支持性，或可伸缩性，等等）。您可以按您希望的方式定义它们，但要考虑如何划分测试工作，以及您想要如何对结果进行报告。之后，您可以使用这些字段从应用程序的不同区域以及不同类型的测试来比较并对比覆盖率和结果。图 2 显示了使用测试用例范畴的实例。
图 2. 定义测试用例范畴、功能、主题，和权重
使用测试计划工具来追踪进度
报告测试进度有时候是测试结果的分析，有时候是对高层次的里程碑、状态门，或进入和退出标准。这是 Rational Quality Manager 的测试计划特性起作用的地方。不应该令人惊奇的是，追踪和报告测试进度的一个重要的工具之一是测试计划。Rational Quality Manager 中包含的默认的测试计划模板提供了帮助您了解测试项目在哪，以及帮助您与其他人交流测试项目的许多特性。
追踪需求
如早先详细的介绍，Rational Quality Manger 有许多帮助您管理需求覆盖率的需求特性。在测试计划中，有一个用于管理您将在已知的测试计划中涵盖的所有需求的 Requirements 部分（参见图 3）。这是有帮助的，因为即使您是在不同的工具中管理您的应用程序需求，并且您仅仅将它们导入 Rational Quality Manager，您都可以在您的计划中定义 您
自己的 测试需求。
图 3. 测试计划中的需求的实例
看到大的功能需求覆盖率是不寻常的（该应用程序应该做 X，但它不应该做 Y），但也没有对异常功能的需求。这不意味着我们不测试它们。我们要测。但是，根据状态和覆盖率总是很难追踪该测试在哪里。通过创建您自己的需求，您可以添加性能、安全性、可用性，及经常被忽略的其他领域的需求。您可以将测试用例与那些需求相联系，从而追踪覆盖率和状态。
追踪测试环境
如果您的应用程序有任意类型的配置测试（支持多种硬件平台、操作系统、浏览器、与其他厂商或程序的集成，或者另一个配置设置），那么就从容地在 Rational Quality Manager 中设立测试环境。在测试计划的 Test Environments 部分中（如图 4 所示），您可以指定您实际的测试环境，以及平台覆盖率。
图 4. 测试计划的测试环境部分中的平台覆盖率的实例
测试环境描述中显示在测试中要使用硬件和软件平台的组合。这通常不是详细的清单，因为它不是总能够覆盖所有内容。但当是时候运行测试时，如果您适当地设置了每样东西，那么看到哪些平台或配置您已经或还没测试就比较容易了。在 Rational Quality Manager 中，特别是使用 Rational Test Lab Manager 附件时，测试环境与实际的测试运行是相关联的。
追踪质量目标
如同您可能从以前的表述中了解到的，项目有时候会压倒性地专注于需求覆盖率，并且大部分需求（99% 或者更多）与功能相关。很遗憾，因为由于此焦点您将在测试中错过很多。IT 是一个痛苦的过程，将测试移动到其他领域。花很多时间测试功能（或者性能）是很重要的，但花很多时间测试其他质量标准也是重要的。
在 Rational Quality Manager 中，您可以明确地在测试计划的 Quality Objectives 部分中定义您的质量目标（图 5）。该部分用表格的形式列出了对于一次发布的质量目标。你可以自由地编辑 Quality Objectives Description、Current Value，和 Comment 字段（没有在此显示）来指定差不多任意目标。
图 5. 测试计划中的质量目标的实例
这些是量度目标的实例：
- 代码复杂性
- 单元测试成功
- 代码覆盖率
- 需求覆盖率
- 分区域测试用例完成（完成百分比、通过百分比）
- 加载、性能，或可伸缩性
- 开放问题和缺陷安全性、容量，或状态
- 缺陷到达率或测试速度
- 测试用例或需求优先级或安全性，或二者
- 遵循标准（Section 508，W3C）
- 文档或证据需求
还有许多许多。当然，您将要选择的质量标准大量地依赖于您试图用项目来实现什么，以及您将要工作的开发环境。不论您选择了什么，Quality Objectives 部分都将从质量管理的角度提供项目所处位置的快照。
追踪进入和退出标准
在 Quality Objectives 之后，您还可以指定进入和退出标准。在测试计划的那些部分中，您可以精化将要支持您的测试过程的标准，以及整个质量标准。您可以使用进入标准（如图 6 所示）来指定开始测试所需的条件，例如，必需的产品和特性质量的最小等级。
图 6. 测试计划中的进入标准的实例
退出标准（图 7）可以用于指定达到考虑要完成的特殊测试周期的条件。举例来说，您可以指定直到修复恶劣所有最严重的缺陷之后测试才是完成的。
图 7. 测试计划中的退出标准的实例
利用 viewlet 和报告进行分析
在移动过去的计划、目标，并且交流高层次的目标和进展时，您可能会疑惑如何看到 Rational Quality Manager 中的真实数据。那么，在此部分中，您将看到 Rational Quality Manager 中的许多报告和 viewlet。对于这些，您可以将它们看作 viewlets（那些您可以在仪表盘上创建来显示关于状态的实时更新的小窗口）和报告（找到目标的数据的可配置的报告）
这不是您可以回顾的完整数据清单，它甚至是不细致的。它只是您可以开始进行的一些分析中的一小部分。所有这些图表都是来自于软件中包含的与格式化的报告。除了提供的报告，您还可以使用 Rational Quality Manager 中的数据来创建或支持基于具体的项目需求和从其他测试管理工具中收集来的数据的定制报告。
追踪测试执行
Rational Quality Manager 默认包含对于测试计划执行的状态、趋势，和缺陷的报告。下面有许多可用的报告的实例，以及简要的描述。基于计划、所有者，和机器的执行状态报告都显示了带有被划分为六种彩色编码的分类的数据的图表。所有这些报告都使用相同的状态结果。
实时的执行状态报告
实时的执行状态 viewlet 是您在第一次登入 Rational Quality Manager 时可以找到的默认的 viewlet 之一。它是可配置的，但默认显示项目中 基于测试计划 的测试执行的状态。多个测试计划可以并排地显示。默认有许多状态可用，单击任意已知的计划或状态区段将给您显示出对于此选区的详细内容。Live Execution Status viewlet 的实例如图 8 所示。
图 8. Live Execution Status viewlet 的实例
依据测试人员的执行状态
此报告列出了依据测试人员，或者所有者的执行工作项的状态。您可以选择一个以上的计划，从而查看跨多个计划的根据所有者的执行工作项的状态。如同对于其他所有的报告一样，您可以单击图上的一个部分，从而查看与对于该所有者的特殊状态相关联的执行工作项。Execution Status per Tester 报告的实例如图 9 所示。
图 9. 依据测试人员的执行状态报告
如果您喜欢此报告，那么您是走运的，因为您可以依据测试人员、所有者、计划，或机器看到相同的信息。它给予您不同的方法来获取进行比较的数据。
执行趋势报告
执行趋势报告可以用于比较实际的测试执行进展和计划的进展。它将您做的和计划做的进行比较。它还显示了剩下多少工作，以及如果想赶上目标需要如何变更速度。该报告给您了一个很好的随着时间的速度的指示。图 10 显示了 Execution Trend 报告的实例。
图 10. Execution Trend 报告的实例
追踪需求覆盖率
可能不惊奇的是，您可以使用 Rational Quality Manager 来获得需求覆盖率的状态的报告。虽然观察其他的量度是很好的，但这仍旧是重要的。以下子部分说明了最有用的基本报告。
需求覆盖率报告
该报告是另一个在仪表盘上提供的默认 viewlet，它显示了您整个的需求覆盖率。饼图分为两个部分：覆盖的和没覆盖的。单击每个部分来获得需求及测试用例的详细信息。图 12 显示了 Requirement Coverage Status 报告的实例。
图 11. Requirements Coverage Status viewlet 的实例
单击 Covered 生成了图 12 中的表格，显示了每个需求及其相关的测试用例。
图 12. Plan Requirements Coverage 细节视图
单击 Not Covered 将生成如图 13 所示的表格，显示每个没覆盖的需求，以及谁拥有该需求。（也许它的基本原理是，通过了解所有者是谁，您可以温和地让此人书写测试用例。）您还可以钻到该信息中，通过测试计划突破覆盖率。
图 13. 没有覆盖到的需求的详细回顾的表格
Requirements Status by Execution 报告
Requirements Status by Execution 报告显示了测试计划中每个需求的工作项的状态。您可以利用 Count 或 Weight 来观察该报告。图 14 显示了实例。
图 14. Requirements Status by Execution 报告的实例
追踪测试用例
如果您是一个喜欢看测试想法来了解测试人员所专注的内容的测试经理，那么您将会喜欢上如此容易地在 Rational Quality Manager 中获得关于测试用例的细节。您不会获得一大列的测试用例。相反，您可以获得利用一些分类和前面提到的标签进行分类和过滤的列表。您可以使用默认的测试用例报告来根据计划、配置，或团队列出测试用例。
Test Cases by Plan 报告
Test Cases by Plan 报告查询作为测试计划一部分的所有测试用例。你可以点击测试用例的名称来查看测试用例。参见图 15 中的实例。
图 15. Test Case by Plan 报告的实例
有一个非常类似的 Test Cases by Team 报告，它与上面的报告看起来及用起来是一样的。该报告跨团队，以及分配给那些团队中的人的测试用例进行查看。
Test Cases by Configuration 报告
类似于 Test Case by Plan 报告，但用于那些进行配置测试的人，Test Cases by Configuration 报告根据目标配置对测试用例分类。图 16 向您显示了其有效性的思想。
图 16. Test Case by Configuration 报告的实例
接下来的步骤
本文向您概述了在 Rational Quality Manager 中进行测试分析及报告的一些选择。下一个步骤是在您的项目中尝试。如同您处理数据一样，看看是否您能够在开头考虑可以做出的变更，从而使得之后的报告更容易。同样，思考你没有从默认的报告中获得的其他类型的信息。下一个步骤是考虑利用 Create Report 特性创建您自己的报告。
参考资料 学习
获得产品和技术
讨论
关于作者 | | | Michael Kelly 目前是一名独立咨询师，为客户提供 IBM Rational 测试工具方面的定制培训。他从事软件测试方面的咨询、撰稿和演讲。他目前担任印第安纳波利斯质量保证协会的 Program Director，并且是软件测试协会的理事长。 |
对本文的评价
| 
