qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

跨出编写300个用例的第一步

接到一个项目,一个大日常,跨很多应用,形成了标准的开发测试N:1,满心欢喜觉得自己终于可以独当一面了。可是当拿到N个UC的时候,就有种瞬间傻眼的感觉。

  但是由于越觉得这个工程很庞大,越想早点开始启动自己的工作,遂会好不容易找到一个突破口就急于开始写用例。

  刚冥思苦想出第一个文件夹的名字后,在这个模块下,想到什么写什么,想不出来的时候,又开始想第二个文件夹的名字,想下一个模块要写什么。当写到第十几个文件夹的时候突然想起第N个文件夹中好像少了一个用例,又每个文件夹,点开看里面的内容,回顾这个文件夹大致覆盖了哪些用例,看看缺少的这个用例该怎么补。也许庆幸的是,找到了那个文件夹补充好这个用例,但是当你写到第几十个文件夹时,过了几天以后,想到好像漏覆盖了什么功能点,那可能不是就仅仅浪费几分钟去找这个文件夹,而是可能会花上大段的时间去回想自己写了什么,这个时候的思路打断就会让你觉得不知道下一步该怎么走,思路越来越乱,下面的用例到底应该以什么纬度进行下去,还有多少的用例被遗漏掉了,什么用例是不需要写,什么用例是需要覆盖的,突然就会对用例有种不可控的感觉。

  但是,如果一个测试人员对自己的用例都无法控制,那还有谁可以来了解用例的覆盖度,用例的纬度。后面的回归测试同学,如何来有序的进行回归,用例的迁移该会是多么痛苦的一件事。

  其实每个人的测试思路会不同,测试习惯也会不同,所以用例可能就会用不同的方式来写。这些都固然没错,但是用例必须要有个纬度划分,有个整体的一个流线。有利于测试,也有利于用例的review及评审,思维可以顺着下来。

  老人是一个很好的灯塔,他可以指引你怎么前进,有时候自己真的一点没有头绪的时候,可以看看以前的用例以怎样的纬度划分,找个较熟悉该应用的老大,问问如果是你,会怎么着手写这些用例。千万不要在自己没有头绪的时候就开始写第一个用例,有可能会越写越乱,写到最后漏了一大片,冗余了一大片。先确定好用例大体以怎么样的几个大方向来写,比如,按照应用来分,sell一块,mickley一块,forest一块;按照测试顺序,先后台建类目,再前台发布,等等。

  确定一个方案还不够的,这个只是个骨架,这些只是好让你定好一级的文件夹名字。不要就开始写用例了,要不然你定好了几个文件夹名字后又会开始不知道怎么入手了,文件夹下要测试哪些东西呢?所以下面的测试设计很重要,列好几个一级文件夹,对照UC看下一级文件夹是什么,一直设计到叶子文件夹要写哪些功能点。最好可以进行测试设计评审,让开发和老人一起评估下,有没有测试用例覆盖漏掉的点,这个时候修改方向,补充漏写的点,很容易,一目了然。

  虽然这可能会花去你一天的时间,你会觉得很可惜,但是这对后面的工作将会有很大的作用,对功能点已经比较熟悉,对用例编写的思路也很清晰,只要对照设计一步一步往下写就可以了,就不用说动不动就停下来绞尽脑汁在想要写什么东西,尤其是对新人来说,对已有的用例也不熟悉,不知道到底应该写哪些用例,需要测试哪些点,这个就尤为重要了。

  300个用例并不可怕,但是不可控的100个用例就会让人很昏头转向。定好方向,做好设计,建好层级,个个攻破,500个用例都将是可控的。

posted on 2011-11-21 13:44 顺其自然EVO 阅读(102) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2011年11月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜