（计算机软件与理论专业论文）面向对象软件自动化单元测试技术研究.pdf

f 一。j、i ： - ，- 摘要 本文首先逐步深入地对软件测试、面向对象软件测试、自动化软件测试 和面向对象软件单元测试进行了介绍和分析。最后主要集中精力于基于 设计模型规格描述的自动化单元测试技术研究。提出了一种使用经过扩 充的状态图规格描述作为输入的自动化单元测试方法。该方法直接存取 被测试对象状态变量，可以实现充分测试。我设计开发了该方法的一个 原型实现。该方法还存在须要解决的问题，状态定义对状态变量的取值 规律要求很可能是具有复杂规律的离散分布。如果没有其它机制的支持， 不可能建模出这种复杂的分布规律。解决这个问题对该方法的实用化和 严晶化很重要，是我下一步的研究方向。 关键词：单元测试状态图扩展有限状态机 a b s t r a c t f i r s t lv t h ep a p e ri n t r o d u c e ss o f t w a r et e s t ，p h i e c to r i e n t e ds o f t w a r et e s t a u t o m a t e d s o f t w a r et e s t ，a n da u t o m a t e du n i tt e s tf o r o b j e c t o r i e n t e ds o f t w a r e t h e n ，t h ep a p e r f o c u s e so nt h er e s e a r c ho fa u t o m a t e du n i tt e s t i n gt e c h n i q u eb a s e do nt h es p e c i f i c a t i o no f d e t a i l e dd e s i g n am e t h o di sp r o p o s e df o ra u t o m a t e du n i tt e s to fo b j e c t o r i e n t e dp r o g r a m ， w h i c hu s e st h es p e c i f i c a t i o no fe x t e n d e ds t a t ed i a g r a ma st h ei n p u t t h i sm e t h o dd i r e c t l v a c c e s ss t a t ev a r i a b l eo ft h eo b i e c tu n d e rt e s t ，s om a ya c h i e v es u f f i c i e n tt e s t ap r o t o t y p e s y s t e mo ft h i sm e t h o di sd e v e l o p e d t h e r es t i l l i ss o m ep r o b l e mt ob er e s o l v e di nt h i s m e t h o d t h em a i o ro n ei st h a tt h es t a t ed e f i n i t i o nc a nb et o oc o m p l e xt ob ed e s c r i b e d a c c u r a t e l 弘t h es t a t ed e f i n i t i o nm a yc o n t a i nc o m p l e xd i s c r e t es t a t ev a r i a b l ed i s t r i b u t i o n w h i c hc a nn o tb ed e s c r i b e da sc o m b i n a t i o no fs t a t ev a r i a b l ev a l u es e c t i o n s w i t h o u te x t r a m e c h a n i s mt os u p p o r tt h i sm e t h o d ，t h ec o m p l e xd i s t r i b u t i o nc a nn o tb ed e s c r i b e d a p o t e n t i a lm e t h o dt or e s o l v et h i sp r o b l e mi st od e s i g nak i n do fo p e nm e c h a n i s mt h r o u g h w h i c ht h eu s e rc a ns u m m i tc o m p l e xs t a t ed e f i n i t i o ni nt h ef o i t i io fas t a t ea 伍r m i n g f u n c t i o n t h ef u n c t i o nw i l lb ec a l l e dd u r i n gt h et e s tp r o c e s st od e t e c tt h eo b i e c t ss t a t e ，1 1 e ni tc o m e st ot h ec o m m e r c i a la n dp r a c t i c a lr e a l i z a t i o no ft h i sm e t h o d i ti s v e r y i m p o r t a n tt or e s o l v et h i sp r o b l e m 0 u rf u t u r es t u d yp l a nf o c u s e so nt h er e s o l v i n go ft h i s p r o b l e m k e y w o r d ：u n i tt e s t i n g s t a t ed i a g r a me x t e n d e df i n i t es t a t em a c h i n e 创新性声明 y 5 8 3 3 9 9 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及敢得的研究 成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不 包含其他入已经发表或撰写过的研究成果；也不包含为获得西安电子科技大学或 其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做 的任何贡献均已在论文中做了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名：聿d ：鎏 同期2 1 坌笙：鸯 关于论文使用授权的说明 本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究生 在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。本人保证毕业 离校后，发表论文或使用论文工作成果时署名单位仍然为西安电子科技大学。学 校有权保留送交论文的复印件，允许查阅和借阅论文：学校可以公布论文的全部 或部分内容，可以允许采用影印、缩印或其它复制手段保存论文。( 保密的论文在 解密后遵守此规定) 本学位论文属于保密在一年解密后适用本授权书。 本人签名：塑型：堑日期兰! ! 丝：! 导师签名：彳 肛 日期一2 生兰兰盟 绪论 绪论 目前，在使用c ”、j a v a 等面向对象语言_ 丌发系统时，盛行的单元测试方法是 由模块编写人员同时编写测试驱动程序和数据生成程序，可能还要编写模拟其它 类和模块的桩程序。按照这种方法完成单元测试需要的工作量非常惊人，使得很 多系统不可能对每个模块进行良好的单元测试。通常情况下，只对非常关键的系 统和系统的核心模块进行比较，“格的单元测试。这种测试条件下，很多错误原本 可以，而且应该已经在测试阶段被发现，却被遗留到了最终系统中。 已经出现了许多自动化测试工具和方法。有的已经在实际软件丌发中得到广泛 的应用。在单元测试方面，主要采用两种技术途径。一种是基于代码生成测试的 方法。它主要是对传统过程语言测试技术进行改进的产物。它采用路径覆盖的覆 盖度量标准，不能很好的测试面向对象程序。同时，基于代码的测试还有一个致 命的缺点不可能对代码和设计进行致性测试。另外一种就是自动测试辅助 工具，它提供了测试工具类库以及嵌入式测试脚本语言。帮助编程人员编写测试 程序，执行测试，以及分析管理程序错误等。使用这种测试方法，极大的减轻了 测试工作量。但是，它只是对传统测试方法的一种自动化改进，没有从本质上减 少测试工作量和降低测试成本。 一种很有应用前景的面向对象软件单元测试技术是基于设计模型的测试。这种 技术把软件单元设计模型以正式或非正式的格式保存在设计文档中，系统实现人 员按照设计编码，然后由自动测试工具以源代码和设计文档作为输入测试设计和 实现的一致性。如果把该方法与模型验证技术结合起来，就可以很好的保证单元 测试的质量。复杂的状态转换是面向对象程序的一个显著特点。为了建模状态转 换规则，状态图在分析和设计中得到了普遍使用。本论文旨在探索可行的、高效 的该方法的实现。在充分借鉴前人研究成果的基础上，提出了一种基于作为单元 详细设计的状态图规格描述的自动化单元测试方法。通过开发个实现该方法的 原型系统，验证该方法的可行性和优越性，同时也是为了发现浚方法的缺陷。在 开发原型系统的过程中，我也认识到了开发基于这种方法的实用的自动测试工具 的难点所在。原型系统对许多困难问题进行了限定性和假设性的简化。要彻底解 决这些问题，还需要很多研究和开发工作。 本文共六章。第章简要介绍测试基本知识。第二章介绍面向对象软件测试， 主要分析了测试面向对象软件的特殊性。第三章介绍了自动化软件测试的相关概 念和技术现状，分析了自动化测试技术的发展方向。第四章介绍面向对象软件自 动化测试的相关方面、解决方法和技术研究现状。第五章提出了个新的面向对 象软件单元测试方法，详细介绍了该方法的原理和实现途径。第六章详鳃介绍了 该方法的原型系统的原理、设计和实现。 第一章软件测试 第一章软件测试 1 1 测试概述 测试并不是一个新事物。牛津英语大词典中记载“t e s t ”词来源于拉r 语 t e s t u m0 原意是罗马人用的一种陶罐，在当时它用来评估像稀有金属矿石这样 的材料的质量。几乎只要是软件开发出来的计算机程序都要经过测试。在软件丌 发早期几乎没有正规的测试，而调试被视为软件开发过程中的重要步骤。 随着软件开发过程采用正规方法而逐渐成熟【1 】，测试方法也随着测试专家采 用了正规的测试方法和技术 2 】而同趋成熟。现代软件开发领域的大多数工作者都 对测试及其目的有直观的认识，最常见的看法包括： 保证程序和相应的规范说明一致。 发现软件中的缺陷。 确保软件不做不必要的事情。 确保系统合理的执行。 明确在系统失败之前可以让系统正常运行到何种程度。 明确发布给用户的系统中有哪些风险。 下面给出测试的更为规范的定义：测试是一种旨在评估一个程序或系统的属r 性 或能力，确定它是否符合其所需结果的活动f 3 1 。这个定义阐述传统的测试方法， 即检查系统是否符合其陈述的需求。这是对测试的一种直观的看法，即我们知道 系统应该执行的一些状态，然后我们确定是否满足这些需求。这种方法也就是所 说的肯定测试。 还有对测试的另一种看法：测试是为了发现错误而执行一个程序或系统的过 程。这个定义不太直观，而且严格地说，并没有考虑系统的需求。相反，它引入 在软件需求范围之外积极查找错误的概念。实际上，系统中可能会有问题或错误。 这种方法也就是所谓的否定测试。 实际上，测试将合并肯定测试和否定测试这两类测试的元素，即检查一个系 统是否符合其需求，同时也试图发现可能会损害系统的成功操作或有用性的错误。 在需求完整并有精确的规范的理想情况下，不须要进行否定测试，因为指定了被 测应用( a p p l i c a t i o n u n d e rt e s t ，a u t ) 的每个方面，在这一点上人们还有所争议。 但是，我们并不能处于完全理想状态下，所以在进行测试时还应该包括否定测试。 最近，用风险来定义测试的观念越来越流行。在这种用法中，“风险”一词与 a u t 通不过可靠性或健壮性测试，可能会对用户带来商业上的损害的可能性有关。 下面是用风险对对测试进行的一个定义：测试是我们考察并理解与发布的软件系 统有关的利益和风险状况的过程【4 】。在这个测试的定义中， 测试者的作用是管理 或转移系统失败的风险，以及可能会给用户带来的不良影响。 面向对象软件【| = | 动化单元测试技术研究 用风险来定义测试给测试人员提供了另外一种处理系统测试的策略。使用基于 风险的方法，测试人员应注重软件分析，以便识别出需要进行充分测试的高胍险 的区域，确保用户在运行系统时不会出现危险。此外，在项目管理环境中，风险 的概念已经众所周知且被大家所了解，有大量的工具和技术可以应用到测试过程 中 4 ，5 ，6 。 对于注重计划和设计测试的人员来说，识别一个特定的a u t 的具体风险可能 会很困难，尤其是当他们不太熟悉软件的运行领域时。在估计风险的时候，考虑 下面这些问题非常重要： a u t 的业务、安全或保密的重要程度。 a u t 的商业公众的可视性。 测试类似或相关系统的经验。 测试同一a u t 的早期版本的经验。 a u t 用户的看法。 a u t 的分析员、设计者和实现者的看法。 7 给出了一个测试的定义：测试是一种保证软件质量的方法，在一定的环境下， 通过以一定的数据输入执行被测试软件来评估软件的质量。质量不只包括正确性， 还包括可靠性、健壮性、可用性等。这个定义很具体，指出了测试的具体实施方 法。这种测试的定义通过要求用测试数据实际执行程序把测试同其它软件质量保 证方法区分了开来。这些质量保证方法包括检查、评审、调试、原型、模拟、数 学模型等。 那么，为什么测试是有益的呢? 因为测试要执行程序本身，它是最直接、最 有效的评估软件质量的手段。测试捕捉到其它方式没有发现的错误，而且可以在 用户运行系统受到影响之前做到。 1 2 测试的相关概念 因为测试包含大量的概念，所以我们须要把这些概念置于一个框架中，这样 便于理解它们之间的联系和区别。 1 2 1 质量的概念 首先，我们注意到有许多以不同的质量概念为基础的不同的测试，比如可靠性 测试、性能测试、强度测试、可用性测试和正确性测试。不同类型的测试有不同 的侧重点。甚至测试实例和缺陷的概念在不同的测试中也不尽相同。例如，在正 确性测试中，选择正确的测试实例很重要，而在可靠性测试中，检测系统何时失 败更加重要。 1 2 2 测试方法学的构成 一种测试方法学由以下几部分构成，每个部分都与测试的一个重要方面有关。 待测试程序和测试环境 第一章软州测试 得到测试实例的方法 执行测试实例和评估测试结果的方法 在测试结果的基础上评定程序质量的方法 1 2 3 程序开发 程序开发涉及很多要素，其中某些要素确实会影响测试。例如，与更传统的 丌发过程相比，面向对象的歼发会导致不同类型的错误，进而，也就引出了不同 的测试技术。 1 2 4 得到测试实例 得到测试实例的方法是测试的一个主要问题。这也是本研究的一个重点。他包 括很多方面，如：怎么选择出“好”的测试实例，其中好可能表示捕捉错误的性 能好，也可能表示在获得用户输入的典型实例方面表现好；如何根据输入执行不 同的程序单元；如何创建标准的、易于理解和使用的测试实例等。 1 2 5 评估测试结果 评估测试结果就是根据程序规格描述判断是否程序的输出是否正确。这就是 正确性验证难题。可用性测试的测试结果评估更加困难：我们需要确定程序对特 定测试实例来说是否“易于使用”。 1 2 6 评定程序质量 评定程序质量非常重要，因为这就是整个测试的目的。可靠性测试在这方面比 正确性测试更先进些。很少有评定程序正确性的方法，而且，仅有的一些方法只 适用于非常小的程序。 1 3 测试方法 历史上，测试方法被分为三种：非正式测试、结构化测试和功能测试【8 ，9 】。 由于没有明确的测试策略，执行代码发现错误几乎等同于盲人摸象 1 0 1 。种非正 式的质量保证机制是代码检查。统计测试方法把系统置于输入数据值的正太分布 中；加权测试法，例如操作剖面测试，给系统中使用频率高的部分赋予更高的权 值。两种方法都只是随机地、不完全地执行系统。只有两种测试方法声称以对被 测试系统的真实理解为根据。 结构( 或白盒) 测试的测试策略直接建立在代码实现的基础上，并且试图表明 程序的所有部分都被测试到了。由于被测试系统的大小以及输入值与决策路径所 组成的上百万的组合，结构测试很少能作到完全测试。即使对中等大小的系统， 也不能覆盖全部的决策路径，而且，决策路径覆盖只是用来证明的决策路径的可 到达性。结构测试只能暴露部分程序缺陷，未发现的缺陷使的程序的质量不能得 到保证。特别地，结构测试不能发现功能遗漏。 功能( 或黑盒测试) 从系统规格描述生成一个测试实例集合，试图证明系统 实现的抽象行为与系统规格描述一致。功能测试可以通过等价类划分实现。等价 面向对豫软件自动化单死测试技术研究 类划分依赖于一个事实。即输入可以被分组或者划分为相对独立的组或者类，这 些类中的所有实例被系统以同样的方式处理。功能测试从输入等价类中选择代表 性的数据执行程序，判断程序的响应是否与规格描述期望的响应是否一致。等价 类划分测试法能够很准确的发现小区间上的期望失效【1 1 。 f 1 2 ，1 3 】给出了一种基于状态机规格描述的功能测试实现。在测试驱动的支持 下，程序实现被在所有状态的所有迁移上进行测试，检查迁移是否给出了正确的 响应、是否到达了正确的状态。这里的正确是指与规格描述所期望的一致。测试 覆盖标准包括状态覆盖( 到达每一个状态) 、迁移覆盖( 激发每一个迁移) 和全路 径覆盖( 追踪状态机的每条路径) 。严格的讲，对j 状态机规格描述的一致性测试是 一种介于结构测试和功能测试之间的测试方法。 基于状态机的测试可以执行到状态层 1 4 1 ，所以在一定的设计假定下，可以用 来保证系统属性。这确实比单纯地执行代码的所有决策分枝更有意义，因为一次 成功的测试也要保证系统对所有的预期事件做出了正确的响应，同时忽略所有的 非预期事件。可是许多基于状态机的测试实现并没有充分利用基于状态机的测试 方法的优点。因为它们采用平坦的f s m 描述系统状态转换 1 5 ，1 6 1 ，即使是一个比 较简单的系统，结果f s m 的状念和路径动辄可以达到百万数量级，这往往就超出 了可测试极限。h o l c o m b e 首先采用了一种分层的状态规格描述【1 7 1 ，这种状态描述 方法基于e i l e n b e r g 的x m a c h i n e 【1 8 】，它实现为带有运行在共享内存上的迁移函数 集的有限状态机。这种模型的优点在于它能把一个层次上的任意复杂迁移函数抽 象成一个独立的状态机。 1 4 测试阶段 在整个开发声明周期中，a u t 要经过测试阶段有：单元测试、集成测试、系统 测试、系统集成测试、验收测试和回归测试。单元测试是a u t 经历的最低层次的 测试。通过执行单元测试来确保产生符合需求的可靠的程序单元。集成测试的目 标是证明组成a u t 的各个模块以正确、稳定和一致的方式进行对接和交互。系统 测试的目的是通过测试建立a u t 将被它的用户接受的自信，即它将通过验收测试。 在系统测试过程中，将证明系统的功能结构的稳定性，以及如性能和可靠性等的 非功能需求。系统集成测试的目的是确保a u t 可以和其它的指定系统成功的相互 操作，对其它可能出现在真实操作环境中的系统没有不好的影响。只有当迫切须 要a u t 和大量其它软件系统进行交互操作时，才将系统集成测试引入测试过程中。 验收测试的目的是确认系统符合它的业务需求，并在正式提交给用户之前确保系 统工作正常并且可用。验收测试通常分为用户验收测试( 涉及到a u t 的业务或最 终用户) 和操作验收测试( 涉及到a u t 的操作或管理用户) 。回归测试的目的是 确保a u t 在系统修改或扩充后功能仍然正确。严格的讲，回归测试不是一个测试 阶段，只是一种可以应用于+ 瓦它任何测试阶段的测试技术。 第? 蕈面向对象较仆测试 第二章面向对象软件测试 2 1 概述 面向对象技术是一种全新的软件丌发技术，正逐渐代替被广泛使用的面向过 程开发方法，被看成是解决软件危机的新兴技术。面向对象技术产生更好的系统 结构，更规范的编程风格，极大的优化了数掘使用的安全性，提高了程序代码的 重用，一些人就此认为面向对象技术丌发出的程序无需进行测试。应该看到，尽 管面向对象技术的基本思想保证了软件应该有更高的质量，但实际情况却并非如 此，因为无论采用什么样的编程技术，编程人员的错误都是不可避免的，而且由 于面向对象技术开发的软件代码重用率高，更需要严格测试，避免错误的繁衍。 因此，软件测试并没有面向对象编程的兴起而丧失掉它的重要性。 从1 9 8 2 年在美国北卡罗来纳大学召开首次软件测试的正式技术会议至今，软 件测试理论迅速发展，并相应出现了各种软件测试方法，使软件测试技术得到极 大的提高。然而，一度实践证明行之有效的软件测试对面向对象技术开发的软件 多少显得有些力不从心。尤其是面向对象技术所独有的多态，继承，封装等新特 点，产生了传统语言设计所不存在的错误可能性，或者使得传统软件测试中的重 点不再显得突出，或者使原来测试经验认为和实践证明的次要方面成为了主要问 题。 几年前讨论测试时，有关人士总是被告诫说要进行“彻底”测试，但是何谓“彻 底”测试? 如何才能做到彻底测试? 实际上并没有可操作的定义做指导，也没有多 少成功先例可援引。时至今日，已有许多技术方法问世，也有许多测试过程中可 遵循的策略出台，还有许多有用的工具可选。近期出版的有关面向对象开发的书 刊也必辟章节专论测试，尽管有些是很粗略的。可比的是，早几年的出版物中要 不就根本不提测试，即使没有完全去除，往往也只是用一两句话轻描淡写地提一 提在面向对象软件中测试是极容易，面向对象大大减轻了软件测试的工作量等。 由此可见人们对面向对象软件测试的看法及其在软件开发中的地位。 这种改变是令人欢欣鼓舞的，因为“彻底”地测试面向对象系统是非同凡响的挑 战，其中至少有三大难点： 第一，对象的典型行为特征就是顺序依赖性，即对象的响应活动是与它所接 受到的消息序列密切相关的。因此我们能够用状态机的概念来说明、实现和测试 对象。将对象类方法孤立起来加以测试，就如同我们处理传统的例程测试那样， 实际上是不充分也无效的。大多数系统化的面向对象测试方法都是基于状态的， 这种基于状态的测试又有两种流派：一是有顺序的基于状态的测试，它立足于查 找消息序列中暴露出错误的消息。状态定义的是下确的行为和不j 下确的对象行为， 这种方法实际上是基于规格说明的，因为人们事先就使用状态定义描述了正确的 面向对象软什白动化单元测试技术研究 和错误的操作。二是域方法的基于状态的测试，它根据被测类的实例变量的假定 值来安排各个状态，这些状态和消息之间的相互作用可以用来产生测试用例。 有顺序的基于状态的测试方法的优势在于它有4 0 年的发展历史，这种方法4 0 年来一直被人们所研究并应用在电子电路、硬件部件和无线通信协议的测试中， 这些领域内的成功经验和知识都可以推广到对面向对象软件的测试中来，这种方 法的缺点在于基于状态的测试是极困难的，状态空问极大，意味着不得不用自动 化测试。此外，在实际测试中有必要添加内置功能，专门设置和报告对象系统中 的状态。本论文的主要目的就是尝试解决这一难点。 第二，面向对象系统从本质上讲不像传统软件那样能测，虽然面向对象程序设 计语言已经去除了容易出错的内容，如弱封装性、全局数据的危险性、类型的错 误匹配等，但也还是带来了不少新问题，如局域化和分块化造成程序的可理解性 的下降。 在用传统程序设计语言编写的软件中，变量的静态集合对应的就是程序的状 态空间。如果程序的结构设计精良，那么其运行时的行为活动也能够跟踪捕捉到。 相反，面向对象程序则不然：用面向对象程序设计语言的继承性和多态性常常使 源代码或规格说明中的路径和状态变得非常复杂。那些所谓的封装性能够减少程 序的复杂性的老生常谈，实际上正在灰飞烟灭。面向对象软件测试中的测试用例 的设置实际上是极为困难的。对象总是由另一些对象组成，所以为一个对象设定 测试用例往往会演变成为该对象嵌套的所有对象设置测试用例。对于面向对象软 件而言，在设计开发软件的同时就考虑和设计该软件的可测试性并内置测试例程， 是一种缓解面向对象软件将面临的测试的紧张局面的有希望的方法。 第三个难点是实际存在的问题，重复的和增量式的开发加上滞后的管理常常 导致类库缺乏正确的功能划分( 从原则上讲类库中的每个类在功能上是正交化 的) ，不保留源代码的文档。这些都是常规问题了，而在面向对象软件中表现的更 加突出，其后果是软件失误的可能性增大、可测试性降低、可重用性降低，同时 伴随出现的问题是类库规模越来越大。而内容越来越陈旧。 以上所讲的问题实际上都是与测试的两大基本原则背道而驰的。测试的基本 原则是： 1 软件的规格说明必须是可以被重复测试的； 2 为被测系统设计的自动测试措施必须是试验过的。 对于功测试，即黑盒测试面言，保持软件需求规格说明和实现之间的同步 性是有相当大的实际困难的，而且随着面向对象软件开发过程中采用快速的、重 复性的开发模式，要保持软件规格说明与软件实现这二者之间的同步性就愈发困 难了。因此，面向对象软件开发过程将严重阻碍可重复的、客观性的软件测试。 尽管软件测试的覆盖率度量并不是一个十全十美的软件质量因素，但毕竟是 第一i l | 旬对琢软什测试 一种能够反映究竟有多少测试用例被试验过，以及软件对这些测试所表现出来的 反映情况的测量手段。它能为最终评价软件质量特性提供一个方面的依据。商用 软件产品在上市之前都必须经过测试、验证。只有满足了一定的测试覆盖率之后， 软件才能成为正式的软件产品在市场上销售。就面向对象软件而言，即使不是无 限组合，其可测部件、对象的组合数目之大都非常惊人。如何计算测试覆盖率? 如何根据不甚了了的测试覆盖率来折算出软件可靠性指标? 这些实质上很关键的 问题，在目前都还不十分明确，这些都极大地影响了面向对象软件的质量。 2 2 测试面向对象程序 测试面向对象程序测试可分为四个阶段：即算法测试、类测试、集成测试、系 统测试 1 9 ，2 0 1 。面向对象程序的算法测试和系统测试与传统软件测试基本相同。 在算法测试阶段，所有的方法被分离测试，因而传统的测试技术可以容易地应用 到该阶段。在类测试阶段，通过把类作为一个单独的实体进行测试来检验类的完 整性。这两个测试阶段已经被广泛研究 1 9 ，2 1 1 。集成测试关注于多个类的综合。 因为单独类的功能性已经被检验过了，集成测试的焦点通常被放在多个并发模块 的同步以及类之间的方法调用上。在系统测试阶段，主要测试类综合之间的交互。 在面向对象程序中，子程序( 也就是对象方法) 不能作为基本的测试单元。许 多对象方法一起参与了对象的行为。所以，面向对象程序的最小测试单元是一个 类的测试实例一一对象。有时一个类不能被单独测试，而只能与其它多个类一起 测试。 在面向对象程序中，对象是基本的运行时实体。它们是封装了状态和方法的类 实例。面向对象技术的三大机制：封装、继承和多态妨碍着对面向对象程序的基 本单元一一类进行有效的测试。 封装意味着可见性问题，因为观察对象状态的唯一途径是通过对象方法，当不 能通过对象方法得到对象属性时问题就出现了。有人建议通过在被测试类中添 加专门的存取类属性的方法 引入继承机制之后，很明显派生类中增加和重载的方法须要重新测试，但是有 人认为继承自父类的方法不须要在测试派生类时再次测试( 如果父类已经被测 试通过了) 。这是错误的，因为方法的调用和结果依赖于对象的状态，因为至 少子类的状态属性可能会与父类的状态属性不同，子类的状态集合与父类的状 态集合也可能会不同。这样，类的每个方法必须被依据类的状态集合进行测试。 多态和动态绑定导致了不确定性问题。几乎不可能静态的分析出对于一个测试 实例，哪个方法将被调用。当调用多态方法或传递多态参数时就会发生这种问 题。幸运的是，多态的固有性质会对该问题的解决有所帮助：所有的多态方法 在逻辑上都完成同样的任务( 否则，就不是多态了) 。我们可以指定期望的任 务和所有可能执行的具体方法。 1 0面向对蒙软件臼动化单死测试技术研究 已经有许多考虑了这些问题的研究报告。它们专注的方面有测试层次、测试模 型和测试方法论。f 2 2 ，2 3 1 把传统的测试层次( 即，单元测试、集成测试等) 进行 适当改动后应用于面向对象程序测试。适用于面向对象程序的新测试层次类 测试 2 4 1 ) 、算法测试、类集成测试 2 5 】也被做了介绍和研究。 类测试也被通过测试模型进行介绍。因为类是基本的测试单元，我们必须考虑 类的行为。为此，类的行为被分解到了状态，也就是保存在变量中的状态属性值， 它们构成了状态的数据表现形式。这就是基于状态的测试2 6 ，2 7 1 。基于状态的测 试专注与对象依赖于状态的行为，而不是控制结构或单独的数据。 两个重要的测试方法论利用了面向对象特征的优点。递增测试 2 8 1 把类的测试 实例组织成一个与派生层次对应的层次结构。通过子类与父类的继承关系，就可 以确定使用或不使用来自父类的测试实例，或者设计新的测试实例。2 9 1 研究了把 统计测试应用于面向对象程序测试。统计测试侧重于遗传机制，以便于对小型子 系统进行递增测试。 在一些研究工作中，设计模型被用来辅助测试过程性软件。比较特别的是，f 3 0 ， 3 i 】把有限状态自动机用于测试目的。状态图【3 2 卜一一种可以生成模块化、分级 的、结构化系统描述的有限状态机的扩展也被用来建模系统的行为特征：在 【3 3 】中，作者使用s t a t e m a t e ( 一种基于状态图【3 4 】的工具) 设计测试实例。 第二章自动化软什测试 第三章自动化软件测试 3 1 概述 软件测试的工作量很大( 据统计，会用到4 0 的开发时白j ：一些可靠性要求非 常高的软件，测试时间甚至占到总开发时间的6 0 ) ，但测试却是在整个软件过程 中极有可能应用计算机进行自动化的工作，原因是测试的许多操作是重复性的、 非智力创造性的、需求细致注意力的工作。计算机就最适合于代替人类去完成这 些任务。比如，如果设计文裆、需求文档具有固定、合理、可理解的结构，那么 从这些文档生成测试数据和相关程序的操作就完全可以程序化实现，就可以基于 从这些文档提取的信息实现测试结果的评估。具体些，可以通过u m l 状态图进行单 元测试，通过u m l 序列图进行集成测试，通过u m l 用例图进行系统测试。要实现基 于u m l 设计文档实现自动化软件测试还有许多问题需要解决。首先，u m l 实际上只 是一系列图形标准，没有相应的规格描述格式标准。这使得程序处理u m l 模型非常 困难。可喜的是，可以使用x m i 文件来描述u m l 模型，x m i ( x m lm e t a d a t ai n t e r c h a n g e ) 是一个o m g 制定的标准，用于在各种工具之间进行u m l 信息交换。目前，r a t i o n a l r o s e 3 5 和a r g o u m l 3 6 都已经支持x m i 。可见，基于x m i 格式的u m l 需求、分 析、设计模型的自动化软件测试技术很有发展前途。 3 2 自动化软件测试技术现状 所谓自动化软件测试是指把软件测试中的部分或全部工作程序化的实现。测试 可以分为多个阶段和层次。对应的自动化软件测试也可以分为多个阶段和层次。 简单地说，测试可分为三个步骤：准备测试实例和执行测试实例的辅助程序、执 行测试实例、评估测试结果。这三个步骤中的部分或全部在某预定义程序帮助下 程序化的实现的测试就可称为自动化软件测试。 最早使用的自动软件测试工具实现的功能有记录测试者输入的测试实例供回 归测试使用。它实际上是种操作捕捉、回放程序。使用这种工具可以明显的降 低回归测试的劳动量。测试者通常只须对被测程序手动执行所有的测试实例一次。 在被测试程序被修改后，可以通过回放程序执行捕捉到的测试操作。这种自动软 件测试工具只实现了对回归测试的准备测试实例和执行测试实例环节的自动化。 但是所有的测试实例还是来自于测试人员的手工输入。而且当被测试程序因设计 错误、逻辑错误等严重错误进行了重大改变，捕捉到的测试操作很可能不再适用， 这时，测试人员必须重新输入改变部分的测试实例。 现在自动化测试工具已经发展成了一些复杂的高度集成的测试套件。这些套件 构成了一个自动化测试框架。我曾经请教过多位同学和同事对自动化软件测试的 看法。他们几乎都说，那很简单，什么自动化，不就是编脚本么? 他们的看法确 实揭示了当前实际应用自动化软件测试的技术现状。自动化测试脚本是软件程序。 面向对象软什白动化单元测试技术研究 它们有自己的适用于软件测试的编程语言或语言扩展。脚本浯言通常嵌入在捕获 回放工具中，该工具带有源码编辑器。语言风格随丌发商而异，所以使用特定产 品的困难度也不同。另外，一些开发商的脚本语言和它们的记录工具比其它开发 商的更健壮。脚本的编写和测试数据的编写一般并行进行，这就是所谓的数据驱 动测试脚本。设计和建立这样的脚本是为了产生一般的测试过程引擎，该引擎独 立于测试数据的内容。这里所说的脚本编写是指测试脚本的编码，它可以使用测 试工具自带的测试脚本语言：也可以使用现有的一些应用编程语言，比如j a v a 或 v is u a lb a s i c ；或者使用标准的脚本语言p e r l 、c g i 或v bs c r i p t ：或者使用操作 系统的命令过程语言( 比如，编写u n i xs h e l l 脚本来执行测试过程) 。 至此，我们可以就自动化软件测试技术的现状给出一个恰当的描述。使用一些 辅助工具交互的生成测试数据，把测试数据保存在数据文件中。在特定测试环境 中，为具体的项目和测试阶段编写特定的独立于具体测试数据的测试脚本。在特 定的测试环境中执行建立的数据驱动的测试脚本。在测试r 志中捕获测试结果， 可以选用自动化测试工具套件( 如r a t i o n a lr o b o t 使用s q a b a s i c ) 提供的自动化 验证方法做测试结果评估。 这种自动化测试模式有以下缺点： 需要人工把测试输入信息( 如设计文档，测试策略等) 转换为测试数据和 测试辅助脚本程序。 在现有测试工具的支持下，测试脚本只能用于测试特定类型系统，编写脚 本成为了实施自动化测试的一个负担，增加了自动化测试的实施代价。 人工生成测试数据不能保证测试的彻底性。 测试结果评估工作量大。现有工具提供的自动验证功能较弱。 3 3 集成测试技术 本节简要介绍面向对象程序自动化集成测试技术。 3 3 1 基于状态的技术 基于状态的测试依靠表示被测试程序状态转换规律的f s m 或状态迁移图。对集 成测试来说，几乎不可能构建出被测试程序的全局f s m ，而且，还受到状态爆炸问 题的阻碍。在处理并发程序时，传统的技术把程序看作静态的互相通信的模块的 集合，然后把程序建模成互相通信的确定性或非确定性f s m 集合。它们系统的把 部件安排进一个f s m 层次，这通过使用抽象( 这样就隐藏了不重要的内部事件) 在每层上减少复合f s m 以及把交互声明分为局部和全局两种类型的方法实现 3 7 。 作为选择，它们可能会剪除多于的不合理的状态迁移，比如通过使用接口方法 3 8 。一些方法甚至在边上保存着无关的细节。与所有f s m 展平复合状态相比， 结果图常常包含很少的节点和边，使得遍历所有的节点和边成为可能。这样，状 态爆炸问题就基本解决了。然后，结果模型就可以被检验特定的属性，比如无死 第二章自动化软件测试 锁或活锁。按照这种测试观点，也可以基于图遍历得到测试实例。诸如“全同步 对覆盖”等策略也已经被提议使用。一个可能的研究方向是更先进的最小图技术。 面向对象程序常常被视为一种特殊的并发程序。可是，诸如对象实例化、持久 化、遗传性之类的面向对象特征为这个观念的适用性添加了许多附加的限制。类 被动态的实例化为对象。对象的状态变化可能跨越程序的生命期。对象之间可能 以无法预料的方式结合与通信。一个类的某些对象的行为特征可能不同于同一类 的其它对象，这取决于实例化的时间和类型。须要开发新测试技术来处理这些新 特征。 3 3 2 基于事件的技术 除了使用基于状态的方法，并行程序的同步序列也可以被看作若干对同步事件 之间的关系。基于同步事件之问的临时关系的技术，如消息序列约束、时序逻辑 等，已经被充分研究。这些方法的一个优点是它们支持事件序列需求分析，无须 关心程序或组件的状态。例如，在c s p e 3 9 中，事件对之间的关系被分为三种 类型：永远有效型，可能有效型和不可能有效型。它们分别代表第一个事件应该、 可以、不应该跟有第二个事件的情况。可能有效的关系又被进一步分为可能正确 型和可能错误型。 面向对象程序实例化的每个对象可能潜在的就是一个并发的成分。这向软件测 试者提出了新的挑战。例如，当我们分析一个静态单元( 也就是一个类) 的时候， 我们可能会断定一些事件对可能有效。可是，当我们分析一个动态单元( 即那个 类的一个单独对象) 时，却发现每对事件只能永远有效或者永远无效。一个在单 个对象中允许可能有效情况的错误实现可能要花费很多精力才能识别出来。如果 允许重载，情况可能会更糟糕。例如，一个对父类对象可能有效的约束对特定子 类的对象却永远有效。 3 3 3 基于正式规范的测试 已经有许多使用正式规范的对面向对象程序在类层次进行测试的研究。例如， d o o n g 和f r a n k 2 0 以及c h e ne ta 1 1 9 ，4 0 已经提出测试一个类的两个对象的 行为等价性，它们使用的是代数规范技术 4 1 。可是，相比之下，很少有基于正 式规范的集成测试研究。合同 4 2 是一种用来描述不同类对象之间的行为依赖和 交互的正式语言。这些行为性质被使用消息传递规则进行定义。也有相关研究提 议在面向对象程序的集成测试中使用合同描述。它为单独消息传递规则和复合消 息传递规则定义了测试程序。不同的正式方法在对面向对象程序的测试的支持上 有各自的优缺点。个可能的研究方向是研究完整的正式测试方法是否可行。例 如，把面向对象与诸如有限状态机和佩特里网之类的基于网的规范结合起来，基 于模型的规范( ! 如o b j e c t - z 4 31 ) ，以及进程代数。 3 3 4 基于u m l 的技术 1 4面向对象软什白动化单元测试技术研究 u m l 4 4 是一种半正式的建模语言，在面向对象程序开发中很受欢迎。u m l 包括 类图、活动图、序列图、协作图、状态图等。它在很大程度上只是一个图形标记 标准，没有规定规格描述格式标准。许多u m l 建模工具都规定了自己的规格描述格 式。此外，还有相关研究提出基于u m l 规范测试面向对象系统。在这种测试方法中， 主测试计划由用例序列组成。每个用例与一个序列图相联系。序列图被正式的翻 译成正则表达式。序列图的每条路径与一个用对象约束语言表述的警戒条件相联 系。 第四章面向对象软件白动化单元测试 第四章面向对象软件自动化单元测试 4 1 概述 类封装了数据( 属性) 和过程( 成员函数、方法) ，是面向对象软件开发中的 基本构造块。而且，类常常被认为是面向对象程序测试的基本单元。在过去的2 0 多年中，有许多技术被用于类测试，其中有一部分使用代数规格描述或基于模型 的规格描述把类建模为抽象数据类型。代数规格描述包含定义句法属性的签名和 描述成员函数属性的公理。基于模型的规格描述使用诸如函数、集合、序列等定 义好的数学模型记录每个类成员函数的前、后置条件。 4 5 ，4 6 从代数规格描述 形式的公理生成了类成员函数序列形式的测试案例。由于类成员函数被处理为不 会对代数规格描述产生影响的数学映射，这种方法不能很好的测试成员函数与状 态属性之间的相互作用。 4 7 把传统的基于图的流技术用于类测试。他们为被测 试类的基于模型的规格描述建立一个与之相关联的流图。把有限状态机( f i n it e s t a t em a c h i n e ，f s m ) 应用于类测试还是一个相对较新的概念 4 8 ，4 9 。基于状态 的类测试方法集中精力于测试类成员函数与状态属性之间的交互。已经有研究工 作证实，通过把状态属性的值看作状态，把类成员函数看作迁移，f s m 可以用来有 效的测试这种交互。 本文研究在类测试中使用u m l 状态图的规格描述。u m l 综合了b o o c h1 5 0 、 r u m b a u g h 5 1 和j a c o b s o n 的方法，已经被o m g 接受为面向对象分析与设计符号的 工业标准。它包含许多用于描述系统静态、动态、使用案例等不同方面的属性的 图表。在这些图表当中，本文致力于从u m l 状态图规格描述生成可执行测试。不 同之处在于，本文采用了一种特殊的规格描述格式来记录状态图，并为状态图引 入了状态属性与状态定义，扩充了u m l 状态图。u m l 状态图被广泛的用于描述类的 动态行为，它实际上是以s t a t e c h a r t s 5 2 为基础的，s t a t e c h a r t s 已经被成功的 应用于反应性系统。u m l 具有几个不同于f s m 的特征，包括嵌套状态和并行状态， 基于事件广播的通信机制以及与状态和迁移关联的动作。 4 2 两种途径 基于状态的类测试的核心思想是迁移覆盖，即测试验证所有的迁移都被正确地 实现。测试一个迁移的过程可以分为三个步骤：把对象置于迁移源状态；输入接 口事件，激发迁移；检查迁移结果状态及响应事件。有两种不同的方法实现迁移 测试：事件法和存取状态变量法。 4 2 1 事件法 把对象置于迁移源状态：从初始状态开始连续输入一串事件使得对象经历一 串迁移到达目标状态。具体操作时，从初始状态开始对象被连续输入目标状态的 识别事件序，同时把接收到的输出事件序列与期望的事件序列