那些年向前冲|微服务下产品集成和集成测试框架流程( 五 ) 作者：人月神话

集成测试清单和测试结果；
集成测试覆盖率分析：接口覆盖率，功能覆盖率；
测试结果统计分析：Bug分析，集成次数和成功率，遗留Bug分析；
测试结果评估；
测试结论和后续改进建议。

集成测试的其它关键点说明通过DevOps实施来实现整个持续集成过程的自动化

持续集成和集成测试还是有很大区别，持续集成强调的是自动化的编译构建，部署，自动化的冒烟测试，保证开发过程的产出随时都可以构建一个冒烟测试通过的可用版本。而集成测试则涉及到严格的测试策略，测试方案，集成测试顺序，各个集成功能点的覆盖，详细的功能性测试等。集成测试不仅仅是接口测试，更重要的是以接口质量为前提的跨组件功能性测试。
而对于DevOps最佳实践本身就包括了持续集成的过程。
持续集成不仅仅是实现了自动化的编译，打包和部署，自动化的单元测试。更加重要的是实现了环境之间的自动化迁移。
这个能力在我们整个产品集成中相当重要。
可视化的版本部署看板实现可追溯

在产品集成整体策略下，一个核心就是对于后续类似验收测试，生产环境等都是做环境迁移，而部署重新进行版本构建。只有这样才能够保证最终测试人员测试版本的一致性。
同时根据部署流水线方式，需要建立版本部署情况追溯表。比如上图，我们可以很清楚的看到当前在每一个环境各个微服务模块处于什么版本。
集成测试执行顺序
集成测试是整个测试里面的一个完整阶段，不仅仅是包括接口集成测试，而应该是包括了功能冒烟测试，接口测试，功能性测试，非功能性测试等完整内容，具体如下：

我一直认为这是集成测试中非常关键的一个内容，集成顺序的确定涉及到前期大量的组件间依赖关系分析，业务功能点和接口对应关系分析等。特别是发展到现在，我们发现很多时候组件间不再是以前单纯的单向依赖关系，由于接口服务注册在总线上，导致多个组件间可以相互依赖，所以前面简单的组件依赖分析已经不适用，替代的方法是基于跨组件的流程协同分析，以核心流程驱动组件间的组装顺序。同时，对于传统的自顶向下集成和自底向上集成方法往往都不能完全覆盖。很多时候采用的都会是混合集成的策略。一个是为了及早的看到集成的效果我们期望从上向下，但是却需要大量的模拟器和stub桩模块。另外一个是为了减少模拟器，我们从最底层向上集成，但是往往却将风险延迟到最后发现。
欢迎关注@人月聊IT 分享SOA ，微服务， DevOps平台规划和建设。