软件测试52讲
茹炳晟
eBay中国研发中心,测试基础架构技术主管
立即订阅
13422 人已学习
课程目录
已完结 63 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从“小工”到“专家”,我的软件测试修炼之道
免费
测试基础知识篇 (11讲)
01 | 你真的懂测试吗?从“用户登录”测试谈起
02 | 如何设计一个“好的”测试用例?
03 | 什么是单元测试?如何做好单元测试?
04 | 为什么要做自动化测试?什么样的项目适合做自动化测试?
05 | 你知道软件开发各阶段都有哪些自动化测试技术吗?
06 | 你真的懂测试覆盖率吗?
07 | 如何高效填写软件缺陷报告?
08 | 以终为始,如何才能做好测试计划?
09 | 软件测试工程师的核心竞争力是什么?
10 | 软件测试工程师需要掌握的非测试知识有哪些?
11 | 互联网产品的测试策略应该如何设计?
GUI自动化测试篇 (10讲)
12 | 从0到1:你的第一个GUI自动化测试
13 | 效率为王:脚本与数据的解耦 + Page Object模型
14 | 更接近业务的抽象:让自动化测试脚本更好地描述业务
15 | 过不了的坎:聊聊GUI自动化过程中的测试数据
16 | 脑洞大开:GUI测试还能这么玩(Page Code Gen + Data Gen + Headless)?
17 | 精益求精:聊聊提高GUI测试稳定性的关键技术
18 | 眼前一亮:带你玩转GUI自动化的测试报告
19 | 真实的战场:如何在大型项目中设计GUI自动化测试策略
20 | 与时俱进:浅谈移动应用测试方法与思路
21 | 移动测试神器:带你玩转Appium
API自动化测试篇 (3讲)
22 | 从0到1:API测试怎么做?常用API测试工具简介
23 | 知其然知其所以然:聊聊API自动化测试框架的前世今生
24 | 紧跟时代步伐:微服务模式下API测试要怎么做?
代码测试篇 (3讲)
25 | 不破不立:掌握代码级测试的基本理念与方法
26 | 深入浅出之静态测试方法
27 | 深入浅出之动态测试方法
性能测试篇 (7讲)
28 | 带你一起解读不同视角的软件性能与性能指标
29 | 聊聊性能测试的基本方法与应用领域
30 | 工欲善其事必先利其器:后端性能测试工具原理与行业常用工具简介
31 | 工欲善其事必先利其器:前端性能测试工具原理与行业常用工具简介
32 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(上)
33 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(下)
34 | 站在巨人的肩膀:企业级实际性能测试案例与经验分享
测试数据准备篇 (4讲)
35 | 如何准备测试数据?
36 | 浅谈测试数据的痛点
37 | 测试数据的“银弹”- 统一测试数据平台(上)
38 | 测试数据的“银弹”- 统一测试数据平台(下)
测试基础架构篇 (4讲)
39 | 从小作坊到工厂:什么是Selenium Grid?如何搭建Selenium Grid?
40 | 从小工到专家:聊聊测试执行环境的架构设计(上)
41 | 从小工到专家:聊聊测试执行环境的架构设计(下)
42 | 实战:大型全球化电商的测试基础架构设计
测试新技术篇 (5讲)
43 | 发挥人的潜能:探索式测试
44 | 测试先行:测试驱动开发(TDD)
45 | 打蛇打七寸:精准测试
46 | 安全第一:渗透测试
47 | 用机器设计测试用例:基于模型的测试
测试人员的互联网架构核心知识篇 (5讲)
48 | 优秀的测试工程师为什么要懂大型网站的架构设计?
49 | 深入浅出网站高性能架构设计
50 | 深入浅出网站高可用架构设计
51 | 深入浅出网站伸缩性架构设计
52 | 深入浅出网站可扩展性架构设计
特别放送篇 (8讲)
测试专栏特别放送 | 答疑解惑第一期
测试专栏特别放送 | 答疑解惑第二期
测试专栏特别放送 | 答疑解惑第三期
测试专栏特别放送 | 答疑解惑第四期
测试专栏特别放送 | 答疑解惑第五期
测试专栏特别放送 | 答疑解惑第六期
测试专栏特别放送 | 答疑解惑第七期
测试专栏特别放送 | 浅谈全链路压测
测一测 (1讲)
测一测 | 这些软件测试题目,你都掌握了吗?
结束语 (1讲)
结束语 | 不是结束,而是开始
软件测试52讲
登录|注册

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

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

测试脚本和数据的解耦

我在前面的文章中,和你分享过 GUI 自动化测试适用的场景,它尤其适用于需要回归测试页面功能的场景。那么,你现在已经掌握了一些基本的 GUI 自动化测试用例的实现方法,是不是正摩拳擦掌准备批量开发 GUI 自动化脚本,把自己从简单、重复的 GUI 界面操作中解放出来呢?
但是,你很快就会发现,如果在测试脚本中硬编码(hardcode)测试数据的话,测试脚本灵活性会非常低。而且,对于那些具有相同页面操作,而只是测试输入数据不同的用例来说,就会存在大量重复的代码。
举个最简单的例子,上一篇文章中实现的百度搜索的测试用例,当时用例中搜索的关键词是“极客时间”,假设我们还需要测试搜索关键词是“极客邦”和“InfoQ”的场景,如果不做任何处理,那我们就可能需要将之前的代码复制 3 份,每份代码的主体完全一致,只是其中的搜索关键词和断言(Assert)的预期结果不同。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件测试52讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(37)

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

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

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

    最后 回答问题,关于争议问题?我觉得就如标题所说,效率为王,那个形式好用就用那个。那个对提升效率有用就用那个。

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

    2018-07-27
    1
    3
  • Cynthia🌸
    我们之前采用过这样一种设计:
    输入数据和要操作的页面元素,都作为数据在外部进行存储,根据不同业务,以用例的形式进行组织并按行存入数据库,一条用例对应有一行记录页面操作,另一行记录输入数据。
    然后脚本中封装了一些方法,使得操作页面元素的写法更加清晰可读。这样在数据中就可以直接这样写click(id,“username”)表明是点击id=username的页面元素,当然对于更加复杂的页面元素,也设计了可读性较高的写法表示多层获取,方便用例设计人员编写。
    脚本读取这样表示页面操作的数据之后,抽取出层级关系,即可拿到页面元素。
    对应的读取输入数据。
    因此主要的操作步骤和数据内容都放在外部存储,脚本就不必随着业务用例的修改而修改。
    而对于重复的页面操作则使用了子用例的概念,直接按照编号或名称进行调用,避免冗余。
    2018-07-28
    9
  • 李真真
    我一直认为api测试就是接口测试,但是看老师写的貌似有不一样,请问具体有什么区别呢?

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

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

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

    2018-07-27
    6
  • sylan215
    1.数据驱动这个概念太重要了,从上层设计的角度看,数据分离是必须的,但有时候项目时间紧急,为了尽快满足实现,很多人就忽略了这些上层设计,只顾眼前利益,结果就影响了长远利益;

    2.页面对象模型,这个名词之前就听说了,但是自己在写 selenium 时并没有进行充分的应用,曾经自己还为了 selenium 自动化设计了 4 层的分层实现逻辑,目前看起来和这个页面对象就是一样的道理,果然有理论性指导实践会更轻松;

    3.关于最后的问题,我也觉得不能一概而论,比如我说的 4 层实现(原子操作层、函数层、实现层、用例层),我把登陆操作给放到了函数层,其他的控件操作则都是在用例层,一方面满足了分层和 PO 的要求,另一方面也保证了实现的简化;

    以上,欢迎关注公众号「sylan215」一起沟通交流。
    2019-02-13
    2
  • 王征
    我同意对操作进行封装的观点,GUI自动化的其中一个问题就是对页面元素的定位操作耗费很多精力去维护,页面元素的多变性也是导致自动化不稳定的原因之一,对操作进行封装能够减少维护脚本的成本,我觉得还是值得投入的
    2018-07-27
    2
  • 阿廉
    个人感觉分开好一些
    提高了粒度
    增加了灵活的使用性
    (入行新手一个月 仅仅是个人感觉)

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

    2018-07-27
    2
  • Nick
    你这里所说的页面对象, 应该就是类似MVVM的ViewModel, ViewModel是应该包含页面的操作
    2018-10-11
    1
  • 图·美克尔
    争论这个也没啥意思,如果代码写出来是给人看给人维护的关键是代码层级要清晰,注释要到位,结构要合理。其他不影响代码性能功能和使用效率的怎么组织都行啊……
    2018-07-28
    1
  • 图·美克尔
    我觉得一个对象除了要有属性还得有行为。

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

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

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

    2018-07-27
    1
  • Gz
    没有按照页面封装而是按照常用动作封装的,每次想对移动页面上的做操作就传入元素的定位方法和值 我自己的感受还是可以的 一直没有 将内容解除yml 变成数据驱动应该会更舒服 原因也比较简单现在不做 GUI自动化了😂
    2019-10-18
  • @说了再见
    我们现在的自动化测试项目每一个 page 都对应一个 PageElement 和 PageOperation 类,前者封装页面元素,后者则是封装页面操作(通过调用 PageElement 中的元素进行定位,操作)
    2019-07-03
  • Ana
    读完犹如醍醐灌顶
    之前请教过一个做过自动化测试的朋友,他就跟我说测试框架的概念,就是能更好的组织测试代码,更高效易维护,要实现数据和代码分离。我之前就是全部都放在一起,当元素定位方式或者传递的参数发生变化时,就要改好几个代码。后来用了他这种方式,但是在,从配置文件读取,数据时也遇到了一些问题,譬如在设计时要包含哪一些字段。老师提供的是思路
    2019-06-28
  • Geek__c1668bdf82c6
    我们之前写代码,数据放在单独地文件中,元素定位放在yaml文件中,实现数据和代码分离,不管数据还是页面ui变化,直接修改数据文件和yaml文件就可以了,节省维护成本,另外,我们会对共用功能进行封装,对不同页面进行封装,减少重复代码的使用,提高代码的质量,测试用例直接调用就可以了
    2019-04-28
  • 口水窝
    更倾向于页面封装于控件,而操作在做一次封装,这样页面和操作完全分开,不同的对象去操作,更透明!
    2019-03-25
  • 小寞子。(≥3≤)
    个人觉得可以让人工智能介入。利用图像识别。未来这方面是有潜力的。
    2019-03-12
  • wyy
    老师,你说的通过web url,自动生成页面上所有控件的定位信息,这个能具体解释下实现原理吗
    2019-03-01
  • 年轻人的瞎折腾^.
    我们主要做后台服务,大部分都是对接口进行自动化,当多个接口一起运行时,有缓存的影响等,容易耦合,请问后台接口自动化如何解耦?

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

    2018-12-09
收起评论
37
返回
顶部