嗯嗯，好像是有的 Switch 开关类型的，这个值会变化，大部分其余的控件都没变化

嗯嗯，是个思路，只能通过点击后，其余元素导向的变化，来验证了； 比如筛选后，列表变化；选中后，输入框变化这种

哦哦多谢，我们都是这种类型，不是 button

我目前的思考就是，这种选中的样式，不好自动化断言，那就手动来执行，这种用例就不做到自动化里。或者用例执行后截图，人工看报告结果，人工干预验证结果

我最近也在思考这个问题；考虑加入代理，可以验证前台点击后，请求传的入参对不对，或者说前台是否触发了这个接口，相当于验证了点击生效； 在这代理可以抓取接口反参，验证列表、筛选等功能的数据正确性，这种数据验证 UI 断言不好做；还可以通过代理 mock 特殊数据，然后验证前端 UI 的展示；但是我还没着手去做，看你 5 年前问的问题，不知道你有事实落地方案么？

嗯嗯，还好这种局部刷新元素的场景不多；还是 wda 问题，没有考虑到这种情况。我和 AI 聊了两天了，AI 让我去改 wda 源码了。。。我也是服了= =，

我的处理方案。。。太 low 了。。。

多谢大佬回复，越狱我没弄过，我先老老实实有线跑，等有空了，试试这个方案

感谢大佬回复，deepseek 的方案不太行哦，我就 IOS 用有线跑就行，安卓用无线跑

请问如何重启 wda；我目前的方案就是断开 inspector，然后更新 "appium:wdaLocalPort": 8700 变为 8701，这样就不会服用之前的 wda 实例，也就相当于没缓存了，然后读出新的元素； 那写脚本，就要断掉 driver，重新生成新的 driver，其实也变相解决了，但是会影响执行速度；也还好五个筛选，就获取五次 driver，每次给 caps 中端口 +1