有持久化，不过当时做得比较简单，只是保存了生成的报告。增量覆盖、多版本（指的是开发可能调整了代码产生新版本这种）覆盖数据合并这些都没有做，所以不大好回答你怎么持久化比较好。

额，你们面试聊协议测试，不是应该先确认好协议是什么的么？你和面试官设计的两种不同的协议方式，对应的测试点也不一样，也很正常。抛开协议实现讲协议测试，这样会出现理解偏差也很正常。

至于哪个更适合，得结合完整业务场景看。比如升级卡牌如果业务上预计后续会变得非常灵活，支持任意类型材料的任意组合（运营常用手段），那面试官设计的 list 类型，确实扩展性会更强，更符合业务长期的需要。

没有特别明确的文档标准，我说下大概过程吧：

1、用例评审通过后，可以开始整理输出 showcase 场景列表。基本上是把本次需求的几个核心流程按照操作步骤梳理出来。在预计提测时间前 1-2 天发给开发，明确 showcase 内容。这部分没有太明确的标准，开发、测试、产品都能看懂（不大推荐用自己写用例的方式写这部分内容，步骤要描述清晰一些，避免歧义），并认可即可。
2、到了提测的时候，开发群里召集产品、测试到其工位进行演示。开发自己操作，把 showcase 里面包含的流程走一遍，以说明此流程没问题。如果测试或者产品有觉得想要确认或者补充的细节点，操作不复杂现场补充，操作复杂就后续自行确认。
3、流程没走通的，不要纠结，记录下来即可。如果开发燃起了 debug 的心，及时先熄灭，不要拖长 showcase 时间。showcase 完毕后，测试可以整理下记录下来的 showcase 问题，在项目群里同步出来，避免开发自己遗漏。流程阻塞类的问题直接就认为 showcase 不通过，要求开发修复后二次 showcase（尽量当天完成修复，避免延期）；非阻塞类的记录一个缺陷即可，认为 showcase 通过。通过后开发可以发出提测邮件，测试可以开始进入测试。

注意：showcase 时尽量使用测试环境，避免 showcase 通过才开始部署，部署过程中出现其他问题导致 showcase 场景测试自己还得手动再过一遍。

可以也介绍下底层原理，以及是否有什么局限性么？

点个赞，这个确实是解决代码变更后，覆盖率数据如何有效延续的一个很关键的策略。

我们之前比较简单粗暴，直接用 jacoco 的 merge 方法，所以导致有些 class 只是改变了一下代码，就导致整个 class 覆盖率被重置，确实是需要这样精细化管理。

感谢表扬

写细点其实也是在帮助自己，时间久了估计我自己也忘，写一下加深记忆，也方便以后找。我现在回看都很佩服 15 年的自己，能写那么多文章记录，有的知识点我现在不看文章都没不大记得了。

之前也是临时受命做类似的事情，不过我当时是音频直播，分享下我当时的做法：

1、梳理直播流程，包括 app 有哪些操作，这些操作背后调用什么接口，调用参数是什么，梳理出一个大致的时序图。主要梳理进直播间这部分的。

2、通过梳理了解到 app 背后会涉及两类系统，一类是业务的服务端，负责类似进房人数统计、房间号是否存在这类基本逻辑。一类是音频组件，包括音频的推拉流、消息通讯（类似公屏显示 xxx 进入房间这些广播消息）。这两个系统背后是两个技术团队

3、普通服务端的就按照普通服务端的方式做就好，比如按照预期的进房速率，算出大概的接口调用量之类的，以及了解下背后的大致系统架构，对可能会是瓶颈的中间件加监控啥的。

4、音频组件的要了解背后的架构（比如主播的推流到听众的拉流，整体是怎么走的，哪些部分用了自己的东西，哪些部分用了第三方），评估瓶颈点，再针对性测试。推拉流虽然没有类似 jmeter 这类开源的压测工具，但如果用第三方组件一般也有提供对应的工具，或者问开发用啥工具（比如 ffmpeg）测试推拉流的，自己用命令行通过循环之类的手段起多个。

5、根据前两步确定了测试方案（有哪些场景，场景里压什么接口、比例如何、要求的 TPS 和响应时间大概多少、关键系统资源消耗要求不能高于多少），找开发和产品一起做一次评审，大家确认是否 OK。OK 就开干了。

我们内部已经进行了沟通，下次类似情况，会改为使用 屏蔽 功能，屏蔽时填写屏蔽原因，便于发帖的同学了解原因。

匿名区由于没有记录作者账号信息，所以无法自动通知，请见谅。

查了下后台，是被删除了。查了下内容，主要是正文太简单了，没有前因后果，突然来这么一句，很突兀。

这种场景下，就要考虑实际业务中，不同业务的实际请求比例（有条件可以线上直接通过日志分析等手段来做，未上线的话只能靠对业务逻辑的了解和与项目成员沟通推导了），然后在压测的时候，按照基本一致的比例来分配压力。这样测出来的 TPS 和响应时间，是具备参考意义。

TPS 有意义，说明以目前的配置，你的系统实际能承受的性能水平就是这个水平了。没意义的是，你 TPS 已经没变化了，继续增大压力持续 1 小时没意义，因为你系统早就满负荷了，当响应时间增加到你觉得正常用户不可承受的水平时，就可以停止增大压力了。

至于响应时间增大，很正常。一般情况下，当全部处理线程都处于满负荷状态时（有监控工具可以看到这个信息），就已经达到最大 TPS 了。类比一下，类似常见的柜台处理业务。一共就 5 个柜台（类比 5 个工作线程），不足 5 个顾客时，还有余量，但超过 5 个顾客时，柜台已经达到最大处理速度了（以现有资源没有可提升的余量），第六个就开始排队了，继续加也只是队伍变长，柜台的处理能力还是不变的。要优化速度，要不增加柜台（增加线程数或者其他限制了速度的资源阈值），要不让每个柜台处理业务的速度加快（优化逻辑）。

这些性能测试的基本概念，建议可以看下极客时间高楼老师的性能测试课程，里面讲得比较清晰。

看来背后有故事

好建议。已经记下来了，抽空改下这个文字。

平台有草稿功能，保存按钮的旁边就是草稿了。

内容是还有没补充的，还是这就是全部了？

你的意思是，mock 时截取的图片，在换为非 mock 时，数据会对不上，导致干扰？

如果是这种场景，两次都用一样的 mock 的数据给前端获取，不就解决了？

至于怎么让自己的前端走自己的 Mock 而非走默认的测试环境，可以用 proxy 做。在 proxy 里面设定固定的返回值，我理解应该就可以了。

getInteger() 和 getInteger() 两个方法都是 com.alibaba.fastjson.JSONObject 中的两个方法，功能类似，从一个 JSONObject 对象中获取到某个 key 的 value 值，区别在于 getInteger() 返回的是一个 integer 类型的对象，而 getInteger() 返回 int 值，属于基础数据类型。

这里的第二个 getInteger ，是不是写错了，应该是 getIntValue 吧？

精准测试的目的，应该是在减少测试内容的同时，也能有效保障改动引起的质量风险。

虽然目前各种原因还没有类似接口测试这么成熟的落地方案，但梦想总归要有的，不成熟不也等于有机会么。

是否可以把解决方案也在正文末尾附上，便于后人快速解决？

不客气。

这个也只是我个人观点，实际性能工具作者自己的思考，可能还得问作者本人才能知道了。我只知道在 Jmeter 或者 nginx 里面，每个请求结束后（包括超时或异常引起的结束），都会记录一条日志，带有响应码、响应时间、记录时时间戳等信息。所以基于这类工具做 TPS 统计，最方便的方式就是基于这个日志来统计了。

如果是担心过滤过度，有 2 种方法：
1、也分析.java 文件，看 .java 文件是否有这些方法。如果没有，说明是编译时生成的，可以忽略。
2、分析是否符合自动生成的 get set 方法命名方式（例如 get+ 大写开头的属性名），如果符合，也忽略。

不过，这部分就算带上，我理解也问题不大？因为一般都不会改到，而且从链路完整性角度，带上这些也更完整。

很不错呀，麻雀虽小，五脏俱全，点赞！

针对提出的几个问题，尝试回答一下：

我在处理的时候，发现我生成了大量的 getset 方法，怎么去对这些方法进行过滤？

不知道你这里的 get set 方法，是不是 mybatis 自动生成的 entity 实体类的对应方法？如果是，遍历类的 method 进行存储的时候，应该可以过滤。

对于通过反射实例化的类是不是就没有什么好的解决方法了？

有解决方法，但要通过运行时采集调用链。可以看下这个项目：https://github.com/lastwhispers/trace-spring-boot 。
但注意一个点，运行时的采集，意味着如果没运行到这个链路，就会采集不到。所以只能作为补充，不好保障齐全。

另外，有个点我看文中没有提到，采集了 Controller 和 mybatis 的代码后，两者是怎么进行关联的？正常中间应该还有一个 service 层来把两者关联起来的吧，我看文中没有提及？

PS：项目时间长，没有任何的接口文档，也没有人愿意编写 swagger 这个问题，其实不用写也可以的。swagger 也认识 spring 各种注解，能自动生成包含路径、request 参数、response 格式（前提是代码里用 dto 这类实体类来写 response，而不是往 map 里加）的接口文档，只是会少了些字段说明之类的信息罢了。

放这个位置纯粹是为了方便。setup.js 是总入口，不用担心不会加载到，而这段代码也不算复杂，所就直接写在这个位置了。

实际工程里使用，如果有更复杂的上报策略，建议抽离单独 js 文件出来吧。

这个问题看得有点一头雾水。。。这个场景是想测试啥，想测试多节点重启是否平滑，还是什么？

重复劳动倒不至于很多，还是会有些侧重点的。只是这个容易中空的地带两边都需要参与，不能成为只是其中一方，这样容易由于不熟悉和关注点不够全面，导致遗漏。