可以回想看看越来越过分的原因是啥，有没有可能恢复回去之前那种还不错的氛围？如果不可能，那就走吧。

用支持分布式压测的压测工具来压？

1、楼主这个回溯上游调用，我理解和 idea 自带的 find usages 其实是类似的方式？如果是，那通过静态分析获取调用关系。这个原理上就无法准确到你例子说的 if else 程度，毕竟并非运行时的话，没人知道是否走到调用 B 的逻辑，那宁滥勿缺，肯定要把这条调用链带上。

2、不知道增量代码覆盖率数据，即直接统计有改动的代码对应行是否又被覆盖，是不是可以满足？或者可以把你这里的 “调用链” 举个具体的代码例子说明下，你的调用链定义具体是什么？从有足够细节的定义去扩展，会比从 “调用链” 这个名字去扩展要方便很多。

都到这份上了，而且还是只有一个测试，没有想出任何有留下来价值的理由。

倒是楼主在这个情况下还在忍，让我在想是不是还有什么别的吸引留下来的点但正文没提及。

1.我在对我的服务进行接口压力测试的时候，提高压力工具的并发路数，系统 TPS 只能维持在 400TPS 左右，响应时间在 100ms。我看我服务器的资源占用非常少，cpu 和内存均不超过 50%。如果是这样，我的系统一般瓶颈会在哪里，有什么查看方法。

个人经验，实际资源消耗不大，但性能上不去，那可能是某些配置限制了资源消耗，导致虽然资源没耗光，但已经没法增加消耗了。这类限制大多是在系统配置、jvm 配置、数据库连接配置等各个系统平台的配置项里，可以先排查下这些配置是否有不合理的地方（PS：如果这些配置都是用系统默认的没动过，那一定是有不合理的地方的，可以找运维协助优化一波配置项）。

2.我的后台服务会连接一个 Oracle 的数据库。如果我把 oracle 和后台服务部署在 2 台机器上，系统的 tps 在 400 左右，如果部署在同一台机器上，tps 在 900 左右。这个是为啥啊？

单纯从你的现象看，像是这两台机器之间网络连接速率太低，导致性能下降，但无法百分百确定。建议你先确认下，这两台电脑之间网络通讯的延迟和速率信息？另外，你分开部署的 2 台机器，配置和单台机器有多大差别，会不会这 2 台机器性能比 1 台机器的时候差，所以引起性能下降？

3.我调用的接口是 “校验客户密码”，用的还是同一个用户，这样是不是存在一个读取数据库缓存的概念？

这个要问开发系统背后的具体实现逻辑，理论上既可以走缓存，也可以走每次都查数据库的。至于选哪个要看开发的取舍。

我不是大佬。。。真正的大佬都在大会分享议题，我还有很多需要学习的。

以前我们内部评审 sonar 自带代码规则的时候，也有这种感觉，每个规则背后都是很多错误累积出来的经验。

是否合理没有整体业务情况上下文，不好评价。一般合并部门的决定都是从上往下整体看才能看出是否合理的，从下往上每个岗位肯定都希望有独立部门独立通道。

如果是说对测试人员是好事坏事，这个要看合并后开发怎么用。如果 leader 好，测试可以接触到很多开发的东西同时，保持测试对质量的把关权力，那是好事；如果 leader 把测试当做附属，不关心和不放权，那肯定是坏事。只是长期来说，相比有独立测试部门的，测试天花板会更低（独立部门至少还可能有总监，非独立部门估计经理就到头了，除非能力够强，连着开发一起管）。

好吧，意思就是冲着要拿规范符合度数据，那只能搞校验工具了。

你提到的那个点，如上面所说，用 json schema 是可以校验的。至于其他规范，没有信息没法给建议，自己见招拆招吧。

可以直接找到订单后，用 break 停止循环？

接口设计规范和异常处理规范，这两项都是需要入参，难实现，譬如接口设计规范其中一项，新增/编辑接口, 需在响应中包括 isSuccess、responseCode、responseMsg、data 四个参数，data 中需返回对应新增的数据 id, 以提高接口响应可信度及易测性（若新增涉及多个表，data 中需返回主表对应新增的数据 id）
（如：{"isSuccess":true,"responseCode":0,"responseMsg":"操作成功","data"：{"id":"6078f109c224ec791af5b5ab"}}）

hmm，如果按照这个示例，一个通用 jsonSchema 应该是可以满足的，只是你要区分接口类型，分出哪些是 新增/编辑 接口。

但我还是没明白，到底目标是啥，价值是啥？推研发类规范，个人理解最有效的应该是直接开发框架内限制用法，从源头上保障难以出问题，而不是搞一堆校验工具吧。比如你上面提到这个响应值包含固定参数的例子，在大一点的公司都会有这种要求，便于客户端使用通用逻辑直接判定成功或失败。而最常见的实践，是直接在网络框架里内置好标准 Response 类，固定有这 4 个参数。代码使用时只能用 Response.success(Object data)（自动设定 isSuccess=true, responseCode=成功对应的 code，responseMsg=''，data 为入参）或者 Response.error(int responseCode, String responseMsg)（自动设定 isSuccess=false, responseCode 和 responseMsg 为入参，data 为 null）等少数几个方法来进行返回，不允许直接 return 任意数据。这样既简化了代码，又落实了规范。

接口规范性，从这个名字猜测，像是验证是否符合 json schema 。不过这个猜测没啥意义，老板的用词不一定那么讲究。

但建议你和你老板聊下，了解清楚他想达到什么目标，再看对应做什么可以达到他的目标？

如果是普通程序，写个 for 循环，循环点击每个台位，直到有订单就好。 appium 有提供 findElements 方法，可以找到符合条件的所有元素。
但放在自动化测试，应该是你在前置条件就给某个指定台位生成好订单，测试时直接用这个台位就一定有订单。

因为如果前置造数据自动化里没控制，你的自动化用例就会不稳定（比如确实所有台位都没订单，那你这个用例算通过还是算不通过？）。不稳定的自动化会在后面浪费你大量时间去排查处理，所以至少在思路上就保证路径唯一，减少可变因素。

1.直接请求服务端，数据已经存储在你手机本地文件，不会被别人所影响；

没太明白。比如金融类业务，“账户余额” 数据是服务端返回的，不可能 app 内置，也不应该存储在手机本地文件（安全性考量）。这类数据不会变化么？还是说你们的业务，确实就全部 app 存储数据？

2.自动回放，我们主要是关于页面能不能跳转，也就是根据你操作的步骤，可能有一个误解，轨迹的回放，其实就是你操作的步骤加数据，所以可以保证你之前的页面，没有问题，而遍历测试指的是有序的遍历，比如你操作的了 A-B-C 页面，就会对先对 A 页面所有控件进行点击，执行完，再执行 B 页面，不会类似 monkey 的无序遍历；router 协议跳转，无法全部像有序功能测试全部验证逻辑，但一大部分可以验证，比如，进入 a，在进入 B，在进入 C，在 D 验证逻辑，那我就可以直接先进入 C，在 D 验证逻辑，数据都是我录制就有的；

这个理解了，感谢。

3.AI 的话，其实就是测试工程师测试完以后，apk 自动化上传测试的数据，服务端根据数据进行排序，类似排名，来确认这个版本哪些页面经常操作，并且这些页面是什么数据的，然后自动化就会定时去获取这些数据，进行页面跳转测试或者页面的遍历测试。其中 AI，就是自动化对数据的解析，最简单的应用。其中这个算法跟数据，还有很大改进。我们只是简单运用。

这个在我目前看到的内容来说，只是聚类或者排序算法层面，还不属于 AI 吧？AI 一般特指机器学习或者强化学习，最基础需要有模型、特征、预测值这些，但你这里都没见到有相关的信息。不建议把所有算法都套上 AI 这个名字，容易变成标题党引起反感。

赞，很实用

MTSC 大会最近 2 届也有不少华为应用市场这类偏互联网业务的出来分享，所以不至于说完全封闭。至于是否到社区之类的交流互动，估计是公司内部缺少气氛或者协议有规定吧，毕竟华为一直都比较低调。

另外，其实本身测试里面交流多的主要也是互联网领域，因为业务相似度高，容易交流。华为互联网相关业务相对较少，目前出来分享的都是应用市场、鸿蒙这类偏互联网的。如果是华为占比最大的偏通讯业务的出来交流，也不见得会在互联网测试的圈子里交流，所以可能这里也会存在幸存者偏差。

被标题吸引进来了，思路确实是挺特别的，基于 app 内部提供的 router 组件统一跳转机制，达到跳转到任意页面的能力。以前我们公司内的 app 架构师也有分享这个，通过 router 来把各个页面组件进行解耦，提高复用性。

有几个疑问点，想交流下：

1、这种 router 提供的能力，主要是 app 部分的，但进入页面后请求服务端数据，还是需要依赖服务端。一般服务端数据也会可能因为有其他人操作导致变化，会引起无法正常回放，这块是怎么处理的？
2、从楼主分享来看，自动回放/遍历方面主要关注 crash/anr ，而这种跳过所有前置步骤直接进入目标页面的方式，会不会导致一些长时间运行才会出现的问题或者组合页面才会出现的问题（比如对一些公共层数据的操作），无法出现？
3、不知道楼主在标题特意强调的 "AI" ，指的是哪部分？微信的文章也看完了，没太看到在哪里运用了 AI 。

这个工具以前所在公司别的团队调研分享有看过，当时有小范围使用，但后面也没有深度用，不知道有没有什么暗坑。

而且这个工具不开源，且比较商业化，大部分公司还是更喜欢免费开源的工具。

get，已记录 issue

你可以去一些沙龙大会看看，大部分用的是 mac 。我说下我选择 mac 的几个核心原因：

1、稳定。我的 mac 几乎天天都用，但一年也就只会因为磁盘空间不足或者要升级系统关几次机，其他大部分时间都只是合盖休眠。这样能确保我每次不用再逐个打开各个软件（日常工作一般都是好几个 idea + 浏览器 + 聊天工具开着），节省时间，思维也比较容易恢复。
2、续航强。windows 本续航能跟上 mac 的，价格基本都比 mac 贵。
3、触控板超好用。我现在日常都用触控板，鼠标基本都不怎么用了。借助触控板 + 全屏应用，能让我更专注在当前工作，不会频繁被消息打断。

看你预算，预算够 16G 内存更好，预算不够可以 8GB，或者直接看官方翻新版，一般同配置官方翻新版可以便宜 20% 左右，而且也可以免息分期。

佩服可以面 30+，手握 10 个以上 offer 的。我毕业到现在累计面试过的估计都没 30 个公司。

开源工具平台的系列文章，默认只加精第一个哈。你可以在第一个头部加上其他后续文章的链接成为一个合集。
后面有干货更足的解析文章，再加精。

感觉有点标题党。我理解的 “轻松搞起来” ，应该是某种机器学习通用套路的介绍，让大家对机器学习的认识能大道至简，快速上手？文中的介绍，感觉对学习机器学习没太大的实际指导作用吧？下面推荐的几本书，都属于专业书，不确定大家入门是否适合。西瓜书以前有看过，对于一个高数已经还给老师的我，前三章都迈不过。

也这个地方分享大家一门我看到过觉得比较不错的机器学习的教程，google 出品的机器学习速成课程，有视频、有文章、有在线练习，学起来比看书要容易记忆。据说本身设计就是用来给内部非机器学习的技术人员快速用上机器学习的，不过内容其实也蛮多的，每天 1 小时，得坚持快 1 个月左右才能完全看完第一遍。

你们这个问题，在于在团队在性能方面专业度不足、无法达成团队共识的情况下，对于性能测试相关决策，没有明确可以拍板的人。产品明显不具备能力，开发和测试意见又相左，甚至开发内部都有两种不同的意见。

解决也不难，看按照你们公司现在的情况，线上性能出严重问题要背锅，是谁来背，然后这个背锅的人/角色来拍板就可以了。拍板的人觉得现在大家都不专业，性能测试做了也没啥意义（对于你目前这个团队情况，我觉得性能测试做完，线上仍然有性能问题这个可能性确实是有的），干脆一刀切全部不做，通过线上监控 + 云服务的灵活伸缩来处理，也是可以的。

当然，从完善的质量保障角度，性能测试肯定不能全部不做，所以可以后面多给开发产品普及下性能出问题影响业务的案例，以及在后面真出事故后，复盘里增加对故障涉及接口的性能测试，这样来逐步推进。