测试计划在国内其实不是很流行。之前在外企工作的时候，每一次的测试工作基本上都是以编写测试计划开始的。好的测试计划可以让团队成员对测试整体进行和测试策略以及方法有一个大体的认识，在一定程度上可以节约沟通成本。最近正好在github上看到一份测试计划文档，我们就一起来学习一下其中的精华吧。项目地址：https://github.com/fityanos/awesome-quality-assurance-roadmap#test-plan-sample

1 介绍

1.1 项目介绍

介绍项目上下文

1.2 读者

描述一下读者人群，比如来自A团队的alice以及来自B团队的bob

2 测试策略

2.1 测试目标

比如完整的回归测试，还是增量的功能验证等；

2.2 测试假定

假设某些东西不需要考虑或者满足某些条件，比如测试环境上可能没有配置负载均衡，这时就可以假定大家都理解这个点，并可以进行适当的忽略

2.3 测试原则

比如所有bug必须fix之类的原则性的东西

2.4 测试范围和级别

这里可以定义测试的范围，该做的就做，不该做的就先约定清楚。比如可以定义

  • 功能测试范围和时间以及交付物
  • 性能测试范围和时间以及交付物
  • 回归测试范围和时间以及交付物
  • UAT测试的范围和时间以及交付物

2.5 LOE(level of effort)

%E5%A6%82%E4%BD%95%E7%BC%96%E5%86%99%E6%B5%8B%E8%AF%95%E8%AE%A1%E5%88%92%20fb24f300af014335945a795002909ca8/Untitled.png

这里就是工作量的分解了，越清晰越好。

3 执行策略

3.1 开始和退出条件

比如功能测试的开始条件是产品体验通过和开发自测通过，结束的条件是所有的bug都被fix

3.2 测试轮次

  • 第一轮
  • 第二轮
  • ……

对于敏捷测试团队来说，其实可以忽略测试轮次的概念。对于瀑布流开发团队来说则需要定义清楚，因为每一轮的时间都很宝贵。

3.3 测试指标

%E5%A6%82%E4%BD%95%E7%BC%96%E5%86%99%E6%B5%8B%E8%AF%95%E8%AE%A1%E5%88%92%20fb24f300af014335945a795002909ca8/Untitled%201.png

这里实际上定义的是测试报告的类型的频率，比如测试执行进度的汇报频率是每天，而测试覆盖率的汇报频率可以低一些，比如每个迭代汇总一次。

3.4 缺陷的追踪及报告

这里定义bug的生命周期。

%E5%A6%82%E4%BD%95%E7%BC%96%E5%86%99%E6%B5%8B%E8%AF%95%E8%AE%A1%E5%88%92%20fb24f300af014335945a795002909ca8/Untitled%202.png

4 测试管理流程

4.1 测试设计流程

4.2 用例执行流程

4.3 测试风险以及依赖方

这里需要提前考虑清楚测试风险以及依赖方，最重要的是需要找到back up，先把退路想好。

%E5%A6%82%E4%BD%95%E7%BC%96%E5%86%99%E6%B5%8B%E8%AF%95%E8%AE%A1%E5%88%92%20fb24f300af014335945a795002909ca8/Untitled%203.png

4.4 团队成员及角色

5 测试环境

这里可以描述测试环境的详细信息，比如测试环境的配置以及数据库情况，staging环境的相关情况，因为staging可能用的是线上正式库。

6 排期和交付

%E5%A6%82%E4%BD%95%E7%BC%96%E5%86%99%E6%B5%8B%E8%AF%95%E8%AE%A1%E5%88%92%20fb24f300af014335945a795002909ca8/Untitled%204.png

项目过程中每个测试阶段的排期和交付物在这里定义，也是整篇文档最重要的部分。