我乐了的博客

本课时我讲解了微服务架构除了具有功能的质量属性，还具有很多非功能的质量属性，如可靠性、可测性、可用性、可扩展性等，而要验证这些属性，需要引入专项测试（非功能测试）技术。常见的专项测试技术如下：全链路压力测试基于生产环境的业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优，以此来找到系统集群的短板，从而进行有针对性的优化，或者合理地规划服务容量，节省运维成本；安全测试通过分析系统架构、对所有可能的攻击入口进行完备的测试，旨在发现系统所有可能的安全隐患点；

在本章中，我首先介绍了测试过程的大体内容，如测试设计、测试执行和测试回归，针对这些测试过程的改进可以提升测试效率，但对测试人员有比较明显的独占，虽然是必需的测试工作，但可以引入能够释放测试人力的测试技术。接着讲解了可以用于提效且可适度释放测试人力的测试技术，如自动化测试技术可以用于回归测试阶段。在实际的落地过程中，需要根据团队和业务特点来确定自动化测试的目标，针对不同层次设定合理的目标。

通常在进行技术选型时，会关注如下几个因素：团队的诉求团队在质量方面遇到了怎样的痛点问题？是个别测试人员遇到的问题还是团队整体的问题？技术的特性基于痛点问题，有哪些可选的测试技术或工具？该测试技术解决了什么问题？它有哪些优势和劣势？技术成熟度是怎样的？如果涉及工具，使用开源工具还是商业工具？落地的成本引入该技术需要怎样的成本？职能分工：该技术的落地需要哪个团队来主导，哪些团队来参与？团队是否具备落地这项技术的能力？所以说，技术的引入不是一蹴而就的，是一个痛点分析、决策的过程。

在本章中，我首先介绍了业务流程的三个阶段：产品研发阶段、日常运营/运维阶段、售后服务阶段。其中产品研发阶段是测试人员的主战场，所以测试人员应积极影响产品研发阶段，推动流程规范的制定、建设和完善，同时对日常运营/运维阶段和售后服务阶段保持关注。其次讲解了产品研发流程中的关键角色（PM、RD 和 QA），制定规范时的关键原则，如各职能角色要有 Owner 角色，整体把控该职能角色的协同，重视评审和讨论环节，提前应对风险，做到前紧后松，并对关键节点的流转严格把控。

在本章中，我讲解了质量保障体系的内涵，它将质量保障内化为企业的组织能力，其基本框架可以以不变应万变。无论对业务还是对测试人员自身来说都至关重要。紧接着我讲解了微服务架构下的质量保障体系的切入点，列举了搜索引擎、金融产品、用车场景等业务的常见特点，从业务特点和阶段、业务目标和质量挑战等方面切入，从而影响质量保障建设的侧重点和子方向的落地优先级。

端到端测试（End-to-end Test）是一种用于测试整个应用程序的流程是否符合预期的测试技术。它模拟用户真实的使用场景，通过用户界面测试应用程序，如图所示：与其他类型的测试相反，端到端测试是面向业务的，其目的是验证应用程序系统整体上是否符合业务目标。为了实现这一目标，该系统通常被视为黑盒子：尽可能完整地部署系统中的微服务，并主要通过 GUI 和 API 等公共接口对其进行操作。GUI：Graphical User Interface，又称图形用户界面或图形用户接口。

在微服务架构下，契约（Contract）是指服务的消费者（Consumer）与服务的提供者（Provider）之间交互协作的约定。契约主要包括两部分。请求（Request）：指消费者发出的请求，通常包括请求头（Header）、请求内容（URI、Path、HTTP Verb）、请求参数及取值类型和范围等。响应（Response）：指提供者返回的响应。可能包括响应的状态码（Status Word）、响应体的内容（XML/JSON） 或者错误的信息描述等。

组件（Component）通常指大型系统中任何封装良好、连贯且可独立替换的中间子系统，在微服务架构中，一般代表单个微服务，因而组件测试（Component Testing）就是对单个服务的测试。在一个典型的微服务应用程序中，会有许多微服务，且它们之间存在相互调用关系。因此，要想高效地对单个微服务进行测试，需要将其依赖的其他微服务和数据存储模块进行模拟（mock）。

本节课讲解了微服务架构下的集成测试定义，接着讲解了微服务下的集成测试的两个方面：网关组件层集成测试和数据持久层集成测试。在网关组件层集成测试中，通过服务虚拟化技术来实现对外部服务能力的模拟，通过模拟网络异常情况来构造外部服务超时、响应慢的情况。在数据持久层集成测试中，通过持久化测试框架可以避免常规持久化测试时编写大量代码和大量 SQL 语句的情况。

本篇内容讲解了单元测试的定义：它是一种软件测试方法，目的是验证软件代码中的每个单元（方法或类等）是否符合预期，即尽早在尽量小的范围内暴露错误。接着讲解了微服务架构下常见的交互场景，测试方式和对象的不同会出现社交型单元测试和孤立型单元测试两种单元测试类型。然后讲解了实际如何开展单元测试，先确定要测试的代码范围，再引入单测框架、mock 框架、断言类型、代码覆盖率工具和持续集成工具，使代码提交过程形成一个有效的单元测试质量反馈环。

确保面向微服务的测试活动具备全面性和有效性质量保障需要内化为企业的组织能力。通过对测试金字塔原理和微服务的特点分析，引入单元测试、集成测试、组件测试、契约测试和端到端测试等分层测试类型来确保测试活动的全面性，通过自身项目阶段和团队情况来选取合适的测试策略模型，以保障测试活动的有效性。要想把质量保障内化为企业的组织能力，就需要通过系统的技术和管理手段形成机制，在流程规范、测试技术、持续集成与持续交付、度量与运营、组织保障等方面构建质量保障体系。相关链接。

上述，我介绍了这么多微服务架构对软件质量保障工作带来的诸多挑战，你肯定坐不住了吧？不要担心，这些挑战都有对策。任何新技术的引入和架构的演变都在解决当前痛点问题的同时引入新的问题，那么这些新的问题也将不断变成痛点被逐个解决，这是技术演化的必然，也是互联网革命的核心（唯一的不变是变化）。任何时候挑战和机遇都是并存的，通过掌握恰当的测试策略和质量保障体系来应对这些挑战，那么你就比同行（横向比较）或过去的自己（纵向比较）具有更多的竞争力和优势，自然也会有更多的机遇。

说了这么多，我想使用两个类比，帮助你简单理解微服务架构和单体应用架构的差异：微服务架构更像是活字印刷，单体应用更像是刻版印刷。