RUP学习

 

 

1． 这是一篇关于 RUP 的入门介绍文章，绝大部分内容均摘至网上各位测试同行的心得体会以及 RUP ，我在这里主要做了一下汇总。

2． 本文起因，其实我们常接触到的经典测试理论以及测试模板，大部分都源自与 RUP ，如软件测试工作分计划测试、设计测试、实现测试、执行测试、评估测试五个阶段来完成。其中计划测试阶段需要制定测试计划、整理测试需求；设计测试阶段要设计测试用例和测试过程；实现测试阶段要根据测试用例实现具体的自动化脚本或者手工的操作步骤；执行测试阶段则通过自动化测试工具或人手工来执行那些自动化或手工脚本；最后的评估阶段则要对软件的质量和测试工作自身的质量做出一个客观的评价等等。但其实这些只是软件开发工程的一部分而已，为了想让大家对测试从宏观上有一个整体的认识，不要孤立的看问题，我想把 RUP 具体的介绍一下。

2． 测试这行业其实和开发联系非常紧密，但具体流程架构我也不是很清楚，然后就想通过 RUP ，这个典型的开发框架流程来了解一下流程。最初的构想是让各位测友（包括我在内，我平常也只是看看，而没实际接触过该流程）通过该框架即流程能对测试有一个整体上的把握，嗯，仅此而已。然后查阅了一下资料才发现其实网上注意到这个问题的人已经很多了，包括 51testing 测试元老 jackei 在内（应该也不大吧，呵呵），参见他的《 RUP 测试过程实践之测试需求与测试用例》 , 因此我的这篇也就当做是用来抛砖引玉把。

3． 详细的流程说明和相关模板文档请自行下载 RUP 查看，在本文中我只是把我认为重要的罗列了出来，为防止翻译出入，保留了部分关键词的中英文对照。

4． 初学 RUP ，很多地方肯定有不足和错误，如需讨论，您可以使用 E-Mail ： salanhess@126.com 同我联系。

 

一 rup简介

软件开发的过程由方法论和工具构成（ process = methodology + tools ）。比方说装配电子设备，靠工具就可以胜任装配任务；但为了减少失误和提高效率，人们往往采用流水线作业，流水线作业便是一种应用于电子设备装配中的方法论。目前，信息技术市场流行的方法论有 RUP(Rational Unified Process), The Zachman Framework, XP(Extreme Programming) 等。在这些方法论中，最流行的要数 RUP 。因它与当前流行的 JAVA, J2EE 技术和面向对象的设计思想（ OOAD ）紧密的结合在一起，所以在大型的信息技术项目中得到了广泛的应用。 RUP （ Rational Unified Process ， Ratinaol 统一过程）是 Ratinaol （中文名称为瑞里）公司提出的一套软件开发过程。他最大的特点就是提供了一套完整的软件开发过程框架，任何组织或个人都可以根据需要来对该过程进行裁剪，并根据自身需要进行调整后使其成为个性化的过程。

Rup 的阶段图如下：

图1

 

图2

图1以二维的形式说明 RUP 的整个体系架构。水平轴代表时间并显示了过程生命周期的各个方面。生命周期阶段的管理视图在顶部，迭代的软件工程和项目管理视图在底部。垂直轴代表按照逻辑分组的规程，表示过程的静态方面 —— 如何用过程部件、规程、活动、工作流，工件和任务来描述 RUP。

图2解释：从管理观点出发，RUP 软件生命周期包括四个顺序的阶段，每个阶段都以一个主要的里程碑结束。进行评估以确定是否达到阶段的目标。令人满意的评估结果可以使项目向下一个阶段进行。简要地说，RUP 生命周期的阶段是：

• 先启（Inception）： 初始阶段的目标是在所有涉众之间达成关于项目的生命周期目标的协议。在项目进行之前必须确定重要业务和需求风险
• 精化（Elaboration）：精化阶段的目标是为系统体系架构设定基础。该体系架构进化了对最重要的需求（哪些需求对系统的体系架构有很大的影响）的考虑和对风险的评估。生命周期体系架构里程碑为系统的体系架构建立了一个受控的基线，并令项目团队在构构建段进行度量。
• 构建（Construction）：构建阶段的目标是澄清剩余的需求并完成基于基本体系架构的系统的开发。在此阶段要强调对资源的管理和对操作的控制，用来优化成本、进度和质量。
• 产品化（Transition）： 产品化阶段的重点是确保软件对最终用户是可用的。产品化阶段可以跨越若干次迭代，该阶段包括为发布而进行的产品测试，以及根据用户反馈做出较小调整。在生命周期的这个阶段，用户的反馈应主要用于对产品进行微调、配置、安装和解决可用性问题，在项目生命周期的更早期就应该解决所有的主要结构问题。

二 rup流程

注 1 ：右面的线条表示该部分在项目中所占用的生命周期，每一条黑线的两端即是该阶段的 milestone

注 2 ： RUP 的核心工作流程（Core Process Workflows ）分为业务建模（ Business Modeling ） 需求 （ Requirements ） 分析设计 （ Analysis & Design ） 实施 （ Implementation ） 测试 （ Test ） 部署 （ Deployment ）六个子流程。与核心工作流程相对应的是核心支持工作流程（ Core Supporting Workflows ），分为环境（ Environment ）、项目管理（ Project Management ）、配置与变更管理（ Configuration & Change Management ）三个子流程。这些流程间相互影响和制约，但是根据实际的项目不同，对应的流程也会相应的删减或扩充（这往往是一定的，计划总赶不上变化的）

 

再来看看 Rational Unified Process 的主要工件，及这些工件间的信息流图：

 

注3：工件是项目期间生成并使用的最终或中间产物。工件用于获取和传达项目信息。工件可以是文档、模型或者是模型元素

 

2．1 需求

整个管理的流程框架由图一可知（按照纵轴来划分）分为业务建模、需求、分析设计、实施、测试与部署6个子工作流程 。这里将介绍需求、实施和测试这部分的流程。

需求工作流程的目的：

1．  与客户和其他涉众在系统的工作内容方面达成并保持一致。

2．  使系统开发人员能够更清楚地了解系统需求。

3．  定义系统边界（限定）。

4．  为计划迭代的技术内容提供基础。

5．  为估算开发系统所需成本和时间提供基础。

6．  定义系统的用户界面，重点是用户的需要和目标。

 

 

这是 需求的工作流程明细图，项目的 先启阶段侧重于 分析问题和 理解涉众需要，而在项目的 精化阶段则强调 定义系统和 改进系统定义。由图可见核心支持工作流程如管理需求变更和项目管理等贯穿项目始终。

 

需求的活动概述：

注4：角色并不代表个人，而是说明个人在业务中应该如何表现以及他们应该承担的责任。若有一组互相联系、在功能上互相补充的活动需要执行，这些活动最好由同一个人来执行

 

需求的工件概述：

开发 前景文档、 用例模型、 用例和 补充规约是为详尽说明系统，即系统要做 什么。这样做的目的在于将所有涉众（包括客户和潜在用户）作为除系统需求之外的重要信息来源。

注5：涉众是指所有会受到项目结果重大影响的人。要有效地解决任何复杂的问题，就会涉及到满足不同涉众的需要，了解涉众的组成及其特定需要是开发有效解决方案的关键

 

前景文档需要从客户的角度编写，不仅要纳入包含的特性的说明，还要纳入那些考虑过的但最终没有包含的特性。它是涉众可看到的需求提供了契约性的依据。

用例模型则是沟通媒介，在客户、用户和系统开发人员之间起到合同的作用。该模型要满足：

1． 客户和用户确认系统是否能符合他们的预期。

2． 系统开发人员按预期进行构建。

用例模型由用例和主角构成。模型中的每个用例都有详细说明，以显示系统如何一步一步地与主角进行交互，以及系统在用例中执行了哪些操作。用例的作用就象是贯穿软件生命周期的一条主线；同一用例模型在系统的分析设计、实施和测试中都有所应用。（因此也有人说rup是靠用例来驱动的，因为他不仅是开发的核心，也是测试的核心）

由图可知需求工作流程同其他工作流程都是相关的：

1．  业务建模 工作流程提供了业务规则、业务用例模型和业务对象模型，包括了领域模型和系统的组织环境。

2．  分析设计 工作流程从需求中获取主要输入（用例模型和词汇表）。在分析设计中可以发现用例模型的缺陷；随后将生成变更请求，并应用到用例模型中。

3．  测试 工作流程对系统进行测试，以便验证代码是否与用例模型一致。用例和补充规约为计划和设计测试中使用的需求提供输入。

4．  环境 工作流程用于开发和维护在需求管理和用例建模中使用的支持性工件，如用例建模指南和用户界面指南等。

5．  管理 工作流程用于制定项目计划，并制定需求管理计划及各次迭代计划（说明请参见迭代计划）。用例模型是迭代计划活动的重要输入。

2．2 实施

实施的目的包括：

1．  对照实施子系统的分层结构定义代码结构、

2．  以构件（源文件、二进制文件、可执行文件以及其他文件等）的方式实施类和对象、

3．  对已开发的构件按单元来测试

4．  将各实施员（或团队）完成的结果集成到可执行系统中。

实施工作流程的范围仅限于如何对各个类进行单元测试。系统测试和集成测试则属于测试工作流程。

实施与以下工作流程有关：

1．  需求 工作流程说明如何通过用例模型获取实施应满足的需求。

2．  分析设计 工作流程说明如何开发设计模型。

3．  测试 工作流程说明在系统集成过程中如何对每个工作版本进行集成测试。它还说明如何测试系统以检查是否所有的需求都已经得到满足，以及如何检测缺陷并递交有关报告。

4．  环境 工作流程说明如何开发和维护实施过程中所使用的支持工件，例如流程说明、设计指南和编程指南等。

5．  部署 工作流程说明如何使用实施模型来生成代码，并将代码交付给最终客户。

6．  项目管理 工作流程说明如何制定最佳的项目计划。计划过程包括几个重要方面：迭代计划、变更管理和缺陷跟踪系统。

实施工作流程明细图：

 

实施的活动概述图:

由图可知，架构设计师最终需要提供实施模型；实施员则扶着实施构件并实施子系统（即编码阶段）；集成员则负责集成构件计划并提交工作版本（即daily build），代码复审员负责复审代码并提交复审记录

注6：集成员提供的构件也可能是桩模块（即包含测试功能的构件或完整的实施子系统）

实施构件的工作流程明细图：

 

由于实施阶段的测试主要集中在单元测试上，下面再具体介绍一下实施中的测试单元部分：

实施员（开发人员或者是测试人员）需要在有可能引入错误的地方引入测试单元，通常这些地方存在于有特定边界条件、复杂算法以及需求变动比较频繁的代码逻辑中。除了这些特性需要被编写成独立的测试单元外，还有一些边界条件比较复杂的对象方法也应该被编写成独立的测试单元。

检查要点（Checkpoint）：编写好了这些测试，我们要有把握地告诉自己，如果代码通过了这些单元测试，就能认定程序的运行是正确的，符合需求的。如果我们不能非常的确定，就应该看看是否还有遗漏的需要编写的单元测试或者重新审视我们对软件需求的理解。需要注意的是如果对一个对象编写单元测试的时候，我们不但需要保证类的静态约束符合我们的设计意图，而且需要保证对象在特定的条件下的运行状态符合我们的预先设定。

   

2．3 测试

终于介绍到我们测试人员最关心的部分了，RUP中测试的工作流程图：

由图可知测试需要历经制订测试计划（Plan test）、设计测试（Design test）、实施测试（Implement）等多个阶段，下面我具体介绍这三个主要阶段。首先是是制订测试计划的工作流程明细图：

该阶段的目的是通过生成包含测试需求和测试策略的测试计划来确定和描述要实施和执行的测试。该计划后可以用来评测和管理测试工作。测试设计员带表最终用户来进行输入。

 

然后是设计测试的工作流程明细图：

该阶段的目的是确定、描述和生成测试模型及其已报告的工件（测试过程和测试用例）。测试设计员此时代表的角色是用例阐释者。（又是RUP的用例驱动思想）

最后是 实施测试的工作流程明细图：

该阶段的目的是实施（记录、生成或编写）在设计测试中所定义的测试过程，可以根据项目的实际情况选择采用自动化测试/手工测试或是两者相结合来进行测试。

 

按照RUP的测试流程，后面还有执行集成测试、执行系统测试以及评估测试等子流程，这里就不多介绍了，只要注意测试人员需要根据实际的工作版本和测试用例来执行测试即可。

三 RUP特点

前面挑了需求、实施和测试三个工作流程简单讲解后，相信大家应该对 RUP 有一个简单认识了把，最后再介绍一下 RUP 的特点

1）软件开发的迭代思想

思想起因：软件开发是一个非常复杂的工程，有诸多的因素影响工程的效率和成败。软件开发需要许多不同背景的个人和团队参与。由于这些复杂性，在软件开发的整个生命周期中每一个阶段都有可能留下隐患和错误。依照传统的瀑布（Waterfall）开发模式如果等到系统已经开发实现完毕，在测试阶段发现了重大问题，这时的返工将会造成人力、物力、财力及时间上的巨大浪费。鉴于以上的考虑，RUP强调软件开发是一个叠代模型（Iterative Model），RUP定义了四个阶段(Phase)：先启(Inception)，精化(Elaboration)，构建(Construction)， 产品化(Transition)。其中每个阶段都有可能经历以上所提到的从商务需求分析开始的各个步骤，只是每个步骤的高峰期会发生在相应的阶段。例如开发实现的高峰期是发生在构建阶段。实际上这样的一个开发方法论是一个二维模型。这种迭代模型的实现在很大程度上提供了及早发现隐患和错误的机会，因此被现代 大型信息技术项目所采用。

2）软件开发是由用例（Use Case）驱动的

Use Case 是RUP方法论中一个非常重要的概念。简单地说，一个Use Case就是系统的一个功能。例如在一个基于电子商务的医疗系统中，病人可以坐在家里通过网上浏览器与医生约定看病的时间(Make appointment)，这样，“Make appointment”就是系统的一个Use Case。在系统分析和系统设计中，Use Case被用来将一个复杂的庞大系统分割、定义成一个个小的单元，这个小的单元就是Use Case,然后以每个小的单元为对象进行开发。按照RUP, Use Case贯穿整个软件开发的生命周期。在商务需求分析中，客户或用户对Use Case进行描述，在系统分布和系统设计过程中，设计师对Use Case进行分析，在开发实现过程中，开发编程人员对Use Case进行实现，在测试过程中，测试人员对Use Case进行检验。

四 小结

    正如Brooks所说：“没有银弹”，RUP也不是，现代软件开发中复杂度、一致性、可变性以及不可见性这些无法规避的内在特性是谁也无法回避的。但是他确实能给我们在时间和质量上带来一些改进，如更早的在细化阶段对系统进行测试，降低项目开发后期困难度等。RUP只是一个良好的开端，一个 需要定制的框架，除此之外，良好的项目管理制度以及软件度量和一个高效的团队等等，这些都是项目成功必不可少的元素。

最后我想说的是：Have fun in RUP and Good luck！

2005-9-22  初稿        c carol2000