来自于Rational Edge：尽管Rational统一过程，或RUP，特别强调测试，但是它并没有给测试人员提供用来建立测试过程所必需的所有工具。实际上，测试人员经常在RUP中实施他们自己的实用工具和方法，来替代RUP中描述的测试方法论。本文描述了一个广为人知的测试方法－TMap与RUP2002版的实施。
然而，与RUP一起实施TMap在许多方面提供极大的增值： 我们希望这种方法为所有碰到此挑战的测试人员提供一种实用的解决方案。本文并不强调迭代化系统开发项目给测试人员提出的挑战。关于本主题的更多信息，读者应该查阅TMap的iCBD版本。1 由于本文重点强调一种明确的变化，所以假定读者对TMap和RUP知识有一定的水平。 测试作为一个RUP的最佳实践 在2002年以前，RUP的重点是在传统的计划、规格说明和测试的执行上，并且很大的一个重点是在测试自动化上。在2002版中，对测试流程进行了相当大的变化。2002版转向了基于探索性测试的方法。认识系统，以及涉及和执行测试现在是并行活动。在此之后隐藏的基本原理是，由于系统文档经常改变，不应当将重点放在设计和编写基于文档的测试用例这些耗时的任务上。理想情况下，设计和执行测试应当发生在软件被交付的时候，并且系统文档不应当被唯一地用作测试依据。2 RUP测试方法是基于以下原理：3
RUP确定了四级测试：单元测试、集成测试、系统测试和验收测试。这些测试级别可以是并列的，这取决于主测试计划（在项目级）和迭代测试计划（在迭代级）。 主测试计划和迭代测试计划 单元测试（UT） RUP中的单元测试是实现人员的明确任务，在对于新的或变更单元的每个迭代中，都是由实现人员来执行实现测试组件和子系统，以及执行单元测试这些活动。这就使得测试成为与此角色相关联活动的主要部分。 尽管RUP包含了许多关于单元测试的指导方针，但是并没有命名一个项目特定指导方针需要在其中被固化的工件。这就和例如设计和用例建模的指南形成了对比。理论上，单元测试的这些指南应当被包括在编程指南中，因为编程指南是记录实现人员角色的其它指南的地方。指南的开发和执行是过程工程师们的共有责任，并且应当是与主测试计划是一致的。 单元测试配置有一个或多个工具。对于单元测试，IBM Rational软件提供了以下工具：
其它可能的工具包括像JUnit这样的免费软件，其用于在Java环境中大范围的测试（软件）单元的功能。工具的选择取决于要测试的需求。例如，如果性能不是一部分需求，那么对于性能测试就不需要工具。 集成测试（IT） RUP规定，集成测试由测试角色的人员来执行。取决于集成活动的数量，这些测试可以合并在集成员角色下面。实际上，这些角色为了效率最大化，可以由相同的人员来承担。这意味着，集成人员也可以执行作为其活动主要内容的集成测试。 关于指南和工具，应用于集成测试与单元测试是一样的。主要的差别是，集成测试的指南不会自动成为编程指南的一部分，但会是测试指南的一部分，或遵循集成构建计划。测试经理需要与其他过程工程师调整这些。 系统测试（ST） RUP确定了系统测试的测试流程。如图1所描述的，缺省工作流、活动、工件、角色等等，都在此流程中进行了详细描述。 
图1：缺省测试工作流 图1显示了用于RUP中的一次迭代的缺省测试工作流。此工作流可以根据不同情况而有所不同。此工作流包含了许多步骤，说明了工作流详细内容。对于测试工作流，这些步骤是定义任务评价，检验测试方法，确认构建稳定性，测试和评估，完成可接受任务和改善测试资产。 每个工作流明细包括许多活动，活动的输出是工件（产品）。相同的活动可以出现在多个明细中－－例如活动“确定测试思想”，出现在定义任务评价、测试和评估、完成可接受任务和改善测试资产。注意，工作流明细的语境会影响活动执行的解释。 对于每个项目，实现流程的方式－－意味着被选择的活动子集和工件，相关的角色，以及谁来实现这些角色－－在开发用例和软件开发计划中规定。这也可以应用于测试流程。履行测试设计员角色职责的人员决定测试指南。测试经理负责指南集中的系统测试的执行，并管理不同的测试角色（谁，做什么，以及什么时间）。其他角色包括测试分析师和测试人员。在每个角色中，都要描述职责、相关技能和可能的任务（包括可能的任务合并）。考虑到提前展开的任务的数量，每个项目的所有角色需要进行充分地分配，因此对于测试团队的成员，就可能共享角色和/或参与到多个项目中。 对于系统测试有多个可用的工具。IBM Rational软件提供：
要推动团队沟通、协作和合作，IBM Rational还提供额外的解决方案：
验收测试（AT） 验收测试被放在移交阶段，并且是部署流程的一个主要部分。RUP定义验收测试不够充分，只是作为系统测试用例子集的重新运行。测试人员需要在一个类似产品的环境中执行这些用例。在验收测试期间，考虑工件产品的产品验收计划是很重要的。项目经理在项目的先启阶段开始编写产品验收计划。验收测试的相关主题是验收标准、接受的工件和评价方法。 RUP没有提供用于在此阶段部署的工具的许多指导。取决于验收测试的实施，可以部署与在系统测试中所使用的相同的工具。 复审
角色 将TMap适配到RUP 主测试计划 阶段划分 
图2：一个活动简短概述的TMap生命周期 让我们按照每个迭代一步步走一下工作流程。对于每个TMap阶段，活动将会被声明并连接到最合适的RUP工作流上。我们也将描述另外的TMap，或在某些情况下的RUP测试活动。大多数的RUP和TMap的相应活动是通过TMap进行详细地描述。此外，附录C包括了TMap和RUP工件之间的一个对比。 图3显示了TMap阶段和RUP工作流之间的一般关系。 
图3：TMap生命周期和RUP工作流之间的全局关系 计划和控制 计划和控制阶段可以被分为用于计划的活动和用于控制的活动。 RUP步骤，定义评价任务“显示了许多与TMap的计划和控制阶段的计划活动相似处。这些相似处在表1中很明显。对于那些不熟悉定义评价任务的人”步骤，显示在图4中。 表1：RUP步骤，定义评价任务，显示了许多与TMap的计划和控制阶段的计划活动相似处。 
对于不熟悉RUP步骤定义评价任务的读者，在图4中描述。 
图4：RUP步骤定义评价任务 定义评价任务工作流确定了迭代的测试目标或测试任务，以及基于主测试计划的测试范围。一个人需要确定这是否是有限功能的第一个原型，这要求一些全局测试，或是否它引用到部署之前的最新迭代。此外，一个人需要确定是否整个系统要求高质量。测试进行了计划，方法得到了确定，资源被明确要求，并且进度监控也到位了。所有这些的结果是迭代的一个测试计划，这就是迭代测试计划。 RUP的定义测试方法工作流包含许多步骤，包括称为确定测试的必要深度的步骤。尽管TMap中的测试策略在某种方式上可以与活动定义测试方法和定义评估和可追踪性需求进行对应，但是TMap中的详细程度要更高一些。而RUP在覆盖方面解释了定义评估和可追踪性需求，覆盖事实上主要是特定于测试技术的使用，并且因为RUP没有在这个问题上细化，此工作如何进行还是不清楚。直到正式的验收测试完成了，测试策略就与不同的涉众协调好了。除此之外，这个工作流提供了如何解释测试结果的全局说明。 如果要使用TMap测试策略，你必须要小心确保测试是在迭代或测试任务的范围中进行。换句话说，不要定义一个适合于最终产品的测试策略，如果第一次迭代只是一个原型的话。 另外一个差异是，TMap测试策略基于风险、质量特性、系统部分和必需的测试技术。RUP也是由风险开始的，但是使用测试类型，而TMap使用质量特性和系统部分。RUP定义的测试类型是：
按照TMap，测试策略的一个重要部分是与成本估算放在一起的。尽管在RUP中，所需要的人时是一个测试计划模版的一部分，但是不清楚估算人时对应于哪些活动。 TMap也详细地定义了所需要的组织和基本结构。RUP在后面的一个阶段，验证测试方法，定义了基本结构。需要的组织是主测试计划和迭代测试计划模版的一部分，但是相应的活动不清楚。 在TMap和RUP都有的控制活动主要是在步骤完成可接受任务。这种映射显示在表2中。 表2：在TMap和RUP中的控制活动 
在一个迭代期间要执行多个测试周期。这个步骤主要集中在每个测试周期。完成可接受任务步骤的目的，如图5所示，是持续地控制不同测试的优先级，并且确保只执行那些可以对测试任务增加最大价值的测试。这包括监控（解决）严重缺陷，监控后续构建可能的回归，以及向所有相关团体报告应用软件的质量。如果有必要，会调整测试任务。 
图5：RUP步骤完成可接受任务 RUP规定，优先级主要是控制过程的一部分，但是在TMap中，优先级在早期阶段就按照测试策略明确化了，然后作为测试计划的维护来进行。 剩下的活动，控制测试，在RUP中被放在改善测试资产下面，其相应于维护测试件和测试环境。 准备 TMap的准备阶段在RUP中不明显，但是可以合并到评价任务和验证测试方法中，这主要是因为在这两种情况中，这些步骤相比较实际的测试，更关心准备情况。 表3：TMap准备接口可以合并到RUP的评价任务和验证测试方法中。 
对于不熟悉RUP步骤验证测试方法的读者，其描述见图6。 
图6：RUP步骤，验证测试方法 如表3所示，在准备阶段的第一个活动，易测性复审，在RUP工作流中没有可对比的活动，除非将其视作常规复审活动的部分。推荐你执行易测性复审。并不关心这是否要被认为是一个单独的活动或是一个复审的一部分－－最后，易测性的复审实际上会得到有关测试质量的有价值信息。万一质量不足，也可以进行及时地调整。标准的TMap易测性复审检查单需要在用UML处理时应用。在这件事情上，可以应用测试用例。4 表3中的活动2、3和4进行技术的改进和采纳，并确定基础结构，在RUP中，这在评价任务和验证测试方法中都可以发现。在RUP工作流中的最后一个步骤，与其它步骤是并行一起发生的，并关注在提供测试子集上。当需要时，这种方法和测试技术可以很好融合。除了这种测试的“测试”之外，其它的关注点是增加测试环境的需求和应用软件的易测性，这些都是在与开发团队紧密的合作中发生的。在测试自动化或一个新方法（对于组织）的情况下，这个步骤要求更多的工作。这种工作在以后的迭代中会迅速地减少。 将易测性作为开发团队的一个议程项目并不是TMap中要明确的，但是这将被证明是一个非常有价值的活动。例如，讨论的目标需要被确定下来，并且驱动程序要被开发团队开发出来。然后这个活动需要被添加到谈到的TMap活动中。 注意到在TMap阶段中没有很明确的测试活动，这是很重要的，然而，这在RUP工作流中是一种情况。取决于必要性，一个人可以选择维护这个或不维护。 规格说明 TMap规格说明阶段可以被映射到RUP中的测试和评价，如表4所示。这个RUP步骤合并了重要的TMap阶段－规格说明和执行。 表4：TMap规格说明阶段可以被映射到RUP中的测试和评价 
对于不熟悉RUP步骤“测试和评价”的读者，可以在图7中看到描述。 
图7：RUP步骤“测试和评价” RUP强调，规格说明和测试用例的执行可以是并行的活动，让我们讨论一下如何从一个TMap的观点来处理这个问题。 在RUP的“测试和评价”阶段，一个测试分析师确定在像“确定测试思想”和“定义测试细节”这样的活动中的一个逻辑级别上的测试用例。然后测试人员将这些转换成物理的测试用例和测试脚本：分别是，“实施测试”和“实施测试集”。 RUP按照一种有别于TMap的方式来定义一个测试脚本。按照RUP，一个测试脚本是一个单个测试用例的实现；TMap认为一个测试脚本是按照一个有效的方式执行的许多动作和检查点。在RUP中，这被称作是一个测试集，并且可以与测试自动化关联起来。本文参考的是TMap术语，除非RUP的术语表示更清晰。RUP测试可以是手工和自动化测试。 应当注意，在确定测试用例中，RUP不强调测试规格技术的使用或必需的测试基础。不幸地是，这会降低系统文档的重要性，尽管RUP不规定适合于测试基础的不同系统文档。例子是用例、用例模型、业务规则、类、类图、序列图、数据模型和补充规约。不同的TMap需求规格技术非常适合于建立基于RUP系统文档的测试用例（也可以参见下面的“技术”一节）。 活动确定测试思想，可以在多个RUP步骤中发现，很少可以映射到TMap内。取决于测试思想的详细程度，这种映射可以在准备阶段中的测试技术选择中或在规格说明阶段的测试用例规格说明中发现。当需要时，可以创建并维护一个测试思想的列表。 在此阶段中的第五个活动，说明测试对象和基础结构的复审，可以被映射到RUP的确认构建稳定性中。有关于这个活动的说明可以在下一节有关执行的部分中找到。 在TMap中，“建立基础结构”是规格说明的一部分。RUP将这部分内容方式了支持活动－支持开发中。 执行 TMap活动提到以下是执行阶段的部分，并被映射凹相应的RUP活动，如表5所示。 表5：TMap执行阶段映射到RUP 
对于不熟悉RUP步骤－确认构建稳定性的读者，在图8中进行了描述。 
图8：RUP步骤－确认构建稳定性 作为执行活动的第一个步骤，复审测试对象或基本结构是RUP步骤－确认构建稳定性的一部分。注意RUP，这个步骤是在定义评价任务之后立即开始的，这与TMap计划阶段多少有些同义。在确认构建稳定性中，已提交的软件版本（构建）被测试稳定性；换句话说，这足以开始进行测试执行吗？因此，按照TMap，这个步骤不比规格说明和预测试执行内容要少。每个迭代都可以提交多个构建，尽管通常不是每个构建都要进行此步骤。此测试可以被（部分地）自动化。 当我们严格遵循RUP时，这意味着我们在软件交付前抛弃了测试用例的规格说明，因为这发生在软件交付之后。这样的缺点是，不会鼓励先于交付而完成测试准备，并且作为将不必要的测试活动放在项目的关键路径上的结果。可能的优点是，软件和文档被同步的可能性更高，测试用例不会基于过期的文档来设计，以及设计和执行同时进行在人时方面会更有效率。5 在TMap中执行预先测试的小步骤比在RUP中强调要详细得多。在许多情况下，延迟测试用例规格说明的优点直到第一次构建交付之后才会大于缺点。对于此，更灵活的解释和下一步骤，测试和评价，可以很容易地消除这些对象。如果还没有交付任何构建，确认构建稳定性就不能执行。然而，下一步骤可以开始。在这个步骤中，测试用例只能指定，但还没有执行。图9显示了这会如何发生。 
图9：可选择的工作流顺序 TMap执行阶段的剩余活动可以放在测试和评价中，和规格说明的大多少活动一样。按照这种方式，测试人员执行他们的测试用例，并在“执行测试集”中分析有关预期结果的缺陷。 完成 TMap完成阶段的活动及其与RUP的对照如表6所示。 表6：TMap完成阶段及其与RUP的对照 
前三个完成活动可以被很好地映射到RUP的完成可接受任务中，这在图10进行了描述。然而，在TMap中，与RUP的改善测试资产有一些重迭。 
图10：RUP步骤－改善测试资产 “完成可接受任务”产生了工件－测试评价总结，其包含测试对象和测试过程的一个评价。“改善测试资产”用一般方式描述了测试件的维护和改善。这包括测试的维护，测试环境的管理，以及自动化测试的维护。对这种执行测试的方式推荐的调整也可以从这个步骤进行，这取决于测试评价总结。除了第四个TMap活动，保存测试件，这个RUP步骤也包含测试过程的评价。在TMap中的另外一个步骤正在解放测试团队。在RUP方法的正式工作中，这常常是不必要的。 组织
这些角色覆盖了测试流程的所有活动。 前三个角色主要对应于TMap测试经理和测试员的两个描述。RUP的测试分析师角色部分包括TMap测试经理的任务，部分包括TMap测试员的任务，并且特别确定了那些测试需要被执行，这些测试的（逻辑）设计，以及测试执行的最终结果的评价。 RUP的测试设计师角色定义并实现了测试方法，包括技术、工件和过程。这个角色的重点是在测试自动化上；因此，这个角色也可以称作“测试构架师”或“测试自动化构架师”。或多或少可对比的TMap角色是方法支持和TAKT构架师。 技术 以下各节将描述有关测试策略开发和测试规格说明技术的许多RUP特定的提示。 测试策略 测试策略需要集中在尽可能早地查找出最重要的缺陷上，并且以最低的成本。对于测试策略的开发，TMap描述的技术是足够的。下面描述了许多不同的额外提示，这需要被考虑到有关测试策略的开发上。 系统开发的重复特性意味着，产品第一次不会被完成，但会持续地进展。每一次进展发生得时间很短，并会受限于时间。 测试人员经常会抱怨，分配给他们的时间太少了：例如，“要在这么短的时间内测试那么多内容。”换句话说，开发人员抱怨，他们同样受限于时间太少，不能按照期限交付产品。项目经理不能允许开发人员在测试的成本上花费时间。因此，测试过程的提前管理并应用一种基于风险的方法，如TMap所描述的，是必须的。例如，不允许额外的功能被合并到最终的构建中，通常应当是同意的。 另外一个问题可以在许多连续进展中发现。在产品已经经历多次演变后，仍然是按照早先需求同意的进行吗？产品的一部分将准备好，并且需要制订有关定义下一个周期变化内容的协议。风险是，在早先的周期中接受和同意的部分还可以变更，并且没有文档化。这种情形被认为是回归。 项目经理通常不提供测试人员进行此回归的任务。回归测试需要在一个合格的基础上执行，以一次次地确认系统的工作。 测试人员的另一项工作是帮助最终用户作出正确的觉定，并且在评估新的产品版本时不要忘记部分内容。要完成这个，测试人员可以使用要评估内容的检查单。测试人员也可以利用他的专门技术和经验，来确定薄弱点和高风险区域。最终用户的职责就是决定产品是否能接受。测试人员的职责是确定概览时很明显的缺点。 测试规格说明技术 可用的测试基础会极大地影响测试规格说明技术的选择。在RUP中，不用说，UML为这些技术提供了基础。UML作为一种传统建模技术的普及给许多人提出了建议，已有的测试规格说明技术同意需要被更改；他们相信，测试技术只能用在传统的建模技术上。这是一个误解。对于传统的建模技术，例如实体关系图或数据流程图，没有可用的特定测试技术会过时。同意地，没有特定的测试技术可用于用例图或类图。通常，测试技术使用了功能描述、数据确认和屏幕布局，以及在哪里找到这些描述是不重要的， 在设计一个基于UML的测试脚本时，需要执行在TMap中所描述的步骤。在确定测试情形时，逻辑测试用例被首先定义，然后被转换到物理测试用例。最后，在收集到初始需要的测试数据之后，执行测试的顺序在一个测试脚本中确定。表7提供了可用测试规格说明技术的一个概述。 表7：可用的测试规格说明技术 
如表7所示，UML的一个重要部分是用例。它们在高层次上描述系统的功能。基于这些用例，测试可以在一个受限层次上进行，因为用例只描述执行者和系统的交互。交互的准确内容和它们发生的频繁程度并不强调。 用例和用例图可以用于测试系统的以下方面：
当执行基于用例的测试时，最明显的技术是过程循环测试（或规则测试）。然后基于用例图来设计测试路径，通过这些，所有相关关系和可能的选择至少要一次通过。测试路径的数量取决于测试标准（有关更多信息，请参见TMap）。 为了能够依靠用例来测试，除了用例描述和用例图之外，还需要有关特定方面的额外信息。特别是，缺乏需要将逻辑测试用例转换成物理测试用例的信息，需要如下问题的回答：
所需的额外信息需要在类和约束、类图和顺序图的描述中确定。 作为一个例子，了解相关变量的内容是重要的。特别是，一个人必须理解影响一个用例结果的不同输入可能性。一个用例可能的实例数量取决于这些变量。例如，偿还抵押贷款的变量可以是不同的偿还方式或一个客户可以允许有的抵押贷款数量。 此外，需要额外的信息在更高的质量级别测试。例如：
除了以上提到的测试规格说明技术之外，检查单也被使用，它是基于经验和系统的许多值得测试或复审的方面的。最终，测试基础的不同的未文档化的变量，像最终用户的知识和经验，可以用来补足文档化的内容。 测试人员在开发过程早期所涉及的内容，特别是在开发人员和最终用户之间的沟通过程中，在迭代系统开发中是及其重要的。也允许测试人员评估非文档化的协议。 基础结构
验收测试
在第一个场景中，验收测试是作为一个项目独立实施的，其是独立于其它RUP项目被执行的。一个设计良好的测试可以提供足够的保证，系统可以按照产品的质量验收。然而，这种类型的一个项目会降低系统开发过程的快速和迭代特性。如果组织发现，将采取迭代化开发的系统直接产品化的风险太高，就可以找到选择这种方法的原因了。在第二个场景中，验收测试按照与RUP迭代中的系统测试相同的方式来执行。在这种情况下，系统开发过程的迭代特性可以被维护，并且测试被组织起来，也称为可能。 第三种组合是将验收测试和系统测试集成到一个集成测试级别（IT）。实际上，这个步骤有太多不合需要的结果和风险，许多测试的质量和覆盖度都不足。因此，这种选则就不推荐。所有这三种可能性的说明如图11。 
图11：验收测试的三种可能性 选择的选项取决于具体情况。无论如何，主测试计划需要确保，系统测试和验收测试是有关测试覆盖的补充。这意味着，在测试覆盖中，不应当有任何不必要的覆盖或缺口。
感谢
附录A：按照RUP和TMap的主测试计划 
附录B：RUP和TMap测试活动的详细对比 
按照从RUP到TMap排序的相同的表： 
注释 2像James Bach, Cem Kaner, 和 Brian Marick这样的测试大师，是这种方法的支持者。有关探索测试的更多信息可以在www.satisfice.com.中找到。TMap和探索测试可以在Koomen, T., (2003)的Exploratory testing and TMap, www.tmap.net 中找到。 3基于Szymkowiak, P., Kruchten, P.,Testing: The RUP philosophy,The Rational Edge, February 2003. 4参见 L. Copeland,use Cases and testing: Testing UML models, Part 1" ，来自STQE Letter, June 2002，在 www.stickyminds.com 5要找更多的有关探索测试和TMap的内容，请发送邮件到tmapadmin@sogeti.nl，索要T. Koomen, Exploratory testing and TMap论文。
|
为什么你应当用TMap来补充Rational统一过程，或RUP中所描述的测试过程呢？毕竟，RUP承认有效测试的重要性，并将测试划分成贯穿整个生命周期的质量验证的一个重要的最佳实践。而且，RUP强调在一个单独的工作流中测试，这一点在2002版中进行了更新。（集中于测试，成了撰写本文的推动因素之一。）并且，与其它系统开发方法比较，RUP提供了详细的测试指导。
Tim
Koomen于1986年毕业于阿姆斯特丹大学的信息学专业，1992年他已经是一名专业测试人员，有管理大多数测试活动的经验。他参与了荷兰Sogeti
Nederland的客户的几个测试项目，这个公司有四百多个专用测试人员，并且是结构化测试方法TMap和TPI模型的所有者。Tim是研发团队的一个成员，参与了许多项目，例如在敏捷环境中测试（DSDM，RUP），测试过程改进（Test
Process Improvement，TPI），以及测试软件包。他是TPI
Book的合著者，这本书由荷兰语翻译成英文，德语，以及日语。他也是TMap
Test Topics一书（2004年荷兰语版，预期2005年出英文版）的编辑之一，并且他经常出席研讨会，例如ICSTest，Quality
Week Europe，SQE Congress 2000，Quality Week 2000，Conquest 2001，StarEast
2003，还有整个欧洲和美国的培训会。在2003年，由于他在TPI、TMap和测试方面的工作，他获得了欧洲测试优秀奖。