51Testing软件测试论坛

标题: 如何正确估算测试周期 [打印本页]

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

我们在估算测试周期的时候,需要考虑进这些意外事件.我们通过表格简单说明下:
当出现以下情况时,该内容生效.
事件                细分             需要时间                   测试周期             责任方
没有达到测试提交标准具体什么原因    开发方解决问题的时间          顺延             开发方
中止测试             原因                同上                   顺延             开发方
测试资源变更测试人员请假,调岗等该测试人员剩余工作量的时间顺延或其他人员顶替    测试方
多轮次测试原因下一轮测试时间启用下一轮测试周期                                  开发方
…. …… …… ….. …….
注:有理由的变更前期的计划,这是你应该做到的.

说了那么多,还是没有说明具体怎么来做这个周期的估算,通过什么手段和工具来做.其实这个并不重要,象word ,project,excel等都可以,我都见过类似的摸板.无论你用表格还是树型图,还是梯状图,只要你能把工作内容,测试资源,时间三者的关系表示清楚就可以了.
这方面我经验也不多,说的也不好,就算是抛砖引玉吧,希望专业人士能私下和我交流,也欢迎想了解这方面内容的一起探讨.

作者: Ego 时间: 2008-3-7 11:53
顶！

作者: dandan 时间: 2008-3-7 12:03
顶，分析得不错....

作者: 庖丁解牛 时间: 2008-3-7 15:19
熟悉测试系统,
做计划的时候能够熟悉测试系统，那可真是“高手之中的高手了”

明确测试资源
资源随时在变，形势的每天在变

细化测试标准
如何细才够细？

作者: kuailederen 时间: 2008-3-7 15:43
好象你有些误解我的意思了
测试周期的估算是说在开始才而是之前,用来评估测试成本和项目进度的工作.当然也在计划之前了.
无论是评估测试周期还是制定测试计划,都建立在对测试系统非常熟悉的基础上,这点是无庸质疑的
无论这些信息是来自需求分析还是来自开发文档或者讲解(大部分是直接来自系统,因为目前现状就是这样,集成以后才进入测试)
你都必须去做这项工作,不然谁都可以做项目经理了.
测试资源指的是测试人员,不会每天都在变化吧
细化测试准则,如果你见过一些规范做的比较好的公司,就知道如何细化了,我在文章中只是列举了影响测试周期的几个重要方面.

希望提出更多的疑义,来一起学习.

作者: rting 时间: 2008-6-6 17:15
我们所说的测试周期,就是从领导下达测试任务开始,到测试达到测试通过标准为止

哪么作为一个领导什么时候下达测试任务好呢？

作者: liangjz 时间: 2008-6-11 21:20
说起来容易做起来难

我们执行做，尽量让测试尽早切入。然后根据历史经验来估计工时

作者: echo5410 时间: 2008-7-7 10:52
学习

作者: stefanie9902 时间: 2008-7-29 21:00

又学习了下高深的理论知识！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)