楼主的文章和我司现在的产品几乎完全契合

这个和 selenium 无关 和你使用的脚本组织框架有关
你可以把异常捕获不再抛出 只是记录下来
或者使用类似于 testng 的 alwaysRun 参数来控制

研发各种能提高测试团队工作效能的工具或者方法

都可以 不局限于表现形式 关键是你得熟悉工作流程 善于挖掘潜在的需求

差不多是这意思

try { 
a=寻找元素;
a.动作()
}catch(InvalidElementStateException | StaleElementReferenceException ex){
Thread.sleep(2000);
a = 寻找元素;
a.动作();
}

这是重试一次的例子 也可以写成循环 多尝试几次

等待条件改成 clickable 试试

那你分析下这个 class 和其他的有什么不同

逐步替换执行的用例集合数量 看看到底是因为数量的原因 还是因为某一个或某类用例执行造成的生成失败了

stale element reference 说明你在操作元素时 已经找到了这个元素 只是元素的状态变化了 无法再使用之前找到的元素引用来操作 需要重新再定位一次 这个异常在 UI 自动化中很常见

按理说不应该出现这种情况 你可以先调试下 确认传入的参数值是不是 10

谢谢分享 有空的时候试一下

不赞成 19 楼的说法 先不说找专业的人来做不是由楼主决定得了的

就算以后需要迁移 前期做的东西 对楼主自己也是一种很好的经历不是吗

用 xpath .//iframe[contains(@src,'https://www.XXX.com/../X.html')]

12 - 18 之间吧 有些企业可能开到 18+ 但工作强度非常高 月均 300
不过你三年多 在长沙能拿到 13 的自研 offer 也算是可以了哦

我在长沙 如果是靠谱的测开的话 11 已经算比较低了哦

分析下日志 看看为什么增加了并行数 速度没有增加

并行级别是什么 运行时确定是 20 个线程在跑吗

有这种情况 对这种情况特殊的元素 可以点击后 再判断下状态 如果没点上 多点几次

1、直接用 JS 的 click 不管是否可见 都能响应点击事件，不过这样也可能带来一些负面影响。总体来说还是可控的
2、运行时查看浏览器的操作，确定你需要操作的元素是否滚动到可见了， action 的 click 是可以穿透遮罩层的。driver 的 click 方法不行
3、参考 7 楼的方法，用无界面模式 可以自定义分辨率

{
"message": "操作成功",
"status": 200,
"count": 2,
"data": [
{
"page": 1,
"rows": 10,
"id": 23,
"question": "商品期权权利方平仓凭证中，作为贷方的科目有 ()(0.5 分)",
"options": "A、 差价收入 B、 交易费用 C、 证券清算款 D、 其他衍生工具_商品期权",
"answer": "标准答案：A",
"questiontype": "单选题"
},
{
"page": 1,
"rows": 10,
"id": 2004,
"question": "商品期权中，义务方认购行权实际理解为 ()(0.5 分)",
"options": "A、 期权增加，期货空头增加 B、 期权减少，期货空头增加 C、 期权减少，期货多头增加 D、 期权增加，期货多头增加",
"answer": "标准答案：B",
"questiontype": "单选题"
}
]
}

假如接口返回数据是这样，可以把 data 提取出来，去除不用比对的字段后保存为一个列表。
期望值也做成一个列表，比较两个列表的差集

可以用列表差集方式比对

定位和操作 是不同的概念 寻找元素是只要元素存在于 dom 中就能找到，不论是否可见可操作的。
显式等待可以自定义等待条件，selenium 本身也预置了很多常用的等待条件。基本上够用了

全 xpath 省事

这个问题很常见

要明确一点 是定位不到还是无法操作 按理来说应该是可以定位得到的
只是由于不可见 所以无法执行 selenium 自带的 click 方法
可以尝试用 JS 的 click 方法来点击

插件好像叫 publish html reporter