课程介绍
随着行业主流开发方式从传统的整体式产品交付，向快节奏的微服务架构迁移，软件测试人员也要相应地调整自己的测试方法和工具，才能多快好省地提高测试覆盖率，尽早发现潜在的缺陷，在快速迭代的背景之下，确保所有微服务满足企业的质量要求。
本课程主要分为三大部分：
第一部分（第01-02课）将带领大家初步认识微服务架构，包括它的主要特征和目前的主流部署方式，尤其是它对于软件测试所带来的新挑战和要求。
第二部分（第03-09课）将通过实战开发，循序渐进地带您掌握微服务架构下的软件测试流水线的所有组成部分，全方位提升您的技术实力和思维方式。
第三部分（第10课）则会从行业发展趋势的角度，指引您在微服务架构逐渐成为主流的情况下，如何准确地定位测试工作的角色，适应行业的演变。
Frank，在跨国公司的软件开发部门深耕多年，经历各个岗位磨练，擅长 DevOps、自动化测试、持续集成/交付和前端开发。曾经云游四海，如今埋首于宇宙中心，用心打造产品，也乐于分享自己的所知所得。
课程内容
第01课：什么是微服务/strong>
微服务的由来
微服务的前身是 Peter Rodgers 博士在 2005 年度云端运算博览会上提出的微 Web 服务 (Micro-Web-Service) 。微软的 Juval Ly 随后也提出了类似的想法，并提议将其作为微软下一阶段最主要的软件架构。
2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，给出了微服务的具体定义：从本质上来说，微服务是一种架构模式。它是面向服务型架构（SOA）的一种变体，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
Martin Fowler 是国际著名的软件专家，敏捷开发方法的创始人之一，现为 ThoughtWorks 公司的首席科学家。在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都扮演着举足轻重的开创者角色。早在20世纪80年代，Fowler 就是使用对象技术构建多层企业应用的倡导者，他著有几本经典书籍： 《企业应用架构模式》、《UML精粹》和《重构》等。
微服务与传统开发方式的区别
与微服务架构相对应，传统开发方式通常被称为单体式架构（Monolithic Architecture）。所有功能都打包在一起，基本没有外部依赖，其中包含了数据输入/输出、数据处理、业务实现、错误处理、前端显示等所有逻辑。
下图显示的一个典型的单体式架构示意图：
再以上面提到的单体式 App 为例，通过用微服务架构方式对其进行改造，将会变成下面这种结构：
这种简易、明确的交互方式为契约测试（Contract Test）提供了基础，本课程的第七课《契约测试入门》将详细介绍这方面的内容。
3.每种服务不一定提供用户界面。
这意味着每种服务的测试，并不一定能够或者需要从 UI 完成。这对 API 级别的集成化测试提出了要求。本达人课的第四课《怎么针对微服务架构做集成测试将具体介绍如何进行集成化测试。
4.微服务通常还可以划分为更小的模块。
如下图所示，一个典型的微服务可以分为这几个模块：资源、业务逻辑、数据存储接口、外部通信接口等。
这就是 Mike Cohn 提出的测试金字塔（Test Pyramid），其中最重要的两个原则是：
- 应该用不同的粒度来测试应用程序；
- 层次越高，测试越少。
最底层的是单元测试（Unit Test），粒度最细，速度最快，维护成本也最低。往上是针对每种服务内部的各种模块、业务流程的测试。最上面是基于前端 UI 的测试，这部分的粒度最粗，范围最大（因为会覆盖大多数服务），但是维护成本最高，因为稍微有些细微的变化就可能需要调整脚本。而且，由于基于前端，需要设置很多响应时间和等待时间，所以速度最慢。
Mike Cohn 是 Scrum 软件开发方法的提出者之一，也是 Scrum 联盟的创始成员。他目前是 Mountain Goat Software 公司的所有者，致力于提供关于 Scrum 和 Agile 软件开发技术的培训。
3.可视化：为了降低交流成本，最好的办法就是让所有的测试结果可视化。这意味着将构建（Build）、测试（Test）、部署（Deploy）所有这些相关任务构建在一个流水线之中，让所有团队成员都可以随时监控项目进度，找到阻碍项目的瓶颈。
以下面这个典型团队为例，整个从开发、测试、构建到部署的一系列过程，都可以借助 Jenkins 或者 TeamCity 这样的任务调度工具，完全可视化，再借助 SonarQube 这样的代码质量监控工具监控测试结果。Google Analytics 或者 Microsoft 的 Azure ApplicationInsight 等云端监控工具，则可以提供实时生产环境的客户使用信息或者测试数据，让整个团队可以随时把握产品的整个流水线的运行状态。
本课总结
简单总结一下本课程所学习的内容：
- 微服务架构对软件测试提出了很多全新的挑战。
- 应对这些挑战的方法包括：
- 自动化
- 层次化
- 可视化
第03课：怎么针对微服务架构做单元测试/strong>
单元测试是开发人员编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序 list 中去，然后确认该值出现在 list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。
对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如 C 语言中单元指一个函数，Java 里单元指一个类，前端应用中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。
这节课，我们将探讨在微服务架构下，单元测试的设计、实现和质量控制。
设计：定义测试边界
要设计高效率（既运行快速又覆盖率高）的单元测试，首要要准确地定义测试边界。测试的目的就是为了验证边界里“黑盒”的行为是否符合预期，我们向黑盒输入数据，然后验证输出的正确性。在单元测试里，黑盒指的是函数或者类的方法，目的是单独测试特定代码块的行为。
但是在微服务架构中，很多时候黑盒的输出需要依赖于其他的功能或者服务，即存在外部依赖。为了更好地理解这个概念，我们以一个简单的注册功能为例：
我们可以使用模拟器来达到各种目的：
- 模拟器可返回任意的设定值，用于模拟外部函数的输出。这在测试罕见的边界情况时会非常有用，比如有些错误场景可能很少发生或者非常难以重现。
- 模拟器也可以捕捉被测试函数传给外部函数的参数，或者把这些参数记录下来。这样就可以验证被测试函数需要调用哪些外部函数，以及需要传给外部函数哪些参数。
通过对外部依赖函数使用模拟器，通常可以在几秒钟内，执行数千个单元测试。这样，开发人员就可以把单元测试加入到日常的开发工作管线（Pipeline）当中，包括直接集成到常用的 IDE 里，或者通过终端命令行触发。通过在编写代码的同时，频繁运行单元测试，有助于尽早发现代码中的问题。对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。
顺便说一句，在微服务架构中，单元测试的作用不仅限于代码开发，它们还对 DevOps/CI（持续集成）有很大的帮助，可以集成到代码合并（Merge）流程里。
譬如，GitHub 支持对一些主流 CI 服务的状态检查。一般它会限制对“Master”主分支的提交权限，不允许开发人员直接向该分支提交代码，而是要求他们把代码先提交到其他分支上（提交 Pull Request），再由其他开发人员进行代码审查（Code Review）。最后，在将代码合并到主分支的时候，GitHub 要求先通过状态检查。这时，Jenkins、CircleCI 和 TravisCI 等 CI 服务都提供了状态检查钩子（hook），它们会从分支上获取代码并运行单元测试。如果通过了，就允许合并代码，否则就不允许。整个过程如下图所示：
高覆盖率的单元测试是保障代码质量的第一道也是最重要的关口。从分工上来说，测试人员可能不会参与单元测试的开发与维护，但是测试人员应当协助开发人员确保单元测试的部署和覆盖率，这是确保后续一系列测试手段发挥作用的前提。
本课总结
简单总结一下本课程所学习的内容：
- 用模拟器来定义单元测试的边界，模拟对外界函数/服务的调用；
- 依照三 A 原则，实现单元测试；
- 使用流程化工具，实时监控单元测试的覆盖率。
下一课中，我们将重点介绍单元测试的下一个层级——集成测试。
第04课：怎么针对微服务架构做集成测试/strong>
第05课：组件测试详解
第06课：契约测试入门
第07课：端到端测试的优化策略
第08课：云端测试和性能测试实战
第09课：揭开测试流水线的奥秘
第10课：测试人员在微服务时代的角色演变
阅读全文: http://gitbook.cn/gitchat/column/5afd51741f74b159eb38f2da
文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树服务 格(istio)ServiceMesh介绍8587 人正在系统学习中 相关资源：漂浮截图工具-教育工具类资源
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！