第5章 软件工程 / 5.4
5.4 软件实现
一句话讲明白
设计图画完就该"真刀真枪干"了：用配置管理管住版本和变更、按规范写出代码、再用各种测试把 Bug 挖出来。
生活类比
拍一部电影：
- 配置管理 = 素材库管理（哪一版剧本、哪一条镜头、谁改的、能不能回退到昨天的版本）。
- 编码 = 正式拍摄，摄影、灯光、表演都得按规范来，不然后期没法剪。
- 测试 = 粗剪（看单个镜头过不过关=单元测试）、合剪（镜头接得上吗=集成测试）、审片（和剧本对不对得上=确认测试）、试映（真在影院放一遍=系统测试）；改完一段还得重看一遍有没有剪坏别处（回归测试）。
正经定义
软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求，或者弄清预期结果与实际结果之间的差别。按 GB/T 15532《计算机软件测试规范》，测试目的是验证软件是否满足开发合同、项目开发计划、系统设计文档、SRS、软件设计说明和软件产品说明等规定的质量要求。
拆解与流程
一、软件配置管理 SCM
一种标识、组织和控制修改的技术，应用于整个软件工程过程。目标：标识变更、控制变更、确保变更正确实现、向其他人员报告变更。
核心内容两项：
- 版本控制：追踪文件变更（何时、何人、改了什么），每次变更版本号增加；另一重要功能是并行开发（分支与合并解决不同版本的 Bug 修复问题）。
- 变更控制：目的不是阻止变更，而是对变更进行管理、确保变更有序进行。变更来源分外部（客户改范围/需求）和内部（修 Bug、改设计），最难处理的是外部需求变更，尤其在项目后期。
SCM 六项活动：软件配置管理计划 → 软件配置标识（识别配置项并建立基线）→ 软件配置控制 → 软件配置状态记录 → 软件配置审计 → 软件发布管理与交付。
二、软件编码
- 程序设计语言：编码前的重要工作是选择恰当的程序设计语言，它会影响人的思维方式、通信质量和他人阅读理解程序。
- 程序设计风格 4 个方面：源程序文档化、数据说明、语句结构、输入/输出方法（让别人也看得懂）。
- 程序复杂性度量：定量度量复杂程度可估算故障数量与开发工作量，并作为模块规模的精确限度。
- 编码效率：程序效率、算法效率、存储效率、I/O 效率（面向人的 I/O 与面向设备的 I/O）。
三、软件测试方法
| 静态测试 | 动态测试 | |
|---|---|---|
| 是否运行程序 | 不运行 | 实际运行 |
| 怎么做 | 分析检查需求规格说明书、设计说明书、源程序的结构与流程 | 比较运行结果与预期结果，分析运行效率和健壮性 |
| 具体手段 | 文档用检查单；代码用桌前检查、代码走查、代码审查 | 白盒测试、黑盒测试 |
| 效果 | 能发现 30%~70% 的逻辑设计和编码错误 | — |
- 白盒测试（结构测试）：把程序看作透明的白盒，清楚内部结构，按内部逻辑设计用例，主要用于单元测试；最常用技术是逻辑覆盖——语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖、路径覆盖。
- 黑盒测试（功能测试）：把程序看作不透明的黑盒，不管内部结构，依据 SRS 设计用例。方法包括：等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法、正交试验法。
四、测试类型（GB/T 15532，按层级递进）
flowchart LR
A[单元测试<br/>依据:详细设计说明书] --> B[集成测试<br/>依据:概要设计文档] --> C[配置项测试<br/>依据:SRS] --> D[系统测试<br/>依据:系统设计文档/合同]
B --> E[确认测试<br/>验证与用户需求一致]
D --> F[回归测试<br/>变更后不损坏原有功能]
| 类型 | 对象/目的 | 关键点 |
|---|---|---|
| 单元测试 | 对模块（可独立编译的程序模块、构件或 OO 中的类）测试，检查是否实现设计说明的功能、性能、接口和约束 | 从模块接口、局部数据结构、重要执行通路、出错处理通路、边界条件入手 |
| 集成测试 | 组装起来的模块，发现与接口有关的问题 | 白盒+黑盒结合；前提是各模块已通过单元测试 |
| 确认测试 | 验证软件功能、性能和其他特性是否与用户需求一致 | 即常说的验收确认 |
| 系统测试 | 完整的、集成的计算机系统，在真实环境下检测完整配置项能否与系统正确连接 | 含功能测试、性能测试、健壮性、安装/反安装、用户界面、压力、可靠性及安全性测试；最重要是功能测试和性能测试；结束标志是满足需求覆盖率且缺陷归零 |
| 配置项测试 | 检验软件配置项与 SRS 的一致性 | 前提是已通过单元和集成测试 |
| 回归测试 | 测试变更后变更部分的正确性、符合性，以及原有正确功能不被损坏 | 系统测试阶段需求频繁变更时要进行多轮回归测试 |
- 面向对象测试：OO 系统三特征封装性、继承性、多态性给测试带来困难（信息隐蔽、继承影响测试充分性、动态绑定等）。
- 软件调试（排错）：测试成功=发现了错误；调试策略分蛮力法、回溯法、原因排除法。
考试怎么考
- 题型：选择题必考；案例题高频——"说明该项目在配置管理和测试方面的问题"。
- 必背数字：静态测试可发现 30%~70% 的逻辑设计和编码错误。
- 常见问法：
- "依据软件详细设计说明书开展的测试是？" → 单元测试
- "集成测试的技术依据是？" → 软件概要设计文档
- "验证软件与用户需求是否一致的是？" → 确认测试
- "软件修改后，为验证原有功能未受影响而进行的测试是？" → 回归测试
- "属于黑盒测试方法的是？" → 等价类划分/边界值分析/因果图；路径覆盖、条件覆盖是白盒
- 陷阱词：把版本控制说成配置管理全部（还有变更控制）；把"变更控制的目的是阻止变更"说对（错，是管理变更）。
易混辨析
| 对比 | 静态测试 | 动态测试 |
|---|---|---|
| 运行程序 | 否 | 是 |
| 手段 | 检查单、桌前检查、代码走查、代码审查 | 白盒（看内部）、黑盒（看功能） |
| 对比 | 黑盒测试 | 白盒测试 |
|---|---|---|
| 视角 | 不透明，只看功能 | 透明，看程序结构和逻辑 |
| 典型方法 | 等价类划分、边界值分析 | 逻辑覆盖（语句/判定/条件/路径） |
| 主战场 | 系统测试、确认测试 | 单元测试 |
一秒记忆
"配置管两头：版本加变更；测试两大类：静看不动（30~70% 错误），动看白黑；层级单→集→配→系，确认对需求，回归防改坏。"