Eclipse中的持续测试：提高软件生产力的关键

理论计算机科学电子笔记107（2004）103-117www.elsevier.com/locate/entcsEclipse中的持续测试大卫·萨，迈克尔·D. Ernstsaff@mit.edu，mernst@mit.edu麻省理工学院计算机科学人工智能实验室美国摘要持续测试在开发人员的工作站上使用额外的周期在后台持续运行回归测试，在编辑源代码时提供关于测试失败的快速反馈。它旨在减少保持代码良好测试所需的时间和精力，并防止回归错误长时间持续存在。本文介绍了在Eclipse开发环境中为Java开发设计和实现的一个连续测试功能。我们面临的挑战是生成和显示一种新的反馈（测试失败的异步通知），这种方式有效地重用Eclipse的可扩展体系结构，并符合Eclipse用户的期望，而不会干扰他们当前的工作习惯。我们提出了我们在解决这一挑战时所追求的设计原则：现在和未来的重用，一致的体验，最小的干扰和可测试性。这些原则，以及我们的插件和Eclipse是如何成功和失败地实现这些原则的，应该引起其他希望实现新类型开发人员反馈的Eclipse扩展器的持续测试插件可以在以下网址公开获得：http://pag.csail.mit.edu/~saff/continuoustesting.html。关键词：持续测试，回归测试，软件生产力，Eclipse插件，异步通知1介绍使用Eclipse的Java开发人员可以利用连续编译;在每次保存更改后，编译（增量）运行，这使生成的类文件与源文件保持最新，并在遇到任何编译错误时迅速通知开发人员。这种反馈有时可能是无用的或多余的。然而，持续编译的流行和有效性表明，提供的反馈足够有价值，处理器足够快，使其值得。1571-0661 © 2004 Elsevier B. V.根据CC BY-NC-ND许可证开放访问。doi：10.1016/j.entcs.2004.02.051104D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）持续测试[8，7]是软件开发环境的一个新特性它基于这样一个想法，即处理器已经变得足够快，不仅可以在代码更改时保持编译，而且还可以保持测试。当代码被更改时，测试被选择并在后台运行，并且故障被快速标记以供开发人员解决。测试变得自动化;它更早地捕获回归错误，让开发人员更有信心他们正在取得进展，并且需要更少的工作。连续测试的目的是减少与测试相关的两种浪费浪费时间的第一个来源是花在运行测试上的时间：记住运行它们，等待它们完成，在被中断运行测试后返回手头的任务。浪费时间的第二个来源是在系统中存在错误时执行开发所花费的时间。在存在错误的情况下执行开发延长了纠正错误的时间：必须考虑更多的代码更改以找到与错误直接相关的更改，代码更改在开发人员的脑海中不再新鲜开发人员不知道错误的时间越长，这些后果可能就越严重我们为Emacs实现了一个持续测试的初步版本，并将其用于对学生开发人员的用户研究（参见2.1节）。在结果的鼓舞下，我们构建了一个功能齐全的持续测试实现，作为Eclipse集成开发环境的插件[3]。1.1设计目标Eclipse已经包含了对集成单元测试、自动异步编译和编译错误自动通知的支持。这意味着，无论是在技术实现中，还是在用户期望和隐喻中，大部分持续测试的基础设施都已经存在。这使我们能够比在Emacs中更快地提供更多的功能，我们希望这将使我们能够更快地开发用户群。使用我们插件的开发人员可以将测试套件与每个Java开发项目相关联。每当项目中的代码发生更改时，测试套件将异步运行，并且任何测试失败都将类似于编译错误那样向开发人员指示为了减少发现失败所需的平均时间，开发人员可以启用测试优先级，尝试首先运行最有可能失败的测试。该插件不会干扰JUnit的手动使用，它使用不显眼的信号向感兴趣的开发人员指示其进度，而不会过度分散注意力。在构建这个插件时，我们遵循了以下架构原则：D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）105• 重用：尽可能重用现有功能。Eclipse是为可扩展性而设计的，在许多地方，它的插件体系结构允许我们在适当的地方简单地贡献我们想要的功能• 未来重用：当重用不可能时，为未来重用而设计。在某些情况下，我们希望扩展的插件没有在我们需要的地方提供扩展点，因此必须将代码从现有插件剪切并粘贴到我们的插件中。在这些情况下，我们将复制的代码尽可能接近原始代码，这样如果将来提供扩展点，就可以很容易地使用它们。• 一致的体验：始终为用户保持一致的前端。一致性意味着不改变旧环境中的行为（例如，保留现有的JUnit结果视图，仅显示手动启动的测试的结果），并允许用户将旧的隐喻用于新功能（测试失败看起来类似于编译错误，但可以区分）。• 最小的干扰：插件使用常识性的语法来避免使用明显冗余的信息来烦扰用户。如果在被测试的代码中有编译错误，测试失败是没有意义的.如果两个项目都引用同一个测试，则其失败应仅指示一次。除了一个新的失败的测试之外，任何状态的改变都应该被巧妙地指出，这样开发人员就可以很容易地忽略它。• 可测试性：使插件尽可能地可测试可测试性在几个方面影响了我们的设计，特别是通过引导我们构建用于监控进度的API，可测试性还鼓励分离表示和应用程序逻辑，特别是在配置对话框中。我们已经衡量了持续测试对用户的生产力和士气的好处但是，Eclipse开发人员和扩展人员可能也会对上述原则在当前插件设计中的应用方式感兴趣。令人鼓舞的是，Eclipse的模块化很好地将自己的设计与几个以前不相关的组件联系在一起。但是，我们也强调了插件和Eclipse中的改进机会本文的组织结构如下。我们首先回顾连续测试和相关主题的相关工作（第2节）。然后，我们描述了持续测试插件的设计，包括它的用户界面（第3节）和技术架构（第4节）。最后，我们描述了改进插件及其所基于的Eclipse框架的机会（第5节），106D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）治疗N正确没有工具11百分之二十七连续编译10百分之五十持续测试18百分之七十八Fig. 1.治疗预测正确性。“N”是每个组的参与者人数。“Correct” means结束（第6节）。2相关工作2.1持续测试我们已进行两种不同类型的研究，以评估持续测试的效益。首先[8]，我们测量了实际的开发项目来估计浪费的时间，包括可预防的额外修复成本加上运行测试和等待测试完成的时间。 在被监控的项目中，浪费的时间占总开发时间（编程和调试）的10-15%。我们还开发了一个开发人员行为模型，从中我们推断出每个错误的无知时间（从介绍到发现）和修复时间（从发现到修复）。我们发现无知时间和固定时间是相关的，并得出结论，减少无知时间应该减少固定时间。对于被监控的项目，持续测试工具可以减少92- 98%的浪费时间，这比测试优先级或更频繁地手动测试更有效。其次[7]，我们进行了一个对照实验，比较了三组学生开发人员：一个提供了连续的测试，一个只提供了连续的编译，还有一个没有提供任何类型的开发错误的异步通知。所有参与者都使用Emacs作为他们的Java开发环境。使用连续测试的学生开发人员完成两个不同的为期一周的编程作业（这是他们正常课程的一部分）的可能性是对照组的三倍;见图1。这些具有统计学意义的结果是由于连续测试造成的：它们不能用实验设置的其他偶然特征来解释，例如工作时间、定期测试或经验或工具偏好的差异。有连续编译能力的学生完成任务的可能性是没有连续编译能力的学生的两倍;据我们所知，这是连续编译有效性的第一个经验证据大多数使用连续测试的用户都有积极的印象，他们说这使他们注意到了他们可能忽略的问题，D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）107它帮助他们更快地产生正确的答案，并编写更好的代码。Sta Wendy说，学生们很快就建立了一个直观的方法来使用额外的功能。94%的用户表示，他们打算在学习后使用该工具进行课程作业，90%的人会向其他人推荐该工具。很少有用户发现反馈会分散注意力，并且没有观察到对生产力的负面影响。2.2相关的想法连续测试可以被看作是连续编译的自然扩展，这是Eclipse中的标准，也是极限编程[1]的标准，它强调了单元测试套件的重要性，这些测试套件非常频繁地运行，以确保代码可以快速地增强或重构而不会出现回归错误。Gamma和Beck [4]，独立于当前的作者，遵循这些线索提出“测试失败是编译错误”作为Eclipse工作示例的一部分。Gamma和Beck的插件包括一个编辑器，用于从自动执行中排除测试。我们的包括通过构建框架的异步测试执行，自动测试的启动配置和环境的详细规范，测试优先级和其他增强。这两个插件是独立和并发设计的，但我们确实参考了Gamma和Beck的Henderson和Weiser [5]提出了连续执行。 通过与VisiCalc等电子表格类比，他们提出的VisiProg系统（他们假设需要比他们可用的更多的计算能力）在三个单独的自动更新窗口中显示程序，示例输入和结果输出。测试套件不是持续地维护一个完整的输出，这可能会使开发人员不知所措，而是将输出抽象为一个简单的指示，以指示每个单独的测试用例是否成功。3用户体验3.1概述持续测试建立在Eclipse中的自动化开发人员支持之上，当开发人员拥有JUnit测试套件时，可以更容易地保持Java代码的良好测试。如果启用了连续测试，Eclipse会在开发人员编辑代码时在后台运行测试，并在任何测试失败或导致错误时通知开发人员。它在开发人员需要108D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）图二.测试失败通知以三种方式显示：在Problems视图中，在源代码空白处，以及在方法名称下显示为红色波浪下划线在更改代码时使用测试套件：当执行维护，bug修复，重构或使用测试驱动开发时[2]。持续测试建立在Eclipse的另外两个特性之上：• JUnit集成：在持续测试下运行的测试套件以相同的格式提供开发人员已经从Eclipse的JUnit集成中但是，持续测试还有助于自动选择何时运行测试、运行哪些测试以及运行顺序。持续测试不会干扰开发人员对JUnit的并发使用，这• 持续编译：一旦开发人员编写了包含编译错误的代码，Eclipse就会在文本和空白处突出显示错误，并在Problems视图中创建一个任务。这使得快速了解问题，并以有序的方式逐步解决和修复问题变得容易。通过持续测试，开发人员在编写或编辑导致测试失败的代码时会然而，测试失败与编译错误的不同之处在于，测试失败有时不能容易地跟踪到单行代码，并且测试失败可以提供比编译错误更多的信息，例如回溯插件是通过Eclipse的内置软件更新实用程序安装的启用和配置持续测试是在每个项目的基础上通过属性对话框完成的。该插件附带了一个完整的源插件，以便于扩展和调试，并且遵循可测试性原则，提供了一个使用Eclipse的JUnit Plug-in Test支持的测试套件3.2运行错误和通知保存代码更改会触发相关测试配置的运行。状态栏显示每个测试开始和完成时的通知失败的测试以多种方式表示（图2），类似于编译错误：D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）109• 问题将添加到Problems视图中。这个问题的图标是一个红色的球，类似于编译错误，但有一个T代表“测试失败”。在Problems视图中右键单击此项将打开一个上下文菜单，其中包含重新运行失败测试、删除标记或查看与失败关联的堆栈跟踪的选项• 在Problems视图中双击该项将打开并突出显示失败的测试方法。方法名称用红色波浪下划线和页边空白处的红色T标记。插件在几个方面遵循最小干扰原则• 测试仅在开发人员保存时运行，以避免在开发人员知道不一致的状态中进行测试。• 由连续测试运行的测试不会显示在标准的JU- nit输出视图中，也不会出现在RunHistory中。 这些地方是为手动发射保留的。 关于当前自动测试运行的详细信息可以在Continuous Testing视图中找到，但是我们希望用户在大多数时候隐藏这个视图。理想的做法是更改标准JUnit接口，使其能够识别和指示手动和自动启动，但这需要更改Eclipse（请参见第5节）。• 如果在正在编辑的项目或包含测试的项目中的任何位置或在这些项目的依赖项中存在编译错误• 如果两个项目与同一个测试套件相关联，那么每个测试只会创建一个失败标记。一旦引入了更改，并且删除了当前标记为失败的测试（即，该测试位于与更改的项目相关联的套件中），则该失败的图标将从红色更改为灰色，因为该测试已计划运行。如果测试再次失败，图标将变回红色。如果成功，标记将被删除。通过这种方式，用户可以区分由当前版本的代码引起的已知故障（红色图标）与仅在先前版本中存在但正在被排除的已知故障（灰色图标）之间的差异。这与Eclipse在自动编译期间处理编译错误的方式是一致的3.3测试优先级调整默认情况下，Eclipse JUnit集成总是以相同的顺序运行套件中的测试（尽管有时很难预测该顺序）。如果开发人员最感兴趣的测试在套件中运行得很晚，这可能会令人沮丧。为了缓解这个问题，110D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）最新失败：最新失败的测试优先。最快的测试优先：测试按运行时间的增加排序;完成最快的测试优先。没有重新排序：测试在每次更改时都以默认的JUnit顺序运行。循环：类似于“No reordering”，但如果测试被中断，则在中断的测试处重新开始测试，并返回到开始处。最频繁的失败：最频繁失败的测试（在之前最大数量的运行中失败）被排序在第一位。随机：测试以随机顺序运行，不重复。图三.测试用例优先级策略由插件按照预期有效性的降序排列[8]。允许几种测试优先级[8，9，6]，通过启动配置的适当性进行确认这是一个相对独立的特性，可以在所有JUnit启动时实现，但目前仅在持续测试时启用。六个当前支持的策略（图3）都包含了以前测试运行的结果，以帮助确定当前计划测试的优先级。技术细节见第4.2我们发现[8]这些策略中最有用的是最新失败优先，因为当前失败或最近失败的测试可能是开发人员最感兴趣的，并且更有可能再次失败4插入式设计在这里，我们讨论Eclipse的设计特性，这些特性限制了插件（4.1），以及插件本身的设计（4.2）。4.1Eclipse设计概述在本节中，我们提出了Eclipse的一些突出设计点，这些设计点影响了持续测试插件的设计我们重点关注自动构建框架和JUnit启动框架的静态结构和动态行为。这是Eclipse设计的高级概述，在可能的情况下省略了较低级别的细节。4.1.1汽车制造图4显示了Eclipse中项目、源文件和构建器的静态结构。每个项目都位于资源树的根，资源树包括文件夹、源文件和其他文件类型。为了简单起见，我们D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）111见图4。Eclipse中自动构建框架的静态结构。 实心箭头表示子类型关系.未填充的箭头表示关联。星号表示一对多和多对多关系中的多样性。将每个项目视为一个简单的源文件容器。每个项目还引用一个有序的零个或多个构建器列表，这些构建器是通过扩展点提供的。每个构建器负责响应增量更改，以保持项目状态一致。例如，Java构建器使用编译器来保持构建的类文件与项目中的Java源文件保持最新，而RMI构建器使生成的骨架和存根文件与项目中的任何RMI接口保持最新图5显示了当用户更改其中一个项目源文件时自动构建框架的行为创建一个增量并应用于源文件。一个全局构建经理会被通知这个delta，并决定哪些项目是被忽略的。然后构建管理器启动一个新的异步作业，在不同的线程中实际执行自动构建。这个新作业将控制权依次传递给项目的每个构建器。如果构建器在响应delta时遇到错误（例如编译错误或类路径问题），它可以创建一个或多个标记，附加到项目中特定位置的源文件。更新GUI以指示这些标记。4.1.2JUnit启动Eclipse为用户提供了一个启动框架，以启动新的Java进程来执行项目中的代码（代码由上面详细描述的自动构建框架不断编译）。图6显示了支持此功能的持久静态结构。Eclipse保留对一组用户定义或自动生成的启动配置的引用每个配置引用一个或多个项目，这些项目（本身或在引用的依赖项目和库中）包含进程运行所需的所有每个配置都有一个特定的启动类型，比如运行Java应用程序，运行JUnit测试112D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）图五.当用户更改源文件时，Eclipse中自动构建框架的动态行为。在本图中首次显示的类以灰色突出显示。 在不同进程或线程中运行的异步作业显示为圆形框。见图6。 Eclipse中启动框架的静态结构使用图形化的测试运行器，以及启动一个包含正在开发的插件的Eclipse新实例。图7显示了在启动JUnit时如何使用它。创建了一个新的JVM实例，并将所有需要的项目和库放置在其类路径中。这个新JVM中的主类是一个远程测试运行器。EclipseJVM中的客户端为远程测试运行器打开一个套接字，运行器使用该套接字来传递其进度和每个测试的结果。客户端使用此反馈来更新测试结果视图。4.2持续测试设计持续测试结合了自动构建和启动框架。它使用修改过的JUnit启动类型来运行测试并为失败的测试创建标记，并使用自动构建框架来保持这些标记与代码和测试的状态保持同步。的原则下为了避免重用，新类尽可能地继承现有类，或者D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）113见图7。 在Eclipse中启动JUnit框架的动态行为。否则从现有类复制，更改最少图8显示了连续测试插件对静态结构的添加首先，添加了一个新的连续测试构建器类型，以保持故障标记为最新。启用了持续测试构建器的项目将使用新的持续测试启动类型的启动配置的引用进行注释，该启动配置将在项目检测到增量时运行。此外，为了使测试优先级，每个连续测试启动配置的持久数据空间维护测试元数据。例如，一个希望首先运行最快测试的工具将存储每个测试的最新观察持续时间图9显示了当源文件被更改时，所有内容如何协同工作和之前一样（虽然这里没有显示），创建一个delta，通知构建管理器，启动一个自动构建线程，然后允许每个构建器依次启动。假设Java编译成功完成，控制权被传递给持续测试构建器，它使用启动框架来启动附加到更改后的项目的配置。持续测试配置启动远程测试运行器和本地测试运行器客户端的修改版本。它还使用一个临时文件将优先化工具的元数据传递修改后的远程测试运行器会询问线束测试应该运行的顺序。修改后的测试运行器客户端更新测试结果GUI，将更改反馈给线束元数据，并创建测试失败标记以附加到测试项目。5今后工作如果像我们这样的插件被认为是有价值的，那么还可以做一些剩余的工作来改进我们的插件和Eclipse的设计114D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）见图8。静态结构的连续测试插件。连续测试的特定功能以灰色突出显示。见图9。 连续测试插件的动态行为。5.1插件持续测试插件最重要的下一步是打破它被打包成几个通过扩展点进行通信的组件插件，这样Eclipse用户和扩展器就可以从当前打包成一个插件的功能中进行挑选这将允许未来的扩展程序遵循重用原则。我们设想单独的插件，• JUnit中的测试优先级• 基于测试失败创建标记，• 将测试启动与项目相关联，以及• 使用构建器在项目更改时自动启动测试。 该插件将来可能会有许多增强功能，包括：• 连续测试可以利用Eclipse调试器使用的热插拔JVM来更改Eclipse上的测试代码，而不必停止和重新启动整个测试过程。D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）115• 如果所需的分析可以足够快地进行，则优先级排序和选择可以基于源增量，而不仅仅是基于先前运行的结果。例如，可以给予已知使用最近更改的方法的测试更高的优先级。• Eclipse• 也许可以利用测试经常在后台运行的事实来实现“即时变量监视”：例如，可以想象将鼠标悬停在一个变量上，以查看下一次测试过程执行该行代码时该变量的值是什么。作者发现自己已经通过在代码中添加调试打印语句，并在测试自动运行时观察控制台中打印的值，来近似此功能。• 持续测试应扩展到插件开发环境测试套件。• 应该可以将启动配置与不同的包甚至文件相关联，而不是与整个项目相关联。• 正如在大型程序上连续编译而不进行增量编译是不可行的一样，在大型测试套件上连续测试将需要某种形式的增量测试。对于长时间运行的测试套件，诸如优先级之类的方法是不够的：必须使用在以前的测试运行中收集的数据来运行那些可能揭示最近引入的错误的测试部分。我们目前正在研究将长时间运行的测试分解为较小的单元测试，即使程序员没有提供单元测试。5.2Eclipse这是对Eclipse的致敬，两个机制，每个机制都包含协作的异步进程，可以以我们在这里所做的亲密方式捆绑在一起，而没有任何迹象表明这样的功能是Eclipse设计者和实现者的原始意图。同样不可避免的是，没有一个系统可以预测贡献者可能尝试扩展它的每一种可能方式。我们发现我们需要一些额外的扩展点和APIJUnit集成：Eclipse中的JUnit集成假设用户只对单个测试配置的单个运行的进度和结果感兴趣-最近手动启动的配置。当引入连续测试时，这会导致冲突• 最近手动启动的配置不一定是116D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）最近跑步我们通过一个单独的Continuous Testing Results视图来处理这个问题，该视图与JUnit视图非常相似，但最好将它们结合起来。• 用户可能有兴趣查看多个测试配置的结果，或者针对不同版本的代码多次调用相同的配置。这种冲突在没有连续测试的情况下已经存在，但是由于连续测试的用户不能直接控制其测试运行的频率或顺序的事实而加剧。当前插件无法解决此冲突。这些连接建议扩展JUnit接口，以显示跨多个版本的多个测试运行（手动和自动）的结果。这就要求实现JUnit启动配置类型和JUnit视图的类更好地设计为继承;我们当前的插件被迫覆盖太多的方法，以便只微妙地改变它们的行为。Problems视图：根据我们自己的使用情况，我们相信开发人员习惯于使 用 Problems 视 图 来 快 速 通 知 他 们 的 代 码 问 题 。 与 其 引 入 单 独 的TestFailures视图或ContinuousTesting透视图，我们觉得更合适的做法是重用Problems视图和Java透视图。然而，通过改变图标的图像和颜色，在视觉上区分测试失败和编译错误，以及当前版本的测试失败和以前版本的测试失败是很重要的（参见第3节）。Problems视图的当前实现对所使用的图标图像进行了硬编码，这需要我们使用一个不幸的技巧，即使用Java反射API来实现预期的行为。Problems视图应该使用与用于在源文件的边距中资源和启动之间的进一步联系：在我们看来，一旦用户习惯了持续测试所使用的项目和启动配置之间的联系，他们可能会看到这个想法的其他应用。例如，每个项目（或细粒度资源）可以有一个用户可设置的默认调试配置，当选择该项目中的任何资源时，可以通过单个按键调用该配置部分持续测试6结论持续测试插件可以在以下网址公开获得：http://pag.csail.mit.edu/~saff/continuoustesting.html。D. Saff，医学博士Ernst/Electronic Notes in Theoretical Computer Science 107（2004）117作者自己也在Java应用程序开发中使用它，并且发现它是稳定的，不引人注目的。我们相信，我们能够更早地发现错误，并且能够专注于我们的发展目标，并确信我们能够快速了解我们的变化的影响。从我们设计和实现这个插件的经验来看，Eclipse作为一个评估和分发软件生产力实验工具的平台，已经显示出很大的各个组件都经过了良好的可扩展性设计，无论是在技术上，还是在创建易于扩展到新功能的用户隐喻方面。 随着越来越多的研究人员将Eclipse视为软件工程中新思想的试验场，本文中讨论的原则和经验应该是有价值的。我们打算与Eclipse的开发人员合作，对插件和Eclipse进行必要的更改，以使它们能够更好地集成。我们将继续支持和推广该插件，建立一个可以从功能中受益的用户群，提供有关其使用情况的反馈，并帮助确定未来开发的优先级。我们希望许多开发人员能够发现持续测试是一种有效的方式，可以更快更自信地工作引用[1] Beck，K.，[2] Beck，K.， “Test-Driven Development: By Example,” Addison-Wesley, Boston,[3] Eclipse，http://www.eclipse.org。[4] Gamma、E.和K.Beck，[5] Henderson ， P. and M. Weiser ， Continuous execution ： The VisiProg environment ， in ：Proceedings of the 8rd International Conference on Software Engineering，London，1985，pp.68比74[6] Rothermel ， G. ， R. H. 昂 奇 角 Chu 和 M. J. Harrold ， Prioritizing Test Cases for RegressionTesting，IEEE Transactions on Software Engineering27（2001），pp. 929-948[7] Sa ， D. ， “Automated continuous testing to speed software development,” Master’s thesis,MIT Department of Electrical Engineering and Computer Science, Cambridge, MA[8] Sahlam，D.和M. D. Ernst，Reducing wasted development time via continuous testing，in：Fourteenth International Symposium on Software Reliability Engineering ， Denver ， CO ，2003，pp. 281-292.[9] 黄，W。E、J. R. Horgan，S.伦敦和H.陈晓，回归测试在软件可靠性工程中的应用，第八届国际软件可靠性工程研讨会，北京，1997年。264-274。