软件组件级测试自动化与测试驱动开发的经济有效性研究

理论计算机科学电子笔记116（2005）3-15www.elsevier.com/locate/entcs测试自动化和测试驱动开发介绍：经验报告Lars-Ola Damm1，2，3，4Lars Lundberg2，6David Olsson3，6摘要本文确定并提出了一种软件组件级测试的方法，该方法可以以经济有效的方式在开发过程中更早地进行缺陷检测Erics- son AB的一个部门在两个项目中引入了一个用于组件级测试的测试自动化工具，以及测试驱动开发（TDD）的概念，这是一种在产品代码之前编写测试代码的实践。实现的方法与极限编程（XP）中使用TDD的方式不同本文描述了实现的测试自动化工具，如何测试驱动开发的工具，并从实施的经验初步结果表明，该概念大大缩短了开发提前期。关键词：软件测试自动化，测试驱动开发，构件测试，单元测试，测试工具。1介绍研究表明，测试至少占总开发时间的50%[10]，[11]。其中一个原因是，开发项目后期的验证活动往往充满了本可以预防或至少在更早的时候删除的缺陷（当它们更便宜地发现和删除时）。1这项工作是由爱立信公司和瑞典知识基金会在“Blekinge -工程软件质量（BESQ）”项目（http：//www.ipd.bth.se/besq）的研究赠款下共同资助的。2部门的SW。Eng. 和比较。Sc.，Blekinge Institute of Technology，Ronneby，瑞典3Ericsson AB，Soft Center，SE-372 25 Ronneby，Sweden.4电子邮件：Lars-Ola. Ericsson.com5电子邮件：Lars. bth.se6电子邮件：David. Ericsson.com1571-0661 © 2004 Elsevier B. V.根据CC BY-NC-ND许可证开放访问。doi：10.1016/j.entcs.2004.02.0904L- O. Damm等人理论计算机科学电子笔记116（2005）3[5]，[10]，[21]）。当许多缺陷在项目后期仍待发现时，进度会延迟，验证提前期会增加[13]。爱立信公司的软件开发部门（以下简称为部门）为移动网络开发基于组件的软件。该部门希望透过引入新工具及程序，在组件层面进行自动化测试，以缩短验证交付时间及为了实现这一目标，他们需要确定对工具、流程和组织的要求因此，本文有四个主要问题要回答：(i) 用于组件级测试的自动化测试工具应该具有哪些特征？(ii) 什么是支持使用这种测试自动化工具的适当过程？(iii) 在引入新的组件级测试过程和工具时，需要考虑哪些方面？(iv) 对于引入这种工具和过程的项目，预期的交货期差异是多少？用于回答前两个问题的方法是分析从以前的改进尝试中吸取的经验教训，以及如何提高该部门的测试效率的论文研究[7 论文研究包括定性与定量调查、项目统计分析和文献研究。其他两个问题的答案是从定性和定量访谈用户的介绍概念。本文概述如下。第二节介绍了测试驱动开发的背景，包括测试驱动开发过程的选择。 第3节介绍了实际执行情况以及一些经验教训和预期的筹备时间收益。第4节将新的测试自动化工具映射到测试自动化的相关技术，然后还描述了在能够实现这样的概念之前，组织需要什么第五节通过一些结论总结了工作。2背景在 引 入 这 个 新 概 念 之 前 使 用 的 方 法 包 括 一 个 测 试 工 具 （ 称 为DailyTest），它可以在交付给功能测试部门之前测试隔离的组件在此上下文中，组件是通过公共接口与其他组件通信的可执行资产。此外，一个组件包含大约5-30个类，该部门开发的产品由大约10-30个组件组成。DailyTest可以执行由简单命令组成的脚本，例如加载组件，然后向其发送一系列请求。L- O. Damm等人理论计算机科学电子笔记116（2005）35命令和无循环），更重要的是，它没有正确地与开发过程集成。当该部门意识到这一点时，前面提到的论文研究[7]评估了测试过程，目的是确定将提高测试效率的工具和过程更改。论文研究表明，发现和修复缺陷的成本在开发过程中越晚发现，成本就会显着增加。这也被认为是软件开发中的一个常见事实[5]，[10]，[21]。由于本文的研究还发现，开发人员通常很少把精力放在测试孤立的组件，本文建议，这是重点改进的工作。独立软件组件的测试是该部门质量保证策略中的第一个测试级别，即爱立信术语中的与普通单元测试一样，基本测试的目的是验证设计规范。然而，与单元测试相反，基本测试不是白盒测试技术，因为组件的接口隐藏了内部组件设计。然而，由于是产品开发人员对组件执行基本测试，他们仍然知道内部设计结构。开发人员开始在组件级别上进行测试的原因是因为测试每个类/方法对他们来说是不划算的。其原因是该部门在确定改进措施应集中在基本测试级别之后，论文研究确定了部门开发人员没有对所有功能进行基本测试的主要原因是由于测试工具（例如DailyTest）不足以及由于延迟时间表造成的最后期限压力高时的过程偏差。当开发活动被推迟时，项目往往会交付未经测试的代码，希望它能以一种神奇的方式工作。类似地，这种现象在软件行业似乎并不罕见[14]，[21]。根据上述经验和发现，论文研究提出了一种新的工具，用于如何在部门自动进行产品基本测试，此后他们在两个即将到来的项目中实施并介绍了该工具。2.1测试驱动开发为了确保新的基本测试工具不会成为一个货架，该部门在将该工具与开发过程集成方面做了大量工作，他们在保持以前的标准过程或引入新概念测试驱动开发（TDD）之间做出了选择[2]。TDD与典型测试过程的主要区别在于，在TDD中，开发人员在编写代码之前编写测试。其结果是，6L- O. Damm等人理论计算机科学电子笔记116（2005）3测试用例驱动产品的设计，因为正是测试用例决定了每个单元的要求[1]，[2]。因此，TDD实际上不是一种测试技术[1]，[6];它最好被视为一种设计技术。此外，TDD简化了设计，并确保实现范围是明确的，即它消除了镀金的愿望[1]。尽管如此，TDD最明显的优势与一般的测试自动化相同，即可以对代码进行持续的质量保证（包括回归测试）[9]。这给了开发人员关于他们代码状态的即时反馈，并且很可能，在以后的测试和客户站点中发现的缺陷的百分比显著降低[19]。此外，通过早期的质量保证，避免了测试自动化的一个常见问题;也就是说，当一个组织在开发周期的后期引入自动化测试时，在交付给客户之前，它就成为了所有缺陷的捕获器。发现缺陷的纠正导致测试和重新测试的螺旋式上升，从而延迟产品的交付[18]。关于TDD的最负面的方面是，在最坏的情况下，测试用例重复了要编写和维护的代码量。然而，这与所有类型的测试自动化都存在相同的问题[12]，代码量增加到什么程度取决于测试用例的粒度以及测试用例封装的模块级别，例如类级别或组件级别。因此，由于该部门将在组件级别上使用TDD，他们将减少编写和维护的测试用例代码的数量。另外，与类/方法相比，自动化使用XML作为数据格式的统一接口更容易，并且对更改更健壮。尽管如此，该部门首先选择使用TDD，因为它可以消除先前提到的不当进行基本测试的风险。当测试用例在代码之前开发时，不开发测试用例就同时，当可执行的测试用例已经被开发出来时，没有理由不对产品进行基本测试总之，新概念的主要目的是增加基本测试中的测试代码量。3基本测试概念在提供了一些背景信息之后，第3.1节和第3.2节给出了技术工具描述，第3.3节描述了该工具如何与部门的开发过程集成。在此之后，第3.4节列出了一些观察结果和经验教训，最后，第3.5节介绍了引入这一概念所带来的预期提前期收益。3.1工具和语言的选择由于基本测试的目的是隔离测试组件，因此需要将模拟L- O. Damm等人理论计算机科学电子笔记116（2005）37受试XML接口（在工具中模拟周围的组件）Fig. 1. 基本测试工具-组件周围的组件。 该连接如图1所示。DailyTest是该部门使用的以前的基本测试工具，它以与图1类似的方式连接到组件。为什么不开发一个新的工具，而不是增强DailyTest，是因为要使DailyTest像所需的那样强大，它几乎会成为一种程序语言。当然，当已经存在几种强大的标准语言（如C++和Java）时，这样做是没有好处的。在选择不增强现有的测试工具之后，该部门需要决定是使用标准语言开发新工具还是购买商业工具。首先，通常在极限编程中使用的TDD工具（例如cppUnit）[2]在这种情况下是不合适的，因为它们在类/方法级别上操作;也就是说，它们不支持组件级别的接口（例如cppUnit）。XML通信）。此外，由于基本测试需要与产品架构紧密集成，因此商业供应商开发的测试工具很难用于此目的，因为它们需要某种可以连接到要测试的组件的接口。这样的调整将涉及额外的成本，更重要的是，这样的工具将对如何开发、执行和监控测试施加不必要的限制。这与这样一个事实相结合，即当产品架构具有如此高的可测试性时，开发内部工具相对便宜（参见第4.2.2节），这使得内部开发工具更可取关于使用测试用例生成器（见第4.1节）或手动编写它们之间的选择，测试用例生成器被认为对部门没有好处这是因为该部门认为直接将设计规格编写为可执行测试用例，而不是首先手动编写正式设计规格，然后从中生成测试用例，接下来，该部门需要选择一种语言来编写测试用例。使用标准脚本语言（例如Vi- sual Basic和JavaScript）的主要好处是，与使用系统编程语言相比，程序员往往不太容易出错[17]。尽管如此，该部门还是选择使用C++作为测试用例语言。首先，因为开发人员不需要任何关于如何使用它的培训，因为他们编写了产品代码。其次，C++有能力处理实际工具中不包含的功能，例如，当工具不支持它时，可以直接调用产品代码中的函数。最后，当测试用例用与产品代码相同的语言编写时，开发人员可以利用现有的编程工具[9]，[20]。8L- O. Damm等人理论计算机科学电子笔记116（2005）3A、测试代码示例（C++）System. out. printlnsendMessage（Request.xml，ExpResult1.xml）;Toolkit.sendMessage（Request2.xml，ExpResult2.xml）;System. out. println（）;System. out.printlnSystem. out. println（）;System. out.println（）;System. out. println（）;B、测试结果示例（XML）<测试名称=<统计><开始时间>2003：01：01-12.24/><结束时间>2003：01：01-12.25/><已执行测试次数>2/><已通过测试数量>1/><测试名称=<请求1><结果>好/结果><联系我们<请求2><结果>不合格/结果>ComparisonRes.xml/><测试名称=<请求1><结果>好/结果><联系我们图二. 基本测试工具-示例3.2测试用例语法和输出样式在决定以C++作为测试用例语言开发内部基本测试工具后，该部门选择在设计工具时使用框架驱动的方法，即该工具通过包装器和实用功能将待测试的组件与测试用例隔离开来（见第4节）。图2：A显示了在新的基本测试工具中实现的测试示例此外，该工具还包含几个用于处理组件状态以及发送和接收请求的命令。所有操作都由该工具控制XML请求是从其相应的DTD（数据类型定义）中生成的。图2：B显示了一个测试执行的日志输出示例。该部门选择XML作为输出格式，因为它已经被用作其产品中的标准例如，很容易开发一个GUI，将XML数据解析为测试结果的树结构（根据XML中的标记结构）。在这样的GUI中，开发人员可以监视他们的测试执行和管理员监控测试进度。3.3发展进程仅仅提供一个好的工具并不能确保成功的测试自动化;一个工具只能变得和使用它的人一样好[21]。因为这个工具是和TDD一起使用的（见2.1节），所以测试用例应该在代码之前编写。如前所述，该部门在组件L- O. Damm等人理论计算机科学电子笔记116（2005）39整体产品设计基本测试设计内部组件设计编 码 和 基本 测 试 执行功能测试图3.第三章。部门的基本测试流程测试用例是在一个组件级而不是在一个类级，即开发人员为每个组件构建一组测试用例，而不是为每个类构建一组测试用例。测试策略是捕获每个组件的所有输入和输出。因此，测试代表每个组件的外部设计。这也导致测试用例可以作为设计文档的一部分，取代一些旧的设计（例如组件规范）。这样做的结果是一个更全面的设计（与简单的英语相比，C++不会留下误解的空间），并且当能够删除一些旧的设计文档时，可以节省一些设计时间。图3显示了基本测试概念是如何与部门的过程级别相结合的。新的活动有了工具和如何使用工具的过程，就只剩下一件重要的事情要做了：如何编写测试用例的标准。否则，这个部门最终会得到一个很难的意大利面条测试理解和维护导致测试自动化的好处将丢失[9]。测试自动化是开发，测试用例是测试其他软件程序的软件程序;因此，测试用例与要测试的程序遵循相同的设计和构造规则[21]，[22]。因此，测试应该遵循结构化编程的普通指导方针，以便它们变得简单，可重用，易于理解和维护。此外，测试应该是独立的[17]，因为这使得在短执行时间至关重要时仅执行单个测试的可能性。另外，当有独立的测试时，缺陷的来源只能在那个测试中，这使得定位来源更容易一个缺陷。在BasicTest工具中，“startTest”/“endTest”构造（参见图2）支持这种测试独立性。最后，为了实现日常回归测试，测试必须是可重复的，也就是说，必须能够在没有人为交互的情况下将其作为回归测试来执行[19]。为了能够跟踪和修复在回归测试中发现的缺陷，测试的良好命名约定是必要的。如图2所示，所有测试都有一个名称标签，部门使用该标签来指定每个测试应该验证什么特性。这样的可追溯性使得可以在任何时候都知道每个特性的进度（开发/通过的百分比）。为了确保开发人员遵循编写测试用例的标准，在让开发人员开始实现产品代码之前，应该有人检查所有测试用例。此外，视察必须确保10L- O. Damm等人理论计算机科学电子笔记116（2005）3测试不仅表明代码将工作，而且相反[23]。为了实现这一点，必须获得足够的测试覆盖率，例如覆盖所有行为变量（包括错误情况和边界值）。该部门必须解决的另一个挑战是在已经存在了几年的产品上实施新的基本测试概念，因此，组件包含许多没有此类测试的旧功能。由于在引入该工具时为所有旧功能开发测试对于单个项目来说成本太高，因此该部门只选择为新功能和修改后的功能开发测试。尽管如此，策略是在即将到来的项目中（即在产品的未来版本中）为越来越多的旧功能开发测试。3.4观察和学到的在新概念的实施和引入过程中，我们进行了一些观察，并吸取了一些经验教训。本节提供了一份清单，其中列出了参与目标项目的本文两位作者以及在引入该概念后与该部门的经理和开发人员进行的定性访谈中确定的该部门已经确定了这一点。. ....测试自动化需要高的产品可测试性。根据相关工作，正是产品接口决定了测试自动化的机会[17]。可测试性的概念将在4.2.2节中进一步讨论。...正如在[21]中所报道的，它对于一个完整的框架设计是很重要的，因为它使测试用例开发更容易，并且对未来的变化是健壮的。...组件级的测试自动化需要对产品体系结构进行调整，因为组件级测试体系结构必须与它们的产品体系结构紧密集成（也在[20]中得到承认）。...每次发现新的缺陷时，都要让人们添加新的测试，这需要持续的跟踪和监控。否则，开发人员倾向于提供未经测试的bug修复。此外，作者在[19]中指出，为每个故障添加新的测试可以增强测试套件。...测试执行速度很重要。其他研究支持这种经验，声称测试执行速度越快，开发人员就越有可能自己执行测试[19]。... [23]《易经》中的“行”字是“行”。当该部门开始引入基础测试的新概念时，目标项目对其给予了适度的关注。然而，当项目开始测量开发和通过的测试用例数量的进度时，使用率增加了。...谨防有人试图偏离商定的程序。在时间压力下，项目往往会忽视一些可能带来短期效益但从长远来看可能是毁灭性的活动[13]。因此，在未得到所有相关方同意的情况下，L- O. Damm等人理论计算机科学电子笔记116（2005）311组织（例如：直线组织）。...测试驱动的开发使人们更多地考虑设计，而不是在不知道实现什么的情况下直接急于编码。...在引入新的工作方式时，需要付出巨大的努力，使组织内的人相信新的工作方式将提高生产力。如果不能成功地做到这一点，新方法的引入很可能会失败，因为管理人员和开发人员拒绝接受新的工作方式（在4.2.1节和4.2.2节中进一步讨论）。...测试工具很容易成为每个问题的借口[8]。问题的原因可能在测试工具、开发环境或被测应用程序中;尽管如此，基本测试工具还是成为大多数问题的替罪羊，因为问题首先是在工具中发现的，无论它们来自何处。...自动化测试需要专用资源。作为一个共同的事实[17]，[21]，测试自动化不能作为业余活动来管理。相比之下，开发或购买工具是相当便宜的;它是活动，如测试用例编写的标准，教用户如何编写好的测试用例，和工具维护是昂贵的。...测试自动化的好处很难在第一个项目发布中获得。其他报告支持这种经验，声称前期成本消除了第一个项目的大部分收益，回归测试的收益通常要到第二个版本才能实现[16]。...测试自动化应该以小步骤引入，例如作为试点项目，以避免不必要的风险（如果以错误的方式引入，但只是小规模的，那么解决问题的成本很可能会这一建议也在研究文献中给出[9]，[12]，[17]。...最小化维护成本是测试自动化中最困难的挑战。测试用例必须在bug修复期间和新产品版本中保持稳健。由于这很难实现，测试自动化中最常见的问题可能是不受控制的维护成本[17]。3.5预期提前期收益本文件并未提供引入概念的成本和收益的实际结果。然而，初步的项目评估表明，故障率显著下降。此外，图4显示了一项研究的结果，其中所有开发人员（在调查问卷中）在使用产品版本X中的概念后估计了交付周期差异。平均而言，他们估计使用该概念时，项目交付周期将越来越短（例如，第三个项目中为25%）。还要注意的是，开发人员并不认为第一个版本中的引入成本延迟了项目，也就是说，他们从一开始就估计了收益。另一个发现（来自对项目经理的定性访谈）是，不仅缩短了交货期是使用控制的原因12L- O. Damm等人理论计算机科学电子笔记116（2005）3产品版本预期交货期差异（开发时间）第十版（2003年）-2%X+1版（2003-2004年）-19%X+2版（2004年）-25%见图4。 新概念他们认为增加的进度控制（执行/完成的测试用例百分比）和增加的交付精度（由于增加的进度控制和改进的质量保证）至少同样重要。4讨论4.1测试自动化的相关技术本节的目的是将部门的测试自动化工具所使用的技术与软件测试自动化行业中使用的其他技术联系起来。本文将介绍这些技术及其优缺点。但是，请注意，本节的主要目的是对工具进行基准测试，而不是进行技术评估。4.1.1捕获-重放捕获-重放的基本概念是工具记录测试人员手动执行的操作，例如鼠标点击和其他GUI事件（稍后可以自动重新执行）。捕获-重放工具使用简单[3]，但根据一些经验，这不是测试自动化的好方法，因为记录的测试用例很容易变得很难维护[9]，[16]，[17]，[21]。主要原因是它们与用户界面和配置的细节联系太紧密，例如，用户界面中的一个更改可能需要重新记录100个测试脚本[21]。4.1.2脚本技术测试自动化的一个强有力的方法是为测试用例编写某种测试脚本。脚本技术提供了一种用于创建测试用例的语言和执行它们的环境[20]。编写脚本的方法在几个方面有所不同：简单脚本与高度结构化的脚本：脚本的复杂性可能会有所不同，从简单的线性脚本到具有条件/循环功能的关键字驱动脚本，再到真正的编程语言[9]。标准脚本/语言与供应商脚本：脚本工具要么使用标准脚本编程语言（例如Visual Basic，C++），要么使用自己的专有语言（供应商脚本）[17]。测试控制流程和操作与数据驱动测试：这个选择是关于脚本还是输入数据控制执行。在数据驱动测试中，输入测试数据文件控制流程和操作[21]。L- O. Damm等人理论计算机科学电子笔记116（2005）313标准脚本与框架驱动测试：框架驱动测试不是直接针对产品接口进行操作，而是向测试工具添加了另一层功能，其想法是将软件与测试脚本隔离开来。框架提供了一个共享函数库，它成为工具语言中的基本命令4.1.3测试用例生成器测试用例生成器是最先进的测试自动化工具。它们有几种变体：结构生成器（从代码的结构生成测试用例）;数据流生成器（使用软件模块之间的数据流作为测试用例生成的基础）;函数生成器（从正式规范生成测试用例）;以及随机测试数据生成器[3]。测试用例生成器可以快速生成多个测试用例，但由于需要手动添加预期的结果，因此仍然不总是更具成本效益。此外，还必须手动检查生成的测试用例/测试用例的执行，以验证它们是否测试了正确的功能。4.2其他考虑在实施本文所描述的新概念之前，组织及其产品必须满足一些先决条件;否则，失败的风险很大。本节介绍与该部门的情况有关的一些先决条件。4.2.1组织的成熟度首先，开发人员遵循的开发流程需要足够成熟。如果过程很差，测试自动化将不会有帮助[9]，[17]。最好是，测试自动化引擎应该容易适应当前的实践;如果变化太大，开发人员之间的阻力风险就会增加[15]。此外，如果开发人员不想按照指示工作，他们就不会[13]。在该部门，开发人员意识到忽略基本测试会导致验证交付周期增加[7]。所以，对于基础测试，他们是持开放态度的。其次，管理者必须致力于新方法，因为正是他们必须承担引入测试自动化的前期成本（这很可能会对短期预算和截止日期产生负面影响[4]）。测试工具成本只是冰山一角[9]，[17]。4.2.2产品成熟度（可测试性）具有高可测试性的产品提供易于开发测试用例的接口，对更改具有鲁棒性，并且其数据易于在测试用例中表示，以及测试执行工具可以自动验证接收到软件的可测试性越强，那么软件开发人员和测试人员就越不需要定位缺陷[20]。比如说14L- O. Damm等人理论计算机科学电子笔记116（2005）3当产品有一个通用的通信接口来模拟时，基本测试工具的构建成本要低得多。5结论爱立信部门引入了一种新的测试自动化工具，该工具与测试驱动开发（TDD）的替代方法相结合，即组件级别上的TDD，其中接口包括交换XML数据的套接字连接，通过这种测试驱动开发的方法，健壮和统一的组件接口使测试自动化更容易。该工具的主要特点是它使用C++，与开发人员编写产品代码相同的标准编程语言，因为开发人员已经熟悉它，它比脚本语言更强大，并且开发人员可以利用现有的编程工具（例如编译器和调试器）。关于过程支持，软件开发部门引入TDD概念来支持该工具，主要是因为：• 当在代码之前编写测试用例时，测试就真正发生了。• 测试用例驱动设计并使其更直接，即具有明确的范围并且没有镀金。• TDD在开发过程中更早地进行故障检测，因为发现故障的成本更低。在实现测试自动化和TDD时，有几个方面需要考虑。第3.4节列出了最重要的问题（以观察和经验教训的形式）。使用过这个概念的开发人员估计，对于每个使用它的新项目版本，项目交付周期将越来越短（见3.5节）。此外，初步项目评估表明，引入新概念后，故障率显著降低引用[1] K. Beck，87比89[2] K. Beck，Test Driven Development[3] B.陈文辉，软件测试技术，第二版，北京，高等教育出版社，1990.[4] M. Berwick，“优化开发和测试过程”，Kelly，M.：软件质量的管理与度量，UNICOMSEMINARS，Middlesex，UK，1993，pp. 51比64[5] B. W. Boehm，软件工程经济学，Prentice-Hall，1981。[6] A. Cockburn，敏捷软件开发，Addison-Wesley，2002年。L- O. Damm等人理论计算机科学电子笔记116（2005）315[7] L-O张文，软件工程和计算机科学，2002年6月，MSE-2002-15， pp. 六十[8] M. Fewster，“使用内部测试工具进行自动化测试：案例历史”，Kelly，M.：软件质量的管理与度量，UNICOM SEMINARS，Middlesex，UK，1993，pp.193-204.[9] M. Fewster，D. 软件测试自动化，北京，2000。[10] B. Hambling，“现实和成本效益软件测试”，Kelly，M.：软件质量的管理与度量，UNICOMSEMINARS，Middlesex，UK，1993，pp. 95比112[11] M. J. Harrold，61比72[12] L.G. Hayes，自动化测试手册，软件测试协会，1995。[13] W.S. Humphrey，Winning with Software，Addison-Wesley，2002年。[14] D. Ince，“关于质量保证的一些问题”，载于Kelly，M.： 软件质量的管理与度量，UNICOMSEMINARS，Middlesex，UK，1993，pp.9比18[15] A. K. Johnston，“给鳄鱼戴上嘴套：一种务实的质量方法”，载于Kelly，M.：软件质量的管理与度量，UNICOM SEMINARS，Middlesex，UK，1993，pp.19比30[16] C.陈文辉，114比116[17] C. Kaner，J. Bach，and B.陈文，《软件测试中的经验教训》，北京，2002年。[18] A. Kehlenbeck，“评论：自动化测试工具没有实现质量承诺.《软件杂志》，Proquest，1997年[19] E. M. Maximilien 和 L. Williams ， “Assessing Test-Driven Development at IBM” ， SoftwareEngineering：Proceedings. 第25届国际会议，IEEE，2003年，pp。564-569[20] J. McGregor，卡内基梅隆大学，软件工程学院，2001年12月[21] D. J. Mosley和B.A. Posey，Just Enough Software Test Automation，Prentice Hall，2002。[22] R. Patton，Software Testing，Sams Publishing，2001。[23] S. R. Rakitin，从业者和管理者的软件验证和确认，第二版，Artech House，2001年。