聊聊「测试分工和测试时间」

注：作为测试从业人员的一点建议与思考，虽然阅读量不是很大，但是清菡个人觉得对大家能有点价值；

-- 清菡

关于「测试分工」和「测试时间」的关系，这个分 2 种情况：

第一种，研发技术水平高，项目业务场景相对来说比较简单。那么，这种情况下，如果管理人员安排一个人写用例，协助开发做冒烟测试，另一个人开始测试，这样做，相对来说问题不大。

但，这就多了时间的成本，接手过来测试的人需要重新了解这块的需求，效率会低一些。

第二种，项目场景复杂，研发水平比较低，一旦上线会出比较大风险的项目（例如涉及优惠券、订单之类）。如果管理人员安排一个人写用例，协助开发做冒烟测试，另一个人开始测试，就会出现比较大的问题：

导致测试进度缓慢，甚至无法上线。

这个也涉及团队协作，研发人员的责任心以及其它客观外部因素的影响。

怎么做？

如下，供参考

1.首先管理人员需对业务熟悉，考虑到风险范围以及风险点在哪。此外，还需考虑到研发人员的技术能力水平及责任心。以此，来做到合理的分工，出了问题也知道出现这样问题的原因。

2.管理人员需要有足够的技术水平支持，能认知到项目风险的前提是清楚明白会有什么样的风险出现，风险点在哪（这个需要清楚前后端技术是怎么实现的）。

3.当管理人员清楚知道了项目的复杂度，影响范围，风险点就可以预估出合理的测试时间，不会存在评估测试时间不合理的情况。或者说出现了这类的问题，管理人员自身清楚是怎么回事。

4.bug 的出现肯定有原因 ，一个是从操作上分析，看看是不是什么操作自己没想到 ，随便瞎点点出来的，一个是代码上分析 ，看懂代码 ，做路径覆盖 。

5.测试是为了尽可能的避免出现问题，没办法保证一定不出问题 ，关键看出的问题是特定场景确实大家都没考虑到 。还是说没经验，  确实考虑不到这种操作才知道会出现这样的问题。

6. 测试估算的时间，只需考虑测试的执行时间。如果中途，由于开发延期提测，或者开发修改 Bug 时间过长，等待新版本测试。在时间评估的时候，需考虑这个时间，把此块时间加上（或者，发版时间，顺延） 。

7. 自己估算的时间，如果后续发现时间不够，自己加班，想办法消化 。另外，版本结束后，吸取经验，总结下，是哪个点消耗时间过多，是否可加速（自己总结的经验，终身受益） 。如果确实不可加速，说明整个团队的效能比较低。下次估算，不满足三分之一评估大法，在之前评估时间的基础上，再加上 20%的时间 。

8. 项目过程中，不接受临时新增需求的测试，如果有临时需求，需要增加对应的测试时间（这块，理论上是这样，实际情况是，很多同学，经常被强塞任务，时间却没有增加）。

9.用例写全。不是凭空想象 ，例如涉及优惠券的项目，一定把优惠卷的影响因子列出来。然后用正交实验大法抽取用例。

10.如果测试用例场景写的不够全，交接用例过来测试的人需要把问题都列出来，总结好发给领导，让领导去判断，避免背锅。

11.开发对业务不熟悉以及技术水平低， 这个不是咱们关注的， 有开发 leader 去把控。

12. 现实情况是，估算好的测试时间，已确定的上线时间，往往由于一些外部因素，提前上线，这个时候，测试同学，需列出已知风险，并做好本职工作，避免背锅 。

最后。

关于测试分工和测试时间的估算，此文的观点是一些非常主观的做法（仅供：不知道如何给测试分工及如何估算测试时间的测试从业者，一些参考）。

每个人的做法，多少会有些不一样。肯定会有更好、更优的做法。欢迎参与评论，或者，进知识星球「清菡软件测试」。点击链接：

https://t.zsxq.com/ZjQf2RV     即可免费加入！探讨交流。

加油。

清菡软件测试 提了一个问题

关于测试分工和测试时间，您有没有好的意见？欢迎来答。

参与讨论

想微信单独找清菡的，公众对话框回复「清菡」（注：文章写过的重复性的问题别问；欢迎问没写过的、高质量的问题）。

2020.10.17      Beijing

希望清菡的每篇文章都对你有那么点价值。

如果有用，点个在看吧。