维护Hudson持续集成的失败用例有一段时间，就发现每当测试用例失败之后，再来定位是不是由于开发修改了某部分代码或某个配置文件导致，就需要我们自己去debug一遍，然后找出问题所在，Hudson插件目前所能做到的也只能是知道本次构建有哪些文件修改了，对于一个功能点而言，从webx的action或screen，到service，到manager，到dao，受影响的点是特定的，而修改的文件又很多很杂，所以很难确定修改的哪几个文件的哪部分代码是对该功能点有影响的。这样的话，严重影响持续集成对产品开发的效率与质量。

于是就想能不能将其自动化，找了雁声、鹤云了解过有关的情况，也在网上找过很多资料过来研究，发现这种想法是可行的。以下是研究的一些东东，还没来得及实践。

由程序自动首先分析出方法调用的层次关系，然后根据调用关系使用SVNKit对比类方法，标记出修改变化点，直接点击即可查看有哪些部分不同，便于快速发现问题所在，方便维护，节省大量时间与精力，提高工作效率。思路大概如下：

a） 基于ASM字节码框架，动态地非侵入式地注入字节码到工程代码，通过日志输出语句，形成方法调用层次的日志文件；

b） 基于SVNKit客户端库，根据日志文件中的方法调用关系，对比类方法的当前版本与最近一次运行成功版本的代码，标记变化点；

c） 自动监控脚本运行状况，如果运行失败，则系统会自动以邮件、旺旺等方式通知到相关人员进行跟踪。

系统方案如下：

图1 系统结构图

a） 系统核心System Core，基于ASM字节码框架，动态地非侵入式地注入字节码到工程代码，通过日志输出语句，形成方法调用层次的日志文件；

b） 系统核心System Core，基于SVNKit客户端库，根据日志文件中的方法调用关系，对比类方法的当前版本与最近一次运行成功版本的代码，标记变化点；

c） 系统核心System Core，自动监控脚本运行状况，如果运行失败，则系统会自动以邮件、旺旺等方式通知到相关人员进行跟踪；

d） 相关人员点击失败脚本链接，系统根据标记的方法变化点展现出类方法的变化情况，帮助其快速定位问题原因。

图2 ASM注入日志输出代码

通过ASM字节码框架注入日志输出字节码到工程代码里（非侵入式），当运行测试脚本时，进入每个方法前都会通过日志输出字节码将日志记录到特定的目录，形成方法调用关系，若脚本运行失败，则记录失败脚本，并将其链接发送给相关人员。

图3 SVNKit分析日志，对比代码变化

相关人员收到失败脚本的消息，点击失败脚本的链接，基于SVNKit客户端库，根据日志文件中的方法调用关系，对比类方法的当前版本与最近一次运行成功版本的代码，若有变化，则记录并返回变化点给相关人员；否则提示可能原因（如数据、配置）给相关人员。