RUP学习.doc

由安博测试空间技术中心/提供 这是一篇关于RUP的入门介绍文章，绝大部分内容均摘至网上各位测试同行的心得体会以及RUP，我在这里主要做了一下汇总。 本文起因，其实我们常接触到的经典测试理论以及测试模板，大部分都源自与RUP，如软件测试工作分计划测试、设计测试、实现测试、执行测试、评估测试五个阶段来完成。其中计划测试阶段需要制定测试计划、整理测试需求；设计测试阶段要设计测试用例和测试过程；实现测试阶段要根据测试用例实现具体的自动化脚本或者手工的操作步骤；执行测试阶段则通过自动化测试工具或人手工来执行那些自动化或手工脚本；最后的评估阶段则要对软件的质量和测试工作自身的质量做出一个客观的评价等等。但其实这些只是软件开发工程的一部分而已，为了想让大家对测试从宏观上有一个整体的认识，不要孤立的看问题，我想把RUP具体的介绍一下。 测试这行业其实和开发联系非常紧密，但具体流程架构我也不是很清楚，然后就想通过RUP，这个典型的开发框架流程来了解一下流程。最初的构想是让各位测友（包括我在内，我平常也只是看看，而没实际接触过该流程）通过该框架即流程能对测试有一个整体上的把握，嗯，仅此而已。然后查阅了一下资料才发现其实网上注意到这个问题的人已经很多了，包括51testing测试元老jackei 在内（应该也不大吧，呵呵），参见他的《 RUP测试过程实践之测试需求与测试用例》,因此我的这篇也就当做是用来抛砖引玉把。 详细的流程说明和相关模板文档请自行下载RUP查看，在本文中我只是把我认为重要的罗列了出来，为防止翻译出入，保留了部分关键词的中英文对照。 初学RUP，很多地方肯定有不足和错误，如需讨论，您可以使用E-Mail：salanhess@126.com同联系Rup的阶段图如下： 图1 图2 图1以二维的形式说明 RUP 的整个体系架构。水平轴代表时间并显示了过程生命周期的各个方面。生命周期阶段的管理视图在顶部，迭代的软件工程和项目管理视图在底部。垂直轴代表按照逻辑分组的规程，表示过程的静态方面 —— 如何用过程部件、规程、活动、工作流，工件和任务来描述 RUP。 图2解释：从管理观点出发，RUP 软件生命周期包括四个顺序的阶段，每个阶段都以一个主要的里程碑结束。进行评估以确定是否达到阶段的目标。令人满意的评估结果可以使项目向下一个阶段进行。简要地说，RUP 生命周期的阶段是： Inception）： 初始阶段的目标是在所有涉众之间达成关于项目的生命周期目标的协议。在项目进行之前必须确定重要业务和需求风险化Elaboration）：化阶段的目标是为系统体系架构设定基础。该体系架构进化了对最重要的需求（哪些需求对系统的体系架构有很大的影响）的考虑和对风险的评估。生命周期体系架构里程碑为系统的体系架构建立了一个受控的基线，并令项目团队在构构建段进行。 构建Construction）：构建阶段的目标是澄清剩余的需求并完成基于基本体系架构的系统的开发。在此阶段要强调对资源的管理和对操作的控制，用来优化成本、进度和质量。 产品化Transition）： 产品化阶段的重点是确保软件对最终用户是可用的。产品化阶段可以跨越若干次迭代，该阶段包括为发布而进行的产品测试，以及根据用户反馈做出较小调整。在生命周期的这个阶段，用户的反馈应主要用于对产品进行微调、配置、安装和解决可用性问题，在项目生命周期的更早期就应该解决所有的主要结构问题 注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：工件是项目期间生成并使用的最终或中间产物。工件用于获取和传达项目信息。工件可以是需求工作流程的目的： 与客户和其他涉众在系统的工作内容方面达成并保持一致。 使系统开发人员能够更清楚地了解系统需求。 定义系统边界（限定）。 为计划迭代的技术内容提供基础。 为估算开发系