首页/开发/软件测试速查/可测试性(Testability)
测试基础与分层67 条

可测试性(Testability)

系统支持被测试的难易程度:可观测性、可控制性、接口清晰度与状态可重置能力;可测试性差会让自动化与定位成本成倍上升。

软件测试速查开发更新于 2026-10-13

可测试性是什么

可测试性(Testability)指系统支持被测试的难易程度:可观测性、可控制性、接口清晰度与状态可重置能力。可测试性差,自动化与定位成本成倍上升:拿不到日志、换不掉依赖、重置不了状态,测试只能靠猜,缺陷修复周期被无限拉长。

基本信息

可观测日志、指标、链路追踪覆盖关键路径
可控制依赖可替换、时间与随机源可注入、状态可重置
接口清晰稳定的标识与选择器、明确的错误结构
可诊断失败时能拿到请求上下文与快照
评审输入把可测试性写成设计评审检查项

典型使用场景

  • 设计评审:新模块评审时逐条核对四项能力。
  • 自动化前置:接口契约与测试标记就绪后再写用例。
  • 故障演练:依赖注入点与降级开关可被测试控制。
  • 排错提速:失败时日志与快照已包含关键上下文。
  • 环境重置:一键回到初始状态,回归不需要人工清库。
  • 指标建设:把「可测试性缺口」纳入技术债清单跟踪。

四项能力检查表

能力检查问题典型抓手
可观测失败时能否看到上下文结构化日志、追踪 ID
可控制依赖能否替换与注入接口抽象、测试模式
清晰接口标识与错误结构是否稳定测试标记、错误码
可重置状态能否一键复位测试辅助接口、夹具
在设计评审阶段提出可测试性需求(如测试专用标记或日志字段),比事后补测更省成本。
可测试性是可演进指标:每个迭代补一点(加日志字段、加注入点),比大改造现实。
生产代码为测试开捷径接口且无访问控制,会把测试便利变成安全漏洞。
评审可直接复用本页的四项能力表格:每个新模块逐格打勾,缺口登记为待办。

易错点

  • 把可测试性当作测试团队内部问题,缺少设计阶段输入
  • 生产代码为测试开捷径接口且无访问控制,引入新风险
  • 依赖无法替换,集成测试被迫连真实第三方,慢且不稳定
  • 状态无法重置,用例之间互相污染,失败难以复现
  • 错误信息笼统(如「操作失败」),线上定位只能靠猜

数据来源与参考

  • Google Testing Blog(可测试性相关文章)
  • ISTQB CTFL 4.0 大纲
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌