之前的文章介绍了如何安装UI测试框架, 如何展示好看的报告, 以及好用的定位方法. 但是想要正确使用UI框架进行测试还远远不够. UI的测试有很多与API测试不同的地方, 需要我们特殊对待. 本文以此为出发点, 简单谈谈个人看法.
UI测试与API测试, 最主要的区别它是一个端到端的测试用例. 因此决定了, 它运行速度慢, 操作路径长, 需要兜底API测试不能覆盖的场景.
运行速度慢
由于UI是完整地端到端用例, 除API的响应等待时间还增加了页面渲染的时间. 因此, 我们在考虑写自动化测试用例时候, 对于数据校验优先使用API测试来完成. UI测试用例主要是覆盖页面的js逻辑为主, 校验各个页面是否正常工作, 交互是否有问题等等, 辅以一些简单的跨页面的数据对比校验.
操作路径长
众所周知, 自动化用例需要重复运行, 并且基本上要求相互独立. 因而在开发自动化用例过程中, 需要编写完备的数据准备以及数据清理步骤. 所以会导致ui自动化整体操作路径会很长. 这样极大增加了程序不稳定的可能性.
操作路径长的第二个问题是, UI测试的校验点跟测试编写人员的经验有关. 有时候在一个很长的操作路径的某处出了问题, 仅仅看最后的截图是不足以找到问题的根源, 但是又没有像接口测试那样, 借助接口返回来判断是哪一步出了问题.
所以基本上所有的UI测试框架, 都会提供截图和录屏等相关的功能. 例如Robotframework+Playwright 框架, 截图是默认启用的, 如果我们想要开启录屏功能, 只需要指定一下视频保存的地址. 这样所有打开页面的关键词的日志下面, 可以看到相关录屏, 方便我们排查到底是哪一步开始出现了问题.
New Context recordVideo={"dir": "${OUTPUT_DIR}/video"} 兜底API测试
API测试毕竟是针对接口操作的校验, 它不能覆盖到前端js的代码. 因此有很多场景我们只能使用UI测试来校验.
- 场景一 下载文件
下载也是一个非常常见的端到端用例, 如何通过Robotframework+Playwright来测试这个场景呢.
首先还是要开启下载功能
New Context acceptDownloads=True其次就开始进行页面操作, 等待文件下载完成, 并校验相关文件是否能在文件系统中找到.
${dl_promise} Promise To Wait For Download ${OUTPUT_DIR}/browser/${file_name}
点击进行下载
Wait For ${dl_promise}
File Should Exist ${OUTPUT_DIR}/browser/${file_name}- 场景二 在一个下拉列表, dom不是马上把所有数据都加载进来, 而是在用户滚动侧边栏来逐步加载数据.
这个场景可以利用 Scroll By 这个关键词, 它接受两个参数, 滚动条所在的dom元素, 以及滚动的像素值, 可以指定是横向也可以是纵向. 由于元素是动态生成的, 不知道要滚动到哪才能生成, 我在这里使用了一个递归方法, 直到最后找到了这个元素为止.
滚动查找元素
[Arguments] ${scroll_holder} ${element}
${status} Get Element States ${element}
Run Keyword If not 'visible' in ${status} Run Keywords Scroll By ${scroll_holder} vertical=70 AND 滚动查找元素 ${scroll_holder} ${element}“天生我材必有用”, 既然现在既有API测试框架, 也有UI测试框架, 就有它们存在的价值. 重要的是, 作为测试开发人员, 如何根据实际场景来判断采用那一种方式去实现.