级别： 中级 Michael Kelly, 咨询顾问, www.MichaelDKelly.com
2009 年 6 月 11 日 通过在开发的整个周期内同步化团队的工作，并使一些费力的工作自动化，IBM® Rational® Quality Manager 能够帮助团队实现更好的合作。使用这款工具，团队可以通过提供及时可靠的评价，来更好的管理他们的项目。Rational Quality Manager 是在 Jazz 平台的基础之上构建的。本文检查了测试计划过程，并探究了 Rational Quality Manager 是怎样支持这个过程的。
通过在开发的整个周期内同步化团队的工作，并使一些费力的工作自动化，IBM® Rational® Quality Manager 能够帮助团队实现更好的合作。使用这款工具，团队可以通过提供及时可靠的评价，来更好的管理他们的项目。使用这款工具，团队可以通过提供及时可靠的评价，来更好的管理他们的项目。Rational Quality Manager 是在 Jazz 平台的基础之上构建的，Jazz 平台是一种协作性的，基于角色的，业务驱动的环境，它能够提供用于工作流程控制，追踪以及评价报告的工具。这款软件是一种协作性的，基于 Web 的质量管理方案，它能够提供综合性的测试计划，双方测试，并能与自动测试工具相集成。
测试计划就是制定测试战略并付之行动，通常是为一个特定的时期而制定的，例如一次重复期，冲刺期或者一个小型项目。本文检查了测试计划过程，并探究了 Rational Quality Manager 是怎样支持这个过程的。您可以按您自己的想法给 Rational Quality Manager 一些测试文档。它提供了尽可能简化这个过程的工具。在计划的每个阶段内，使用 Rational Quality Manager，而不是一个基本文件或者项目计划的目的，是在项目进行过程中，将它与您的报告和评价集成起来。
考虑测试计划
当您考虑您的测试计划时，您不应该从一个文件开始。这是一个过程。您应该做的第一件事情，是理解具体公司和项目的背景。理解背景也就是说，理解您将要与之打交道的事物的价值、过程、操作、思想、政策以及个性。而不仅仅是商业目标以及项目需求。而是关于公司和团队是怎样工作的，以及为什么要这样做。
一旦您对背景有所了解，那么就开始制定一项测试计划吧。Karen N. Johnson 最近在 Portland，Oregon 举行的 Pacific Northwest Software Quality Conference 会议上，发表了关于创建一个测试计划的谈话。在这次谈话中，她进行了生动的描述：“测试战略的有趣之处在于，如果您不去写出它，那么它就会自己写出来。” Karen 继续指出，如果您不去制定一项测试计划，那么它将会以人们会思考您将要进行的测试这种假设的形式而替换。随后您可能会发现，只有通过写下一些什么东西，您才能够节省大量的时间和精力。
这就是测试战略的全部：它是一种您告诉团队成员您想要测试什么以及不想测试什么，下一步您准备怎么做的方式。它是一种传达意图的高水平交流方式。Karen 谈话传达的另一个信息，是可以将测试战略当做测试商品账单或者工作总结。这是您告诉人们您计划想要交付什么的一种方式。对于测试战略，您要回答以下这些问题：
- 我们正在测试什么？
- 我们将要采用什么方法？
- 为了更有效的计划我还需要哪些信息？
只有在您知道您开始计划后想要交付什么以后。测试计划就是测试所要完成的特定任务。它是逻辑性的测试用例以及资源，并且包含了在测试时您需要注意的所有附件以及风险。在您计划时，您要估计，发现您不能完成您想要做的一切事情，商议范围，确定交付日期并且分配工作。
当您在计划时，问一些如下的问题：
- 我们将会怎样执行我们的测试？
- 我们将会在什么地方执行它们？
- 我们将会在什么时候开始执行它们？
- 我们将会怎样管理工作中发现的问题？
- 以及等等诸如此类问题。
提出这些问题的目的，是概括并总结某个特定时期内的测试效果细节。一般更加有可能的情况是，如果您正在记录一个测试计划（它并不仅仅是为管理和处理的过程），那么您就能够使用它来帮助指导测试效果。这意味着您想要信息竟可能的正确。
接下来就是您可以处理测试计划的一些问题：
- 前期准备
- 人员配备
- 测试范围
- 所有的测试需求（技术上或者其他方面的）
- 测试环境
- 进入标准
- 退出标准
- 职责分配
- 设施批准
- 任务计划
- 日程安排
- 记录与其他的团队成员之间的协调和合作
- 可能会影响测试的风险和问题
- 测试项目的具体可传递性
通常在您计划时，项目会在您完成计划之前就已经开始执行了。这就迫使您同时进行计划和执行。当您使用 Rational Quality Manager 这样的工具时，您可以追踪进展，并记得解决计划过程中出现的一些问题 。
当您在进行计划时，您应该拥有以下：
- 关于背景的信息
- 关于需要解决难题（或者项目）的信息
- 关于测试的打算
- 关于测试覆盖面的打算
- 关于项目风险的打算
- 关于具体执行方案的打算
- 试着共享意图的文件或者产品，这在挑战假设和理解方面十分有用。
- 可能需要移到进程前面的文件或者产品（取决于背景）
Rational Quality Manager 中的测试规划
本段将会探讨您可以怎样使用 Rational Quality Manager，来支持您的计划过程。Rational Quality Manager 拥有被称为测试计划的对象，为测试规划提供了可定制的模板，并提供工具和可视性到您的进程中。下面有一系列您可以使用 Rational Quality Manager 的特性的方法。
在开发进程内进行规划
您可以使用 Rational Quality Manager 中的一系列特性，将其集成到您的开发环境中。Rational Quality Manager 会使用角色的概念，工作流程以及产品包含中的工具。我们的目标不是让您以一种“Rational 的方式”来做事，而是向您提供一些不用改造就可以直接使用的工具。通过这种方式，您可以学到它的一些功能，这样您就会发现什么是可能的，并得到业内其他人士正在做的事情的信息。
从计划的角度来看，这项任务很重要，因为它允许您去做很多事情。首先，您可以在工具中创建一个测试计划概述。它可以包含检查器，产品状态，信号以及等等。在图 1 中，您可以看到一个具体的例子，是关于怎样在包含的默认流程中这一切是怎样执行的。测试计划的状态现在被设置成 Draft，而且您可以将测试计划转化为 Ready for Review 状态。当您创建 Roles 时，您可以定义由谁来在 Ready for Review 状态下检查测试计划。
图 1. 在 Rational Quality Manager 中将一个测试计划转化为 Ready for Review 状态
除了为检查创建简单的工作流程，您还可以通过创建工作项，来向其他人分配测试计划的任务。如图 2 所示。
图 2. 在 Rational Quality Manger 中分配工作项
然后这些项目就会自动显示在被分配任务人员的“要完成之事”的列表之中。每一个项目都会有其自己的状态以及可能的准许进程，如图 3 所示。对于该工作项，状态是新的，而且您可以因为准许，检查或者证实来提交它。
图 3. 准许 Rational Quality Manager 中的工作项
在任务的另一端，如果您不需要准许或者检查，那么您就可以删除它，或者直接简单的不去使用它。您可以根据需要创建或者删除角色，映射工作流程的各个方面的角色，更改工作流程。您可以控制进程，并使其能够支持您的计划进程。
除了角色，工作流程以及检查，在测试计划中还有进入和退出标准，它能使您的开发过程变得可见。许多团队使用进入标准来指定什么时候可以开始进行测试，使用退出标准来指定什么时候工作算已经完成。这些标准可以为严格的审视把关，或者作为产品什么时候为严格的测试做好了准备，或者什么时候测试算完成的启发式指示符。但是如果您使用它们的话，它们可能会十分的棘手，因为您可以在一个中心的位置处追踪它们，并使用自动生成的报告来报告它们。图 4 中显示的就是一个追踪进入标准的范例。
图 4. Rational Quality Manager 测试计划的进入标准范例
注意就算是对标准项，您也可以创建工作项。在前一个例子中，您也许为需要创建的三种测试环境配置创建了工作项。那么理论上您就可以更紧密的追踪这些活动的状态了。
不管测试计划的各个部分，您可以为 Rational Quality Manager 的计划追踪个人项目（如果您愿意这么做的话）。使用这种工具的优势，就像一个 Microsoft® Project 计划那样，将您和您的团队维持在剩余工作可以完成的工具处。它同样还集成了您的项目追踪和报告功能。
规划覆盖范围
Rational Quality Manager 中追踪和报告测试进程的一个关键工具，就是测试计划。Rational Quality Manger 拥有一些需求特性，这些特性能够帮助您去管理需求覆盖范围。在测试计划中，有一个管理某个测试计划所有需求的 Requirements 部分（如图 5 所示）。如果您想要追踪来自 Rational Quality Manager 的需求，那么您完全有能力这样做。如果您想要从其他工具中导入它们，您也拥有这个能力。您还可以选择，如果您只想创建并追踪一些通用的测试需求的话，也是可能的。
图 5. Rational Quality Manager 中测试计划的 Requirements
许多项目拥有大量的功能性需求覆盖范围（如果应用让您做 X，那么您就不该做 Y，等等），但是他们只对辅助功能性需求拥有需求。这并不意味着您不去测试它们：您需要这样做。但是，追踪测试的状态和覆盖范围通常会十分困难。如果您创建自己的需求，那么您可以为性能，安全性，实用性以及其他易忽略的方面添加需求。然后您可以将测试用例与这些需求联系起来，以追踪覆盖范围以及测试计划层次的状态。
在 Rational Quality Manager 中，您可以在测试计划中的 Quality Objectives 部分中清晰的定义您的质量目标，如图 6 所示。该段以表格的格式，列出了您的质量目标。您可以自由的去编辑 Quality，Objectives Description，Current Value，以及 Comment 区域（没有显示出来），允许您去指定您想要实现的所有目标。
图 6. 测试计划中质量目标的范例
一些可能的目标包含了以下领域的方法：
- 代码复杂性
- 单元测试成功
- 代码覆盖范围
- 需求覆盖范围
- 测试用例完成情况（完成百分率，通过百分率，等等）。
- 负载，性能或者评价性
- 开放的话题或者缺陷的严重情况，范围或者状态
- 缺陷出现率或者测试速度
- 测试用例或者需求优先级或者严重性
- 标准适应性（section 508，W3C，以及等等）
- 文献或者证据支持
您所选择的质量标准，很大程度上取决于您想对项目所要做的，以及您在哪种开发背景下工作。不管您选择了什么，Quality Objectives 部分都会向您提供一个很棒的快照，显示在一种质量视角下项目在什么地方。
Rational Quality Manager 中一个重要的特性，便是测试计划中的 Test Environments 计划部分。当您首次打开该部分时，它会催促您去定义需要涉及到的平台需求。如下面的图 7 所示，您所需要做的，就是定义您需要涉及到的平台构件的类型，以及您需要测试的版本或者属性。您只需创建需要测试的一个简单列表。
图 7. 定义测试计划中的平台覆盖范围
从这里开始，您可以继续去定义基于不同范围模型的覆盖面。如果您切换至 Test Environment 项时（如图 8 所示），您可以看到一副不同的景象，它最终会包含您将会碰到的每一个环境。
图 8. 生成之前的 Test Environments
在您保存测试计划之后，如果您点击 Generate New Test Environments 图标的话，您将会启动一个向导，该向导将会带您去生成一个初始的覆盖范围列表 。该向导的第一步，如图 9 所示，将会定义您想要处理的元素，以及您想要使用的生成方法。
图 9. 生成环境的第一步
这里提供了一系列的覆盖范围方法，包括单向的，双向的以及三向的交流，还有所有的排列。您在这里所做的选择，决定了您将会碰到什么样的环境。很少有 团队拥有测试所有排列的资源，所以问题是您和您的团队愿意接受什么层次的风险。如果需要的话，您可以在未来改善您的生成过程：更改环境元素的高级属性，并添加明确包含（explicit inclusions）、排除（exclusions）以及加权（weightings）。
在您选择您所喜欢的涵盖方法之后，您可以点击 Next，您就得到了一次机会，在接受它们之前检查生成的环境。这种方式允许您，如果需要的话您可以做出更改。图 10 使用浏览器分类的双向的覆盖来显示生成的环境 。
图 10. 生成环境的第 2 步（浏览器分组的，双向的）
当您接受环境时，它们会添加到测试计划中的 Test Environments 列表中（如图 11 所示）。从这里开始，如果您不需要的话您就可以删除它们中的任何一个，或者如果需要添加一个新的配置时手动添加记录。如果需要的话，您还可以编辑任意一个特定的环境。
图 11. 载入测试计划中的 Test Environments
规划执行
计划过程中一个比较棘手的方面便是规划执行。您需要考虑以下的一些事情（有一些是您将会遇到的，有一些您不会遇到）：
- 测试人员的数量
- 应用每一个时期需要的层次，环境和配置，或者质量标准
- 您必须支持的测试初始资源的大小和范围
- 您认为必须执行测试的一段时间
- 您觉得您将会遇到多少问题或者需要解决多少问题的估计
- 您将会揭示并需要运行多少新型测试的估计
- 您估计您不需要运行多少次测试的估计
为了让事情变得更加困难，作为一个测试管理员，您并不需要完全凭空想去计划。您必须考虑对其他团队和管理员的依赖性。对于过去的项目，计划涉及到了一系列文件（计划文件，项目计划，估计传单以及等等）还要举行会议并进行检查。对于现在的项目，计划一般会更快，并涉及到了更少的人，但是它仍然需要考虑您知道些什么，以及您不知道什么。
使 Rational Quality Manager 测试计划更加显眼的是 Test Schedules，Test Estimation，以及 Test Team 部分。这三项以一种帮助您描述执行的画面的方式，集合了其他所有的 部分（Entry and Exit Criteria，Test and Quality Objectives，Requirements，以及 Test Cases）。
在 Rational Quality Manager 的管理界面内，您可以建立并管理不同的测试团队。您可以使用一对多分配模式来完成它，这意味着同一个人可以工作在多个团队（现实中很常见）。一旦您开始了创建，如果您选择了一个计划内的测试团队，那么您可以查看是哪个团队成员分配给了该项目（同样见于图 12）。这些团队成员通常能够去做任务分配，测试用例分配以及计划内的其他操作。
图 12. 测试计划内的 Test Team 分配
作为计划过程的一部分，您可以创建关于测试计划大小的高层次估计。您也可以提供运行每一个私人测试用例所需的具体时间或者精力的估计。这些估计帮助您去评估您的进展，它们会向一些报告提供输入 。
在测试项目的早期阶段，您可以提供高层次的完成测试计划活动所需时间的估计，以及运行所有测试所需的时间和精力的估计。这些测试通常都是基于您对项目需求的理解。图 13 显示了在测试计划中定义高层次估计的范例。在早期这种拉下式计划可以十分有用。
图 13. 测试计划内高水平的测试估计
在随后的计划中，您可以通过向每一个测试用例添加一个加权值，来提供一份详细的关于测试执行效果的估计。在 Rational Quality Manager 中，测试扩展记录继承了相关测试用例的加权值。例如，一个分配有 10 加权值的测试用例，其运行的时间可能是加权值为 5 测试用例的两倍。一般来说，所谓的加权值就是您的测试团队使用某个测试单元的数值。
有一些测试团队想以点来衡量权重，而另外一些人则以小时、分钟或者其他的一些测量手段来衡量。这些具体的范围信息可用作一些执行状态报告的输入。通过向每一个测试用例分配不同的权重，您可以运行精确的报告，同时考虑运行中的测试用例的绝对数量，以及运行每一个测试用例所需的时间。
在高水平的估计之后，您可以在测试计划的 Test Schedule 部分中，定义一个高水平的日程表（如图 14 所示）。对于每一个重大事件或者重复中，您可以创建高水平的日程表，该日程表列出了诸如版本、代码冻结、UI 冻结、beta 入口、beta 出口，以及其他的日期之类的信息。
图 14. 测试计划中的日程安排规划
规划自动化
从测试计划的角度出发，该角度时候考虑 Rational Quality Manager 可以怎样帮助您去计划使用自动化。您可以为性能和安全性测试之类的事情设置质量目标，并为您的自动化测试覆盖面定义环境。您还可以为您准备使用哪些工具，以及在什么地方使用它们做一些前置计划。
在您的测试计划中，所有的测试元素都会与 Rational Quality Manager 联系起来，您有机会去计划并管理您的自动化效果。首先，您可以向您的需求添加通用标签。这给您一些自动化使用方面的前置计划。例如，如果您正在检查一项需求，那么您可以将其贴上以下的标签：
- 关键字 regression 用于您想要建立一个自动化回归测试用例的需求
- 关键字 performance 用于您需要开发性能测试的需求，或者需要联系基于需求一些方面的性能测试
- 关键字 configuration 用于可能驱动自动化测试多环境的需求
- 关键字 SOA 用于您想要在 Web 服务界面层次上测试的需求
- 关键字 security 用于可能会使用 IBM® Rational® AppScan®（或者其他一些工具）来测试的需求
在计划那些自动化效果时，提供一些您可以报告的简单标签。
在此之后，您可以尝试进行特定自动化的脚本和测试。您还可以选择，为一些不同种类的您可能对项目进行自动化的类别分配测试用例。除了标签和追踪性，考虑一下向您的日程表和估计添加不同的自动化，性能，安全性测试以及 Web 服务测试任务。通过这种方式，您可以将它们与测试项目的其余部分完全的集成起来。
下一步
现在考虑一下您的测试计划过程，以及您用于支持它的工具。如果您使用并不止一个，您可以考虑将一些测试工具移动到诸如 IBM Rational Quality Manager 之类的工具之中。同样，考虑一下在您的团队中是怎样共享信息的。您是否在使用 SharePoint 文件夹的复杂集合，或者 e-mail？这也是您想要将此移动到更加自然分配信息的工具中的信号。使用 Rational Quality Manager 来开发一系列的计划，根据数据进行工作，并查看您是否可以考虑更早的进行报告。
接下来逻辑化的一步，便是使用您在执行项目时在测试计划中获取的信息。文章“使用 IBM Rational Quality Manager 实现测试分析和报表”是本文的后续文章。它对测试分析以及报告使用 Rational Quality Manager 方面进行了深入探讨。
参考资料 学习
获得产品和技术
讨论
关于作者  | | | Michael Kelly 目前是一名独立咨询师，为客户提供 IBM Rational 测试工具方面的定制培训。他从事软件测试方面的咨询、撰稿和演讲。他目前担任印第安纳波利斯质量保证协会的 Program Director，并且是软件测试协会的理事长。 |
对本文的评价
| 
