[发明专利]自动生成可再现运行时问题的单元测试用例的方法和系统

说明书

技术领域

本发明涉及计算机程序的测试及调试领域，更具体地，涉及一种用于自动生成可再现运行时问题的计算机程序单元测试用例的方法和系统。

背景技术

软件产品例如IBM的软件产品的开发通常遵循这样的过程，开发团队负责产品开发和单元测试，产品其他的验证测试工作则由专门的测试团队来负责，验证测试所发现的缺陷由开发团队来更正。单元测试是白盒测试，主要目的是验证代码逻辑，而验证测试则是黑盒测试，用来验证软件功能和表现。

在验证测试期间，可能会发现很多运行时问题，例如非期望的异常以及不正确的或不正常的程序行为。由于测试团队和开发团队是相互独立的，验证测试环境和开发环境也不相同，验证测试中发现的缺陷往往只能通过测试者的文字描述和软件本身记录的日志信息反馈给开发团队。由于测试环境缺乏调试工具，而缺陷描述和日志信息又无法直接调试，这样开发团队必须先根据缺陷描述重建测试环境来进行调试。这通常是非常繁琐和低效的过程。并且有时非常难以再现运行时问题并发现它们的原因。

而且，当开发团队修正了当前发现的缺陷后或者开发了软件新的版本后，因为加入了新的代码，测试团队仍然必须确保之前发现的并已修正的所有缺陷都仍然是被修正的，没有受到当前修改的影响，即进行所谓的回归测试。虽然测试团队必须进行回归测试，但是如果开发团队已经能够提前确保回归测试的正确性，那么测试团队则只要再做一次验证而已，无疑回归测试的效率将会大大提高。因为开发团队验证工具通常是单元测试用例，所以就要求开发团队为每一个已发现的缺陷开发出能够验证其是否被修正的单元测试用例。但是由于前一个问题的原因，调试工作已然复杂，根据缺陷开发单元测试用例往往也是很繁琐的过程，常常被开发团队所忽略。

目前的测试自动化工具，例如Rational Robot和WinRunner等，仅仅针对测试团队和测试过程，其出发点是替代测试者重复的测试动作。它们致力于通过记录和回放用户动作，例如键击和鼠标点击，而不是捕获内部程序行为。它们生成脚本以模拟来自用户和运行时环境的输入。难以确定必须记录多少用户交互以便再现问题。并且由于回放脚本中可能包含一些不相关的动作，再现问题所需要的时间可能不是最佳的。

单元测试目前已在软件开发过程中得到广泛使用。开发者可以在将程序提交测试团队进行验证测试之前通过执行单元测试套件(test suite)来迅速和简单地发现和消除缺陷。一般来说，单元测试的成本远低于验证测试的成本。

目前也存在几种技术和单元测试工具，例如JTest，能够帮助开发者生成单元测试用例。然而，它们只是针对开发团队和开发过程，是根据对代码的静态分析等手段而不是运行时上下文来生成测试用例的。但是单纯的静态分析不能确定程序执行时各程序单元执行的上下文，不能利用运行时上下文和状态创建出可再现运行时问题的测试用例。因此，它们都不能连接测试过程和开发过程，来解决上述问题。

因此，如果能够根据运行时刻的缺陷自动生成单元测试用例，以上两个问题将得以有效的解决：一方面开发团队可以直接使用该测试用例进行调试，省去重建测试环境的工作；另一方面开发团队还可以将此测试用例加入单元测试过程，以确保回归测试的正确性。

标题为“用于监视程序执行的方法和装置”(Method And ApparatusFor Monitoring The Execution Of A Program)的美国专利6,738,778公开了一种跟踪调试工具，它可以在程序中被调用，能够自动收集并打印程序运行信息(如程序当前运行在哪个类的哪一行)。然而，此专利只是打印用于调试的跟踪信息，而不是生成单元测试用例。也不能主动发现程序运行中的错误和异常，并以此触发生成单元测试用例的。