专利名称：一种持续集成失败用例的定位方法及系统的制作方法
技术领域：
本申请涉及测试技术，特别是涉及一种持续集成失败用例的定位方法，以及，一种持续集成失败用例的定位系统。
背景技术：
持续集成是一种软件开发的实践方式，利用自动化的方式对团队开发人员提交的新增与修改的代码进行持续构建(包括编译、发布、自动化测试)，至少每天一次，尽早地发现代码问题，从而保证产品质量。一个典型的持续集成周期包括以下几个步骤I)持续集成服务器不断从版本控制服务器上检查代码状态，看代码是否有更新；2)如果发现代码有最新的提交，那么就从版本控制服务器下载最新的代码；3)等代码完全更新以后，调用自动化编译脚本，进行代码编译；4)运行所有的自动化测试；5)进行代码分析；6)产生可执行的软件，并提供给测试人员进行测试。如果其中任何一个步骤失败，就表示该构建失败，持续集成服务器会给予相应的反馈。在对项目工程进行持续集成时，如果开发人员修改工程中的部分代码或者修改配置文件，都将导致测试脚本失败，从而导致持续集成不能正常进行，严重影响持续集成对产品开发的效率与质量。此时，就必须快速定位问题原因，并解决问题使持续集成正常运转。目前定位问题原因的手段比较繁琐低效，主要是人为地通过Eclipse工具(Eclipse是著名的跨平台的自由集成开发环境(IDE)) —步一步调试代码来分析出程序代码问题，或者人为地通过SVN(Subversion，一种版本管理工具，通过对源代码进行版本控制，从而达到保证文件同步的目的)的客户端工具Show log查看最近代码更新，以及对比出程序代码的变更情况。目前的这两种方案都是由人为手工来分析定位问题，此时会涉及到技术经验、维护成本等问题，当技术经验不足时很有可能发现不到问题所在，而且当脚本成百上千时维护起来非常困难，所以人为来定位需要消耗大量的时间与精力，影响工作效率。
发明内容
本申请的目的在于，提供一种持续集成失败用例的定位方法及系统，以解决目前手动定位效率低的问题。为了解决上述问题，本申请公开了一种持续集成失败用例的定位方法，包括加载工程代码时，在工程代码中注入日志输出字节码；当运行包含所述工程代码的测试脚本时，进入测试脚本的每个方法前通过所述日志输出字节码记录方法调用日志，并根据方法调用日志形成方法调用层次的日志文件；
根据所述日志文件中的方法调用层次分析运行失败的测试脚本，定位运行失败的原因。优选的，所述根据所述日志文件中的方法调用层次分析运行失败的测试脚本，定位运行失败的原因，包括根据所述日志文件中的方法调用层次，对比方法的当前版本与最近一次运行成功版本的代码；将对比发现的变化点进行标记，并将标记的变化点定位为运行失败的原因。优选的，若对比发现无变化，还包括提示运行失败的可能原因，所述可能原因包括数据库变更和/或配置变更。优选的，当点击某个运行失败的测试脚本的链接时，根据所述日志文件中的方法调用层次分析该被点击的运行失败的测试脚本，定位运行失败的原因。优选的，根据所述日志文件中的方法调用层次分析所有运行失败的测试脚本，定位所有运行失败的原因之后，还包括当点击某个运行失败的测试脚本的链接时，从中获取对应的运行失败的原因。本申请还提供了一种持续集成失败用例的定位系统，包括字节码注入单元，用于加载工程代码时，在工程代码中注入日志输出字节码；方法调用层次分析单元，用于当运行包含所述工程代码的测试脚本时，进入测试脚本的每个方法前通过所述日志输出字节码记录方法调用日志，并根据方法调用日志形成方法调用层次的日志文件；失败定位单元，用于根据所述日志文件中的方法调用层次分析运行失败的测试脚本，定位运行失败的原因。优选的，所述失败定位单元包括对比子单元，用于根据所述日志文件中的方法调用层次，对比方法的当前版本与最近一次运行成功版本的代码；标记子单元，用于将对比发现的变化点进行标记，并将标记的变化点定位为运行失败的原因。优选的，若对比发现无变化，所述失败定位单元还包括提示子单元，用于提示运行失败的可能原因，所述可能原因包括数据库变更和/或配置变更。优选的，所述系统还包括第一点击查看单元，用于当点击某个运行失败的测试脚本的链接时触发所述失败定位单元，所述失败定位单元根据所述日志文件中的方法调用层次分析该被点击的运行失败的测试脚本，定位运行失败的原因。优选的，所述失败定位单元根据所述日志文件中的方法调用层次分析所有运行失败的测试脚本，定位所有运行失败的原因；所述系统还包括第二点击查看单元，用于当点击某个运行失败的测试脚本的链接时，从所述失败定位单元中获取对应的运行失败的原因。与现有技术相比，本申请包括以下优点首先，本申请在持续集成过程中，通过加载工程代码时在工程代码中注入日志输出字节码，利用所述日志输出字节码分析出测试脚本中的方法调用层次，然后根据方法调用层次分析运行失败的测试脚本，最终自动定位出运行失败的代码点。这种自动定位失败用例的方法无需人工调试代码，因此可以方便、快速地自动定位到问题原因，解决问题，而且方便维护，节省大量时间与精力，提高了工作效率。其次，本申请使用SVN Kit客户端库自动对比当前版本与最近一次成功调用版本的方法，找出其中的代码变更或者配置变更，无需手动比对变化点，从而更方便、更快速地自动定位到问题原因。再次，本申请还可以自动监控脚本运行状况，如果运行失败，则系统会自动以邮件、即时通讯等方式通知到相关人员进行跟踪。而且，相关人员点击失败脚本链接，系统根据标记的方法变化点展现出类方法的变化情况，帮助其快速定位问题原因。当然，实施本申请的任一产品不一定需要同时达到以上所述的所有优点。
图1是本申请实施例所述一种持续集成失败用例的定位方法流程图；图2是本申请实施例所述一种持续集成失败用例的定位系统结构图；图3是本申请另一实施例所述一种持续集成失败用例的定位系统结构图；图4是本申请另一实施例所述一种持续集成失败用例的定位系统结构图；图5是本申请另一实施例所述的系统结构图；图6是图5所示实施例中ASM注入日志输出字节码的流程图；图7是图5所示实施例中SVN Kit对比代码变化的流程图。
具体实施例方式为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式
对本申请作进一步详细的说明。在对项目工程进行持续集成时，为了快速定位到问题原因，本申请首先自动分析出测试脚本中方法调用的层次关系，然后根据方法调用层次分析运行失败的测试脚本，最终自动定位出运行失败的代码点。下面通过实施例对本申请进行详细说明。参照图1，其为本申请实施例所述一种持续集成失败用例的定位方法流程图。步骤101，加载工程代码时，在工程代码中注入日志输出字节码；字节码(Byte-code)是一种包含执行程序、由一序列op代码/数据对组成的二进制文件。字节码是一种中间码，它比机器码更抽象。它经常被看作是包含一个执行程序的二进制文件，更像一个对象模型。字节码被这样叫是因为通常每个opcode是一字节长，但是指令码的长度是变化的。每个指令有从O到255 (或十六进制的00到FF)的一字节操作码，被参数例如寄存器或内存地址跟随。每次测试时，在加载当前测试所需的工程代码时，将日志输出字节码注入到工程代码中，因此不会对工程代码的源代码造成修改。所述日志输出字节码的作用是分析出测试脚本中方法调用的层次关系，具体的分析方法如步骤102详述。步骤102，当运行包含所述工程代码的测试脚本时，进入测试脚本的每个方法前通过所述日志输出字节码记录方法调用日志，并根据方法调用日志形成方法调用层次的日志文件；
测试脚本中的代码主要是一些类方法的代码，方法之间存在树型的层次调用关系，所有方法可形成一棵方法调用关系树。在测试脚本的运行过程中，每次运行到要进入一个方法前，注入到测试脚本的日志输出字节码就将这个方法与其他方法的调用关系进行日志记录，如这个方法是被另一个方法调用，这个方法又会调用另一个方法。通过这样的方式，日志中就记录下了测试脚本中所有方法之间的调用关系，最终日志文件中形成方法调用层次，也即方法调用关系树。这种方法调用的层次关系可用来定位导致脚本运行失败的原因。步骤103，根据所述日志文件中的方法调用层次分析运行失败的测试脚本，定位运行失败的原因。具体的，步骤103可以包含以下两个子步骤子步骤a，根据所述日志文件中的方法调用层次，对比方法的当前版本与最近一次运行成功版本的代码；在实际应用中，由于方法之间是层层调用的关系，因此对于运行失败的测试脚本，需要找到对应的多个文件，分别进行当前版本与最近一次运行成功版本的两两比较。例如，针对某个运行失败的测试脚本，根据方法调用的层次关系有三个记录了当前版本类方法代码的文件，分别是文件Al、文件B1、文件Cl，此时还需要得到这三个文件在最近一次运行成功的版本代码，如文件A2、文件B2、文件C2，然后将Al与A2、B1与B2、C1与C2进行两两对t匕，找出两个版本的代码是否有变更。子步骤b，将对比发现的变化点进行标记，并将标记的变化点定位为运行失败的原因。以上对比过程是一个自动执行的过程，在对比过程中，若两个版本的代码有变化，则将变化点标记出来，这些变化点可以帮助用户快速定位到脚本运行失败的原因。此外，若对比发现无变化，步骤103还可以包括以下子步骤子步骤C，提示运行失败的可能原因，所述可能原因包括数据库变更和/或配置变更。即如果文件中的代码在两个版本中没有变化，则脚本运行失败可能是由于数据库变更或配置变更所导致。此外，也可能由其他原因导致，本实施例不再一一列举。需要说明的是，上述通过子步骤a、b、c实现步骤103的方案是本实施例的一个优选方案，可实现自动定位，无需人工分析定位。但是，步骤103也可以通过手动方式定位，SP找到需要对比的文件，然后一步一步调试代码找出变化点。由于步骤101和步骤102可以自动分析出测试脚本中的方法调用层次，因此即使手动定位变化点，与现有技术完全通过手动方式实现的方案相比，也可以提高工作效率。此外，自动执行完步骤102之后，步骤103可以在下述两种情况下执行I) 一种情况是根据用户的点击实时分析定位，具体如下当点击某个运行失败的测试脚本的链接时，根据所述日志文件中的方法调用层次分析该被点击的运行失败的测试脚本，定位运行失败的原因。在测试脚本的运行过程中，如果运行失败，注入到测试脚本中的日志输出字节码会记录失败的脚本，并生成失败脚本链接返回给用户，用户点击该链接后，将触发步骤103实时定位问题原因。例如，用户点击失败脚本链接A，则系统实时定位测试脚本A的问题原因，并将定位结果返回给用户查看；若用户点击失败脚本链接B，则系统实时定位测试脚本B的问题原因并返回给用户。由此可知，用户没有点击的失败脚本链接，将不会执行步骤103。2)另一种情况是先自动分析定位，然后根据用户的点击展示定位结果，具体如下在执行完步骤102之后，自动执行根据所述日志文件中的方法调用层次分析所有运行失败的测试脚本，定位所有运行失败的原因；之后，还包括当点击某个运行失败的测试脚本的链接时，从中获取对应的运行失败的原因。即系统在用户没有点击查看的情况下先自动定位出所有脚本的问题原因，并将定位结果存储起来，当用户需要时点击某个失败脚本链接，系统直接从存储的所有定位结果中快速找出对应的定位结果，并返回给用户查看。实际应用中，可选择上述任意一种方式实现，本实施例对此不做限定。综上所述，这种在持续集成过程中自动定位失败用例的方法无需人工调试代码，因此可以方便、快速地自动定位到问题原因，解决问题，而且方便维护，节省大量时间与精力，提高了工作效率。基于上述方法实施例，本申请还提供了对应的系统实施例。参照图2，其为本申请实施例所述一种持续集成失败用例的定位系统结构图。所述系统可以包括字节码注入单元10、方法调用层次分析单元20和失败定位单元30，其中字节码注入单元10，用于加载工程代码时，在工程代码中注入日志输出字节码；方法调用层次分析单元20，用于当运行包含所述工程代码的测试脚本时，进入测试脚本的每个方法前通过所述日志输出字节码记录方法调用日志，并根据方法调用日志形成方法调用层次的日志文件；失败定位单元30，用于根据所述日志文件中的方法调用层次分析运行失败的测试脚本，定位运行失败的原因。优选的，在本申请的另一系统实施例中，所述失败定位单元30具体可以包括以下两个子单元对比子单元，用于根据所述日志文件中的方法调用层次，对比方法的当前版本与最近一次运行成功版本的代码；标记子单元，用于将对比发现的变化点进行标记，并将标记的变化点定位为运行失败的原因。优选的，若对比发现无变化，所述失败定位单元30进一步还可以包括下述子单元提示子单元，用于提示运行失败的可能原因，所述可能原因包括数据库变更和/或配置变更。优选的，在本申请的另一系统实施例中，参照图3所示，所述定位系统还可以包括第一点击查看单元40，用于当点击某个运行失败的测试脚本的链接时触发所述失败定位单元30，所述失败定位单元30根据所述日志文件中的方法调用层次分析该被点击的运行失败的测试脚本，定位运行失败的原因。优选的，在本申请的另一系统实施例中，参照图4所示，所述失败定位单元30可以根据所述日志文件中的方法调用层次分析所有运行失败的测试脚本，定位所有运行失败的原因；基于此，所述定位系统还可以包括第二点击查看单元50，用于当点击某个运行失败的测试脚本的链接时，从所述失败定位单元30中获取对应的运行失败的原因。对于上述定位系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见图1所示方法实施例的部分说明即可。为了使本领域技术人员更加了解本申请的实现，下面通过另一个更具体的例子进行说明。在该例中，将基于ASM和SVN Kit实现持续集成失败用例的定位。ASM是Java字节码处理分析框架，能够非侵入式地动态修改或者生成类，且能够驱动类到字节码的转换以及进行代码分析。其中，所述“非侵入式”是指动态修改或者生产类的过程不会对源代码产生影响。SVN是Subversion的缩写，是一种版本管理工具，通过对源代码进行版本控制，从而达到保证文件同步的目的。SVN Kit是一个纯Java的SVN客户端库，使用SVN Kit无需安装任何SVN的客户端，即可操作SVN服务器端的代码。参照图5，其为本申请另一实施例所述的系统结构图，该系统描述如下I)系统核心System Core,可基于ASM字节码框架,在加载工程代码时动态地非侵入式地注入日志输出字节码到工程代码中，并通过日志输出语句，形成方法调用层次的日志文件；所述ASM字节码框架是一个开源框架，提供了将字节码注入工程代码的功能，利用该功能，本实施例可以将自定义功能的日志输出字节码注入到加载的工程代码中。当系统运行包含所述工程代码的测试脚本时，在进入测试脚本的每个方法前通过所述日志输出字节码，可以将方法调用日志记录下来，并通过日志输出语句形成方法调用层次的日志文件。其中，所述“动态”是指在每次加载工程文件时注入日志输出字节码，这是一个动态的注入过程。所述“非侵入式”是指ASM字节码框架可以使注入到工程代码中的日志输出字节码不影响工程代码的源代码。2)系统核心System Core，可基于SVN Kit客户端库，根据日志文件中的方法调用关系，对比类方法的当前版本与最近一次运行成功版本的代码，标记变化点；所述SVN Kit客户端库不同于背景技术提到的SVN客户端工具SVN客户端工具是一个客户端软件，用户需要在客户端安装所述SVN客户端工具，才能手动查看代码并找出不同版本的变化点；而使用SVN Kit无需安装任何SVN的客户端，即可操作SVN服务器端的代码。SVN Kit提供了文件比对功能，但是SVN Kit只能对两两文件进行单一的对比分析。而如前所述，在本申请实施例中，一个测试脚本由于方法调用的层次关系将对应多个类方法的文件，因此需要对多个类方法的文件进行不同版本的比较。此时，本实施例可以根据方法调用关系树的结构获取需要进行对比的所有类方法的不同版本文件，然后调用SVNKit的单一对比功能对指定的两个版本的文件进行一一对比，从中找出变化点。3)系统核心System Core，还可自动监控脚本运行状况，如果运行失败，则系统会自动以邮件、即时通讯等方式通知到相关人员进行跟踪；4)相关人员点击失败脚本链接，系统可根据标记的方法变化点展现出类方法的变化情况，帮助其快速定位问题原因。参照图6，其为ASM注入日志输出字节码的流程图。具体如下步骤601，通过ASM字节码框架注入日志输出字节码到工程代码里(非侵入式)；步骤602，运行测试脚本；步骤603，记录方法调用的日志文件；进入每个方法前，通过日志输出字节码将日志记录到特定的目录，形成方法调用关系的日志文件；步骤604，判断测试脚本的运行状态；若脚本运行失败，则记录失败脚本，并将失败脚本链接发送给相关人员；若脚本运行成功，则结束流程。参照图7，其为SVN Kit对比代码变化的流程图，是根据用户的点击实时对比分析的例子，具体如下步骤701，相关人员收到失败脚本的消息，点击失败脚本的链接；步骤702，基于SVN Kit客户端库，根据日志文件中的方法调用关系，对比类方法的当前版本与最近一次运行成功版本的代码；步骤703，若有变化，则记录并返回变化点给相关人员；步骤704，否则，提示可能原因(如数据、配置变更等原因)给相关人员。综上所述，上述系统通过ASM字节码框架分析出Java代码中的方法调用树，然后使用SVN Kit客户端库对比SVN上关联文件(Java代码或配置文件)的不同版本的变化点，标记出修改变化点，直接点击即可查看有哪些部分不同，从而更方便、更快速地帮助用户自动定位到问题原因，解决问题。此外，基于本申请的思想，还可以通过以下两种方式实现I)基于ASM封装的工具包(Cglib)进行开发，分析得出方法调用关系树，然后从SVN下载源代码，通过SVN客户端工具手动查看代码或文件的变化点。这种方案中，ASM封装的工具包(Cglib)功能太过强大，除提供注入字节码的功能夕卜，还提供了更多本申请不涉及的功能，因此在实现本申请时功能太过冗余，影响了分析效率。而且，通过SVN客户端工具手动对比的方式显然不及图7所示自动对比的方式。2)基于现有的开源代码覆盖率工具(E_a)进行第二次开发，分析得出方法调用关系树，然后从SVN下载源代码，通过SVN客户端工具手动查看代码或文件的变化点。与将字节码注入工程代码来获取方法调用关系的实现方案相比，基于Emma需要开发大量代码，并不适合本申请，而且也存在手动对比的问题。综上所述，图5、图6和图7所实现的方案为本申请的一个优选实施例。需要说明的是，对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作或单元模块并不一定是本申请所必需的。本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。以上对本申请所提供的一种持续集成失败用例的定位方法及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式
及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。
权利要求
1.一种持续集成失败用例的定位方法，其特征在于，包括: 加载工程代码时，在工程代码中注入日志输出字节码； 当运行包含所述工程代码的测试脚本时，进入测试脚本的每个方法前通过所述日志输出字节码记录方法调用日志，并根据方法调用日志形成方法调用层次的日志文件； 根据所述日志文件中的方法调用层次分析运行失败的测试脚本，定位运行失败的原因。
2.根据权利要求1所述的方法，其特征在于，所述根据所述日志文件中的方法调用层次分析运行失败的测试脚本，定位运行失败的原因，包括: 根据所述日志文件中的方法调用层次，对比方法的当前版本与最近一次运行成功版本的代码； 将对比发现的变化点进行标记，并将标记的变化点定位为运行失败的原因。
3.根据权利要求2所述的方法，其特征在于，若对比发现无变化，还包括: 提示运行失败的可能原因，所述可能原因包括数据库变更和/或配置变更。
4.根据权利要求1至3任一所述的方法，其特征在于: 当点击某个运行失败的测试脚本的链接时，根据所述日志文件中的方法调用层次分析该被点击的运行失败的测试脚本，定位运行失败的原因。
5.根据权利要求 1至3任一所述的方法，其特征在于， 根据所述日志文件中的方法调用层次分析所有运行失败的测试脚本，定位所有运行失败的原因之后，还包括: 当点击某个运行失败的测试脚本的链接时，从中获取对应的运行失败的原因。
6.一种持续集成失败用例的定位系统，其特征在于，包括: 字节码注入单元，用于加载工程代码时，在工程代码中注入日志输出字节码； 方法调用层次分析单元，用于当运行包含所述工程代码的测试脚本时，进入测试脚本的每个方法前通过所述日志输出字节码记录方法调用日志，并根据方法调用日志形成方法调用层次的日志文件； 失败定位单元，用于根据所述日志文件中的方法调用层次分析运行失败的测试脚本，定位运行失败的原因。
7.根据权利要求6所述的系统，其特征在于，所述失败定位单元包括: 对比子单元，用于根据所述日志文件中的方法调用层次，对比方法的当前版本与最近一次运行成功版本的代码； 标记子单元，用于将对比发现的变化点进行标记，并将标记的变化点定位为运行失败的原因。
8.根据权利要求7所述的系统，其特征在于，若对比发现无变化，所述失败定位单元还包括: 提示子单元，用于提示运行失败的可能原因，所述可能原因包括数据库变更和/或配置变更。
9.根据权利要求6至8任一所述的系统，其特征在于，还包括: 第一点击查看单元，用于当点击某个运行失败的测试脚本的链接时触发所述失败定位单元，所述失败定位单元根据所述日志文件中的方法调用层次分析该被点击的运行失败的测试脚本，定位运行失败的原因。
10.根据权利要求6至8任一所述的系统，其特征在于:所述失败定位单元根据所述日志文件中的方法调用层次分析所有运行失败的测试脚本，定位所有运行失败的原因；所述系统还包括:第二点击查看单元，用于当点击某个运行失败的测试脚本的链接时，从所述失败定位单元中获取对应的运行 失败的原因。
全文摘要
本发明提供了一种持续集成失败用例的定位方法及系统，以解决目前手动定位效率低的问题。所述方法包括加载工程代码时，在工程代码中注入日志输出字节码；当运行包含所述工程代码的测试脚本时，进入测试脚本的每个方法前通过所述日志输出字节码记录方法调用日志，并根据方法调用日志形成方法调用层次的日志文件；根据所述日志文件中的方法调用层次分析运行失败的测试脚本，定位运行失败的原因。本发明无需人工调试代码，因此可以方便、快速地自动定位到问题原因，解决问题，而且方便维护，节省大量时间与精力，提高了工作效率。
文档编号G06F11/36GK103077111SQ20111032952
公开日2013年5月1日 申请日期2011年10月26日 优先权日2011年10月26日
发明者何晓峰 申请人:阿里巴巴集团控股有限公司