全网回归
全网回归 是淘宝网主站 持续集成的 组成部分,
要解决的问题
1. 应用多,
目标
目前情况
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. 机器管理
- 目的
确保测试机器高可用度
- 分析
- 技术
机器唯一性标识
机器信息&软件配置获取
(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%不等,回归机器没有被充分利用起来,导致部分产品回归时间长;
- 按任务优先级调度
现状:WebUI回归2小时完成率大约在74%,通过分析发现,70%运行超时的脚本(约300个)都被安排在了02:00之内运行,这就导致了运行快的脚本被排挤到了2H以外;
- 机器节点动态伸缩
探测回归机器是否可用,并能够动态的增加或减少回归机器。不会因为其中的少量机器不可用,而引起回归超时、或失败的问题;
Depend系统的API接口采用基于REST风格的接口规范。所有的调用请求都需要走http的方式调用统一的URL(暂定http://XXXXX:8080/depend/rest.do )来实现。
Depend实现原理关键技术点:在被测试应用所有类中插入jvm指令,以取回方法调用链、当前请求URL、tair服务的名字空间等信息,存入数据库即完成了依赖关系的收集,具体技术要点如下:
- 在depend的数据类中定义全局静态数据载体属性,这是一个ThreadLocal对象,能进行线程安全的数据存储操作。
- 在被测试应用所有方法入口处插入以下代码,可以取得整个调用链中所有类与方法名,并将此信息存入全局数据载体中。
StackTraceElement[] stackTrace = new Throwable().getStackTrace();
- 根据各种类型应用预先设置好入口类,入口类中插入特定代码以取回URL、特定参数值(如tair的名字空间),下面以webx应用为例说明:
Webx应用的入口类名为com.xxx.xxxx.xxxx.WebxFrameworkFilter,入口方法为doFilter(request,response,chain),要在此方法的第一行插入如下指令以从request对象中取回URL,并将此URL和上述信息存放在一起,最终传回服务器进行分析处理。
- 在服务器端,将所有的URL、方法调用链信息去重后存入数据库,即完成依赖关系收集。
- 从SVN取回某个变更了的方法名,取回所有受到影响的方法列表
实现方法:使用HttpClient开源组件发送请求到URL:
请求的返回值为json格式:
- 来源: Web UI; API; Android; IOS;
- 组织:
业务线回归(on time): P0,P1,P2,P3;
公司级回归(on demand): P0, P1;
精准回归(on event): P0,P1,P2,P3;
通过用例的逻辑操作,可自由加入回归实验室;
5. 时间分析
WebUI脚本Profiler
![](http://qa.taobao.com/wp-content/uploads/2012/04/process1-300x231.png)
- 现状:目前主站应用数大致为 800多个,应用的daily环境为 1120多个(虚机)。
基本的部署过程: build.sh先更新代码和配置项打包后进入以下过程
- 部署方式
目前部署已经实现web化操作 daily环境的建立和维护人为scm,开发、测试、scm都可以有权限来进行部署
在scm.taobao.net平台中申请环境部署权限,可以通过页面实现以下部署
- 今年daily环境将要进行的工作:
1.daily主要应用梳理,备机方式
解决问题:应用部署时,对测试的影响
应用出现问题,可以切换到备机
2.二套标准环境推广
项目、沙箱或者开发环境可以绑定二套标准环境,提升环境的稳定性
7. 测试环境(daily 环境)稳定
- Daily下应用部署的监控
现状:对于daily下应用的部署情况只有片面、粗略的了解,没有办法基于数据做一些分析
- 应用部署测试
现状:daily环境下,部署应用后,并没用立即验证,这经常引起依赖的业务方访问出问题;
- 网络稳定和响应提速
现状:daily环境应用响应速度慢,主要有三方面原因:1、js/css没有压缩,部分合并、部分没合并;2、图片直接从TFS文件系统读取,没有做缓存;3、automan部分机器配置差,部分网段网络不稳定(6网段和24网段)。
- 应用性能提升
现状:每天大约有100个URL在全网回归执行过程中,时长超过5S,疑似被测应用本身性能较低。
在一个上百人测试部门,上千人以上规模的研发团队, 做好一件事情,技术是一方面,另外一个重要方面是所有人一起为了一个目标去努力,背后是每一位工程师的心血和汗水, 是每一位工程师的努力打造了淘宝网今天的持续集成一角