灌水 请教各位在功能测试项目中如何做测试时间评估

洋葱 · 2017年12月26日 · 最后由 雷子 回复于 2017年12月27日 · 3224 次阅读

近期在整理部门测试流程方面的一些东西,把之前根据经验,根据感觉来做的一些工作转为有文档可依的工作流程。
遇到测试时间评估没有具体方法的问题,这里准确的说,是测试执行时间,想请教大家。

我回忆了老东家的方法,通过长时间的经验,根据测试数据准备,测试步骤多少,执行复杂度,来评估出测试执行时间。
但是老东家是做对企业交付的,有完备的自动化和手工回归测试流程,项目时间也充足,3 个月一个版本往往只有 5 个以内的 bug。

对应到现在的公司,3 周一个迭代,需求规模庞大,并且不是清晰的 checklist 形式;测试用例规模大致每期在 500+(单测试点一条用例)。
在评估测试时间的时候往往还没开始写用例,评估出的时间较为不准确,总是会造成最后的加班发生。

大家一般是怎么评估每个迭代的测试执行时间?有什么具体的方法呢。

共收到 8 条回复 时间 点赞

我一般评估度,会确定本次修改内容,牵涉平台,对现有系统的影响进行评估,对 checklist 进行估算,一般每个测试环境 给 2-3 天的测试期,1-2 天的改 bug 期,依据开发预估的提测日期,给 2-3 的天开发缓冲期,测试后期留 1-2 天的延后期。不过在实践中,我发现,这个计算的周期会因为项目进度受影响,目前会上线出现加班通宵上线情况,主要在我们流程上面不完善,沟通不顺畅。临时会接很多别的临时的需求,加上产品新手情况,最近预估的十次有八次需要加班,沟通不畅。

结合目前项目的情况,我们版本迭代也很频繁,每位还是根据需求内容、测试的复杂度、对业务的熟悉程度、开发是否有时间修改 bug 来评估测试时间

跟项目类型有关吧,按照我的经验,普通的应用和游戏差别还是挺大的。
一般我都会加很多 buffer,理想情况是 double

edsion 回复

留 buffer 这个工作在我的理解中应该是项目经理的工作,如果我在给出的时间中预留,需求方就会过来问这个地方的时间具体是在做什么,然后设法砍掉,所以想找一个有理可据的方法

雷子 回复

临时的需求,目前的我采用的做法是 在项目中固定安排一个时间点允许需求方修改或者增加需求。这样需求方知道可以增加,也就不会频繁的变更,当然也要和开发统一思想,不要私接。所有的变更需求,我要求也要评估时间,评估影响,然后在看做不做

假精哟 回复

能具体说说么,一旦 double,需求方回来说不够细,这个地方为什么这么多时间,在干什么.....

全凭经验估算。。。自己估算的时间 哭着加班也要干完 然后下次可以➕buffer

洋葱 回复

研发多测试人少,往往需求会叠加,产品新手,沟通不畅,导致到测试手里往往是多个叠加,老大有时候强压上线。我预估时间就会多加几天。传统的互联网公司就这样,哎。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册