嗯嗯，所以要结合团队情况看。

写配置的其实也是有办法做成复用的，最常见的方案就是关键字驱动（比如 robot framework），可以用写用例的方式写函数封装。不过会有点感觉像是四不像，简单程度上比纯数据驱动会复杂一些，毕竟可以有控制语句了（if/else/while 等），灵活程度上又没有代码灵活，没有适合的 ide 配套写起来非常难受。

我是觉得，如果编程水平实在不行的，那就直接弄录制回放，甚至考虑下此时是否适合引入自动化。因为先不论自动化脚本编写难度如何，实际自动化总会遇到一些问题需要排查，而排查解决没有一定的编程基础，是搞不定的，容易直接卡住。这种情况下，要不有专门自动化团队有能力协助搞定这些问题，要不就通过培训 + 淘汰，提高团队这方面能力。

可以考虑让运维给你临时开几台虚拟主机，直接把压测工具和脚本放到 git 仓库，然后 clone 到机房主机。跑完后把报告数据拉到本地分析生成图表。也可以考虑直接部署个 meterphere 上去，直接 web 平台操作，不用拉来拉去。

公司内网到机房的带宽是有限的，而且如果中间有 CDN 之类的挡一下，你基本压不倒实际服务。

以下仅代表个人观点：
1、写 yml 配置形式。好处是实现简单，上手也简单，容易统一。缺点是灵活性容易受限，对于相对复杂的用例，写和调试相对麻烦，不好复用（不是复制粘贴，特指调用已有的某些步骤）。
2、直接写代码。好处是非常灵活，缺点也是过于灵活，没有好的规范容易乱。同时上手也相对难一些，需要有一些编程基础。

具体选哪个，核心看你们目前团队的编程水平。会编程的人多，第二种会更好，因为灵活性足够高，因此用例怎么多也不至于太乱。如果大部分不会编程，选第一种，甚至直接选录制回放生成脚本的可能更合适。

做的项目全部没有效果数据，看不出掌握程度和项目难度。比如自动化多少用例，通过率百分之多少，突破过什么难点，都没提。体现不出水平，默认认为水平不高，也看出总结归纳能力不强，有需要当一些项目负责人或小组长，会有点悬

见过一些 1-2 年的简历，写得也差不多，属于都会不精。3 年最好有一个精一点的，详细写下，突出深度。

建议你看看 chrome 开发者工具里的 lighthouse 和 performance ，注意不是直接看界面（这个东西还没简单到直接看界面就无师自通），而是去找相关的使用文档先了解下。这两个就是做前端性能检测相关的事情的。

另外，浏览器提示卡死这个现象，本身就基本上可以排除服务端原因。因为服务端再怎么慢，也只会导致请求超时（请求都是后台异步的，本质就是持续的等待），不会导致资源耗光引起浏览器认为卡住（个人理解应该是 UI 主线程卡住，没法响应任何用户操作事件）。同时也通过看浏览器 network 里面这个服务端请求的返回耗时，看是先返回，还是先卡住。

你们改 header 的目的是什么，只有改 header 这条路可以走吗？

如果是，改 header 这个，我理解也可以直接在 wifi 路由器里，或者弄个 http proxy ，来篡改请求数据？

这个问题有点伸手了，先搜索引擎搜索下？

可能你说的距离和我理解的不大一样。你说的看起来像是楼层高度，我说的是楼层间隔，即中间隔了几层。1 楼和 2 楼间隔是 1（2-1=1），2 楼和 3 楼间隔也是 1（3-2=1）。

有楼层高度是会更精确，但实际上楼层高度差异很大（某楼层高度是其它楼层的 2 倍甚至更多）的楼毕竟是少数，而且差异 0.5 米按照电梯的速度，时间差异也基本在 1-2 秒内，从等电梯的人角度看，这个差异几乎可以忽略不计？对于电梯公司来说，少数几套通用算法走天下，成本比每个大楼还得根据楼层高度来调整算法要低不少吧。

公司给不到技术支持，可以多上来社区提问哈。社区有专门问答区的，大家都会看到，得到答复也快而准。

提问方式可以参照下那些回答数比较多的是怎么提的，仿照着来。社区毕竟不像同事，可以立即互动，所以尽量把问题描述清楚，这样才能更好的得到最佳答案。

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

其次，按照目前情况来看，一线大厂的薪酬，和二三线的银行，差距会挺大的（差 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 加载出问题了。