在上面几节课中，我们陆续介绍了微服务架构的主要测试类型。现在，让我们再回顾一下它们的特点：
- 单元测试：对生产代码中最小的可测试片段进行检查，判断其是否符合预期。
- 集成测试：检查模块的组合能否发挥作用，以及模块和外部服务、资源、数据库的通信是否正常。
- 组件测试：以单个微服务作为对象，通过内部接口和外部模拟，将微服务与外界隔离开，测试其功能。
- 契约测试：在各个微服务之间的接口上，检查它们的交互是否符合预期标准。
- 端到端测试：从整个产品/系统的角度，进行端到端的检查，判断是否符合外部要求和达到其目标。
总而言之，从上到下，测试的粒度由细到粗。一种测试的粒度越粗，涉及的部分就越多，也就越脆弱（容易误报），执行和维护的成本就越高。接下来，我们就可以用 TeamCity 或者 Jenkins 这样的调度工具，建立起一个支持持续集成/持续交付（CI/CD）的自动测试流水线。本课将详细介绍这方面的常用方法和工具。
什么是 CI/CD
持续集成（Continuous Integration）是指，在开发人员提交了新代码之后，立刻进行构建（Build）、测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
Martin Fowler 说：“持续集成并不能消除 Bug，而是让它们非常容易发现和改正。”这样的软件开发实践，要求开发团队必须经常集成他们的工作，而不是等到一周、一个月甚至几个月之后才进行集成和测试。这符合现在最流行的测试理念：