不是事前建 而是事前删
不清楚你的具体情况,各个用例之间的数据会有依赖吗,
设计用例时 最好是每个用例都能单独跑 这是一个原则
这个得看你们公司的需求,一般来说 UI 只是用来做页面的冒烟测试,保证不出低级问题就行。没必要做到这么细致
不过,我这里确实是做了的,包括标签文本校验、表单元素默认值、列表关联项动态加载、元素状态控制、表单元素布局、数据列表校验
因为产品本身是属于需要长期维护更新的企业应用。自动化也跟着做了好几年了
1 和 3 都遇到过
1、回收数据如果无法使用 SQL,在事后处理确实容易受到用例本身运行情况的影响,可以考虑把回收工作做到测试的事前处理。这样的好处一是稳定,不受测试用例本身的影响。二是如果测试失败,还留有测试数据更容易复现问题。
3、对于异步处理,如果页面直接反馈的信息不准确,可以直接根据后端数据的变化来进行断言。设置一个比正常处理时间稍长的阀值,对结果数据做轮询。前提是在前端能查到用来做标志位的数据。
中小型项目的接口自动化选 jmeter 够用了。至于测试报告可以考虑使用 jenkins 的插件来实现
很正常,按钮点击要有动作必须要其对应的 JS 方法加载完毕。而显式等待一般也只是判断按钮元素本身是否加载完成或者显示。
这之间还是会有一定的时间差。 所以建议所有的动作之间都加上 0.5 到 1 秒的延时。可以避免很多类似的问题
实际是两个步骤
第一个步骤 是输入 你需要核对的 列头的文本列表 获取 各自对应的 index 保存下来
第二个步骤 是根据上一步获取的 index 获取列表元素对象,再去逐一比对期望值
能理解吗
这个要结合 header 和 cloumn 一起看
不管你的元素具体的 class 里数字是多少
只要 列头和列表元素的数字是有规律能对应起来的就行了
比如 列头的 class 里 数字是 2 那列表元素的 class 里也是 2 或者是固定的偏移量 都可以
不知道你具体是怎么设计的 我直接说一下我的方案好了 希望给你一些参考 ,能否实现 也和前端框架有关系的
列表数据的校验是一个难点,我的方式是通过列头的文本值来通过 xpath 相对定位获取这一列所有元素 再逐个与期望值校验
其实也是参考 RF 的设计,把元素和动作分开,页面不带任何动作 需要操作时把元素和动作组合起来使用就行了
把元素定位和动作分开封装,PO 只维护对象,动作可以抽象出来和元素进行任意组合,一般的 WEB 页面也就是几十种动作类型
根据公司项目的业务特点和 UI 自动化的职能目标而定
如果 UI 只是用来做页面的 CURD,各用例之间有依赖是可以接受的。每个用例都做前置后置数据维护工作量会更大
如果需要做流程,用例最好能做到独立运行。一般还是推荐用接口做流程回归,受客观因素影响比较小
另外还可以加入重试机制,能很大程度降低外部因素引起的测试失败
我这里 UI 只用来做功能冒烟 约 500 个页面 用例数 2500~3000 之间 通过率平均 93~95% 左右
嗯 使用哪种方案还是根据项目具体情况而定
jmeter 资料丰富 上手快 对人员要求也低 用来做一些短期项目的接口自动化还是挺不错的
可以在测试框架中集成大漠插件 不过只能在 windows 中使用
jmeter + ant + jenkins 短平快
这是 Driver 内部的通讯超时了 检查一下 driver 和浏览器的版本是否匹配 或者浏览器是不是自动升级了
1、在开发环境运行时可以直接在 IDE 的控制台里查看日志
2、在非开发环境以本地方式运行,可以使用日志工具写日志文件,再做个桌面应用读取刷新
3、如果是以远程方式运行。写个 web 页面来获取服务端 log
动作无非就是哪些 单击 双击 输入 切 iframe 访问 url 之类的 一般也就几十个 可以抽象出来 将元素和这些动作进行任意的组合
链式写起来舒服,对调试就不怎么友好了
不建议用这种 PO 设计
页面对象建议只维护元素定位,动作可以再抽象一层独立出来
1、容器类元素带唯一标识就行了,叫什么随便定
2、不同页面的同类元素 最好使用统一的命名
用 text 来相对定位 比如 .//span[text()='福州白金翰宫']/..
参数流转可以参考 jmeter 的方式 都是相通的
可维护性这个得具体问题具体分析了
嗯 它可以做到流程自动化 但是断言什么的功能需要自己实现 而且按键只支持 VBS 扩展能力弱了一点