面向对象软件的测试

《面向对象软件的测试》由会员分享，可在线阅读，更多相关《面向对象软件的测试（10页珍藏版）》请在金锄头文库上搜索。

1、面向对象软件的测试用户使用低质量的软件，在运行过程中会产生各种各样的问题，可能带来不同程度的严重后果，轻者影响系统的正常工作，重者造成事故，损失生命财产。软件测试是保证软件质量的最重要的手段。什么是软件测试？1983 年 IEEE 定义为：使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。现代的软件开发工程是将整个软件开发过程明确的划分为几个阶段(参见6 的论述)，将复杂问题具体按阶段加以解决。这样，在软件的整个开发过程中，可以对每一阶段提出若干明确的监控点，作为各阶段目标实现的检验标准，从而提高开发过程的可见度和保证开发过程

2、的正确性。经验证明，软件的质量不仅是体现在程序的正确性上，它和编码以前所做的需求分析，软件设计密切相关。软件使用中出现的错误，不一定是编程人员在编码阶段引入的，很可能在程序设计，甚而需求分析时就埋下了祸因。这时，对错误的纠正往往不能通过可能会诱发更多错误的简单的修修补补，而必须追溯到软件开发的最初阶段。这无疑增大了软件的开发费用。因此，为了保证软件的质量，我们应该着眼于整个软件生存期，特别是着眼于编码以前的各开发阶段的工作。这样，软件测试的概念和实施范围必须扩充，应该包括在整个开发各阶段的复查、评估和检测。由此，广义的软件测试实际是由确认、验证、测试三个方面组成（注：本文对后面用广义测试概念处

3、不另加标识）： 确认：是评估将要开发的软件产品是否是正确无误、可行和有价值的。比如，将要开发的软件是否会满足用户提出的要求，是否能在将来的实际使用环境中正确稳定的运行，是否存在隐患等。这里包含了对用户需求满足程度的评价。确认意味着确保一个待开发软件是正确无误的，是对软件开发构想的检测。验证：是检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件是会正确无误的实现软件的需求，开发过程是沿着正确的方向在进行。 测试：与狭隘的测试概念统一。通常是经过单元测试、集成测试、系统测试三个环节。在整个软件生存期（参见6中的划分） ，确认、验证、

4、测试分别有其侧重的阶段。确认主要体现在计划阶段、需求分析阶段、也会出现在测试阶段；验证主要体现在设计阶段和编码阶段；测试主要体现在编码阶段和测试阶段。事实上，确认、验证、测试是相辅相成的。确认无疑会产生验证和测试的标准，而验证和测试通常又会帮助完成一些确认，特别是在系统测试阶段。面向对象技术是一种全新的软件开发技术，正逐渐代替被广泛使用的面向过程开发方法，被看成是解决软件危机的新兴技术。面向对象技术产生更好的系统结构，更规范的编程风格，极大的优化了数据使用的安全性，提高了程序代码的重用，一些人就此认为面向对象技术开发出的程序无需进行测试。应该看到，尽管面向对象技术的基本思想保证了软件应该有更高

5、的质量，但实际情况却并非如此，因为无论采用什么样的编程技术，编程人员的错误都是不可避免的，而且由于面向对象技术开发的软件代码重用率高，更需要严格测试，避免错误的繁衍。因此，软件测试并没有面向对象编程的兴起而丧失掉它的重要性。从 1982 年在美国北卡罗来纳大学召开首次软件测试的正式技术会议至今，软件测试理论迅速发展，并相应出现了各种软件测试方法，使软件测试技术得到极大的提高。然而，一度实践证明行之有效的软件测试对面向对象技术开发的软件多少显得有些力不从心。尤其是面向对象技术所独有的多态，继承，封装等新特点，产生了传统语言设计所不存在的错误可能性，或者使得传统软件测试中的重点不再显得突出，或者使

6、原来测试经验认为和实践证明的次要方面成为了主要问题。例如：在传统的面向过程程序中，对于函数y=Function(x);你只需要考虑一个函数（Function()）的行为特点，而在面向对象程序中，你不得不同时考虑基类函数（Base:Function()）的行为和继承类函数（Derived:Function()）的行为。面向对象程序的结构不再是传统的功能模块结构，作为一个整体，原有集成测试所要求的逐步将开发的模块搭建在一起进行测试的方法已成为不可能。而且，面向对象软件抛弃了传统的开发模式，对每个开发阶段都有不同以往的要求和结果,已经不可能用功能细化的观点来检测面向对象分析和设计的结果。因此，传统的

7、测试模型对面向对象软件已经不再适用。针对面向对象软件的开发特点，应该有一种新的测试模型。 一、面向对象测试模型(Object-Orient Test Model)面向对象的开发模型突破了传统的瀑布模型，将开发分为面向对象分析（OOA） ，面向对象设计（OOD） ，和面向对象编程（OOP）三个阶段。分析阶段产生整个问题空间的抽象描述，在此基础上，进一步归纳出适用于面向对象编程语言的类和类结构，最后形成代码。由于面向对象的特点，采用这种开发模型能有效的将分析设计的文本或图表代码化，不断适应用户需求的变动。针对这种开发模型，结合传统的测试步骤的划分，本文建议一种整个软件开发过程中不断测试的测试模型，

8、使开发阶段的测试与编码完成后的单元测试、集成测试、系统测试成为一个整体。测试模型如下图所示： OOA Test: 面向对象分析的测试 OOD Test:面向对象设计的测试OOP Test:面向对象编程的测试 OO Unit Test:面向对象单元测试OO Integrate Test:面向对象集成测试OO System Test:面向对象系统测试OOA Test 和 OOD Test 是对分析结果和设计结果的测试，主要是对分析设计产生的文本进行，是软件开发前期的关键性测试。OOP Test 主要针对编程风格和程序代码实现进行测试，其主要的测试内容在面向对象单元测试和面向对象集成测试中体现。面向

9、对象单元测试是对程序内部具体单一的功能模块的测试，如果程序是用 C+语言实现，主要就是对类成员函数的测试。面向对象单元测试是进行面向对象集成测试的基础。面向对象集成测试主要对系统内部的相互服务进行测试，如成员函数间的相互作用，类间的消息传递等。面向对象集成测试不但要基于面向对象单元测试，更要参见 OOD 或 OOD Test 结果（详见后叙述） 。面向对象系统测试是基于面向对象集成测试的最后阶段的测试，主要以用户需求为测试标准，需要借鉴 OOA 或 OOA Test 结果。尽管上述各阶段的测试构成一相互作用的整体，但其测试的主体、方向和方法各有不同，且为叙述的方便，本文接下来将从 OOA，OO

10、D，OOP，单元测试，集成测试，系统测试六个方面分别介绍对面向对象软件的测试。对由 OOA，OOP，OOD 这三个开发阶段所构成的开发模型、各阶段应该完成的目标以及结果报告的形式等详细介绍，已经超出本文内容，请参见1。 二、面向对象分析的测试(OOA Test)传统的面向过程分析是一个功能分解的过程，是把一个系统看成可以分解的功能的集合。这种传统的功能分解分析法的着眼点在于一个系统需要什么样的信息处理方法和过程，以过程的抽象来对待系统的需要。而面向对象分析（OOA）是把 E-R 图和语义网络模型，即信息造型中的概念，与面向对象程序设计语言中的重要概念结合在一起而形成的分析方法 （参见1） ，最

11、后通常是得到问题空间的图表的形式描述。OOA 直接映射问题空间，全面的将问题空间中实现功能的现实抽象化。将问题空间中的实例抽象为对象（不同于 C+中的对象概念） ，用对象的结构反映问题空间的复杂实例和复杂关系，用属性和服务表示实例的特性和行为。对一个系统而言，与传统分析方法产生的结果相反，行为是相对稳定的，结构是相对不稳定的，这更充分反映了现实的特性。OOA 的结果是为后面阶段类的选定和实现，类层次结构的组织和实现提供平台。因此，OOA 对问题空间分析抽象的不完整，最终会影响软件的功能实现，导致软件开发后期大量可避免的修补工作；而一些冗余的对象或结构会影响类的选定、程序的整体结构或增加程序员不

12、必要的工作量。因此，本文对 OOA 的测试重点在其完整性和冗余性。尽管 OOA 的测试是一个不可分割的系统过程，为叙述的方便，鉴于2中 Coad 方法所提出的 OOA 实现步骤，对 OOA 阶段的测试划分为以下五个方面： 对认定的对象的测试 对认定的结构的测试 对认定的主题的测试 对定义的属性和实例关联的测试 对定义的服务和消息关联的测试 对象、结构、主题等在 OOA 结果中的位置，参见下图：1 对认定的对象的测试：OOA 中认定的对象是对问题空间中的结构，其他系统，设备，被记忆的事件，系统涉及的人员等实际实例的抽象（参见2） 。对它的测试可以从如下方面考虑：1.1 认定的对象是否全面，是否问

13、题空间中所有涉及到的实例都反映在认定的抽象对象中。1.2 认定的对象是否具有多个属性。只有一个属性的对象通常应看成其他对象的属性，而不是抽象为独立的对象。1.3 对认定为同一对象的实例是否有共同的，区别于其他实例的共同属性。1.4 对认定为同一对象的实例是否提供或需要相同的服务，如果服务随着不同的实例而变化，认定的对象就需要分解或利用继承性来分类表示。1.5 如果系统没有必要始终保持对象代表的实例的信息，提供或者得到关于它的服务，认定的对象也无必要。1.6 认定的对象的名称应该尽量准确，适用。 2 对认定的结构的测试在 Coad 方法中，认定的结构指的是多种对象的组织方式，用来反映问题空间中的

14、复杂实例和复杂关系。认定的结构分为两种：分类结构和组装结构。分类结构体现了问题空间中实例的一般与特殊的关系，组装结构体现了问题空间中实例整体与局部的关系。2.1 对认定的分类结构的测试可从如下方面着手：2.1.1 对于结构中的一种对象，尤其是处于高层的对象，是否在问题空间中含有不同于下一层对象的特殊可能性，即是否能派生出下一层对象。2.1.2 对于结构中的一种对象，尤其是处于同一低层的对象，是否能抽象出在现实中有意义的更一般的上层对象。2.1.3 对所有认定的对象，是否能在问题空间内向上层抽象出在现实中有意义的对象2.1.4 高层的对象的特性是否完全体现下层的共性2.1.5 低层的对象是否有高

15、层特性基础上的特殊性2.2 对认定的组装结构的测试从如下方面入手：2.2.1 整体（对象）和部件（对象）的组装关系是否符合现实的关系。2.2.2 整体（对象）的部件（对象）是否在考虑的问题空间中有实际应用。2.2.3 整体（对象）中是否遗漏了反映在问题空间中有用的部件（对象） 。2.2.4 部件（对象）是否能够在问题空间中组装新的有现实意义的整体（对象） 。3 对认定的主题的测试主题是在对象和结构的基础上更高一层的抽象，是为了提供 OOA 分析结果的可见性，如同文章对各部分内容的概要。对主题层的测试应该考虑以下方面：3.1 贯彻 George Miller 的7+2 原则（参见3 ） ，如果主

16、题个数超过 7 个，就要求对有较密切属性和服务的主题进行归并。3.2 主题所反映的一组对象和结构是否具有相同和相近的属性和服务。3.3 认定的主题是否是对象和结构更高层的抽象，是否便于理解 OOA 结果的概貌（尤其是对非技术人员的 OOA 结果读者） 。3.4 主题间的消息联系（抽象）是否代表了主题所反映的对象和结构之间的所有关联。4 对定义的属性和实例关联的测试属性是用来描述对象或结构所反映的实例的特性。而实例关联是反映实例集合间的映射关系。对属性和实例关联的测试从如下方面考虑：4.1 定义的属性是否对相应的对象和分类结构的每个现实实例都适用。 4.2 定义的属性在现实世界是否与这种实例关系密切。4.3 定义的属性在问题空间是否与这种实例关系密切。4.4 定义的属性是否能够不依赖于其他属性被独立理解。4.5 定义的属性在分类结构中的位置是否恰当，低层对象的共有属性是否在上层对象属性体现。4.6 在问题空间中每个对象的属性是否定义完整。4.7 定义的实例关联是否符