微服务可靠性测试_微服务和单体架构下测试角色工作内容的区别有哪些

刚毕业的首份工作，鉴于当时微服务的概念还不是很响亮，当时的东家做的产品的技术架构层面还没有引入微服务概念。主要是以单体架构为主，鉴于我们的产品客户主要是各大券商，而当时还没有中台的概念，产品是在基础功能的层面上以满足券商个性化需求为主，当时做的相当难受，因为你要为每家客户开发一套系统，所以当时我们小组内的测试同时经常会去各自负责客户所在的城市出差。而福报厂是国内最早推广微服务的公司，微服务这块发展的相对比较成熟，总体而言微服务是平台化实现的一种手段。有这两段不同的工作经历，也抽空对微服务和单体架构下，测试角色的工作内容也做了一下对比。

单体架构

常见的单体架构一般是Linux+Nginx/Tomcat+Mysql+Java/PHP，一个服务中，不同业务模块作为该服务的一部分存在同一进程中，它们通过方法调用的方式进行通信。

优点

1. 开发，测试简单

2. 部署简单

3. 扩容简单(但提升性能上限的天花板低)

缺点

1. 容灾性差(核心流程出错，整体就崩了)

2. 业务耦合性高

3. 不利于提供平台化能力

微服务架构

微服务架构下，业务逻辑层被分拆成不同的服务，每个服务可以各自进行负载均衡扩展和数据库扩展，微服务之间通过远程调用/异步消息方式进行通信。

优点

1. 容灾性好

2. 服务之间(各域)可以独立部署

3. 微服务之间通过远程通信

4. 微服务是松散耦合的，单服务实现比较简单。

5. 不同服务由不同团队开发。

6. 微服务能够通过不同的编程语言与工具进行开发。

缺点

1. 架构设计复杂(依赖很多中间件：分布式中间件、消息中间件、数据库中间件)，系统越复杂出错的风险就越高

2. 项目整体周期比较长

二者项目流程区别

架构类型	需求评审	技术(系分)评审	研发	冒烟测试(提测门禁)	测试	发布	运维
单体架构	0.PRD要求评审前必须熟悉 1.效率高、周期短 2.问题提出到确认比较快速 3.UI评审单独过	1.技术基本控制1.5个小时内。 2.技术文档详细(文档之外不测) 3.评审之后基本确定设计方案 4.技术方案业务更多考虑业务实现，缺乏架构层面思考	1.研发流程较短，联调周期短 2.测试开发互动较多	1.测试提供自测用例，2.测试同学需验收100%通过允许提测	1.用例xmind编写，通过工具导入用例平台执行 2.用例评审确定自测用例 3.维护2套环境，测试&线上，测试环境一轮+回归，线上checklist回归(存在弊端，比如需求并行开发)。 4.业务型功能，全链路测试+接口自动化 5.服务性接口，接口自动化 6.注重核心业务质量(功能+非功能) 7.bug定位较简单，缺陷一般是开发业务逻辑错误导致 8.业务执行给外包，正式员工负责质量把关\新技术探索\团队管理 9.缺陷周期短，基本日结	1.发布依赖少，发布较快	1.缺陷影响范围大。 2.机器扩容不能点对点扩容(从而性能提升有限) 3.监控粒度比较粗(服务器层面监控)
微服务架构	1.评审周期长(一个需求牵扯到域较多) 2.需求目标比较明确	1.系分文档包含业务模型、数据模型、架构模型很好 2.改动点不够清晰(可以时序图标记) 3.评审之后可能受其他域的改动而调整实现方案 4.技术方案除了业务，还会增加技术风险的考量	1.单域开发周期短，但是整体项目周期较长，域间通过契约方式约定输入输出 2.研发自测用例开发设计 3.三板斧原则	1.貌似没有冒烟环节	1.维护四套环境(dev\sit\pre\生产) 2.测试内容：异常测试比重较多，重点在业务质量+技术风险防控 3.域间通过契约测试实现 4.自动化维护及时，起到的作用比较明显 5.排查bug较麻烦(业务、中间件) 6.部分业务给外包，正式员工测试工作内容比较饱和(业务+自动化+专项) 7.缺陷周期较长	1.发布依赖中间件(配置)较多 2.发布流程较重	1.机器扩容可以点对点扩容 2.监控颗粒度细(可以做到业务层面)

微服务测试难点

架构复杂度高

1. 服务间异步场景多，服务见需要保证兼容性、容错性

2. 分布式，需要保证分布式事务下的一致性

3. 团队协作难度大

4. 项目流程较重、周期较长

微服务测试策略

单体下的测试策略：分层测试模型

微服务架构下测试模型：钻石模型