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

1、团队概况

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

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

 接下来给你们介绍一下中台测试团队的质量保障体系以及咱们在测试效率提高上作的事情。

2、中台质量保障体系

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

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、中台测试效率提高

 为了提高你们的测试效率，咱们开发了不少工具。部分也在测试博客内作了详细的介绍，篇幅有限，简单介绍几个。

3.1 测试平台

 测试平台包含数据工厂、用例平台、mock工厂、云测平台、测试报告等。你们能够点击到具体的文章查阅详细设计思路。

3.2 混沌工程

 微服务化后，快速迭代的门槛愈来愈低，可是对复杂系统稳定性的考验却在成倍增加，在复杂的分布式服务体系中，故障发生的随机性和不可预测性都大大增长了。混沌工程能够提升系统弹性，经过设计和执行一系列实验，帮助咱们提早发现系统中潜在的问题，除了常规故障注入，也能够探究更多其余的非故障类的场景。关于混沌工程的介绍能够看这里

3.3 持续交付

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

3.4 公交车系统

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

3.5 线上拨测系统

 在介绍质量保障体系时提到过上线后的节点，咱们主要经过线上业务监控和拨测系统进行质量防御，关于拨测系统的详细介绍能够见这里。

3.6 性能测试平台

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

3.7 度量平台

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

3.8 覆盖率与精准

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

以上是团队的大体状况介绍，篇幅有限，不少东西没有罗列。有赞测试组在持续招人中，大量岗位空缺，欢迎你们加入，能够一对一详细讲解，有意向换工做的同窗欢迎发简历到 winta【@】youzan.com ，当天便可回复。