全网回归
全网回归 是淘宝网主站 持续集成的 组成部分，
要解决的问题
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的回归时间：