需求分析与系统 设计
系统测试
概要设计
集成测试
详细设计
单元测试
编码
W模型
W模型由Evolutif公司提出，强调测试活动伴随着整个软件开发 周期，而且测试对象不仅仅是程序，需求、设计等活动同样需 要测试，也就是说，测试与开发是同步进行的。
W模型可以说是V模型的自然而然的发展。W模型体现了“及早 的和不断的进行软件测试”原则，能够帮助改进项目的内部质 量，减少总体测试时间，加快项目进度，降低测试和修改成本。
X模型也是对V模型和W
模型的改进。X模型提
出针对单独的程序片段
进行相互分离的编码和
封版 测试，此后通过频繁的
程序片段1 测试设计
X模型是事先计划再进行测试
执行测试 交接，通过集成最终合 成为可执行的程序。
工具配置
测试设计
X模型左边描述的是对
执行测试
工具配置
单独程序片段所进行的
编码完成
集成1～n
分离的编码和测试，此
敏捷开发过程模型 TDD
敏捷开发是一种以人为核心、迭代、循序 渐进的开发方法。在敏捷开发中，软件项 目的构建被切分成多个子项目，各个子项 目的成果都经过测试，具备集成和可运行 的特征。换言之，就是把一个大项目分为 多个相互联系，但也可独立运行的小项目， 并分别完成，在此过程中软件一直处于可 使用状态。
第三方测试也叫做独立测试，是指介于软件开发 者和软件用户之间的测试组织对软件进行的测试。
测试用例
从测试目的的角度来看，为达到最佳的 测试效果或高效的揭露隐藏的错误，而 精心设计并执行的少量测试数据，称之 为测试用例。
测试用例最基本由输入和预期输出组成。
软件开发过程模型
软件工程的核心就是过程，软件产品、人 员、技术通过过程关联起来。软件工程过 程能够将软件生命周期内涉及的各种要素 集成在一起，从而使软件的开发能够以一 种合理而有序的方式进行。
软件测试的定义
概括说来，软件测试是为了发现错误而 执行程序的过程。或者说，软件测试是 根据软件开发各阶段的规格说明和程序 的内部结构，而精心设计一批测试用例， 并利用这些测试用例去执行程序，以发 现程序错误的过程。
软件测试的对象包括：源程序、目标程 序、数据及相关文档。
实际的测试过程中无法做到穷举测试。
该模型的主要特点是：
◦ 最适用于很小且很简单的项目。编码修正模型是从一个大致 想法开始工作，然后经过非正规的设计、编码、调试和测试 过程，最后完成工作。
◦ 成本可能很低，经过少量设计就进入编码阶段。 ◦ 易于使用，人员只需要很少的专业知识，写过程序的人都可
以用。 ◦ 对于一些非常小的、开发完成后就会很快丢弃的软件可以采
最优方案； ◦ 开发本次迭代可供交付的内容； ◦ 评估完成情况，规划下一个迭代过
程； ◦ 交付给下一步，开始新的迭代过程。
RUP模型
RUP吸取了已有模型的优点， 克服了瀑布模型过分强调序 列化和螺旋模型过于抽象的 不足，总结了多年来软件开 发的最佳经验：
◦ 迭代开发，提前认知风险。 ◦ 需求管理，及早达成共识。 ◦ 基于构建，搭建弹性框架。 ◦ 可视化建模，打破沟通壁垒。 ◦ 持续验证质量，降低缺陷代价。 ◦ 管理变更，有序积累资产。
需求 构造增量1
需求 构造增量2
演化模型是显式地把增量模型扩展到需求 阶段。为了第二个构造增量，使用了第一 个构造增量来精化需求。这一精化可以有 多个来源和路径。
演化模型的长处和不足与增量模型类似。 优点有：
◦ 在需求不能予以规范时，可以使用这一演化模 型；
◦ 用户可以通过运行系统的实践，对需求进行改 进；
所有的模型都具有如下基本特征：
◦ 描述了开发的主要阶段； ◦ 定义了每一个阶段要完成的主要过程和活动； ◦ 规范了每一个阶段的输入和输出； ◦ 提供了一个框架，可以把必要的活动映射到该
框架中。
编码修正模型（边做边改）
编码 测试
编码修正模型是所有模型中最古老也是最简单的模型， 该模型将软件开发过程分为编码和测试两项活动。
该模型的主要特点是：
◦ 每一阶段都以验证/确认活动作为结束，其目的是尽可能多地消除 本阶段产品中存在的问题；
确认 ◦ 在随后的阶段里，尽可能对前面阶段的产品进行迭代。
设计
验证
编码 单元测试
测试 验收测试
运维 重新确认
需求
增量模型
构造增量1
构造增量2
增量模型是由瀑布模型演变而来的第一个模型， 它是对瀑布模型的精化。该模型有一个假设， 即需求可以分段，成为一系列增量产品，对每 一增量可以分别地开发。
◦ 单元测试、集成测试、系统测试和验收测 试。
软件测试的分类
按是否需要执行被测试软件
◦ 静态测试
静态测试又称静态分析，是不实际运行被测软件，而 是直接分析软件的形式和结构，查找缺陷。主要包括 对源代码、程序界面和各类文档及中间产品（如产品 说明书、技术设计文档等）所做的测试。
◦ 动态测试
动态测试又称动态分析，是指需要实际运行被测软件， 通过观察程序运行时所表现出来的状态、行为等发现 软件缺陷，包括在程序运行时，通过有效的测试用例 （对应的输入、输出关系）来分析被测程序的运行情 况或进行跟踪对比，发现程序所表现的行为与设计规 格或客户需求不一致的地方。
黑盒测试设计方法
◦ 侧重于测试软件的功能需求，主要试图发现几类 错误：功能不对或遗漏、界面错误、数据结构或 外部数据访问错误、性能问题、初始化和终止错 误。
黑盒测试方法
等价类划分法
◦ 设计测试用例的步骤
对每个输入和外部条件进行等价类划分，画出等 价类表，并为每个等价类进行编号。
设计一个测试用例，使其尽可能多地覆盖有效等 价类，重复这一步，直到所有的有效等价类被覆 盖。
执行测试 工具配置
探索性测试
后将通过频繁的交接， 最终集成为一个可执行
测试设计
执行测试 的程序
程序片段n
黑盒测试基本概念
黑盒测试基本概念
◦ 只知道系统输入和预期输出，不需要了解程序内 部结构和内部特性的测试方法称为黑盒测试。
◦ 黑盒测试又叫功能测试，它主要关注被测软件功 能的实现，而不是其内部逻辑。
敏捷的最低要求应该是使得项目具备以下 基本条件：
◦ 可追溯性、可理解性、可验证量性、其他“开 发时质量要求”
测试过程模型
随着计算机的普及和计算机应用的飞速 发展，软件数量和复杂度不断增加，导 致软件开发过程越来越难以控制。
软件测试过程模型是对软件测试过程的 一种抽象，用于定义和描述软件测试的 流程和方法。软件测试过程模型的发展 伴随着人们对软件工程理解和软件测试 理解的深入和发展。
H模型体现了测试活动的独立性，它存在于整 个软件生命周期并与其他流程并发进行，体现 了“及早的和不断的进行软件测试”原则。不 同的测试活动可以按照某个次序先后进行，也 可以支持反复和迭代过程。只要某个测试达到 测试就绪点，测试执行活动就可以进行。
测试准备
测试就绪点 测试执行
测试流程
其他流程
X模型
黑盒测试方法
边界值分析法-健壮性测试
◦ 健壮性测试是边界值分析的一种简单扩展，除了 使用5个边界值分析取值，还要通过采用1个略小 于最小值和1个略大于最大值的取值。 1个n变量函 x2数的健壮性边界值有6n+1个测试用例。
d
◦
min-
◦
max+
c
a
b
x1
健壮性边界值测试用例示意图
因果图法的定义：
增量模型作为瀑布模型的一个变体，具有瀑布 模型的所有优点，此外，还有以下优点：
◦ 第一个可交付版本所需要的成本和时间较少。 ◦ 开发由增量表示的小系统所承担的风险不大。
◦ 由于很快发布了第一个版本，因此可以减少用户 需求的变更。
◦ 允许增量投资，即在项目开始时，可以仅对一个 或两个增量投资。
演化模型
场景法
◦ 用例场景是通过描述流经用例的路径来确 定的过程，这个流经过程要从用例开始到 结束遍历其中所有的基本流和备选流。
V模型
V模型是最有代表性的软件测试过程模型， 最早由Paul Rook在20世纪80年代提出。
在V模型中，单元测试和集成测试验证程序的设计，检测程序的执行 是否满足软件设计的要求；系统测试验证系统设计，验证系统功能、 性能的质量特性是否达到系统设计的指标；验收测试验证软件需求， 确定软件的实现是否满足用户需求或合同的要求。但是，V模型没有 明确说明早期的测试，不能体现“及早的和不断的进行软件测试”原 则动，才因能此发前现期。各开用户发需求阶段隐藏的错误，需要完成该阶段对应的测验试收测活试
用户需求
用户需求V&V验收测试 准备
需求分析与系统 设计
需求分析与系统设计 V&V系统测试准备
概要设计
概要设计V&V集成测试 准备
详细设计
详细设计V&V单元测试 准备
编码
交付
验收测试
实施
系统测试
集成
集成测试
单元测试
H模型
H模型，它将测试活动完全独立出来，形成一 个独立的流程，将测试准备活动和测试执行活 动清晰的体现出来。
输出
需求 输出
软件
事件
软件测试的分类
按测试执行时是否需要人工干预
◦ 手工测试
手工测试是完全由人工完成测试工作，包括测试 计划的制定，测试用例的设计和执行，以及测试 结果的检查和分析。传统的测试工作都是由人工 来完成的。
◦ 自动测试
自动测试指的是通过软件测试工具，按照测试人 员的预定计划对软件产品进行自动的测试。
用。 ◦ 对于规模稍大的项目，采用这种模型是很危险的，由于缺乏
预先的计划并且通常伴随着不正规的开发方式，容易导致代 码碎片，交付的产品质量也很难保证。且因为设计没有很好 的文档化，因此代码维护困难。