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