• 推荐一本书《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. 比对两次回放之后的数据结果,除写入时间外,所有字段值完全一致

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