和本次需求无关的，这个定义其实还是有灰色地带。

比如为了这次需求实现更便利，调整了以前一些代码的实现模式，这种算是私自夹带代码不？

回归正题，从工具角度解决这个问题，思路上我想到 2 个点：
1、类似精准测试，从代码改动点结合用例执行的覆盖率数据，倒推大概影响的用例或者功能。这样通过看影响功能来辅助倒推是不是有影响一些不该影响的功能。
2、在前期技术方案阶段，就细化到预计需要改动的点（到文件和方法级别），工具检查是否有超出范围的改动。

不过说实话，这两个工具解决私自夹带问题，有点杀猪用牛刀，大材小用了。

根据以前的经验，夹带私货只要测试有覆盖，其实风险还是可控的。我们以前针对这类问题的解决方案是：
1、确认预发环境最后一次构建的版本，到线上实际发布的版本，代码是否有不同点（根据之前线上问题经验，夹带私货导致出线上问题，90% 以上是这个时候引入的修改引起的）。当时主要是人工，当然工具也是可以的，比较 commit 历史即可。
2、如果真的出问题，那就需要复盘时强调影响范围的正确同步，同时相应的开发一起背锅，该影响绩效的影响绩效。
3、同时也引导开发要优化代码或者解决遗留 bug，单独提出即可，并尽量影响范围和本次需求范围重合度高一些，这样不增加测试负担，同时开发也能做好代码优化。

我也好好奇，怎么知道明天的登录用户数

如果你说的是性能测试里的场景预估，那可以根据历史数据 + 未来运营计划（如活动计划）来预估。

从报错日志看，是 adb 命令响应超时了（设定值是 20 秒，超时自动认为 session 创建失败）

你确认相同的脚本和配置，其他非 M1 机器没问题吗？试下重启下测试机 + 重启下电脑端的 adb server ？

PS：下次不要贴图，直接复制粘贴文字。图里字小，看起来非常不方便

这个问的好深，不准备很多真的答不上。。。

想确认下，你的 data.py 数据的更新，是在什么时候更新的？

听你意思，是在运行所有用例前？

如果是，时机改为是运行任意用例前，那是不是就可以做到不管是首次执行还是重试执行，都会使用新的数据了？

PS：我觉得你问题的核心，是先排查清楚用例不稳定的原因，针对性解决，而不是纠结怎么重跑？

挺实用的工具，点赞。

提个小建议，如果可能，建议上 ELK，在线查日志和预警都方便很多。

哈哈，没想到还有一样做法的。握个爪

我觉得偏门，主要是和自动化测试的一些原则违背了。大量的一次性数据，虽然不影响什么，但还是会有点不大舒服。

我们用的 java 的 testng ，重跑机制和你第二个比较接近。

没太明白你说的 重跑时的数据和第一次数据肯定是一样的 是为啥？我们每个用例 setup 阶段就会创建新数据了，所以重跑用的数据不会和第一次一样的。

正统做法：
1、tearDown 里做好删除（调删除接口或直接删除数据库数据）。方便重复使用。
2、每次都重新初始化完整数据库内容，保证干净

但我们是金融类系统，为了方便回溯，系统其实是没有任何硬删除的。软删除且添加时带有一些不能重复的 key，会导致二次添加直接失败。直接删数据也不容易删干净，各个系统间有比较多关联关系。

这种情况下我们的偏门解法：每次都用新数据。从用户注册开始，全部都是新的数据。

这些插件是 jvm-sandbox-repeater 的插件，不需要另外启动。启动 repeater 并且提前做好配置就可以了。

金融系统的设计应该都需要考虑安全性的。后端做校验，做粗了就只是恒等式校验（比如你这个场景的 a-b=c ），没啥用。做细了基本就是再算一遍，确认和前端一样，这样又变成了重复劳动，维护成本增加。

所以大部分情况，都是前端不做计算，要计算就请求后端，后端返回计算结果。最多会做试算，但不会以此为准确值。

这里感觉有点问题。

vue 或者 react 这些现在流行的前端框架，基本都是带有数据双向绑定的特性，即界面的数据一更新，js 里面对应的值和基于这个值计算的所有值都会立即自动更新（有个 computed 计算属性，里面固定写 c=a-b ，那 a 或者 b 有变化，c 就会自动变）。

一般用这种框架，应该不需要监控失焦这类事件来触发值变化，除非是数据没有绑定到 js 里的 data 值，导致 vue 监控不到数据变化。

OK，理解。

其实只要这些计算由服务端做，会简单很多。前端交互基本都是各种相互关联事件流，组合方式多，容易遗漏。服务端基本就一个请求一个返回，会简单很多。

倒不是要你描述清楚技术层面的问题，但操作交互还是需要说清楚的。你这个答复还是没看懂，具体的操作步骤是什么，先点哪里，后操作哪里，这些操作效果的预期和实际有啥不同。

我也有想过这种可能，但这个交互设计好奇怪。。。就不给人家纯键盘操作了么。

涉及金额的，我们前端都只做试算，真正入账的金额都是在后端算。因为前端或者接口，都是很容易被伪造的。

PS：你的步骤里，没有收到鼠标移动的操作，所以他没有做 a-b=c 这个没太懂。鼠标移动操作这个没太看懂。

之前试用的时候，web 平台启动倒不复杂，但配套的 java agent 发现用不了，提示 class not found 。你有遇到不？

嗯嗯，我们大部分团队也是一个人一个测试集，一般一个迭代 1-2 个测试。但有些团队一个迭代有 6 个测试以上，所以需要共用测试集。

[Appium] Closing session, cause was 'New Command Timeout of 60 seconds expired. Try customizing the timeout using the 'newCommandTimeout' desired capability'

这条日志你看一下？里面写得很清晰了。

你用这个 url 看看，实际运行时 wda 的 fps 配置是多少？

http://<这里替换成你的 wda 地址>/session/<这里替换成你的 sessionId >/appium/settings

接口返回值大概是类似下面这样：

{
  "value" : {
    "screenshotOrientation" : "auto",
    "shouldUseCompactResponses" : true,
    "mjpegServerFramerate" : 30,
    "snapshotMaxDepth" : 50,
    "activeAppDetectionPoint" : "64.00,64.00",
    "acceptAlertButtonSelector" : "",
    "snapshotTimeout" : 15,
    "elementResponseAttributes" : "type,label",
    "keyboardPrediction" : 0,
    "screenshotQuality" : 1,
    "keyboardAutocorrection" : 0,
    "useFirstMatch" : false,
    "reduceMotion" : false,
    "defaultActiveApplication" : "auto",
    "mjpegScalingFactor" : 100,
    "mjpegServerScreenshotQuality" : 25,
    "dismissAlertButtonSelector" : "",
    "includeNonModalElements" : false
  },
  "sessionId" : "1053FDC1-77AC-4674-A0BF-04C7C1605098"
}

上面这个值里的 mjpegServerFramerate 就是实际使用的最高帧率。

我目前的改法，是直接改 atx 源码，建立 session 后，发一个请求去修改帧率的，默认好像是 15。实践中修改为 30，感受上会比较流畅，大部分时间帧率会在 25-30 之间。改为 60，实际受限于 wda 性能，也到不了 60 的，反而可能因为帧率不稳定感觉卡卡的。具体改动的 diff 截图发你参考下

对于运行速度这个，感觉 selenium 也不慢。有相同操作下两者运行速度差异的对比数据吗？

我觉得学一下倒无妨，留个印象，有时候广度就是这么来的，随性舒服，比如看到一个技术点感兴趣，就会花点时间去找下相关的材料，了解清楚背后大致的原理什么的。只是我一般会限制自己学习时间，比如设置个 20 分钟倒计时，到点就停响起闹钟停止探究，避免耽误正事。

真正要深入的技能，还是建议在工作中去试用，并尽可能争取到资源去落地应用，这样才能深入。毕竟工作时间有 8 小时以上，投入时间足够多，而且一旦立项也会有各种监督保障你不会半途而废，这样会比自己一直只是自学要来的高效靠谱。

会不会遇到后端改了自己代码，但没改文档里面的参数，导致文档落后于代码？这个实践中是通过什么方法来保障同步呢？

个人之前用的大多是类似 swagger 这类从代码生成文档的工具，这样一致性保障可以程序全自动完成，避免人为疏忽遗漏。也想交流了解下看这类通过文档生成代码的，在这个方面具体是怎么保障的。

好奇问一个点，这里面提到的最佳实践里，好像没提到 "你这接口参数怎么又变了？" 的解决方案？这个应该是前后端并行开发最容易遇到的问题了。