模板
教程
环境
性能
功能
管理
淘宝网 持续集成的 尝试
全网回归
全网回归 是淘宝网主站 持续集成的 组成部分，
要解决的问题
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服务的名字空间等信息，存入数据库即完成了依赖关系的收集，具体技术要点如下：
