ETL 过程一般需要对数据的 完整性、一致性、正确性、规范性进行校验。具体的规则得看你们的业务而定

1、这样就失去了从界面上测试上传动作的意义了 实际只测试了后端
2、拖拽用 js 实现我在不同场景下尝试过几次 有些场景可以 有些场景不行

可以参考 RF 的设计 把页面对象和动作分开抽象

页面只维护元素对象 动作类维护动作 降低耦合性 写脚本时把元素和对应的动作关联起来就行了

我是把 py 打包成 exe 然后用 java runtime 来执行的 比较笨重 不过需求场景不多 也就凑合用了

是的 我也是这种思路 但是没有用模板引擎

这种简单的场景 在执行第二个用例前在库里插一条用户记录就行了 跑完后再删掉

不清楚你是怎么操作的

按正常来说 输入查询字符后 列表展示过滤后的信息 再选择你需要的选项即可 不存在丢失焦点之类的 如果 selenium 提供的 click 不好用可以尝试下用 JavaScript 的 click 方法点击

用容器环境 不需要考虑这些东西 要什么版本就用什么版本的镜像

public static void setValue(WebDriver driver,WebElement ele,String value){
        JavascriptExecutor executor = (JavascriptExecutor) driver;
        executor.executeScript("arguments[0].value=\""+value+"\";", ele);
}

下游模块的功能测试用例 需要上游模块产出的数据或状态做为前置条件 用例中直接作为用例的前提条件出现好了

用 index 试试

标题写错了 不是测试报告 是 BUG 报告

如果条件允许的话尽量拆成多个独立的小用例来执行，一个用例流程太长 稳定性也更难保障

是的 要看具体的业务来定

我们 UI 一般只用来跑冒烟测试 前司约 4500 个用例 20 个 Driver 并行 一个半小时左右

他这个 1000 用例 5 个小时 肯定会有优化空间的

一个用例有多少步骤？单独跑需要多长时间？
1000+ 用例 5 个小时确实太慢了 尽量要控制在 1 小时以内
在保证操作稳定性的前提下 可以适当减少不必要的线程等待时间，优化操作步骤的流程，灵活运用显式等待的各种条件
实在不行还可以增加 Node 数量 一台 4C8G 的虚拟机跑 10 个 Driver 没问题的 8 个不够 就增加到 16 个或更多

另外要合理分配各个 Node 的执行用例，总执行时长是由最慢的那个 Node 决定的

看实际场景需求和资源来定 如果参与脚本开发的人都有一定的代码能力 可以直接写代码 这样最灵活 对人员要求也要高一点

否则可以封装起来 对外只使用 excel 或 yaml 文件编辑 参与开发的人员只需要熟悉你框架开放的 api 规则就行了

存储介质常见的几种方式各有利弊 我们一般是使用 excel 编辑效率比纯文本文件高很多

我们是通过定义抽象 xpath 表达式的方式来实现降低维护成本的
虽然不能完全避免 UI 变动带来的维护 但是需要维护的页面对象比之前少了 90%+ 从实际效果来看 还是很不错的

很不错 谢谢楼主的分享

造数工具 取数工具 (解析文本数据源或从网站爬)

自动化脚本自动生成工具 版本对比工具

excel 转 word 工具 还有各种流程机器人 总之就是怎么能偷懒怎么来。。

java 用反射 python 应该也有类似的方法

jira 有学习版。。 不一定非得要用云的 自己加插件就是了

应该是引用路径不对 直接按截图文件名搜一下 看看具体存在哪里了

总结的很好 基本上都是在自动化落地过程中遇到过的问题

用 xpath 轴定位

期待楼主的新书问世 ! 另外 监控平台和 UI 自动化两个链接都打不开了 。。