软件产品的成功与否，离不开测试，而对测试来说，测试估时和实际测试范围挂钩，这就使得测试估时非常重要。很多公司实行敏捷开发模式，开发需要估时，测试也需要估时，这样才能知道一个sprint的工作量，并预估整个项目时间周期。
估时的原则是：实际，精确。
本文不讨论测试估时的具体步骤，仅从理论上说下如何让测试估时更加实际，更加精确。
1、给自己留有余地
估时的时候需要给自己留一点风险时间，留有余地，但不是增加额外缓冲时间。任何事情都不是理想状态的，留有余地确保在不利的情况下也有时间应付，同时也能保证最大化测试范围。
2、充分考虑公司的流程
测试预估的时候要把bug的分析定位也考虑进来，实际所花费时间常常比预估的时间更久，所以实际预估的时候要把当前产品版本的稳定性考虑进来。
有的公司流程留给测试的时间非常少，所以，测试优先级的评定，测试范围的确定，出现问题如何解决，都是在测试计划时候就预估好。
有些公司一个发布过程要从开发环境、测试环境、生产环境再到正式发布，而服务器不稳定就有可能就会block测试。
3、并行测试
没有太大依赖的任务，是不是可以一起测；在开发人员刚开始开发时候，是否可以开始做一些准备工作，比如创建帐号、准备测试用例、自动化脚本等。
4、随时关注进度，重估时间
有很多不可预见的因素，项目没有预期进行，或与最早的预估有偏差，我们就要随时校正并重新预估时间。
5、基于过去的经验
过去的经验可以帮你预计到可能的风险，并尽早确定应对策略，这样的估时也更加精确、实际。
6、目标明确
对一次版本发布，并不需要把所有的bug都解决，所以发布的标准是什么？产品需求细节是什么？作为测试人员，都要非常清楚。测试估时偏差过大就会引起delay, 相对应就需要加班，这不是高效的方式也不利于未来的沟通。
7、了解你的团队
如果你是team leader, 还需要明白整个团队的战斗力，每个人的专长，谁更熟悉哪块业务，等等。
8、基于目前的资源
估时要以现有的资源为前提，因为很多时候，招人并不能立刻起到显著效果。所招新人也不一定迅速可以投入使用。
9、取决于你，你的公司，你的领导
根据公司、团队领导对测试的重视程度不一样，可以接受的测试时间不同，但从产品质量方面考虑，作为测试人员就需要去布道，争取时间。测试估的时间多了，PM肯定又不接受；可是若不争取，估计会被压得更厉害，天天加班，团队不稳定，而且产品质量也无法保证。
其他部门通常都认为测试很简单，分分钟就能搞定，不就是点点鼠标吗？逐渐给其他部门布道，让质量深入人心非常重要。
-- End --
文末寄语： 事到手，切莫急，便要缓缓想。想得时，切莫缓，便要急急行。