第02章 rup软件测试基础

3.1 传统软件测试的问题

传统的软件测试流程：
单元设计单元测试→集中进行大量的测试（功能和性能的集 成测试） →系统测试。
问题：
1.
项目进度难于控制，项目管理难度加大

如图3-1 所示，大量的软件错误往往只有到了项目后期，即系统
测试时才能够被发现。解决问题所花的时间很难预料，经常导致 项目进度无法控制，同时在整个软件开发过程中，项目管理人员 缺乏对软件质量状况的了解和控制，加大了项目管理难度。
案例分析：中兴软件外包测试流程

如果竞标成功，项目就要开始启动。中兴方会提供一份CRS(客户需求)和 SOW（工作任务书），中兴方派人过来进行需求培训，这时该项目的测 试组长也要参与到项目需求的培训和评审，也就是测试工作从需求开始介 入。 项目经理编写《项目计划》，开发人员产出《SRS》，这时测试组 长就要根据SOW 开始编写《测试计划》，其中包括人员，软件硬件资源 ，测试点，集成顺序，进度安排和风险识别等内容。

《测试计划》编写完成后需要进行评审，参与人员有项目经理，测试经理 和中兴方人员，测试组长需要根据评审意见修改《测试计划》，并上传， 由配置管理员管理。

待开发人员把《SRS》归纳好并打了基线，测试组长开始组织测试成 员编写《测试方案》，测试方案要求根据《SRS》上的每个需求点设 计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测 试方案》编写完成后也需要进行评审，评审人员包括项目经理，开发 人员，测试经理，测试组长，测试成员和中兴方；如果中兴方不在公 司，就需要测试组长把《测试方案》发送给中兴进行评审，并返回评 审结果。测试组长组织测试成员修改测试方案，直到中兴方评审通过 后才进入下个阶段――编写测试用例。
3.1 软件测试

针对传统软件测试容易导致项目进度难于控制、
风险控制能力较弱和由于测试较晚而导致开发费 用增加的问题，RUP 的软件测试提出了三大成功 经验：尽早测试、连续测试、自动化测试。
3.1.2 基于RUP 的软件测试成功经验
基于RUP 的软件测试技术提供了完整的软件测试流程和一整套的软 件自动化测试工具，使我们最终能够做到：一个测试团队，基于一 套完整的软件测试流程，使用一套完整的自动化软件测试工具，完 成全方位的软件质量验证。 1. 尽早测试 RUP 主要在以下三个方面为我们提供的尽早测试的软件工程技术： 首先，软件的整个测试生命周期是与软件的开发生命周期基本平 齐的过程，如图3-3 所示，即当需求分析基本明确后，我们就应该 基于需求分析的结果和整个项目计划来进行软件的测试计划； 伴随着分析设计过程，同时应该完成测试用例的设计； 当软件的第一个发布出来后，测试人员要马上基于它进行测试脚 本的实现，并基于测试计划中的测试目的执行测试用例，对测试结 果给出评估报告。 这样，便可以通过各种测试指标实时监控项目质量状况，提高对整个项 目的控制和管理能力。
负责执行。

执行测试则通过自动化测试工具或手工来执行那些自 动化或手工脚本，目的是确保整个系统按既定意图运 行。每一迭代都需要测试增加的功能，并重复执行以
前版本测试过的所有测试用例（回归测试）。该环节
由测试人员负责执行。

评估测试要对软件的质量和测试工作自身的质量做出 一个客观的评价，目的是生成并交付测试评估摘要。 该环节由测试设计员负责执行。
3.2.1 软件测试流程框架


RUP 对测试管理流程进行了完整的定义，通常有一个角色和一个行动，这 样会有一个固化的流程来帮助测试团队执行这个工作。RUP 通过这些来强 调测试的进度和质量，通常会事先规定需求覆盖率，测试用例实现率，然 后开发测试用例，看是否达到了覆盖率和实现率。最后是统计分析，比如 对缺陷分布进行分析。 RUP 测试流程框架如图3-6 所示，软件测试团队可以以它为基础，根据业 务发展的实际要求，定制符合团队使用的软件测试流程。
图3-1 传统测试流程中存在的问题
2.
对于项目风险的控制能力较弱
•
项目风险在项目开发较晚的时候才能够真正降低。往往是经 过系统测试之后，才能确定该设计是否能够满足系统功能、
性能和可靠性方面的需求。
3.
软件项目开发费用超出预算

错误发现的越晚，单位错误修复成本越高 。
图3-2 传统测试流程中存在的问题
第二章 RUP 测试概论
夏劲伟 徐州师范大学计算机科学与技术学院
问题：有关汽车生产过程质量

由某公司引入当时世界上最先进的生产线和工艺
流程生产的产品

由厂家技术精湛的师傅花了一个多月的时间用车 床加大锤手工精制而成。

排除其它购买因素，在汽车的质量上，您认为哪 款最好呢？
第一辆车的质量是由汽车生产的过程质量决定的。 而第二辆车的质量则依赖于师傅的资质背景。 软件产品的过程质量 保证规范的测试流程、测试规范、和其它配置管理环 节、版本的管理环节等。 结论：软件质量保证不应该只是在某一个环节上，而应该是 整个的流程，我们应该全面地去改进流程来保证质量。这 就是我们本章要讲的RUP 测试理念的核心。

这时测试人员就修改增加测试用例。待到开发修改完Bug 并转来新的测 试版本，测试部开始进行第二轮的系统测试，首先回归完问题单，再继 续进行测试，编写第二轮的测试报告，如此循环下去，直到系统测试结 束。在系统测试期间，测试人员还需要编写验收手册，验收用例和资料 测试用例等。
2.
3.
自动化测试 在整个软件的测试过程中要想实现尽早测试、连续测试，可 以说完善的测试流程是前提，自动化测试工具是保证。

为了使各种软件测试团队更好地进行测试，各大测试工具厂
商在借鉴RUP 的测试成功经验之外，还为我们提供了一整 套软件测试流程和自动化测试工具，使软件测试团队能够有
条不紊地完成整个测试任务。

测试需求

测试需求定义了“做什么”。这个概念比较简单，比如我们要对一个 哈希表的插入操作进行测试，我们首先要考虑做什么，会出现什么情 况，把所有的情况都考虑到，这样就得到所有的测试需求，如下：
1.
插入一个新的条目
2.
3. 4.
插入失败－条目已经存在 插入失败－表已满 哈希表在插入前为空


测试用例是选择满足这些测试需求的输入值 / 测试数据。一个简单的 测试用例可能会同时满足好几个测试需求。 为每一个测试需求设计一个单独的测试用例，就可以不必考虑那些复 杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有 所下降。 换句话说，测试需求并没有指出具体的数值或数据，而测试用例对被 插入元素进行描述。
《软件测试方法和应用》
1-28

测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测 试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证 用例的可执行和对需求的覆盖。测试用例包括测试项，用例级别，预 置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详 细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需 求点，这样才能保证客户需求不遗漏。同样，测试用例也需要通过开 发人员，测试人员和中兴方评审，测试组长也要组织测试人员对测试 用例进行修改，直到中兴方评审通过。
《软件测试方法和应用》
1-29

在编写测试用例阶段，开发人员基本完成代码的编写，同时完成单元 测试。中兴的外包项目一般是一次性集成，所以软件转测试部后直接 进行系统测试。测试部对刚转过来的测试版本进行预测试，如果软件 未实现CheckList 清单上的10％，测试部会把该版本打回。否则， 软件转测试部进行系统测试。根据《测试计划》进度安排，测试组长 进行多轮次的测试，每轮测试完成后，测试组长需要编写测试报告， 其中包括用例执行通过情况，缺陷分布情况，缺陷产生原因，测试中 的风险等等。

测试计划

测试计划表示预计要执行的测试的主要分组。它可包 含对关联的子测试用例记录的引用，或对进一步指定 相关测试区域的其他测试计划的引用。测试计划记录 提供项目中其他测试资产的组织结构。简单地说，测
试计划就是描述了要进行的测试活动的范围、方法、
资源和进度的文档。它确定测试项、被测特性、测试 任务、谁执行任务、各种可能的风险。测试计划可以 有效预防计划的风险，保障计划的顺利实施。
图3-4 测试阶段的划分
连续测试 连续测试是从迭代式软件开发模式中得来的。 过程：1）将整个项目的开发目标划分成为一些更易于完成和达 到的阶段性小目标。 2）制定迭代计划，而且每个迭代中都包括需求、设计、 编码、集成、测试等一系列的开发活动，都会增量式集成一 些新的系统功能。 3）通过每次迭代，我们都产生一个可运行的系统。 在迭代式软件开发的每个迭代周期，都会进行软件测试活动。 整个软件测试的完成，是通过每个迭代周期不断增量测试和回归 测试实现的。 意义：持续的提高软件质量、监控质量状态，使系统测试的 尽早实现成为可能。从而有效的控制开发风险、降低测试成 本，切实保证项目进度。
试类型，也可以为每种测试类型制定一个测试计划。两者都是可以采
用的方法。 该环节由测试设计员负责执行。
名词解释

测试用例

Байду номын сангаас


RUP 给出的定义是测试用例记录需要在受测试系统中进行验证的行为 单元。测试用例记录始终保持至少与一个测试计划记录相关。简单的 讲，为某个特殊目标而编制的一组测试输入、执行条件以及预期结果 ，以便测试某个程序路径或核实是否满足某个特定需求。这些特殊目 标可以是验证一个特定的程序路径或核实是否符合特定需求。因此测 试用例文档指对一项特定的软件产品进行测试任务的描述，体现测试 方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据 、测试步骤、预期结果、测试脚本等。 影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包 括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用 等等。因为有些因素是客观存在的，无法避免。 因此测试用例的设计和编制是软件测试活动中最重要的。

设计测试要设计测试用例和测试过程，保证测试用例完全覆盖测试 需求，目的是确定、描述和生成测试过程和测试用例。该环节同样 由测试设计员负责执行。

实施测试要根据测试用例实现具体的自动化脚本或手工操作步骤， 目的是实施设计测试中定义的测试过程。输出工件是测试过程的计 算机可读版本，称为测试脚本。测试脚本的生成可以在测试自动化 工具环境中或编程环境中完成。另外，还需要用适当的工具和方法 创建在执行测试脚本时所需要的外部数据集。该环节由测试设计员
图 3-6 RUP 软 件 测 试 流 程

在RUP 中对测试流程的描述为：软件测试工作要通过制定测 试计划、设计测试、实施测试、执行测试、评估测试几个阶 段来完成。每个测试环节的具体阐述如下：

制定测试计划需要整理测试需求，目的是确定和描述要实施和执行的
测试。这是通过生成包含测试需求和测试策略的测试计划来完成的。 可以制定一个单独的测试计划，用于描述所有要实施和执行的不同测

图3-3 软件测试生命周期
测试成本


发现问题越早，付出的代价越低。 通过迭代式软件开发把原来的整个软件开发生命周期分 成多个迭代周期，在每个迭代周期都进行测试，这样在 很大程度上提前了软件系统测试发生的时间，可以在很 大程度上降低项目风险和项目开发成本。 RUP 的尽早测试，还体现在它扩展了传统软件测试阶 段从单元测试、集成测试到系统测试、验收测试的划分 ，将整个软件的测试按阶段划分成开发员测试和系统测 试两个阶段，如图 3-4 所示，它把软件的测试扩展到整 个开发人员的工作过程。通过提前测试发生的时间来尽 早地提高软件质量、降低软件测试成本。
问题：自动化测试平台搭建和软件工具配置跟测试有 什么关系？

分析： 团队测试。 测试报告。（测试计划，测试用例，测试数据，测试报告
，测试中间产生的状态）

测试进度 测试管理需要测试平台
3.2RUP 软件测试流程

RUP 软件测试流程，不仅仅包含完整的软件测试
流程框架，同时还提供了内嵌软件测试流程的测 试管理工具的支持，包括完整的测试评测方法。

这样的过程是需求管理，可通过自动化测试工具把需求细 化到每一个用例，甚至一个需求用例对应好几个测试用例 ，包括测试分支或正反向分支等。经常会有这样的情况发
生，比如测试用户不同有不同的情况出现，需求和测试用
例对不上，客户发现测试人员没发现的问题。这个时候可 利用测试工具来进行循环测试，每一个迭代产生一部分版 本，由于更改可能带来新的Bug，因此要做回归测试。