您的位置:首页 > 运维架构 > 网站架构

架构之路(四):测试驱动

2016-02-20 18:53 465 查看
摘要:测试驱动有着更宽广的概念,他要求以“测试”为驱动力,来推动整个开发活动。似乎相当多的人认为这个观点根本不具有可执行性。但当我第一眼接触这个观点,我就觉得,它像一道闪电划破长空,光华璀璨,价值无以伦比!

【编者按】本文作者自由飞是一个奇人, 彻彻底底的非科班程序员:98年读大学-国际贸易专业、03年11月英语培训机构当英语老师、04年2月-05年6月律师事务所实习和公司法务、05年6月-07年12月成立装饰公司做老板、08年8月软件公司做程序员。

作者从文科生转学编程,毫无基础,一年入门,距今七年,目的很明确,就是奔着“架构”来的。受到《野生程序言的故事》一文评论里同学们普遍性的自怨自艾,意欲 为非科班出生程序员代言。接下来,作者将以两个目前仍在开发的项目(详见: 英雄帖:开源项目招募英才)为例,一步一步的讲解,如何通过领域驱动和测试驱动,进行敏捷开发,构建一个面向对象的B/S系统。以下为他倾囊相授的第四篇,第三篇为: 《架构之路(三):单元测试》、第二篇为: 《架构之路(二):性能》、第一篇为: 《架构之路(一):目标》

上一章我们提到, 单元测试只是测试驱动的一个子集;换言之,测试驱动有着更宽广的概念,他要求以“测试”为驱动力,来推动整个开发活动。这个观点似乎非常具有争议性,相当多的人认为其根本不具有可执行性。但很奇怪的是,当我第一眼接触这个观点,我就觉得,它像一道闪电划破长空,它光华璀璨,价值无以伦比!

需求文档可测试化

我第一点想到的,就是需求文档应该可测试化。我不太明白,这样简单有效的一个工作,为什么几乎没有人去做?因为发包方的原因?

大家接触到的需求文档是什么样子的?我从来没有看到过一份我满意的需求文档。都是word格式的,文字加上图片说明。文字都是简单的陈述句说明,比如:用户名不能重复。简明扼要,是不是?是你妈个逼!sorry,我爆粗口了,但这种文档真的会让你疯掉的!

你觉得这是一个很简单的需求,是吧?然后你就噼里啪啦的开始编码了,20分钟搞定,踌躇满志,小case啊!

然后噩梦就开始了。

第一次验收。发包方的眉毛皱了起来,“嗯,其实我想的是那种:当用户把用户名输入完成之后,能立即显示该用户名是否重复,而不用点击提交之后才显示这个结果,你看XXXX网站就是这样的”。OK,Ajax效果是吧?好呢,我改。感谢asp.net mvc,有现成的Remote实现,20分钟,收工,over!

第二次验收。发包方有点不耐烦了,“你这个还是不对啊!你看我给你说了XXXX网站,如果这个用户名不重复的话,要打个勾啊;错了,打个叉,再显示‘用户名重复’的提示啊……”。你有没有想哭的感觉?我忍,含着泪,找个勾勾叉叉的图片,再改。

第三次验收。发包方终于笑了,“不错不错!”你心里一块石头落了地。但这发包方思维很严密,他突然想到一个问题,“你说,假如两个用户同时注册,用的是同样的用户名,这个用户名也是以前数据库里没有的。所以页面输入的时候,肯定是显示用户名有效,是吧?所以他们都可以提交,但他们用户名又是一样的,都提交了就重复了,这时候会发生什么情况?……”你仔细的想了想,是不是觉得晴天霹雳天旋地转?

这只是一个非常非常简单普通的需求,都可以演化出无数种具体实现,更何况其他你可能从来没接触过的复杂需求?你作为一个程序员,只是觉得苦逼郁闷或者还得赶工加班;但对于公司来说,这就是个大麻烦了:工期延误、费用增加、信誉破产……这时候该追究谁的责任?我们可以设想这样的对话:

发包方向你们公司老大抱怨:“张总,你们这个项目都延期好几次了,我不好交代了呀!”

公司老大张总叫来项目经理:“这个项目怎么回事?赶快去催一下。”

项目经理找到你:“怎么一个功能做这么久?你是怎么搞的?”

你:“我怎么搞的?需求改了N遍了!我还想问你是怎么定的需求呢?你看……”

项目经理找到公司老大:“张总,这个客户的需求变了啊!一直改需求,我们……”

公司老大找到发包方:“这个刘总,这个项目你们改了需求啊!不光这个工期不行,费用也得考虑考虑啊,呵呵!”

发包方就炸了,“还要加钱?你们这些个奸商!合同不是写得好好的,一口价……”

“不是改了需求么?”

“我哪里改?就不过‘用户名不能重复’啊,我改成了‘用户名可以重复’?”

“不是。我们最开始以为……,结果……”

“你们为什么最开始不提出来呢?你们是专业人士,你们应该把这些问题考虑到的呀!还亏得我们思虑周全,我们业余人员都能想到的,你们怎么就想不到呢?你们怎么样的一个业务素质?……”

(程序员同学,说句题外话,老板在外面受的气不是你们所能想象的。你以为他们在外面吃喝玩乐好不潇洒,他们实际上就一个“三陪”而已,陪吃陪喝陪笑,不比做小姐的好到哪里去!都是给你们“背黑锅”“揩屁股”啊。)

就事论事,这件事的责任还真赖不到发包方。他的需求最多算是“不明确”,你不能说他“变更”了需求。但是,不明确的需求你接受了,责任就转移到你的身上了。退一万步讲,你是“专业人士”,你真的应该考虑得比发包方周全。

所以,你观察周围经验老到的程序员,他们拿到这个需求是不会立马动手敲代码的。他们一定会想一想,多问几个具体细节,觉得没有问题之后,才开始动手。所以他返工就少,他就是可以不加班,这就是人家的本事。

但是,正如我反复强调的,架构/管理的目的,应该是通过一种制度一种流程来避免上述问题,而不是靠个人技巧经验。追根溯源,解决这个问题,就应该“明确需求”——也就是说,需求不能这样懵懵懂懂大而化之,必须相当的明确清晰,具有唯一性。怎么实现?需求文档可测试化。或者你可以理解为:把需求文档像测试文档一样写。比如,上述需求就变成:

在注册页面

输入用户名xxxx,移出焦点,页面不刷新,显示图标“叉”和错误提示:用户名重复
输入用户名yyyy,移出 焦点,页面不刷新,显示图标“勾”
……

这份需求/测试文档,交发包方审核确认;之后验收,就严格按该文档逐项进行,所有测试通过,验收合格。如果需要加需求,一般都得加测试;加测试,那不用说,我们就来谈谈时间费用的问题。

BuildDatabase

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

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

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

以test-1112为用户名注册一个新用户
再使用test-1112为用户名进行注册
页面显示错误提示:用户名重复
……

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

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

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

使用test-1112为用户名进行注册
页面显示错误提示:用户名重复

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“你重新BuildDatabase再跑!”

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

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

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

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

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

(责编/钱曙光,关注架构和算法领域,qianshg@csdn.net)
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: