微服务架构
是现在软件开发领域/互联网领域比较常用的架构思维，区别于单体应用，是将项目按照业务拆分为独立的项目/应用/服务，只负责一小块具体的业务或分层；
形象理解为单体应用像古代的刻板印刷，而微服务更像活字印刷术。
微服务通过轻量级接口或消息队列进行通信；
缺点：
微服务通常也是分布式系统，在系统容错，网络延迟，分布式事物等方面容易产生各类问题；
还由于技术栈的多样性，导致应用程序设计和体系结构不一致，产生维护成本；（这一点公司内部可以人为避免）
网络安全漏洞对微服务通讯的影响；
还应主要考虑成本更高的问题，包括沟通及维护成本；
可靠性，数据一致性，关联性等问题。
微服务的三大挑战：
1.架构设计成本高
2.团队协作难度大
3.测试成本高
从2个方面来保障质量：
1.选取合适的测试策略模型保障全面有效
2.建立质量保障体系，使质量保障内化为企业的组织能力
测试人员的核心竞争力：质量保障体系建设技能和测试策略分析能力还有优化测试体系的全剧视角。
微服务架构下，既需要保障各服务内部每个模块的完整性，又需要关注模块间、服务间的交互。只有这样才能提升测试覆盖率和全面性，因此，可以通过如下的分层测试来保证微服务的全面性。
微服务测试金字塔：
单元测试：从服务中最小可测试单元视角验证代码行为符合预期，以便测试出方法、类级别的缺陷。
集成测试：验证当前服务与外部模块之间的通信方式或者交互符合预期，以便测试出接口缺陷。
组件测试：将测试范围限制在被测系统的一部分（一般是单个服务），使用测试替身（test doubles）将其与其他组件隔离，以便测试出被测代码的缺陷。
契约测试：验证当前服务与外部服务之间的交互，以表明它符合消费者服务所期望的契约。
端到端测试：从用户视角验证整个系统的功能能否符合用户的预期。
探索测试：
可见，上述测试策略模型中的测试方法，是自下而上逐层扩大测试范围和边界，力保微服务架构的模块内、模块间交互、服务内、服务间交互、系统范围等维度的功能符合预期。
微服务“测试蜂巢”：
微服务“测试钻石”：金字塔之上增加了非功能性测试=安全&性能等专项测试
【概念理解】质量保障体系解读：通过一定的流程，测试技术和方法，借助于持续集成和持续交付等技术把质量保障活动有效组合进而形成系统化标准化和规范化的保障体系，同时还需要相应的度量和运营手段，以及组织能力的保障。
重点
1.流程规范
2.测试技术和方法
3.持续集成&持续交付
4.度量和运营【度量维护视角：质量、效率、产品价值】
5.组织的保障
