用于产生、捕获、存储和加载失败的测试脚本的调试信息的方法和装置与流程

背景技术：

随着软件变得越来越复杂，用于设计、开发、测试和调试它的工具也变得越来越先进。因此，软件开发人员现在越来越多地团队工作并依靠诸如调试器和测试脚本的开发工具来帮助识别并解决他们的代码中的错误(通常称为“缺陷”)。

调试器(通常是集成开发环境解决方案(ide)的一部分)是用于识别并解决源代码中的错误的工具。调试器内的常见组件是“执行跟踪器”，该“执行跟踪器”允许调试器记录、观察、并控制诸如正在开发的应用这样的另一处理的执行。在跟踪应用的执行的同时，调试器可在应用运行时访问应用的“执行上下文信息”。应用的执行上下文信息可包括诸如执行路径、方法调用历史、调用堆栈、以及本地和全局变量的值这样的信息。

通常，执行跟踪与“断点”一起使用。跟踪点和断点几乎是同义的。主要区别在于跟踪点由执行跟踪器自动设置并处理。相反，断点等待用户以恢复应用。断点是代码中的特定点，如果在应用执行期间到达所述特定点，则在该点将暂停应用的执行并向开发人员提供执行上下文信息。在执行暂停的同时，开发人员可检查执行上下文信息以确定错误的原因。为了继续调试，开发人员可以恢复应用的执行，直到命中另一断点或者应用已完成执行。

调试过程非常繁琐、耗时、并且需要设置断点和执行应用的多个循环。当测试失败或应用抛出错误时，开发人员在调试过程中的第一步是识别可能导致错误的代码的区域，在那些代码位置手动设置断点，利用调试器手动重新启动应用，并且此后等待执行以到达断点。如果达到断点，则开发人员检查应用在该点的执行上下文信息以对应用的行为进行分析。如果开发人员无法确定错误的原因，则开发人员会继续应用的执行(或者根据需要逐渐地进行到该执行中的下一步)，直到该执行到达下一断点或执行完成。

如果无法解决错误并且应用已终止，则开发人员必须使用调试器重新启动应用，并根据需要手动设置其它断点。如果其他开发人员想要协助调试应用，则他们必须共享对本地开发机器的访问并且使用上述步骤，或者将开发环境(即源代码、二进制文件、调试器)复制在他们的机器上，这可是耗时的、资源密集的、并且仍然不一定确保错误会被复制。

正如本发明人所认识到的，需要这样一种方法或工具，该方法或工具用于产生、捕获、存储、并且加载对应用错误或失败的测试进行调试所必需的调试信息而无需手动地重新执行应用或访问本地开发机器。

技术实现要素：

该说明书描述了与使用测试脚本来调试软件有关的技术，并且具体地描述了与捕获、存储、并共享失败的测试脚本的执行上下文信息的方法和系统有关的技术。

通常，在该说明书中所描述的主题的一个方面可具体体现为用于集成软件测试脚本并捕获和存储调试数据而无需用户交互的方法和组件。示例性组件包括一个或多个处理设备以及用于存储指令的一个或多个存储设备，所述指令在由一个或多个处理设备执行时使得一个或多个处理设备实现示例性方法。示例性方法可以包括：执行软件测试脚本；并且响应于软件测试脚本的不成功的执行，重新执行测试脚本而无需用户交互；捕获测试脚本的执行的跟踪和相关源代码数据而无需用户交互；以及存储测试脚本的跟踪和相关源代码数据而无需用户交互。

这些和其它实施例可以可选地包括以下一个或多个特征：未成功的执行可以包括测试失败；未成功的执行可以包括测试超时；加载所存储的跟踪和相关源代码数据以用于在远程开发环境上进行调试；存储跟踪和相关源代码数据并从数据库对其进行访问；存储跟踪和相关源代码数据并从本地开发环境对其进行访问；通过存储介质(如数据库)向多个用户提供对所存储的跟踪和相关源代码数据的并发访问；向用户显示跟踪和相关源代码数据；在集成开发环境(ide)中显示跟踪和相关源代码数据。

在附图以及下面的描述中对本发明的一个或多个实施例的细节进行了阐述，所述附图仅仅是作为说明给出的。从描述、附图、以及权利要求书将显而易见地得知其它特征、方面、以及优点。在各附图中相同参考数字和标记表示相同元件。

附图说明

图1是用于说明执行包含源代码文件、二进制文件、单元测试文件、调试器、以及用于执行这里所述的方法的跟踪捕获组件的本地开发环境的示意图；还说明了托管包含调试数据的数据库的服务器。

图2是用于声明三个方法的类的示例性源代码文件。

图2a是在图2中所声明的方法，methoda，的示例性源代码。

图3a是用于返回“success(成功)”的methoda的单元测试的执行的示例。

图3b是用于返回“fail(失败)”的methoda的单元测试的执行的示例。

图4是用于调试单元测试的开发人员的传统方法的流程图。

图5是用于产生、捕获、并且存储单元测试的调试数据而无需任何用户交互的示例性方法的流程图。

图6是用于对存储在多个远程用户/开发人员可访问的数据库上的调试数据进行说明的示意图。

图7是用于调试单元测试而无需访问本地开发环境或重新执行应用的开发人员的方法的流程图。

图8是用于在本地开发环境中调试单元测试的ide的用户界面的截图。

图9是用于对示例性计算设备进行说明的方框图。

具体实施方式

这里所述的示例性实施例包括下述步骤，即从本地开发环境产生、捕获、存储、并加载失败的测试脚本的调试数据而开发人员无需设置调试过程或与活动的调试器/调试过程进行交互。图1描绘了本地开发环境(105)和数据库(155)。本地开发环境(105)可以包含源代码文件(110)、与源代码文件(110)相关联的可执行二进制文件(115)、针对二进制文件(115)运行的单元测试(120)、用于产生执行跟踪数据的调试器(125)、以及用于实现这里所述的方法的跟踪捕获组件(130)。这里所述的本地开发环境(105)仅作为示例并且不应被认为是限制本发明的范围。在一些实施例中，开发环境(105)可能更复杂，其中源代码和二进制文件在多个位置，这需要访问远程库和服务。另外，开发机器可以具有集成的开发环境软件(ide)。

在示例性实施例中，ide可以在集成软件解决方案中管理源代码文件、二进制文件、调试器、编译器、分析器、以及其它开发组件。该示例性实施例描述了具有这些ide元件的跟踪捕获组件(130)的功能。虽然在该示例中跟踪捕获组件(130)被描绘为独立组件，但是在其它示例中，组件(130)可以被集成在调试器(125)中，作为扩展集成在ide中，或者作为服务集成在服务器上。

图1还描述了可以存储包括失败的单元测试的相关执行跟踪和源代码数据的调试数据(160，165，170)的数据库(155)。虽然在该示例性实施例中仅对失败的测试进行了处理并将其存储在数据库(155)中，但是因为通常仅失败的测试需要调试，因此该方法不仅限于失败的测试而且还可应用于其通常包括成功的单元测试和应用测试的所有调试。

图2是用于声明以下三个方法的类的源代码文件的示例：methoda(205)、methodb(210)、以及methodc(215)。图2a是所声明的方法中的一个，methoda(205)的示例性源代码。methoda具有两个整数输入参数并且可返回true(真)或false(假)的布尔值。如果第一参数x是第二参数y的值的一半，则methoda应返回true，否则该方法应返回false。与该方法相关联的结构完善的单元测试集将测试这两种情况：1)当x的值是y值的一半时；以及2)当x的值不是y值的一半时。在这里，源代码总是错误地返回true，因而包含了缺陷。因此，该方法的单元测试应测试何时第一参数x不是第二参数y的值的一半，并返回“fail”(下面在图3b中进一步所示)以指示源代码中的缺陷/错误。

图3a是与methoda相关联的单元测试的示例性执行。即就是软件测试脚本的methoda_unittest1调用methoda，其中输入参数为6和12。在该示例中，该测试是成功的，因为单元测试测试当第一参数x是第二参数y的值的一半时该方法是否返回true。因为值6是12的一半，因此该测试期望返回值为true，并且该方法实际返回值为true。因而，测试通过。

图3b是另一单元测试的示例性执行。methoda_unittest2也调用methoda，但输入参数为1和10。因为1不是值10的一半，因此单元测试期望返回值为false，但是该方法实际上返回值为true。因而，该单元测试失败并发出与应用中的潜在缺陷有关的告警。

单元测试仅是执行和测试应用的一种手段。在这里单元测试的使用仅意味着作为示例并且不应被认为是对本发明范围的限制。例如，其它类型的测试可以包括一般(非单元)测试脚本、自动gui测试工具、或者用户驱动的测试。这里所述的方法焦点型的单元测试(每次测试一个方法)也仅是示例并且也不应被认为是限制本发明范围。单元测试的结构和复杂性或者与开发中的应用相关联的其它测试策略可以基于应用的开发和设计而变化。

图4是用于调试单元测试的传统方法的流程图。通常，所有或一组单元测试自动运行或者当代码更改并且应用的相关二进制文件已被重建时由开发人员调用。单元测试针对这个新产生的构建运行以验证该构建的完整性并对由代码更改所引起的任何潜在错误进行检测。传统地，当单元测试失败时，开发人员经历在源代码中设置断点并且利用如在此更详细描述的调试器来重新执行该应用以检查执行上下文信息这样的手动过程。

传统方法开始于(405)单元测试的执行(410)。如果测试通过(415，416)，则没有检测到缺陷，开发人员不做任何操作(420)。如果测试失败(415，417)，则开发人员首先检查单元测试(425)和任何相关错误以确定导致失败的源代码区域。接下来，开发人员在代码的那些区域中设置断点(430)以指令调试器在那些点处停止应用的执行。此后开发人员使用调试器重新开始单元测试(435)以跟踪应用的执行。如果应用执行到达断点(440，441)，则调试器在该点处停止应用的执行并向开发人员提供应用的执行上下文信息。开发人员检查该信息(445)以尝试并解决该缺陷(450)。

如果开发人员能够解决该缺陷(450，451)，则该方法完成(460)并且开发人员可实现必要的源代码更改。然而，如果开发人员无法解决该缺陷(450，452)，则开发人员继续执行应用(455)。如果命中另一断点(440，441)，则执行再次停止并且开发人员在该断点处重复检查执行上下文信息的步骤(445)以试图并解决该缺陷。在没有断点被命中(440，442)的情况下执行可以继续，即执行完成或终止，并且缺陷仍然存在。

此后开发人员返回到检查单元测试的步骤(425)。如所示，对于开发人员来说该过程可是非常耗时和繁琐的，这潜在地需要手动检查单元测试、源代码文件、设置断点、并重新执行应用的多个循环。此外，需要开发人员访问应用所驻留的本地开发机器，使用调试器来运行应用，并在相关源代码中手动地设置断点以检查该应用的执行上下文信息。

图5是根据示例性实施例的描述用于在执行失败的单元测试之后产生、捕获、并存储由跟踪捕获组件所产生的相关调试数据而不需要任何用户交互的示例性方法的流程图。虽然在该示例性实施例中，“失败的单元测试”表示期望返回值与实际返回值不匹配的情况，但是不应认为是对本发明的范围的限制。“失败的”还可以包括该代码是低效或非高性能的。

示例性方法开始于(505)单元测试的执行(510)。如果测试通过(515，516)，则该方法可以不做任何操作(520)。如果测试失败(515，517)，这意味着软件测试脚本的执行是不成功的，则该示例性方法可以利用调试器和支持跟踪的执行来自动地重新执行单元测试而无需用户交互(525)。该重新执行步骤与开发人员手动地执行该步骤(435)、可能执行多次(450，452)、以及利用诸如检查源代码(425)并且设置手动断点(430)这样的一些其它先前步骤来执行的传统方法相反。在该示例性方法中，跟踪捕获组件可以自动地对与单元测试的执行路径相关联的源代码的每一行设置跟踪点(530)并且可以对源代码的每一行捕获执行上下文信息(535)而无需用户交互。跟踪捕获组件还可以被配置/优化为根据诸如源代码文件的位置、类型、大小这样的某些因素来捕获并存储执行上下文信息而无需用户交互。这些仅是用于提高跟踪捕获组件/方法的有效性和效率的一些示例并且不应被认为是限制本发明的范围。在测试失败或测试超时的情况下，软件测试脚本的执行是不成功的。

相反，在传统方法下，开发人员手动地查看单元测试以确定相关源代码文件(425)并在相关源代码中手动设置断点(430)以跟踪那些代码区域并检查那些点处的执行上下文信息(445)。

在该示例性方法中，此后可以将所捕获的相关跟踪数据(即执行上下文信息和相关源代码)存储在数据库或其它存储介质(540)上并从其访问以供多个开发人员检查。在一些示例中，可以只对失败的单元测试存储相关跟踪数据。向用户提供对所存储的跟踪和相关源代码数据的并发访问。这完成了示例性方法(545)，现在任何开发人员可以使用所捕获的单元测试的调试数据以调试错误而不必重新执行应用或访问本地开发机器。这与开发人员访问本地开发机器并在它运行的同时调试应用的传统方法形成鲜明对比。

图6是包含methoda_unittest2(610)的调试数据的数据库(605)的示例。基于我们在图3b和流程图5中的示例，这应该是当应用如在示例性实施例中所述的方法时的结果。如所示的，诸如团队中的原始开发人员或其他开发人员这样的多个用户(615，620，625)可访问调试数据(630)(单元测试的所捕获的执行上下文信息以及相关源代码)并将其取回到本地机器而不必重新执行应用或访问本地开发环境。

图7是开发人员调试单元测试而无需访问原始本地开发环境或者重新执行应用的方法的流程图。示例性方法开始(705)，其中开发人员可以加载可能已被捕获(如图5所述)并被存储(如图6所述)的单元测试的调试数据(710)。使用该数据，开发人员可以在如集成开发环境软件(ide)这样的用户界面中检查执行上下文和相关源代码以解决来自其本地机器(715)(即不是原始开发机器)的错误而无需重新执行应用或单元测试。

图8是在新的开发环境(在该情况下为本地开发环境2)上的具有methoda_unittest2_debugdata的调试数据的ide用户界面的屏幕截图。在该示例中，已捕获、存储了失败的单元测试的调试数据并且现在将其本地加载到不同的新的开发环境(本地开发环境2(800))而不是原来的(105)。该示例性ui描绘了列出并允许开发人员选择单元测试的相关源代码文件(815，816，817)的ide软件(805)。与应用实际上在本地机器上执行时相类似，用户界面还提供了诸如“后退”(820)、“前进”(821)、“进入方法”(822)、以及“跳出方法”(823)选项这样的调试能力以浏览应用的执行跟踪。在这里，“进入方法”功能没有启用，因为执行点(835)不是方法调用的代码行。来自跟踪捕获组件的已捕获的调试数据允许开发人员在原始本地开发环境上对调试器的相似的功能。在methoda的情况下，内部窗口(825)还显示相关源代码以及行号(830)。对开发人员还高亮显示调试过程中的当前执行点(835)。在下面的窗口(845)中显示该点(835)处的执行上下文信息。随着开发人员“单步执行”(820-823)或点击源代码中的不同行(830)，更新高亮显示的当前执行点(835)以及调试信息(840-845)。开发人员还可选择执行上下文信息(840-843)的类型以显示诸如局部变量信息(840)、调用栈数据(841)、方法历史(842)、或者变量历史(843)。在该屏幕截图中，选择用于在单元测试的执行期间显示执行点(835)处的局部变量的值的“局部”(840)。现在开发人员可确定在该情况下局部变量正确地加载，但返回值是不正确的，从而解决了该缺陷。

图9是在计算设备(900)上显示应用的高级方框图。在基本配置(901)中，计算设备(900)典型地包括一个或多个处理器(910)、系统存储器(920)、以及存储器总线(930)。存储器总线用于处理器与系统存储器之间的通信。该配置还可以包括用于实现上述方法的独立跟踪捕获组件(926)，或者可以被集成到应用(922，923)之中。

取决于不同配置，处理器(910)可是微处理器(μp)、微控制器(μc)、数字信号处理器(dsp)、或者其任何组合。处理器(910)可包括诸如l1缓存(911)和l2缓存(912)这样的一个或多个级别的缓存、处理器内核(913)、以及寄存器(914)。处理器内核(913)可包括算术逻辑单元(alu)、浮点单元(fpu)、数字信号处理内核(dsp内核)、或者其任何组合。存储器控制器(916)还可是处理器(910)的独立部分或内部部分。

取决于期望的配置，系统存储器(920)可是包括但不局限于易失性存储器(诸如ram)、非易失性存储器(诸如rom、闪速存储器等)、或者其任何组合的任何类型。系统存储器(920)典型地包括操作系统(921)、一个或多个应用(922)、以及程序数据(924)。应用(922)可以包括跟踪捕获组件(926)或者用于产生、捕获、存储、并且加载应用或测试的执行的系统和方法。程序数据(924)包括以下存储指令，该存储指令当由一个或多个处理设备执行时实现所述方法和组件(923)的系统和方法。或者，通过跟踪捕获组件(926)可以执行方法的指令及实现。在一些实施例中，应用(922)可被安排成与程序数据(924)一起在操作系统(921)上操作。

计算设备(900)可具有附加特征或功能以及附加接口以便于基本配置(901)与任何所需设备和接口之间的通信。

系统存储器(920)是计算机存储介质的示例。计算机存储介质包括但不局限于ram、rom、eeprom、闪速存储器或其它存储器技术、cd-rom、数字多功能盘(dvd)或其它光存储、磁盒、磁带、磁盘存储或其它磁存储设备、或者可以用于存储期的望信息并可由计算设备700访问的任何其它介质。任何这样的计算机存储介质可是设备(900)的部分。

计算设备(900)可是作为诸如蜂窝电话、智能电话、个人数据助理(pda)、个人媒体播放器设备、平板计算机(平板)无线web观看设备、个人耳机设备、专用设备、或者包括任何以上功能的混合设备这样的小尺寸规格便携式(或移动)电子设备的一部分。计算设备900还可以被实现为包括膝上型计算机和非膝上型计算机配置这两者的个人计算机。

以上详细描述已通过使用方框图、流程图、和/或示例对设备和/或过程的各种实施例进行了阐述，只要这样的方框图、流程图、和/或示例包含一个或多个功能和或操作，本领域技术人员将会理解的是这样的方框图、流程图、或示例之内的每个功能和/或操作可通过宽范围的硬件、软件、固件、或者其实质上地任何组合而单独地和/或共同地实现。在一个实施例中，这里所述的本主题的若干部分可以是通过专用集成电路(asic)、现场可编程门阵列(fpga)、数字信号处理器(dsp)、或者其它集成格式而实现的。然而，本领域技术人员将认识到这里所公开的实施例的一些方面在整体上或部分地可以等同地在集成电路中实现、作为在一个或多个计算机上运行的一个或多个计算机程序实现、作为固件实现、或者作为其实质上的任何组合实现，并且按照本公开设计电路和/或编写软件或固件的代码在本领域技术人员的技术能力范围内。另外，本领域技术人员将认识到这里所述的主题的机制能够作为多种形式的程序产品进行分发，并且无论实际用来执行分发的非暂时性信号承载介质的具体类型如何，这里所述的主题的示例性实施例均适用。非暂时性信号承载介质的示例包括但不局限于以下：诸如软盘、硬盘驱动器、致密盘(cd)、数字通用盘(dvd)、数字磁带、计算机存储器等这样的可记录型介质；以及诸如数字和/或模拟通信介质(例如光纤光缆、波导、有线通信链路、无线通信链路等)的传输型介质。

就这里任何复数和/或单数术语的使用而言，本领域技术人员可根据上下文和/或应用适当地将复数转化为单数和/或将单数转化为复数。为了清楚起见，在这里可以明确地阐述各种单数/复数置换。

因而，已对本主题的特定实施例进行了描述。其它实施例在以下权利要求的范围之内。在一些情况下，权利要求中所列举的动作可以以不同顺序执行并且仍然实现期望结果。另外，在附图中所描绘的过程不是必须需要所示的特定顺序或相继顺序来实现期望结果。在某些实现中，多任务和并行处理可能是有利的。

根据示例性实施例，公开了一种用于产生、捕获、存储、并且加载失败的测试脚本的调试数据而无需用户交互的方法和系统。在示例性实施例中，跟踪捕获组件将自动地重新执行失败的测试脚本并在测试脚本的重新执行期间捕获与失败的测试脚本相关联的执行上下文信息和源代码文件。将执行上下文信息和相关源代码存储在数据库或其它共享存储介质上并且可以被多个用户访问以允许多个用户同时进行调试。所捕获的信息允许对失败的测试脚本进行调试而不需要访问原始机器或重新执行应用。

在以下中，对根据本公开的进一步示例和方法进行了描述。

第一示例涉及一种用于集成软件测试脚本并调试而无需用户交互的方法，该方法包括：执行软件测试脚本；以及响应于软件测试脚本的不成功的执行，重新执行测试脚本而无需用户交互；捕获测试脚本的执行的跟踪和相关源代码数据而无需用户交互；并且存储测试脚本的执行的跟踪和相关源代码数据而无需用户交互。

在基于第一示例的第二示例中，不成功的执行是测试失败。

在基于第一或第二示例的第三示例中，不成功的执行是测试超时

在基于第一至第三示例中的一个的第四示例中，该方法进一步包括加载所存储的跟踪和相关源代码数据以在远程开发环境上进行调试。

在基于第一至第四示例中的一个的第五示例中，该方法进一步包括存储跟踪和相关源代码数据并从数据库对其进行访问。

在基于第一至第四示例中的一个的第六示例中，该方法进一步包括存储跟踪和相关源代码数据并从本地开发环境对其进行访问。

在基于第一至第六示例中的一个的第七示例中，该方法进一步包括通过如数据库这样的存储介质来向多个用户提供对所存储的跟踪和相关源代码数据的并发访问。

在基于第一至第七示例中的一个的第八示例中，该方法进一步包括向用户显示跟踪和相关源代码数据。

在基于第一至第八示例中的一个的第九示例中，该方法进一步包括在集成开发环境(ide)中显示跟踪和相关源代码数据。

第十示例涉及一种用于集成软件测试脚本并调试而无需用户交互的跟踪捕获组件，该跟踪捕获组件包括：一个或多个处理设备，用于接收软件测试脚本的状态；一个或多个存储设备，用于存储下述指令，所述指令当由所述一个或多个处理设备执行时使得所述一个或多个处理设备：执行软件测试脚本；并且响应于软件测试脚本的不成功的执行，重新执行测试脚本而无需用户交互；捕获测试脚本的执行的跟踪和相关源代码数据而无需用户交互；并且存储测试脚本的执行的跟踪和相关源代码数据而无需用户交互。

在基于第十示例的第十一示例中，状态表示测试失败。

在基于第十或第十一示例的第十二示例中，状态表示测试超时。

在基于第十至第十二示例中的一个的第十三示例中，所述跟踪捕获组件进一步包括加载所存储的跟踪和相关源代码数据以在远程开发环境上进行调试。

在基于第十至第十三示例中的一个的第十四示例中，所述跟踪捕获组件进一步包括存储跟踪和相关源代码数据并从数据库访问所存储的跟踪和相关源代码数据。

在基于第十至第十三示例中的一个的第十五示例中，跟踪捕获组件进一步包括存储跟踪和相关源代码数据并从本地开发环境访问所存储的跟踪和相关源代码数据。

在基于第十到第十五示例中的一个的第十六示例中，跟踪捕获组件进一步包括向多个用户提供对所存储的跟踪和相关源代码数据的并发访问。

在基于第十至第十六示例中的一个的第十七示例中，跟踪捕获组件进一步包括在集成开发环境(ide)中显示跟踪和相关源代码数据。