里面也有说，之所以保留工程师批准，只是因为如果出问题线上可能有较大影响，所以还是保留了人工二次确认。实际上准确度能提高到一定程度，加上自动的灰度校验，这道关卡就可以去掉了。

这个算是一个正向循环，bug 案例越多->自动化处理比例越高，准确度越高->人工介入程度越低。

不过这个 18 年提出的，后续也没见到有什么更新，不知道是不是已经夭折了。

可以跑，前提是：
1、你的 app 用到的所有包，包括第三方依赖，都支持模拟器（有的包只支持真机 arm 指令集，不支持模拟器 x86 的）
2、你的测试内容不需要用到真机才有的特性（如扫码之类的）

满足这两个前提，然后打包的时候设定好参数打模拟器用的包（特别强调下这个，ios 用的是 oc 或 swift ，直接编译成机器码的，不是 android 那种还有个 jvm 虚拟机，所以打包时就已经设定好了能运行在什么平台上了），剩下的基本把原来真机的替换为模拟器的就可以了。

问题 1 和问题 2，归根结底还是 TPS 的统计问题。即处理事务横跨多秒时，计数应该算到起始时间段还是完成时间段。

个人理解， TPS 一般是用完成时间来计算的，因为这样计算，性能消耗成本最低（只要在完成时加一个记录即可）。如果按开始时间，甚至按照持续时间拆分，那么每个请求还得额外消耗资源去存储和计算这些。我觉得，对性能工具来说，发起大压力才是它的最根本的职责。统计数据这些说实话，只是附属功能，交给其他外部监控程序做都完全没问题（nginx 日志就可以反映每秒请求数量和每个请求的处理耗时了），没必要为了统计准确那么一点点，增加那么多系统负载，进而导致无法发起更大的压力。

至于消耗的时间统计，这个是用响应时间这个指标来统计的，不是用 TPS 。一般看性能测试结果，响应时间和 TPS 都得看。TPS 反映的是系统性能是否已到达瓶颈（即在当前配置下都已经没法再快了），响应时间反映的是达到瓶颈后整体处理时间延长的情况（即给到每个用户体感，会慢多少）。

拉一个单独的集成团队，负责整体。或者改变测试团队的结构，类似产品，按业务分，而非按端分。

我们这边用的主要是第二种，不按端分测试团队，只按业务分。如果是有些需求涉及中台型的团队（如审核系统，一对 N，不归任何一个业务线），那集成部分这个团队的测试和业务团队都执行一遍，交叉验证。

建议你可以买本《不测的秘密：精准测试之路》看看。不知道算不算是业内做得最好的（毕竟大部分实际效果你没在公司内实际用，都不好说），但应该算目前公开资料里最全的了。

facebook 还真做过这个自动修复 bug 的系统：https://www.jiqizhixin.com/articles/Facebook-ai-dubug-tool-SapFix

hmm，这种和开发人员本身习惯有关。来几次线上事故，复盘时明确说开发夹带私货不同步，让开发背下锅，就好了。因为这个夹带私货本身在研发过程就是不好的事情，正常开发领导都不应该允许这种情况在团队里随意发生。

前面 @gyyfifafans 提到的封版也是一种很好且简单的方式。只要测试握有测试环境、生产环境的代码发布版本控制权就好。

从目前我看到的几类方式上看：

基本原理上，大多是通过覆盖率来关联的。比如执行 A 用例的时候，通过覆盖率数据可以知道会执行到 a 函数。然后记录下 A 用例->a 函数 这个关系。后面如果 a 函数有变更，就会认为 A 用例需要执行。这里面也会有一些精细化的调整，比如可能会细化到函数内部的 if else 分支级别，或者结合一些算法来减少推断出来的用例数（比如一个底层网络库调用调整，全部涉及接口交互的用例都自动出来了，但实际可能只需要执行任意一条即可校验）

也有的是到接口级别，执行 A 用例，会调用 a 接口，那映射关系就是 A 用例->a 接口。 只要 a 接口有变更，A 用例就要执行。接口级别甚至可以不用覆盖率，只需要日志打印。

还有只是反推到接口级别的，通过 ASM 分析（通俗点说，有点类似于平时 idea 里的 find usage 倒推调用位置，一直倒推到 controller 层）+ 运行时数据采集（比如通过反射来调用的，就只能用这种了），反推某次代码改动影响到哪些接口，然后执行这些接口相关的接口测试用例。客户端类型的话把接口改为界面（activity/fragment/view/url），也可以同理推断

不过怎么维护好 测试用例->代码（函数/行/接口）这个映射关系，除了接口测试用例天然自带映射关系外，目前还没见到有特别好的招。

你们现在是开发提的影响范围都不靠谱，还是夹带的私货都不同步你们，导致你们没测到，所以直接在线上出问题？

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

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

回归正题，从工具角度解决这个问题，思路上我想到 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，理解。

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

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

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