软件测试与维护期末复习——Chapter 2 Testing in the Software Process

1. 瀑布模型

一切的起点

1. 特点

   1. 纯串行流程，各个阶段之间没有任何重叠

   2. 需求→分析→程序设计→编码→测试→运维

   3. 所有规划都在一开始完成,一旦创建就不能更改

2. 优点

   1. 前期完善需求和设计可减少大量后期返工的时间和精力

   2. 重视文档，文档完整，新人易上手

3. 缺点

   1. 项目结束前几乎看不到进展

   2. 对变更不够灵活

   3. 写文档很耗时

   4. 测试仅在最后进行——意味着测试可能不充分（时间或预算限制）

   5. 程序需要作为整体来测试，测试不充分

   6. 如果测试发现需要重新设计的问题，很可能因为修改成本太高而被忽略

   7. 如果客户不满意，后续维护阶段需要花大量时间解决问题

2. V模型

瀑布模型的升级：测试和开发同步规划，提前写测试用例

1. 特点

   1. 通过标记开发过程中每个阶段与测试活动的关系，来强调验证与确认

   2. 每份文档的产生与V模型成对的阶段对应

      1. URS：User Requirements Specification. 用户需求规范

      2. SRS：System Requirements Specification. 系统需求规范

      3. SDS：System Design Specifications. 系统设计规范

      4. DDS：Detailed Design Specifications. 详细设计规范

2. 优点

   1. 简单易管理（瀑布模型的刚性/线性结构）

   2. 阶段交付物明确，有评审流程（瀑布模型）

   3. 强调全阶段的验证和确认（开发时每阶段验证，测试时每阶段确认）

   4. 测试和开发同等重要（一开始就规划测试，而不是作为最后补充）

3. 缺点

   1. 和瀑布模型一样，直到项目后期才有可运行软件

   2. 不适合需求易变的项目

   3. 不适合大型、复杂、面向对象项目

3. W模型

V模型的升级：开发和测试并行执行

1. 开发流程：编写需求 → 定义系统 → 设计系统 → 编写代码 → 构建软件 → 构建系统 → 安装系统

2. 测试流程：测试需求 → 测试规范 → 测试设计 → 单元测试 → 集成测试 → 系统测试 → 验收测试

3. 特点

   1. V 模型的扩展，由两个 V 组成，所以叫 W 模型

   2. 测试不是在代码实现之后才进行

   3. 测试流程与开发流程并行执行

   4. 开发与测试之间需要协作

   5. 测试不只是测试用例的编写、执行和评估（需求评审、设计评审、文档验证等全流程工作，而不只是执行用例）

4. 螺旋模型（Spiral Model）

瀑布模型的升级，属于迭代开发：风险分散；用户反馈早；需求可调整；每一轮风险分析

1. 特点

   1. 风险驱动的开发过程

   2. 瀑布模型与快速原型迭代模型的结合

   3. 每一轮迭代以设计目标为起点，以客户审查结束（相当于走了一遍瀑布流程）

      1. 确定目标

      2. 识别风险

      3. 开发与测试

      4. 规划下一轮迭代

2. 优点

   1. 支持后期变更

   2. 成本估算简单（成本按小片段估算）

   3. 风险管理能力强（持续的风险分析和迭代开发）

   4. 开发快速（每一圈都快速出一个可运行版本）

   5. 客户反馈顺畅

3. 缺点

   1. 进度和预算风险（迭代周期失控）

   2. 严格遵守螺旋模型步骤

   3. 文档多（中间步骤多，每一轮迭代相当于走了一遍瀑布流程）

   4. 仅适合大型项目，需要专业的风险评估能力

   5. 不适合小型项目

5. 增量开发（Incremental Development）

瀑布模型的升级：风险分散；用户反馈早；需求可调整

1. 特点

   1. 每一轮迭代都会新增功能或增强现有功能，逐步进化为最终版本

   2. 测试在每轮迭代结束后进行

   3. 大部分测试都是回归测试（代码修改后重新运行之前的测试用例），测试用例和测试数据可大量复用

2. 优点

   1. 风险分散，易变更

   2. 客户参与早，需求匹配高

3. 缺点

   1. 文档不足，管理难度大

   2. 持续变更导致维护逐渐困难

6. 敏捷模型（Agile Model）

增量开发的升级：更短、更快、更协作

1. 特点

   1. 强调短时间内构建可发布软件

   2. 以周为单位开发（别的模型是按月），且高度协作

2. 要求

   1. 测试人员全程参与需求沟通

   2. 需求确定后，立刻转化为测试用例

   3. 需求变更时，测试人员第一时间修改测试用例

7. 极限编程（Extreme Programming，XP）

敏捷模型的极致

1. 特点

   1. 强调代码评审、持续集成、自动化测试和极短迭代

   2. 推崇持续完善或重构，而非前期一次性大设计，保持当前实现简单

   3. 优先实时沟通（面对面），而非写文档

   4. 强调团队协作

   5. 程序员对自己的代码负责测试，测试人员聚焦用户验收

2. 价值（CSFC）

   1. 沟通（Communication）

   2. 简单（Simplicity）

   3. 反馈（Feedback）

   4. 勇气（Courage）

8. 测试驱动开发（TDD）

1. 流程闭环

   为新功能写测试→编译→修复编译错误→运行测试并失败→编写最小代码→运行测试并通过→按需重构→保持所有测试通过

   • 为新功能写测试：先写测试代码，调用还不存在的类 / 方法

   • 编译：因为类 / 方法还没定义，直接编译失败

   • 修复编译错误：补全类 / 方法名，不实现功能

   • 运行测试并失败：没有代码实现所以会失败

   • 按需重构：优化实现

2. 优点：

   1. 单元测试一定会被写出来

   2. 接口和行为设计更清晰

   3. 开发者满意度高，测试编写更一致

   4. 可验证、可重复、自动化的验证

   5. 让你有信心修改代码

   6. 提升代码质量，降低bug率