微信号:grzlwx

介绍:光荣之路官方资讯

看看序员们怎么做?架构之路之测试驱动(二)

2015-10-13 23:11 光荣之路


BuildDatabase

在一些文档规范严格的公司,实际上是同时 有一份开发文档和测试文档的。但开发人员在整个开发过程中,并没有参考测试文档,所以最后就很容易造成测试阶段开发人员不断地返工,开发人员和测试人员之 间矛盾尖锐。但最终80%的情况,还是开发的问题,毕竟你是做事的人,人家是检查的人。所以为什么不从一开始,就把需求文档、测试文档和开发文档合其为一 呢?(当然,分开写,会有一些“监督”的作用,但我始终觉得,这种监督效率不高,投入产出不划算)

而且我发现,这些测试文档,都有一个问题:操作繁琐不经济。

仍以“用户名不能重复”为例,我看到的测试文档大致就是这样写的:

  1. 以test-1112为用户名注册一个新用户

  2. 再使用test-1112为用户名进行注册

  3. 页面显示错误提示:用户名重复

  4. ……

表面上看起来没有问题,但是如果测试次数多了的话,就会感觉每次先去注册一个新用户很麻烦。而且,这只是最简单的功能,如果功能复杂,要求准备的数据多/难/特殊,怎么办?我们又讲一个故事吧。

项目上线前夕,测试人手不够,我们开发过去帮忙。我跑一个test case,跑了一个多星期!你信不信?我的问题就在于测试的这个数据做不出来。测试文档是一步步写清楚了的,但你这样做不下去:权限不够、数据已有变化、 文档模糊……到处找人问。找到懂这事的人,中途又发现,程序(页面)发生了更改,有些功能跑不起来……最后一个workaround,得改数据库,数据库 又得找DBA啊……总之,这个test case搞得鸡飞狗跳,好在最后还是跑出来了——但以后(下一次)怎么办, 我就不知道了。

本质上,这种做法,测试数据是要测试人员自己“做”,或者“找”的,有很多问题。所以,从那时开始,我就在想:能不能把测试用的数据“固化”下来?让测试人员就基本上不用“做”,或者很方便的就能“找”打测试数据。比如:“用户名不能重复”的文档就直接写成:

  1. 使用test-1112为用户名进行注册

  2. 页面显示错误提示:用户名重复

最多加一个说明:test-1112是已有用户名,用户名不能重复。

这个诱惑一直吸引着我,最后我在solution中就引入了一个BuildDatatase项目,专门为开发测试准备数据。毫无疑问,这个决定也遭到了开发人员的抵制。因为这个数据也不是那么好做的,具体我们将在项目详解里谈。

我铁腕推行,大概经过了两件事,他们慢慢的就习惯/认同了这种做法。

第一件事,是任务列表页面。开发代码之前是写好了的,而且已经跑了一段时间了。我让他为该页面重新创建测试数据,他一脸不可置信:这种筛选排序,天?要准备多少数据?!怎么准备?代码都写好了,跑得好好的,有必要吗?

我让他先冷静一下。然后有以下对话:

“如果你不准备这些数据,你怎么保证你代码的正确性?”我问。

“就直接在页面上建几个任务啊,然后跑一下。”他想了想。

“要建几个呢?”我继续追问。

“……”,他一时答不出来。

“随便做几个数据,随便的跑一跑,然后就不管了,是吧?你以前就是这样做的?”,我接着说,“所以我们的代码没有质量。然后如果没有专门的测试呢, 就让用户当免费测试员;有测试呢,我们就把这些脏活累活扔给他们。他们一遍遍的报bug跑不过,我们还不服气还有怨气……为什么我们不一开始就把它做好 呢?”

首先确定要做,然后再想办法!很快我们就想到了一个办法,反过来做:满足所有筛选条件的任务就一条,然后逐个的减少筛选条件,每少一个筛选条件,就 增加一个适格任务。这样理下来,共计25条数据就够了,并没有我们想象的多。从构思到文档再到最后“造”完所有任务,差不多花了一个下午的时间而已。最 后,戏剧性的是:出效果了!跑一遍,我们立马发现了代码里面的两个bug。因为这种query查询写代码的时候都“复制粘贴”的,十几个条件,难免出错。如果不是这样跑一次,这些bug不知道什么时候能冒出来——因为我们自己用的筛选条件比较固定的,某些筛选条件从来没用过。所以我问他:你之前说“跑得好好的”?他只能呵呵了。

第二件事,是在任务编辑页面,我们要测试父子任务关系之间的自动化功能,这就需要比较复杂的一个“任务树”做开 发测试数据,好在我们是做了的。代码review的时候,我在我这边一跑,不对,就直接打回去了;过了一会,他跑过来,代码没问题啊?当时我们脑子都短 路,没想到其他,就先去看代码去了,折腾了好久。在他电脑上跑,然后又在我电脑上跑,又是设断点,又是看逻辑。

后来我突然灵光一闪,“是不是数据的问题?”

“嗯,有可能。但怎么确定呢?”

“你重新BuildDatabase再跑!”

果不其然,原来他自己跑的时候改动了数据,然后就忘了呀,一直就在已变动的数据上跑,当然没问题了。亏得我们有BuildDatabase,可以随时重建“基准”数据,否则,这种问题是相当花冤枉时间的!

这类似的情况其实很多很多,测试人员报bug之后,我估计开发人员最常用的一句台词就是:“我这里都能跑啊?!”所以问题80%都出在数据上——那为什么我们的数据就不能规范统一起来呢?

通过BuildDatabase,建立一个有序的可控的数据库,我们才能够在此基础上进行一系列的(测试驱动的)文档编写、开发和测试活动。所以说,BuildDatabase是“测试驱动”的基石和保障。除此以外,BuildDatabase还可以在项目发布、模拟展示等方面发挥重要作用。

(我以前公司的集成测试环境这些,数据库都是从生产环境中copy或截取的,我们需要的数据都是“自己造”,或者“自己找”的。这样做能基 本满足开发测试需要,但中间总是很容易“出篓子”——正如我前面所说,一个test case可以跑一周。而且随着数据增加,这个copy也越来越难啊,一次导几百个G终究很累,所以好像是到了一定时候,还是得自行维护测试数据库——但维 护主要是数据结构上的,比如增减列之类的,数据本身是无法维护的。

我很好奇,除了我的builddatabase以外,有没有其他比较可行的办法?欢迎大家踊跃交流!)

老规矩,说项目进展情况。任务管理系统修了一些小bug,主要是“任务树(关系)”可以向上向下自由展开了。接下来的主要工作是完善文档,方便新加入的同学能迅速上手跑源代码。唉~~~想到写文档就苦逼啊!我最爱代码,恨文档!!!



本系列目录:架构之路
争取每周一更,你的支持鼓励(推荐评论)和鞭策(拍砖催更)是我坚持的动力。
所涉及的项目均为本人真实开源项目。欢迎大家的参与,详见:
英雄帖:开源项目招募英才

(完)

(作者:来源:http://www.cnblogs.com/freeflying/p/4846618.html)


  
             
  
             
  
             
  
            
  
            
  
            
  
            
  
            
  
            
  
            
  
            
  
            
  
            

感谢作者,传播测试知识、技能与正能量!
欢迎来稿,分享你的测试生活!735821166@qq.com

光荣之路软件测试培训

官网:http://www.gloryroad.cn/

微信公众号:gloryroadtrain

性能测试QQ群:415987441
软件测试招聘QQ群: 203715128
自动化3群QQ: 371211499


 
光荣之路 更多文章 今天晚上的 linux 公开课- Awk 编程 7月28日(今天)晚上的 linux 公开课- shell编程 8月4日(今天)晚上的 linux 公开课- shell编程 9月1日(本周一)晚8点半,光荣之路Web自动化系列基础课—javascript第二讲 推荐本好书《与机器赛跑》
猜您喜欢 程序员面试技巧总结 [精校版]Using Swift with Cocoa and Objective-C--互用性--Cocoa数据类型 8点1氪:苹果公司在印度出售二手iPhone计划遭拒;华为女士专用智能手表在美国开售,起步价500美元 教你编写第一个Python程序 [实践]数据科学驱动力矩阵方法介绍