软件测试与维护.md 3.6 KB


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]]

相关页面

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