51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 2226|回复: 4

[讨论] 项目管理(一):文档可测试化

[复制链接]
  • TA的每日心情
    无聊
    2024-3-7 09:16
  • 签到天数: 43 天

    连续签到: 2 天

    [LV.5]测试团长

    发表于 2018-3-21 15:32:11 | 显示全部楼层 |阅读模式
    需求文档可测试化

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

    大家接触到的需求文档是什么样子的?我从来没有看到过一份我满意的需求文档。都是word格式的,文字加
    上图片说明。文字都是简单的陈述句说明,比如:用户名不能重复。简明扼要,是不是?


    你觉得这是一个很简单的需求,是吧?然后你就噼里啪啦的开始编码了,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
    还可以在项目发布、模拟展示等方面发挥重要作用。

    回复

    使用道具 举报

  • TA的每日心情
    开心
    2018-6-13 16:30
  • 签到天数: 31 天

    连续签到: 1 天

    [LV.5]测试团长

    发表于 2018-3-23 14:51:53 | 显示全部楼层
    谢谢楼主的好文章分享!
    对于楼主提出的“需求文档可测试化” 问题, 我十分赞同。
    有时,可能项目经理都没理清全面关系就抛出来改改改了。
    而且我个人认为测试人员很有必要对需求重新梳理一遍,既加深业务理解,也可能会发现一些之前没考虑到的需求细节。

    另,看楼主对BuildDatabase用处描述,引起了我兴趣。想自己也整个,然后百度了下,懵。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2019-1-17 15:54:56 | 显示全部楼层
    楼主,你在哪个项目里面讲解了?
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-3-29 23:07 , Processed in 0.063392 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表