有赞业务中台测试团队介绍

一、团队概况

有赞帮助每一位重视产品和服务的商家成功，目前旗下拥有：有赞微商城、有赞零售、有赞美业、有赞小程序等 SaaS 软件产品，适用全行业多场景，帮商家网上开店、网上营销、管理客户、获取订单。

有赞业务中台测试团队按照职责划分为六条线：交易组、营销组、用户赋能组、商品大数据组、基保工具组和稳定性组，各组职能如下：

接下来给大家介绍一下中台测试团队的质量保障体系以及我们在测试效率提升上做的事情。

二、中台质量保障体系

在定义里面测试是对软件规格说明、软件设计和编码的最后复审。但软件质量不是测出来的，而是贯穿整个软件开发生命周期，需要各方配合，测试环节的目的只是在产品交付之前尽可能多的发现问题，测试是一个找错的过程，但无法保证经过测试的代码一定正确，无法证明程序无错。为了保证尽可能地交付高质量软件，我们会要求测试人员介入软件整个生命周期的各个关键节点，如下图所示：

2.1 需求阶段

做正确的事比正确地做事更重要，问题发现越晚，修复的成本就越高，在需求阶段测试左移，开发测试产品一起参与需求评审，测试参与技术评审，提前发现设计问题、可测性问题，当然这会需要开发和测试有比较强的需求分析能力和测试分析能力。

2.2 开发阶段

我们会提供冒烟测试用例，并要求开发在提测之前完成执行，有两个目的，一是减少提测的轮数，提测打回的次数越多，资源浪费就越多；二是很多开发不是不想测而是不知道测什么，冒烟测试阶段测试会给开发用例，可以帮助开发梳理要自测的用例。在冒烟测试执行过程中，开发可以跟测试确定一个合理的冒烟用例数。另外关于冒烟质量的评价，我们有提测打回的机制，3 次打回需求可以不测。

开发阶段，我们对于核心应用的静态代码扫描以及单测也有一定的要求。

上图是 Martin Fowler 博客里面截的测试金字塔，越是上层的测试，就会耗费越多的精力、时间和成本。假设我们在验收阶段发现了问题，这个时候修复代码会导致之前测过的功能很可能需要重新测试一遍，项目延期的风险很高，而且 bugfix 有引入新 bug 的风险。所以我们希望在单测或者静态代码扫描阶段可以尽可能发现问题，降低成本。

2.3 测试阶段

中台需要提供各种能力到上层，目前我们整体的用例量 10000+，如此庞大的用例量无法通过单纯的功能测试进行很好地质量保障，搭建完善的自动化保障体系非常重要。

除了要求各应用的单测覆盖率和有效性以外，我们会花费较多精力在不同维度的集成测试上，如上图所示，其中展现层的业务编排通过集成测试和拨测系统进行保障，这里面还有外部调用的情况，比如电商、零售，所以我们的集成测试还会包含电商零售的 P1P2 场景。在 UI 层，业务稳定的线，会做一部分 UI 自动化，覆盖核心场景。

在这个环节，部分业务线会根据项目情况做专项测试，包括：异常测试、性能测试、安全测试和兼容性测试。另外在中台测试组每月或每季度会成立专项测试小组专门执行对应的专项测试。

2.4 发布阶段

在发布阶段，我们提供了快车发布流程、SOA 合并发布流程和 iron 公交车发布流程，各线根据业务实际情况会做微调，尽量精简并适合各自业务特点的发布流程把控。这样做的好处显而易见，上车的功能会经过测试的二次 check，跟分开单独发相比，质量更有保障，原先多次测试介入合并成一次，更能节约测试资源。

此外根据项目情况，可以选择灰度发布，灰度发布会在生产环境稳定集群之外，额外部署一个小规模的灰度集群，并通过流量控制，引入部分流量到灰度集群，进行正式生产发布前的灰度验证。流量控制可支持百分比、店铺 ID 等，如果灰度发布验证有问题，则流量重新切回稳定集群即可。

针对应用的不同情况，还可以接入流量回放平台，采集线上请求到预发环境执行，然后对比线上和预发响应，如果响应结果不一致则判断可能是预发部署的代码分支有 bug，加速回归速度。

2.5 上线阶段

在这一环节，主要通过线上业务监控和拨测系统进行质量防护，线上拨测的用例是场景化的，即使使用量非常少的业务场景也能发现问题，但不足的点在于无法发现一些特殊店铺才会触发的问题以及一些偶现问题，需要业务监控进行补充。针对前端核心场景，也会有部分的 UI 自动化运行。

三、中台测试效率提升

为了提升大家的测试效率，我们开发了很多工具。部分也在测试博客内做了详细的介绍，篇幅有限，简单介绍几个。

3.1 测试平台

测试平台包含数据工厂（https://tech.youzan.com/dmm-develop/）、用例平台、mock工厂、云测平台、测试报告等。大家可以点击到具体的文章查阅详细设计思路。

3.2 混沌工程

微服务化后，快速迭代的门槛越来越低，但是对复杂系统稳定性的考验却在成倍增长，在复杂的分布式服务体系中，故障发生的随机性和不可预测性都大大增加了。混沌工程可以提高系统弹性，通过设计和执行一系列实验，帮助我们提前发现系统中潜在的问题，除了常规故障注入，也可以探究更多其他的非故障类的场景。关于混沌工程的介绍可以看《混沌工程 - 软件系统高可用、弹性化的必由之路》。

3.3 持续交付

为了让项目更有质量地交付，我们深度参与并设计了持续交付流程，实现底层调度逻辑，将质量保障策略融入整个 pipeline，让产品交付的质量得到更好的保障。

3.4 公交车系统

公交车系统的作用是为了让整个发布测试流程更有效率，同时通过将多人变更合并发布，节约测试轮次。另外公交车系统与持续交付系统也做了一些融合，比如开发自测的需求可以在发车时及时关注到自动化测试结果。

3.5 线上拨测系统

在介绍质量保障体系时提到过上线后的节点，我们主要通过线上业务监控和拨测系统进行质量防护，关于拨测系统的详细介绍可以见《有赞线上拨测系统实践（一）》。

3.6 性能测试平台

性能测试平台目前分成单接口压测和全链路压测两块，除了让压测过程更加简单便捷以外，还提供了自动生成压测结果图表的功能，方便大家生成压测报告。

3.7 度量平台

我们提供了数据度量平台，通过分析项目过程、质量数据以及上线以后的各类数据表现，判断出不同纬度的质量情况以及软件开发生命周期中出现的问题，方便及时调整优化，这部分数据比较敏感，暂时不给截图了。

3.8 覆盖率与精准

我们目前用的覆盖率工具是 JaCoCo ，在之前的博客里面，也跟大家介绍过我们针对 JaCoCo 做的改造，使它支持计算增量代码覆盖率。另外结合调用链，我们做了精准测试工具，可以通过代码改动，精确评估影响范围。