xcuitest 应该本身就支持 Macos app 吧，没太明白为何要额外关联个 ios ？可以具体说明下你想做什么不？

看 appium 的 https://github.com/appium/appium-mac2-driver ，底层也是用的 xcuitest 做的。你可以研究下。

1、登录这个 token 有效期多久？是否可以预先准备，压测时直接使用，而不是压测时才获取？

2、TPS 达到多少合适，要看你业务峰值压力预估情况，没有通用参考值。如果是已经上线有线上数据的，可以根据线上数据以及业务预估业务峰值（比如搞活动）会比日常的峰值多多少倍，来预估；如果未上线，那就要自己结合业务情况评估了，最好评估后拉上开发、产品一起确认，达成共识。举个例子，假设预估业务高峰期会达到一小时 1000 人左右进行驾驶证申请，那驾驶证申请接口的 TPS 要求就是 1000/(60*60)=0.27 。

PS：不要盲目用什么二八原则按天估算，这就是纯 yy 的。实际日常业务高峰期情况怎样，各个接口负荷情况如何，找运维拉个单日各接口调用量的图表看更靠谱。

运行期才出现的、通过反射等方式的调用大家是怎么分析调用的。

前面忘了回答，这种原理上就无法通过静态分析来做了，只能通过运行时的动态调用链路记录来做，而且没法保障是否全（没跑到就不会被记录），只能作为补充。

首先，我理解你的链路每个节点，具象到代码层面，应该就是每个函数的入口了吧。那确认链路是否有被覆盖，你得用会记录每个函数入口信息组合的链路跟踪工具（比如一些服务端 APM 工具），记录每个从服务入口进来后的链路。

代码覆盖率工具一般关注的只是是否覆盖这个结果，不关注通过什么链路覆盖这个过程，也不会记录这种信息。

哈哈，这种情况，直接走就好了，说明现在新的领导对技术非常不看重。让我想起了《凤凰项目》书里面的情节，非技术的领导，确实容易觉得技术不是公司核心竞争力之一，看轻技术。

没看懂问题描述。标题说是 xcuitest 和 macos app 的 usb 通讯（还混了个 swift 不知道想表达什么），正文里写 ios app 和 macos app 的 usb 通讯且有结果了，只是用 xcuitest 执行这个通讯就断了。

能不能明确说下，你想实现什么效果，遇到什么问题？

google 了一下：
https://social.msdn.microsoft.com/Forums/en-US/293437b1-cc3b-4a73-9549-2e737afc14d3/can-be-my-silverlight-application-been-atacked-with-xss?forum=silverlightjavascript

大概意思是：
silverlight 1.0 理论上可能受到 XSS 攻击（因为原理上用的是 XAML + javascript ），2.0 开始用 XAML + C#/VB.NET ，应该就不会受到 XSS 攻击了。

但我自己本身对这块也不熟悉，只是搬运下别人的答案，仅作参考哈。

个人理解：

1、这个图里的总体吞吐量，实际计算公式是总样本数/总压测时长，因此你会发现和上面每个接口吞吐量加起来的和差不多。

2、对于 “系统能处理的吞吐量” ，我觉得需要加上前置条件，就是 “在存在 xxx 、xxx... 接口调用，且比例为 xx:xx:xx... 时，系统可处理的总吞吐量”。原因很简单，你的接口调用个数（调 3 个不同的接口改为调 4 个不同的接口），或者比例一旦变化，这个吞吐量的数值可能就会变了，所以没有这个前置条件，可以有无数个 “系统能处理的吞吐量” ，且都是真实压测采集到的数据。

3、一般性能测试，关注的是典型业务场景下性能是否可以抗住，所以主要是通过模拟典型业务场景下的接口调用比例去调用接口，观察此时的性能是否达标（吞吐量 + 响应时间）。此时的总体吞吐量一般会简称为 “xx 场景下的系统总体吞吐量” 。从你图上看，样本数各个接口基本是 1:1 的，感觉不像是真实业务场景（最简单的，登录和申请办证的比例一定是 1：1 么？个人经验应该不会）。如果场景本身就和现实情况差异很大，那这个场景下的性能数据就没啥意义了。

1.想问下各位大佬的公司用例评审都是用的什么格式的文档，接收程度如何？

我们全部用 xmind ，写和执行都是，并且用了基于开源 xmind 用例管理平台 AgileTC 二次开发的内部平台做在线管理，接入了公司 sso 相当于每个人自带账号。

2.你们用例评审的时候，是一条条讲吗，还是挑重点讲？

看有多少用例，大部分时间是一条一条，但不会每条都细到每个字级别，大概几秒一条的速度，只有觉得不确定会需要讨论的才会细一些，如果确实数量太多会挑重点。毕竟用例评审目的是再一次对齐产品、开发、测试对需求的理解，并且是最细粒度的，有些需求评审、技术评审遗漏的点就靠测试用例评审来统一了，所以能全部过尽量全部过。

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

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

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

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