淘宝网 持续集成的 尝试

全网回归

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

要解决的问题

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以外；

办法：增加调度优先级，例如：运行快的脚本被优先执行，重要的用例优先执行等；

• 机器节点动态伸缩

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

l

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.previousMethod.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的回归时间：

l

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请求"}, ...]}

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