最近关注集成测试比较多，特别是大型项目中的产品和应用集成。一个产品一个小组做的时候往往集成问题藏在小组内容，但是当真正进行大型的组件化开发和多团队协同的时候，集成就显得很重要的。集成测试处于单元测试和验收测试之间，是真正将组件组装和集成为产品的关键。

　　持续集成和集成测试

　　持续集成和集成测试还是有很大区别，持续集成强调的是自动化的编译构建，部署，自动化的冒烟测试，保证开发过程的产出随时都可以构建一个冒烟测试通过的可用版本。而集成测试则涉及到严格的测试策略，测试方案，集成测试顺序，各个集成功能点的覆盖，详细的功能性测试等。集成测试不仅仅是接口测试，更重要的是以接口质量为前提的跨组件功能性测试。

　　集成测试的可迭代性

　　在整个软件开发都可迭代的模式下，要意识到集成测试过程本身也是可以迭代的。大型产品集成不应该等待到真正各个子系统或业务模块都开发好才开始集成测试。功能开发的迭代直接驱动集成测试过程也是迭代，同时在每个集成测试周期中最好又分为几个关键点，首先是服务模拟器，其次是替换掉模拟器联调通组件接口，再次测试接口服务中详细实现。

　　部署流水线和环境版本管理

　　集成测试过程承上启下，部署流水线强调的是必须是单元测试环境测试通过的版本才能够部署到集成测试环境，部署的过程不应该重新再进行编译和打包，而应该直接部署上一个环境验证通过的部署包。对于这个策略我完全赞同，只有这样才能给保证版本本身的严肃性，但是缺点是每次提交集成都需要在上一环境验证通过，加长了集成测试的整个周期。

　　集成测试的顺序问题

　　我一直认为这是集成测试中非常关键的一个内容，集成顺序的确定涉及到前期大量的组件间依赖关系分析，业务功能点和接口对应关系分析等。特别是发展到现在，我们发现很多时候组件间不再是以前单纯的单向依赖关系，由于接口服务注册在总线上，导致多个组件间可以相互依赖，所以前面简单的组件依赖分析已经不适用，替代的方法是基于跨组件的流程协同分析，以核心流程驱动组件间的组装顺序。

　　同时，对于传统的自顶向下集成和自底向上集成方法往往都不能完全覆盖。很多时候采用的都会是混合集成的策略。一个是为了及早的看到集成的效果我们期望从顶向下，但是却需要大量的模拟器和stub桩模块。另外一个是为了减少模拟器，我们从最底层向上集成，但是往往却将风险延迟到最后发现。

　　测试全流程的问题

　　在每个组件或模块的单元测试阶段更加容易实现每日构建和持续集成，持续集成完后应该对每个独立模块进行详细测试，但是测试需要依赖一定的模拟器。在集成测试环境则进入到集成流水线，集成流水线的准入应该是每个组件在单元测试环境都完全测试通过，集成流水线根据组件的集成需求来规划具体的测试计划和测试方案。集成测试过程仍然应该首先是冒烟测试进行准入验证，然后是接口测试，然后是详细功能测试，最终交付到验收。

　　测试全流程的问题

　　回归和逆向流程是全流程管理里面另外一个关键问题，特别是在由于某个组件的原因导致集成失败的情况下，需要考虑某一个组件的重新构建和提交，配置管理需要和部署流水线结合，同时部署版本需要到具体的组件，建立某一次集成中各个组件版本间的追踪。