学习 python， 做后端接口自动化，推荐这个路径

1. 官网入门教程，代码手动敲一遍，看自己的节奏，可能 1-3 个月。这样对语法，基础数据结构，内置函数， 生成器装饰器都有些概念了。
2. 学一下 pytest 框架，推荐《python testing with pytest》，或者 pytest 官方文档。英文如果有问题就跟 AI 一起学。
3. 用一下常见的 http 请求库， 开始可以用 requests， 简单好上手。 或者 httpx， 现代化风格的库，设计兼容 requests, 但集成了异步客户端，后期无痛替换集成。
4. 其他常用库，比如日志 loguru, 报告生成的 allure，一些常用的 pytest 插件。
5. 这样就可以搭建自己的接口测试框架了。
6. 按自己需求写工具，造数脚本/冒烟脚本/页面爬虫等，任何需要执行 3 遍以上的任务，就考虑其中重复的步骤是否可以用工具实现，释放自己的时间去学习。 注意业务和技术两条腿走路，不断加深理解业务模型和被测系统/服务的架构。 祝好。

找本好书系统化的学学吧， 动手把示例代码敲一遍。
针对性的搜索一些常见的面试问题做准备。
比如 python 的基本数据结构，方法，常用库。
日常写一些小工具，试着把工作中涉及到接口查询，数据处理，排序，搜索，计算的任务都用 python 做成工具。
还可以把工具打包成二进制程序给同事使用哦。

"干测试 1 年多了，功能测试、Requests 接口测试、jmeter 压测目前会这些，现在月薪 4 千 6，还需要再拓展下哪些知识，各位大佬对跳槽有什么建议吗"
“会” 是什么意思呢？试试更准确的用语言描述自己的工作能力和技能水平？

1. 功能测试，擅长什么业务领域，擅长前端还是后端？如何设计功能用例，用例如何划分优先级，前端和接口分别怎么设计用例，哪些用例是测试业务功能，哪些用例测试幂等性，数据一致性？
2. requests 接口测试是怎么做的呢？测试脚本如何组织数据/用例的？能把脚本换成其他异步库么？如何多进程执行脚本？测试用例怎么组织的？如何共享数据的？测过哪些接口？同步接口和异步接口在测试上有什么差异？
3. jmeter 压测是怎么设计和执行呢？最大发压 QPS 达到了多少？压力场景怎么设计的？测出过什么性能问题？常见的性能问题有哪些？如何排查？常见的优化方式有哪些？单服务压测和全链路压测分别怎么做？压力从哪里注入？哪些服务会受影响？消息中间件和数据库会承压么？apigateway, loadbalancer 的基本原理？服务缓存，数据库索引？常见的弹性缩扩机制？IO 密集型服务和计算密集型服务各自压测的重点是什么？ 月薪 4 千 6 是在什么地区呢？国内 1，2，3 线城市同职位的收入差别挺大的。 税前/税后？13 薪/15 薪？ 希望以上这些问题能帮助你思考。 祝好

几个建议

1. 目标是找外包吗？照外包的职位描述补强对应的能力并适当包装简历，缩短 gap 时间拿到面试机会，再用面试时的表现拿到面试官认可，视情况主动说明隐藏 gap 时间和原因也是一种选择。
2. 之前的工作经验， App 是什么行业的，前端测试一般偏重功能测试，考虑重点包装下业务领域知识和用例设计能力（可以看看书补强一下）。 找一个 App 写功能用例练练手，传 github 上也可以作为简历附件链接。
3. 建议熟练掌握 python， 找本好书老实敲完示例代码，配合 AI 提问理解，接口自动化测试其实不难。
4. 英文能力咋样？有决心补起来么？考虑海外平台接测试外包工作么？如果现在英文不行，一些平台找国内短期测试外包也有机会。报酬可能不高，但就主要是刷经验和重新进入行业的跳板了。
5. 干过 4 年，好歹也有些技术积累和人脉关系吧，这方面再想想挖掘一下？ 其他： 如果打算长期在测试领域发展，需要了解自己，行业/业务，钻研技术的好奇心，业务和技术两条腿缺一不可。 先全面发展，业务专家/前端/后端/自动化/安全/性能， 专精其中之一也不错了。 作为招聘者，最看重的就是候选人能不能干好活，是否有责任心，能否清晰的思考和沟通。 Gap/年龄这些都是辅助判断因素。

祝好

确认一下问题，题主是指的数据库主从同步不实时，使得数据在前端业务表现不一致吗？
对于这种问题，可能需要确认一下完整的数据链路，涉及到数据的生成，存储，读取，更新过程。

1. 源数据是怎么生成的？ 用户通过接口调用传入，经过服务处理，生成业务数据，然后落地到数据库吗？还是消费自 kafka 这种消息中间件呢？
2. 业务是否有使用缓存，比如 redis，数据如何落地？同步还是异步？如果是批量落地，那么每次处理的最大时间间隔和？
3. 使用的什么数据库，用的什么同步策略？
4. 业务性质是什么？ 需要什么样的数据一致性？最终一致性？写即读一执性？强一致性？
5. 服务是无状态还是有状态的？有几个 replica？如何处理并发？路由策略是怎么样的？ 建议跟产品，开发详细对一下第 4 点，达成一致的预期。 其他部分跟研发好好沟通，确认细节测试要点。 简单的 cover 测试验证，可以从 创建数据-> 读取校验数据 -> 更新数据-> 读取校验数据，比对数据是否符合预期，结合相关服务日志和数据库日志进行观察 搞定基本业务逻辑后，搞一下高并发的场景。

不是很理解这个问题。
看评论，测试的目的是为了保证迁移数据的完整性和正确性。需要对比的是文档内容，不是测试前端渲染和文本解析功能，跟编辑器毫无关系。
那么直接写个脚本，连接源库和目标库，对全量或采样数据，取出来对比就行了呗。

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

• 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 处理时长，与文件大小，数据结构深度的关系等， 能分析源码看实现机制会使得测试更有针对性。