（计算机应用技术专业论文）基于事件关联的gui测试研究.pdf

硕上学位论文 摘要 软件测试是保证软件质量及可靠性的关键 软件测试的开销常常占整个工程 预算的很大比重 目前 g u i 程序已经得到了广泛的使用 进行有效的g u i 测 试变得十分重要 但对g u i 测试的研究工作还相对薄弱 由于g u i 软件的不同 特点使得传统软件的测试技术并不能直接应用于g u i 测试 g u i 测试工作面临 着比传统软件测试更大的困难与挑战 如何为g u i 软件生成测试用例是其中的 一个重要研究课题 本文针对g u i 软件事件驱动型的特点 通过分析事件之间的相互关系 对 事件进行分类 把与业务逻辑无关的事件分离出来单独进行模块单元测试 同时 根据g u i 系统的规模和实际测试要求 取其重要事件构造出较为简化的g u i 事 件关联图 本文详细地介绍了事件的分类方法以及如何对事件之间的约束关系进 行划分 并给出了构造事件关联图的基本步骤 由于目前在g u i 测试方面尚未有标准的测试覆盖准则 因此本论文在参照 传统软件测试中的一些基本测试覆盖准则基础上 给出了适合本方法的四条基于 事件关联的测试覆盖准则 论文提出了g u i 事件关联图的遍历算法 通过该算 法可以得到相应的事件序列 利用等价类划分 边界值分析等方法 对各个事件 的输入空间精简 得到对应的特征值空间 通过对事件特征值空间采取一定的取 值策略 应用到通过g u i 事件关联图的遍历算法得到的事件序列上 进而得到 测试用例 最后 本论文通过一个实例应用 结合我们自主开发的招生管理系统的测试 详细地描述了g u i 事件关联图的构造和测试用例的生成过程 实践证明 这些 方法是可行的 关键词 软件测试 g u i 测试 事件关联 测试覆盖 测试用例生成 a b s t r a c t s o f t w a r et e s t i n gi st h ek e yt og u a r a n t e es o f t w a r eq u a l i t y a n dr e l i a b i l i t y c o s to f t e s t i n go f t e nt a k e sl a r g ep e r c e n t a g eo ft h et o t a lp r o j e c tb u d g e t a p r e s e n gu l i s w i d e l vu s e di nm o s tm o d e r ns o f t w a r ed e v e l o p m e n t t h e r e f o f e i t sq u l t e 姗p o r t a n t a n dn e c e s s a r yt ot e s tg u ie f f i c i c n t l y h o w e v e r t h er e s e a r c h o fg u it e s t i n gi st a r f r o mb e i n ge x t e n s i v e l yp e r f o r m e d s i n c eg u i s o f t w a r eh a sc h a r a c t e r i s t i c st h a ta r e d i f f e r e n tf r o m t h o s eo fc o n v e n t i o n a l s o f t w a r e t e c h n i q u e s d e v e l o p e d t ot e s t c o n v e n t i o n a ls o f t w a r ec a n n o tb ed i r e c t l ya p p l i e dt o g u it e s t i n g m o r ed i f f i c u l t i e s a n dc h a l l e n g e sw e r ef a c e dt 0t h ew o r k0 fg u it e s t i n gt h a nt h o s e o fc o n v e n t l o n a l s o f t w a r et e s t i n g h o wt og e n e r a t et e s t c a s ef o rg u is o f t w a r ei sac r u c l a lr e s e a r c n s u b j e c li n v o l v e di n f o c u s i n go nt h ee v e n t d 洲n g c h a r a c t e r i s t i co fg u is o f t w a r e t h t s p a p e r c l a s s i f i e se v e n t sb ya n a l y z i n gr e l a t i o n s h i p sa m o n ge v e n t s a n dt h e ns e p a r a t e s t n e e v e n t sw i t h o u tr e l a t i o no f0 p e r a t i o nl o g i ct o t a k em o d u l et e s t i n g m e a n w h l l e t h e p a p e rp i c k s o u ti m p o r t a n t e v e n t st o c o n s t r u c tac o m p a r a t i v e l ys 姗p i e uul e v e n t f e l a t i n g c h a r t t h e p a p e rp a r t i c u l a r l y i n t r o d u c e sm e t h o d s o l e v e n t c l a s s i f i c a t i o na n dh o wt oc l a s s i f yr e s t r i c t i n gr e l a t i o n sa m o n g e v e n t s a n dp r o p o s e s b a s i cs t e p so fc o n s t r u c t i n ge v e n t r e l a t i n g c h a r t t h e r ei s n tas t a n d a r do ft e s t i n gc o v e f a g ec r i t e r i ai n g u it e s t i n ga tp r e s e n t b a s e do ns o m eo ft h eb a s i cc o v e r a g ec r i t e r i a so fc o n v e n t i o n a ls o f t w a r et e s t l n g t m s p a p e rp r o p o s e sf o u rt e s t i n gc o v e r a g ec r i t e r i a sw h i c h i ss u i t a b l et ot h i sm e t h o db a s e d o nt h er e l a t i n ge v e n t s a d d i t i o n l y t h ep a p e r b r i n g so u ta n a l g o r i t l l m o ft r a v e r s l n g g u ie v e n t r e l a t i n g c h a r t w i t hw h i c hc a ng e tt h ec o r r e s p o n d i n g e v e n ts e q u e n c e a n d c o n d e n s e st h ei n p u ts p a c eo f e v e n t s c a na t t a i n s t h e e i g e n v a l u es p a c e w l t n e q u i p o l l e n ts p e c i e sc l a s s i f i c a t i o n a n db o u n d a f yv a l u ea n a l y s e b ya p p l y l n gt h e s t r a t e g yo fg e t t i n gv a l u e sf r o mt h ee v e n t e i g e n v a l u es p a c et o t h ee v e n ts e q u e n c e w h i c hi sg e t t i n gf r o md ea 1 9 0 r i t h mo fg u i e v e n t r e l a t i n g c h a r t w ec a ng e n e r a t et n e t e s tc a s e f i n a l l y t h i s p a p e r d e s c r i b e st h ep r o c e s s o fg u le v e n t r e l a t l n g c h a r t c o n s t r u c t i o na n dt e s tc a s eg e n e r a t i o nb y a p p l y i n g t h em e t h o di nt h ee n r o l l m e n t m a n a g e m e n ts y s t e md e v e l o p p e db y o u r s e l v e s i ti s p r o v e d t h e s em e t h o d sa r e f e a s i b l e m 硕二l 学位论文 k e y w o r d s s o f t w a r et e s t i n g g u it e s t i n g e v e n tr e l a t i n g t e s t i n gc r i t e r i a t e s tc a s eg e n e r a t i o n 基于事件关联的g u l 测试研究 插图索引 图2 1 软件测试的v 模型 6 图2 2 软件测试的w 模型 7 图2 3 软件测试技术分类 一9 图2 4g u i 软件测试框架 1 4 图2 5 两个变量程序的输入域 1 8 图2 6 两个变量程序的边界值分析 1 8 图3 1g u i 状态与事件的关系 2 0 图3 2 事件执行序列 2 1 图3 3 学生培训报到用户界面 2 4 图3 4 学生培训报到界面对应的事件关联图 一2 4 图3 5 事件关联图中的回路 2 6 l 硕士学位论文 附表索引 表5 1 学生培训报到请假用例描述 3 6 表5 2 测试事件序列 3 7 表5 3 事件的输入空间以及特征值空间 3 7 湖南大学 学位论文原创性声明 本人郑重声明 所呈交的论文是本人在导师的指导下独立进行研究所 取得的研究成果 除了文中特别加以标注引用的内容外 本论文不包含任 何其他个人或集体已经发表或撰写的成果作品 对本文的研究做出重要贡 献的个人和集体 均已在文中以明确方式标明 本人完全意识到本声明的 法律后果由本人承担 作者签名 饷夫池 日期 沙 矿年丁月2 争日 学位论文版权使用授权书 本学位论文作者完全了解学校有关保留 使用学位论文的规定 同意 学校保留并向国家有关部门或机构送交论文的复印件和电子版 允许论文 被查阅和借阅 本人授权湖南大学可以将本学位论文的全部或部分内容编 入有关数据库进行检索 可以采用影印 缩印或扫描等复制手段保存和汇 编本学位论文 本学位论文属于 1 保密口 在年解密后适用本授权书 2 不保密团 请在以上相应方框内打 作者签名 俩夫池 日期 加驴吕年岁月2 乒日 刷磁名力寺数醐 训蛑朋2 垆日 硕上学位论文 1 1 课题背景和意义 第1 章绪论 质量是软件产品的一项重要指标 为了保证产品的质量 不仅需要在软件过 程方面进行严格控制 而且需要对软件本身进行检测 在目前形式化方法和程序 正确性证明还无法成为实用性方法的情况下 软件测试在将来相当长的时间内仍 然是软件产品质量保证的有效方法 1 1 近年来 国内软件行业迅速发展 但离国 际先进水平仍然有不小的差距 国内软件开发团体主要将研究重点放于开发技术 和算法上 而在软件过程 特别是软件测试上研究较少 软件测试是控制软件质 量的重要环节 只有保证良好的产品质量才能在国际软件市场上更加具备竞争 力 因此 对软件质量的测试研究是一个非常有实际价值的课题 图形用户界面 g u i 已经成为用户与软件交互的一种必不可少的方式 g u i 是软件底层代码的前端 软件的使用者通过g u i 和软件进行交互 g u i 通过消 息传递或者方法调用的方式与底层代码进行交互 由于图形用户界面提供了使用 者一个非常直观的使用环境 因此现在g u i 程序几乎成为软件开发的事实准则 1 2 1 软件开发人员越来越多地使用快速开发环境从而构建g u i 程序 这使得 g u i 几乎占据了一个应用程序6 0 的代码量 3 另外 现在越来越多对安全性有着 较高要求的程序也采用了g u i 方式 所有这些使得g u i 界面本身的安全性 正 确性及鲁棒性成为了影响整个应用程序性能的一个重要因素 因而g u i 的测试 变得尤为重要 g u i 软件测试的整体目标和传统软件测试的目标 4 5 l 是一致的 即以最少的 时间和人力找出软件中潜伏的各种错误和缺陷 6 1 g u i 软件和传统的软件有许多 不同的特点 g u i 软件以用户事件作为输入和以图形化数据作为输出 它采用的 事件驱动模式 具有事件触发的随机性 多任务以及消息传递等特点 7 与传统 的顺序型程序有很大不同 最大不同就是程序员预先无法准确知道程序实际的执 行流程 另外 g u i 交互空间巨大 其条件组合的数量庞大且多变 传统的测试 手段难以覆盖所有的运行状态 因此g u i 软件所具有的一些特性使得传统的软 件测试方法并不完全适用于g u i 的测试 这些特性给软件测试带来了许多新的 影响 8 9 j 因此g u i 测试虽然传承于传统的软件测试 却又与之不尽相同 它是 在软件测试基础之上兴起的一个新的测试领域 尽管g u i 的应用不断增长 但作为一个新的测试领域 对g u i 测试的研究 依然还很薄弱 现有的g u i 测试方法大多仅仅处于理论层次的研究 而另外一 基于事件关联的g u i 测试研究 些方法虽然已经针对不同的需求应用于实践中 但是这些已有的成品大多数都是 基于录制 回放机制的 它们将用户使用的被测试系统的操作流程记录 然后将 操作流程进行简单的修改 作为测试用例重新驱动被测试系统进行运行 虽然这 种方法对特定的情形是有益的 但是捕获 回放功能大约仅仅是其全部功能的 1 1 0 而且这种方式不能产生新的测试用例 一般只用于回归测试 再者 此种 工具生成脚本到执行完测试的整个过程也相当的耗费时间 这种工具的缺陷使我 们在测试中不能过分依赖它 当业务出现变动时 这样的工具无法满足测试需求 存在着很大的局限性 在这样的背景下 研究一种行之有效的g u i 测试方法将 具有重要的现实意义 1 2 国内外研究现状 在面向对象软件测试当中 g u i 测试是当前研究的难点 虽然从用户的角度 来说 g u i 技术让软件变得更易使用和操作 但这却使得软件开发工作越来越复 杂 而同时 测试g u i 比测试传统软件要复杂的多 造成g u i 测试困难的主要 原因有 g u i 可能拥有大量需要测试的状态 影响g u i 的输入与事件的不同排 列数目使得输入空间异常巨大 g u i 系统中可能存在非常复杂的依赖关系 1 0 l o s t r a n d 等人提出了一种用于g u i 的测试环境 测试开发环境 t d e 1 1 它 将测试者 测试设计库和利用捕获 回放技术完成测试生成的工具结合在一起 在目前比较流行的测试工具中 m i 的t e s t d i r e c t o r 与w i n r u n n e r i b mr a t i o n a l 的t e s t m a n a g e r 与r o b o t 等工具与这个测试开发环境相类似 将测试计划 测试 管理 测试设计和测试执行等过程结合在一起 在面向对象软件测试技术中 以类的有限状态机 f s m 模型 1 2 1 3 1 4 1 5 和其 状态转换图为依据的基于状态测试得到了最有为广泛的研究 它可以完美地表示 g u i 软件中的所有状态 但是将这种模型应用于g u i 测试用例生成时会有状态 爆炸问题 为了有效地控制状态数目 s h e h a d yrk s i e w i o r e kd p 在f s m 的基 础上 建立了v f s m 变量有限状态机 模型 1 6 定义了新的全局变量 与f s m 已有状态相关联 以有效地减少状态数目 从而相应地减少需求的测试用例数目 但是 尽管如此 这种模型产生的状态和测试数目仍然相当巨大 而且此方法需 要测试者手动插入确认检查点 无法实现测试自动化 a t i fm m e m o n 1 7 1 8 等人先后提出了基于目标的测试用例生成方法以及采用 人工智能规划自动产生g u i 软件测试用例的方法 其核心思想是以g u i 软件的 某个测试用例所包含的事件及其相互之间的交互作为功能覆盖标准 将g u i 划 分为g u i 组件 g u ic o m p o n e n t s 结合g u i 组件内事件覆盖准则和g u i 组件 之间的覆盖准则 使得以事件序列描述测试用例成为可能 在国内 也有很多学者已经在g u i 软件测试方面取得了很大的成果 如 硕士学位论文 首都师范大学的顾玉良博士针对具有图形化界面的面向对象软件的测试 提出了 一种界面类对象建模技术 j 该技术体现了对象的封装 通信和动态特征 使 得对象状态易于识别 模型规模容易控制 并且支持建立被测试对象的控制和观 察机制 北京航空航天大学的刘超教授提出了一种程序交互执行流程图 p i e f p r o g r a mi n t e r a c t i v ee x e c u t i o nf l o wc h a r t 用以描述交互式软件的各种可 能交互执行过程 基于被测程序的交互执行流程图 进一步提出了功能测试的若 干基本测试覆盖准则 测试用例生成策略以及自动化方法 2 0 1 浙江大学的杜栓 柱针对具有图形用户界面且进行事务处理软件系统的功能测试 从界面构件间关 联特征触发 提出了界面构件关联图 2 1 1 描述界面中各个构件之间的相互联接 相互制约关系 进而提出了基于界面构件关联图的软件测试覆盖准则和测试用例 生成方法 以上技术大多从基于功能的角度探讨了g u i 测试方法 对g u i 测试做出了 指导性与实践性的研究 他们的具体方法各有不同 各有其优势与局限 基于对 象建模的g u i 测试技术使得界面对象易于识别 但是测试用例的覆盖程度不够 理想 基于界面构件关联图的测试方法有较好的交互关系和覆盖准则 但是关联 提取复杂 导致关联图冗余 基于v f s m 的测试方法减少了f s m 的简单状态冗 余 但是v f s m 到f s m 的转化又难以优化 这些g u i 测试方法的成功与否 都 依赖于通过用户手册 代码或是设计文档所获取信息的准确程度和广度 1 3 论文工作 本论文是在总结前人研究成果的基础上 提出了g u i 事件关联图的构建过 程 并以此为基本模型 进一步提出测试用例的生成方法 从而达到对g u i 系 统测试的目的 本文较详细地阐述了如何对g u i 系统中的事件进行分类 以及 划分事件之间的约束关系 进而根据系统的不同测试要求 去除非重要事件 构 造出较简化的g u i 事件关联图 同时 本文基于传统软件测试中的测试覆盖准 则 给出了基于事件关联的测试覆盖准则 最后论文提出了测试用例生成规则及 测试路径遍历算法 阐述了测试用例生成的基本步骤 通过实例应用 说明该方 法具有一定的有效性和实用性 论文的主要工作如下 1 研究了g u i 测试的特点 g u i 测试所面临的困难以及g u i 测试的主要 方法和步骤 2 针对g u i 测试的特点 给出了基于g u i 事件关联图的测试方法 3 提出了对g u i 事件的分类方法以及它们之间的约束关系 并给出g u i 事件关联图的构建过程 基于事件关联的g u i 测试研究 4 研究了传统软件的测试覆盖准则 并在此基础上给出了适合本文方法 的若干条g u i 测试覆盖准则 5 提出了g u i 事件关联图的遍历算法 限制循环路径多次执行 从而获 得测试事件序列 6 论文给出了基于事件关联图的测试用例生成的基本步骤 并应用实例 具体阐述整个过程 1 4 论文结构 论文共分五章 按以下方式组织 第一章为绪论 概述了g u i 测试的研究背景和意义 当前国内外的研究现 状 以及全文的主要工作 第二章介绍了软件测试的基本概念和相关知识 给出了软件测试中两种典型 的模型 v 模型和w 模型 在此基础上又较详细地介绍了几种常见的软件测试 方法及其它们的分类关系 同时又给出了g u i 测试的基本步骤 较详细地描述 了g u i 测试的基本框架 最后介绍了一些本文中将使用到的相关术语和技术及 其它们的研究状况 第三章主要提出了g u i 事件关联图的构建过程 首先给出了g u i 事件的表 示方法 这是基于事件关联的g u i 测试的前提工作 其次介绍了如何将g u i 事 件进行分类以及划分事件之间的约束关系 最后 给出了构件g u i 事件关联图 的基本步骤和注意事项 第四章是基于事件关联图的g u i 测试用例生成方法 本章首先在传统软件 测试覆盖准则的基础上 给出了适合本文的测试覆盖准则 然后详细地介绍了基 于事件关联图生成测试用例的规则 测试路径的遍历算法以及用例生成的基本步 骤 第五章通过实例应用详细地描述了如何g u i 事件关联图的构建以及基于此 事件关联图的测试用例生成过程 最后是本文的总结 一方面对论文工作进行了总结 另一方面对g u i 测试 的进一步研究提出了展望 硕r 上学位论文 第2 章软件测试和g u i 测试概述 软件测试技术是和程序联系在一起的 自从有了程序 也就有了软件测试 大量统计资料表明 软件测试的工作量往往占软件开发总工作量的4 0 以上 在极端情况下 测试那种关系人生命安全的软件所花费的成本 可能相当于软件 工程其他开发步骤总成本的3 5 倍 2 2 1 仅就测试而言 它的目标是发现软件中 的错误 但是 发现错误并不是我们的最终目的 软件工程的根本目标是开发出 高质量的完全符合用户需求的软件 2 0 世纪9 0 年代后半期 面向对象软件测试在理论和实践上都得到迅速发展 由于图形用户界面 g u i 软件采用事件驱动模式 具有事件触发的随机性 多 任务性以及消息传递等特点 与传统顺序型软件有很大不同 因此它的测试面临 着更多的挑战 需要更多的研究工作 2 1 什么是软件测试 由于软件及软件错误的复杂性 长期以来 人们对软件测试的认识一直是模 糊的 许多科学家从不同的角度给出了软件测试的不同定义 但总体来看 都是 不全面的 2 3 1 在g j m y e r s 的经典著作 软件测试之艺术 t h ea r to fs o f t w a r e t e s t i n g 中 给出了测试的定义 程序测试是为了发现错误而执行程序的过程 该定义明确给出了软件测试就是为了发现软件中的错误 这一概念目前被业界所 公认 经常被引用 实际上 这只是一个狭义的概念 2 4 1 因为他认为测试是执 行程序的过程 也就是传统意义上的测试 在代码完成后 通过运行程序来发 现程序代码或软件系统中错误 但是 这种意义上的测试是不能在代码完成之前 发现软件系统需求 发现设计上的问题 把需求 发现设计上的问题遗留到后期 这样就可能造成设计 编程上的部分返工 增加软件开发的成本 延长开发的周 期等 需求阶段和设计阶段的缺陷产生的放大效应会加大 这非常不利于保证软 件质量 2 5 1 这种狭义论是受软件开发瀑布模型影响 正是为了更早地发现问题 所以将测试延伸到需求评审 设计审查活动中去 也就是将 软件质量保证 的部分活动归为测试活动 实际上 在软件开发实际操 作中 常常将软件测试和质量保证 这两种努力 e f f o r t s 合并起来 2 6 1 从标准论来看 软件测试可以定义为 验证 v e r i f i c a t i o n 和 有效性确认 v a l i d a t i o n 活动构成的整体 即软件测试 v v 验证 是检验软件是否已 正确地实现了产品规格书所定义的系统功能和特性 验证过程提供证据表明软件 相关产品与所有生命周期活动的要求相一致 有效性确认 是确认所开发的软件 基于事件关联的g u l 测试研究 是否满足用户真正需求的活动 2 7 1 相当于 保持对软件需求定义 设计的怀疑 一切从客户出发 理解客户的需求 发现需求定义和产品设计中的问题 这主要 通过各种软件评审活动来实现 1 9 8 3 年 i e e e 给出的定义是 使用人工或自动手段来运行或测定某个系 统的过程 其目的在于检验它是否满足规定的需求或是弄清楚预期结果与实际结 果之间的差别 应该说该定义是比较全面的 软件测试是贯穿整个软件开发生 命周期 对软件产品 包括阶段性产品 进行验证和确认的活动过程 其目的是 尽快尽早地发现在软件产品中所存在的各种问题一一与用户需求 预先定义的不 一致性 2 2 软件测试模型及方法介绍 软件测试学与软件工程学的发展依依相关 相辅相成 2 引 对于比较先进的 测试理念 测试工程师应该贯穿于软件工程的整体过程中 在软件生存期的各个 阶段都可能存在错误 不同阶段的错误性质是不同的 不同的错误又对应不同的 测试方法 2 2 1 软件测试的经典模型 软件测试模型与软件测试标准的研究是随着软件工程的发展而越来越深入 在2 0 世纪8 0 年代后期p a u lr o o k 提出了著名的软件测试的v 模型 旨在改进软 件开发的效率和效果 v 模型反映出了测试活动与分析活动的关系 在图2 1 中 从左到右描述了基本的开发过程和测试行为 非常明确地标注了测试过程中存在 不同类型的测试 并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应 关系 图2 1 软件测试的v 模型 硕上学位论文 v 模型指出 单元测试和集成测试应检测程序的执行是否满足软件设计的需 求 系统测试应检测系统功能 性能的质量特性是否达到系统要求的指标 验收 测试确定软件的实现是否满足用户需求或合同的要求 但v 模型存在一定的局 限性 它仅仅把测试作为编码之后的一个阶段 是针对程序进行的寻找错误的活 动 而忽视了测试活动对需求分析 系统设计等活动的验证和确认功能1 2 9 1 e v o l u t i f 公司针对v 模型的缺陷 相对于v 模型 提出了w 模型的概念 w 模型增加了软件各开发阶段中应同步进行的验证和确认活动 如图2 2 所示 w 模型由两个v 字型模型组成 分别代表测试与开发过程 图中明确表示出了 测试与开发的并行关系 图2 2 软件测试的w 模型 w 模型强调 测试伴随着整个软件开发周期 而且测试的对象不仅仅是程 序 需求 设计等同样要测试 也就是说 测试与开发是同步进行的 w 模型 有利于尽早的全面地发现问题 例如 需求分析完成后 测试人员就应该参与到 对方需求的验证和确认活动中 以尽早地找出缺陷所在 同时 对需求的测试也 有利于及时了解项目难度和测试风险 及早制定应对措施 这将显著减少总体测 试事件 加快项目进度 3 0 1 但w 模型也存在局限性 3 1 在w 模型中 需求 设计 编码等活动被视为 串行的 同时 测试和开发活动也保持着一种线性的前后关系 3 2 1 上一阶段完 全结束 才可正式开始下一阶段工作 基于事件关联的g u i 测试研究 2 2 2 软件测试基本方法及分类 软件测试的方法和技术是多种多样的 3 3 1 对于软件测试技术 可以从不同 的角度加以分类 从是否需要执行被测试软件的角度 可分为静态测试 s t a t i c t e s t 和动态测试 d v n a m i ct e s t 从测试是否针对系统的内部结构和具体实现 算法的角度来看 可分为白盒测试 w h i t et e s t 和黑盒测试 b l a c kt e s t 1 静态测试 静态测试的基本特征是对软件进行分析 检查和测试时 不实际运行被测试的程序 它可以对各种文档进行测试 是软件开发中十分有效 的质量控制方法之一 在软件开发过程中的早期阶段 由于可运行的代码尚未产 生 不可能进行动态测试 而这些阶段的中间产品质量直接关系到软件开发的成 败与开销的大小 因此 在这些阶段 静态测试的作用尤为重要 目前 比较常 用的静态测试方法有 y o u r d o n 的结构化走通法和f a g a n 检查法1 3 4 j 2 动态测试 静态测试只能定性地分析软件的质量 而不能定量 从这 种意义上讲 静态测试是有很大的局限性 但这并不能否定静态测试的重要性 所谓动态测试 就是通过运行软件来检查软件的动态行为和运行结果的正确性 因此 动态测试只存在于软件生存期和编码阶段之后 3 5 l 动态测试包括两个基 本要素 一是被测程序 二是用于运行软件的数据 称为测试数据 程序一次运 行所需要的测试数据称为测试用例 所以测试数据是测试用例的集合 3 白盒测试 白盒测试也称结构测试或逻辑驱动测试 它是知道产品内 部工作过程 可通过测试来检测产品内部动作是否按照规格说明书的规定正常进 行 按照程序内部的结构测试程序 检验程序中的每条通路是否都有能按预定要 求正确工作 而不顾它的功能 白盒测试的主要方法有逻辑驱动 基路测试等 主要用于软件验证 白盒 法全面了解程序内部逻辑结构 对所有逻辑路径进行 测试 在使用这一方案时 测试者必须检查程序的内部结构 从检查程序的逻辑 着手 得出测试数据 贯穿程序的独立路径是天文数字f 3 6 但即使每条路径都 测试了仍然可能有错误 第一 穷举路径测试决不能查出程序违反了设计规范 即程序本身是个错误的程序 第二 穷举路径测试不可能查出程序中因遗漏路径 而出错 第三 穷举路径测试可能发现不了一些与数据相关的错误 4 黑盒测试 黑盒测试也称功能测试或数据驱动测试 它是在已知产品 所具有的功能 通过测试来检测每个功能是否都能正常使用 在测试时 把程序 看作一个不能打开的黑盒子 在完全不考虑内部结构和内部特性的情况下 测试 者在程序接口进行测试 它只检查程序功能是否按照需求规格说明书的规定正常 使用 黑盒测试方法主要有等价类划分 边值分析 因一果图 错误推测等 3 7 l 主要用于软件确认测试 黑盒 法着眼于程序外部结构 不考虑内部逻辑结构 针对软件界面和软件功能进行测试 黑盒 法穷举输入测试 只有把所有可能的 硕上学位论文 输入都作为测试情况使用 才能以这种方法查出程序中所有的错误 实际上测试 情况有无穷多个 人们不仅要测试所有合法的输入 而且还要对那些不合法但是 可能的输入进行测试 动态测试和静态测试是一种分类方法 黑盒测试与白盒测试又是另外一种分 类方法 二者是有许多交叉的 动态测试含有黑盒测试与白盒测试 静态测试一 般只含有白盒测试 黑盒测试一般都是动态测试 而白盒测试一般都包含动态测 试和静态测试 图2 3 是对现有软件测试技术的具体分类 3 8 l 软件测试技术 静态测试技术动态测试技术 广 t t 1 广 代代桌静棼 白盒测程序与规约相结黑盒测 码码面态术 试技术合的测试技术试技术 皇耋笙坌登广 广 广l r 广1 广1 广 1 一 t 一 查查查析审盎矗存在壶薮鲁卤翔遗壶状季 制测号序异据价果定值交态务 流试执插测流类图表分实测流 测行装试测划析验试测 试 试分设试 厂 r 广 广 1 计 语分条判件路 全全全用 句支件定覆径 定引定覆 覆覆覆三盖覆 值 用值盖 盖盖盖条盖 覆覆引 盖盖 图2 3 软件测试技术分类 2 3 什么是g u i g u i 是指图形用户界面 g r a p h i c su s e ri n t e r f a c e 它使用图形的方式 借 助菜单 按钮等标准界面元素和鼠标的操作 帮助用户方便地向计算机系统发出 指令 执行操作 并将系统运行的结果同样以图像方式显示给用户 当今绝大部 分的软件通过图形用户界面和用户进行交互 图形用户界面使用现实生活中我们 熟悉的表示方法 如按钮 菜单 桌面 透过窗口的视图 垃圾箱和房间的布局 软件的使用者通过事件来与g u i 进行交互 他操作g u l 对象的方法就像操作现 实事物的方法一样 g u i 具有层次结构 这种层次结构可以通过窗口 对话框 层次菜单中事件的分组表现出来 定义2 1 一个图形用户界面是一个软件系统的层次化 图形化的前端 它 从固定事件集中接受用户产生 系统产生的事件作为输入 并生成确定性的图形 化输出结果 一个g u i 包括一个或多个对象 每个对象拥有其固定的属性集 在任何g u i 执行期间 对象的属性所具有的都是离散值 这些离散值的集合便 基于事件关联的g u i 测试研究 构成了g u i 的状态 上面定义的g u i 仅仅是众多g u i 类型中的某一类 这类g u i 都有一个固定 的事件集合 这些事件在具有离散属性值的g u i 控件上执行 产生确定的输出 结果 本文所有的方法 技术都只针对于此类g u i 而言的 2 4g u i 软件测试的特点 虽然应用程序基于代码的测试过程包含了对g u i 底层代码的测试 但由于 g u i 程序不同于传统的应用软件 它的图形界面和功能代码是相互独立的 相同 的代码可能会对应不同的界面 不同版本的g u i 可能只对于界面部分做了调整 而功能代码部分却没有改变 功能代码所对应的消息或方法是对应于它所关联的 事件的 对这些代码的测试只检查了这些事件的独立执行情况 而对事件间交互 则没有明显的效果 很多情况下 g u i 中应用的控件无法得到全部的源代码 所 以应用基于代码的方法对g u i 进行测试还是不够的 只有将对g u i 的测试从基 于代码的测试中分离出来 综合应用g u i 测试技术和基于代码的测试技术 才 能对g u i 程序进行全面有效的测试 g u i 测试与传统软件测试主要有以下几方 面的不同 1 一个g u i 的交互空间是十分巨大的 每一个不同的g u i 事件序列将导 致一个不同的状态 每一个g u i 事件需要用所有的这些状态来评价 大量可能 的状态导致大量需要广泛测试的输入重排列 2 由于g u i 程序属于事件驱动程序 用户通过与图形的交互来触发相应 的事件进而与内部的代码及业务逻辑发生交互 因此 不能像传统软件那样 通 过所使用的测试用例到底覆盖了多少内部的代码 执行路径 分支 条件等来度 量覆盖率 而是看每一代码有多少不同的状态被测试了 3 测试用例执行中每一步后的状态验证也是g u i 测试中非常重要的方面 一个不正确的g u i 状态将导致意想不到的结果 因此 一旦发现错误 必须立 刻终止测试用例的执行 另外 如果不在每一步后进行状态的检测 就很难识别 错误的真正原因 4 由于用户对于各个事件的不同触发顺序使得每一次实际执行的完整程 序都是不一样的 换句话说 这相当于将完整程序分割成许多程序段 事件代码 段 每次按不同顺序 触发事件的顺序 组成完整程序运行 因此 这种 乱序 执行 方式使得编程人员不能像以往那样对自己所编制程序的行为有一个完整的 把握 由于交互空间的庞大 必然会有大量隐含的操作路径被实现人员无意引入 程序 这些操作路径多数会引起潜在的安全漏洞设置导致整个程序的崩溃 5 g u i 程序的回归测试对于测试人员来说也是个挑战 即使简单地修改 事件代码而不对原有界面或操作模式做修改也将产生问题 因为改变的代码将改 硕上学位论文 变许多原有的状态并可能引入新的状态 由于现在越来越多地使用快速开发工 具 界面的变更变得十分方便 这导致了图形用户界面在不同版本的软件中可能 产生很大的变化 2 5g u i 软件测试的一般步骤 虽然由于g u i 自身的特点 对它的测试内容和测试技术不同于传统的软件 测试 但对它们测试的基本过程却是一致的 g u i 测试过程有如下几个阶段 1 决定测试目标 在g u i 测试的第一阶段 首先要决定测试什么 即决 定对哪些g u i 事件或事件序列进行测试 2 生成测试输入 g u i 测试输入可以参照软件的规格说明或软件的结构 它由初始条件和事件序列构成 对g u i 系统来说 测试输入由事件所构成 例 如鼠标点击 菜单选择 键盘输入 对象操作等行为 3 生成预期输出 对应测试输入中事件序列的 每个事件 生成每个事件 执行后的预期结果 4 测试的执行及验证 在测试输入中的初始条件下 顺序执行事件序列 中的事件 并对比每个事件的预期输出与实际输出 当两者出现不匹配的情况时 表示当前测试不能通过 5 判断测试的充分性 在执行了部分或全部的测试后 分析所有测试执 行情况 判断是否达到预期的要求 对g u l 系统而言 需要进行如此的分析以 确定已被测试过与未被测试的g u i 状态的事件以及其结果状态 因为在覆盖标 准中要求的内容并非总是会被测试到 可能会有测试不到的部分 故这一步骤也 不可忽视 6 回归测试 当程序变更后 针对g u i 的变化情况 选择部分的测试用 例或重新生成新的测试用例对更改部分进行重新测试 回归测试用例集包括 原 有测试用例的一部分 用于软件测试原有软件中受到修改影响的那一部分 新的 测试用例 用于测试软件中受到修改影响但又没有被原测试用例测试到的部分 在g u i 软件中 回归测试包括分析g u i 对象外观的改变 选择需要重新运行的 测试用例及生成新的测试用例 一般来说 g u i 测试方法都必须要执行上面的全部步骤 目前的一些情况是 g u i 测试者大多依赖于捕获 回放工具来测试g u i 系统 然而使用这一类工具测 试过程中需要大量的人工操作 使得g u i 测试变的效率很低 代价昂贵 为更有效的测试g u i 系统 则需要对上述的g u i 测试的每一步骤都采用自 动化的测试方法 一种方法是为自动化测试g u i 测试的每一步骤而开发独立的 工具和技术 国内外已对这方面有一定的研究 并设计了一些自动化工具 例如 使用有限状态机 f s m 模型生成测试用例 开发测试用例生成器 4 0 1 并应用 基十事件关联的g u i 测试研究 拉丁平方的方法进行回归测试 4 1 等 虽然此类独立工具与技术对于g u i 测试某 些方面的自动化有一定作用 但它们都没有从g u i 测试的整体过程来考虑 而 且 由于这些方面的g u i 测试工具和技术大多是独立开发的 相互之间很有可 能并不兼容 对g u i 测试工作者来说 使用这类独立的测试工具 就意味着同 时需要学习每一种工具的各种不同的特性 因而 在实际的g u i 测试工作中综 合使用这些工具可能是比较困难的 2 6 针对g u i 软件的测试框架 2 6 1 开发g u i 测试框架的挑战 目前 在g u i 测试方面已经取得了不少宝贵的研究结果 很多专家学者从 不同角度对g u i 测试进行研究 虽然这些方法在某些方面非常有用 但是它们 忽略了整个过程 另外 在实践中 由于各种工具之间不兼容 使得某个工具产 生的结果不能被另一个工具直接使用 因此 开发一个g u i 测试框架就显得尤 为重要 开发一个g u i 软件测试框架 它包括执行g u i 软件测试各个步骤的技术 在实现g u i 测试框架的过程中必须注意如下几个方面 4 2 1 g u i 软件测试各个阶段的技术必须统一起来 采用相同的表示方法 以便一个阶段采用的工具与另一阶段的工具相兼容 2 g u i 软件测试各个阶段都尽可能自动化 以便简化软件测试者的工作 3 g u i 软件测试各个阶段应该是高效的 因为软件测试通常是一个乏味 的 代价昂贵的过程 低效率往往令人沮丧 并使人最终放弃 4 各阶段技术应该是鲁棒性的 当g u i 进入一个异常状态时 测试算法 应该检查出错误状态和所有可能的用于调试的信息 5 测试框架必须是可移植的 在一个平台上 产生和收集到的测试的信 息 如测试用例 预期结果 覆盖报告和错误报告 应该可以在相同g u i 软件 运行的其它平台上可以使用 上述的综合g u i 测试框架开发工作是一个复杂困难的过程 开发符合上述 目标的g u i 软件测试框架极富挑战性 4 引 1 如何构建能适用于g u i 测试各个步骤不同技术的g u i 表示方法 为了 有效的捕捉g u i 事件 构建的g u i 表示方法需要高度的抽象 另外 这种表示 方法必须能够全面地捕捉g u i 界面信息 g u i 底层事件代码信息 以便能更加 全面的检测g u i 软件的正确性 2 如何开发g u i 测试覆盖准则 由于g u i 的特性 g u i 测试的覆盖准则 不同于传统软件的覆盖准则 因此需要开发一种能恰当分析g u i 表示方法 并 硕士学位论文 确定所选测试用例是否充分测试g u i 的g u i 测试覆盖准则 3 如何选择一种好的测试用例生成方法 使生成的测试用测既能尽可能 多地测出界面错误 又能尽可能多地测出事件代码引发的错误 另外一个有关测 试用例产生的难题是如何控制g u i 软件的状态 比如 如何使g u i 软件进入测 试用例的初始状态 对于每个测试用例 可能需要执行若干个事件后才能获得它 需要的初始状态 4 g u l 软件的测试结果分析不同于传统软件的测试结果分析 测试结果 分析用于确定软件在测试时执行结果是否正确 在传统的软件测试中 测试结果 分析在测试用例执行完之后才触发 测试用例执行最终的输出结果与预期输出结 果进行比较 对于g u i 软件 测试结果分析和测试用例的执行是交错进行的 因为不正确的g u i 状态会引起非预期的结果 如果此时继续执行无效的测试用 例 测试用例中的事件就可能根本无法找到g u i 对象 因此一旦软件运行出现 错误 测试用例的执行应当立刻终止 如果测试用例每一步执行后不进行验证 可能很难找到错误的真正原因 因为可能出现最终输出结果正确而中间输出结果 不正确的情况 因此在g