调研的目的是什么？
需要么满足什么需求？
有什么痛点是目前工具所不能解决的？

• websocket 接口测试？
• http/grpc 主流接口之外的定制化协议支持？
• 消息中间件的读写？
• 数据库查询？
• 故障模拟和注入？
• 高请求压力生成？
• UI 用例录制/回放？

技术产生和发展都是为了解决问题，满足需求。
从目的出发去反推手段也许是更有效的路径。

推荐一本书《The.Art.of.Application.Performance.Testing.From.Strategy.to.Tools.2nd.Edition》
虽然有点老了，但是讲解还是很清楚的。
多交流。

从 2 个方面考虑：

1. 通用技能：测试理论/用例编写/测试执行/报告提交/问题跟进/团队沟通/业务理解（很重要）/脚本编写（python/shell/SQL)/文档能力 (读/写）。

2.特色技能：跟你的实际经验有关，做 web 测试的，应该熟悉浏览器 inspector 中的 resource/network 相关功能，熟悉对应接口特性，对于问题发生在前端/后端能有基本判断，了解 h5 基础；

做移动端测试的，至少应该了解 Android/iOS app 组件，从源码编译到模拟器/真机运行，熟悉功能测试外，对兼容性/弱网/前端性能/安全有基本理解；

做后台测试的，应该了解从网关到微服务的调用栈（日志跟踪），微服务与数据库的交互（读写），数据库读写分离/分库分表/主从同步的方案，缓存机制，负载均衡等有所了解。

《python testing with pytest》
应用性很强的好书，讲解清晰。
看完理清楚，可以说基本上理解了自动化单元测试和功能测试原理，还跟着完整的测试了一个小型项目。
可以着手开始自己的小开源工具/插件开发了。

同意 1 楼的回答 1.
另外，可考虑在服务器使用 venv 管理自己的 python 环境, 先用 shell 脚本 activate 目标 venv，然后执行 python 脚本。

先进一线大厂是对的，可以接受标准化规范化的职业训练，接触主流技术栈。

建议有两点：

1. 注意保护身体，不要被加班和压力把身体搞垮了
2. 如果不是喜欢与人斗的性格，建议好好积累技术和业务理解，结交一些聪明，靠谱，努力的同事。
3. 如果做到了 1 和 2， 3 年后，你的认知已经比现在强很多了，也会有更多的职业选择。

一定要想清楚，什么是工作，什么是事业。
个人看法，仅供参考，欢迎交流。

你好，感谢回复。
抱歉近期由于各种原因，较忙回复你不太及时。
关于你提到的几个要点。

1. 系统不知道该回放到哪个事件，只是在启动后，从快照记录的 offset 开始，去消费之后的事件，进行处理，对系统而言，回放的事件和未处理过的新事件是一样的。
   对于每一个输入事件，存在一个全局唯一且单调自增的序列号，系统处理后产生的输出事件，会携带此序列号，也就是说，输出事件的序列号为 “输入事件序列号 - 此事件的第 n 个输出事件” 这样的格式。
   下游关心的是对于事件的处理 “不漏”，但允许重复，重复事件意味着其序列号也完全一致，因此可根据序列号去重（当序列号小于等于前一个所处理的事件序列号，则为有效事件）

2. 数据库只记录了部分关键数据，一些中间计算数据并未存储。

3. 此处的处理确实需要慎重考虑，感谢您的意见。

问题过于笼统，难以提供有效有价值的回复。

你所做的项目采用什么技术栈？你负责的是哪部分测试？
所测的产品是以什么形式提供给使用方？web?移动端？接口？
使用者是普通用户，还是其他程序员，或特定业务人员？

一般来说，自动化测试适用用场景和范围是有限的，对于相对稳定的旧有功能编写自动化脚本，进行自动化回归是实践证明有效且必要，应考虑整合进 CI 持续集成中去。

从整理回归用例开始吧。
然后做手工回归测试 -> 半自动化 ->全自动化 的迁移。

感谢回复。
关于你提到的问题：

1. 可理解为弱一致，定期同步（测试发现最高有 5 秒左右延时）。
2. 变量类型不太清楚，对应数据字段的外部接口查询是从数据库读取。
3. 抱歉，这里是我的表述不清。快照的内容就是内存中的数据， 没有历史的一个瞬间状态。 “手动指定从某中间快照回放”，是指将此快照加载到内存，回放是指顺序执行快照之后的发生所有事件（重置上游 kafka 的 offset 为此次快照时的 offset, 重新消费消息， 由消息解析出事件，根据事件对内存数据进行操作，消费完历史消息后立即再打一次快照，自此启动过程结束，开始正常服务）。

补充说明： 系统设计是 event sourcing 模式，对此模式我的理解还不太深，欢迎讨论。

感谢回复，详细说明了问题，请看楼上。

某个服务，主要功能是从上游消费事件消息，内存计算，异步落库。

定时（每 x 小时）和定量（每消费 y 个事件）进行内存快照，快照存储在网盘。
重启过程为

1. 加载最近一次快照到内存， 2.回放此次快照之后的所有事件，使内存状态恢复到重启之前的状态 3.回放完成后，立即打一个最新快照，同时把内存数据再刷库一次

问题：
如何测试这个重启机制？

我的方案：
测试一：

1. 在重启前打一个快照 A
2. 让系统消费各种事件（包含所有可能的事件类型）
3. 查询数据库相关表全量数据，写入文件 1
4. 指定从 A 快照， 重启回放
5. 查询数据库相关表全量数据，写入文件 2
6. 比较文件 1 和文件 2， 期望除写入时间外，所有字段值完全一致

测试二：

1. 手动指定从留存的最旧的快照开始回放
2. 手动指定从某中间快照回放
3. 比对两次回放之后的数据结果，除写入时间外，所有字段值完全一致

这里只关注了数据库状态，没有真正的测试到内存状态，感觉还不够完整。
大家有没有更好的思路呢？

1. 从开发提交规范上进行管控，每次 commit 只针对某单独问题。参考 google 的代码提交规范，适度简化。
2. 做 code review 和处理 pr 的人按规范做事。
3. 所部署镜像绑定 tag，测试拉取该 tag 对应的 commit，做一次 git icdiff 看看就好。

1. 允许重复的话，递归生成，循环复制倍增试试，要么 C++/Go 等开多线程/协程处理。
2. 单元测试/基线测试，比如调用某方法 10 万次，传入不同长度的文件，max/min/avg/mid 处理时长，与文件大小，数据结构深度的关系等， 能分析源码看实现机制会使得测试更有针对性。