本文章转载于搜狗测试
序
熬夜加班，排好的一个月计划并公示项目组，终于回家睡了个好觉。第二天到公司，纳尼？[震惊]需求有逻辑问题，前期没发现（前期需求了解不充分），现在要修改？！任务评估时间与实际不符？！忘记排例会（常规任务忘记排）？！有突发任务？！……别理我，让我哭一会儿……[哭]
哭完了，作为一名正在冉冉升起的测试新星，绝不会被困难吓倒。理一理思路，总结经验教训：除了质量，项目组最关心的是测试的进度（任务进行排期就是为了告诉项目组测试安排，任务完成的时间点）。作为一名测试负责人，如何提高项目实际工作内容与计划的吻合度，使测试人员的工作节奏更具合理性（不会累的像狗一样），以下将从四个方面探讨这个问题：
1.项目前期的需求阶段—“进度控制”开篇：你确定你了解需求吗？
2.项目前期的任务评估—“进度控制”中篇：运筹帷幄粗略测试计划
3.项目前期的详细测试计划制定—“进度控制”下篇：明明白白详细计划
4. 项目中的突发任务处理—“进度控制”尾篇：不慌不忙应对突发状况
"进度控制"开篇:你确定你了解需求吗？
引言
模块负责人进行需求了解、评审是整个项目流程的始发点，如果需求不统一，残留问题较多，必然导致后期较多的需求沟通、修改，增加沟通成本，甚至导致开发返工，增加测试工作量，从而影响整个项目进度。本篇是模块负责人主要从“需求了解”“需求评审”“需求变更”三个角度说明以前踩过的坑以及填坑方式
需求了解
坑1.模块负责人对需求了解不透彻，未发现需求遗漏、不明确内容
例如：
①模块负责人只看懂了需求中的文字，并不能上下贯通，不能发现需求遗漏内容
②个别需求较难理解，没有真的明白也没有继续跟进
含泪总结：问题发现的越晚，对测试的限制越大，因此，提早预防需求问题导致的功能不稳定，才能在后续项目中做到有条不紊，在此只有两个字可推荐“认真”。不要抱着了解个大概的心态，不要停留在需求的表面，提前思考其背后延伸的逻辑，对现有功能是否有影响，以及反向逻辑。如仍存在需求遗漏的现象，可尝试如下方法：
①跟进2~3个版本的需求确认内容，总结不能发现的需求遗漏点，提高需求审核能力
坑2. 需求文档写的不够详细，导致后期花费较多时间进行问题沟通确认
例如：
① 需求文档太粗糙，缺少细节，欠缺文案，无法进行用例编写（即使在这个基础上编写了用例，后续也需要再花费时间进行补充修改）
② 因测试和产品对需求的出发点不同，测试考虑的点一般都会比产品多，所以需求文档中欠缺一些异常逻辑，特殊操作等相关需求
含泪总结：一个新产品或者进行大改版的时候，模块负责人编写用例不宜过早，应该等产品文档稳定后再进行编写
①当产品文档存在过多以上问题时，收集问题并说明对自己的影响，反馈给产品经理或者项目负责人推动进行优化解决
② 也可以将上面整理的问题+影响在项目总结会上由项目负责人反馈给项目组
③总结当前需求产品一般不会考虑到点，增加需求评审经验，尽早发现欠缺内容，并推进产品补充文档 。
例如：a. 异常逻辑的处理 b. 新功能对旧功能的影响 c. 提示文案未确定 d. 不走产品引导的逻辑怎么处理
坑3. 个别情况下无需求文档
例如：开发自己代码优化、bug修改无需求文档，指派给测试后才测试才知道，额外增加测试工作量
含泪总结：与开发沟通，以下两种解决方案
①开发的需求提交至产品，并由产品补充至需求文档
② 不需要提交的小需求（某功能的优化），可在测试范围确认信中补充
需求评审讨论
坑1. 需求讲解不够详细，导致后期占用较多时间沟通细化需求，影响开发、测试进度
含泪总结：
① 模块负责人在产品同学进行需求讲解前，要先了解需求并整理出自己的需求疑问，以便在需求讲解会议上进行沟通
② 讲解不详细，及早反馈项目负责人，要求产品组织相关负责人进行二次讲解
③ 与产品沟通确认有效的需求讲解方式：目前的方式为：分模块与相关负责人进行需求讲解，测试可能会占用较多时间
坑2. 需求文档、交互文档、设计稿不一致，后期需多方确认
含泪总结：尽量在需求了解阶段发现该问题，总结反馈产品并更新需求文档，减少后期返工时间，当前与产品沟通后的结论为：
①需求逻辑以产品文档为标准，测试过程中发现不一致，以产品文档为标准提交bug
②视觉以设计图为标准，产品进行验收、设计进行走查；测试需关注兼容性问题、视觉不友好问题
坑3. 三方（开发，产品，测试）信息不统一
例如：原来的数据统计功能由开发经理实现并统一给出开发文档，模块负责人以开发经理为唯一出口，不与产品进行讨论。后期由于数据统计功能在开发方进行模块划分与交接，接手的开发修改的数据统计与原有的数据统计功能，需求，均不一致
含泪总结：
方案一：
①唯一出口变成产品，产品将数据统计的需求文档统一发给开发和测试，并进行统一讲解
②开发给出数据统计实现文档后，若测试发现有数据统计不统一问题直接反馈产品，由产品推动解决
方案二：开发产出数据统计的实现文档后，由产品经理进行审核，达到预期才交给测试同学
需求变更
坑1. 需求变更信息不统一、不及时，后期沟通成本大，例如：需求变更信息不能及时传达至三方
含泪总结：
① 三方共同确认的需求，后期统一更新至需求文档
② 任意两方口头、qq等方式沟通的需求，若需求逻辑较大，要求产品尽快更新至产品文档并邮件通知；若为较小细节需求，实时以qq、邮件、口头方式通知三方，后期统一更新至需求文档并邮件通知（补充：个别细节需求产品不会补充至需求文档，因此测试需要记录补充细节需求，以作备忘和信息同步）
③模块负责人若发现有需求变更，实时将变更信息qq通知组内，并补充至svn需求整理中，以做信息同步和备忘
坑2.产品间有关需求不能达成一致
含泪总结：将该类问题反馈给项目-产品负责人，由产品负责人统一给出结论
坑3.需求变更不能及时更新文档
含泪总结：若有需求变更产品无法及时更新需求文档时，要求产品第一时间以qq、邮件、口头的方式通知三方，要求当天将需求补充至文档。
坑4. 需求变更&需求增加直接影响测试进度
含泪总结：首先，模块负责的测试同学评估影响的范围、时间、对进度的影响，考虑组内是否可以协调资源或任务置换等方式解决？
a)可以，组内消化，并将相关信息同步至产品。
b)不可以，与产品沟通测试计划，重点表述不能达到预期的原因、测试所做的努力（资源协调、测试方法的优化）以及自己的意见（延长测试周期、砍需求、开发自测保证质量等），协调达成一致，重新排期并公示。
写在最后
千里之行，始于足下，需求了解是第一步。从一开始就提高警惕，避免被坑，项目进度才会按照自己的计划一步一步进行。
