（测试计量技术及仪器专业论文）软件测试自动化框架的研究与实现.pdf

南京邮电大学 硕士学位论文摘要 学科、专业：工学测试计量技术及仪器 研究方向：智能丛墨皇塑达丕统 作 题目：软件测试自动化框架的研究与实现 i l ll l ii i lli i il l lulll y 17 5 4 8 3 7 英文题目：r e s e a r c h & i m p l e m e n t a t i o n o fs o f t w a r et e s t a u t o m a f i o nf r a m e w o r k 主题词：软件测试；软件测试自动化框架；关键字驱动；功能测试工具 k e y w o r d s ：s o f t w a r et e s t ；s o f t w a r et e s ta u t o m a t i o nf r a m e w o r k ；k e y w o r dd r i v e n ；f u n c t i o n t e s tt o o l s 南京邮电大学硕士研究生学位论文 摘要 摘要 随着计算机技术的迅速发展，软件的应用范围越来越广泛。为了保证软件产品的质量， 软件测试越来越受到人们的重视。实施测试自动化已经是软件测试行业一个不可逆转的趋 势。测试自动化的实施需要一个完整的测试管理系统，即需要设计一套合理的测试自动化 框架。因此对测试自动化框架的研究具有很重要的意义。 基于这样的前提，本文对现有的测试自动化技术和测试工具进行研究，针对目前常用 的测试框架对测试工具有依赖性的缺点，提出了一种混合测试自动化框架h t a f ( h y b i r d t e s t i n ga u t o m a t i o nf r a m e w o r k ) 。此框架具备一个独立的驱动引擎，基于关键字驱动思 想，独立于通用软件测试自动化框架s t a f 和功能测试工具，但结合了两者的功能。最后， 本文将混合测试自动化框架应用于实际的软件测试项目中，实现了自动从版本服务器下载 并安装产品、配置测试环境、自动执行测试并生成测试报告反馈给测试人员，完成了全自 动化测试，极大地提高了测试的效率，节约了相当多的人力、物力、时间等资源，同时此 框架也适用于其他软件产品的功能性测试。 关键词：软件测试；软件测试自动化框架；关键字驱动；功能测试工具 南京邮电大学硕士研究生学位论文 a b s t r a c t w i t ht h er a p i dd e v e l o p m e n to fc o m p u t e rt e c h n o l o g y , t h ea p p l i c a t i o ns c o p eo fs o f t w a r ei s m o r ea n dm o r ew i d e s p r e a d i no r d e rt oe n s u r et h eq u a l i t yo fs o f t w a r ep r o d u c t s ，p e o p l eh a v ep a i d m o r ea n dm o r ea t t e n t i o nt os o f t w a r e t e s t i n g t h ei m p l e m e n t a t i o no ft e s ta u t o m a t i o ni sa l r e a d ya n i r r e v e r s i b l et r e n di ns o f t w a r et e s t i n gi n d u s t r y i tw o u l dr e q u i r eac o m p l e t et e s tm a n a g e m e n t s y s t e m , t h a ti st os a yw en e e dd e s i g n i n gar e a s o n a b l et e s ta u t o m a t i o nf r a m e w o r k t h e r e f o r e ， t h e r e sv e r yi m p o r t a n ts i g n i f i c a n c et or e s e a r c ht e s ta u t o m a t i o nf r a m e w o r k b a s e do nt h i sp r e m i s e ，t h i sp a p e rr e s e a r c h e so nt h ee x i s t i n gt e s ta u t o m a t i o nt e c h n i q u e sa n d t e s t i n gt o o l s b e c a u s et h ec o m m o nt e s tf r a m e w o r kh a st h ed e p e n d e n c ew i t ht h et e s tt o o l s ，t h i s p a p e rp u t sf o r w a r dah y b i r dt e s t i n ga u t o m a t i o nf r a m e w o r k ( h t a f ) b a s e do nt h ek e y w o r d d r i v e ni d e o l o g y , w h i c hh a sa i n d e p e n d e n td r i v e ne n g i n e ，c a r r i e so u tt h ed e t a i l e dr e s e a r c ho nt h a t a sw e l l t h ef r a m e w o r kh t a fi s i n d e p e n d e n to ft h eg e n e r a ls o f t w a r et e s t i n ga u t o m a t i o n f r a m e w o r k ( s t a f ) a n dt h ef u n c t i o n a lt e s t i n gt o o l s ，y e tb i n d st h ef u n c t i o n so ft h et w o a tl a s t ， t h i sa r t i c l ea p p l i e st h eh y b 硼t e s t i n ga u t o m a t i o nf r a m e w o r kt oa c t u a ls o f t w a r et e s t i n g p r o j e c t s i t c a l la u t o m a t i c a l l yd o w n l o a dt h ep r o d u c tf r o mt h eb u i l ds e r v e ra n di n s t a l li t , c o n f i gt h et e s t e n v i r o n m e n t ，r u nt e s ta n dg e n e r a t et h et e s tr e p o r tt ot e s t e r s i tr e a l i z e sf u l l ya u t o m a t e dt e s t i n g , g r e a t l yi m p r o v e st h ee f f i c i e n c yo ft h et e s t , s oi ts a v e sac o n s i d e r a b l ea m o u n to fm a n p o w e r , m a t e r i a lr e s o u r c e s ，t i m ea n do t h e rr e s o u r c e s i t su n i v e r s a lt ot h ef u n c t i o nt e s to fs o f t w a r e p r o d u c ta sw e l l k e y w o r d s ：s o f t w a r et e s t ；s o f t w a r et e s ta u t o m a t i o nf r a m e w o r k ；k e y w o r dd r i v e n ；f u n c t i o nt e s t t o o l s i i 南京邮电大学硕士研究生学位论文 目录 目录 摘要i a b s t r a c t _ i i 目录i i i 第一章绪论l 1 1 课题研究背景1 1 2 研究现状2 1 3 课题研究意义3 1 4 论文内容及组织结构4 第二章软件测试自动化概述6 2 1 软件测试6 2 1 1 软件测试的定义6 2 1 2 软件测试的目的7 2 1 3 软件测试原则7 2 1 4 软件测试的分类8 2 2 软件回归测试与冒烟测试9 2 2 1 回归测试的概念9 2 2 2 回归测试的策略9 2 2 3 冒烟测试1 0 2 3 软件测试自动化1 1 2 3 1 测试自动化的概念1 1 2 3 2 实施测试自动化的前提1 2 2 3 3 测试自动化的优点和局限性1 2 2 4 本章小结1 4 第三章软件测试自动化框架相关理论1 5 3 1 测试自动化框架- 1 5 3 1 1 测试框架定义1 5 3 1 2 测试自动化框架的发展历程1 5 3 2 通用软件测试自动化框架s t a f 1 7 3 2 1s t 师介绍1 7 3 2 2s t a f 基本概念1 7 3 2 3s t a f 提供的服务及服务请求方式1 9 3 2 4s t a f 的特点2 0 3 3 界面功能测试工具s e l e n i u m 介绍2 0 3 3 1 界面测试工具的选择比较2 0 3 3 2s e l e n i u m 的运行模式2 l 3 3 3s e l e n i u mr c 的原理2 2 3 4 本章小结2 3 第四章混合测试自动化框架h t a f 的设计2 4 4 1h t a f 介绍2 4 4 1 1 常用的功能测试框架问题分析2 4 4 2 2 框架h t a f 的设计策略2 5 4 2 框架h t a f 结构及测试流程2 6 i i i 南京邮电大学硕士研究生学位论文 目录 4 2 1 框架h t a f 的结构2 6 4 2 2 框架h t a f 测试流程2 7 4 3 测试用例的编写2 8 4 3 1 测试用例管理系统a t m s 2 9 4 3 2 测试用例的文本编写方法3 0 4 4 框架h t a f 各组成部分设计与实现3 1 4 4 1 配置文件设计与实现3 l 4 4 2 驱动引擎设计与实现3 2 4 4 3 测试用例库设计与实现3 5 4 4 4 组件设计与实现3 5 4 4 5 测试结果及日志库3 7 4 5s t a f 在h t a f 中的开发应用3 8 4 5 1s t a f 的应用流程3 8 4 5 2h t a f 中基于s t a f 所开发的服务4 0 4 6s e l e n i u m 在h t a f 中的开发应用4 2 4 6 1s e l e n i u m 的启动模式4 2 4 6 2s e l e n i u m 的开发4 3 4 7 本章小结4 5 第五章h t a f 在i m s s 产品中的应用4 6 5 1i m s s 介绍及需求分析4 6 5 1 1i m s s 介绍? 4 6 5 1 2 测试需求分析4 7 5 2i m s s 产品回归测试流程4 7 5 3 实施测试自动化4 9 5 3 1 测试准备工作4 9 5 3 2 启动测试5 0 5 。3 3 测试报告生成5 l 5 4 测试结果分析：5 3 5 5 框架应用总结5 4 5 6 本章小结5 5 第六章总结与展望5 6 6 1 总结5 6 6 2 展望5 6 致谢5 8 参考文献5 9 已发表论文6 l i v 南京邮电大学硕士研究生学位论文第一章绪论 1 1 课题研究背景 第一章绪论 软件产业作为信息产业的核心和灵魂，在促进国民经济发展和社会发展信息化中 具有重要的地位和作用。随着信息技术的飞速发展，软件规模的日益增大，软件产品 应用到社会的各个领域，软件质量的高低将会决定一个企业的未来发展。而对软件进行测 试就是保证软件质量最重要和最有效的方法。 1 9 9 6 年6 月，a r i a n e5 火箭发射后仅仅3 7 秒，便偏离它的飞行路径，解体并爆炸了。 火箭上载有价值5 亿美元的通信卫星，总计6 亿美元付之一炬。后来的调查显示，控制惯 性导航系统的计算机向控制引擎喷嘴的计算机发送了一个无效数据。 2 0 0 9 年7 月，微软就o f f i c e 漏洞一周内连续两次发布紧急通告。根据3 6 0 安全中心统 计，截至7 月中旬，这两大微软高危漏洞已导致近7 0 0 0 万人次遭攻击，超过2 8 万家网站 被先后“挂马”。而所谓的漏洞就是软件的缺陷。 而事实上软件产品中所存在的问题可以统称为软件缺陷，最终表现为软件质量与用户 的需求之间有着一定的差距。上面的数据表明，软件产品的缺陷将会给人们的工作与生活 带来很大的影响。然而，完美无缺的软件是不存在的。这是因为在软件的开发过程当中， 由于软件本身的复杂性、用户需求的变化、时间压力、各种人为错误等等原因将会导致软 件开发质量上的失控。正如任何生产过程都离不开产品质量检验一样，测试工作也是软件 开发过程中必不可少的环节。软件测试的核心就是发现软件产品中的缺陷。因此，为了避 免缺陷的产生和消除已有的缺陷，测试人员需要采取更好的办法来进行软件测试，尽可能 地发现软件产品更多的缺陷，争取将软件产品的缺陷数量与等级降到最低。 软件测试是一项艰苦的工作，需要投入大量的时间和精力。据统计，软件测试会占用 整个开发时间的4 0 n 1 。一些可靠性要求非常高的软件，测试时间甚至占到总开发时间的 6 0 。而在软件开发的过程中，当开发人员改动了软件产品的代码，由于软件系统的复杂 性，为了保证软件产品原有的功能不受影响，同时为了保证此番改动不会带来新的软件缺 陷，需要重新对软件产品进行回归测试。这种测试找到软件缺陷的可能性小，效率较低， 堕室堕皇奎兰堡圭塑壅生堂垡丝塞茎二兰堑笙： 但又是极为必要的。在此测试过程中，采用传统的手工测试方法将会耗费大量的人力、物 力资源。另外在进行系统负载、稳定性测试时需要模拟大量并发用户或者长时间的对软件 产品进行测试，这些测试使用手工测试难以实现。 软件测试自动化是相对于手工测试而存在的。实现测试自动化能够解决手工测试的局 限性，并且会带来另外的很多好处。例如，测试自动化能将测试人员从繁琐和重复的测试 活动中解脱出来；测试效率高，充分利用硬件资源；帮助完成许多手工测试无法实现或难 以实现的测试；测试自动化可以随时触发，在最大程序上还可以实现“无人测试 等等。 总之，在大多数情况下，正确、合理地实施测试自动化，能够快速地对软件进行测试，从 而提高软件测试的效率，节约成本，缩短产品发布周期。因此，测试自动化成为软件测试 必然的发展趋势之一，已成为当前软件测试技术研究的重点和难点，也越来越受到软件界 的重视。 1 2 研究现状 国外在技术进步和需求推动作用下，软件测试逐步形成了独立的理论体系和技术框 架。1 9 8 3 年美国的i e e e 、a c m 等组织制定了一系列软件测试规范。国外的许多大学( 如 c a r n e g i em e l l o n 、华盛顿大学等) 、研究机构( 如n a t i o n a ls o f t w a r et e s t i n gl a b 等) 和 公司( 如s o f t w a r er e s e a r c h ，m e r c u r yi n t e r a c t i v e ，r a t i o n a lc o r p o r a t i o n 等) 进行了大 量软件测试的研究和应用工作。其中c a r n e g i em e l l o n 大学侧重于回归测试和 c l i e n t s e r v e r 测试技术的研究，g e o r g em o s a n 侧重于基于规范的测试自动生成和面向对 象测试技术。 国外的许多公司研究出了比较专业的测试工具。目前比较流行的软件测试工具有 m e r c u r yi n t e r a c t i v e 的功能测试工具q u i c k t e s tp r o 、w i n r u n e r ，性能测试工具 l o a d r u n n e r ，p a r a s o f t 公司的自动化白盒测试工具j t e s t ，a p a c h e 组织的功能和性能测试 的工具j m e t e r ，微软的压力测试工具m i c r o s o f tw e ba p p l i c a t i o ns t r e s st o o l 等。 一般的软件测试自动化的实施过程中会借助于上述第三方测试工具，但是仅仅依靠某 个工具企业也较难成功实施测试自动化。软件测试自动化日益成为一种编程行为，它在项 目过程中的实施也更加广泛，在整个项目中实施好自动测试的过程也越来越受到软件业的 重视。 目前，对于国内来说，把软件测试作为软件生命周期的一个必不可少的环节，已经达 成共识。虽然有研究单位对软件自动化测试进行了一系列的研究，并取得了一定的成果。 2 雨京邮电大学硕士研究生学位论文 第一苹绪论 但大部分的企业，对测试的定位仍然偏低。软件产品自动化测试技术起步较晚，其测试自 动化实施现状主要表现为以下几个方面： ( 1 ) 公司高层重视程度不够，意识不到软件测试自动化的重要性，这也可能是因为 测试整体行业都没有被重视起来，也有可能是因为公司高层有更需要重视的环节，例如直 接关系公司存亡的命脉性东西； ( 2 ) 公司规模小，人员、资金、资源不足，实施不了自动化； ( 3 ) 公司内部资源规划、组织结构不合理，开发与测试之间矛盾重重，实施测试自 动化的成本比手工测试还要大； ( 4 ) 测试自动化的实施相对比较成功，但是仍存在些问题，比如工具选择不准确， 培训不到位，文档不完备，人员分配不合理，脚本可维护度不高等等，造成一种表面上的 自动化测试流程。 国内企业对具体的开发环境下开发的特定领域的软件系统应采用怎样的自动化测试 方法，对其进行全面的、完整的测试，仍没有具体的标准可以遵循，对如何设计自动化测 试系统的体系还缺乏深刻的认识。 1 3 课题研究意义 通常在测试自动化的实施过程当中，除了特殊场合之外，人们一般会借助于市面上成 熟的第三方测试工具。使用这些专业的测试工具可以很大程度上减少测试人员进行测试自 动化的工作量，提高测试自动化的效率。但是在具体实践中，企业依靠某个工具很难成功 实施测试自动化。原因主要有两方面，一是，理论上利用测试工具进行自动化测试可以替 代部分工作，但在实践过程中并不能完整地解决测试质量与效率、投入与产出等一系列现 实因素之间存在的矛盾。从这个角度来说，测试工具提供的测试技术只是测试自动化的一 部分。二是，测试人员开发了一堆自动化测试脚本若没有具体的框架来规定实施和执行的 原则，也会无用武之地。因此，现实的测试实践中，我们需要一个完整的自动化测试解决 方案一一测试框架，以便真正地实现高效、高质量的软件自动化测试。 然而如果一个测试自动化框架没有经过很好地设计，将会耗费掉高昂的先期构建成 本，并且在测试过程中会带来无休无止的维护工作。另外如果此框架不具备良好的可扩展 性，只适用于单一的产品，那么此框架的设计也无足轻重，实现不了测试开发人员的设计 初衷。而一个设计合理的自动化测试机制能够很大程度地降低测试自动化的成本，并提高 测试的效率。 3 南京邮电大学硕士研究生学位论文 第一章绪论 因此，对测试自动化框架的研究具有比较重大的意义。本文就此展开研究，设计并实 现了一个低成本、健壮的、易维护、易扩展的测试自动化框架，来帮助测试人员实现高效 率的测试。 1 4 论文内容及组织结构 本文的研究内容是设计并实现一个混合的测试自动化框架h t a f ，并将其应用在大型网 关邮件扫描系统i m s s 开发过程的回归测试中。此混合测试框架依据i m s s 产品系统的敏捷 开发模式，采用关键字驱动思想，主要用于完成产品的功能性回归测试。该测试系统实现 了自动从版本服务器( b u il ds e r v e r ) 下载并安装产品、配置测试环境、自动执行测试并生 成测试报告反馈给测试人员。 本文的主要工作如下： 1 基于关键字驱动的思想，结合了通用测试框架s t a f 及界面测试工具s e l e n i u m ，设 计了一个独立的关键字驱动引擎，最终实现了混合的测试自动化框架h t a f ( h y b i r dt e s t i n g a u t o m a t i o nf r a m e w o r k ) ，该框架具有良好的可扩展性、可重用性； 2 设计了一套基于u i 的测试用例管理系统a t m s ( a u t ot e s tm a n a g e m e n ts y s t e m ) ， 提出一种新的测试用例编写方法； 3 设计并实现了产品的无需人工干预的自动化回归测试； 4 将框架h t a f 应用于i m s s 产品的软件测试项目中，并对测试结果进行了分析。 其中本文的创新点在于混合测试自动化框架的设计策略。此框架基于关键字驱动的思 想，具备一个单独的驱动引擎，独立于通用框架s t a f 或其他测试工具，但是仍然可以很 好地运用这两者的功能。 围绕本文的主要工作及创新点，本文的组织结构如下： 第一章绪论。介绍了本课题的研究背景，概述了软件测试自动化的国内外研究现状 以及课题的研究意义，并叙述了本文的内容及组织结构。 第二章软件测试自动化概述。讲述了软件测试的基本概念、软件回归测试与冒烟测 试的概念、提出在回归测试中应用软件测试自动化技术，并在此基础上分析了软件测试自 动化的优点及局限性。 第三章软件测试自动化框架相关理论。首先介绍了测试自动化框架的定义及发展历 程，重点介绍了本文所采用的i b m 公司的测试自动化框架s t a f 的相关概念；其次分析了 目前主流的几种测试工具，最终选择采用s e l e n i u m 工具并对其进行了介绍。 4 雨京邮电大学硕士研究生学位论文 第一苹绪论 第四章混合测试自动化框架h t a f 的设计。这是本文的重点。首先对目前常用的功能 测试框架的问题进行分析，阐述了框架h t a f 的设计策略：然后描述了框架的组织结构及 测试流程、测试用例的编写；接着对详细分析了框架各组成部分的设计；最后叙述了s t a f 和s e l e n i u m 在此框架中的应用开发。 第五章h t a f 在i n t e r s c a nm e s s a g i n gs e c u r i t ys u i t e 产品中的应用。分析了i m s s 产品测试的需求，介绍了i m s s 产品的回归测试流程，通过h t a f 实施测试自动化，并对其 测试结果进行了分析，对框架的应用进行了总结。 第六章结束语。总结了论文目前所取得的研究成果，并探讨了课题进一步研究方向。 5 南京邮电大学硕士研究生学位论文 第二章软件测试自动化概述 第二章软件测试自动化概述 一般来说，软件测试的工作量很大，许多操作是重复性的、非智力创造性的工作。回 归测试尤其如此。以往大多采用手工测试方法，耗费大量的人力、物力。测试自动化使得 所取得的测试用例得以重复测试，并能保障测试的科学性、严密性、组织性。采用测试自 动化技术可以大大提高软件测试的效率，会对整个开发工作的质量、成本和周期带来非常 明显的效果。 2 1 软件测试 2 1 1 软件测试的定义 在软件产品的开发周期的每一阶段里，软件测试有着不同的目的。根据测试目的的不 同，会有不同类型的软件测试定义。 ( 1 ) 软件测试的正向思维定义 软件测试的正向思维的出发点是使自己确信产品是能够工作的。主要代表人物是b i l l h e t z e l 博士。1 9 7 3 年他首先给出软件测试的定义：“测试就是建立一种信心，确信程序 能够按期望的设想进行 。1 9 8 3 年他又将软件测试的定义修改为：“评价一个程序和系统 的特性或能力，并确定它是否达到期望的结果。软件测试就是以此为目的的任何行为乜功。 基于这样的思维，测试通常被认为是软件生命周期中编码之后的一项活动。因此，可 以认为这是一种狭义的软件测试定义。 ( 2 ) 软件测试的反向思维定义 g l e n f o r dj m y e r s 认为测试不应该着眼于验证软件是工作的4 ，相反应该首先认定 软件是有错误的，然后用逆向思维去发现尽可能多的缺陷。1 9 7 9 年，g l e n f o r dj m y e r s 给出了他对软件测试的定义：“测试是为发现错误而执行一个程序或者系统的过程1 。” m y e r s 提出的“测试的目的是证伪 这一概念，推翻了过去“为表明软件正确而进行测 试 的理解，为软件测试的发展提出了新的方向。基于这种思维，测试人员往往能够更多 地发现系统中存在的缺陷。 和软件测试正向思维的定义一样，软件测试反向思维指的也是软件的执行和运行，而 不是全程的软件测试的概念，因此，也是一种狭义上的软件测试定义。 ( 3 ) i e e e 软件测试的定义 6 南京邮电大学硕士研究生学位论文第二章软件测试自动化概述 1 9 9 0 年的i e e e a n s i 标准将软件测试进行了这样的定义h 1 ： 在规定条件下运行系统或构件的过程。观察和记录结果，并对系统或构件的某些方 面给出评价。 分析软件项目的过程。检测现有状况和所需状况之间的不同，并评估软件项目的特 性。 随着信息行业进入了大发展，软件趋向大型化、高复杂化。人们对软件工程化更加重 视，软件分析、设计的作用越来越突出。同时，需求和设计阶段所产生的缺陷具有放大效 应，严重影响软件质量。因此，为了更早地发现并解决问题，降低修改错误和缺陷的代价， 有必要将测试延伸到需求分析和设计阶段中去，使软件测试贯穿于整个软件生命周期，提 倡软件全生命周期测试的理念，即软件测试是对软件形成过程中的所有工作产品( 包括程 序以及相关文档) 进行的测试，而不仅仅是对程序的运行进行测试。因此，我们可以把软 件测试定义为：软件测试是贯穿整个软件开发生命周期、对软件产品( 包括阶段性产品) 进行验证和确认，衡量软件质量，并对其是否能满足设计要求进行评估的过程。 2 1 2 软件测试的目的 根据软件测试正向思维的观点，软件测试是为了验证软件程序的正确性，使人们树立 起对软件质量的信心；测试目的为确信产品能够工作，可以简单抽象地描述为这样的过程： 在设计规定的环境下运行软件的功能，将其结果与用户需求或设计结果相比较，如果相符 则测试通过，如果不相符则视为存在缺陷。这一过程的终极目标是将软件的所有功能在所 有设计规定的环境全部运行，并通过，并确认这些功能，确认这些功能的适合性和正确性。 这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。 根据其反向思维的观点，软件测试则是为了发现软件产品中更多的缺陷。简单地说就 是验证软件是不工作的，或者说是有错误的。m y e r s 认为，一个成功的测试必须是发现缺 陷的测试，不然就没有价值。这种思维的观点强调了测试人员不断思考开发人员理解的误 区、不良的习惯等等，它的目标就是发现系统中各种各样的问题， 从根本来说，软件测试就是为了保证软件的质量满足用户的需求。这也是两种思维的 统一之处。严格的软件测试对于保证软件质量具有重要作用。 2 1 3 软件测试原则 基于测试是为了寻找软件的缺陷，评估与提高软件质量，为了更好地进行测试，应该 遵循以下原则晦1 ： ( 1 ) 所有的软件测试都应追溯到用户需求。 7 南京邮电大学硕士研究生学位论文 第二荦软件测试自动化概述 这是因为软件的目的是使用户完成预定的任务，并满足用户的需求，而软件测试所揭 示的缺陷和错误使软件达不到用户的目标，满足不了用户需求。 ( 2 ) 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。 合理的输入条件是指能验证程序正确的输入条件，而不合理的输入条件是指异常的， 临界的，可能引起问题异变的输入条件。只有合理地设计测试用例，才能充分地对软件产 品进行测试。 ( 3 ) 程序员应避免测试自己的程序。 测试工作需要严格的作风，客观的态度和冷静的情绪。人们常由于各种原因具有一种 不愿否定自己工作的心理，另外可能会因为编写程序而形成一种思维定视。这都将成为测 试自己程序的障碍。 ( 4 ) 充分注意测试中的群集现象。 经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正 比。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。 ( 5 ) 测试无法显示软件潜在的缺陷 尽管人们采用了多种方法来保证软件产品的质量，但是软件产品仍然不可能完美无 缺，仍然会存在各种各样的问题。软件测试可以查找出软件缺陷和错误，但不能保证软件 的缺陷和错误全部找到，继续进一步测试可能还会找到一些，也就是说测试只能证明软件 存在错误而不能证明软件没有错误。 2 1 4 软件测试的分类 软件测试是一项复杂的系统工程，从不同的角度考虑可以有不同的划分方法，对测试 进行分类是为了更好地明确测试的过程，了解测试究竟要完成哪些工作，尽量做到全面测 、h 讽。 根据被测内容可分为功能测试、结构测试和非功能性测试嘲。功能测试指依据功能需 求规格说明书评估被测对象的功能是否符合需求。结构测试是指基于被测对象的内部结构 或者逻辑寻找缺陷的测试活动。非功能性测试指依据非功能需求规格说明书评估被测系统 的某些整体属性，例如性能测试、安全性、易用性等是否符合需求。 另外，通常还有如下几种分类方法： ( 1 ) 根据是否查看源代码，也是基于测试方法可以划分为白盒测试、灰盒测试和黑 盒测试； ( 2 ) 根据测试阶段划分为单元测试、集成测试、系统测试、验收测试； 8 南京邮电大学硕士研究生学位论文 第二章软件测试自动化概述 ( 3 ) 根据是否运行被测系统，可分为静态测试和动态测试； ( 4 ) 根据测试方法，可分为手工测试和自动测试； ( 5 ) 根据测试实施组织，可分为开发方测试、用户测试和第三方测试。 2 2 软件回归测试与冒烟测试 2 2 1 回归测试的概念 在软件生命周期中，软件程序的任何改变都可能给软件产品带来问题。这种改变主要 来源于以下几个方面： ( 1 ) 在上轮的测试中，测试人员发现了软件缺陷并提交给开发人员，开发人员为了 修复软件缺陷对软件程序做了改动； ( 2 ) 为了对软件程序增加了新模块或者新功能而新增加了软件代码； ( 3 ) 为了对软件产品原有的功能进行一些调整和加强。 而这样的改动可能会带来意想不到的结果。有可能会使原来已经满足用户需求的功能 出现了问题，或者开发人员并没有修复掉以往发现的软件缺陷，或者软件产品新增加的模 块或功能并不能正常工作。 为了避免对软件代码的改动带来这样的结果，需要对软件产品已有的功能进行再测 试。这种再测试被称为回归测试。i e e e 对于回归测试( r e g r e s s i o nt e s t i n g ) 的定义为 ( i e e e 6 1 0 1 2 - 9 0 ) ：回归测试是为了验证所作的修改没有对原有系统造成影响，而对系统或 组件进行选择性的重新测试订1 。回归测试在软件生命周期中扮演着重要的角色。回归的问 题根源是软件系统的内在复杂性。随着系统的复杂性的增加，更改产生难以预见的影响的 可能性也增加了哺1 。 从回归测试的定义看来，回归测试需要达到以下两方面的目的： ( 1 ) 保证已经满足用户需求的功能不应该出现任何问题； ( 2 ) 保证之前发现的软件缺陷已经被修复了，开发人员对软件产品的改动是正确的。 2 2 2 回归测试的策略 回归测试重复率高，工作量大，虽然可以利用测试自动化技术来完成，很多时候如果 有足够的资源用全部测试用例来做回归测试是最佳选择。但是更多时候我们没有足够的资 源，有时也没有必要这样做。为了确保软件代码修改的正确性及其影响，需要探索出一种 9 南京邮电大学硕士研究生学位论文 第二苹软件测试自动化概述 有效的测试用例选择策略。兼顾效率和有效性两个方面，常用的回归测试策略包括阳1 ： ( 1 ) 选择全部测试用例 选择测试用例库中的所有测试用例作为回归测试用例，这是一个较为保险的方法，同 时测试成本也是最高的。在理想的状态下( 有足够的资源，测试人员不知疲惫) ，这种方法 绝对是首选。但在现实环境中，测试资源时常缺乏，特别是项目的测试时间有限。所以， 无论从现实资源考虑还是从测试成本上考虑，都不可能在每次回归测试时都选择全部测试 用例。 ( 2 ) 基于风险选择测试用例 这是基于一定的风险标准从测试用例库中选择部分测试用例形成测试包。按测试优先 级来来选择最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高 稳定的测试用例。这样测试任务会大为减轻但效果并不差，因为由此没有被发现的缺陷是 较少并且严重性较低的。 ( 3 ) 基于操作剖面选择测试用例 这种方法适用于测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系 统的实际使用情况。回归测试时可以优先选择那些针对最重要或最频繁使用功能的测试用 例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。 ( 4 ) 再测试修改部分 这种是基于开发对修改的影响区域有较大把握时所采取的一个策略。通过相依性分析 识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上， 此时只选择相应的测试用例来做回归测试。此策略风险最大，但成本也是最低的。 以上四种回归测试策略各有优缺点，实际应用中测试人员需要根据项目的资源，进度 及项目开发的模式等实际情况来选择最优策略。在软件改动比较大的版本或比较重要的版 本中，最好选择风险最小的全回归测试。在b u i l d 更新较快或极限编程中，则可以选择第 四种测试策略。其他情况下则可以选择折中的第二、三种策略，当然也要依据测试的实际 情况。 2 2 3 冒烟测试 冒烟测试，是微软首先提出来的一个概念u 。冒烟测试这个名称的来历，是从电路板 测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟则继续进行其 它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么开发出来的相应的版 1 0 南京邮电大学硕士研究生学位论文第二章软件测试自动化概述 本也会返回给开发人员进行修正。 每日构建( d a i l yb u i l d ) 是将一个软件项目的所有最新代码取出，对版本进行需求 提交、程序开发、修改、测试这一系列完整过程。每日构建意味着自动地，每天，完整地 构建整个代码树。 冒烟测试就是在每日构建建立后，对系统的基本功能进行简单的测试。这种测试强调 对程序的主要功能进行的验证。冒烟测试的对象是每一个新编译的需要正式测试的软件版 本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。 冒烟测试其实就是小规模的回归测试。提供给测试人员测试的版本必须首先通过冒烟 测试的考验。只有保证了软件产品的基本功能不会出现问题，才有必要进行大规模的回归 测试。否则只会浪费测试人员时间、人力等资源。 2 3 软件测试自动化 传统的软件测试是采用手工测试的方法，劳动强度高，并且很单调，浪费大量的资源， 消耗了测试人员大量的时间和精力。测试自动化不仅能够大大减轻测试人员的工作量，还 能够帮助完成许多手工测试难以完成的任务。测试自动化使得软件测试进入了一个新的发 展时期。测试自动化是一种测试技术，是软件测试未来发展的必然趋势之一。 2 3 1 测试自动化的概念 通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一 步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬 件资源，提高测试效率，便引入一项让计算机代替测试人员进行软件测试的技术，即测试 自动化。自动化测试相对于手工测试而言，其主要进步在于自动化测试工具以及自动化测 试框架的引入n 。 测试自动化是指利用策略、工具以及产出等，减少人工介入到非技术性、重复性、冗 长的测试活动里，从而达到无人监守完成测试，并自动产生测试报告，分析测试结果等一 系列活动。其意在将软件自动化测试中所涉及的环节作为一个统一的整体考虑，从测试脚 本的管理和执行到测试报告的提交都有相应的策略、规范和实现方法。 由于回归测试主要是用来重复执行一些已经存在的测试用例，故而可以结合实际情况 将其实现测试自动化。测试自动化的程度越高，回归的周期就越短，测试的效率也就越高。 南京邮电大学硕士研究生学位论文第二章软件测试自动化概述 2 3 2 实施测试自动化的前提 测试自动化虽然能够帮助测试人员节约大量的资源，但是并不适用于所有的测试。在 实施自动化测试之前需要对软件产品进行分析，以观察其是否适合使用自动化测试。 这些前提包括以下几类n 幻： ( 1 ) 实施测试自动化的成本 自动化测试的开发本质上也是一种软件开发行为，但它同时又具备测试的性质。每一 轮测试的软件版本和其代码都是变化的，每次回归测试都采用不同的软件版本。因此自动 化测试的脚本需要考虑这些因素。可以用一个公式来计算实施测试自动化的成本： 实施测试自动化的成本= 测试工具成本+ 前期测试框架开发的成本+ 后期测试框架维护 的成本。 当某些测试很少运行时，开发自动化测试仍然会耗去测试人员一定的资源，这时使用 自动化测试所花费的代价有可能大于手动测试。 当软件产品的代码变更过多，需要不断修改自动化测试脚本时，后期维护的成本将大 大增加，如此以来实施测试自动化的成本也会大于手动测试。 ( 2 ) 规则复杂的对象 规则复杂的对象将很难进行测试自动化。例如界面的美观、声音的体验、易用性的测 试等，这些目前为止只能依靠测试人员进行手工测试。 ( 3 ) 软件产品的稳定性 如果软件产品不能达到一定的稳定性，实施的自动化测试将会因为各种严重的软件缺 陷而失败。此时对测试自动化的维护将会是巨大的。只有当软件达到相对的稳定，没有严 重错误和中断错误才能开始自动化测试。 ( 4 ) 项目周期时间的长短 由于测试自动化需求的确定、测试自动化框架的设计、测试脚本的编写与调试均 需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长 的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么 即使勉强实施了测试自动化