首页/开发/软件测试速查/基于检查表的测试(Checklist-Based)
用例设计方法62 条

基于检查表的测试(Checklist-Based)

用维护好的检查表覆盖易错维度(权限、边界、并发、兼容性、日志等),逐项确认;适合快速评审与漏测补齐。

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

清单法是什么

基于检查表的测试把历史经验固化成可勾选清单:上线检查单、兼容性清单、输入校验清单、安全冒烟清单。它不产生新的用例设计,而是防止「老坑」重现——成本低、易执行,适合重复性场景。与检查表评审配合使用,效果最好。

基本信息

清单来源历史缺陷、事故复盘、规范条款、领域经验
典型清单发布检查、兼容性核对、权限矩阵、数据迁移
执行方式人工勾选、评审会走查、脚本抽查部分条目
维护节奏每次事故与复盘后补充条目,定期删过时项
局限覆盖不了新逻辑,不能替代用例设计方法
组合用法清单打底防遗漏,探索测试补充新风险

常见清单类型

清单典型条目适用时机
发布检查备份、回滚、监控、公告每次上线前
兼容性分辨率、内核、字体、缩放前端发版前
安全基线越权、注入、敏感字段输出对外接口发布前
迁移对账条数核对、抽样比对、回滚预案数据迁移前后

典型使用场景

  • 上线发布前逐项核对,防人为遗漏
  • 多环境部署一致性抽查
  • 权限与安全基线走查:越权与敏感信息是重灾区
  • 数据迁移对账:条数与抽样双核对
  • 回归防漏:把曾经漏测过的点全部列回清单
  • 新人交接:清单是成本最低的业务与风险常识载体
条目必须可判定:把「检查性能」改成「p95 低于 300 毫秒」这类可验证表述,否则勾选全靠感觉。
清单要瘦身:条目越加越多,执行越敷衍。定期评审删除过时项,保持单页可完成。
勾选留痕:谁执行、什么时候、结果如何,无记录的清单无法追责也无从改进。

易错点

  • 清单常年不更新:新踩的坑不进单,防的永远是老问题
  • 把检查表当唯一测试手段:覆盖停在已知区域,新逻辑完全没测
  • 条目不可判定:「加强关注」这类表述让执行者无法操作,最终走过场
  • 只挂墙不执行:没有签字与记录,出了事故才发现清单从没被用过
  • 清单散落在多个文档:版本不一致,有人照旧版执行,检查结果互相矛盾

数据来源与参考

  • ISTQB CTFL 4.0 大纲(检查表相关技术)
  • 行业测试实践
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌