vlambda博客
学习文章列表

背景

事前

        当我第一次听到这个事的时候，内心是拒绝的，1）改动太大，两个月后就是双 11 了，风险太高；2）订单 QA 团队新人较多，还没有熟悉那么多复杂业务流程。但结合 618 大促 N 多轮的压测及压测后的数据，结合当时线上已经存在单表超亿条数据的情况，数据库已经成为瓶颈，详细背景可见《》，最终还是接受了这件事；

先说一下分库分表项目的特点：

1. 订单这次是新增一个与数据库交互的原子层服务，逻辑服务改动很小；
2. 理论上只是底层改动，上层业务无感知；
3. 项目是由订单技术发起，需要业务方QA配合进行回归测试；

对于以上特点，针对性的测试点就是

1. 要保证新老服务接口返回结果的一致性；
2. 虽然“理论上”上层业务无感知，但是还是要走一遍涉及订单的业务的核心场景，以保障线上订单的创建、状态流转正常；

        “凡事预则立”，既然要做，那就提前做好准备工作，首先提前整理并列出需要做的事情，然后 QA 和 RD 一起结合可以投入的资源制定一下节奏；

大项目在制定节奏时要按照以下原则：

1. 要评估一下哪些可以提前做，哪些可以同步做；
2. 合理评估工作量，不要盲目托大；
3. 每个阶段要预留 buffer，留有 plan B；
4. 从“目标”出发，寻找解法；

事中

        根据分库分表项目的特性，我们把测试的生命周期划分为以下几个阶段：

【打好招呼】、【CR】、【diff阶段】、【功能测试】、【扫尾阶段】、【灰度上线】、【压测】

测试周期过程，使用项目甘特图进行细化管理；

【打好招呼】

        项目立项后，就要向上反馈需要业务方协助测试，以便业务方 QA 负责人提前预留资源，避免临时要资源的情况发生；

        技术方案评审后，整体的实现方案进行了微调，但整体节奏没有大的变动；技术方案确定后，整个项目的时间节点才算确定下来；

        准备测试启动会，拉齐认知，刚开始我认为拉个群说一下这个事情就可以了，领导告诉我只有自己重视这件事情，那么别人才会重视，必要的会议及节点是不能省的；

【CR】

        线上运行的系统用到了其他数据库中间件，技术方案中需要先下掉老中间件才可以进行后续的步骤，理论上原用到老中间件代码的地方改为直接改为读新库从库就可以了，对于这个场景，如果投入大量人力进行回归的话，工作量不可控以及后续的进度也会受到影响，另因为改动属于逻辑平移形式的改动，采用CR的方式，效果明显且质量同样有保障，加上细粒度的灰度降低风险。所以老中间件下线的部分采用了CR的方式进行质量保障。

资料梳理

        业务梳理及用例编写，中台 QA 按照业务模块划分各自负责的业务，进行业务梳理和用例编写，并在整个测试周期作为各模块负责人与业务方进行合作，并拉上业务 QA 进行用例评审，提前找业务方 QA 准备相关的数据构造；

【diff 阶段】

        提测后，先进行接口 diff，按照每人每天进行任务拆解，使用 testNG 自带的断言类进行比对，所有不一致的返回值都需要 RD 来判断一下是否有影响，例如：老接口返回 null，新接口返回 0；刚开始时间会慢，后期节奏就会很快；

        diff 后期，抽出一个同学，先进行功能测试，走通核心业务的主流程，避免业务介入测试时，流程还存在阻断的情况；其他人继续进行接口 diff，因为接口太多，有不少接口在线上调用量很少，即使是进行 diff，场景也很难构造，在 diff 阶段已经超时 2 天后，对剩余的接口进行了整理，标出常用接口进行重点突破，非常用接口放到功能测试之后，在继续进行；

        每天下班前进行站会，前期主要对做了哪些，进度过半后，会上主要对还遗留哪些；列出待办事项，指定到具体的跟进人；

【功能测试】

        进入功能测试阶段，涉及的业务方比较多，但整体上业务侧是在中台之后进入功能测试，这里需要解释一下，为什么要进行两次功能测试？关注点不一样，中台更关注订单节点的流转、钱货的流向，业务方更关注业务流程和自定义交互的展示是否正确；

        这个期间，在站会前需要更新详细进度表，业务梳理的时候，已经按照业务模块指定了负责人，各负责人需要及时更细进度表，追踪业务进度，及时帮助业务方 QA 解决测试过程中的问题；在线下测试完成或沙箱测试完成时，在测试沟通群中同步进度；

【扫尾阶段】

        项目时间跨度长，越到后期越需要保证质量，而且越到后期，遗留的都是难啃的“骨头”，但还是要保证质量优先，每天站会时，只过遗留的问题和明日待办事项；

【灰度上线】

        整个测试阶段完成后，就到了灰度上线的环节，转转技术中心有一套完善的事故报告机制，为了避免“上报告”，灰度方案需要保证即使出了事故影响范围也可控，影响时长也可控。影响范围由白名单+灰度机器来控制，逐步扩大范围，首先收集 QA 及中台产品的 UID 做线上灰度，再扩展到单量较小的业务线，然后再全量；线上有多台机器，上班时先部署一台，下班后回滚到原来的分支；影响时长由开关来控制，本项目改动，对外接口不变，因此可以重点关注灰度机器的 error 日志和数据同步中间表，发现异常，及时关闭开关；这个时候虽然没有每日站会，但还是要“测试右移”，每天关注灰度进度及线上 bug 量；

        线上灰度分四个阶段：写旧同步写新读旧、写旧同步写新读新、写新同步写旧读新、写新读新，前三个阶段 RD 都会查看同步表中的异常数据，随时可以改回写旧读旧，具体可以参考 RD 后续的技术文章；

【压测】

        灰度完成后，离双 11 已经很近了，留给压测的时间已经不多，幸好 618 大促时的场景脚本只需要简单的改动就能用，并且双 11 改变了策略，以大促预估转换率为基准，上浮一定空间后，算出下单的最大峰值；人工值守+定时任务帮助 RD 发现阻塞点；

事后

        个人认为，双 11 平稳度过后，才算项目真正的“事后”，在所有项目小伙伴齐心协力下，项目赶上了双 11，并且保障了双 11 的平稳度过；现在回头来看有几点心得和收获：

1. “早走一步”，中台先介入，要保证业务介入时，基本流程可用，节省对方的时间，就是节省自己的时间；
2. 动态调整，diff 阶段超时了，及时改变策略，不能一直卡着；
3. 站会时，项目前期只过已完成的，后期只过未完成的；
4. 提前进行业务梳理很有必要；

        当然也留下了几点遗憾：接口测试平台在 diff 阶段没有应用上；测试期间没有梳理不同业务的代码调用链路，并“顺道”整一套自动化用例；diff 阶段资源有点多；