pytest 驱动测试套件 执行内容不详，但是用例可以定义执行重试次数，一般需要 2-3 次才会执行成功。
来分析这个问题：
1.Ui 自动化来说，多重试会是把测试用例执行总时长拉长的元凶。
2.重试次数更多是用来 python 栈来完成对于接口幂等性问题验证和应答次数验证等。
幂等性问题 是多次请求结果一致。
一次性请求，后面多次发的失败结果一致，并且后端接收一次。
应答次数比如打点次数>3 次，用这个 pytest 插件化行为触发 3 次或者大于 3 次都是良选。
所以初步判断是健壮性不足（检查点不够良好和关键节点上文验证条件在下文执行前没有验证）
PS:注意这个问答本身不考虑建设一套完善记录上下场景关系的回退处理异常和复位 Case 内部变量初始值等，也不会对 pytest 插件本身进行改造和添加监听器等条件，所以检查点设置尤其重要。
从业务角度去改的，可以一步步改造得框架比较完善。
eg1：
登录页面，账号密码验证都 pass，点击登录，到达二级页面。
因为网络问题和首次登录请求数据会较多，登录时会出现转圈圈图和提示登录中的文本，导致登录有可能会失败。
这个场景执行次数设置多次 Ok，检查点应该设置为登录后的场景内容，如果还是设置在登录页面，会遇到接下来的 case 批量失败。
那么设置这个登录后场景内容是否足够良好？
其实并不良好，因为缺省了登录时会出现转圈圈图和提示登录中的文本。
通过业务分析，转圈圈是动图，提示登录文本是静态的。
也就是在重式的时候，检查点需要先判断是否出现过登录文本。
到达二级目标页面失败，首要判断条件是是否出现过登录文本，然后才判断是否包含二级页面的元素是否存在。
写法上 xxxx_ele =find_element_ByXXX("值") 先判断对象是否存在,判断对象可操作属性。
这样一旦出现错误也可以快速判断问题出现在哪里。
eg2:
每个页面有个重要得标记图，每次进入页面这个标记图不一定是同一张会在固定几张内切换（假定我们不能设置其他检查点去绕开它）
如果是图或者元素，action_click 不是单纯用显式等待,但可以定义检索频率。
# Demo代码，坐标是在需要判断得case得逻辑代码下面，abc是3个对象，都是通过dr.定位器查询方式找到的。这个while找不到可以继续找，f定义了一个执行次数，每次找不到f-=1,当f等于0就while自己退出了。
while(a or b or c or f):
if action_click(a):
print(f"操作的是{a}")
break
elif action_click(b):
print(f"操作的是{b}")
break
elif action_click(c):
print(f"操作的是{c}")
break
f-=1
这样就能知道你目前记录的是哪张图，并且用例也具备扩展性。
上文就是你的操作上文，哪怕每个用例类对象的文件都解耦了，还是会有源头部分的。
面对这块，最简单是用数据库（频繁请求的 nosql 类型，比如 redis，固定存一次 mysql），不想用数据库用内存形式如下：
caseB 上文是 caseA，如果 caseB 和 caseA 在一个文件的同一个类里面，在 caseA 逻辑代码开始的时候，临时申请一个 self.上文标记对象=False（不用在类变量里面先声明在定义一个 None），在 caseA 关键位置,修改 self.上文标记对象 =True,caseB 逻辑代码开始得地方判断这个类变量是 True 还是 False，在对用例进行不计算执行正确失败计算和 return
caseB 上文是 caseA,如果不在一个文件内，可以用一个全局变量 只定义一个，这个全局变量在 caseA 结尾修改，caseB 开头时使用。
PS：内置函数 setup 属于第一种，如果需要多个，就不够灵活，所有文件都需要用，就等于每个文件都要写。
pytest skip 函数有缺点，往往是一开始就决定了，可以用到对用例内容定义标签，满足这个标签得进行执行。
如果这段看不明白，建议去补下语言结构基础，不补还坚持写 就和烧菜烧得不好坚持开餐馆一样，自己为难自己没意思。
每次出现打开新窗体的把窗体句柄记录到一个字典表里面，在这个句柄的操作也记录在链表里，如果关闭了界面就删除这个字典的句柄号，那么里面句柄操作信息的 value 也被删除了。
需要对元素用过 dr.定位器找到后先保存起来，然后再通过 element.isDisplayed 等等手段来检查
接口需要需要执行多次，后面几次会成功的。
如果在前提条件充足的情况下，运行接口 case,个人是没遇到，除非是发送无效等价类，服务器对你做了踢掉处理。这个时候需要写一个处理重链的函数。
这个我看看是否拿到问题需求，然后在补充写。