开发阶段遇到需求变更,软件测试用例如何控制

上一篇 / 下一篇  2012-07-06 11:22:44 / 个人分类:测试经验

x4JL7eG L'o:b0  编写背景:

N"U LY3\d/fN0

]1pK1__*d b0  今天上我那块测试论坛的菜地看看去了,想把一些东西给规整规整,对其中的一个帖子发表了好长的感慨,大家有空可看看。^_^。

u']+S"\@#[;P"SWO0

开发阶段遇到需求变更,测试用例如何控制!!!51Testing软件测试网Kg+G%T*G

%NK,j)\7C1kq0  案例描述:开发阶段的测试用例如何设计

/Sg@8^*W2H d,sF9^w)E0

i:]Yv;|b7j#]W0  常遇到这类问题,开发阶段的策划案经常修改,程序也经常调整,而一份详细的测试用例要花费几倍的测试时间,好不容易完成了,只要策划案子一修改,以前做的就白费了,部门很多人也不赞成写测试用例,认为对于一个老测试员来说,这根本是不必要的,是只工作时间的浪费,而且以目前的工作量来说,根本没有时间写,对于不稳定的异变的程序来说,意义也不大,在这种环境中,如何推广测试用例呢?测试用例的存在有何意义?sdlkfj8

/}\mo&T-Vv mb0

G3Q z QLg9[0  我的回复:51Testing软件测试网w/eCRX;P"Qs

51Testing软件测试网 q CS3^A S$Hc

  今天回头看了一下这个帖子,发现有这么几点问题:

^7s2T b:Hi @051Testing软件测试网 _C]"[Vxw$n0C

  1、首先帖子的标题是:开发阶段的测试用例如何设计51Testing软件测试网;_G4{{C1Gb~*W

Of%};})D'\p#hh6b9A0  没看帖子内容,一看这个题目就觉得很奇怪,测试用例的设计和开发阶段有什么关系。具体看了帖子内容后才明白,原来是,测试用例设计好后,在开发阶段时出现需求变更,导致测试用例要进行变化的现象。51Testing软件测试网M@_"y!wa,}V|

51Testing软件测试网(Y8y!o5Ac~M

  建议楼主把帖子标题改成:开发阶段遇到需求变更,测试用例如何控制。这样帖子标题和内容更一一对应上。

?RZ+Vd'Z;@ R0

0TNV/R`Dx0  2、在帖子的内容中,描述了如下的几个观点和现象:

E+R-eS}'~051Testing软件测试网~hZqHt+A P

  1)开发阶段的策划案经常修改,程序也经常调整,而一份详细的测试用例要花费几倍的测试时间,好不容易完成了,只要策划案子一修改,以前做的就白费了。

kur%V4b3q-J051Testing软件测试网.Pv;];L+u ]B

  2)部门很多人也不赞成写测试用例,认为对于一个老测试员来说,这根本是不必要的,是只工作时间的浪费,而且以目前的工作量来说,根本没有时间写,对于不稳定的异变的程序来说,意义也不大51Testing软件测试网 I rABRTS

\2w|\ { r7Li-}c0  3)在这种环境中,如何推广测试用例呢?测试用例的存在有何意义?51Testing软件测试网ja bpvG4u

51Testing软件测试网q:Y;x/`;M-@-C

  我的观点如下:

&he K&_XO yj0

%q0lDG'DG i cg2iY2w0  对于第1个,开发阶段需求会有变化;我在猜想,如果你的测试用例是关于黑盒/灰盒的测试用于系统测试阶 段的话,在开发阶段需求发生变更,从结果上就可以知道,这个需求前期做的有问题,要么是用户不明白自己要做什么,不然就是需求人员没有搞懂用户到底要做什 么;之所以让用例修改,祸根就是需求的变化不是人家开发惹得祸;要弄清楚病根到底在哪里,才好下药。应对办法,测试前期参与需求理解、从测试的角度去把需 求中不明确的地方弄清楚;在写测试用例的时候、尽量简洁明了可以节省时间,这就是写作技巧的能力了。

5Rt Fw!eF0

%N yA]$A}d+G*l0  如果你的测试用例是关于白盒的测试用于单元测试阶段的话,这真的很惨,有一种花费了很高成本做好的东西拿出去卖,没人买,被耍的感觉。我没遇到这样的现象,目前不知道是怎么应对的。

K7BMe X r f7Zn0

SK5xP a0   对于第2个,部门很多人不赞成写测试用例,原因是:浪费时间没有必要,其次是没有时间写,最后就成了意义不大。我在想,做测试的如果没有时间写测试用 例、来一个产品就随便点点、想怎么用就怎么用,这叫测试吗?这不叫测试,这叫试用。我看不想写用例的根本原因一个是:懒,说白了就是对这个工作忽悠过就得 了;在就是自己感觉对这个东西挺熟悉的,有经验,不写用例也可以点出问题来,这说明程序写的很烂、试用都能用出一堆问题。有责任心的人,当测试过的产品在 用户那边出现一堆问题的时候,就会自我反省那个地方漏测了,没有写用例的人往往会漏的很多。把测试用例看的那么没有意义、那么不重要,我在想你们部门应该 是个产品试用部门吧,还算不上真正的测试。

n"dLB ftv0

H2aVL3M5p0  对于第3个,我觉的很好玩也很奇怪,基于上面的1和2点,把测试用例看得那么不重要、那么没 有意义,为什么还要推广呢,你自己都不认为很重要的东西想让旁边的人认为重要,很难、非常的困难。想要把一个好的东西介绍给人使用,首先自己要觉得它很有 价值,然后要让大家看到实实在在的价值和帮助、还有好处,这样才会得到认同。不过我觉得你那的环境比较困难,从你上面的描述得出,非常的困难、不是一般的 困难、是相当的困难。51Testing软件测试网[%u"uJ y

51Testing软件测试网"L0}m;W2SL g1p

  嘿嘿,写了那么多,不知道能否对你有启发,祝你好运了。^_^。51Testing软件测试网}qCiR5~

51Testing软件测试网!l2~h8v:zblAx/q

  最后回到正题,开发阶段遇到需求变更,测试用例如何控制? 问题已经出现了,需求已经变了,该怎么办?那只能修改测试用例咯,然后告诉具体负责人,需求变更已经影响到了测试的进度和工作,做好这方面的时间工期应对风险。

m EL"\YG0

TAG:

 

评分:0

我来说两句

Open Toolbar