TMap和Rational统一过程

　　为什么你应当用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)

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

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