也许是受“测试是无法穷尽的”的影响，我个人倾向于不去估计“每个用户故事的测试执行时间”。有段时间我甚至为此找到了一个说服自己的逻辑：开发之所以可以估计开发时间，而测试不能估计测试执行时间是因为：开发是一个可以明确定义“完成”的事情，而测试不是。例如，一个用户故事开发完成可以定义为“需求全部实现、单元测试通过、演示通过”。在此基础上“增之一分则少，减之一分则多”。而测试执行的“完成”如果定义为“按照测试用例跑完一遍，把所有缺陷修复都测试一遍”，是否再增加一点就“过”了呢？好像不是。比如，如果测试有更多的时间，针对一些重要的业务逻辑或者执行过程中发现缺陷比较集中的地方增加一些探索式测试是有益、甚至必要的。如果在早期还不了解被测对象的实现细节、不确定被测对象的质量状况，就预计一个具体的测试执行时间，它本身的意义有多大呢？
但是我并不反对“估计一个版本里所有的测试执行时间”。这听上去有些矛盾。如果不估计每个用户故事的测试执行时间，又如何估计所有用户故事的执行时间呢？我一般采用相对粗略的估算，所以不是累加各个用户故事的时间，而是基于“开发和测试的工作量在大部分的时候都成正比，且该比例不会波动太大”的假设，并根据以前的经验值得到的开发工作量和测试工作量的比例来推算大致测试的工作量。按照经验值，我们的项目开发和测试的时间是五五或者六四的关系。但在转为敏捷开发的流程后，测试执行时间和开发时间更多时候是重叠的，因此以前的这个时间的估算比例也就没有用处了。但是我们仍然需要尽早知道这个迭代里测试任务是否能完成，再加上因为迭代周期变短，一旦某个环节延期回旋的余地比以前更小，所以估算仍有价值。
为了一探项目在新的开发流程下“开发和测试的工作量的比例到底是多少，且该比例会不会波动太大”，我打算还是估计并记录真实的测试活动的工作量，然后分析三个时间之间的关系，即“开发的工作量”、“设计测试用例的工作量”、“测试用例执行的工作量（指按照测试用例执行一轮测试的时间，不包括记录缺陷的时间）”。相对于测试执行时间而言，我认为估算设计测试用例的时间偏差会更小、可靠性更高，所以我们估计设计测试用例的时间已经有一段时间了，而基于开始说到的个人认识原因，测试执行时间在最近的这个迭代才刚刚开始估计。从分析结果来看，估计的设计用例执行时间大约是开发时间的6%~8%。估计的测试执行时间大约是开发时间的22%（这个目前只有1个迭代的数据，所以仅供参考。）从实际的设计测试用例的时间来看，与估算的偏差一般较小。我想这一定程度上要归功于用户故事的分析比较明确和具体，故事的粒度也拆分得比较小。从实际的执行测试用例的时间来看，偏差比设计测试用例要大一些。例如，测试时发现缺陷较多，而每次为了报告缺陷必须保留当前数据，另起炉灶造出新的测试数据因此比较耗时；环境的不稳定性使得测试无法顺利进行浪费较多时间去沟通问题和报告一些无效缺陷；对于一些技术相关的改动在最初估算测试时间时比较轻视，没有正确认识其测试复杂度。这些偏差较大的具体案例真实地反应了目前阻碍测试有效性和效率的风险。针对它们的改进也就自然而必要了。
所以，在验证了假设成立的前提下，作为测试负责人的你可以在几秒钟的时间里根据开发估算的工作量乘以一个本项目适用的百分比，大致估算出测试的工作量。也许这是在测试资源有所变化的时候一个发现明显风险的快速办法。而对于每个一线的测试人员，对每个用户故事进行估算主要的好处也许并不在让测试负责人心里有数，而在于帮助个人暴露估算的盲区或者误区，从而降低自己工作的风险。
版权声明：本文出自 zdlzx 的51Testing软件测试博客：http://www.51testing.com/?56882
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
