谈产品集成

发表于:2012-05-23来源:新浪博客作者:人月神话点击数: 标签:集成测试
对于大型产品开发,一次可能开发多个新的业务系统,同时一个业务系统本身又包含多个业务模块和组件。只要我们在前期产品规划中存在子系统和模块的分解,那么后续就一定存在产品集成的动作。在架构设计中我们通过进行组件分解,识别和定义组件间接口,一方面是

  对于大型产品开发,一次可能开发多个新的业务系统,同时一个业务系统本身又包含多个业务模块和组件。只要我们在前期产品规划中存在子系统和模块的分解,那么后续就一定存在产品集成的动作。在架构设计中我们通过进行组件分解,识别和定义组件间接口,一方面是通过分而治之降低大系统复杂度,另外一方面则是通过分解和接口定义后各模块可以并行开发。只要架构阶段存在分解动作,那么最终在各模块开发完成后一定存在集成动作。架构做出一个假设,只要在分解的时候各组件模块按预定的接口契约进行实现,那么后续各个组件一定可以进行集成和组装形成一个完整的产品。所以架构不能仅仅只关心解耦,还必须关心集成和装配,解耦后的东西无法集成,那么分解过程仍然是失败的。

  产品集成和持续集成的关系

  产品集成强调是的是把左右的组件最终能够组装和集成起来,形成一个完整的系统。而大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成它们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件。可见持续集成只能算做产品集成的一个子实践。

  要明白持续集成只是产品集成的一种方式,不论是开发过程是瀑布模式,增量模式还是迭代模式,都可以采用持续集成的思路。要明白持续集成的一个核心是将整个开发过程透明化,同时将集成工作提前化。尽可能早的暴露问题和风险,同时纠正在前期系统分析和架构设计中的不足。

  对于持续集成我们往往会强调每日构建,冒烟测试,自动化测试等内容。强调开发,测试和生产环境的部署流水线作业。但是要明白对于大型产品集成仍然回包括模块内测试和集成,模块间测试和集成,跨系统间的测试和集成工作。对于单个模块内可以采用每日构建和持续集成策略,但是对于模块间和跨系统我们可以采取分迭代式的集成方式进行集成。

  关于持续集成的核心逻辑

  在这里要分两个层面来谈,首先是单环境,涉及到自动化构建,部署,测试一系列动作。具体过程可以简化描述如下。首先是编写好自动化编译脚本代码,如使用ant工具完成;然后设置定时作业和任务,开发人员按时check in相关代码。使用CI持续集成工具根据定时任务点在构建环境自动获取最新代码,自动运行ant自动化编译脚本对代码进行编译,编译完成后自动化部署到某个环境。部署完成后运行单元测试自动化脚本对代码进行自动化测试,输出自动化测试结果和报告;如果通过的话测试人员通过QTP进行进一步自动化测试或手工执行一遍冒烟测试脚本,完成本次持续集成。在持续集成模式下,一方面是可以尽可能早的发现问题,一方面对测试人员随时都可以有一个可进行详细功能性测试的可用环境。

  其次如果对于多环境,涉及到开发环境测试通过后自动部署集成测试环境,集成测试环境测试通过后自动部署到验收环境等一系列动作。对此我们叫部署流水线模式,实现跨环境的持续集成管理。

  对于持续集成,由于组件间可能存在编译依赖,我们需要分析组件间的依赖关系,以顺利的完成整改编译过程。而在产品集成过程中我们考虑的不是编译依赖而是本身组件间的功能依赖,因此我们需要进一步详细的考虑组件间的集成顺序和集成策略问题。

  产品集成顺序的分析

  产品集成顺序分为两种模式,一种是自顶向下的模式进行集成,一种是自底向上的方式进行集成。对于自顶向下方式的集成,首先集成最外层或流程最末端的业务模块,业务模块前置依赖用模拟器(桩)实现。然后继续在每一层按宽度或深度优先,用完全实现模块代替模拟器,并建立下层。以这种方式继续直到所有被测系统中的桩已经实现和测试。在这种模式下可以看到整个集成过程完全是顶层需求驱动进行,集成工作可以较早的开始进行,如果产品集成图是正金字塔结构较容易,模拟器开发较少;反之同理。

  对于自底向上集成,首先集成最底层的业务模块,只在底层模块未实现前使用模拟器(桩)。然后继续在实现并测试对上一级模块,这些构件使用已经测试的下级模块。整个系统使用根一级模块测试。对于这种模式模拟器开发较少,同时上次各模块基本可以开始并行测试。这种集成方式最大的风险是如果上次需求变化可能直接影响到最底层。

  产品集成的集成场景分析

  集成场景分析目的是为后续的集成测试用例设计提供依据,集成测试用例要覆盖所有场景。对于场景分析输入主要包括跨模块协同业务流程图,系统需求规格说明书,概要设计说明书等。对于集成场景分析可以从静态和动态两个层面进行分析,对于静态分析主要分析模块依赖关系,分析某一个服务接口影响到的业务模块具体功能点,可以模块-》模块的矩阵分析方法进行。对于动态分析主要是根据跨系统或模块流程入手,分析跨模块的流程协同,流程协同中所涉及到的所有接口服务。

  集成场景的分析将为集成测试用例的设计提供核心输入,要明白,集成测试不是简单的接口测试,接口反映的是跨系统或模块的交互流程,需要通过交互流程的贯通来检验接口本身的正确性。

原文转自:http://www.ltesting.net