微服务中的测试

新的挑战 微服务和传统的单块应用相比,在测试策略上,会有一些不太一样的地方。简单来说,在微服务架构中,测试的层次变得更多,而且对环境的搭建要求更高。比如对单块应用,在一个机器上就可以setup出所有的依赖,但是在微服务场景下,由于依赖的服务往往很多,要搭建一个完整的环境非常困难,这对团队的DevOps的能力也有比较高的要求。 相对于单块来说,微服务架构具有以下特点: 每个微服务在物理上分属不同进程 服务间往往通过RESTful来集成 多语言,多数据库,多运行时 网络的不可靠特性 不同的团队和交付周期 上述的这些微服务环境的特点,决定了在微服务场景中进行测试自然会面临的一些挑战: 服务间依赖关系复杂 需要为每个不同语言,不同数据库的服务搭建各自的环境 端到端测试时,环境准备复杂 网络的不可靠会导致测试套件的不稳定 团队之间的沟通成本 测试的分层 相比于常见的三层测试金字塔,在微服务场景下,这个层次可以被扩展为5层(如果将UI测试单独抽取出来,可以分为六层)。 单元测试 集成测试 组件测试 契约测试 端到端测试 和测试金字塔的基本原则相同: 越往上,越接近业务/最终用户;越往下,越接近开发 越往上,测试用例越少 越往上,测试成本越高(越耗时,失败时的信息越模糊,越难跟踪) 单元测试 单元测试,即每个微服务内部,对于领域对象,领域逻辑的测试。它的隔离性比较高,无需其他依赖,执行速度较快。 对于业务规则: 商用软件需要License才可以使用,License有时间限制 需要License的软件在到期之前,系统需要发出告警 @Test public void license_should_expire_after_the_evaluation_period() { LocalDate fixed = getDateFrom("2015-09-03"); License license = new License(fixed.toDate(), 1); boolean isExpiredOn = license.isExpiredOn(fixed.plusYears(1).plusDays(1).toDate()); assertTrue(isExpiredOn); } @Test public void license_should_not_expire_before_the_evaluation_period() { LocalDate fixed = getDateFrom("2015-09-05"); License license = new License(fixed....

October 1, 2016 · 2 min · 邱俊涛 | Juntao Qiu