RF实现数据驱动DDT

场景

在自动化测试框架中,数据驱动的意思指定的是测试用例或者说测试套件是由外部数据集合来驱动的框架。这里说的数据集可以是任何类型的数据文件比如xls,xlsx,csv等等。它的核心的思想就是数据和测试代码分离,及时当测试数据发生大量变化的情况下测试代码(或者说测试用例)可以保持不变。数据集合里有1条数据和100条甚至更多,是不会影响到测试用例的执行。如果想使用一组不同的数据来执行的相同的操作没那么你就可以选择数据驱动。

在自动化测试中,为了维持回归测试的稳定一致,测试脚本应当尽量避免更改。在非数据驱动的情况下,恰恰违背了这一原则。自动化测试中,随着项目的深入,测试脚本将会持续增多,测试数据和脚本揉在一起?维护起来将会是一件恐怖的事情,出错在所难免,所以这时不要这样做,让数据和脚本分离,坚持死的代码,活的数据,维护的大部分工作将只面向数据。

因此,数据和脚本分离、维护对象由脚本转向数据,这样的数据驱动测试将会缓解上述测试数据难扩展和测试项目维护难的痛点。

比如,在这么一种场景下,例如你需要用多个不同的账号和密码来登陆某个邮箱,来验证哪些是有效的值,哪些是错误的值,或者哪些值可以导致出错,这只是一个简单的例子。

另外一个简单的例子就是网络电话的测试,当我们模拟拨号、挂断、回拨等等操作时我们希望验证每个按钮是否能正常工作并能得到正确的结果。

或者是搜索功能, 不同的搜索条件, 返回不同的结果. 以下代码就以百度的搜索为例.

代码

Step1:

以下代码演示的是三个搜索条件, 软件测试/RobotFramework/数据驱动. 编写的线性代码, 那么几个搜索条件, 就需要几条测试用例.

*** Settings ***
Library           SeleniumLibrary

*** Test Cases ***
case1
    Open Browser    https://www.baidu.com/
    Input Text    id=kw    软件测试
    Click Element    id=su
    sleep    2
    Close Browser

case2
    Open Browser    https://www.baidu.com/
    Input Text    id=kw    RobotFramework
    Click Element    id=su
    sleep    2
    Close Browser

case3
    Open Browser    https://www.baidu.com/
    Input Text    id=kw    数据驱动
    Click Element    id=su
    sleep    2
    Close Browser

Step 2:

试想, 如果有10个搜索条件, 乃至100个, 那不是要写100条?

对于重复操作的步骤, 我们首先想到的, 应该是封装. 在RF中封装的概念就是自定义关键字.

新建一个Resource, 命名为Resource.robot, 里面存放一个用户关键字search, 把重复操作的步骤代码写入其中, 该关键字需要传入一个参数, 即搜索字段

*** Settings ***
Library           SeleniumLibrary

*** Keywords ***
search
    [Arguments]    ${text}
    Open Browser    https://www.baidu.com/
    Input Text    id=kw    ${text}
    Click Element    id=su
    sleep    2
    Close Browser

Step 3:

新建测试集, 导入资源文件Resource.robot.

数据驱动的实现, 需要用到Template, 也就是模板. 在Test Template处引入search关键字.

RF实现数据驱动DDT_第1张图片

Step 4:

数据驱动正式开始. 该测试集下的所有测试用例都会引用关键字search, 只需要在测试用例填写它需要传入的参数即可.

*** Settings ***
Test Template     search
Resource          Resource.robot

*** Test Cases ***
case1
    软件测试

case2
    Robotframework

case3
    数据驱动

写在最后

数据驱动测试并不适用于所有的测试。

首先,对于弱参数的测试,使用数据驱动,将会降低测试效率。所谓弱参数测试,就是测试用例对测试参数不敏感,具体表现在用例不需要传入参数的情况,或者难以参数化的情况等等。

举个例子,我们要测试一个接口,它的功能是返回当前系统时间的时间戳,它没有需要传入的参数,返回的数据也完全由当前时间决定。在这个例子中,我们几乎看不到需要参数化的东西,唯一有可能被参数化的是接口的返回参数,而这个返回参数还是随着当前时间动态变化的。如果要对这个接口实现数据驱动,那么我们需要在数据池中增加动态获取时间的逻辑,然而获取当前时间在测试脚本中,用一行代码就可以实现,所以,本例使用数据驱动得不偿失。

再者,对于非大规模的,或者非自动化的,或者非长期优化的测试,使用数据驱动通常没有必要。对于一个小的、临时的或者一次性的测试需求,整个测试过程讲究灵活变通,完全没有必要去花力气去建设一个专门的数据驱动的平台。总之,如何能够达到效率最高,就如何去安排测试的方法。

脱离了具体需求的测试方法或者技术,都是在耍流氓。

​现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
分享他们的经验,还会分享很多直播讲座和技术沙龙
可以免费学习!划重点!开源的!!!
qq群号:485187702【暗号:csdn11】

最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走! 希望能帮助到你!【100%无套路免费领取】

你可能感兴趣的:(软件测试,程序员,接口测试,自动化测试,测试工程师)