最近老听一些测试的朋友抱怨,说制定出来的测试周期领导是如何如何的不满意.也有一些朋友私下问我如何来正确的评估测试周期.我告诉他们,办法是有的,但必须要做到三个前提条件.那就是:熟悉测试系统,明确测试资源,细化测试标准.
在讲这三个前提前,我们先来了解下什么是测试周期.测试周期是软件生命周期的一个阶段,他从测试的介入开始,到测试完成结束.更好理解的讲,更切合实际的讲,我们所说的测试周期,就是从领导下达测试任务开始,到测试达到测试通过标准为止,对产品来说是产品上线,对项目来说是项目通过验收.(请不要告诉我说是从需求开始,请问你们有几个见过可以根据需求来做测试的需求?)
作为领导他当然最关心测试周期了,因为他关心项目的进度和测试的成本,而时间正是他们所关心的中心问题,所以说只有合理的,紧凑的,饱满的时间安排才符合他们的要求,这就是我为什么说要作好测试周期的估算,必须做到三个前提条件,这是我们做测试周期估算的前提条件, 也是说服领导我们的测试周期估算是合理的证据.
我们先来看一个例子,要建筑一栋大楼,那么在建造之前肯定要设计好建筑图纸,然后根据图纸能估算出需要多少耗材,需要多少人工和需要多少时间才能完成,从而就能估算出需要花费多少成本.我认为我们的测试周期估算也类似.
熟悉测试系统
这正是根据图纸来估算需要多少耗材和人工的时候.一个系统有多少模块,有多少功能点,甚至每个功能点要怎么来测试(设计多少测试用例才能覆盖),作为一个测试组长,测试负责人,你都要心中十分清楚.在目前大部分公司没有需求管理的情况下,这就要求测试负责人要付出更多的努力去熟悉测试系统.(可能有人会说,如果系统还没开发完成,那怎么来熟悉呢? 哈哈,发挥你作为测试人员刨根问底的特长吧,反正这部分工作一定要作好).设想,你前期能了解到系统共有六大模块,250个主要功能点,细化为1000个测试功能点,大约需要3000个用例来覆盖,那你还不知道有多少工作量吗? 只要知道有多少测试资源(人工),那么就简化成一道小学应用题了.
明确测试资源
主要是指,要多少测试人员可以参加,他们的技术特长和测试经验及对该测试任务的熟悉程度. 我们要根据这些来给他们分配工作内容和工作量,并且根据这些来估算他们工作效率.(单位时间内所完成的工作任务). 现在有1000个工件需要做,有4个工人,甲每天做3个工件,乙每天做4个工件,丙每天做5个工件,丁每天做6个工件,那么问完成1000个工件总共需要多少天? 问题就这么简单,前提条件是你要清楚内在的因素.
我知道问题远没有那么简单,有人肯定会问需求变更了呢?人员调整了呢?测试中间出现意外呢?要经过多伦次测试呢?其他不可预知的因素影响测试进度呢?........疑问很多,但我们还是要面对.
细化测试准则
在测试开始之初,我强烈建议做好以下测试准则:
测试启动标准,要求开发方必须对主要功能做测试,保证提交过来的测试程序可以测试,不出现不可安装卸载,功能没实现或者存在重大功能缺陷的问题.
通过测试标准:测试达到什么程度,缺陷修复到什么程度,即可通过测试.一般从BUG的级别上来判断(要对BUG级别有个明确的定义哦).
中止测试标准:如果测试过程中出现那些问题,就要中止测试.一般指出现不可安装,功能性重大缺陷导致测试无法进行下去.
进入下一轮测试标准: 如果一轮次测试没有通过,那么就要进入下一轮测试.就是什么情况下,有多少测试用例没有通过,需要进入下一轮测试.
我们在估算测试周期的时候,需要考虑进这些意外事件.我们通过表格简单说明下:
当出现以下情况时,
该内容生效.
事件 细分 需要时间 测试周期 责任方没有达到测试提交标准 具体什么原因 开发方解决问题的时间 顺延 开发方中止测试 原因 同上 顺延 开发方测试资源变更 测试人员请假,调岗等 该测试人员剩余工作量的时间 顺延或其他人员顶替 测试方多轮次测试 原因 下一轮测试时间 启用下一轮测试周期 开发方
…. …… …… ….. …….
注:有理由的变更前期的计划,这是你应该做到的.
说了那么多,还是没有说明具体怎么来做这个周期的估算,通过什么手段和工具来做.其实这个并不重要,象word ,project,excel等都可以,我都见过类似的摸板.无论你用表格还是树型图,还是梯状图,只要你能把 工作内容,测试资源,时间三者的关系表示清楚就可以了.