本文主要谈如何构建微服务的质量体系。在这之前,大家先简单了解下几个问题:
1.为什么用微服务
单体应用就是将应用程序的所有功能都打包成一个独立的单元,最终以一个 WAR 包或 JAR 包存在,里面包含 DAO,Service、UI 等所有的逻辑。不幸的是,这种简单的单元有很大的局限性。应用程序随着业务需求的迭代,功能的追加扩展,最终成为一个庞然大物。
复杂性高:业务规模和团队规模发展的一定阶段,模块耦合严重,代码难以理解,质量变差
交付效率低:构建和部署耗时长,难以定位问题,开发效率低,全量部署耗时长、影响范围广、风险大,发布频次低
伸缩性 (scalable) 差:单体只能按整体横向扩展,无法分模块垂直扩展
可靠性差:一个 bug 有可能引起整个应用的崩溃
阻碍技术创新:受技术栈限制,团队成员使用同一框架和语言
2.什么是微服务
微服务架构:将单体应用拆分为多个高内聚低耦合的小型服务,每个小服务运行在独立进程,由不同的团队开发和维护,服务间采用轻量级通信机制,独立自动部署,可以采用不同的语言及存储。微服务的优点:
易于开发与维护:微服务相对小,易于理解
独立部署:一个微服务的修改不需要协调其它服务
伸缩性强:每个服务都可按硬件资源的需求进行独立扩容
与组织结构相匹配:微服务架构可以更好将架构和组织相匹配,每个团队独立负责某些服务,获得更高的生产力
技术异构性:使用最适合该服务的技术,降低尝试新技术的成本
微服务的介绍有很多,可以参考:https://zhuanlan.zhihu.com/p/32945365
3.微服务带来的质量挑战
系统依赖性增加:将单体应用转成微服务,虽然增加了缩放能力和灵活性,但是引入了更多的依赖,使系统整体变的更复杂,使测试环境的搭建配置以及校验指标更加难以掌控。
并行开发障碍:系统依赖性的增加还会给微服务的并行开发工作造成影响,需要等待其他微服务测试环境部署完毕,才能实现集成、测试。微服务数量越多,需要考虑的对象就越是广泛
影响传统测试方法:传统测试方法往往通过 UI 测试进行验证,而微服务的测试方案更加复杂。不仅需要验证各独立微服务,还需要检查整体业务的执行路径
4.质量体系如何搭建
4.1 下面是比较通用的微服务架构下质量保障体系图
基础质量平台
有一套完整的好用的自动化测试框架,支撑相关人员去写各种维度(单元、接口、端到端)的自动化测试
有好用的持续集成、回归能力
有代码的质量度量方法,比如根据代码的复杂度、自动化覆盖率、代码的规范等
任何要合并到主干的代码必须经过代码门禁检测,门禁的内容可以根据实际情况定义,比如:代码规范要符合要求、自动化通过率要符合要求,通过之后才允许合并
在业务负责,成功率不高的场景下,需要具备精准测试的能力,否则排查大量失败的用例,是一件极其痛苦的事情
线下质量
所有的测试用例能实现自动化的一定要自动化,这里我建议自动化的粒度要细:单元测试、接口测试(针对系统内部的接口测试,本地启动 spring 容器,偏系统功能测试,调用第三方系统可以选择 mock,测试代码需要集成在业务系统里)、端到端测试(根据自身业务情况,可以选择从业务的中部端到端,也可以从业务最顶部端到端,测试代码相对独立)
针对业务现状,约定好研发流程
有需要的业务可以进行专项测试
大部分的同学会发现,工作中的很多时间会花在咨询上,这里尽量将所有的咨询都工具化、一键化,无法工具化的就文档化,然后通过机器人(大部门的通讯工具都支持,比如钉钉)的方式对外提供服务
线上质量
相信大部门公司应该都具备灰度、蓝绿的发布过程
线上平台功能的问题一定是技术人员第一时间发现,如果不是,请反思。这里的线上监控可以分为两类,一类是线上自动化用例监控,一类是摘要日志的监控
资金类的业务数据核对非常重要,尽量做到实时、T+M、T+H 核对
大数据测试,将线上的流量存储下来,在线下、线上回放,这里需要注意隐私数据的脱敏保护
4.2 下面是自动化测试框架设计图
核心思路:一切组件化,依靠模板串联组件,测试同学只需要关心测试场景和测试数据,不用关心代码实现,配合可视化的 idea 插件,可以快速高效的编写自动化用例
4.3 有了上述质量防控体系,整个迭代将会变成如下流程:
这里需要强调,针对目前互联网行业既要快速迭代,又要保障质量,那么一定要有强大的快速的自动化回归体系,否则上面的流程肯定无法实施。很多人会发现业务背景比较复杂的情况下,自动化耗时久,成功率低,不仅没有帮助测试人员提高效率,反而成了负担。针对这种情况,建议重接口自动化,轻端到端自动化,同时做好精准测试。
下一篇文章将会和大家分享精准测试的技术实现方案。
欢迎关注个人技术网站:http://www.runtester.com