集成测试的几个思考点

标签: 随笔文章 | 发表时间:2012-06-11 15:36 | 作者:人月神话
分享到:
出处:http://blog.sina.com.cn/cmmi
最近关注集成测试比较多,特别是大型项目中的产品和应用集成。一个产品一个小组做的时候往往集成问题藏在小组内容,但是当真正进行大型的组件化开发和多团队协同的时候,集成就显得很重要的。集成测试处于单元测试和验收测试之间,是真正将组件组装和集成为产品的关键。

持续集成和集成测试

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

集成测试的可迭代性

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

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

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

集成测试的顺序问题

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

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

测试全流程的问题

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

测试全流程的问题

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

   女人的情色电影笔记本   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [集成测试 思考] 推荐:

集成测试的几个思考点

- - 人月神话的BLOG
最近关注集成测试比较多,特别是大型项目中的产品和应用集成. 一个产品一个小组做的时候往往集成问题藏在小组内容,但是当真正进行大型的组件化开发和多团队协同的时候,集成就显得很重要的. 集成测试处于单元测试和验收测试之间,是真正将组件组装和集成为产品的关键. 持续集成和集成测试还是有很大区别,持续集成强调的是自动化的编译构建,部署,自动化的冒烟测试,保证开发过程的产出随时都可以构建一个冒烟测试通过的可用版本.

Android集成测试

- - 百度质量部 | 软件测试 | 测试技术 | 百度测试
  Android集成测试主要是在单元测试的基础上测试接口访问或者异步任务是否正确,在. 移动凤巢系统中,大概有30+个接口需要测试,他们都遵循一个特定的访问模式:前台的. Activity获取到触发事件后,将它传给这些接口,这些接口都是AsyncTask的实现——即后台. 异步线程执行某个任务(一般是发送http请求到后端服务或者执行存取数据库等耗时操作),.

集成测试-意义和方法

- - 人月神话的BLOG
集成测试是将模块按照设计要求组装起来同时进行测试,主要目标是发现与接口有关的问题. 如数据穿过接口时可能丢失;一个模块与另一个模块可能有由于疏忽的问题而造成有害影响;把子功能组合起来可能不产生预期的主功能;个别看起来是可以接受的误差可能积累到不能接受的程度;全程数据结构可能有错误等. 集成测试是单元测试的逻辑扩展.

maven 自动化web应用集成测试

- - BlogJava-首页技术区
        web应用集成测试的时候,各位还需要启动web容器,然后打开浏览器,输入ulr,然后看到浏览器的输出吗. 下面我们用maven做到自动化. 我们利用maven的生命周期和jetty插件来实现. 下面描述下做的自动化web集成测试实现的原理. 1,在生命周期pre-integration-test启动jetty容器.

为什么集成测试比单元测试更重要

- - CSDN博客研发管理推荐文章
在假定一些数据的环境下,能顺利通过测试的系统就可算是一个好系统. 不过,现在可以直连外部资源的集成测试才让程序更有价值. 谁知道那些内容商(供应商,vendor)会做出什么傻事来. 很多人一直尝试着让测试达到100%的代码覆盖率,这是很棒的想法,但我倒觉得它有些基本概念上的问题. LosTechies,  Ryan Svihla 提出了"反模式(anti-pattern", 有个有趣的观点: “多数应用都需要与外部资源交互”.

终极思考

- wei - 牛博国际
我的海淀剧院演讲门票放出后,八小时卖了四百多张,同事们说,日. 我淡淡地说,别这样,也许正是因为便宜才这么好卖嘛. 一转身我马上就打电话给老婆,操. 早知道就他妈把票价定高一点啦,真倒霉......干. 很大程度上,这可以解释两件事:1.为什么已婚事业男性的健康状况会相对好一些. 2.为什么在社会上受到尊重和认可的事业男性在老婆的眼里都是傻逼.

动车追尾的思考

- David Ruan - 扬韬
1、两列运行的动车追尾,绝对属于重特大责任事故. 雷电导致前车失灵,已经是责任事故了. 前车失灵,信号没有外发,又是责任事故. 调度体系没有发觉列车失灵,也是责任事故. 后车没有察知前车失灵,还是责任事故. 最后,后车发现问题,紧急制动系统有没有用也值得怀疑,因为后车司机据说是人工制动并殉职于岗位的.

《系统思考》读后感

- 章明 - 所有文章 - UCD大社区
经别人推荐(都忘了是谁推荐的了~),买了这本《系统思考》,看完前几章,发现这是一本非常好的书. 全书的精华也都在前面几章,后面都是一些具体的案例分析. 为什么必须从整体研究系统. 将系统分块通畅破坏了你所试图研究的系统. 如果你破坏了系统内的连接,你就破坏了系统本身. 更奇妙的是,很多系统表现出他们的任何组成部分都不具备的特征.

重新思考电子书

- Alex - 爱范儿 · Beats of Bits
Hart,“古登堡计划”发起人,2011 年 9 月 6 日去世,享年 64 岁. 从 1971 年 Hart 制作第一本电子书,启动“古登堡计划”开始到 2011 年,Kindle、Nook 流行,正好经过 40 年. 如今电子书阅读器、电子书变得越来越流行,在北京的地铁上,你会经常看见低头拿着 Kindle、Nook、iPad、汉王的人们.

Google Reade关闭的思考

- - 猫星石 ~CafeNeko
关于google reader所引起的口诛笔伐已经看的足够多了,所以这里我并不想再去谈Google的这个决定正确与否. 我想说的是关于”后GR时代”的一些思考. 关于GR的好我已经听的太多,曾几何时我也是重度的GR脑残粉. 但是早在GR宣布准备关闭时,我一边看着GR里面永远也不会清空的条目,我就在想,我真的还是GR的脑残粉吗.