测试工作量评估的故事

背景：某应用软件有多个模块组成，各模块都有不同的满足用户需求的业务功能，但“数据导出”比较特别，在多个业务模块中都有此功能。于是在设计时，开发人员对“数据导出”相关共性需求的处理函数进行了封装，对外只提供相关接口给其他模块调用。各业务模块与数据导出模块的关系如下图所示。此模块的测试由工程师陈X负责。

业务模块与数据导出公共模块的调用关系图

事件：在任务开始前，主管李A安排陈X先评估此任务的工作量，当陈X把工作量10天（即2周）报给其主管时，其主管几乎不敢相信会相差那么远，因为他自已评估的是2-3天，差了不少于3倍的时间，更何况陈X还是一个资深测试工程师。问题出在哪呢，为何会相差那么远？

原因分析：主管李A找来陈X交流

主管李A：数据导出的测试，你评估的工作量是10天，请具体说说这些时间的任务分布吧。

陈X：数据导出功能，在整个软件中共有5个模块调用，由于每个模块的业务不同，导出的数据是不同的，需分别设计测试用例，及执行测试，估计一个模块花2天的时间，5个模块共10天。

  主管李A：从业务出发，每个模块导出的数据是不同的，但各模块是如何实现此共性功能的，是否作过分析。

  陈X：没有，也没见到开发有相关的设计文档。

  主管李A：是否找过相关开发人员沟通、分析过其实现原理。

  陈X：没有，我是按需求说明进行验证的。

   问到此处，主管李A只好把数据导出模块的实现原理，与各业务模块的接口关系对着开发的代码实现讲解了一遍，并让陈X理解各模块的测试边界在哪里，那些是共性的，那些是特性的测试。陈X听后，有种晃然觉悟的理解，回头再梳理了自己的测试思路，整理共性与特性的测试点，最后评估的测试时间约为4天。

启示：工作量的评估，是我们经常遇到的，看似与技术无关，但通过上面的案例，相信读者能体会到其中对系统业务、设计、实现把握度的重要性。测试前期某测试任务的评估，隐含着初步的测试对象分析，测试方案、用例的设计，与测试效率有着直接关系，是一种测试综合技能的体现。