要资料 文章 文库 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   成长之路  
会员   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
分享到
淘宝网 持续集成的 尝试
 

作者: mozhenghua,发布于2012-7-3

 

网回归

全网回归 是淘宝网主站 持续集成的 组成部分,

要解决的问题

1. 应用多,

2. 有依赖,各应用之间有依赖,开发应用者不完全清楚。

3. 同一个测试环境,解决问题容易,排查问题难。

目标

1. 对业务线的回归; on time

2. 公司级别的回归, 安全,运维团队 升级 打补丁之后, 可以直接选择需要回归的业务线以及 用例优先级; on demand

3. API 的精确回归, 当某一API 发生 变化时, 能够精确的定位被影响的全网 其他API ,并且进行回归,给出结果,通知相应的人; on event (we are here)

目前情况

2011年

1. 平均每天2.1个bug;共发现208个bug;帮助降低线上BUG遗漏率 45.31%(208/459);

2. 脚本平均运行时间: WebUI:1.38分钟API:1.2秒

3. 脚本数量:19263个(WebUI-1613,API-17650) ----------> 54120个(WebUI-6492,API-47628)

4. 脚本成功率: WebUI平均95%(最高97%,最低92%);API平均97%(最高98%,最低95%)

5. 投入成本: 平均每条线维护脚本0.955个,耗时10分钟(6条线); 平均每人维护脚本0.035个,耗时3.75秒(200人计)

6. 成本降低: 平均每天在跑用例 50k,每个用例人工执行 算5min; 则需要 520个工作日的时间(每天8小时不间断工作),相当于 520个人 一天8小时 不间断的工作量

关键技术

1. 机器管理

目的

确保测试机器高可用度

降低测试机器搭建的成本

分析

现状:从春节后的2月份开始,automan(淘宝自动化框架)升级了5次,但每一次升级都不完整,总会有一些机器升级不成功。回归机器已达到了70+台,排查起来费时费力;

Agent也有同样的问题,但相比而言要少些;目前,全面升级一次的时间挺长,约2小时;

办法:测试平台提供统一的客户端软件批量升级的办法,升级后能验证是否成功,并反馈到kelude(淘宝测试系统)上的机器管理系统中,负责人可以立即看到所有机器的升级情况,进而快速发现问题、解决问题;

另外,机器管理还需要收集各回归机器的关键软件信息,如:版本、配置等,方便负责人快速发现环境差异;

对回归机器的全面验证,例如:benchmark

现状:在kelude(淘宝测试系统)系统中登记的机器共有100+,但这里面的机器有些不能访问,或者性能低下;例如,2012-03-14对全网回归的99台机器进行验证,结果发现:有39台没有执行脚本,有40台机器正常执行(<20S),有15台机器执行时间超过20S;
办法:建立一套验证脚本和验证机制:每天定时 或 按需(例如加机器,或升级)运行这一套脚本,对所有的回归机器进行全面的自动验证,从中确定有问题的,运行缓慢的机器,或优化,或淘汰等;

验证脚本可以根据需要 添加进来,例如:对性能的验证,对浏览器访问的验证,对automan(淘宝自动化框架)版本的验证等;
机器标准化

机器标准化:账号、软件、配置等,并提供标准化的虚拟机镜像,方便快速创建新的回归机器;后期会尝试 KVM 的接入

技术

机器唯一性标识

每个KeludeAgent接入到Kelude系统时,会由系统分配一个独一无二的UUID,用来在Kelude系统内标识该KeludeAgent。

机器信息&软件配置获取

(windows)KeludeAgent定期读取(1h)注册表获取机器信息,浏览器信息,通过 HTTP API 推送到kelude平台

(linux) 暂未支持

软件升级

KeludeAgent开放 Deploy RPC service 接口,Kelude Web 将升级的命令通过 RPC调用传递给KeludeAgent执行。

(windows)KeludeAgent 执行 Kelude Web 传递的命令进行升级。由于在某些时候可能需要升级KeludeAgent本身,因此KeludeAgent在执行升级命令时,会将升级过程单独启动一个独立的进程来执行。即使KeludeAgent被关闭,也不会影响升级过程。

可用性检测

任意程序可以通过访问KeludeAgent暴露的 RPC 接口来确定其是否可用.

可用性检测告警

在机器信息收集的基础上,定义了一些触发条件。当机器的信息满足这些条件时,Kelude系统就发出旺旺消息通知对应的机器管理人员。

目前定义的规则主要包括

机器可用状态变化

机器 C 盘空间降低到500M以下(windows)

2. 任务调度

按机器池并行调度

现状:2月份,各回归机器的利用率差别很大,从30%-90%不等,回归机器没有被充分利用起来,导致部分产品回归时间长;

办法:首先按产品线建立机器池,各产品线回归 从机器池中获取可用机器,以10个-30个TC为一组 进行并行调度;

期望的效果是,均衡机器的利用率,缩短整体回归时间;

按任务优先级调度

现状:WebUI回归2小时完成率大约在74%,通过分析发现,70%运行超时的脚本(约300个)都被安排在了02:00之内运行,这就导致了运行快的脚本被排挤到了2H以外;

办法:增加调度优先级,例如:运行快的脚本被优先执行,重要的用例优先执行等;

机器节点动态伸缩

探测回归机器是否可用,并能够动态的增加或减少回归机器。不会因为其中的少量机器不可用,而引起回归超时、或失败的问题;

3. 如何确立全网的API依赖关系(系统内,系统外)

Depend系统的API接口采用基于REST风格的接口规范。所有的调用请求都需要走http的方式调用统一的URL(暂定http://XXXXX:8080/depend/rest.do )来实现。

Depend实现原理关键技术点:在被测试应用所有类中插入jvm指令,以取回方法调用链、当前请求URL、tair服务的名字空间等信息,存入数据库即完成了依赖关系的收集,具体技术要点如下:

在depend的数据类中定义全局静态数据载体属性,这是一个ThreadLocal对象,能进行线程安全的数据存储操作。

在被测试应用所有方法入口处插入以下代码,可以取得整个调用链中所有类与方法名,并将此信息存入全局数据载体中。

StackTraceElement[] stackTrace = new Throwable().getStackTrace();

stackTrace[1].getClassName());

stackTrace[1].getMethodName();

根据各种类型应用预先设置好入口类,入口类中插入特定代码以取回URL、特定参数值(如tair的名字空间),下面以webx应用为例说明:

Webx应用的入口类名为com.xxx.xxxx.xxxx.WebxFrameworkFilter,入口方法为doFilter(request,response,chain),要在此方法的第一行插入如下指令以从request对象中取回URL,并将此URL和上述信息存放在一起,最终传回服务器进行分析处理。

aload_1

invokestatic com.taobao.depend.InfoPicker.getUrl(javax.servlet.http.HttpServletRequest)

取tair的名称空间以及其他的值,都是需要依赖特定的API的。

在服务器端,将所有的URL、方法调用链信息去重后存入数据库,即完成依赖关系收集。

从SVN取回某个变更了的方法名,取回所有受到影响的方法列表

实现方法:使用HttpClient开源组件发送请求到URL: http://XXXX:8080/depend/rest.do,同时带上如下参数:

名称 类型 必选 描述 示例值
api String method.previous Method.get
v String API版本号,请设置成0.1 0.1
app_name String 应用名称 xxxx
class_name String 类名称 com.xxx.xxx.xxxxx. xxxxxx
method_name String 方法名称 xxx
ivk_type Integer 调用方式。0为全部,1为本地调用,2为远程调用。 0
valid_day Integer 有效日志天数。查询时只使用有效天数之内的日志。默认值为30天 7
format String 返回的数据格式,前期支持json json

请求的返回值为json格式:

{

“app_name”: “xxxx”,

“class_name”: “com.taobao.xxx.xxx.xxx”,

“method_name”: “xxxx”,

“methods”:

[{

“app_name”:”xxxx”,

“class_name”: “com.taobao.xxx.xxx.xxx”,

“method_name”: “xxxxx”,

“ivk_count”: 105

},{

“app_name”:”xxxx”,

“class_name”: “com.taobao.xxxxx”,

“method_name”: “xxx”,

“ivk_count”: 13048

}]

}

其中[ ]中的内容即为受影响的方法列表(包含类名)。

其他API的调用方法相同,参数请参照原文档。

对于测试类里面的方法,可以通过解析获取到一个测试类里面的方法所直接调用的方法列表。

4. 用例来源与组织

来源: Web UI; API; Android; IOS;

组织:

业务线回归(on time): P0,P1,P2,P3;

公司级回归(on demand): P0, P1;

精准回归(on event): P0,P1,P2,P3;

通过用例的逻辑操作,可自由加入回归实验室;

5. 时间分析

WebUI脚本Profiler

现状:WebUI脚本执行时间长,7000个TC,在70台机器执行需要3小时;而测试人员并不能分析出其中的性能瓶颈:automan框架引起的、脚本编写、或者是被测系统响应慢;

办法:提供WebUI脚本的运行各环节的时间消耗,以及脚本中各个step的时间消耗,推送到kelude平台汇总分析;
WebUI脚本的执行给出硬性规定,5分钟算超时,10分钟回归系统强行结束;

从近2周的数据,我们已经准确的分析出了automan平台的瓶颈,以及 淘宝被测系统的瓶颈,运行最慢的脚本等;

例如:3.6分析了最近7天,平均访问超过 5S 的10次的URL 共有50+个;

价值:直接给测试员提供性能瓶颈;分析出淘宝的性能瓶颈URL;

2012.3.14的回归时间:

6. 环境部署

Daily下应用的部署

现状:目前主站应用数大致为 800多个,应用的daily环境为 1120多个(虚机)。

基本的部署过程: build.sh先更新代码和配置项打包后进入以下过程

部署方式

目前部署已经实现web化操作 daily环境的建立和维护人为scm,开发、测试、scm都可以有权限来进行部署

在scm.taobao.net平台中申请环境部署权限,可以通过页面实现以下部署

今年daily环境将要进行的工作:

1.daily主要应用梳理,备机方式

解决问题:应用部署时,对测试的影响

应用出现问题,可以切换到备机

2.二套标准环境推广

项目、沙箱或者开发环境可以绑定二套标准环境,提升环境的稳定性

7. 测试环境(daily 环境)稳定

Daily下应用部署的监控

现状:对于daily下应用的部署情况只有片面、粗略的了解,没有办法基于数据做一些分析

办法:收集daily下所有应用的部署事件:svn, ip, app等,后续可挖掘出跟环境相关的很多信息:例如部署次数最多的应用;

应用部署测试

现状:daily环境下,部署应用后,并没用立即验证,这经常引起依赖的业务方访问出问题;

办法:由部署事件驱动,应用部署后立即自动验证,比如:hsf接口验证,http接口;这类用例要能够从系统级别来验证,而且要快,20分钟左右;

网络稳定和响应提速

现状:daily环境应用响应速度慢,主要有三方面原因:1、js/css没有压缩,部分合并、部分没合并;2、图片直接从TFS文件系统读取,没有做缓存;3、automan部分机器配置差,部分网段网络不稳定(6网段和24网段)。

解决办法:

针对第1点,在daily环境中推动js/css压缩、合并、设置过期时间,减少应用端对js/css的请求量。

针对第2点,在daily环境中架设一层TFS缓存,提升图片的响应速度。

针对第3点,更换配置高的机器,尽量选择kvm虚拟技术+win2003server操作系统;并调整不稳定的网段,将automan执行机放置到独立的网段,避免其它测试(如性能测试)对执行机产生影响。

应用性能提升

现状:每天大约有100个URL在全网回归执行过程中,时长超过5S,疑似被测应用本身性能较低。

办法:利用kelude的log分析出慢URL,kelude调用pap组件的接口将URL推送给pap,pap自动执行专项性能测试,暴露出性能瓶颈。

实现方法:pap以post方式提供http接口,kelude分析好数据后以json方式post给这个URL。 json串格式

urlinfo={"hostbinds":"hosts文件中需要添加的绑定信息,换行为\r\n",

"username":"登录使用的用户名",

"password":"登录使用的密码",

urls: [{"url":"访问的url","owner":"url对应的负责人","method":"automan对应的action,共有4个,start,goto,cast为http get请求,click为http post请求"}, ...]}

在一个上百人测试部门,上千人以上规模的研发团队, 做好一件事情,技术是一方面,另外一个重要方面是所有人一起为了一个目标去努力,背后是每一位工程师的心血和汗水, 是每一位工程师的努力打造了淘宝网今天的持续集成一角


相关文章

每日构建解决方案
如何制定有效的配置管理流程
配置管理主要活动及实现方法
构建管理入门
相关文档

配置管理流程
配置管理白皮书
CM09_C配置管理标准
使用SVN进行版本控制
相关课程

配置管理实践
配置管理方法、工具与应用
多层次集成配置管理
产品发布管理

 
分享到
 
 
     


集成与构建指南
项目管理:Maven让事情变得简单
持续集成工具hudson
持续集成
Maven权威指南
程序集(UML中的包)之间循环
更多...   


产品发布管理
配置管理方法、实践、工具
多层次集成配置管理
使用CC与CQ进行项目实践
CVS与配置管理
Subversion管理员

相关咨询服务
SCM启动咨询
SCM流程规范咨询
SCM评估性咨询


海航股份 重构及持续集成
电研华源 设计原理、建模与重构
软件配置管理日构建及持续集成
单元测试、重构及持续集成
中国软件研发中心 单元测试与重构
单元测试、重构和持续集成实践
罗克韦尔 C++单元测试+重构+Gtest
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号