用于收集程序运行时信息的系统和方法

专利名称：用于收集程序运行时信息的系统和方法
技术领域：
本发明涉及计算机领域，具体涉及计算机软件的测试，更具体涉及一种用于收集 程序运行时信息的系统和方法。
背景技术：
功能验证测试(又称黑盒测试)是指由测试人员在不知道程序的内部实现的情况 下来测试程序/系统。测试人员所知道的信息是输入的数据和观察到的输出结果，但他们 不知道程序或系统是怎样工作的。在测试过程中，当执行测试用例的时候，如果发现缺陷(defect)，就需要给开发人 员开缺陷，这通常包括1)描述重现缺陷的步骤；2)如果有错误日志，则将错误日志从日志 中抽取出来；3)保存快照；4)然后使用诸如Rational ClearQuest等缺陷跟踪和报告工具 将上述所有信息发送给开发人员。由于传统的功能验证测试流程是黑盒测试，测试人员没有方法来分析源代码，去 了解被测程序的内部逻辑，而只能在外部理解和分析，所以有时候测试人员很难判断一个 缺陷是环境原因导致的还是确实是一个缺陷。这就造成了测试人员常开错缺陷，从而浪费 测试人员和开发人员的时间。测试人员也很难精确定位发生错误的代码，因而无法分析错 误并向开发人员提供更多的有用信息。由于缺陷描述信息的不准确和不详细，导致开发和 测试人员之间的沟通困难。对于跨国企业而言，开发和测试人员常常是跨地域跨时区的，不 能即时地、自由地对缺陷进行交流，这进一步增加了沟通的困难。尽管在有些情况下，被测程序会有异常抛出，并记录在错误日志里，如websphere application server的SystemOut. log，这样测试或开发人员可以根据错误日志中的信息 定位错误位置，但在很多情况下，被测程序并不会生成日志，在另一些情况下，生成的日志 并不准确。另外，作为一个测试人员，他不能也不应该像开发人员一样安装一套开发环境来 调试程序的错误，并获得有关错误的详细信息。而且，对于一些服务器应用来说，需要在测 试的同时能够运行并处理来自其他客户的并发请求，而调试程序却使该应用服务器无法同 时运行并处理来自其他客户的请求。此外，尽管一些测试人员注册了诸如CVS等源代码版本管理工具来查看分析源代 码。但这只是一个静态的分析，而不能获取和观察程序的实时运行情况。而且这种方法在 某些项目中因为可能涉及到安全的问题，是被禁止的。从以上所述可见，本领域中目前缺少这样一种处理方法在功能测试的过程中提 供更多更准确的信息来开高质量的缺陷，从而使测试人员能够更准确的定位错误的位置， 降低开发人员和测试人员间的沟通成本，提高工作效率。

发明内容
在本发明的一个方面，提供了一种用于收集程序运行时信息的方法，包括通过程序插桩将监视代码插入到将运行的程序中的异常类的构造函数中；以及在程序的运行过程 中，通过所述监视代码收集程序的运行时信息。在本发明的另一个方面，提供了一种用于收集程序运行时信息的系统，包括插桩 模块，用于通过程序插桩将监视代码插入到将运行的程序中的异常类的构造函数中；以及 由所述监视代码实现的监视模块，用于在程序的运行过程中，收集程序的运行时信息。本发明的方法能向测试者提供被测程序运行过程中发生错误时的更详细和准确 的信息，包括发生错误时的调用栈以及参数值，使得测试者更好地为开发者开缺陷，从而使 开发者更好地理解程序缺陷的上下文和原因，定位错误并更快地克服程序缺陷。此外，这一 切都是在原来的测试环境中实现的，不需要测试者安装额外的开发和调试工具。而且，对于 在服务器上运行的程序而言，不需要中断服务，而是可以在测试的同时处理来自其他客户 的请求。


所附权利要求中阐述了被认为是本发明的特点的创造性特征。但是，通过参照附 图阅读下面对说明性实施例的详细说明可更好地理解发明本身以及其优选使用模式、目 标、特征以及优点，在附图中图1示出了根据本发明的实施例的用于在功能验证测试中收集和提供诊断信息 的系统的体系结构；图2描述根据本发明的实施例的用于在功能验证测试中收集和提供诊断信息的 方法；图3示出了在一具体示例场景中用于输入用户信息的用户界面；图4示出了在该具体示例场景中用于查看用户信息的用户界面；以及图5示出了在该具体示例场景中用于显示所述调用栈信息和相应的源代码信息 的用户界面。
具体实施例方式下面参照附图来说明本发明的实施例。在下面的说明中，阐述了许多具体细节以 便更全面地了解本发明。但是，对于本技术领域内的技术人员明显的是，本发明的实现可不 具有这些具体细节中的一些。此外，应当理解的是，本发明并不限于所介绍的特定实施例。 相反，可以考虑用下面的特征和要素的任意组合来实施本发明，而无论它们是否涉及不同 的实施例。因此，下面的方面、特征、实施例和优点仅作说明之用而不应被看作是所附权利 要求的要素或限定，除非权利要求中明确提出。本发明的基本思想是在功能测试的过程中收集和提供程序运行时的准确的诊断 信息，以便测试人员开缺陷。图1示出了根据本发明的实施例的用于在功能验证测试中收集和提供诊断信息 的系统的体系结构。如图所示，该系统包括插桩模块101，用于通过程序插桩向被测程序 插入用于收集被测程序运行时信息的监视代码；由所述监视代码实现的监视模块102，用 于在被测程序的测试运行过程中，收集被测程序的运行时信息；以及可选的呈现模块103， 用于将与程序缺陷有关的运行时信息呈现给测试者。4
所述插桩模块lol可以由本领域所知的任何插桩工具来实现。如本领域的技术人员所知的，插桩是指在程序的源代码、执行代码或某种中间代码中插入额外的监视代码以抽取程序运行过程中的信息。例如，可以将监视代码插入到方法的开始和结束的位置，这样在运行时刻，当一个线程进入方法时，就能够记录和报告被该线程调用的方法名称、以及方法的参数信息。再例如，可以将监视代码插入以用于读或写堆中的对象或类的域的指令周围，以便记录当前内存操作的所有者类或对象的信息、域信息、操作类型等信息。
在现有技术中，插桩通常应用于程序的覆盖性分析，而没有用于在功能验证测试收集诊断信息以用于开缺陷。本发明首次将程序插桩技术应用于程序的功能验证测试，以收集程序运行过程中与程序缺陷有关的运行时信息。
根据本发明的实施例中，被测程序为了aVa程序，且所述插桩为字节码插桩，即在丁aVa类中特定的位置插入额外的监视代码来抽取类执行过程中的信息。
根据本发明的实施例的系统中的所述监视模块102是由插入到被测程序中的监视代码实现的。
根据本发明的实施例，为了跟踪被测程序运行过程中的出错点，进行以下两种方式的插桩中的任何一种或两种
1)用于捕获异常的插桩。在程序执行过程中，抛出异常，表明程序出现异常情况。抛出异常的位置，一般就是出错的位置。当异常出现的时候，一个异常对象会被构造。通过插桩异常对象的构造，就可以捕获到出错位置。因此，对于这样的出错方式，根据本发明的实施例的系统对异常类的构造函数进行插桩。例如，出现异常时，会有类似如下代码。
EXCepti。n e—neW S。meEXCepti。n() ；
通过修改类EXCepti。n的构造函数，在其中插入用于记录程序运行时的相关信息的监视代码，就可以捕获到抛出异常时的出错位置等程序运行时信息。因为EXCepti。n类是所有异常类的父类，所有异常类的构造都会调用EXCepti。n类。以jaVa为例，
publ iC ClaSS EXCepti。n eXtendS Thr。Wable{
publ iC EXCepti。n(){
]Super()；
}
修改后的EXCepti。n类变成为，
publ iC ClaSS EXCepti。n eXtendS Thr。Wable{
publ iC EXCepti。n(){
Super()；
runtimeReC。rder．reC。rdEXCepti。nwithThreadStaCk(thiS) ；
}
如上述代码片断所示，在EXCepti。n类构造函数的末尾，通过字节码插桩技术插入一个新方法的调用，reC。rdEXCepti。nwithThreadStaCk(EXCepti。n e)，这个方法用来的记录这个异常构造和该异常构造的时候当前线程或所有线程的调用栈信息。
reC。rdEXCepti。nwithThreadStaCk(EXCepti。n e){
／／步骤l记录异常e
／／步骤2记录运行时当前线程或所有线程的调用栈
}在这种插桩方式中，每当被测程序执行过程中抛出异常时，所述监视代码就将发 生异常时的程序运行时信息(例如调用栈信息等)记录下来，例如记录在一诊断信息存储 库中，以便由呈现模块103呈现给测试者。当然，监视代码也可以直接将发生异常时的程序 运行时信息提供给呈现模块103，以便由呈现模块103呈现给测试者。在传统的异常捕获方法中，都是对异常处理部分进行插桩，以在异常处理部分来 捕获程序中的异常，但是由于异常处理部分遍及程序的所有位置，所以需要修改所有的异 常处理部分，这不但十分繁琐，而且更严重的是，有些异常不需要显式处理，所以有些异常 在异常处理部分是无法捕获到。根据本发明的实施例的系统仅对异常的构造函数进行插 桩，不但大大减轻了工作量，而且还能有效地捕获到程序运行中产生的所有异常。如本领域的技术人员所知的，调用栈信息中包括被程序运行到当前时刻的当前线 程标识以及一系列被调用的类和方法的名称、输入输出参数信息。通过调用栈信息可以得 知当前的程序运行时状态以及发生错误的位置。2)针对断言变量的插桩。在功能验证测试中，测试用例会使用断言来判断程序执 行结果，即设置验证点(verification point)变量及其预期置。如果被测程序运行后验证 点变量的值和预期值一致，则判断测试正确，断言通过；否则，判断测试错误，断言失败。根 据本发明的实施例，在测试执行前，解析测试用例中的断言，从而获得验证点变量。然后，对 被测程序中所有对验证点变量的访问位置(包括对检查点变量的每一次读访问或者写访 问)进行插桩，插入监视代码，以记录被测程序运行时的相关信息。在这种插桩方式中，每当被测程序在运行过程中访问验证点时，监视代码就会将 被测程序在访问验证点时的运行时信息(例如当前调用栈信息等)以及访问验证点变量时 验证点变量的值记录下来(例如记录在诊断信息存储库中)或直接提供给测试工具，以便 由测试工具通过分析所记录或提供的信息判断测试用例中的断言是否成功，并响应于判断 断言失败，通过呈现模块103将引起断言失败的验证点访问时的程序运行时信息以及验证 点变量的值呈现给测试者。根据本发明的一实施例，该系统还包括一可选的解析模块104，用于解析测试用例 中的断言以获得其中的验证点变量，以便进行相应的插桩。当然，也可以通过人工解析测试 用例中的断言来获得其中的验证点变量。例如，对于如下的测试用例
##################################################邶TESTCASL· NAME :test_savingaccount.script##VERSI0N % ff% -% E%亂INE ITEM=PythonArrays##C0MP0NENT(S) =DBOPprint" TestCase Start，，......declare accountSum long ； ----变量声明......DepositMoney (accountSum, 100)----变量访问 权利要求
1.一种用于收集程序运行时信息的方法，包括通过程序插桩将监视代码插入到将运行的程序中的异常类的构造函数中；以及 在程序的运行过程中，通过所述监视代码收集程序的运行时信息。
2.根据权利要求1的方法，还包括 呈现所收集的运行时信息。
3.根据权利要求2的方法，该方法用于程序的功能验证测试，且还包括 通过解析测试用例中的断言获得其中的检查点变量；通过程序插桩将监视代码插入到程序中访问所述检查点变量的位置。
4.根据权利要求3的方法，其中，呈现所收集的运行时信息包括响应于根据检查点变量的值判断断言失败，将程序在测试运行过程中访问该检查点的 运行时信息以及检查点变量的值呈现给测试者。
5.根据权利要求1-4中任何一个的方法，其中，所述程序的运行时信息包括程序运行 中的当前线程的调用栈信息。
6.根据权利要求1-4中任何一个的方法，其中，所述程序的运行时信息包括程序运行 中的所有线程的调用栈信息。
7.根据权利要求1-4中任何一个的方法，还包括通过将所收集的运行时信息与程序的源代码进行比较来确定与程序缺陷相关的源代 码；以及呈现所述源代码。
8.一种用于收集程序运行时信息的系统，包括插桩模块，用于通过程序插桩将监视代码插入到将运行的程序中的异常类的构造函数 中；以及由所述监视代码实现的监视模块，用于在程序的运行过程中，收集程序的运行时信息。
9.根据权利要求8的系统，还包括呈现模块，用于呈现所收集的运行时信息。
10.根据权利要求9的系统，该系统用于程序的功能验证测试，且还包括 解析模块，用于通过解析测试用例中的断言获得其中的检查点变量；且其中，所述插桩模块还用于将监视代码插入到程序中访问所述检查点变量的位置。
11.根据权利要求10的系统，其中，所述呈现模块用于响应于根据检查点变量的值判断断言失败，将程序在测试运行过程中访问该检查点的 运行时信息以及检查点变量的值呈现给测试者。
12.根据权利要求8-11中任何一个的系统，其中，所述程序的运行时信息包括程序运 行中的当前线程的调用栈信息。
13.根据权利要求8-11中任何一个的系统，其中，所述程序的运行时信息包括程序运 行中的所有线程的调用栈信息。
14.根据权利要求8-11中任何一个的系统，还包括比较模块，用于通过将所述与程序缺陷有关的运行时信息与程序的源代码进行比较来 确定与程序缺陷相关的源代码；以及所述呈现模块还用于呈现所述源代码。
全文摘要
提供了一种用于收集程序运行时信息的系统和方法，该系统包括插桩模块，用于通过程序插桩将监视代码插入到被运行的程序中异常类的构造函数中；以及由所述监视代码实现的监视模块，用于在程序的运行过程中，收集程序的运行时信息。
文档编号G06F11/36GK102053906SQ20091021131
公开日2011年5月11日 申请日期2009年10月30日 优先权日2009年10月30日
发明者刘艳凯, 唐闯, 沈星星, 齐尧 申请人:国际商业机器公司