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

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

51Testing软件测试网d?#Ix+u`!NS7`

  编写背景:

%KT)xSF^'w051Testing软件测试网.ki-KEC^4[

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

0`0@+V,gj\2A W0y0

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

D;Z0h n C"VZ-X{051Testing软件测试网u8f-m1r,z

  案例描述:开发阶段的测试用例如何设计51Testing软件测试网(t]!{'_)EZ%CWi

*r.`^/mK9Y'F0  常遇到这类问题,开发阶段的策划案经常修改,程序也经常调整,而一份详细的测试用例要花费几倍的测试时间,好不容易完成了,只要策划案子一修改,以前做的就白费了,部门很多人也不赞成写测试用例,认为对于一个老测试员来说,这根本是不必要的,是只工作时间的浪费,而且以目前的工作量来说,根本没有时间写,对于不稳定的异变的程序来说,意义也不大,在这种环境中,如何推广测试用例呢?测试用例的存在有何意义?sdlkfj851Testing软件测试网&q3H.tG2LI-w

51Testing软件测试网'oNq?U B[,[

  我的回复:

rxLA e1R2z0

?T#d+T_O4Z:o K0  今天回头看了一下这个帖子,发现有这么几点问题:51Testing软件测试网(i#Xx._e J

z @1G'Db DwL0  1、首先帖子的标题是:开发阶段的测试用例如何设计51Testing软件测试网R:]-b+KHh'G~Q(I

51Testing软件测试网|)I%\e#ix`!_n@6}

  没看帖子内容,一看这个题目就觉得很奇怪,测试用例的设计和开发阶段有什么关系。具体看了帖子内容后才明白,原来是,测试用例设计好后,在开发阶段时出现需求变更,导致测试用例要进行变化的现象。51Testing软件测试网;u\&VIw

#I(a-c9Y)ha0  建议楼主把帖子标题改成:开发阶段遇到需求变更,测试用例如何控制。这样帖子标题和内容更一一对应上。51Testing软件测试网Q-E+l7J~(q~

:U/[z~ UHYaXm0  2、在帖子的内容中,描述了如下的几个观点和现象:51Testing软件测试网^y2n,KC^8aX

51Testing软件测试网$i%{Hd W,kZ.o

  1)开发阶段的策划案经常修改,程序也经常调整,而一份详细的测试用例要花费几倍的测试时间,好不容易完成了,只要策划案子一修改,以前做的就白费了。51Testing软件测试网6sb0} @*|0E+P&@

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

6MX!j8z]gi*G051Testing软件测试网 oz ^#Ka%|es%yX

  3)在这种环境中,如何推广测试用例呢?测试用例的存在有何意义?51Testing软件测试网9E}@ b'CVD

51Testing软件测试网"D F2^7A1}w?NQt:v

  我的观点如下:51Testing软件测试网9I|3@2C4nY0s!}

51Testing软件测试网J:[G$z?m1o

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

O#Y6n0D;{5ak0B.s#`0  如果你的测试用例是关于白盒的测试用于单元测试阶段的话,这真的很惨,有一种花费了很高成本做好的东西拿出去卖,没人买,被耍的感觉。我没遇到这样的现象,目前不知道是怎么应对的。

m^"\*Rj`*l0O0

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

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

1q f#I,Aa0r*cg Xh"K051Testing软件测试网vk%x!Z,nH1Z

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

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


TAG:

 

评分:0

我来说两句

Open Toolbar