TMap和Rational统一过程(5)

　　组织

　　迭代化系统开发已经在一个项目的组织中有了重要地位，并且对于测试组织也是这样。本文并不详细说明这些，因为这是在RUP中详细说明的。然而，特定于RUP就是测试角色。RUP有许多测试角色：

　　测试经理

　　测试分析师

　　测试员

　　测试设计师

　　这些角色覆盖了测试流程的所有活动。

　　前三个角色主要对应于TMap测试经理和测试员的两个描述。RUP的测试分析师角色部分包括TMap测试经理的任务，部分包括TMap测试员的任务，并且特别确定了那些测试需要被执行，这些测试的(逻辑)设计，以及测试执行的最终结果的评价。

　　RUP的测试设计师角色定义并实现了测试方法，包括技术、工件和过程。这个角色的重点是在测试自动化上;因此，这个角色也可以称作“测试构架师”或“测试自动化构架师”。或多或少可对比的TMap角色是方法支持和TAKT构架师。

　　技术

　　TMap有多个技术特性，包括测试策略开发、测试点分析、测试的易测性复审和许多测试规格说明技术和检查单。这些技术没有在RUP中描述，但是他们可以毫无问题地应用到RUP测试项目中。

　　以下各节将描述有关测试策略开发和测试规格说明技术的许多RUP特定的提示。

　　测试策略

　　测试策略需要集中在尽可能早地查找出最重要的缺陷上，并且以最低的成本。对于测试策略的开发，TMap描述的技术是足够的。下面描述了许多不同的额外提示，这需要被考虑到有关测试策略的开发上。

　　系统开发的重复特性意味着，产品第一次不会被完成，但会持续地进展。每一次进展发生得时间很短，并会受限于时间。

　　测试人员经常会抱怨，分配给他们的时间太少了：例如，“要在这么短的时间内测试那么多内容。”换句话说，开发人员抱怨，他们同样受限于时间太少，不能按照期限交付产品。项目经理不能允许开发人员在测试的成本上花费时间。因此，测试过程的提前管理并应用一种基于风险的方法，如TMap所描述的，是必须的。例如，不允许额外的功能被合并到最终的构建中，通常应当是同意的。

　　另外一个问题可以在许多连续进展中发现。在产品已经经历多次演变后，仍然是按照早先需求同意的进行吗?产品的一部分将准备好，并且需要制订有关定义下一个周期变化内容的协议。风险是，在早先的周期中接受和同意的部分还可以变更，并且没有文档化。这种情形被认为是回归。

　　项目经理通常不提供测试人员进行此回归的任务。回归测试需要在一个合格的基础上执行，以一次次地确认系统的工作。

　　测试人员的另一项工作是帮助最终用户作出正确的觉定，并且在评估新的产品版本时不要忘记部分内容。要完成这个，测试人员可以使用要评估内容的检查单。测试人员也可以利用他的专门技术和经验，来确定薄弱点和高风险区域。最终用户的职责就是决定产品是否能接受。测试人员的职责是确定概览时很明显的缺点。

　　测试规格说明技术

　　可用的测试基础会极大地影响测试规格说明技术的选择。在RUP中，不用说，UML为这些技术提供了基础。UML作为一种传统建模技术的普及给许多人提出了建议，已有的测试规格说明技术同意需要被更改;他们相信，测试技术只能用在传统的建模技术上。这是一个误解。对于传统的建模技术，例如实体关系图或数据流程图，没有可用的特定测试技术会过时。同意地，没有特定的测试技术可用于用例图或类图。通常，测试技术使用了功能描述、数据确认和屏幕布局，以及在哪里找到这些描述是不重要的，

　　在设计一个基于UML的测试脚本时，需要执行在TMap中所描述的步骤。在确定测试情形时，逻辑测试用例被首先定义，然后被转换到物理测试用例。最后，在收集到初始需要的测试数据之后，执行测试的顺序在一个测试脚本中确定。表7提供了可用测试规格说明技术的一个概述。

　　表7：可用的测试规格说明技术

　　如表7所示，UML的一个重要部分是用例。它们在高层次上描述系统的功能。基于这些用例，测试可以在一个受限层次上进行，因为用例只描述执行者和系统的交互。交互的准确内容和它们发生的频繁程度并不强调。

　　用例和用例图可以用于测试系统的以下方面：

　　事件的预期顺序。(需要)在系统中执行操作的顺序。

　　例外事件或特定事件。例如，在系统的非预期操作或不正确使用下，系统的反应。

　　所有的关联和依赖用例和执行者之间，以及用例之间

　　当执行基于用例的测试时，最明显的技术是过程循环测试(或规则测试)。然后基于用例图来设计测试路径，通过这些，所有相关关系和可能的选择至少要一次通过。测试路径的数量取决于测试标准(有关更多信息，请参见TMap)。

　　为了能够依靠用例来测试，除了用例描述和用例图之外，还需要有关特定方面的额外信息。特别是，缺乏需要将逻辑测试用例转换成物理测试用例的信息，需要如下问题的回答：

　　参与一个用例的所有变量的范围是什么?

　　在不同的用例变量之间存在哪些输入和输出关系?一个用例触发什么，前置或后置条件是什么?

　　有不同用例之间的顺序依赖吗?

　　所需的额外信息需要在类和约束、类图和顺序图的描述中确定。

　　作为一个例子，了解相关变量的内容是重要的。特别是，一个人必须理解影响一个用例结果的不同输入可能性。一个用例可能的实例数量取决于这些变量。例如，偿还抵押贷款的变量可以是不同的偿还方式或一个客户可以允许有的抵押贷款数量。

　　此外，需要额外的信息在更高的质量级别测试。例如：

　　要开发一个测试策略和计划，了解哪些用例对于系统功能是至关紧要的，哪些不是，这是很重要的。除此之外，要注意了解每个用例的相关执行次数。换句话说，用例以何种频率在系统中使用?当不能从文档中取得额外信息时，在客户组织中的系统专家和/或最终用户应当提供这些问题的答案。

原文转自：http://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb05/koomen/