weixin_41918841的博客

微服务的由来微服务的前身是 Peter Rodgers 博士在 2005 年度云端运算博览会上提出的微 Web 服务 (Micro-Web-Service) 。微软的 Juval Löwy 随后也提出了类似的想法，并提议将其作为微软下一阶段最主要的软件架构。2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，给出了微服务的具体定义：从本质上来说，微服...

在上面几节课中，我们陆续介绍了微服务架构的主要测试类型。现在，让我们再回顾一下它们的特点：单元测试：对生产代码中最小的可测试片段进行检查，判断其是否符合预期。 集成测试：检查模块的组合能否发挥作用，以及模块和外部服务、资源、数据库的通信是否正常。 组件测试：以单个微服务作为对象，通过内部接口和外部模拟，将微服务与外界隔离开，测试其功能。 契约测试：在各个微服务之间的接口上，检查它们的交互...

到上一课为止，我们已经介绍了微服务自动化测试的主要组成部分：单元测试、集成测试、组件测试（单服务测试）和端到端测试。它们足以确保对本地部署、运行的应用程序有足够的测试覆盖率。但是，随着越来越多的应用程序开始采用云端部署的方式，包括微软 Azure、谷歌云、亚马逊 AWS 或者国内的阿里云、腾讯云等， 怎样确保在本地正常工作的生产代码（Production Code）在部署到云端以后，还能继续提供符...

上篇中的契约测试解决了我们对微服务之间协作、交互的验证需求。本达人课到目前为止介绍的测试都是后端或者 API 级别的测试，可以说都属于“白盒测试”。自动化测试的最后一步，就是所谓的端到端测试（End-to-End Test），又称黑盒测试，即从用户角度验证整个系统的功能，看其从启动到结束是否全部符合用户预期。黑盒测试：又被称为功能测试、数据驱动测试或基于规格说明的测试，是通过使用整个软件或某...

在前面几篇文章中，我们学习了怎么对一个微服务，实施从单元到整体的全部测试。下一步，我们就需要考虑怎么测试不同微服务之间的协同、交互。如果采用传统的总体测试方法，对服务之间的协作进行验证，那么随着服务数量和调用关系复杂度的增加，必须面临成本呈现指数级增长的挑战，这表现在： 验证成本高：为了验证多个服务协作后的功能正确与否，需要为每个服务搭建基础设施（包括其依赖的数据库、缓存等），并执行部署、配...

本课程中所说的组件（Component），是指一个大型系统中，某一个可以独立工作的、封装完整的组成部分。在微服务架构中，组件实际上就代表着微服务本身，或者说单个微服务。以下将其称为“单服务测试”（Single-service Test）。这个测试的实质，就是将一个微服务与其所依赖的所有其他服务或资源全部隔离开，从该服务外部“用户”的角度来审视服务能否提供预期的输出。这样做有很多好处：通过把...

在上一节中，我们讲解了怎么进行单元测试。虽然单独测试微服务内部的各个单元非常重要，但是，测试微服务的模块或者子系统能否正确地与外界交互也同样重要，这项工作可以通过集成测试来完成。这节课，我们将分别探讨在微服务架构下，集成测试的概念和实现方法，并分别以几个实例来说明。集成测试（Integration Test）的定义有很多。简单来说，集成测试（也叫组装测试、联合测试）是单元测试的逻辑扩展，即把两...

单元测试是开发人员编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序 list 中去，然后确认该值出现在 list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。对于单元测试中单元的含义，一般来说，要根据实际情况...

在上一节里，我们学习了微服务的来源和主要特点。对于软件测试人员而言，微服务架构对软件测试带来了哪些新的挑战呢？我们应该用什么样的策略和方法来迎接这些挑战？总体的测试策略软件测试的目的是确保软件产品的质量符合预期。衡量测试质量的指标有很多，最常见的是测试覆盖率和测试成本（包括测试所用时间、测试维护成本），而衡量测试效果的主要手段则是最终产品在实际使用中暴露出来的问题数量（Bug Number...

本达人课到目前为止，谈得都是如何实施自动化的测试。但是，无论整个流程多自动化，都需要“人”这个角色来加以设计、开发、管理和维护。这离不开测试人员的全力投入。长期以来，测试人员在开发企业中常常面临着定位不清晰、职业发展路径未明，乃至被管理层认为可有可无的窘境。这一方面，固然与企业对于质量的重视不足有关，需要企业管理层、开发团队负责人员加以改进，另一方面，也的确需要测试人员从自身角度分析原因：怎么样不...