1、天津科技大学本科生毕业设计（论文）外文资料翻译专 业：软件工程学 号：10103134姓 名：张慧云指导老师姓名：赵青天津科技大学外文资料翻译1测试多态关系的准则Roger T. Alexander and A. Jefferson OffuttGeorge Mason UniversityDepartment of Information and Software EngineeringSoftware Engineering Research LaboratoryFairfax, Virginia 22030-4444ralexand,ofut gmu.edu11th Internatio
2、nal Symposium on Software Reliability Engineering (ISSRE 00), pages 1523, San Jose CA, October2000.摘 要面向对象的程序的重点在于定义同时具有状态和行为的抽象。这种重视会导致软件单元的软件组件的连接方式的重心。因此，我们发现，我们需要较少强调单元测试和更多的集成测试。继承的组成关系和聚集，特别是当与多态相结合，引进新品种集成故障。本文从一个正在进行的研究项目提出结果，具有提高面向对象软件的质量目标。新的测试标准介绍，采取继承和多态性的影响考虑在内。这些标准是基于类似程序之间数据流分析的新分析技术。
3、这些测试标准可以通过确保集成测试是高品质的提高面向对象软件的质量。1. 介 绍在面向对象的语言强调的是定义抽象（如抽象数据类型）该模型的各个方面 的问题18。这些抽象的实现为同时具有状态和行为的用户自定义类型。虽然抽象数据类型可以帮助实现更高质量的设计，但是它们的使用也可能会影响软件测试。一个主要因素是，从面向过程到面向对象的软件转移经常变化的复杂性。复杂性是在程序如何和部件相连接，而不是那些复杂的控制结构的程序，面向对象的软件往往有简单的程序。因此，测试人员发现，单元测试和更多的集成测试需要较少的强调。在面向对象的语言7中发现的关系固有的复杂性也影响测试。继承和聚合的组成关系，结合多态性的力
4、量，可以使它更难被侦测到故障元件集成的方式。这是因为组件的集成是不同的面向对象的语言6。其中在本文所讨论的语言类型的主要区别是在用于抽象的机制。面向过程的语言使用过程和函数作为其主要的抽象机制，而面向对象的语言使用数据抽象。此外，面向对象的语言使用的继承和多态（动态绑定）的整合机制，这两者都可以强烈地影响组件的集成。继承不同于聚合，一个新的类型都可以访问的祖先类型的内部表示。当一个呼叫是由一个多态的方法形成，它执行的版本天津科技大学外文资料翻译2取决于物体的类型18 。因此，继承和多态提供两种形式的整合是当测试对象必须处理时，这两者有一个面向过程的对应。本文提出了一个正在进行中的具有改善面向对
5、象软件的质量目标的研究项目的结果。先前的文献 1 提出了技术分析的面向对象软件的继承和多态的关系。本文提出了一种解决方案，在集成组件之间的多态关系发现错误的问题。该解决方案的总体策略是定义新的覆盖准则，这将允许测试在集成度程序方面加以形式化。测试充分性准则是重要的，原因有几个。通常情况下，当面对测试程序，开发人员不知道要测试什么或在哪里开始。首先，正规的标准有助于这种情况下通过提供用于指定测试要求的基础。反过来，测试要求通过提供一个清晰的要检验什么的描述来指导测试过程。这提供了一种机制，用于决定何时停止测试和可重复性的测试工作的基础。其次，正规的标准给测试人员提供一些方式来决定在测试过程中使用
6、何种测试输入，使测试仪更容易发现故障的程序，并提供更可靠的保证软件的高品质和可靠性。1.1 测试面向对象软件程序单元是一个过程，函数或方法。一个模块是相关单位的集合，例如，一个 C 文件，一个 Ada 包，或 Java class.Unit。模块测试（或只是单元测试）是程序单元和独立于其余软件测试的模块。集成测试是指测试接口单元和模块之间，以确保他们有一致的假设和正确的沟通4。这相对于系统的测试，其中的目的是测试整个系统集成为一个整体。因为强调测试接口，集成测试通常需要源代码的可用性白盒测试活动。与此相反，系统测试通常需要假定的情况下的源代码，因此通常是黑盒。请注意，虽然本文中遵循标准 IEE
7、E 定义15，这两种术语在实践中通常可以互换使用。测试要求是必须满足或覆盖的特定的事情，例如，达到语句是语句覆盖的要求。测试标准是强加在一组测试用例要求的规则或规则的集合。测试工程师测量的程度的标准是满足要求的百分比的覆盖率。测试实际上是包括数块。一个测试用例值直接满足一个或一个以上的测试要求。如果软件正确执行，预期输出是测试的结果。测试的其余部分包括任何其他的对于软件是必要的获得由测试用例值所需的状态，并导致显示或打印的实际输出的投入。本文介绍了用于测试面向对象软件的新标准。首先，给出了一些背景的定义，并引入了一些新的术语。然后是测试标准的定义。最后提供的是我们目前的状态和这个研究项目的未来
8、计划。2. 背 景在本文提出的测试标准是部分基于先前定义的面向过程的程序来使用的继承和多态语言的标准。因此，给出了继承和多态的简要概述，并描述了以耦合天津科技大学外文资料翻译3为基础的测试的概念。连接序列则完全是总结在以前的文件中定义的概念1。2.1 继承和多态面向对象编程的基本构建块是类，它是用来定义新的类型。类封装了状态变量的集合状态信息和有关于这些状态变量操作方法的集合。一个类定义了一个用于创建对象（实例）的类型。聚合和继承，可以用来组成类的类型，形成新的类型。聚合是一种类型含有另一种类型的情况的传统的机制。继承允许一种类型的表示定义在一组其它类型的表示中，发生这种情况时，被定义的类型都
9、将继承其祖先的属性（方法和变量） 。多态性允许变量按照继承层次结构具有不同的类型。动态绑定允许相同的语句来执行不同的方法体，执行哪一个取决于使用方法调用的对象的当前类型。继承和多态使面向对象软件的测试复杂化。一类家族是一组关于一个基类 C（家族（C） ）都有一个共同的行为的类。C 的各后代是 C 家族的一个部件 D。如果 D 在 C 的家庭，多态性是指 D 的任何实例可以自由用于任何 C 的实例中。每个 C 类定义了一个类型的家庭，该类型的家庭至少包括 C。2.2 耦合和基于耦合的测试在本文中介绍的标准是基于金，Offutt16以前的基于数据流测试11的工作。他们提出一种方法，是基于面向过程的
10、软件中的程序耦合关系的集成测试。耦合最初是衡量设计9，19，及原来的文件提出了十二个不同类型联轴器的名单被定制了严重的条款。对于测试，只有三个无序类型被使用：参数耦合，共享数据耦合和外部设备连接。每当一个过程参数传递到另一个参数时耦合发生。当两个程序引用同一个外地变量共享数据时耦合发生。当两个程序访问相同的外部存储时外部设备接头发生。Jin 和 Offutt 的方法要求程序执行的变量定义调用方调用站点，然后在调用程序对应的形参的使用。一个定义是赋值给一个变量或其它运算结果的变量得到一个新的值。访问一个变量的值时，将出现使用。从定义中使用的执行路径必须是清晰，明确的，那就是，变量不能沿路径重新定
11、义。其基本思想是，有高度的信心所产生的软件，所有的在一个过程变量的定义必须在调用程序被正确地使用。这种方法被称为基于耦合的测试（CBT ） 。下面的定义是从原来的耦合定义 16 ，在那里 Jin 和 Offutt 更正式的定义。VP 是由程序组件引用的变量的集合 P，NP 是在 P 的控制流图的节点集。P1 和P2 是程序单元， X 和 Y 是程序变量。天津科技大学外文资料翻译4从节点 i 到 j 的路径是清晰，明确的关于 x，如果存在 x 的路径上没有定义，除了可能在结点 i。一个调用点是一个节点 iNP1 ，包含一个呼叫从 P1 到 P2。如果有一个定义清晰的路径，从 i 到 j 关于 x
12、，我们说 x 在我的定义中可以达到j。节点 iNP1 是一个耦合，包含一个定义，可以对一些执行路径使用 P2。一个耦合的使用是一个节点 iNP2，包含一个使用，可以通过在另一个单元的定义在至少一个执行路径。两个程序单元之间的耦合路径是开始在调用单元中的一个变量的定义，并结束在被称为一个单位使用的路径。这包括涉及参数的耦合，共享数据耦合和外部耦合路径。需要注意的是，该定义必须有一个定义清晰的路径，以通过调用相应的用途。通过使用这些定义，四耦合为基础的测试标准的定义 16 。P1 和 P2 是一个系统的程序单元： 呼叫耦合：该组由测试集执行路径必须包括在该软件的所有调用点。 全耦合定义：对可变的
13、P1 每个耦合定义，该组由一个测试集执行路径必须覆盖至少一个联接路径中的至少一个可到达的耦合使用。 全耦合使用：对可变的 P1 每个耦合定义，该组由一个测试集执行路径必须覆盖至少一个耦合路径的每个可到达的耦合使用。 全耦合路径：测试执行的设置必须覆盖从耦合定义所有的耦合路径集所有可达耦合使用。耦合路径集是一组可以出现在子路径通过一个耦合的定义和使用之间的程序单元的节点。这解释了其中程序单元具有环路的情况。要求所有耦合路径覆盖一般是不现实的。然而，它涵盖了所有耦合路径组确保每个循环体至少被执行一次，但不要求所有可能的执行。2.3 耦合序列虽然面向对象的设计和编程的激励目标之一是减少软件组件之间的
14、耦合量，新的语言功能也引入组件耦合的新途径。为了处理这些接头中的分析技术，先前被引入一个偶联序列的想法1。直观地说，一个耦合序列代表被测命令的集成对象 O 的方法之间的相互作用。我们的目标是不需要确定是否 O 是正确的，而是要确定 M 是否正确使用 O。耦合序列代表在 M 的文本中的故障很可能伴随 O 发生。帧内方法耦合序列通过对某个特定方法的上下文中提出的方法调用定义，被称为耦合方法。当一个方法 M 是通过一个对象 O 调用，我们说 M 在被 O 所提供的实例的上下文中执行，是指以红色作为上下文变量。一个内部方法耦合序列的两个方法调用都是通过同一个上下文变量，因此，它们都有一个共同的上下文实
15、例。此外，存在两种方法调用是定义清晰的相对于该上下文变量和到天津科技大学外文资料翻译5由第一种方法中定义和第二种使用的至少一个状态变量之间的至少一条路径。这样的路径被称为耦合路径。帧内方法耦合序列类似于定义使用对2，并用于与一个状态变量的定义，以跨越一个程序边界在一个特定的对象和方法的上下文中的相应用途。从表面上看，它可能出现测试这样的一个足够的测试类的对象的路径。然而，它不是正被测试的类，而是利用了对象和相应的方法的方法。帧内方法耦合序列的一个例子示于图 1。方法 F 是耦合方法，包含一个单一的耦合序列，S j,k，即在节点 j 的开始，帧内方法耦合的序列（以下统称为耦合序列）和帧间方法耦合
16、序列留到以后的工作。图 1 耦合序列的例子 Sj,k一种耦合序列 Sj,k 被定义为与一组由先前方法中定义和使用的方法，由此产生的状态变量。这组变量被称为耦合集 Sj,k，S j,k 和这组的每个成员都是一个耦合变量。耦合序列 Sj,k 的设置如图 1 所示是：Sj,k = class(o):v其中类（O）是上下文变量邻声明的类型。Sj,k 包含到 O 中引用的状态变量是由先前方法中定义和使用在耦合序列 Sj,k 随之而来的方法。Sj,k 开始在具有特定耦合变量的定义，最后在先前方法的节点，并结束在有相应的同一耦合变量的第一个使用随之而来的方法节点的耦合路径。 1请注意，对于一个给定的耦合序列
17、，即通过先行或随之而来的节点上执行一个调用的结天津科技大学外文资料翻译6果的方法取决于该序列的上下文变量绑定到该实例的类型。如果上下文变量是类型 T的，任何类是 T的类型家族的成员的任何实例可以被绑定到上下文变量。1 一个变量 v的最后一个定义是一个节点 n沿的方法，其中 n是定义 v之前的方法的出口节点的最后一个节点的一些路径。类似地，第一次使用的 V是第一个节点 n沿开头的入口节点的方法，例如，有使用 v该用途的 n之前没有其他节点的一些路径。3. 耦合条件本文定义了四个面向对象的耦合原则进行集成测试。测试标准可以通过以下两种方式之一来使用，作为一种机制，以帮助测试人员机械或手工生成的测试
18、（测试生成） ，或测量的预先存在的测试（覆盖分析）的质量。这项工作目前假定的标准将被用作覆盖分析器，也就是说，一组测试已经存在。机械或测试数据自动生成的问题不是当前研究的一部分。当使用测试标准，它假定在该耦合序列的方法之前，前提和后果的方法已被单独测试。这使得开发人员假定任何发现的故障是与接口相关的。3.1 准过程间分析这些标准的一个重要组成部分是，程序间的数据关系的一些知识必须从程序中导出。然而，Harrold 和 Soffa 的过程间数据流测试12，关于数据的完整信息单元之间流动是没有必要的。对于本研究中，数据有必要从流定义信息来调用站点，从调用点的用途，从入口节点到用途，以及从定义到结束
19、节点。然而，这是需要整个过程调用的唯一信息是关于参数传递的信息（即实际参数被传递给形参） 。这就避免了多程序间的数据流分析的费用。那是因为需要过程间的信息有限，我们称这种准过程间分析。可能该分析的信息可以被用来解决在软件工程中的其他问题。3.2 四耦合原则该标准是全耦合序列，全聚类，全耦合定义用途，以及全聚耦合定义用途。在下面的小节，Tsj,k 代表组测试用例耦合序列 Sj,k。3.2.1 全耦合序列.它可以说是集成测试，至少在每一个耦合序列中每一个类的每一个方法应该被包括在内。这里，覆盖面意味着每个偶联序列被至少执行一个测试用例。因此，全耦合序列要求每个耦合序列所涵盖的至少一个测试用例。定义
20、 1 全耦合序列：在方法 F的每个耦合序列 Sj,k，有至少一个测试用例 Tsj,k使得当采用 t执行 f有在 Sj,k 即 f的执行跟踪的一个子路径的耦合路径的路径天津科技大学外文资料翻译7p。3.2.2 全聚类.全聚类标准，加强全耦合序列要考虑继承和多态。这是对于每一个类通过确保至少有一个测试，可以为每个耦合序列来实现提供一个实例的上下文。这个想法是，耦合序列应与可能发生在给定的上下文中耦合每一个可能的类型替代测试。全聚类的标准要求，对于在方法 F 中的耦合序列 Sj,k，并且在每个类中的 c 由 Sj,k 的上下文中定义的类型家族中，至少有一个测试，涵盖c 和 Sj,k 的每一个可行的组
21、合适用于 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
22、的序列中，必须有至少一个相对于 v 执行每个耦合路径测试用例。那就是，每一个可行的耦合路径的每个耦合的定义和 V耦合对之间必须至少有一个测试用例执行。定义 3 全耦合定义用途：在每一个序列的方法耦合 Sj,k，并为该每一耦合变量V 和每个节点在该含 V 最后定义的先前的方法，至少有一个测试用例等，当 F是执行使用 T，有一个耦合路径 P 在微量的 F 开始，并且到达在 Sj,k 的随之而来的方法，该方法具有第一利用 V 的一个节点。3.2.4 全聚耦合定义用途.除了继承和多态，标准全聚耦合定义用途需要的定义的影响，并采用考虑。全聚偶合定义用途要求执行所有耦合路径为通过耦合序列的上下文中定义的类
23、型的每个家庭成员。定义 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。虽然有一定的异常，常见的假设是，在更高层次的包容层次结构的标准
24、有更多的测试功耗，成本较高。这个问题对于测试人员，那么，以确定哪些标准来选择一个特定的情况。图 2描述了本文所提出的标准的包容层次结构。天津科技大学外文资料翻译8图 2 面向对象耦合测试的归入层次3.4 准过程间分析注释困难之一，随着这种分析产生是由有变量动态绑定到不同的类型，从而允许多态实例的能力带来的。没有动态绑定，方法之间的数据流关系是静态的，可以在被执行之前知道。但当动态绑定是可能的，多态性效果可以在不同的方法是通过相同的调用站点上执行时，这取决于当前绑定到该变量的实例的实际类型。要理解这一点，考虑图 3（a）所示的 UML 类图（一） 。如图所示，A 类包括法计算命令 n 随着状态变
25、量 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，则实际调用是到
26、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 定义了。但考虑其
27、中 o 的类型为 C 的情况，方式 C: m 定义了一个 A : v，但不是 A : u。在声明中调用三个结果在 C 运行 C: m，这反过来又定义了A: v，但不是 A : u。后来，当调用语句 5，B : n 被执行，它使用 C:u。天津科技大学外文资料翻译9图 3 例如类层次结构与重写方法有一个潜在的问题，数据流异常，因为显然 A : u 不使用前面的定义。看来，执行 C:m 违反了关于 A:u 由 B:n 的假设。问题的唯一可能，是因为它可能是 A:u 通过先前的方法调用或作为建造绑定到 O 的实例的一部分来定义。动态绑定多态性的结果，因为前面的讨论说明，是一个面向对象的程序的数据流图
28、可以动态变化。虽然这极大地复杂的分析，可能类型的对象的数量是有限的，并且通常是小的。困难之处在于，有一个必须被考虑为给定的方法，这取决于动态绑定的存在，并可能发生的可能的多态性的多个图形表示。我们做了详尽的分析，计算所有可能的解决这个问题的耦合数据流。上面的讨论引发了另一个问题，即不可行帧内法耦合序列。帧内方法耦合序列是不可行的，如果没有输入，可以执行该序列。这是测试的一个问题，因为不可行耦合序列产生的测试需求无法得到满足。此外，它是非常困难的，以确定耦合序列是否是不可行的，或者如果它仅仅是很难找到合适的测试用例。不可行耦合序列的问题是一个比较普遍的问题一个特定的实例，通常被称为可行路径问题，
29、它说，对于某些结构试验标准的一些测试要求是不可行的，即程序的语义意味着没有测试用例满足测试要求。等效突变体，在路径测试技术不到的语句，和不可行 DU-双数据流测试是可行的路径问题的所有实例。虽然技术已被开发，它可以识别在大多数情况下用于突变检测，传统的数据流测试，和路径的测试技术20是不可行的路径，该问题一般是不可判定。我们还没有解决这个问题，在不可行耦合序列的上下文中，虽然人们希望通过 Offutt 和 Pan20开发的技术可以应用到这种情况下也是如此。另一个问题，就是与该类型是可行的特定连接顺序。A 型 Tis 认为是可行的，如果耦合序列的上下文变量可以经常被绑定到一个实例，其中 Tis
30、无论是声明的类型的上下文变量，或声明的类型的后裔。在某些情况下，这是微不足天津科技大学外文资料翻译10道的。例如，在耦合方法 F（如图 3（b）所示） ，上下文变量 o 耦合序列 S3,5 的传递作为一个正式的说法了。为改变 o，测试驱动程序只需要调用 f 传递不同类型的实例的实际参数。但是，如果 o 是代替 A，是由它绑定到一个方法调用 g的返回值，改变实例的类型初始化的局部变量将是极其困难的，目前超出了我们目前的研究范围之内。2 在 C +作用域解析运算符:用于指示哪些方法和状态变量都被提及。4. 相关工作有许多特有的面向对象软件测试的问题。一些研究人员宣称，一些传统的检测技术不能有效的面
31、向对象软件5，10，14。方法在面向对象的软件常用的方式意味着许多传统的软件测试技术测试错误的东西。具体而言，方法往往较小和较不复杂的，所以基于路径的测试技术是不太适用的。此外，继承和多态引入不可判定的软件3。执行路径不再是类的静态声明的类型的函数，但就是不知道，直到运行时的动态类型的函数。在他的博士论文，Overbeck 提出了一种基于客户端和服务器类22中的测试合同的方法。合同规定在一个类中的每个公共方法的前提条件和后置条件。类之间的相互作用进行测试，以确保客户正确使用类，及从方法返回的结果是由客户端的理解。这是通过施加一个特殊的测试过滤器，它位于客户端和类之间映入方法调用的类来完成。过滤
32、器进行检查，以确定是否其中一种方法是正确的类型和值，则该方法被调用以正确的顺序，而且如果所调用的方法的前提是真实的。如果这些检查都通过了，呼叫将被传递给类进行处理。否则，会报告错误和引发异常。这种技术并不能帮助创建测试用例，并且依赖于书面的程序员的正式规格。Jorgensen 和 Erickson17描述了一种方法，集成测试，类似于许多黑盒测试技术。他们通过，形成了系统类的集合定义路径。每个路径与特定的输入事件相关联，并且横穿参与该系统的响应的类。该路径包括通过方法调用遍历所有的类，并结束当系统输出已被观察到。检测到故障时，系统输出不期望的输出相匹配。故障确定回溯路径上的每个参与者。再次，有创
33、建测试用例没有帮助。Harrold 和 Rothermel 描述了适用于数据流分析，以类的方法 13。他们的方法强调三个层次的测试：（1）帧内法测试;（2）跨法检测 ;（3）内部类测试。为了进行这些分析，Harrold 和 Rothermel 代表了一类作为一类控制流图（CCFG）由单个进入和退出的。本文不介绍如何在测试过程中使用此信息。Chen 和 Kao 介绍一种方法，称为对象流测试测试面向对象的程序 8。在他们的方法，他们试图要找出和测试，可以发生在方法中可能的对象绑定。我们的想法是确定的定义使用对方法内发生的之间的方法，是从相同的调用者调天津科技大学外文资料翻译11用对。他们定义的施加
34、方法测试要求两个标准。第一，全绑定，要求每个对象的每个可能的结合可以至少被执行一次，并且进一步结合所有可能的组合，当表达式包含多个对象进行测试。这个标准类似于我们全聚类标准。他们的第二个标准，所有的都对，要求每一个定义明确的路径的一个对象，该对象至少测试一次每使用一个定义之间。这类似于全耦合定义用途。这里定义的标准主要是分层的，既考虑到细，之间的集成对象和方法，它应该允许更严格的测试粗粒度的相互作用。Orso 和 Silva 目前专注于通过识别包含测试（MUT ）21 的方法中的多态方法调用路径测试多态的定义和用途的技术。这项工作还认为，可能发生一个给定的对象引用可能的绑定。然而，这种方法的重
35、点是起因于多态调用中 MUT的效果。我们的方法考虑这一点，同时也相当重视对测试所造成的 MUT 内进行方法调用之间发生的相互作用。这不仅对 MUT 有影响，也影响的 MUT 的执行顺序对对象，它通过方法调用使用。5. 结论和未来工作本文介绍了面向对象软件的新的集成测试技术。四个不同的标准被提出，可以帮助测试人员评估基于继承和多态的软件组件之间的连接。这些标准依赖于一种新的类型的程序分析，准间分析。集成测试的这个水平是一个重要而困难的问题区域，面向对象的开发人员，因为采用面向对象的设计往往意味着重要的设计决策进行编码的互连组件之间，并且继承和多态的抽象机制可能会导致在非常复杂并且容易出错的关系。
36、本研究针对开发形式化的，可衡量的标准，从面向对象软件测试产生的问题。这些条件依赖于源代码的详细分析，并且可以被用来生成集成测试用于面向对象的软件，它是在检测中的软件组件之间的连接设计和编程错误有效。目前我们正在建设的概念证明的覆盖分析工具来支持这种技术。这个工具是美国普渡大学的 Tao 和 Palsberg 用 Java 构建，测试 Java 程序，并且是基于一般的 Java 解析器生成的 JavaCC 和 Java 树构建器（JTB） 3。该工具目前解析Java 程序，并生成多种图表分析。目前，我们正在设计技术，仪器的测试程序来判断测试是否满足在本文提出的测试标准。该工具将被用于提供该技术的
37、有效性的证据。本文是一个正在进行的项目，提供面向对象的软件开发与集成测试更好的工具和技术的一部分。这最终将导致软件，可建更便宜，更可靠。3 JTB 可以从网上下载，http:/www.cs.purdue.edu/jtb/index.html。参考文献1 Roger T. Alexander and A. Jefferson Offutt. Analysis techniques for testing polymorphic relationships. In Thirtieth International Conference on Technology of 天津科技大学外文资料翻译12O
38、bject-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.
39、 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
40、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, Sept
41、ember/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.Structure
42、d 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
43、 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 Rotherm
44、el. 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 Huffman Hayes. Testing of object-oriented programming systems (OOPS): 天津科技大学外文资料翻译13A fault-based approach. In E. Bertino and S
45、. Urban, editors,Object-Oriented Methodologies and Systems, volume LNCS 858. Springer-Verlag, 1994.15 IEEE. IEEE Standard Glossary of Software Engineering Terminology. ANSI/IEEE Std 729-1983, 1983.16 Zhenyi Jin and A. Jefferson Offutt. Coupling-based criteria for integration testing. The Journal of
46、Software Testing, Verification, and Reliability, 8(3):133154, September 1998.17 Paul C. Jorgenson and Carl Erickson. Object-oriented integration testing. Communications of the ACM, 37(9):3038, 1994.18 Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, Englewood Cliffs, New Jersey,
47、 2nd edition, 1997.19 A. J. Offutt, M. J. Harrold, and P. Kolte. A software metric system for module coupling.The Journal of Systems and Software, 20(3):295 308, March 1993.20 A. J. Offutt and J. Pan. Detecting equivalent mutants and the feasible path problem. The Journal of Software Testing, Verifi
48、cation, and Reliability, 7(3):165192, September 1997.21 A. Orso and S. Silva. Integration testing of procedural objectoriented languages with polymorphism. In16th International Conference on Testing Computer Software (ICTCS99), Washington, DC,1999.22 Jan Overbeck. Integration Testing for Object-Oriented Software. Ph.D. Dissertation, Vienna University of Technology, 1994.
