计算机外文翻译--测试多态关系的准则.doc

测试多态关系的准则Roger T. Alexander and A. Jefferson OffuttGeorge Mason UniversityDepartment of Information and Software EngineeringSoftware Engineering Research LaboratoryFairfax, Virginia 22030-4444ralexand,ofut 11th International Symposium on Software Reliability Engineering (ISSRE 00), pages 1523, San Jose CA, October2000.摘 要面向对象的程序的重点在于定义同时具有状态和行为的抽象。这种重视会导致软件单元的软件组件的连接方式的重心。因此，我们发现，我们需要较少强调单元测试和更多的集成测试。继承的组成关系和聚集，特别是当与多态相结合，引进新品种集成故障。本文从一个正在进行的研究项目提出结果，具有提高面向对象软件的质量目标。新的测试标准介绍，采取继承和多态性的影响考虑在内。这些标准是基于类似程序之间数据流分析的新分析技术。这些测试标准可以通过确保集成测试是高品质的提高面向对象软件的质量。1. 介 绍在面向对象的语言强调的是定义抽象（如抽象数据类型）该模型的各个方面 的问题18。这些抽象的实现为同时具有状态和行为的用户自定义类型。虽然抽象数据类型可以帮助实现更高质量的设计，但是它们的使用也可能会影响软件测试。一个主要因素是，从面向过程到面向对象的软件转移经常变化的复杂性。复杂性是在程序如何和部件相连接，而不是那些复杂的控制结构的程序，面向对象的软件往往有简单的程序。因此，测试人员发现，单元测试和更多的集成测试需要较少的强调。在面向对象的语言7中发现的关系固有的复杂性也影响测试。继承和聚合的组成关系，结合多态性的力量，可以使它更难被侦测到故障元件集成的方式。这是因为组件的集成是不同的面向对象的语言6。其中在本文所讨论的语言类型的主要区别是在用于抽象的机制。面向过程的语言使用过程和函数作为其主要的抽象机制，而面向对象的语言使用数据抽象。此外，面向对象的语言使用的继承和多态（动态绑定）的整合机制，这两者都可以强烈地影响组件的集成。继承不同于聚合，一个新的类型都可以访问的祖先类型的内部表示。当一个呼叫是由一个多态的方法形成，它执行的版本取决于物体的类型18。因此，继承和多态提供两种形式的整合是当测试对象必须处理时，这两者有一个面向过程的对应。本文提出了一个正在进行中的具有改善面向对象软件的质量目标的研究项目的结果。先前的文献 1 提出了技术分析的面向对象软件的继承和多态的关系。本文提出了一种解决方案，在集成组件之间的多态关系发现错误的问题。该解决方案的总体策略是定义新的覆盖准则，这将允许测试在集成度程序方面加以形式化。测试充分性准则是重要的，原因有几个。通常情况下，当面对测试程序，开发人员不知道要测试什么或在哪里开始。首先，正规的标准有助于这种情况下通过提供用于指定测试要求的基础。反过来，测试要求通过提供一个清晰的要检验什么的描述来指导测试过程。这提供了一种机制，用于决定何时停止测试和可重复性的测试工作的基础。其次，正规的标准给测试人员提供一些方式来决定在测试过程中使用何种测试输入，使测试仪更容易发现故障的程序，并提供更可靠的保证软件的高品质和可靠性。1.1 测试面向对象软件程序单元是一个过程，函数或方法。一个模块是相关单位的集合，例如，一个C文件，一个Ada包，或Java class.Unit。模块测试（或只是单元测试）是程序单元和独立于其余软件测试的模块。集成测试是指测试接口单元和模块之间，以确保他们有一致的假设和正确的沟通4。这相对于系统的测试，其中的目的是测试整个系统集成为一个整体。因为强调测试接口，集成测试通常需要源代码的可用性白盒测试活动。与此相反，系统测试通常需要假定的情况下的源代码，因此通常是黑盒。请注意，虽然本文中遵循标准IEEE定义15，这两种术语在实践中通常可以互换使用。测试要求是必须满足或覆盖的特定的事情，例如，达到语句是语句覆盖的要求。测试标准是强加在一组测试用例要求的规则或规则的集合。测试工程师测量的程度的标准是满足要求的百分比的覆盖率。测试实际上是包括数块。一个测试用例值直接满足一个或一个以上的测试要求。如果软件正确执行，预期输出是测试的结果。测试的其余部分包括任何其他的对于软件是必要的获得由测试用例值所需的状态，并导致显示或打印的实际输出的投入。本文介绍了用于测试面向对象软件的新标准。首先，给出了一些背景的定义，并引入了一些新的术语。然后是测试标准的定义。最后提供的是我们目前的状态和这个研究项目的未来计划。2. 背 景在本文提出的测试标准是部分基于先前定义的面向过程的程序来使用的继承和多态语言的标准。因此，给出了继承和多态的简要概述，并描述了以耦合为基础的测试的概念。连接序列则完全是总结在以前的文件中定义的概念1。2.1 继承和多态面向对象编程的基本构建块是类，它是用来定义新的类型。类封装了状态变量的集合状态信息和有关于这些状态变量操作方法的集合。一个类定义了一个用于创建对象（实例）的类型。聚合和继承，可以用来组成类的类型，形成新的类型。聚合是一种类型含有另一种类型的情况的传统的机制。继承允许一种类型的表示定义在一组其它类型的表示中，发生这种情况时，被定义的类型都将继承其祖先的属性（方法和变量）。多态性允许变量按照继承层次结构具有不同的类型。动态绑定允许相同的语句来执行不同的方法体，执行哪一个取决于使用方法调用的对象的当前类型。继承和多态使面向对象软件的测试复杂化。一类家族是一组关于一个基类C（家族（C）都有一个共同的行为的类。C的各后代是C家族的一个部件D。如果D在C的家庭，多态性是指D的任何实例可以自由用于任何C的实例中。每个C类定义了一个类型的家庭，该类型的家庭至少包括C。2.2 耦合和基于耦合的测试在本文中介绍的标准是基于金，Offutt16以前的基于数据流测试11的工作。他们提出一种方法，是基于面向过程的软件中的程序耦合关系的集成测试。耦合最初是衡量设计9，19，及原来的文件提出了十二个不同类型联轴器的名单被定制了严重的条款。对于测试，只有三个无序类型被使用：参数耦合，共享数据耦合和外部设备连接。每当一个过程参数传递到另一个参数时耦合发生。当两个程序引用同一个外地变量共享数据时耦合发生。当两个程序访问相同的外部存储时外部设备接头发生。Jin和Offutt的方法要求程序执行的变量定义调用方调用站点，然后在调用程序对应的形参的使用。一个定义是赋值给一个变量或其它运算结果的变量得到一个新的值。访问一个变量的值时，将出现使用。从定义中使用的执行路径必须是清晰，明确的，那就是，变量不能沿路径重新定义。其基本思想是，有高度的信心所产生的软件，所有的在一个过程变量的定义必须在调用程序被正确地使用。这种方法被称为基于耦合的测试（CBT）。下面的定义是从原来的耦合定义 16 ，在那里Jin和Offutt更正式的定义。VP是由程序组件引用的变量的集合P，NP是在P的控制流图的节点集。P1和P2是程序单元，X和Y是程序变量。从节点i到j的路径是清晰，明确的关于x，如果存在x的路径上没有定义，除了可能在结点i。一个调用点是一个节点iNP1，包含一个呼叫从P1到P2。如果有一个定义清晰的路径，从i到j关于x，我们说x在我的定义中可以达到j。节点iNP1是一个耦合，包含一个定义，可以对一些执行路径使用P2。一个耦合的使用是一个节点iNP2，包含一个使用，可以通过在另一个单元的定义在至少一个执行路径。两个程序单元之间的耦合路径是开始在调用单元中的一个变量的定义，并结束在被称为一个单位使用的路径。这包括涉及参数的耦合，共享数据耦合和外部耦合路径。需要注意的是，该定义必须有一个定义清晰的路径，以通过调用相应的用途。通过使用这些定义，四耦合为基础的测试标准的定义 16 。P1和P2是一个系统的程序单元：l 呼叫耦合：该组由测试集执行路径必须包括在该软件的所有调用点。l 全耦合定义：对可变的P1每个耦合定义，该组由一个测试集执行路径必须覆盖至少一个联接路径中的至少一个可到达的耦合使用。l 全耦合使用：对可变的P1每个耦合定义，该组由一个测试集执行路径必须覆盖至少一个耦合路径的每个可到达的耦合使用。l 全耦合路径：测试执行的设置必须覆盖从耦合定义所有的耦合路径集所有可达耦合使用。耦合路径集是一组可以出现在子路径通过一个耦合的定义和使用之间的程序单元的节点。这解释了其中程序单元具有环路的情况。要求所有耦合路径覆盖一般是不现实的。然而，它涵盖了所有耦合路径组确保每个循环体至少被执行一次，但不要求所有可能的执行。2.3 耦合序列虽然面向对象的设计和编程的激励目标之一是减少软件组件之间的耦合量，新的语言功能也引入组件耦合的新途径。为了处理这些接头中的分析技术，先前被引入一个偶联序列的想法1。直观地说，一个耦合序列代表被测命令的集成对象O的方法之间的相互作用。我们的目标是不需要确定是否O是正确的，而是要确定M是否正确使用O。耦合序列代表在M的文本中的故障很可能伴随O发生。帧内方法耦合序列通过对某个特定方法的上下文中提出的方法调用定义，被称为耦合方法。当一个方法M是通过一个对象O调用，我们说M在被O所提供的实例的上下文中执行，是指以红色作为上下文变量。一个内部方法耦合序列的两个方法调用都是通过同一个上下文变量，因此，它们都有一个共同的上下文实例。此外，存在两种方法调用是定义清晰的相对于该上下文变量和到由第一种方法中定义和第二种使用的至少一个状态变量之间的至少一条路径。这样的路径被称为耦合路径。帧内方法耦合序列类似于定义使用对2，并用于与一个状态变量的定义，以跨越一个程序边界在一个特定的对象和方法的上下文中的相应用途。从表面上看，它可能出现测试这样的一个足够的测试类的对象的路径。然而，它不是正被测试的类，而是利用了对象和相应的方法的方法。帧内方法耦合序列的一个例子示于图1。方法F是耦合方法，包含一个单一的耦合序列，Sj,k，即在节点j的开始，帧内方法耦合的序列（以下统称为耦合序列）和帧间方法耦合序列留到以后的工作。图1 耦合序列的例子Sj,k一种耦合序列Sj,k被定义为与一组由先前方法中定义和使用的方法，由此产生的状态变量。这组变量被称为耦合集Sj,k，Sj,k和这组的每个成员都是一个耦合变量。耦合序列Sj,k的设置如图1所示是：Sj,k = class(o):v其中类（O）是上下文变量邻声明的类型。Sj,k包含到O中引用的状态变量是由先前方法中定义和使用在耦合序列Sj,k随之而来的方法。Sj,k开始在具有特定耦合变量的定义，最后在先前方法的节点，并结束在有相应的同一耦合变量的第一个使用随之而来的方法节点的耦合路径。1请注意，对于一个给定的耦合序列，即通过先行或随之而来的节点上执行一个调用的结果的方法取决于该序列的上下文变量绑定到该实例的类型。如果上下文变量是类型T的，任何类是T的类型家族的成员的任何实例可以被绑定到上下文变量。1一个变量v的最后一个定义是一个节点n沿的方法，其中n是定义v之前的方法的出口节点的最后一个节点的一些路径。类似地，第一次使用的V是第一个节点n沿开头的入口节点的方法，例如，有使用v该用途的n之前没有其他节点的一些路径。3. 耦合条件本文定义了四个面向对象的耦合原则进行集成测试。测试标准可以通过以下两种方式之一来使用，作为一种机制，以帮助测试人员机械或手工生成的测试（测试生成），或测量的预先存在的测试（覆盖分析）的质量。这项工作目前假定的标准将被用作覆盖分析器，也就是说，一组测试已经存在。机械或测试数据自动生成的问题不是当前研究的一部分。当使用测试标准，它假定在该耦合序列的方法之前，前提和后果的方法已被单独测试。这使得开发人员假定任何发现的故障是与接口相关的。3.1 准过程间分析这些标准的一个重要组成部分是，程序间的数据关系的一些知识必须从程序中导出。然而，Harrold 和 Soffa的过程间数据流测试12，关于数据的完整信息单元之间流动是没有必要的。对于本研究中，数据有必要从流定义信息来调用站点，从调用点的用途，从入口节点到用途，以及从定义到结束节点。然而，这是需要整个过程调用的唯一信息是关于参数传递的信息（即实际参数被传递给形参）。这就避免了多程序间的数据流分析的费用。那是因为需要过程间的信息有限，我们称这种准过程间分析。可能该分析的信息可以被用来解决在软件工程中的其他问题。3.2 四耦合原则该标准是全耦合序列，全聚类，全耦合定义用途，以及全聚耦合定义用途。在下面的小节，Tsj,k代表组测试用例耦合序列Sj,k。3.2.1 全耦合序列.它可以说是集成测试，至少在每一个耦合序列中每一个类的每一个方法应该被包括在内。这里，覆盖面意味着每个偶联序列被至少执行一个测试用例。因此，全耦合序列要求每个耦合序列所涵盖的至少一个测试用例。定义1 全耦合序列：在方法F的每个耦合序列Sj,k，有至少一个测试用例Tsj,k使得当采用t执行f有在Sj,k即f的执行跟踪的一个子路径的耦合路径的路径p。3.2.2 全聚类.全聚类标准，加强全耦合序列要考虑继承和多态。这是对于每一个类通过确保至少有一个测试，可以为每个耦合序列来实现提供一个实例的上下文。这个想法是，耦合序列应与可能发生在给定的上下文中耦合每一个可能的类型替代测试。全聚类的标准要求，对于在方法F中的耦合序列Sj,k，并且在每个类中的c由Sj,k的上下文中定义的类型家族中，至少有一个测试，涵盖c和Sj,k的每一个可行的组合适用于F。组合（C，Sj,k）是可行的，当且仅当c是和上下文变量的Sj,k相同的声明的类型，或c是声明类型的孩子，它定义了一个重写方法为先前的或由此产生的方法。因此，被认为是唯一的类重写的前提和随之而来的方法。定义2 全耦合类：在方法F的每个耦合序列Sj,k，并且在每个类中的由Sj,k的上下文中定义的类型的家族中，有至少一个测试用例t，使得当采用t执行f有一个路径p中耦合Sj,k是f的跟踪的子路径的路径。3.2.3 全耦合定义用途.标准全耦合定义用途需要定义和变量的用途考虑在内。它需要的是，对于在方法F中的耦合序列，并且在每个耦合变量v的序列中，必须有至少一个相对于v执行每个耦合路径测试用例。那就是，每一个可行的耦合路径的每个耦合的定义和V耦合对之间必须至少有一个测试用例执行。定义3 全耦合定义用途：在每一个序列的方法耦合Sj,k，并为该每一耦合变量V和每个节点在该含V最后定义的先前的方法，至少有一个测试用例等，当F是执行使用T，有一个耦合路径P在微量的F开始，并且到达在Sj,k的随之而来的方法，该方法具有第一利用V的一个节点。3.2.4 全聚耦合定义用途.除了继承和多态，标准全聚耦合定义用途需要的定义的影响，并采用考虑。全聚偶合定义用途要求执行所有耦合路径为通过耦合序列的上下文中定义的类型的每个家庭成员。定义4 全聚耦合定义用途：在方法F中的任意耦合序列Sj,k，并为每类由Sj,k的上下文中定义的类型的家族中，并为Sj,k的每一个耦合变量v和每个节点n中的最后一个定义具有第一个节点m使用的变量v有至少一个测试用例T，使得当采用T执行f有在Sj,k的耦合路径是f的迹的子路径一个路径p。3.3 标准的包容上述标准强加于测试过程中有一定的要求，并且每个是在一个特定的成本。比较测试标准的常用方法是包容关系11，16。标准A涵括标准B当且仅当满足A也每一个测试集满足B。虽然有一定的异常，常见的假设是，在更高层次的包容层次结构的标准有更多的测试功耗，成本较高。这个问题对于测试人员，那么，以确定哪些标准来选择一个特定的情况。图2描述了本文所提出的标准的包容层次结构。图2 面向对象耦合测试的归入层次3.4 准过程间分析注释困难之一，随着这种分析产生是由有变量动态绑定到不同的类型，从而允许多态实例的能力带来的。没有动态绑定，方法之间的数据流关系是静态的，可以在被执行之前知道。但当动态绑定是可能的，多态性效果可以在不同的方法是通过相同的调用站点上执行时，这取决于当前绑定到该变量的实例的实际类型。要理解这一点，考虑图3（a）所示的UML类图（一）。如图所示，A类包括法计算命令n随着状态变量u和v。同样，B类包括方法n和l及状态变量w。最后，C类包括方法命令状态变量v。需要注意的是B : n覆盖方法A : n，和C: m替代方法A : m。2 现在考虑的方法F的定义，并通过在图3（b）所示的源代码段中所描绘的耦合序列S3,5所示。首先观察有f需要被声明为类型A的形式参数o。继承允许o到被绑定到一个对象，其实际类型为A，B或C。现在考虑的调用位置在语句3和5。在这里，明显的调用方法A: m和A: n制成。然而，由于动态绑定和多态性的方法，实际上是被称为依赖型T，实例的束缚。当T是A，则实际调用是到A: m和A: n。然而，当T是B，那么实际调用不是A: n，A: n而是A: m。同样，当T是C，实际调用是到C: m和B:n。了解动态绑定和多态性可能对方法之间的数据流关系的影响，考虑表中，如图3（c）所示，其中总结了在图3（a）该方法的定义和用途所示。方法A: M定义状态变量A : u和A : v及方式A: n使用A:V。从数据流的角度看，当o的类型是A和这些方法被执行是没有问题，如图3（b）所示。同样，B:n使用A : u。也是没有问题的，当o的类型为B，因为A : u通过调用已在声明中的语句3定义了。但考虑其中o的类型为C的情况，方式C: m定义了一个A : v，但不是A : u。在声明中调用三个结果在C运行C: m，这反过来又定义了A: v，但不是A : u。后来，当调用语句5，B : n被执行，它使用C:u。图3 例如类层次结构与重写方法有一个潜在的问题，数据流异常，因为显然A : u不使用前面的定义。看来，执行C:m违反了关于A:u由B:n的假设。问题的唯一可能，是因为它可能是A:u通过先前的方法调用或作为建造绑定到O的实例的一部分来定义。动态绑定多态性的结果，因为前面的讨论说明，是一个面向对象的程序的数据流图可以动态变化。虽然这极大地复杂的分析，可能类型的对象的数量是有限的，并且通常是小的。困难之处在于，有一个必须被考虑为给定的方法，这取决于动态绑定的存在，并可能发生的可能的多态性的多个图形表示。我们做了详尽的分析，计算所有可能的解决这个问题的耦合数据流。上面的讨论引发了另一个问题，即不可行帧内法耦合序列。帧内方法耦合序列是不可行的，如果没有输入，可以执行该序列。这是测试的一个问题，因为不可行耦合序列产生的测试需求无法得到满足。此外，它是非常困难的，以确定耦合序列是否是不可行的，或者如果它仅仅是很难找到合适的测试用例。不可行耦合序列的问题是一个比较普遍的问题一个特定的实例，通常被称为可行路径问题，它说，对于某些结构试验标准的一些测试要求是不可行的，即程序的语义意味着没有测试用例满足测试要求。等效突变体，在路径测试技术不到的语句，和不可行DU-双数据流测试是可行的路径问题的所有实例。虽然技术已被开发，它可以识别在大多数情况下用于突变检测，传统的数据流测试，和路径的测试技术20是不可行的路径，该问题一般是不可判定。我们还没有解决这个问题，在不可行耦合序列的上下文中，虽然人们希望通过Offutt 和 Pan20开发的技术可以应用到这种情况下也是如此。另一个问题，就是与该类型是可行的特定连接顺序。A型Tis认为是可行的，如果耦合序列的上下文变量可以经常被绑定到一个实例，其中Tis无论是声明的类型的上下文变量，或声明的类型的后裔。在某些情况下，这是微不足道的。例如，在耦合方法F（如图3（b）所示），上下文变量o耦合序列S3,5的传递作为一个正式的说法了。为改变o，测试驱动程序只需要调用f传递不同类型的实例的实际参数。但是，如果o是代替A，是由它绑定到一个方法调用g的返回值，改变实例的类型初始化的局部变量将是极其困难的，目前超出了我们目前的研究范围之内。2在C +作用域解析运算符:用于指示哪些方法和状态变量都被提及。4. 相关工作有许多特有的面向对象软件测试的问题。一些研究人员宣称，一些传统的检测技术不能有效的面向对象软件5，10，14。方法在面向对象的软件常用的方式意味着许多传统的软件测试技术测试错误的东西。具体而言，方法往往较小和较不复杂的，所以基于路径的测试技术是不太适用的。此外，继承和多态引入不可判定的软件3。执行路径不再是类的静态声明的类型的函数，但就是不知道，直到运行时的动态类型的函数。在他的博士论文，Overbeck提出了一种基于客户端和服务器类22中的测试合同的方法。合同规定在一个类中的每个公共方法的前提条件和后置条件。类之间的相互作用进行测试，以确保客户正确使用类，及从方法返回的结果是由客户端的理解。这是通过施加一个特殊的测试过滤器，它位于客户端和类之间映入方法调用的类来完成。过滤器进行检查，以确定是否其中一种方法是正确的类型和值，则该方法被调用以正确的顺序，而且如果所调用的方法的前提是真实的。如果这些检查都通过了，呼叫将被传递给类进行处理。否则，会报告错误和引发异常。这种技术并不能帮助创建测试用例，并且依赖于书面的程序员的正式规格。Jorgensen 和 Erickson17描述了一种方法，集成测试，类似于许多黑盒测试技术。他们通过，形成了系统类的集合定义路径。每个路径与特定的输入事件相关联，并且横穿参与该系统的响应的类。该路径包括通过方法调用遍历所有的类，并结束当系统输出已被观察到。检测到故障时，系统输出不期望的输出相匹配。故障确定回溯路径上的每个参与者。再次，有创建测试用例没有帮助。Harrold 和Rothermel描述了适用于数据流分析，以类的方法13。他们的方法强调三个层次的测试：（1）帧内法测试;（2）跨法检测;（3）内部类测试。为了进行这些分析，Harrold 和Rothermel代表了一类作为一类控制流图（CCFG）由单个进入和退出的。本文不介绍如何在测试过程中使用此信息。Chen 和 Kao介绍一种方法，称为对象流测试测试面向对象的程序8。在他们的方法，他们试图要找出和测试，可以发生在方法中可能的对象绑定。我们的想法是确定的定义使用对方法内发生的之间的方法，是从相同的调用者调用对。他们定义的施加方法测试要求两个标准。第一，全绑定，要求每个对象的每个可能的结合可以至少被执行一次，并且进一步结合所有可能的组合，当表达式包含多个对象进行测试。这个标准类似于我们全聚类标准。他们的第二个标准，所有的都对，要求每一个定义明确的路径的一个对象，该对象至少测试一次每使用一个定义之间。这类似于全耦合定义用途。这里定义的标准主要是分层的，既考虑到细，之间的集成对象和方法，它应该允许更严格的测试粗粒度的相互作用。Orso 和 Silva目前专注于通过识别包含测试（MUT）21的方法中的多态方法调用路径测试多态的定义和用途的技术。这项工作还认为，可能发生一个给定的对象引用可能的绑定。然而，这种方法的重点是起因于多态调用中MUT的效果。我们的方法考虑这一点，同时也相当重视对测试所造成的MUT内进行方法调用之间发生的相互作用。这不仅对MUT有影响，也影响的MUT的执行顺序对对象，它通过方法调用使用。5. 结论和未来工作本文介绍了面向对象软件的新的集成测试技术。四个不同的标准被提出，可以帮助测试人员评估基于继承和多态的软件组件之间的连接。这些标准依赖于一种新的类型的程序分析，准间分析。集成测试的这个水平是一个重要而困难的问题区域，面向对象的开发人员，因为采用面向对象的设计往往意味着重要的设计决策进行编码的互连组件之间，并且继承和多态的抽象机制可能会导致在非常复杂并且容易出错的关系。本研究针对开发形式化的，可衡量的标准，从面向对象软件测试产生的问题。这些条件依赖于源代码的详细分析，并且可以被用来生成集成测试用于面向对象的软件，它是在检测中的软件组件之间的连接设计和编程错误有效。目前我们正在建设的概念证明的覆盖分析工具来支持这种技术。这个工具是美国普渡大学的Tao 和 Palsberg 用Java构建，测试Java程序，并且是基于一般的Java解析器生成的JavaCC和Java树构建器（JTB）3。该工具目前解析Java程序，并生成多种图表分析。目前，我们正在设计技术，仪器的测试程序来判断测试是否满足在本文提出的测试标准。该工具将被用于提供该技术的有效性的证据。本文是一个正在进行的项目，提供面向对象的软件开发与集成测试更好的工具和技术的一部分。这最终将导致软件，可建更便宜，更可靠。3 JTB可以从网上下载，/jtb/index.html。参考文献1 Roger T. Alexander and A. Jefferson Offutt. Analysis techniques for testing polymorphic relationships. In Thirtieth International Conference on Technology of Object-Oriented Languages and Systems (TOOLS30), pages 104114, Santa Barbara, CA, 1999.2 F. E. Allen and J. Cocke. A program data flow analysis procedure. Communications of the ACM, 19(3):137146, March 1976.3 Stephane Barbey and Alfred Strohmeier. The problematics of testing object-oriented software. InSQM94 Second Conference on Software Quality Management, volume 2, pages 411426, Edinburgh, Scotland, UK, 1994.4 Boris Beizer. Software Testing Techniques. Van Nostrand Reinhold, New York, New York, 2nd edition, 1990.5 Edward Berard. Issues in the testing of object-oriented software. In Electro94 International, pages 211219. IEEE Computer Society Press, 1994.6 Edward V. Berard.Essays on Object-Oriented Software Engineering, volume 1. Prentice Hall, 1993.7 Robert V. Binder. Testing object-oriented software: A survey. Journal of Software Testing, Verification & Reliability, 6(3/4):125252, September/December 1996.8 Mei-Hwa Chen and Ming-Hung Kao. Testing object-oriented programs - an integrated approach. In10th International Symposium on Software Reliability Engineering (ISSRE99), pages 7383, Boca Raton, FL, November 1999. IEEE Computer Society.9 L. L. Constantine and E. Yourdon.Structured Design. Prentice-Hall, Englewood Cliffs, NJ, 1979.10 Donald G. Firesmith. Testing object-oriented software. InEleventh International Conference on Technology of Object-Oriented Languages and Systems (TOOLS USA, 93), pages 407426. PrenticeHall, Englewood Cliffs, New Jersey, 1993.11 P. G. Frankl and E. J. Weyuker. An applicable family of data flow testing criteria. IEEE Transactions on Software Engineering, 14(10):14831498, October 1988.12 M. J. Harrold and M. L. Soffa. Selecting and using data for integration testing. IEEE Software, 8(2):5865, March 1991.13 Mary Jean Harrold and Gregg Rothermel. Performing data flow testing on classes. InSecond ACM SIGSOFT Symposiumon Foundations of Software Engineering, pages 154163. ACM Press, New York, New York, 1994.14 Jane Huff