---
title: 软件测试与维护
tags:
  - module
  - software-engineering
  - testing
  - maintenance
  - joplin
type: module
source_type: reconstructed
created: 2026-04-23
updated: 2026-04-23
---

# 软件测试与维护

> [!abstract]
> 这一模块关注软件交付前后的质量保证工作。测试负责尽早发现问题，维护负责让软件在真实环境中持续可用。

## 模块结论

- [[软件测试]] 的目标不是证明程序“没问题”，而是系统性发现缺陷并验证需求满足程度。
- 测试通常按单元、集成、系统、验收分层推进，黑盒和白盒是两种基本观察视角。
- [[软件维护]] 不只是修 bug，还包括适配环境、完善功能和预防性优化。
- 维护成本高，反过来说明前期设计、文档、测试做得是否扎实。

## 一、软件测试在做什么

- 通过执行程序或分析逻辑发现缺陷。
- 检查功能、性能、稳定性和需求符合性。
- 为发布和后续维护提供质量依据。

## 二、测试层级

### 单元测试

- 目标：验证单个模块或函数是否正确。
- 常与白盒测试配合。

### 集成测试

- 目标：验证模块接口和协作关系。
- 常见策略：自顶向下、自底向上。

### 系统测试

- 目标：站在整体系统角度验证功能和性能。
- 更强调真实使用场景。

### 验收测试

- 目标：由用户或代表用户的角色判断系统是否满足需求。
- 常见形式：Alpha、Beta。

## 三、测试方法

### 黑盒测试

- 关注输入和输出，不依赖内部代码结构。
- 常见方法：等价类划分、边界值分析。

### 白盒测试

- 关注内部逻辑结构和控制路径。
- 常见指标：语句覆盖、条件覆盖、路径覆盖。

### 灰盒测试

- 介于两者之间，既关注部分内部结构，也关注外部行为。

## 四、测试工具与自动化

- 单元测试工具：JUnit、PyTest。
- 接口与功能测试工具：Postman、Selenium。
- 性能测试工具：JMeter。
- 持续集成工具：Jenkins 等。

### 自动化的意义

- 减少回归测试成本。
- 在需求迭代频繁时保持质量基线。
- 让测试成为开发流程的一部分，而不是项目尾声的补救动作。

## 五、软件维护

### 维护四分类

- 改正性维护：修复已发现缺陷。
- 适应性维护：适配新环境或新平台。
- 完善性维护：扩展功能或优化性能。
- 预防性维护：重构、补文档、改善结构以降低未来风险。

### 为什么维护成本高

- 软件长期处在变化环境中。
- 真实业务需求会持续演化。
- 历史设计缺陷和文档不足会放大每次修改成本。

## 六、降低维护成本的做法

- 采用模块化设计和清晰接口。
- 保持文档与代码同步。
- 建立自动化回归测试。
- 在关键阶段做重构，而不是无限堆补丁。

## 七、易错点

- 测试的目标是发现问题，不是证明软件绝对正确。
- 黑盒和白盒不是互斥替代关系，而是不同层面的补充。
- 维护四分类不是只在理论里区分，项目中往往会直接决定资源分配。

## 八、复习提问

- 单元测试、集成测试、系统测试分别关注什么边界？
- 路径覆盖为什么比语句覆盖更严格？
- 为什么说维护阶段反过来检验了前期工程质量？

## 来源

- [[raw/Joplin/计算机专业基础/软件工程/_软件工程考研复试终极整理版.md]]
- [[raw/Joplin/计算机专业基础/软件工程/4.软件工程——软件测试与维护.md]]

## 相关页面

- [[软件工程]]
- [[软件工程关键过程与设计]]
- [[软件测试]]
- [[软件维护]]