内容


TMap和Rational统一过程

Comments

Illustration为什么你应当用TMap来补充Rational统一过程,或RUP中所描述的测试过程呢?毕竟,RUP承认有效测试的重要性,并将测试划分成贯穿整个生命周期的质量验证的一个重要的最佳实践。而且,RUP强调在一个单独的工作流中测试,这一点在2002版中进行了更新。(集中于测试,成了撰写本文的推动因素之一。)并且,与其它系统开发方法比较,RUP提供了详细的测试指导。

然而,与RUP一起实施TMap在许多方面提供极大的增值:

  • TMap是一种非常广泛和完善的测试方法,但是在RUP中,测试只是许多方面之一。一种完善的方法,在所有范围中都有详细内容,例如技术的描述,在测试方面提供比RUP单独提供的更广泛的指导。
  • TMap在许多组织中都成为标准,测试人员非常熟悉它,并且许多测试人员受过TMap培训,使用过工具和模板。当一个组织开始一个RUP项目时,为了尽可能取得最大效率,通常会尝试使用大家都知道的方法。
  • 测试的应用在RUP的2002版中更为困难。特别是如果你不知道选择探索性测试的话。工作流程明细、活动和角色已经在很大程度上进行了扩展,但是这些方面之间的关系,对于那些通过更常规的测试方法来获得测试经验的人来说,比较难以理解。

我们希望这种方法为所有碰到此挑战的测试人员提供一种实用的解决方案。本文并不强调迭代化系统开发项目给测试人员提出的挑战。关于本主题的更多信息,读者应该查阅TMap的iCBD版本。1

由于本文重点强调一种明确的变化,所以假定读者对TMap和RUP知识有一定的水平。

测试作为一个RUP的最佳实践

按照RUP,测试是系统开发的一个重要部分。第五个最佳实践(在IBM Rational是持续地质量保证)主要说明,所有的开发活动和工件都需要通过持续的测试和复审来检查质量。这意味着测试不仅仅是软件构建之后的一个阶段。

在2002年以前,RUP的重点是在传统的计划、规格说明和测试的执行上,并且很大的一个重点是在测试自动化上。在2002版中,对测试流程进行了相当大的变化。2002版转向了基于探索性测试的方法。认识系统,以及涉及和执行测试现在是并行活动。在此之后隐藏的基本原理是,由于系统文档经常改变,不应当将重点放在设计和编写基于文档的测试用例这些耗时的任务上。理想情况下,设计和执行测试应当发生在软件被交付的时候,并且系统文档不应当被唯一地用作测试依据。2

RUP测试方法是基于以下原理:3

  • 迭代化开发。测试是在整个迭代化开发周期中执行的,每次都有一个不同的目标,依照RUP这是大家都知道的一个任务。例如,测试在精化阶段,可以集中在确认构架上,而在构建阶段中,测试可以集中在查找最重要的软件缺陷上。
  • 在起始点最少的可用文档。除了绝对必需的测试文档,不应当产生更多的测试文档。主测试计划和测试工作的详细计划,应当是在测试执行之前所产生的所有文档。
  • 整体分析。整体分析集中在搜索一个问题或关注点的所有方面之间的关系上。在RUP中,这意味着,测试依据不仅仅来源于规格说明书,而是来源于一个原始信息集,包括那些没有文档化的。
  • 测试自动化。工具在不同的测试活动中都会有帮助。

RUP确定了四级测试:单元测试、集成测试、系统测试和验收测试。这些测试级别可以是并列的,这取决于主测试计划(在项目级)和迭代测试计划(在迭代级)。

主测试计划和迭代测试计划

RUP对整个项目使用一个主测试计划,对每个迭代使用一个迭代测试计划。测试经理在先启阶段草拟主测试计划。尽管是从系统测试开始的,但为了排列这些测试级别,在这两种情况中,计划都有可能包括系统测试之外的其它测试级别。这两个计划在内容上有大量的相似之处。只有范围和详细的程度有区别。一个选择是将迭代测试计划与迭代计划集成在一起。在这种情况下,测试的贡献主要是在于指出了确定和执行测试用例所依据的需求。与此迭代相关的其它测试活动也被提出来了;例如,适当的测试工具的选择或创建明确的指导方针。

单元测试(UT)

单元测试用于软件的最小可测试单元。单元测试强调内部结构,例如逻辑和数据流,以及单元的功能和外部可见行为测试。

RUP中的单元测试是实现人员的明确任务,在对于新的或变更单元的每个迭代中,都是由实现人员来执行实现测试组件和子系统,以及执行单元测试这些活动。这就使得测试成为与此角色相关联活动的主要部分。

尽管RUP包含了许多关于单元测试的指导方针,但是并没有命名一个项目特定指导方针需要在其中被固化的工件。这就和例如设计和用例建模的指南形成了对比。理论上,单元测试的这些指南应当被包括在编程指南中,因为编程指南是记录实现人员角色的其它指南的地方。指南的开发和执行是过程工程师们的共有责任,并且应当是与主测试计划是一致的。

单元测试配置有一个或多个工具。对于单元测试,IBM Rational软件提供了以下工具:

  • IBM Rational PurifyPlus。提供多平台、独立IDE的多种运行时分析能力--例如内存泄漏检测,性能压力,以及代码覆盖独立--针对Java,C/C++,.NET语言和Visual Basic。
  • IBM Rational Software Architect 和 IBM Rational Application Developer for WebSphere Software。这些工具提供了Rational PurifyPlus针对Java语言中的所有功能,再加上其他功能,包括自动化组件测试、高级内存泄漏检测,线程分析,以及执行流可视化。
  • IBM Rational Test RealTime。提供针对在嵌入式或运行时目标中执行的软件的运行时分析和组件测试功能--从8位微芯片到64位运行时操作系统。

其它可能的工具包括像JUnit这样的免费软件,其用于在Java环境中大范围的测试(软件)单元的功能。工具的选择取决于要测试的需求。例如,如果性能不是一部分需求,那么对于性能测试就不需要工具。

集成测试(IT)

集成测试取决于当软件组件在被合并起来执行一个用例时,是否功能正确。实现人员将他的已单元测试过的组件提交到集成人员那里,集成人员将这些单元合并成一个中间构造。这种一步步的组件集成发生在自下至上的方式中,并且按照集成构建计划规定的顺序进行。在每一步之后,集成人员组成一个中间构造,被提交用于执行集成测试。主要目标是确定这些组件与已经集成组件之间的兼容性。结果,常常会执行集成构建计划的一个子集。这种一步步的方法考虑到足够的问题隔离和分析。

RUP规定,集成测试由测试角色的人员来执行。取决于集成活动的数量,这些测试可以合并在集成员角色下面。实际上,这些角色为了效率最大化,可以由相同的人员来承担。这意味着,集成人员也可以执行作为其活动主要内容的集成测试。

关于指南和工具,应用于集成测试与单元测试是一样的。主要的差别是,集成测试的指南不会自动成为编程指南的一部分,但会是测试指南的一部分,或遵循集成构建计划。测试经理需要与其他过程工程师调整这些。

系统测试(ST)

当软件功能成为一个系统时,在不同组件的集成(测试)之后,就开始执行系统测试。多个构建可以在一个迭代中交付。通常,每个构建都要进行一次系统测试,除非集成测试计划另有规定。主测试计划和更具体的迭代测试计划,需要简要说明哪个构建需要被测试。

RUP确定了系统测试的测试流程。如图1所描述的,缺省工作流、活动、工件、角色等等,都在此流程中进行了详细描述。

Figure 1

Figure 1

图1:缺省测试工作流

图1显示了用于RUP中的一次迭代的缺省测试工作流。此工作流可以根据不同情况而有所不同。此工作流包含了许多步骤,说明了工作流详细内容。对于测试工作流,这些步骤是定义任务评价,检验测试方法,确认构建稳定性,测试和评估,完成可接受任务和改善测试资产。

每个工作流明细包括许多活动,活动的输出是工件(产品)。相同的活动可以出现在多个明细中--例如活动“确定测试思想”,出现在定义任务评价、测试和评估、完成可接受任务和改善测试资产。注意,工作流明细的语境会影响活动执行的解释。

对于每个项目,实现流程的方式--意味着被选择的活动子集和工件,相关的角色,以及谁来实现这些角色--在开发用例和软件开发计划中规定。这也可以应用于测试流程。履行测试设计员角色职责的人员决定测试指南。测试经理负责指南集中的系统测试的执行,并管理不同的测试角色(谁,做什么,以及什么时间)。其他角色包括测试分析师和测试人员。在每个角色中,都要描述职责、相关技能和可能的任务(包括可能的任务合并)。考虑到提前展开的任务的数量,每个项目的所有角色需要进行充分地分配,因此对于测试团队的成员,就可能共享角色和/或参与到多个项目中。

对于系统测试有多个可用的工具。IBM Rational软件提供:

  • IBM Rational TestManager 用于计划、管理和报告任何测试工作要求
  • IBM Rational Manual Tester 用以提高手工测试工作的效率
  • IBM Rational Functional TesterIBM Rational Robot 用于功能和回归测试的自动化
  • IBM Rational Performance Tester 用以通过多用户模拟和响应时间度量来评估应用软件可扩展性。

要推动团队沟通、协作和合作,IBM Rational还提供额外的解决方案:

  • IBM Rational RequisitePro 用于需求和用例管理
  • IBM Rational ClearQuest 用于基于工作流的缺陷和变更管理
  • IBM Rational ClearCase 用于配置管理

验收测试(AT)

验收测试是在软件部署之前的最后的测试。主要的目标是验证软件是否已准备好,可以被最终用户用于执行其设计的任务和功能。

验收测试被放在移交阶段,并且是部署流程的一个主要部分。RUP定义验收测试不够充分,只是作为系统测试用例子集的重新运行。测试人员需要在一个类似产品的环境中执行这些用例。在验收测试期间,考虑工件产品的产品验收计划是很重要的。项目经理在项目的先启阶段开始编写产品验收计划。验收测试的相关主题是验收标准、接受的工件和评价方法。

RUP没有提供用于在此阶段部署的工具的许多指导。取决于验收测试的实施,可以部署与在系统测试中所使用的相同的工具。

复审

如第五个最佳实践所展示的,RUP将质量验证认为是在整个系统开发过程中要被执行的事情;除测试之外,这也意味着质量保证。质量保证计划是作为系统开发计划的一部分编写的,特别是控制过程的质量。复审在RUP中描述得很详细,定义了三个角色:复审协调员、管理复审员和技术复审员。复审协调员协调和管理复审过程,管理复审员主要检查项目计划和报告,技术复审员复审实际的系统开发产品(例如业务用例模型,业务分析模型,需求,构架,设计和代码)。复审不会在本文中进一步详细说明。

角色

在每个角色中,都有职责、相关技能和可能的分配(包括角色的可能组合)。对于每个项目,所有的角色都需要进行充分地分配(质量和数量),因此就有可能共享角色和/或参与到多个项目中。

将TMap适配到RUP

现在,让我们考虑一下TMap阶段和活动如何被合并到RUP中。TMap遵守RUP的测试实践,如测试流程中所描述的那些。因此,这里所描述的映射只会在系统测试上,而不水在单元测试、集成测试或验收测试上。如在前一章所描述的,这些测试没有在RUP中进行足够详细的描述,以进行一个彻底的映射过程。有关这些额外测试的更多详细内容在TMap方法中可以得到。对于单元和集成测试,TMap的白盒测试阶段可以应用;对于验收测试,读者可以阅读下面的验收测试一节。

主测试计划

TMap的主测试计划可以比作RUP的主测试计划。一个需要考虑TMap主测试计划的范围大体上会有多个测试级别,而在RUP中可以只是单个系统测试。TMap的主测试计划也可以明确地提出测试策略,并选择不同测试的质量准则。入口准则可以比作TMap的前提条件;出口准则相对于标准TMap是多出的,但是当使用一个预先确定的测试策略时,就不是必要条件了。

阶段划分

TMap的阶段关联到测试流程的缺省工作流,如早先在图1所示。图2显示了TMap生命周期的一个高级视图。

Figure 2

Figure 2

图2:一个活动简短概述的TMap生命周期

让我们按照每个迭代一步步走一下工作流程。对于每个TMap阶段,活动将会被声明并连接到最合适的RUP工作流上。我们也将描述另外的TMap,或在某些情况下的RUP测试活动。大多数的RUP和TMap的相应活动是通过TMap进行详细地描述。此外,附录C包括了TMap和RUP工件之间的一个对比。

图3显示了TMap阶段和RUP工作流之间的一般关系。

Figure 3

Figure 3

图3:TMap生命周期和RUP工作流之间的全局关系

计划和控制

计划和控制阶段可以被分为用于计划的活动和用于控制的活动。

RUP步骤,定义评价任务“显示了许多与TMap的计划和控制阶段的计划活动相似处。这些相似处在表1中很明显。对于那些不熟悉定义评价任务的人”步骤,显示在图4中。

表1:RUP步骤,定义评价任务,显示了许多与TMap的计划和控制阶段的计划活动相似处。

Table 1

Table 1

对于不熟悉RUP步骤定义评价任务的读者,在图4中描述。

Figure 4

Figure 4

图4:RUP步骤定义评价任务

定义评价任务工作流确定了迭代的测试目标或测试任务,以及基于主测试计划的测试范围。一个人需要确定这是否是有限功能的第一个原型,这要求一些全局测试,或是否它引用到部署之前的最新迭代。此外,一个人需要确定是否整个系统要求高质量。测试进行了计划,方法得到了确定,资源被明确要求,并且进度监控也到位了。所有这些的结果是迭代的一个测试计划,这就是迭代测试计划。

RUP的定义测试方法工作流包含许多步骤,包括称为确定测试的必要深度的步骤。尽管TMap中的测试策略在某种方式上可以与活动定义测试方法和定义评估和可追踪性需求进行对应,但是TMap中的详细程度要更高一些。而RUP在覆盖方面解释了定义评估和可追踪性需求,覆盖事实上主要是特定于测试技术的使用,并且因为RUP没有在这个问题上细化,此工作如何进行还是不清楚。直到正式的验收测试完成了,测试策略就与不同的涉众协调好了。除此之外,这个工作流提供了如何解释测试结果的全局说明。

如果要使用TMap测试策略,你必须要小心确保测试是在迭代或测试任务的范围中进行。换句话说,不要定义一个适合于最终产品的测试策略,如果第一次迭代只是一个原型的话。

另外一个差异是,TMap测试策略基于风险、质量特性、系统部分和必需的测试技术。RUP也是由风险开始的,但是使用测试类型,而TMap使用质量特性和系统部分。RUP定义的测试类型是:

  • 功能
  • 数据和数据库完整性
  • 业务周期
  • 用户界面
  • 安全性
  • 容量
  • 压力
  • 负载
  • 性能
  • 安装
  • 配置
  • 恢复

按照TMap,测试策略的一个重要部分是与成本估算放在一起的。尽管在RUP中,所需要的人时是一个测试计划模版的一部分,但是不清楚估算人时对应于哪些活动。

TMap也详细地定义了所需要的组织和基本结构。RUP在后面的一个阶段,验证测试方法,定义了基本结构。需要的组织是主测试计划和迭代测试计划模版的一部分,但是相应的活动不清楚。

在TMap和RUP都有的控制活动主要是在步骤完成可接受任务。这种映射显示在表2中。

表2:在TMap和RUP中的控制活动

Table 2

Table 2

在一个迭代期间要执行多个测试周期。这个步骤主要集中在每个测试周期。完成可接受任务步骤的目的,如图5所示,是持续地控制不同测试的优先级,并且确保只执行那些可以对测试任务增加最大价值的测试。这包括监控(解决)严重缺陷,监控后续构建可能的回归,以及向所有相关团体报告应用软件的质量。如果有必要,会调整测试任务。

Figure 5

Figure 5

图5:RUP步骤完成可接受任务

RUP规定,优先级主要是控制过程的一部分,但是在TMap中,优先级在早期阶段就按照测试策略明确化了,然后作为测试计划的维护来进行。

剩下的活动,控制测试,在RUP中被放在改善测试资产下面,其相应于维护测试件和测试环境。

准备

TMap的准备阶段在RUP中不明显,但是可以合并到评价任务和验证测试方法中,这主要是因为在这两种情况中,这些步骤相比较实际的测试,更关心准备情况。

表3:TMap准备接口可以合并到RUP的评价任务和验证测试方法中。

Table 3

Table 3

对于不熟悉RUP步骤验证测试方法的读者,其描述见图6。

Figure 6

Figure 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中的测试和评价

Table 4

Table 4

对于不熟悉RUP步骤“测试和评价”的读者,可以在图7中看到描述。

Figure 7

Figure 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

Table 5

Table 5

对于不熟悉RUP步骤-确认构建稳定性的读者,在图8中进行了描述。

Figure 8

Figure 8

图8:RUP步骤-确认构建稳定性

作为执行活动的第一个步骤,复审测试对象或基本结构是RUP步骤-确认构建稳定性的一部分。注意RUP,这个步骤是在定义评价任务之后立即开始的,这与TMap计划阶段多少有些同义。在确认构建稳定性中,已提交的软件版本(构建)被测试稳定性;换句话说,这足以开始进行测试执行吗?因此,按照TMap,这个步骤不比规格说明和预测试执行内容要少。每个迭代都可以提交多个构建,尽管通常不是每个构建都要进行此步骤。此测试可以被(部分地)自动化。

当我们严格遵循RUP时,这意味着我们在软件交付前抛弃了测试用例的规格说明,因为这发生在软件交付之后。这样的缺点是,不会鼓励先于交付而完成测试准备,并且作为将不必要的测试活动放在项目的关键路径上的结果。可能的优点是,软件和文档被同步的可能性更高,测试用例不会基于过期的文档来设计,以及设计和执行同时进行在人时方面会更有效率。5

在TMap中执行预先测试的小步骤比在RUP中强调要详细得多。在许多情况下,延迟测试用例规格说明的优点直到第一次构建交付之后才会大于缺点。对于此,更灵活的解释和下一步骤,测试和评价,可以很容易地消除这些对象。如果还没有交付任何构建,确认构建稳定性就不能执行。然而,下一步骤可以开始。在这个步骤中,测试用例只能指定,但还没有执行。图9显示了这会如何发生。

Figure 9

Figure 9

图9:可选择的工作流顺序

TMap执行阶段的剩余活动可以放在测试和评价中,和规格说明的大多少活动一样。按照这种方式,测试人员执行他们的测试用例,并在“执行测试集”中分析有关预期结果的缺陷。

完成

TMap完成阶段的活动及其与RUP的对照如表6所示。

表6:TMap完成阶段及其与RUP的对照

Table 6

Table 6

前三个完成活动可以被很好地映射到RUP的完成可接受任务中,这在图10进行了描述。然而,在TMap中,与RUP的改善测试资产有一些重迭。

Figure 10

Figure 10

图10:RUP步骤-改善测试资产

“完成可接受任务”产生了工件-测试评价总结,其包含测试对象和测试过程的一个评价。“改善测试资产”用一般方式描述了测试件的维护和改善。这包括测试的维护,测试环境的管理,以及自动化测试的维护。对这种执行测试的方式推荐的调整也可以从这个步骤进行,这取决于测试评价总结。除了第四个TMap活动,保存测试件,这个RUP步骤也包含测试过程的评价。在TMap中的另外一个步骤正在解放测试团队。在RUP方法的正式工作中,这常常是不必要的。

组织

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

  • 测试经理
  • 测试分析师
  • 测试员
  • 测试设计师

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

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

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

技术

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

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

测试策略

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

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

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

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

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

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

测试规格说明技术

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

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

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

Table 7

Table 7

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

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

  • 事件的预期顺序。(需要)在系统中执行操作的顺序。
  • 例外事件或特定事件。例如,在系统的非预期操作或不正确使用下,系统的反应。
  • 所有的关联和依赖用例和执行者之间,以及用例之间

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

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

  • 参与一个用例的所有变量的范围是什么?
  • 在不同的用例变量之间存在哪些输入和输出关系?一个用例触发什么,前置或后置条件是什么?
  • 有不同用例之间的顺序依赖吗?

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

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

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

  • 要开发一个测试策略和计划,了解哪些用例对于系统功能是至关紧要的,哪些不是,这是很重要的。除此之外,要注意了解每个用例的相关执行次数。换句话说,用例以何种频率在系统中使用?当不能从文档中取得额外信息时,在客户组织中的系统专家和/或最终用户应当提供这些问题的答案。
  • 通过设计基于类描述的测试用例,一个人能够在较深的级别上测试系统。实际上,许多内部对象不能之间被控制,这使得单独测试它们不太可能。然后这些定义的测试用例只能通过将它们与测试用例合并来测试。

除了以上提到的测试规格说明技术之外,检查单也被使用,它是基于经验和系统的许多值得测试或复审的方面的。最终,测试基础的不同的未文档化的变量,像最终用户的知识和经验,可以用来补足文档化的内容。

测试人员在开发过程早期所涉及的内容,特别是在开发人员和最终用户之间的沟通过程中,在迭代系统开发中是及其重要的。也允许测试人员评估非文档化的协议。

基础结构

TMap的基础,“基础结构”,涉及到测试环境、工具和工作空间。对于一个RUP项目中的一个测试过程,只有工具支持是特定的,其它两个都是“一切正常”。IBM Rational软件提供几个工具支持测试过程,如早先的“系统测试”一节中所描述。然而,测试自动化不是其自己的一个目标。特别是,使用记录和回放工具--如Functional Tester 或 Robot--的功能验收测试的自动化需要小心地被考虑。以下考虑对这种情况有影响:

  • 在软件以较小的方式经常变更,并且新的发布版本经常交付时,回归测试的自动化就十分重要了。
  • 测试的自动化要求开发期间的一个适度稳定的系统。如果不是这种情况,测试脚本就需要一次又一次地构建。稳定性会受到影响,例如,用户界面的易变性和项目或迭代中系统分解的质量。
  • 在迭代中测试的时限决定是否有充足的时间用于测试自动化。
  • 是否能找到足够的(高级)测试自动化人员?如果没有,计划能提供足够的时间培训人员吗?
  • 维护组织能够接收自动化测试集吗(在一个稍后的时间)?

验收测试

要弥补RUP中验收测试(AT)指南的不足,可以建议可能性:

  • 将验收测试组织和结构化为TMap所描述的。
  • 将验收测试与系统测试按照TMap描述的组织在一起,按本文档所注明的那样。

在第一个场景中,验收测试是作为一个项目独立实施的,其是独立于其它RUP项目被执行的。一个设计良好的测试可以提供足够的保证,系统可以按照产品的质量验收。然而,这种类型的一个项目会降低系统开发过程的快速和迭代特性。如果组织发现,将采取迭代化开发的系统直接产品化的风险太高,就可以找到选择这种方法的原因了。在第二个场景中,验收测试按照与RUP迭代中的系统测试相同的方式来执行。在这种情况下,系统开发过程的迭代特性可以被维护,并且测试被组织起来,也称为可能。

第三种组合是将验收测试和系统测试集成到一个集成测试级别(IT)。实际上,这个步骤有太多不合需要的结果和风险,许多测试的质量和覆盖度都不足。因此,这种选则就不推荐。所有这三种可能性的说明如图11。

Figure 11

Figure 11

图11:验收测试的三种可能性

选择的选项取决于具体情况。无论如何,主测试计划需要确保,系统测试和验收测试是有关测试覆盖的补充。这意味着,在测试覆盖中,不应当有任何不必要的覆盖或缺口。

参考文献

  • Copeland, L.,Use Cases and testing: Testing UML models, Part 1," 来自STQE Letter, 2002年6月,在 www.stickyminds.com
  • IBM Rational 软件(1997),UML Summary 版本 1.0
  • IBM Rational软件,不同的RUP白皮书,www.rational.com
  • Koomen, T., (2002) Testen van iCBD, www.tmap.net
  • Koomen, T., (2003) Exploratory testing and TMap, www.tmap.net
  • Kruchten, P. (2000), The Rational Unified Process, An Introduction, Second Edition, Addison-Wesley, ISBN: 0-201-70710-1
  • Pol, M., R. Teunissen, E. van Veenendaal (1999), Testen volgens TMap, Tutein Nolthenius,Hertogenbosch, ISBN: 90-72194-58-6
  • Szymkowiak, P., Kruchten, P. Testing: The RUP philosophy,The Rational Edge, February 2003.

感谢

RUP2002版的产生得到了Sogeti工作组"TMap in RUP"的帮助。特别感谢Fedor Janssen, Richard Hakvoort, Loek Wilhelmus, Wim Bos, Andrsan Pelt, 和 Rob Baarda。Chris Dugardyn是IBM Rational的测试咨询师,Rabo的Cees Dulfer也提供了有价值信息。我也将感谢Sogeti的Mark Tolsma,在准备用于本文写作的材料上得到了他的帮助。

附录A:按照RUP和TMap的主测试计划

下表全面对比了RUP MTP和TMap MTP。

Appendix A Table

Appendix A Table

附录B:RUP和TMap测试活动的详细对比

下面的两个表在详细层次上对比了RUP和TMap的活动。第一个表说明了与RUP活动相连的每个阶段的TMap活动。当没有清晰的关系时,这个域已经被标记了一个问题标记(?)。请考虑,一个RUP活动可以出现在多个工作流上。在许多情况下,一个工作流的活动可以被映射到一个TMap活动上是很清楚的,但是相同的活动不能被映射到一个不同的工作流上。这种情况的一个例子是测试和评价中的“定义测试明细”,其可以被映射到TMap规格说明阶段中的“准备测试规格说明”。相同的活动“定义测试明细”也出现在“改善测试资产”和“验证测试方法”上。在这些情况下,匹配的TMap活动还没有被填充。

Appendix B1 Table

Appendix B1 Table
Appendix B1 Table
Appendix B1 Table

按照从RUP到TMap排序的相同的表:

Appendix B2 Table

Appendix B2 Table
Appendix B2 Table
Appendix B2 Table

附录C:对比TMap产品和RUP工件

Appendix C Table

Appendix C Table

注释

1Koomen, T., (2002) Testen van iCBD, www.tmap.net

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论文。


相关主题

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational, WebSphere
ArticleID=58249
ArticleTitle=TMap和Rational统一过程
publish-date=02152005