浅谈集成测试中的一点思考.docVIP

PAGE PAGE 1 浅谈集成测试中的一点思考 　　【摘要】所有的软件项目都不能摆脱系统集成这个阶段。本文介绍了集成测试的总体情况，并详细说明了集成测试的目的、原则和相关注意事项。 　　【关键词】持续集成；集成测试 　　首先，持续集成和集成测试还是有很大区别，持续集成强调的是自动化的编译构建，部署，自动化的冒烟测试，保证开发过程的产出随时都可以构建一个冒烟测试通过的可用版本。而集成测试则涉及到严格的测试策略，测试方案，集成测试顺序，各个集成功能点的覆盖，详细的功能性测试等。集成测试不仅仅是接口测试，更重要的是以接口质量为前提的跨组件功能性测试。 　　1.为什么要集成测试 　　集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。 　　理论上凡是两个单元（如函数单元）的组合测试都可以叫做集成测试。实际操作中，通常集成测试的对象为模块级的集成和子系统间的集成，其中子系统集成测试称为组件测试。 　　在单元测试和系统测试间起到承上启下的作用，既能发现大量单元测试阶段不易发现的接口类错误，又可以保证在进入系统测试前及早发现错误，减少损失。 　　对系统而言，接口错误是最常见的错误，单元测试通常是单人执行，而集成测试通常是多人执行或第三方执行。集成测试通过模块间的交互作用和不同人的理解和交流，更容易发现实现上、理解上的不一致和差错。 　　2.集成测试什么时候开始 　　●在开始体系结构设计的时候开始； 　　●在进入详细设计之前完成集成测试方案； 　　●在进入系统测试之前结束集成测试。 　　3.集成测试原则 　　●集成测试是产品研发中的重要工作，需要为其分配足够的资源和时间。 　　●集成测试需要经过严密的计划，并严格按计划执行。 　　●应采取增量式的分步集成方式，逐步进行软件部件的集成和测试。 　　●应重视测试自动化技术的引入与应用，不断提高集成测试效率。 　　●应该注意测试用例的积累和管理，方便进行回归并进行测试用例补充。 　　4.集成测试需要关注以下问题： 　　4.1　集成测试的可迭代性 　　在整个软件开发都可迭代的模式下，要意识到集成测试过程本身也是可以迭代的。大型产品集成不应该等待到真正各个子系统或业务模块都开发好才开始集成测试。功能开发的迭代直接驱动集成测试过程也是迭代，同时在每个集成测试周期中最好又分为几个关键点，首先是服务模拟器，其次是替换掉模拟器联调通组件接口，再次测试接口服务中详细实现。 　　4.2　集成测试的顺序问题 　　我一直认为这是集成测试中非常关键的一个内容，集成顺序的确定涉及到前期大量的组件间依赖关系分析，业务功能点和接口对应关系分析等。特别是发展到现在，我们发现很多时候组件间不再是以前单纯的单向依赖关系，由于接口服务注册在总线上，导致多个组件间可以相互依赖，所以前面简单的组件依赖分析已经不适用，替代的方法是基于跨组件的流程协同分析，以核心流程驱动组件间的组装顺序。 　　同时，对于传统的自顶向下集成和自底向上集成方法往往都不能完全覆盖。很多时候采用的都会是混合集成的策略。一个是为了及早的看到集成的效果我们期望从顶向下，但是却需要大量的模拟器和stub桩模块。另外一个是为了减少模拟器，我们从最底层向上集成，但是往往却将风险延迟到最后发现。 　　4.3　测试全流程的问题 　　在每个组件或模块的单元测试阶段更加容易实现每日构建和持续集成，持续集成完后应该对每个独立模块进行详细测试，但是测试需要依赖一定的模拟器。在集成测试环境则进入到集成流水线，集成流水线的准入应该是每个组件在单元测试环境都完全测试通过，集成流水线根据组件的集成需求来规划具体的测试计划和测试方案。集成测试过程仍然应该首先是冒烟测试进行准入验证，然后是接口测试，然后是详细功能测试，最终交付到验收。 　　5.集成测试方法 　　5.1　非递增式集成测试 　　●所有软件模块完后单元测试后一次集成。 　　●优点：测试过程中基本不需要设计开发测试工具。 　　●不足：对于复杂系统，当出现问题时故障定位困难，和系统测试接近，难以体现和发挥集成测试的优势。 　　5.2　递增式集成测试 　　●逐渐集成，由小到大，边集成边测试，测完一部分，再连接一部分。 　　●在复杂系统中，划分的软件单元较多，通常是不会一次集成的。 　　●软件集成的精细度取决于集成策略。通常的做法是先模块间的集成，再部件间的集成。 　　●优点：测试层次清晰，出现问题能够快速定位。 　　●缺点：需要开发测试驱动和桩。 　　5.3　集成测试实现 　　●集成测试在实现方式上和单元测试是一样的，需要根据测试需