测试进阶
首发于测试进阶
从数据驱动到各种驱动

从数据驱动到各种驱动

分享一点自动化测试的基础概念,希望对大家有帮助。


一、数据驱动

数据驱动如果大家做自动化测试的话一定不会陌生了。

一般拿到一个待测软件功能之后,我们会去从各个角度考虑怎么测,比如James Bach等人的快速测试里有一个SFDIPOT方法,从结构、功能、数据、接口、平台、操作、时间等角度来分析。

而数据驱动就是从数据角度,我去考虑这个功能能接受哪些输入数据,会输出什么样的结果。对于自动化测试,这一点尤其有用。因为对同样的操作,我可以用不同的输入数据,并预期不同的结果。

举个例子,我要自动化测试的方式测一个用户登录。那么我要考虑多种不同的测试数据输入,比如正确的用户名密码,错误的用户名密码,等等等等,也就是所谓等价类划分。这些划分的结果作为测试数据记下来。同样对应的预期结果,也是某种意义上的测试数据,也记下来。比如是这样:


那么,一个非数据驱动的自动化测试里,可能我要写4个case,每个case用不同的用户名和密码,并与其不同的结果。要测这个功能时执行4条case。

而在数据驱动的自动化测试里,我只会写1个case,这个case里可能用户名密码还有登录结果的返回信息都是变量,通过某种方式把上述表格里的值依次传入到这些变量里。要测这个功能时,只执行1条case,但是用不同的数据。

数据驱动就是这么简单。因为重用了测试的业务逻辑(比如登录),测试脚本的维护量降低了。未来你如果要多测一些其他用户名密码的登录情况,比如测试一些特殊字符的用户名,那么只需要在表格里多加几行。现在所有主流的测试执行器,都支持数据驱动。比如testNG有data provider标签,robot framework有test template,等等。


那么关于数据驱动要注意的点呢:

(注意以下注意点不能生搬硬套到实际项目,具体项目一定要具体分析)

1.我看到有很多人把数据放在excel里,来做数据驱动。这不是不行,只是比较重量级。用csv都比用excel容易点。

2.有人把数据放在xml里,来做数据驱动。个人觉得是比较麻烦的,很可能作者是常年用java受到了java的设计思想影响。

3.有人把数据放在数据库里,这也可以,但是数据库的问题是没有版本控制。个人不太建议。除非你的项目比较特殊。

4.我个人建议的做法,像robot framework里的test template那样的数据驱动我觉得是比较好的。

5.数据驱动只是把数据和对应的预期结果抽离出来,不要把测试步骤也当作数据抽离出来,虽然可以做,但很可能抽过了头。


二、关键字驱动

关键字驱动的出场率也是比较高的,仅次于数据驱动了。

关键字驱动的思路是,我把具体的测试业务实现看作一个一个的关键字,具体怎么实现我不管。我只是用这些关键字把我的自动化测试搭出来。

这样做的好处,最大的好处就是写自动化测试脚本的人可以不懂技术,而单纯只使用关键字。缺点是,我要维护一层伪代码的关键字层。但维护这层伪代码又得到一个好处,业务逻辑的表述更清晰了。同样也带来一个坏处,关键字驱动的调试可能比较困难。总之关键字驱动是有好有坏,很纠结的一种技术。其代表作品是robot framework,据说这个框架曾经是我诺基亚的人搞出来的,所以现在诺基亚公司还在用这个框架。

关键字驱动也可以用表格来描述,举个例子,在百度搜索“测试进阶":

这是一种常见的关键字驱动测试用例,第一列是关键字,第二列是测试数据。同样,根据你的抽象程度不同,你还可以做出这样的用例:


只有一列了,这一列就只包含关键字,不包含数据。但是关键字的特点就在于,关键字可以一层套一层。第一层关键字“打开百度”,他的实现是第二层关键字“打开URL baidu.com”,第二层关键字的实现可能是某种编程语言和具体的库,比如用python和selenium。你可以给一个关键字驱动测试用例套好多层,在每一个层次上的关键字都可以复用。当然,并不推荐套这么多层。

对关键字驱动感兴趣的话,可以从robot framework开始学。这个还是比较容易学的。但是记住robotframework只是做测试执行器的,不会跟浏览器之类的起冲突(今天有人问我这个问题。。。)。

一些tips供参考:

1.不要做过度抽象,抽象过多的关键字层次。
2.数据抽象和关键字抽象不矛盾,参见robot framework的test template功能

3.维护伪代码比较费时间,考虑好你是否真的需要关键字驱动。如果测试团队比较大,测试人员代码水平参差不齐,可能会比较适合用关键字驱动。
4.即使你是使用别人的关键字来做自动化测试,你最好去了解下他们怎样实现那些关键字。

5.robot framework的用户手册十分强大。你的问题大多数都在用户手册能找到答案。

6.不建议用一些很冷门的工具,比如fitness,这个工具最大的问题是没有版本控制。现在做自动化测试,无论如何都不要去选没有版本控制的工具。


三、业务驱动

业务驱动,缩写BDD。

这类驱动是以cucumber为代表的。使用given when then 开头的伪代码来描述测试,并用类似于关键字驱动的方式把测试用例的逻辑和实现分离开来。

对于这类框架,我个人建议你别用。原因有以下几点:

1.所谓的given when then 伪代码并不符合一般人的语言习惯。如果想测试用例变得更接近自然语言,可以去实现domain specific language(DSL),而不需要用cucumber。

2.和关键字驱动同样的缺点,难调试、工作量加大等。但优点却不明显。

3.除非你的伪代码是交给业务人员编写的,而且这个项目有复杂的业务知识要求,导致你的测试人员不能简单得写出测试用例。否则真的不建议用。


伪代码这个东西,真是令人又爱又恨啊。作为走技术路线的测试人员,一定要敢于接触真正的代码噢。


首发于公众号:测试进阶(test_up)公众号上还会不定期推送一些面试题或练习题。

发布于 2017-10-31

文章被以下专栏收录

    本专栏面向零基础人士,希望给初入门者一些指引,使读者掌握需要掌握,但却没有人教你的基本技能。希望这个行业里越来越多的人都能尽快掌握自学能力,自主学习。