结构化解读-如何制定测试计划

该文章面向msup《角色地图--跟一流专家系统学习好的工作经验方法》的测试栏目而撰写，更多测试词条内容可通过下载“角色地图”app获知。以下为测试计划制定的结构化解读，共享给各位读者同仁。


定义
测试计划Testing plan，描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系统应用软件组装测试和确认测试。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。


观点
古语有云，凡事预则立，不预则废。计划在任何一个项目流程中都有着非常关键的作用，测试计划也不例外。测试计划是每一位测试人员都必须掌握的基本技能，能不能做出一份完善而详尽的测试计划，是证明测试人员是否全面了解需求、是否将版本发布风险降到最低的有力证据。同时，也是衔接项目流程中上下游工作的重要依据。
在制定测试计划时，我们需要先搞清楚以下几个问题：
1.谁来制定测试计划
通常，测试计划由小组之中经验较丰富的测试工程师来制定，以其对被测对象更全面的了解、更专业的测试策略、更丰富的测试经验、更完备的风险控制策略等来保障测试的深度和广度。需要注意的是，在实际执行中，见过不少测试团队会把这项工作交给初级测试工程师甚至实习生来做，让其在接触测试工作之初就承担输出测试用例以及测试计划的工作。这其实并不合理，如此做法，其实有违测试计划制定的初衷。
2.什么阶段来制定测试计划
在敏态互联网项目流程中，强调持续交付能力，测试计划的制定也会随着项目节奏而前置。通常认为，一旦需求经过评审且准备就绪后，测试就可以根据需求制定测试计划。计划中依赖技术方案的部分，可以根据开发的技术设计而制定。在时间上，我们需要在版本提测之前，就输出测试计划。一方面，为了进一步规避风险有些计划需要在提测前甚至coding前进行评审；另一方面，计划制定者和执行者不是同一个工程师时，需要进行工作衔接和测试资源的提前准备，以保证在提测之后能快速进行计划的执行。
在稳态互联网项目流程中，更强调严谨和极致的风险规避，往往测试计划也会有更细致的要求和评审确认。此时，我们以不影响项目进度的最早完成时间为原则即可。
3.测试计划应该如何制定
1）前提条件
制定测试计划的前提条件，一定是对需求本身足够的熟悉、技术方案的足够了解。但是具体要多熟悉多了解呢？上面第二条说到，当需求一旦确认，测试就完全可以制定测试计划了，之所以可以凭“空”计划，正是由于在评审时，已经对需求本身的诉求、业务逻辑、技术方案有了明确的认知。
举个简单例子，某需求的内容是：要为某网站增加服务弹窗提醒，需要用户根据自身实际信息勾选相应选项以便后续推送不同内容。
在需求评审通过时，测试工程师需要明确知道包含但不限于以下内容：
弹窗出现的具体交互场景
弹窗的页面交互逻辑
存储用户选择信息时所调用的接口
用户信息存储的字段及其枚举值（该项根据具体研发方案而定）
后续读该信息时的逻辑以及注意事项
数据有效期及其存储风险
是否有性能、安全性等要求
异常处理
假如我们对以上的各项信息都了然于胸，我相信一定可以毫不畏惧的开始制定测试计划。如果需求确认后，如上述所列的种种信息依然不能完全获得，那我们需要反思自己是否真的了解了需求、搞清楚实现方案、明确了测试内容。
2）制定方法
确认测试对象：这是计划的第一步，我们需要明确要测试什么，这看起来并不难。但是需要注意的是，并非和需求关联的所有内容都具有可测性，在面对复杂系统时，合理的拆分出测试人员可以着手测试的部分，以及不可测部分如何规避风险，也非常的关键。
列出测试内容：根据测试对象，需要确认具体的测试项、测试方法、策略、工具、测试用例步骤、预期结果和通过标准。我个人的建议是，测试项和测试步骤要尽可能详尽，详尽到可执行。因为抽象的需求说明，只有落实到具体执行时，才能暴露问题，所以我们罗列测试项和测试步骤的同时，相当于在脑海中测了一遍，这可以帮助我们尽早的暴露问题。
资源和环境准备：通过上述详尽的测试内容罗列，我们可以明确的知道所执行的这次测试，需要什么样的测试环境、硬件以及软件资源、人力资源。例如，一些移动端app的测试需要测试终端兼容性，那么就需要不同品牌、机型、系统版本的移动终端资源来进行测试，还可能需要一些辅助的脚本或者工具，以及特定的网络环境。这些都是我们需要提前准备的内容。
进度和人力计划：为了保障版本发布的时间要求，测试人员必须对测试进度负责。依据需求要求的上线时间，执行此次测试所消耗的时间、人力需要测试人员来把握。然而，在项目过程中，开发和测试阶段是极具不确定性的一个阶段。很多前期隐藏的问题，会在这个阶段暴露出来且打乱我们的计划安排。这种情况下，需要第一时间把问题记录并反馈给项目经理和研发经理，并在时间和人力计划上根据历史经验留有一定余地。
协作和流程：有很多项目是跨组、跨部门甚至跨公司的合作，此时测试人员需要对合作的内容、方式、工作界限、是否需要联调、是否有时间点和业务逻辑钳制等有明确的认知，并且要把需要协作的部分做具体的执行说明。且，在工作中我们和上下游配合处理哪些流程、记录缺陷和问题，也是我们需要明确的。
风险评估：任何版本的发布都具有一定的风险，测试人员需要根据对测试内容的评估，做出可能的风险预测，例如人力风险、测试资源风险、流程风险、上线验证风险、业务风险等等。我们需要根据以上的计划内容来判断可能的风险点，并尽可能的给出规避措施。
一份完善的测试计划应该是可执行的，比如测试人员A制定的测试计划，那么组内任何有一定测试基础的测试人员B都可以根据测试计划直接进行测试。

岗位胜任力概述
制定测试计划并不是一件轻松的事情，测试计划几乎提前预演了所有的测试活动和输出结果。必然，它对计划的制定者有着较高的要求。从测试初学者成长为可以游刃有余地制定测试计划的测试工程师需要不断的学习和实践，而具备以下能力是非常必要的条件：
1.需求分析能力
只有能准确的分析需求，提前洞察到需求的应用场景、逻辑才能帮助我们快速的提炼出必需的测试场景。这是测试人员的一项必备技能，且也有一定的方法论可循，感兴趣的同学可以学习相关知识然后结合自身项目实践进行不断提升。
2.技术能力
熟悉项目架构、所使用的编程语言、系统工作流程、部署结构以及常用中间件的特性等，并能进行技术方案的研讨等能力非常的关键。测试是开发流程中的一部分，我们和开发其实是一体的，只是工作内容有区分而已。除了某些深层次的纯代码技术问题，对于其他项目中的基本技术能力，我们不应该和开发同学有过多的差异。
可能对于某些测试岗位来说，手工测试偏多，测试人员的就职门槛并没有过多要求技术能力，但是随着测试人员的不断成长，和开发人员尽可能对等的技术视野和思考能力，在项目执行和职业发展过程中起到关键的作用。
除此之外，对于测试技术本身，例如基本验证方法的掌握、测试工具使用、用例设计、环境搭建部署、测试脚本开发等能力，也至关重要。
3.全局思维能力
从上面的计划制定方法可以看出，制定一个详尽的测试计划，几乎需要知道从原始需求到发布上线的全流程以及每个环节的执行要点。不仅如此，还需要具有和产品经理、项目经理一样的业务格局和技术视野才能洞察一个需求对业务的影响程度。这些是我们进行场景设计和风险评估的必要条件。而且，对于测试技术本身，也需要十分的熟练才能给出最快速、准确的测试方法。所以说，具有一定的全局思维能力，可以帮助我们更全面的制定测试计划。
4.应变能力
既然测试阶段充满了不确定性，那么制定测试计划时，就需要知道如果出现问题该如何快速应对解决。要知道，测试计划虽然制定，但不是一成不变的，可能因为人员的突然变动、缺陷影响范围的扩大、需求的临时变更等，测试计划也会受到影响。而制定计划之时，就需要提前思考出现问题该如何应变。
5.沟通和组织能力
制定测试计划为什么需要沟通和组织能力呢？这是一个具有社会性的问题。任何工作其实都是在和人打交道，除了处理事情本身，我们更多的是要处理人的问题。比如，测试资源的协调准备、上下游和内外部的协作、流程的相互约束、过程中的问题反馈和跟踪等等，需要测试人员具有一定的沟通和组织能力。快速定位问题、给出方案、协调资源，这非常的关键。而在制定测试计划时，我们就需要对这些内容充满信心。否则，真正执行的时候，一个不起眼的预期之外的问题，就足以搅乱整个计划。


学习建议
一、学习方法
从执行计划到制定计划是一个循序渐进的过程，上述几项关键能力非朝夕之功。在学习过程中，我们需要放平心态，踏实践行。可以用以下几个方法不断提升自己制定测试计划的能力：
1.测试理论的学习
对于快速迭代的互联网行业测试人员来说，系统而全面的测试理论学习是非常奢侈的。我了解的很多测试人员，甚至在工作了N年之后，仍然没有得到过基础而系统的测试理论学习，我认为这是非常遗憾而无奈的。了解测试工作本身的重要性、基本的测试理论、严谨的测试方法会带给我们对测试工作完全不一样的感受。这样的学习，会帮助我们进一步树立对测试计划的执行态度和原则。否则，我们可能需要踩过很多的坑，才能正视测试计划的价值。
2.数据收集和总结
总结和复盘无疑对任何环节都有巨大的价值，测试流程也不例外。
第一，通过收集和分析用户或运营需求，我们可以看到产品优化方向从而进一步提升需求分析能力。
第二，通过收集和分析线上问题、遗留问题，我们可以找到测试遗漏的测试点，从而健全测试内容。
第三，通过历史缺陷的统计，我们可以看到所在团队研发同学缺陷分布情况，从而指导我们指定更合理的版本计划。
第四，每个测试计划都进行自我的小小的复盘，找到该计划做的好的和未考虑到的部分，结合数据的分析，可以帮助我们不断输出更好的测试计划。
举个简单例子，如下图一所示，某研发团队2019年整体的缺陷中，因为异常处理不够导致的缺陷最多，那么我们在制定测试策略时，就会优先、集中的做异常测试以尽早发现问题。



图一


3.充分的团队协作
没有人能在面对复杂问题时，一次性考虑到所有可能的风险。测试计划的评审对于健全测试计划、增强测试信心非常的重要。当我们无法确定是否还有潜在风险时，不妨邀请产品经理、项目经理、研发经理和运维负责人一起进行测试计划评审，利用集体的力量帮我们修订和完善这份计划。值得注意的是，组织多人会议时，尽量避免过分发散以提升效率，提出问题的同时也必须确认解决方案。
4.带有敬畏的实践
之所以能作出完善的测试计划，一定是对质量的敬畏。缺少了这份敬畏，那么严谨的测试工作就无从谈起。保障质量是测试工作的价值所在，对于质量的敬畏心，决定了我们工作的底线。当我们制定测试计划时，也一定是有着这样的敬畏心，才会时刻警惕时刻负责。

二、典型问题
实践项目中面对的工作场景往往会更具有个性化，没有一条通用理论可以解决所有问题，在实际工作中难免会踩了很多的坑才能找到自己的最佳实践。以下是几个比较典型的问题，我们来看一下如何应对：
问题1：项目迭代快，编写测试计划会占用较多的时间甚至导致工期延长，可不可以不写测试计划？
应对措施：答案是否定的。测试计划是项目必不可少的管理性文档，它或简单或复杂，但是一定是必要的，必要性不再赘述。但是在快速迭代的项目中，我们不妨简化测试计划的模板和标准，只保留关键核心的内容，比如测试方案（用例设计）、风险评估、工时评估等，其他的无特殊情况可不做额外说明（例如某些运营类网站系统，测试资源不会根据每次的版本内容有太多变化，那么测试资源这里就可以省去）。
除此之外，制定测试计划可以帮助我们更好的将测试过程可视化。越是在快速迭代的项目中，过程可视化就越重要。通过前期对测试任务的分解，可以明确每个节点应该完成的测试任务以及过程产物，辅助线下物理看板或线上精益看板，可以做到测试过程可视化，提高整体效率。
问题2：测试计划只是项目的硬性文档要求，实际执行中根本没人看不能用？
应对措施：测试计划很容易流于形式，大家找到项目文档模板，按照过去的旧文档拿过来抄一抄、改一改，然后上传到自己的项目文档管理中心，测试计划制定这项工作就算结束了，然而这个文档里具体写了啥，自此无人问津。所谓的测试计划，变成一纸空文。整个测试工作的执行，也和测试计划有很大的出入。
我个人的观点是，与其花费时间写一篇没有价值的文档，不如认真的思考到底该如何制定和实施测试计划。测试计划的价值，在于实施不在于文档本身。如果我们制定的测试计划，总是不能很好的执行下去，那说明计划本身是有问题的，需要提升的是制定计划的能力，而不是否定计划本身。我们需要从计划的可行性和有效性上去寻找原因，例如是不是制定的策略不符合实际测试场景导致无法执行？工期预估是不是过于乐观导致每次都会延迟？测试方案考虑是不是不够细致导致测试时总是发现有更多的东西需要测试？等等。这些看起来不起眼的问题，是计划无法执行的直接原因，也是我们要解决的问题本身。
问题3：执行过程中需求变更了，需要重新修改计划么？
应对措施：答案是肯定的。执行中经常遇到上游需求中途变更，或者为了解决突发问题增加、删除、修改原有逻辑的情况，此时测试人员绝不可以忽略变更，在不经过深入思考的情况下直接测试。反而，我们需要评估新的需求以及新的技术方案，针对其对系统的影响做新的计划。当然这并不是要求我们完全推翻原来的，但是我们需要在测试计划文档中，重新考虑更改部分的测试方案、评估风险、评估工期等。
我曾经遇到过一个项目，因为所谓的快速迭代，没有人维护需求变更而引起的技术方案变更文档、测试计划文档，经过中途若干次变更（事件跨度月余）之后，大家都已经对之前做过什么、即将要做什么逐渐模糊，一些事情为什么这么做大家也逐渐说不清理由，导致上线之后有严重逻辑漏洞。
对测试人员来说，每一次的需求变更其实都是一次新的需求，都必须谨慎对待，尤其当识别到重大影响或风险时，及时向项目负责人反馈不能擅自做决定。作为一名职业的测试工程师，我们需要对测试的整个过程和结果负责任。

实际项目执行中遇到的问题不止于此，需要在坚持原则的情况下活学活用。


学习资源推荐
《软件测试》作者:（美）佩腾（Patton,R.） 著，张小松等译，出版社:机械工业出版社。本书涵盖了软件测试的方方面面：软件测试如何适应软件开发过程，基本的和高级的软件测试技术，在常见的测试任务中运用测试技能，使用自动化提高测试的效率，测试工作的计划和文档化，有效地报告发现的问题，衡量测试工作的成效和产品的改进等。可以通过此书看到软件测试的发展史，以及基本的测试理论等。
《Google软件测试之道》作者:(美)惠特克等，出版社:人民邮电出版社。从内部视角谷歌公司是如何应对21世纪软件测试的独特挑战的。介绍了软件测试工程师的角色；讲解了技术测试人员应该具有的技术技能；阐述了测试工程师在产品生命周期中的职责；讲述了测试管理及在Google的测试历史或在主要产品上发挥了重要作用的工程师的访谈等等内容。通过此书可以拓宽自己的视野，站在更专业和更高的高度上看待测试工作。

-
作业思考题
1.选择题：以下表述正确的是
A.项目比较紧急的时候，为了节省时间，可以不必做测试计划。
B.测试计划的评审对于健全测试计划、增强测试信心非常的重要，必要时需要进行评审确认。
C.测试人员只需要关注是否有风险，至于如何规避风险，测试人员不用计划。
D.充分的了解需求，是制定测试计划的必要条件。
E.总结过去的缺陷和问题，有助于健全测试计划。
答案：B、D、E

2.实践题：尝试对即将开展的项目，做一份完整可执行的测试计划，并着重分析项目难点，给出能最大程度降低风险的测试方案。

3.思考题：结合当前项目的自动化使用情况，思考如何在方案设计时借助自动化测试工具提升测试效率，又如何留下可复用用例。