本文章转载于搜狗测试

剧情回顾

又到周末喽，还记得我们约定的四个阶段吗：

1.“进度控制”开篇：你确定你了解需求吗？已get√

2.“进度控制”中篇：运筹帷幄粗略测试计划

3.“进度控制”下篇：明明白白详细计划

4.“进度控制”尾篇：不慌不忙应对突发状况

“项目进度”中篇：运筹帷幄粗略测试计划

引言

当一个项目的需求了解完毕之后，测试负责人驱动各个模块负责人对模块任务做一个粗略的评估（复杂度、前期准备、测试方案、测试时间等），以提前明确大概的阶段性测试时间（前期测试准备时间，一轮测试时间，回归测试时间）是否符合项目组预期。换句话说：开发提测之前能否做好前期准备？一轮测试+回归测试的时间是否会超过项目组的时间预期？

确实很想提前知道这些信息，那么到底该怎么做，做的时候又会出现哪些坑呢？

怎么做？

1. 项目负责人了解完需求后，根据①与原有模块的关联性 ②模块负责人的执行能力③模块负责人的现有任务 ④ 新功能的难易程度 对新增加的需求进行模块划分，并指定对应的模块负责人，同时，需要考虑以下因素

a)原有旧模块的需求变更，对应原有模块负责人

b)与开发沟通，未变动的旧模块是否有代码变动或被影响。如有，将相应模块列入粗略计划表中，并对应原有模块负责人；如没有，可不填写

2.模块划分完之后，和项目组的开发经理以及产品经理核对任务是否有遗漏，并请他们填写对应功能的开发负责人和产品负责人

3.项目负责人将制定好粗略计划样表（划分的模块，对应的开发，产品负责人，测试的各个阶段）发给模块负责人进行任务评估，如下图所示

4.模块负责人对自己的模块，进行需求了解，确定要做的测试内容并对使用的时间进行评估。例如：是否需要兼容性测试，是否有接口需要做容错测试，如有需要则进行时间评估，不需要的部分时间为0，如下图所示

5.模块负责人评估好时间之后将具体信息反馈给项目负责人，项目负责人根据自己的经验对模块负责人评估的时间进行审核修正。

6.项目负责人对所有的任务进行整合，拆分。获得信息：前期测试准备时间哪部分时间最长，一轮测试时间哪部分时间最长，回归测试时间哪部分时间最长。然后再进行任务以及人员的协调，使所有人的任务平均并得出每个阶段的完成时间点，最终得出项目全部完成的时间点，如下所示

以上信息可以得知：

a. 测试准备时间最长为14H，新功能测试最长时间为18H，功能回归最长时间为7H，测试一共需要时间为39H

b. 当然以上都是理想状况，一旦某一环节delay则其余环节都得delay，其中，最大的风险就是张mou，秉着前紧后松的原则，张mou的工作应尽可能提前，如能协调其他成员则进行人员的协调，如其他人不能帮忙完成，则需要考虑周末加班

以上操作步骤虽然说起来很容易，但其中的坑坑洼洼说起来又是一把鼻涕一把泪

坑洼出没

坑1.模块负责人该如何下手进行评估

含泪总结：模块负责人拿到任务后，先去了解需求，分别从以下角度考虑：

①客户端需要实现的是哪部分。对该功能的影响因素有哪些？和其他功能的交互有哪些？是否需要做UI兼容性测试？

② 后台服务器需要实现的是哪部分。服务器的接口是新的还是旧的，是否需要做容错？

③是否有数据库的需求。其中是否涉及到数据库的兼容性

④客户端和服务器的功能是否需要联调。客户端的功能和服务器的功能是单独测试，如果是单独测试后续就需要增加联调

坑2.模块负责人的评估考虑不足，导致后续实际执行时进度失控

含泪总结：①项目负责人可自己评估一份粗略计划，当模块负责人评估时间与预期有较大出入时，听取模块负责人的评估方案，明确出入问题，双方讨论一个合理的评估②需要多方配合测试执行的模块，需要加入环境搭建、沟通协调时间

坑3. 功能遗漏

含泪总结：在和产品经理，开发经理进行任务核对后，一般是不会再有功能遗漏，但是，对应功能的数据统计部分是最容易被忽略的，这个需要强行记住

坑4. 有些不难测试的功能，但是重复性很大，占据大量的测试时间

含泪总结：提前和测试开发商量是否可进行自动化以便提高测试效率，如兼容性、容错测试

写在最后

运筹帷幄之中 决胜千里之外