软件测试 52 讲
茹炳晟
腾讯 TEG 基础架构部 T4 级专家
70473 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 63 讲
结束语 (1讲)
软件测试 52 讲
15
15
1.0x
00:00/00:00
登录|注册

13 | 效率为王:脚本与数据的解耦 + Page Object模型

在上一篇文章中,我用 Selenium 2.0 实现了我们的第一个 GUI 自动化测试用例,在你感觉神奇的同时,是否也隐隐感到一丝丝的担忧呢?比如,测试脚本中既有测试数据又有测试操作,所有操作都集中在一个脚本中等等。
那么,今天我就通过介绍 GUI 测试中两个非常重要的概念:测试脚本和数据的解耦,以及页面对象(Page Object)模型,带你看看如何优化这个测试用例。

测试脚本和数据的解耦

我在前面的文章中,和你分享过 GUI 自动化测试适用的场景,它尤其适用于需要回归测试页面功能的场景。那么,你现在已经掌握了一些基本的 GUI 自动化测试用例的实现方法,是不是正摩拳擦掌准备批量开发 GUI 自动化脚本,把自己从简单、重复的 GUI 界面操作中解放出来呢?
但是,你很快就会发现,如果在测试脚本中硬编码(hardcode)测试数据的话,测试脚本灵活性会非常低。而且,对于那些具有相同页面操作,而只是测试输入数据不同的用例来说,就会存在大量重复的代码。
举个最简单的例子,上一篇文章中实现的百度搜索的测试用例,当时用例中搜索的关键词是“极客时间”,假设我们还需要测试搜索关键词是“极客邦”和“InfoQ”的场景,如果不做任何处理,那我们就可能需要将之前的代码复制 3 份,每份代码的主体完全一致,只是其中的搜索关键词和断言(Assert)的预期结果不同。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件测试 52 讲》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(47)

  • 最新
  • 精选
  • 康美之心 淇水之情
    置顶
    觉得data provide只是从行为操作上分离了数据的提供方式,没有从根本上解决自动化测试中测试数据本身的稳定性、快速响应变化、数据丢失、数据被修改的这些难点和blocker,比如生产数据库里的数据没半边会导入并refresh测试环境数据库,之前cases里使用的数据都没有了;比如几个小组在一个系统里使用同一个测试环境数据库,A组正在用的测试数据B组也正在用,B组还要把数据改变一下再用,或者B组用完后测试数据已经发生改变了;比如使用的测试数据本身随着时间是有实效性的到,状态会改变的,从active变成inactive的等;觉得自动化测试的其他方面都不是什么大问题,最主要的阻碍就是测试数据本身(特别是在真实的测试环境上时,单元测试不会有这些问题),想问一下老师,有没有一些好的方法、方式、工具、工程实践来解决上述这些数据本身的问题?

    作者回复: 哈哈,你说的完全在点子上,数据驱动不是用来解决你说的这些问题的,你遇到的这一系列问题我后面会介绍一个比较完美的方案,基本可以统一解决所有这些问题,我会在后买专门讲测试数据的时候详细展开,一定让你有豁然开朗的我感觉,因为我们也是一路走过来的

    3
    29
  • 红娟
    置顶
    首先 周三的例子通过python+seleniun3实现了,并且还开始在项目中开始了脚本编写。有点小小的成就感 其次,今天课程的关键词 数据解偶,模块化,页面对象 数据解偶和模块化我是深有体会的,之前测试项目中有用到自动化,因为是嵌入式设备,所以大多数都是自己写脚本,并没有现成的平台可以用。所以经历很多摸索。一开始是流水账式,后来发现测试用例一多,就无法维护。后来就思考,能不能数据和期望结果是一张表格,测试用例其实就是数据不一样。哇,这一做不得了,测试框架很清晰,测试用例管理很灵活。维护也很简单。效率必须提高。如果早知道有数据解偶这个词就好了😊。会少走很多弯路。 模块化,是写代码的一个必备功能。特别是像我们大多数是基于c开发,如果没有做到模块化,那维护就如看天书😊 页面对象,不是太能理解。我感觉像c++里面的面向对象。狗就一大类,小狗,大狗,哈士奇……,那都是基于狗这个基类继承发展出来的不同属性……。 最后 回答问题,关于争议问题?我觉得就如标题所说,效率为王,那个形式好用就用那个。那个对提升效率有用就用那个。

    作者回复: 非常感谢高质量的留言👍,页面对象你可以看文章中最后那张截图,页面对象就是把页面元素的定位集中放在一起。

    2
    12
  • ll
    更倾向于 页面模型只封装控件,这种方法其实也是模块化思想的深一层应用,控件是页面的更小单元,且一个产品或项目中使用的控件种类有限,但是页面却很多,每个页面控件组合方式又不同,在项目中两种方法多次实践后,将控件单独封装后,页面操作又节约大量的开发和维护成本。

    作者回复: 很棒的逻辑分析👍

    12
  • 李真真
    我一直认为api测试就是接口测试,但是看老师写的貌似有不一样,请问具体有什么区别呢?

    作者回复: 接口测试的含义范围一般更广,api测试是接口测试的一种,接口测试还包括传统软件集成测试中的模块之间的接口

    11
  • 图·美克尔
    我觉得一个对象除了要有属性还得有行为。

    作者回复: 这个就是一个典型的争议点,只是这个行为的封装是放在属性一起,还是具体属性再包装一个行为class

    3
  • 阿廉
    个人感觉分开好一些 提高了粒度 增加了灵活的使用性 (入行新手一个月 仅仅是个人感觉)

    作者回复: 嗯嗯,这个目前的确没有标准答案,各自都有自己的优缺点

    2
  • CoolPanda
    数据驱动测试的思想不适用于 GUI测试 这个是想说“不仅”适用于GUI吧

    作者回复: 你完全对,文中有提到,api测试,单元测试其实都是适用的

    2
  • 年轻人的瞎折腾^.
    我们主要做后台服务,大部分都是对接口进行自动化,当多个接口一起运行时,有缓存的影响等,容易耦合,请问后台接口自动化如何解耦?

    作者回复: 这个取决于你的后台架构以及相应的缓冲机制,没法一概而论

  • Mafia
    没有必要在 “传统“这个层面讲很多..

    作者回复: 你希望更多看到的是哪方面的内容?其实目前互联网企业整体在gui测试上的投入都逐渐在减小

  • hohofugao
    老师讲讲接口测试,有没有好的实践

    作者回复: 后年专门会有文章来讲api测试的,期待一下吧

收起评论
显示
设置
留言
47
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部