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

15 | 过不了的坎:聊聊GUI自动化过程中的测试数据

预埋数据的可靠性问题
一次性使用的测试数据不适合
硬编码测试数据
对测试环境的依赖性强
业务数据的连带关系导致创建效率低
测试执行时间较长
数据准确性问题
需要同步更新测试数据工具中的SQL语句
执行效率高
可以创建和修改API不支持的测试数据
执行效率不高
不是所有测试数据都有相关API支持
测试数据准确性由API保证
遇到的问题及解决方案
公司如何准备GUI测试的测试数据
选择不同的测试数据创建方式
综合运用API调用和数据库操作
适用时机
缺点
问题
举例:创建特定测试数据
缺点
优点
缺点
优点
事先创建数据(Out-of-box)
实时创建数据(On-the-fly)
综合运用API调用和数据库操作
数据库操作
API调用
思考题
总结
On-the-fly和Out-of-box的互补
事先创建测试数据:Out-of-box
实时创建数据:On-the-fly
综合运用API调用和数据库操作创建测试数据
基于数据库操作创建测试数据
基于API调用创建测试数据
创建时机
创建技术手段
GUI自动化测试数据的创建

该思维导图由 AI 生成,仅供参考

在前面几篇文章中,我从页面操作的角度介绍了 GUI 自动化测试,讲解了页面对象模型和业务流程封装,今天我将从测试数据的角度再来谈谈 GUI 自动化测试。
为了顺利进行 GUI 测试,往往需要准备测试数据来配合测试的进行,如果不采用事先数据准备的方式,测试效率将会大打折扣,而且还会引入大量不必要的依赖关系。
以“用户登录”功能的测试为例,如果你的目的仅仅是测试用户是否可以正常登录,比较理想的方式是这个用户已经存在于被测系统中了,或者你可以通过很方便的方式在测试用例中生成这个用户。否则,难道你要为了测试用户登录功能,而以 GUI 的方式当场注册一个新用户吗?显然,这是不可取的。
其实从这里,你就可以看出测试数据准备是实现测试用例解耦的重要手段,你完全不必为了测试 GUI 用户登录功能而去执行用户注册,只要你能够有方法快速创建出这个登录用户就可以了。
在正式讨论测试数据的创建方法前,我先来分析一下 GUI 测试中两种常见的数据类型:
第一大类是,测试输入数据,也就是 GUI 测试过程中,通过界面输入的数据。比如“用户登录”测试中输入的用户名和密码就就属于这一类数据;再比如,数据驱动测试中的测试数据,也是指这一类。
第二大类是,为了完成 GUI 测试而需要准备的测试数据。比如,“用户登录”测试中,我们需要事先准备好用户账户,以便进行用户的登录测试。今天我分享的测试数据创建的方法,也都是围着这一部分的数据展开的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

GUI自动化测试数据的创建是一个关键技术,本文从技术手段和时机两个方面进行了探讨。在技术手段上,主要分为API调用、数据库操作和综合运用API调用和数据库操作三种方法。而在创建的时机上,则分为实时创建数据(On-the-fly)和事先创建好“开箱即用”的测试数据(Out-of-box)两种方式。最佳的选择是利用API来创建数据,只有当API不能满足数据创建的需求时,才会使用数据库操作的手段。同时,综合运用这两种方法可以提供更多种类的业务测试数据。然而,在实际测试项目中,实时创建数据方式存在执行时间长、创建效率低和对测试环境依赖性强等问题,因此还会引入Out-of-box方式来准备测试数据。综合来看,本文通过深入分析了GUI自动化测试数据的创建方法,为读者提供了全面的技术视角和实践经验。 在实际的大型测试项目中,往往会采用两者相结合的方式,从测试数据本身的特点入手,选取不同的测试数据创建方式。针对应该选择什么时机创建测试数据,结合多年的实践经验,作者总结了以下三点:对于相对稳定、很少有修改的数据,建议采用Out-of-box的方式;对于一次性使用、经常需要修改、状态经常变化的数据,建议使用On-the-fly的方式;用On-the-fly方式创建测试数据时,上游数据的创建可以采用Out-of-box方式,以提高测试数据创建的效率。 总的来说,本文详细介绍了GUI测试数据的准备,强调了综合运用API调用和数据库操作来创建测试数据,并根据测试数据自身的特点,采用On-the-fly和Out-of-box的方式,以寻求数据稳定性和数据准备效率之间的最佳平衡。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件测试 52 讲》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(20)

  • 最新
  • 精选
  • 晴天
    hui测试的两类数据感觉没有什么区别,老师能详细说下嘛

    作者回复: 其实这里是从两个不同的角度来描述测试数据,一种是测试输入数据,也就是你的数据驱动中用到的数据,另一种是讲你怎么去创建这个测试数据。

    2018-08-10
    1
  • 假装乐
    数据库监控工具有推荐的吗
    2018-08-01
    1
    31
  • sylan215
    是不是可以这么理解: API 调用和数据库操作创建,本质上都是操作数据库,不过 API 调用是做了一层封装,保证了操作的可控性(避免胡乱写数据库操作语句)。 实时创建数据和事先创建测试数据,其实也是不冲突的,我理解他俩并不是互斥的关系,而是互为补充,在 API 调用逻辑内部,先检查数据库中是否存在需要的测试数据,存在则继续,不存在则创建即可。 欢迎沟通交流,公众号「sylan215」
    2018-08-01
    1
    15
  • 捷后愚生
    了解到的新知识:利用数据库监控工具获取一段时间内数据库所有的业务表修改记录,以此为依据得到创建数据的 SQL 语句集。 在自己实际工作中,自己曾经使用QTP来创建测试数据,都是准备给自己使用,所以数据量不大。 我在银行做测试,测试数据准备是一个很大的问题,测试的对公信贷系统对接了几十个系统,现在还是主要以手工准备数据为主。 虽然有一个造数平台,现在准备数据比以前方便了,但是还是做不到快速大批量造数。是手工在造数平台造数后,再在对公信贷手工引入数据。 至于使用API造数,现在也实现不了,项目中接口文档没有形成知识资产,有些接口找不到接口文档,不知道具体字段的含义,项目内没有安排人统一去梳理接口,估计难以使用API造数。 数据库改数,也是很困难。银行内有专门的环境组管理环境,一般人使用的数据库用户都只有查询权限,没有改数权限,只有在测试的时候,真的需要改数,得提单进行申请修改。而且不同系统间是不同的人管理。 做为测试,太复杂的SQL写不出来,也不了解具体要改哪些表、哪些字段,所以很多时候还是得找开发帮忙。
    2020-07-09
    7
  • 任大树
    老师讲的很清楚~~我有个小问题想请教一下:自动化做完 要进行数据还原,老师有没有什么数据还原的方法推荐呢?比如数据库快照什么的。或者说有哪些类型的自动化测试根本不用还原?
    2018-09-21
    4
  • 叶夏立
    我的做法是备份还原整个数据库😂,当然也是看业务场景的
    2018-08-01
    4
  • 口水窝
    小公司,没有做GUI自动化测试,更无从测试数据的准备谈起,只能自己摸索,不断尝试,总结更多的实践经验。
    2019-03-29
    3
  • arthur
    我们的产品有一个best practice的包,里面包含了很多数据,对测试非常有用
    2018-08-06
    3
  • 年轻人的瞎折腾^.
    我们是out the box 脚本预制 然后on the fly 接口调用,API测试,经常因为接口变动大,数据库也有变化 这样脚本经常容易改动 有什么方法可以设置变量方面,灵活性的脚本?
    2018-11-08
    2
  • FamilyLi
    最近几张讲的GUI测试,听起来主要是基于浏览器的业务测试,对于APP的测试如何应用
    2018-08-02
    2
收起评论
显示
设置
留言
20
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部