集成测试用例_微服务下产品集成和集成测试框架流程

作者：人月神话，新浪博客同名

简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践

今天谈下微服务架构下的应用集成和集成测试方面的内容。在微服务架构下，由于传统的的单体应用以及拆分为多个微服务，那么原来单个系统内部的API接口调用以及变成了微服务间的外部接口调用，而且还可能已经由不同的开发团队在开发不同的微服务模块。

在这种情况下如果不能很好的进行产品应用集成和后续集成测试，那么会经常出现类似单元测试问题遗留到集成测试，端到端流程无法测试通过，测试用例和数据反复制作，集成过程中出现问题故障排查困难等诸多问题。

也正是这个原因，今天准备讲下产品集成和集成测试方面的内容，可以看到微服务下的产品集成和集成测试实际和传统组件化开发下的组件集成思路基本是一致的。当然在CMMI三级的时候我们有一个PI的过程域，该过程域也给出了产品集成的核心指导思路。

产品集成概述

大型软件产品开发一次可能开发多个新的业务系统，同时一个业务系统本身又包含多个业务模块和组件。只要在前期产品规划中存在子系统和模块的分解，那么后续就一定存在产品集成的动作。

在微服务架构设计下可以看到，我们通过传统单体应用的大拆小，形成了多个松耦合的微服务组件模块。一方面是通过分而治之降低大系统复杂度；另外一方面则是通过分解和接口定义后各模块可以并行开发。

只要架构阶段存在微服务模块拆分动作，那么最终在各模块开发完成后一定存在集成动作。

架构做出一个假设，只要在分解的时候各组件模块按预定的接口契约进行实现，那么后续各个组件一定可以进行集成和组装形成一个完整的产品。所以架构不能仅仅只关心解耦，还必须关心集成和装配。解耦后的东西无法集成，那么分解过程仍然是失败的。

在新的平台+应用，微服务+容器云平台下应用集成可以看到比常规的产品集成更加复杂，对于一个业务应用或组件首先是要考虑和平台层类似消息，缓存等技术服务能力的集成，其次才是考虑组件之间的进一步横向集成。

在这种场景下本身对应用集成的方案，策略和执行等都提出了更高的要求。

应用集成的内容

对于应用集成的内容主要分为三个方面的内容。

其一：单个微服务模块和平台层能力的持续集成和发布

对于单个微服务模块的持续集成，首先是编写好自动化编译脚本代码，如使用ant工具完成，然后设置定时作业和任务，开发人员按时check in相关代码。使用CI持续集成工具根据定时任务点在构建环境自动获取最新代码，自动运行ant自动化编译脚本对代码进行编译，编译完成后自动化部署到某个环境。部署完成后运行单元测试自动化脚本对代码进行自动化测