想先确认下，楼主对于 “好走” 的定义是啥？这个用词不大准确，每个人都有每个人的理解。

其次，按照目前情况来看，一线大厂的薪酬，和二三线的银行，差距会挺大的（差 2-3 倍甚至更大），天花版差异也大。一般除想得特别透彻（赚够钱，不再关注钱方面的事情），或者迫于无奈（比如加不动班了），否则一般情况下，应该没有人会愿意放弃丰厚的薪酬和前途，回去二三线做个没啥发展空间的测试的。

不过现在二三线发展也挺快，大厂也逐渐有二三线的分部，我看到更多的同学选择是在大厂内部转岗去二三线分部，拿着一线大厂的薪酬，在二三线消费相对低的城市里相对优雅地生活。

总结：先去大厂总归没错，有这段经历，以后选择也比别人多。至于是否选择二三线银行，这个到了那个时候再去考虑把。

我提的这个方案算可以么？几乎完全不知道 是指其他楼层吧，如果电梯是在 1F 或者 B1F，按照题目里的条件，只要一开门就知道了。

现在这家公司没有涉及到自动化，我自己后面是想往自动化靠近，就自己不能实践到工作中，这样效率就比较低

这里想确认下，公司没有涉及自动化，和你自己不能把自动化实践到工作中，关联是什么？公司没有涉及自动化，你也可以本地自己搭，自己用的。我自己平时也会做些便利自己的小脚本。

赠送的蓝钻可用户参与此游戏 这句话怎么看起来怪怪的？

这类游戏玩法我们也有类似的。前端一般需要保障
1、操作没问题。比如下注是对的，不会点一下变成 +2 之类的卡顿
2、展示没问题。底部角色记录、倒计时、钻石使用数这些，都要正确。开奖动画和开奖结果要正确。特别是倒计时，要保障大家都同步开奖（我们这边是这样，不知道你们有没有差别），所以倒计时准确度需要在 1 秒内。

不过最核心的，不是这些界面，而是背后的开奖逻辑。最低要求，是要保证这个游戏的庄家（就是公司）是能盈利的。所以这个开奖规则本身设计就要很严谨，实现也必须保障和设计保持一致。所以测试重点是在这个开奖规则的实现是否准确，以及在调整各种配置后（微调概率啥的）也是能正确按照新配置来开奖的。

从你给的信息看，你现在是一个困境，你想学点东西来跳槽，但你发现不跳槽自己学不好东西。结果就是东西没学好，槽也跳不了
突破的关键，是提高自己的自学能力（比如去培训班，有监督），尽快学到能跳槽的水平。

同时也需要明确，自己自学，碰壁是必然的，要有耐心坚持下去。我自己试用过很多新的东西，基本没有一帆风顺的，都是有各种坑或者文档未提及的点，需要自行解决，问题多的可能 1 周都跑不起来个完整 demo。而打破这些壁的关键就在于搜索和沟通。先搜索尝试解决，解决不了可以在社区或者其他地方进行提问沟通。踩坑填坑多了，经验就会积累起来，然后再做好总结梳理，形成思维框架，就会逐步成为你的核心能力。

过来人经验，自学没有合适方法的话，容易效率很低且产出基本拿去面试没啥用。

建议你选一个方向自学下基础，然后找机会换一个能让你更容易接触到你说的这些东西的公司，在里面通过工作实践来上手吧。尽量选一些规模稍微大一点（研发团队 200 人以上）的公司，并在面试时明确了解公司内部是否有开展你说的这些测试类型。毕业生前 2-3 年，找对平台很重要，否则就浪费了学习精力最旺盛的这几年了。

好的，大概理解了。你这个感觉和之前接触过的流式处理 flink 的比较接近，要求重启后要恢复到上次消费消息的状态，然后继续往后走，保障消息处理不重不漏。

event sourcing 模式搜了下，是 Martin Flower 大神设计的微服务架构模式，通过统一的事件流来触发各个子系统的操作。但你这个好像又有点不一样。event sourcing 的核心点在于 event store ，以及聚合资源库。聚合资源库就是提供应用了最新事件后的最新数据状态，供外部查询使用。我看的是这个：https://zhuanlan.zhihu.com/p/38968012 ，如果有理解不正确的欢迎指正。

回到你这个功能，个人理解核心点应该还是保障重启后消息处理的不重不漏，即重启后可回到重启前状态。你这里的场景一、场景二应该可以满足正向场景的要求。但有几个实际使用中会出现的场景可能需要考虑下：

1. 事件是一个动态的存储内容，系统怎么知道回放到哪个事件，刚好等价于重启前的那个事件？此处如果有一些存储机制，也需要测试一下它的可靠性
2. 你这里提到正常运行时，内存和数据库基本延迟在 5 秒内，但你的快照定时是按小时/事件数来的，应该远超过 5 秒。那为何不考虑直接把数据库内容加载到内存，而是要从快照 + 事件来呢？这个点可以了解下，可能背后包含某些取舍。
3. 重启除了单纯的重启服务，还可能存在修改事件处理逻辑后重启（比如上线发布）。此时可能会出现修改逻辑后，事件处理结果和原来的不一致，把快照到重启前那一刻的事件都处理完，也不一定内存就回到当时状态。这种情况应该怎么处理才正确，我觉得可能也是需要去考虑的点。因为在根本设计上，你实际就是通过重复消费来恢复状态的，那就有可能出现逻辑改动引起数据处理结果不一致的情况。

面试官表示对于 “距离优先” 这个条件，有办法通过计算来覆盖到。

距离优先的入参是电梯离目标楼层的距离。如果按照题目说的除了电梯在 1F 和 B1F 开门外，都不知道电梯在哪，那只能基于电梯在这两个楼层来测试这个特性了。

我在想，他说的是不是这样的测试方法？
1、先想办法让电梯 B 停在 1F（找人协助啥的）
2、把电梯 A 停在 B1F
3、在 1F 按按钮，确认是电梯 B 开门，而不是 A 开门

但实际场景，可不仅仅是考虑距离优先的，还要考虑方向是否对等（比如 A 在 3 楼，但正在下；B 在 B1 楼。此时 1 楼按个下，应该让 A 过来，而不是 B 过来）。同时也没告知除了从 1F、B1F 的电梯外部按按钮外，还有什么控制手段，感觉好多东西没有交代，需要去确认。

覆盖率 0，那没有评估的必要，说明压根没测。。。

想确认下，楼主是在独立的自动化团队（专门写自动化脚本），还是在业务团队兼顾写自动化脚本？

如果是后者，价值体现应该比较容易，节省自己的工作量就是价值了。
如果是前者，光靠自动化体现价值比较难。还是要基于自动化扩展下更多的事情。单纯自动化价值实在有限。

我们之前用覆盖率，不会这么硬性指定必须达到 xx%。我们关注的是没覆盖的部分，是否能给出合理的说明（比如这个只是一个捕获异常后的日志记录，对业务不那么重要），保障不会有明显漏测即可。

好奇问下，那你们后面是怎么解决这个问题的？怎么去设计测试用例避免被带偏或者遗漏？

哦哦，我明白你意思了。
我是基于需求先写用例，然后根据设计文档进行补充调整（有一些实现细节通过，设计文档会更清晰，也更容易拆分和针对性测试）。你是直接基于设计文档写用例，确实容易走偏。

额，基于设计文档来调整用例我也挺常做的，P9 大佬是说有啥问题？

大概理解你意思了。这个功能核心是保障重启前后内存状态保持一致，实现上采用了定时全量（快照）+ 实时增量（事件）结合的方式。

这里面有几个细节点，你没有提到，想确认下：
1、内存和数据库的关系是强一致（写内存同时就写库，失败时同时删除），还是弱一致（数据库总落后于内存，定期同步保障一致）？
2、系统内这个内存具体是怎么存储的，一个全局变量，还是多个局部变量？是否有方法直接获取值（如通过外部接口 get）？
3、你的方案二有提到 "手动指定从某中间快照回放" ，感觉你这里的快照还可以进行回放，有点奇怪。能否介绍下快照实际存储的内容是什么？是类似 git 一样的所有增量集合，还是一个没有任何历史的全量记录？

打开 chrome 的开发者工具，通过 network 看看是哪里有问题？

没有样式一般就是 css 加载出问题了。

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

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

至于哪个更适合，得结合完整业务场景看。比如升级卡牌如果业务上预计后续会变得非常灵活，支持任意类型材料的任意组合（运营常用手段），那面试官设计的 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 就开干了。

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

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

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