本文主旨是想沉淀一下如何写测试计划。但是经过了一段时间翻阅资料，我发现网上大部分测试计划模板的内容多而杂，基本都是适用于传统项目的。刚好研究了一段时间如何给敏捷项目做测试计划，同时也在公司内成功进行了推广，把我目前所学所想沉淀下来。
敏捷项目的测试计划，首先要知道，什么是敏捷项目和敏捷测试？
敏捷项目
相对于传统项目少则三五个月，多则一年两年，最近几年火起来的敏捷项目，让团队成果产出的速度更快了起来。传统项目往往功能体系较为完整、庞大的系统，具备较为完善的文档，较为固定的流程，通常通过设立里程碑来标记一个阶段的完结。敏捷项目相对于传统项目更加灵活，周期短（一星期/半个月/一个月），更加注重高迭代、响应变化。
敏捷项目的特点：需求变化快、项目周期短。
敏捷测试
在敏捷项目的大前提下，我们可以知道，在短周期内要做极致详尽的测试计划（大家可以百度一下传统项目的测试计划模板）几乎是不可能的。所以敏捷测试相对于传统项目的测试，测试计划、测试用例等流程和内容上会有不同程度的简化。大家更注重与团队沟通，注重于高效产出。测试人员则是更实际的从需求阶段就参与到整个项目，在需求产出 到 发布上线 的阶段中，持续不断的对产品质量做出反馈。
测试人员对质量的反馈，贯穿整个项目周期。
写测试计划
什么是测试计划
测试计划是指导测试过程的纲领性文件。是为了达成一定时期内的目标，进行的任务规划和行动步骤设计。
为什么要做测试计划
当你身处一个项目中，请你尝试回答以下几个问题：
- 本项目的发布主题是什么？重要需求是哪些？
- 你有多少测试工时，能否在预期时间内保质完成测试任务？
- 项目内各测试人员的工作是否饱和， 分工是否均衡？
- 分工是否明确，是否有工作重复或遗漏？
- 是否有外部依赖？如何获取外部依赖的进度？
- 可能出现什么风险？有什么准备？
- 什么时候可以进行产品验收？
- 最终成果的测试质量标准是哪些？
我认为，一切能让你回答出这些问题的准备，都可以称之为“做测试计划”。
之前我经常见到这种情况：
- 发布时间是确定的，但测试完结时间就是发布时间，根本不知道质量过不过关。导致大家发布前匆匆忙忙测试，发布后匆匆忙忙处理线上故障；
- 发布的时候质量是否可靠，大家都不知道；
- 我们的新功能需要依赖外部团队的一个新接口，但新接口什么时候给出来？给不出来我们就一直等等等;
- 两个人一起参与测试，前期测试A忙忙忙，后期测试B忙忙忙，忙不忙的看运气;
- 开发前期提测功能少，快发布了，批量提测，导致测试忙不过来...
也有人抱怨：
需求安排下来，开发人员说能做完就排进来了，可测不完怎么办？
想让开发分批提测，让后期测试压力小一点，可是开发有自己的节奏怎么办？
针对以上问题，我只想说，我们要尽早分析我们可能遇到的问题，才能尽早的实施解决方案。而写测试计划的过程，就是一个分析我们可能遇到问题的最有效、最全面的方式。做完完整的测试计划，上面的问题都有了答案，你的所有抱怨，都可以有真凭实据。
什么时候做完测试计划
接上面的话，尽早分析我们可能遇到的问题，才能尽早的实施解决方案，所以，当你知道要进行测试的那一刻起，你的所有关注，都可能形成测试计划的一部分。因为测试计划文档，一定是要有一定的积累和设计后，才能形成一份完善的文档。
与此同时，测试计划受产品的需求、开发的设计、测试的分析、项目的周期、外部影响这几方面的影响，应该是一个初稿+不断完善的过程。随着项目推进，不断完善计划，收集反馈，如此往复。
所以我的项目中，我们的测试人员会在planning（计划会议，即大家在一起确认需求的开发和测试工时）结束后，开始写测试用例之前，完成测试计划初稿的撰写，让测试计划能够作用与之后的每一个阶段 ——有人会说，敏捷测试不是从需求开始，测试就在参与了吗，为什么测试准备阶段测试计划才开始生效？是的，需求阶段测试的参与，是在于对产品的理解，从测试的角度提出产品设计上的问题，这个阶段在敏捷测试中，可以归结与敏捷的测试体系和公司/团队文化，不需要在测试计划中单独体现。言归正传，在测试准备阶段之前完成的是测试计划的初稿，这个初稿中，允许有未确定的事项存在，正如上面所说，我们的测试计划是个初稿+不断完善的过程，在后面的每一个阶段，我们都可以继续完善或者变更初稿中的内容。这个现象跟敏捷宣言中的“响应变化”有异曲同工的感觉。
我们期望测试计划能带来什么？
假设我们已经有了一份详细的测试计划，
* 领导看到了你的测试计划，能够根据测试计划了解项目资源，进行宏观调控、相应资源配置等
* 测试人员：能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等
* 其他人员：了解测试人员的工作内容，能够知道在这个周期中，需要何时给你提供协助，进行有关配合工作
测试计划的内容
其实就是项目中需要参与测试的人员搞清楚的几个基础项。通过确立这些基础项，我们就能最大程度的剖析出我们的测试项目，有效克服测试的盲目性。
我们要做的就是把下面这些内容，整理为测试计划的要素。
- 明确测试资源
- 明确时间节点
- 明确需求内容
- 明确测试内容/测试范围
- 明确了开发的设计并讨论过测试方案
- 明确关键需求的策略
- 明确需要的协助
- 明确可预估的风险，并有相应的应对策略
- 明确时间估算和消耗
- 明确测试任务分配
- 明确输出内容
- 明确质量要求
经过我一段时间的资料分析和总结，我觉得在敏捷项目中，能包含以下几点的测试计划，基本已经完备了测试计划的所有要素。
即 项目背景、测试资源、测试内容及安排、测试策略、风险预估、关键时间节点、预期质量目标。
敏捷项目的测试计划要素
如何让测试计划更有执行力
主要有两方面，一方面是撰写测试计划的tester，一方面是文档内容。
对于撰写者，首先要充分了解当前团队成员的特定，因为人员也是一个风险，例如，我一般会重点关注质量不佳的开发小伙伴的提测时间。另外，撰写者需要充分了解当前团队的研发活动，了解我们要经历几个测试阶段，换几套测试环境，什么时候是一轮测试的节点，什么时候该要求开发人员全部提测完毕，以此来安排测试活动的时间。
对于文档内容，也是要求撰写者「计划」「如何」「去做」。请一定要认真研究这3个词，每个词都能让你的测试计划文档更饱满，更有意义。测试计划报告的平台可以开发，模板可以提供给你，但是测试计划的内容到底有没有用，就要真的要用心去做安排。
我对我的测试计划有3个要求：
1、范围清晰。要明确测试资源、测试范围、时间节点
2、策略合理。利用合理的策略，节约测试成本、强化测试效果
3、风险控制。尽量挖掘测试过程中可能遇到的风险，早发现早预防
风险预估
提到风险评估，大家会觉得这个词并不陌生，但如果真正要对一个项目做风险评估，很多人会觉得无从下手，因为我们要考虑的是还未发生的事情。
如果不知道从何下手，不妨先试试把各式各样的风险分个类（如下表）。然后按照时间线，来想一想在项目的不同阶段，我们可能会遇到哪些问题。
上面讲了如何识别和发现风险，接下来谈谈，应对风险的4种方法。
风险预估模板
测试策略
有些人搞不清楚测试策略和测试计划有啥不一样。
简单来讲，测试计划主要目标是包含所有关于测试的信息，比如为什么测、测什么、什么时候测、怎么测、谁来测等。
测试策略详细描述了QA使用什么样的具体测试方法来达成测试目标，给测试流程和活动设置了标准，主要关注测什么和怎么测。
由此可见，测试计划涵盖的内容远远多于测试策略，并且包含了测试策略。
首先看一下，如何判断一个需求需要做测试策略，可以根据下面的3个原则进行思考：
1、除了手工测试，我可以通过别的什么手段，可以更快更好的保障质量？
2、在完成目标的前提下，是否可以通过一定的手段节约测试成本（如减少些测试时间、释放些测试人力）；
3、不是所有需求都需要写测试策略，实在没有，常规测试方法就是保障质量的基础手段。
测试策略举例
关于测试计划评审
现在的项目，往往会议比较多，产品需求要评审、设计要评审、测试分析要评审、测试用例要评审... 那测试计划要不要评审？答案是，需要，但又不全需要。
我们比较认同的评审方式可以分为两种：
常规迭代 （大部分需求是团队内）这种迭代项目的测试计划，因为人员稳定、测试阶段稳定，大部分迭代的测试计划内容都是通用的，只重点分析测试策略和风险即可，这时候，只要保障测试人员了解开发的设计和重点难点，能够针对性的产出较为规范的测试策略，就没有什么太大的问题，这种迭代往往是可以不用大范围组织评审的，只要确保信息互通，确保你的测试策略是对应的开发认可的，就足够了。
而对于较为重大的迭代，有多个团队参与，涉及外部交互的，这种迭代是一定一定要组织测试计划评审的，要把你的测试计划同步给其他团队，也能同时至少其他团队的测试安排，这样更有利于大家达成质量共识，也更容易在测试时间和测试阶段上保持一致，以防后期大家进度不一致，互相掣肘，影响整体进度。
测试计划评审，是测试人员对于测试工作的一个公开，接受每个角色对于我们测试工作安排的检验，不要因为麻烦就不做，因为重要项目的测试计划不做评审，后期可能面临更大的麻烦，还是那句话，行动一定要趁早趁早趁早！
测试计划发给谁
1、直接参与者：项目经理、开发人员、产品经理、测试人员以及其他与需求有关的参与者
2、间接参与者：外部需求或对外需求的对接人员
3、需要谁协助：测试策略中写明的需要外部协助时的参与人员
4、其他关注者：你的领导等关注项目概况以及测试资源的人
最后想说的话
近期面试了一些测试人员，当我问TA如何把控项目进度的时候，大部分人都会回答，按照测试计划、或者按照测试组长分配给我的任务进行执行。但我问测试计划或者组长任务怎么安排出来的，大部分人回答不出个所以然，其中不乏有工作了5、6年的被试者。当你不能把控好原来你自己的项目，我如何相信你能把控好我的项目呢？当我们在一个敏捷项目中的时候，因为产品变化太快了，我们往往需要更精细的测试计划才能让我们的节奏不打乱，方向不会偏航，所以我希望我们测试人员，都能够具备这种把控项目的能力。你可以不做，但希望你会做。
【原创文章，转发请注明来源！】