近期在整理部门测试流程方面的一些东西，把之前根据经验，根据感觉来做的一些工作转为有文档可依的工作流程。
遇到测试时间评估没有具体方法的问题，这里准确的说，是测试执行时间，想请教大家。
我回忆了老东家的方法，通过长时间的经验，根据测试数据准备，测试步骤多少，执行复杂度，来评估出测试执行时间。
但是老东家是做对企业交付的，有完备的自动化和手工回归测试流程，项目时间也充足，3 个月一个版本往往只有 5 个以内的 bug。
对应到现在的公司，3 周一个迭代，需求规模庞大，并且不是清晰的 checklist 形式；测试用例规模大致每期在 500+（单测试点一条用例）。
在评估测试时间的时候往往还没开始写用例，评估出的时间较为不准确，总是会造成最后的加班发生。
大家一般是怎么评估每个迭代的测试执行时间？有什么具体的方法呢。
我一般评估度，会确定本次修改内容，牵涉平台，对现有系统的影响进行评估，对 checklist 进行估算，一般每个测试环境 给 2-3 天的测试期，1-2 天的改 bug 期，依据开发预估的提测日期，给 2-3 的天开发缓冲期，测试后期留 1-2 天的延后期。不过在实践中，我发现，这个计算的周期会因为项目进度受影响，目前会上线出现加班通宵上线情况，主要在我们流程上面不完善，沟通不顺畅。临时会接很多别的临时的需求，加上产品新手情况，最近预估的十次有八次需要加班，沟通不畅。
结合目前项目的情况，我们版本迭代也很频繁，每位还是根据需求内容、测试的复杂度、对业务的熟悉程度、开发是否有时间修改 bug 来评估测试时间
跟项目类型有关吧，按照我的经验，普通的应用和游戏差别还是挺大的。
一般我都会加很多 buffer，理想情况是 double
edsion
回复
留 buffer 这个工作在我的理解中应该是项目经理的工作，如果我在给出的时间中预留，需求方就会过来问这个地方的时间具体是在做什么，然后设法砍掉，所以想找一个有理可据的方法
雷子
回复
临时的需求，目前的我采用的做法是 在项目中固定安排一个时间点允许需求方修改或者增加需求。这样需求方知道可以增加，也就不会频繁的变更，当然也要和开发统一思想，不要私接。所有的变更需求，我要求也要评估时间，评估影响，然后在看做不做
全凭经验估算。。。自己估算的时间 哭着加班也要干完 然后下次可以➕buffer
洋葱
回复
研发多测试人少，往往需求会叠加，产品新手，沟通不畅，导致到测试手里往往是多个叠加，老大有时候强压上线。我预估时间就会多加几天。传统的互联网公司就这样，哎。