（计算机软件与理论专业论文）基于移动智能网自动化测试系统的研究与实现.pdf

；p 文辩簧 基予移动智能网蠡动化溅试系统蛉磷究与实职 摅要 软# ：测试是软搏生命髑期中鹩“个羹要除段，怒豫诞款待质餮豹关键。髓寿面 向对象穰序设计憋想的撼出，对两向对象的测试也憝软件测试中的一个关键部分。 随卷软件裁模的不断扩大，溯试技术瓣不断捉离，软件测试邂澎以自动测试的 方式来代替手工测试方式，软件的良动亿测试思想开始出现在软讳的测试过程中。 软件靛蠢动纯测试并不仅仅燕回归灏试中的翻动纯，真正意义上的溅试爨动纯应该 体蕊在熬个软件测试进程中。针对蕊在软件测试领城通拜i 的溺试糯例设计方法茅瓣测 试躅铡煎孰行过程蕊及两阪予回归浏试道程中依较予手工溅试的强葫托测试方法， 本文在数据褒的l 鬣，状态梳的生成，溺患静比较及灞试褥镶赣瓣条辞静梭囊方嚣 终了改遴，疆毒藜鹣蠡谚辱乏测试聚统。 奁薪麓系统中，数键表浆繇麓，狻态襁耱书璇，瀵爨豹磁较和溅试震铡输赛条 f ：豹裣焱都采取整韵捉魏方式寒瓮裁。文中对改遂菇熬囊旗他测试系统传了详缨戆 镄逮，绘密了攥璇麓诿绥设计滚程。本文啐 鼹设诗熬系统不稷逶髑予豳甥溅试中瓣 囊麓纯测试，聂且瞧适用于憋个款 牛测试过程中其德测试的爨动化。 本文蔫先对麓誊测试攫论雩譬了麓要静糖述，论述了较 孛测试方法，争愈蹋期秘 测试模型。对爨动化测试蓉绞的概要设计，详绷设计郡作了详缨鲍介缁。最后介 缨了自动纯测试系绞在实琢磐能阚测试环壤豹实骏过程，给出了系统的实验结采分 辑。对惹统的优缺点以及改进的方向作了迸一步的搽讨。 关键字： 软件浏菇，测试用侧，翻归测试，窘动纯涮试 垒! ! ! ! 垒坚 s t u d y i n ga n di m p l e m e n t o f 王糕嚣s y s 善e 鑫蠖o ft h e t e s ta u t o m a t i o nb a s e do nt h em o b i l e i n t e l l i g e n tn e t w o r k 蠡b s t 琵c t s o f t w a r et e s t i n gi sa ni m p o r t a n tp h a s ei nt h es o f t w a r el i f ec y c l e ， a n di ti st h ek e yt oa s s u r et h eq u a l i t yo ft h es o f t w a r e w i t ht h er i s i n go f t h eo b j e c t o r i e n t e dp r o g r a m m i n gi d e ao b j e c t - o r i e n t e dt e s f i n gi sa l s oa k e yp a r t yo f t h es o f t w a r e t e s t i n g 。 w i t ht h e e n l a r g i n g o ft h es o f t w a r es c a l e g r a d u a l l y a n dt h e i m p r o v e m e n to f t h et e s tt e c h n o l o g i e s ，t h es o f t w a r et e s to fm a n u a lt e s ti s b e i n gr e p l a c e db y t h et e s ta u t o m a t i o ng r a d u a l l ya n dt h ea u t o m a t i o nt e s t i d e a b e g i n t oa r i s ei nt h es o f t w a r et e s t 。t h ea u t o m a t i o nt e s to ft h e s o f t w a r ei sn o to n l ya u t o m a t i o nt e s ti nt h er e g r e s s i o nt e s t ，b u tt h ea c t u a l a u t o m a t i o nt e s ts h o u l da p p l yt ot h ew h o l et e s to fs o f t w a r e a i m i n ga tt h e g e n e r a ld e s i g nw a yo ft h e t e s tc a s ea n dt h ep r o c e s so ft h et e s tc a s e e x e c u t i o na n dt h ea u t o m a t i o nt e s tw h i c hi sl i m i t e dt ot h er e g r e s s i o nt e s t a n dd e p e n do nt h et e s tr e s u l tb ym a n u a l ，i nt h i sp a p e rw em a k en e w p r o g r e s si nt h ec o n f i g u r a t i o no f t h ed a t at a b l e ，t h ec r e a t i n go ft h es t a t e 中文摘要 m a c h i n e ，t h ec o m p a r i s o n o ft h e m e s s a g ea n d t h e c h e c k i n g o ft h e p o s t c o n d i t i o n i nt h en e w s y s t e m i p a y m o r ea t t e n t i o nt ot h i sp a r t s ，a n da p p l yt h e a u t o m a t i o nt ot h ec o n f i g u r a t i o no f t h ed a t at a b l e ，t h ec r e a t i n go ft h es t a t e m a c h i n e ，t h ec o m p a r i s o n o ft h e m e s s a g e a n dt h e c h e c k i n g o ft h e p o s t c o n d i t i o n i n t h i sp a p e rw ed e s c r i p tt h em o d i f i e da u t o m a t i o nt e s t s y s t e m i nd e t a i l ，a n dp r o v i d et h ep r o c e s so f t h ed e t a i ld e s i g nt h i ss y s t e m c a nn o to n l ya p p l yt ot h er e g r e s s i o nt e s tb u ta l s ot oo t h e rt e s ti nt h ew h o l e t e s tl i f e 。 f i r s t l y , w ed e s c r i p tt h et h e o r yo f t h et e s ti nb r i e fa n dd e s c r i p tt h e t e s tw a y , t h el i f ec y c l eo ft e s ta n dt h em o d e lo f t e s t s e c o n dw ed e s c r i p t t h es u m m a r yd e s i g na n dd e t a i ld e s i g no f t h es y s t e m 。l a s t l y , w ed e s c r i p t t h ee x p e r i m e n tp r o c e s si nt h ei n t e l l i g e n tn e t w o r k a n d p r o v i d e t h ea n a l y z e o ft h er e s u l t w eh a v ed i s c u s s e dt h ep e r f o r m a n c eo ft h i ss y s t e ma n d i m p r o v e m e n t k e yw o r d s ： s o f t w a r et e s t ，t e s tc a s e ，r e g r e s s i o nt e s t ，a u t o m a t i o n t e s t 薷i 负 重量 第一章前言 较睾漆试绝对蕃怒开笈灌动完裁璐麴牧逡： 睾，缀多大鳖承开茨竣嚣，溅试会占据 项嚣霜期一拳以上瓣时阀。隧t e 4 。0 为n ，代粥，下袭时耨为6 令舞，嚣稳定程序花去了 8 令努戆时耀。藩徽软囊黟g 磷究浣漆i 、较臀测试专家塔宏娥浚遂。款授入弱瓷金秘久 力貔力泉番，测试、餮产鼓穗定露黪羧麓去瓣游勰哥裁占裂8 溉。 较符测试之瑟啦发震翱霹缓强，一个缀爨是擞臻究翻敷开发熬a 交滚的撰会翅黠 少。必有骰大登系绞王程熬入蠢“会对i 翼| | 试掇爨较裹黪癸求，蓬黉蛙宠熬最瑷出寐，褥檄 磅究； 彗教学敬久没毒大型琴缀z 程琰强实铡，掰以造成了；i i | | 试褒论礤究戆发鼹缺乏充实 熬黎鹚材秘。粪正锻丈漤系统开发瓣王程 摹，又没有露翅斑簿手豹测试经验突或系绕 靛理论。 “在美鞫，佛罗撼达j j 翻华盛颧媚分嬲骞一所大学开设软件测城瀑稳，其德裔歪 怒深穆救学校不是缎多。软 牛测试疋停镪在没有学秘系统、没商系统教育的输段。魅然 已缓有学校开设了这门课程，想是谯鞠镌教学掰铡，多半怒单视数停，还谈不上系统的 理论。”酶宏剐蹲士介绍谈。 搓软 譬溅试中一般需要运行大量鞠测试翔铡，但是软锌测试对润有隈。在一些愤 况下翁一个版本中已经运行通过的测试疆例需要在新的舨率中褥重新运行一邋。然而， 当兹鹣软停浏试主要依纛测试人员手工完成，溯试人员霈要送行数箍袭配嚣，虢态祝掏 造( 针对一些电信领域的软件测试) ，测试环境配鬣，输出祭 牛裣镬以及消息比较。所 有这些工佟鄙出测试久员手工来完成，在软件测试遘獠中存在大量麓燕复焚韵。因魏对 上述过程进行一定程度的融动化可以减少软件测试开锵，键商软件测试效率。 在实际软件测试中可以针对溺试箍襁飘行静不溺狯黢来实瑷蠢动纯，本文裁楚敲 这方面蓿手，糟重对数摇交静矗动亿配罾，状态祝瀚蠢动亿构造，输绥条件懿鑫动纯检 查，消息瀚蜜动纯诧较懿及溺试环麓鲍鑫瀚纯鬣羹港萼亍了磷究。 本文曾先筒蘩介绥了软件澜试的基本灌论，葵中包稔测试稳定义，灏试旋蘩本穷 法，测试酌，圭愈蠲精帮涌试篌燮。然纛对囊劝纯溺谈壤论挥了较为洋缀熬余缁。对 鹫有 软侔测试系统避行了分辑，总结密壤有溺试系统存在游阕瑟秽霹良菠避斡魏方。锌对凝 有灏试系统熬不是，键盘改避方案。谨绥费绍了馥邋系统戆竣诗滚穆，设诗溅理及设活 基确。最蜃将殴避屠静鑫动位渊试系统在餐懿蕊顼瑟s l ，r 黪测试中避行了实验，对实 验羧臻帮过爱送行了较为襻爨懿臻述，对实验缱慕 乍了详爨的分掇，总结了改进蕊绞的 优点霸不是，对未来熬磷究送行了袋鬻。 论文惩鞠如下：第一一章，蔻誊( 论文壤迷) ，辫二章，款待测试理谂，翳三章，软 翦言 件自动化测试理论，第四章，介绍了智能网中服务层的测试，笫五章，分析现有测试系 统存在豹不是，提出改进方案，第六章，改进系统的详鲡设计，第七章，系统实验及结 果分析，第八章，系统展望。沧文还包括结束语，参考文献和致谢。 一， 鏊壁塑堕堡堡 2 1 软件测试基本理论 2 1 1 软件测试的定义 第二章软件测试理论 软件测试( s o f t w a r et e s t i n g ) 是软件生存朝( s o f t w a r e f ec y c l e ) 中的个 重要阶段，是软件质量保证的关键步骡。通俗地讲，软件测试就是在软件投入运行河， 对软件需求分析、没计籁格说明和编码遗行最终复审的活动。1 9 8 3 年i e e e 键出静软件 工程术语中给软件测试下的定义是：“使用人工或融动的手段来运行或测定某个软件系 统的过程，其目桷在于检验它是否满足规定静需求域弄清预期结巢与实际绦莱之闯的差 别”。这个定义明确指出：软件测试的目的是为了枪验软件系统是否满足需求。 觚用户麓免疫来看，蔷遍希望遴过软件潲试暴灞软 宰中隐藏静错误和谈陷，所以软 件测试应该是“为了发现错误而执行程序的过程”。或者说，软件测试应该根据软件开 发鑫除段豹爝捂说嚼帮程痔的内部绪梅露精心设谤一藏测试雳镶 鞠输天数据及萁预麓 的输出结果) ，并利用这些测试用例去运行程序，以发现程序错误或缺陷。 2 12 软件测试方法 对于软件的测试，按照测试用例的设计是否依据程序结构分为白盒测试和黑盒测 试。 白盒测试： 软 牛的白盒测试是对软件的过程性细节擞细致粒检查，这个方法是把测试对象器作 一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或者选择 测试用例，对程序所有逻辑路径进行测试。通过在不同点梭查程序的状态，稳定实际的 状态是否与预期的状态一致。因此白盒测试又称为结构测试或者逻辑驱动测试。具体实 现又包括逻辑覆盖和楚本路径测试聪大类方法。 逻辑覆盖是以程序内鄢的逻辑结构为基础的测试用例的设计技术。遥一方法溪求 测试人员对程序的逻辑结构有清楚的了解。由于软件测试的目标不问，逻辑测试可分为： 语旬覆盖、潮定覆羲、判定条 孛覆盖及条件缝合覆盖。 基本路径测试是在程序控制流图的基础上，通过分析控制构造的环路挝杂性，导山 基本胃执行疑弪集台，麸露设计溅试翔铡豹方法。 黑盒测试： 软髂没i 试理沦 黑盒测试也称功熊测试或数据驱动测试。它在已知产品应具有的功能的条件下，通 过测试寒检溺每令功& 是焉鄙缝正常缓瑙。在溅试到，据程序- 器露一令不能亨j 。开静黑盒 予，在完全才i 考虑程序内部结构和内部特性的情况下，测试者存程序接口进行测试，它 必捡鸯程序功戆是否按照需求嫒辏说蜞书躲裁定正常饺赝，稳彦是惫熊适当逡接收竣入 数据而产生正确的输出信息，并且保持外部信息( 如数粥库或文件) 的完整性。 黑盒测试是以用户的观点，从输入数据与输出数据的对应关系出发进行测试的，它 不涉及刘程序的内部绪构。狠嘲盈，如果矫部特性本身有问题或规格说明的撬定有误， 用黑盒测试方法是发现不了的。黑盒测试法注遵于测试软件的功能需求，主要试图发现 ，l 类镄误：功能不对或遗漏、界丽错误、数蠢结构或井部鼗攒痒涝阉镣误、靛l 镑谈、 初始化和终止错误。 其体兹黑盒测试测试矮铡游设诗方法趣蘩等捻娄裂分、遴鬃霞、镄误接溅法、边界 值分析、功能图等。在使用时，针对开发项目的特点对方法加以适当的选择。 等价类划分 等价类划分是一种典型的黑盒测试方法，也是一种非常实用的重要测试方法。使用 这一方法，完全不考虑程序的内部结槐，只依援程序的规格泌明来设计测试用倒。 用所有t j 能输入的数据来测试程序是不可能的，只能从全都可供输入的数据中选择 一个子集进行测试。等价类划分是把所有可能灼输入数据，蹦程序的输入域化分成若于 部分，然后从每一部分中选取少数有代表性的数据作为测试用例。 在考虑等价类划分时，先从程序的功能说明中找出每个输入条件，然后为碡个输入 条件划分两个躐更多个等价类。等价类可分两种情况；有效等侨类私秃效等价类。有效 等价类是指对程序的规格说明是有意义的、合理的输人数据所构成的集合；无效等价炎 蔗 蠢对程序躲篾辏说裙是不合理戆或无意义熬输人数据赝鞫或戆集合。 边界值分析 较俘溺躐常露静一个方法是把溺试工臻按目样懿彩式划分。对数据进行软馋溪l 试， 就是检查用户输入的信息、返回结果以及中间计算结果是否正确。 边器僮分柝( b o u n d a r yv a l u ea n a l y s i s ，b v a ) 是一毒中 b 充等价淡划分的测试用例 设计技术，它不是选择等价类的任意元素，而鼹选择等价类边界的测试用例。实践证明， 在设讣测试用侧时，对边界附近的处理必须给予足够的重视，为检验边界附近的处理专 门设计测试滔例，常常可以取得蘸好的测试效果。b v a 不 叉羹视输入条件边赛r 丽且氇 从输出域导出测试用例。 罐误拄溅法 测试人员可以根掘经验和直觉推测程序中可能存在的错谡，从而有针刘性地编写榆 查这鉴错误静溺试周铡，这豪| 是镑豢捺溅法。 错误推测法的基本思想是：列举出程序中所有可能有错误和容易发生错误的特殊情7 兄， 棂爨豫饲来选择测试髑剿。 功能图 功髓匿方法楚用功能髫f d ( f u n c t i o n a ld i a g r a m ) 形式化地表示程序的功能说明， 软件测试理论 并机械地生成功能图的测试用例。 功能图模型由状态迁移图和逻辑功能模型构成，状态迁移图用于表述输入数据序列 以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状 态。逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。测试用例则 是由程序中经过的一系列状态和存每个状态中必须依靠输入输出数据满足的一对条件 组成。 2 1 3 软件测试策略 软件测试按四个步骤进行，即单元测试、组装( 集成) 测试、确认测试和系统测试。 图2 一l 给出软件测试经历的四个步骤。 氅 露 瓠 、 ，、 日b 女# f 1 一 d * l 一 m “m # ”、 、一一 图 2 1 软件测试的过程 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程 序模块是否正确地实现了规定的功能。然后，把已测试过的模块组装起来，进行组装测 试，主要对与设计相关的软件体系结构的构造进行测试。为此，在将一个一个实施了单 元测试并确保无误的程序模块组装成软件系统的过程中，对正确性和程序结构等方面进 行检查。确认测试则是耍检查已实现的软件是否满足了需求规格说明中确定了的各种需 求，以及软件配置是否完全、正确。最后是系统测试，把已经经过确认的软件纳入实际 运行环境中，与其它系统成分组合在一起进行测试。 2 2 面向对象软件测试理论 面向对象技术是一种全新的软件开发技术，l e 逐渐代替被广泛使用的面向过程，| ：发 方法，被看成是解决软件危机的新兴技术。面向对象技术产生更好的系统结构，更规范 的编程风格，极大地优化了数据使用的安全性，提高了程序代码的重用，一些人就此认 为面向对象技术开发出的程序无需进行测试。应该看到，尽管面向对象技术的基本思想 一鏊壁型蔓堡鲨 保证了软件应该有更高的质量，但实际情况却并非如此，因为无论采用什么样的编程技 术，缓矮人赛懿错误都蹩不可避免戆，霭置由于瑟向嚣雪象技术开发静软错+ 找鹨熏= 孀率菘， 更需嚣f “格测试，避免错误的繁衍。因此，软件测试并没有因丽向对鳃编程的兴起而丧 失掉它豹重要一隧。 2 2 驽向对象设计的测试( 0 0 1 t e $ t ) 通常的结幸句他的设计方法，用的是“面向作业的设计方法”，它把系统分鳃阻后， 提出组作业，这些作业是以过程实飘系统的基础构遗，把问题域的分析转化为求解域 的设计，分析的结果是设计阶段的输入。 而面向对黎设计( o o d ) 采用”造裂的观点”，以o o a 为基础归纳鞋5 类，并建立类结 构或进一步构造成类库，实现分析结果对问题空问的抽象。o o d 归纳的类，可以是对苏 简单的延续，可以是不同对象的丰羁同或确钕的驻务。由此可觅，o o d 怒o o a 的进一步踊 化和更高层的抽象。所以，o o d 与o o a 的界限通常是难以严格区分的。o o d 确定类和类 结构不仅是满足当前需求分橱静要求，更重要静是通过重囊缀合或热以适当的脊充，辘 方便实现功能的重用和扩增，以不断邋应用户的要求。因此，对o o d 的测试，主要针对 功麓f | 穹实现帮藿瘸以及对o o a 结栗静掭震，扶鲡f 三方瑟送行瑟向对象设计黪溺试： 对认定的类的测试 对构逸秘类层次终稳静溅试 对类库的支持的测试 222 面向对象编程的测试( o o pt e s t ) 媳型的砸向对象程序具有继承、封装和多态的新特性，这使得传统的测试策略必须 有所改变。封装是对数据的隐藏，岁 器只能邋过被提供的操作来访问成修改数据，这样 降低了数据被任意修改和读写的可能性，降低了传统程序中对数据非法操作的测试。继 承是蠢向对象程序的擞要特点，继承傻褥代码的重用枣提高，同时也使错误传播的概率 提高。继承使得传统测试遇见了这样一个难题：那就是对继承的代码究竟应该怎样测试。 多态使得面向埘蒙裎序对外呈现出强大的处理能力，假同时却使得程序内”尉一”函数的 行为复杂化，测试时不得不考虑不同类型具体执行的代码和产生的行为。 觏囱对象程序是把功能的实现分布在类中。能正确实现功能的类，通过消息传递柬 协同实现设计要求的功能。正是这种面向对象程序风格，能将出现的错误精确缝确定在 某具体的类。因此，在面向对象编稷( o o p ) 阶段，忽略类功能实现的细则，将测试 的舀光集中在类功能的实现和稠应的蕊囱对象程序风格，主黉体现为下两个方面。 数据成员是否满足数据封装的要求 软件测试理论 类是否实现了要求的功能 2 23 面向对象的单元测试( 0 0u n i tt e s t ) 传统的单元测试是针对程序的函数、过程或完成某一特定功能的程序块。沿用单元 测试的概念，实际测试类成员函数。一些传统的测试方法在面向对象的单元测试中都可 以使用。如等价类划分法，因果图法，边界值分析法，逻辑覆盖法，路径分析法，程序 插装法等等。单元测试一般由程序员完成。 22 4 面向对象的集成测试( 0 0in t e g r a t et e s t ) 传统的集成测试一般可以在部分程序编译完成的情况下进行。而对于面向对象程 序，卡日互调用的功能是散布在程序的不同类中，类通过消息相互作用申请和提供服务。 类的行为与它的状念密切相关，状态不仅仅是体现在类数据成员的值，也许还包括其他 类中的状态信息。由此可见，类相互依赖极其紧密，根本无法在编译刁i 完全的程序上对 类进行测试。所以，面向对象的集成测试通常需要在整个程序编译完成后进行。此外， 而向对象程序具有动态特性，程序的控制流往往无法确定，因此也只能对整个编译后的 程序做基于黑盒子的集成测试。 面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作 用时才会产生的错误。基于单元测试对成员函数行为f 确性的保证，集成测试只关注于 系统的结构和内部的相互作用。面向对象的集成测试可以分成两步进行：先进行静态测 试，再进行动态测试。 静态测试主要针对程序的结构进行，检测程序结构是否符合设计要求。现在流行的 一些测试软件都能提供一种称为”可逆性工程”的功能，即通过原程序得到类关系图和函 数功能调用关系图，换句话说，通过这种方法检测o o p 是否达到了设计要求。 动态测试设计测试用例时，通常需要上述的功能调用结构图、类关系图或者实体关 系图为参考，确定刁i 需要被重复测试的部分，从而优化测试用例，减少测试_ t 作量，使 得进行的测试能够达到一定覆盖标准。测试所要达到的覆盖标准可以是：达到类所有的 服务要求或服务提供的一定覆盖率：依据类间传递的消息，达到对所有执行线程的一定 覆盖率；达到类的所有状态的一定覆盖率等。同时也可以考虑使用现有的一些测试工具 来得到程序代码执行的覆盖率。 2 2 5 面向对象的系统测试( 0 0s y s t e mt e s t ) 通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认在实际 软件测试理论 运行时，它是否满足用户的需要，是否存在实际使用条件下会被诱发产生错误的隐患。 为此，对完成开发的软件必须经过规范的系统测试。换个角度说，= 川：发完成的软什仅仪 是实际投入使用系统的一个组成部分，需要测试它与系统其他部分配套运行的表现，以 保证在系统各部分咖调工作的环境下也能f 常工作。 系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的 完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考 o o a 分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全”再现”问 题空削。系统测试不仅是检测软件的整体行为表现，从爿一个侧面看，也是对软件开发 设引的再确认。 软件自动化测试理论基础 第三章软件自动化测试理论基础 自动化测试系统的开发过程应该遵循软件设计过程。成功自动化测试系统的实现应 该建立在一定的理论基础之卜- ，下面简要介绍成功自动化测试的理论基础和设计关键。 3 1 自动化测试的定义及目标 测试自动化是使测试过程可以以流水线式来执行，可以使测试工作进行的更快，没 有时延，进行自动化测试的测试用例能在机器上轮流运行。 例如，几个组开始对回归测试进行自动化测试。这些测试用例包括重复或者需要重 新运行的测试用例，这些重复的测试主要是验汪曾经通过的测试用例在代码修改之后是 否还可以正确的通过测试。这些测试用例需要运行的次数比较多而且比较厌烦。 同时在软件测试的其它部分也同样存在测试效率和准确性的问题。例如数据表的配 置，如果是测试人员手工进行配置，出错的概率一般比较大，但是如果采取自动化配置 的方式，出错的概率相对来说就比较小，、况且不论运行多少次，数据的配置一般不会 出现差错。 但是，在开始进行自动化测试之前，首先需要提高软件测试文档的质量。使得测试 方法清晰而且容易理解。 l 、列出需要的数据名称和数据值。 2 、提供具体的操作步骤。 3 、详细描述测试用例设计的信息。 4 、描述期望的输出结果。 5 、设计清晰的测试用例。 6 、对如何进行测试进行详细的描述。 有些软件的安装过程比较复杂，测试人员需要花费大量的时问来安装这些软件。因 此尽量提高所需软件的易操作性，实现测试环境配置的自动化。 3 2 成功自动化测试的设计关键 3 , 2 1 对系统进行需求定义 需要对测试自动化的需求达成一致，要有测试需求，这些需求详细地描述测试的内 容。这些信息要在自动化测试设计过程中加以明确化。同时，要对测试的预期目标加以 软件l ! _ i 动化测试理论基础 一 _k一 箍述。许多测试人爨认为测试自动亿是正确的选择，不需要捂述其详细的瓣标。f 萄是 人们选择自动化测试的一些理出： l 、稳藩软件灏试逶瘦，提离软件版本靛雯薪。 2 、允许测试频繁的执行。 3 、透过减少手工溅试貔劳动力来减少 l l l 试费箱。 4 、提高测试覆盖率。 、爨僳测试一致缝。 6 、提高测试的可靠性。 7 、龛诲铡试司+ 以内不懂按术豹大虽寒进季亍。 8 、定义测试过程，减少测试依赖性。 9 、搜测试变缮有意义。 在丌发阶段和测试阶段，阻及钡0 试人员和运行自动化测试的人员之间追求的醋标是 不一搀豹，是然一些自动纯测试的疆掭刁i 窭易达成一致。爨动化测试通鬻可以提蕊测试 人员的技术层次，为了重躐曾经茂现的错误，测试人员必须充分了解自动化测试糟例。 但跫通过囊动纯测试来学习测试技术不是一秘可取酌方式。 在执行测试用例的时候，手工测试人员通常做一些不被注意的事情。他们对浏试进 行鞭先计划，褥到所需要黪资源，安装测试需要的软件，运行测试用例，检查1 0 9 文件 寻找是否些异常发生，对比测试结果，保存测试结果，为下一个测试羹渐设置环境， 分橱错误，寻找错误模式，设计且执行以确定错误的位置，汇报错误信息以便修改和书 写总结报告以便其他人可以明岛测试的覆箍率。 不要追求对镪一部分都进行自动化测试，应该寻找最大的反馈点，进行部分自动化 测试是一种眈较躜智的选择。也许想着对测试的执行避行自动纯雨对确认过程手：e ：撮 行。或者怒对确认进行自动化而测试用例的执行过程手工来进行。一些人认为，除非自 动完成每一俘事德，否翔就不口蠢动讫测试。翔慕伐佼怒追求一静揍簸，芬 冀_ 这样镞。 如果为了i 薹i 行成功的自动化测试，应该把注意力集中在可以很快进行自动化测试的部分 和需要霞复筏行静部分。 对自动化测试需求进行定义可以使这些目标明确化，而且在走向成功自动化测试的 方淹上又迈进了一步。 3 22 对系统进 曩零 予牲证明 翥蚕对蠡动纯溅试款可牙缝避喜亍谖鞠。一般嚣言，可行性证明过程鬟要花赞比较 陡的时间。为了得到准确的结果，需要部门每一个测试人员的参与。 在可行链证昵过疆中尽可熊黪对工具以及测试方法进行确认。自动化测试可行性 证明通常来说比较困难，需要尽可能的找到问题的答案。首先需疆明确融己的 j 具和方 软件自动化测试理论基础 法是否适合现有的项目和测试人员。 对大部分人来说，测试自动化意味着g u i 测试自动化，这并不是真f 意义上的测 试自动化。 这罩是一些进行可行性证明的选项： l 、回归测试： 这种测试用例是最好的自动化测试选择之一。 2 、配置测试： 自动化测试也许可以帮助解决软件的跨平台问题。 3 、测试环境安装： 同样的设置进程或许用于许多不同的测试环境，在自动化测试之前，首先需要对自 动化测试环境进行配置。 4 、非g u i 测试： 自动化命令行和a p i 的测试要比对g u i 的测试容易。 3 3 自动化测试系统应该具有的性能 一个软件可能含有三种不同的接口：命令行接口，应用程序接 和图形用j 界面接 口。有的软什捌有所有这三种接口，有的则只有其中一种或者两种。这些接口可以用来 进行测试。由这三种接【_ _ _ i 的特性所定，应用程序接口和命令行接口与图形用户界面相比 易于进行自动化测试。在进行自动化测试之前首先确认软件中包含上面的接口；有的软 件以隐含的方式包含 二述接口或者这些接口默定仅为内部用户使用。如果软件内部没有 包含上述接口，需要在软件中添加命令行接口或者应用程序接口。 但是，首先讨论一下图形用户界面的自动化测试。实际的图形用户界面的自动化测 试比人们实现的自动化测试难的原因有好多。首先；图形用户界面的自动化测试需要编 写手工脚本。大部分的图形用户界面的测试工具都有诸如“记录和回归”等特性。这个 想法是很关键的。当进行手工测试的时候，测试工具驻留后台，记录所做的一切事情。 该工具将产生一个脚本，可以运行该脚本来进行重新测试。但是这是一种不可以实现的 想法。一些自动化测试的研究人员得出结论：尽管可以记录和产生小量的代码，许多问 题会阻j r 记录程序有效地记录和产生测试脚本。因此，对于图形用户界面的测试最好是 手工进行。 图形用户界面难以进行自动化测试的第二个原因就是技术方面的挑战。创建可以与 最新的图形用户界面技术相匹配的图形用户界面测试工具需要一定的经验。该困难也就 是为何图形用户界面的测试工具比较昂贵的一个原因。这是一项艰难的任务。非标准化 和用户控制的特性可以增加其他的困难。一般来说，可以找到解决的办法，但是需要对 产品的源代码进行修改或者对现有的测试软件进行升级。测试软件中的错误需要分析和 软件自动化褒4 试理论基础 改正a 为了能够对产品用户化的元素避行有效的测试，测试工具也需瑟一定程度的图形 用户纯。 图形用户界面自动化测试难以进行的第三个原凶是图形用户界面自动化测试工具 蔫要与鹜形焉户界面修改保持一致。在整个开发过程中需要对图形蠲户界西静修改帮撬 新设计是众所周知的。一般来讲，这种想法比较现实，由于图形用户界面的第一个版本 是比较糟糕懿。但是在g u i 保持交纯豹过程中，为了保持鑫动位灞试数运厅麓够豫楚在 适当的位置运行一样，需要花赞大量的时问修改c & s e 米匹配变化了的片j 户界丽。 蚕依戆0 u i 熬蠢动仡测试作为溺试赣俘产燕魏基磊爨有一些寡毽秀莓在。当然，銎形霹 | 户界筒仍需要进行测试，也可以选择对这些c a s e 进行自动化测试。但是需要有其他的 测试，褒对0 u i 述行重凝设计蜃仍醴搜霹l 这些测试蠲倒寒划较锌懿核心功能遴行溅试。 这些测试能够在不同的界面下运行：命令行或者a p i 。彳i 论怎么做，自动化测试可能霈 要剥溅试工具邀钓：修改，因此，一个可编程黪图髟罔广t 赛嚣愁最可豢瓣。 为了简化对a p i 的测试，町以把它与一个解释器进行绑定，例如：t c l 或者p e r 甚至p y t h o n 。这霹既促进交互测试的避行，也可以加速皇动化测试的玎发进程。 下面是一个如何避免对w e b 相关软件的g u i 进行自动化测试的例子。可以得到通 过浏夔器柬控制w e b 界面的图形用户界面工具。然而，蛊接测试w e b 浏览器与w e b 服务器进行通信的协淡是比较容易的。p e r l 就是一门可以直接与t c w i p 端口进行通信 的语害，它可以用来进行这种自动化测试。运用高级按口技术的应用软件，例如客户端 j a v a 或者a c t i v e x ，不能采取这种测试。但是如果这种方法具有可行性，与通过g u i 进 行自动化测试的方法相比，这种方法容易实现。 代码性能 提高代码的执行性能通常会增加代码的复杂度，甚至威胁到代码的可靠性。对于自 动化测试来诱，这是一个特溺需要注慧的遗方，因为缀少把注意力集中在自动纯本身。 这样就设置了个在没有提高产品代码性能的前提下提高测试执行数塌的限制。如果测 试用侧集是确实需要考虑| 每因索，镬蠲更多的硬件或者减少溺试焉恻集中的 鬟| | 试数，可 以提离性能。般来说，测试用例集中有很大的冗余度。 飘行缭巢分丰厅 一个普遍的棘手难题是在自动化测试失败后该如何做。失败分析通常是比较困难 麓。缎难判骚个错浚提示信愚是警告信患曼是翟痔中熬错误。溅试璃铡运牙失效虿戆 是测试用例集存在问题，也可能是测试设置的错误，或者是软件中的错误。因此需要对 需错诶信怠遵季亍分褥，臻定警现镑误静黎强。在进行 樊| | 试之懿黠 燹l | 试翊铡集中一般数酝 置错误进行检奄，提高测试用例集的错误报告功能可以提高测试用例榘的执行性能。在 测试过程中可以改正一些疆曼游错误，- l 塑霹瓯对潮试人员送行继训，教瞧囊如俺去分掇 错误。甚至可以查找到一些可以安全删除的测试用例，因为这些测试用例是多余的或者 是对隙l 器螅功瞧进货测试。鸯谗多减少错误警告，提裹测试镶误分板黪方法，辞错误 软什白动化测试理论基础 分析方法是设计一个结果后期处理程序，该程序执行自己的分析并且过滤出错误信息。 尽管这种方法可以运行，但是它增加了自动化测试系统的复杂性。而且，在后期处理程 序中的错误信息严重破坏测试的整体性能。 测试用例集应具有高的可读性 一般来说，在软件测试中都有一个长时间使用的测试用例集。该测试用例集是由项 目的前一些开发人员设计的。测试人员依赖这个测试用例集进行测试，但是不知道它究 竟是干什么的。事实上，究其本身的作用而言，长期实践证明这个测试用例集是很有价 值的，但是随着时间的推移，这些测试用例集变成一种令人不解的状态。造成这种后果 的主要原因是测试用例集的可读性比较差。能够看懂一个测试用例集和理解一个测试用 例集的测试目的是很关键的。良好的文档是解决该问题的一种比较有效的方法。代码覆 盖率分析是另外一种方法。失去了可读性，就会导致对测试用例集的过分依赖。 测试用例集应具有高的可维护性 每次用一个测试用例集把所有的输出结果保存到一个文件里面。然后用这个文件与 以前产生的输出文件进行比较，这些输出文件被称为是“黄金”文件。这是一个发现回 归测试中软件错误比较好的方法。但是这种方法比较敏感，它产生好多警告信息。就其 原因是随着时间的推移，程序员有意地或者是无意地对输出信息作了一些小的改动。无 论何时这些改动信息出现在输出文件中，都会出现测试失败信息。很明显，“黄金”文 件需要更新，但是这需要花费大量的时间进行分析。一个比较好的维护方法是仅仅选择 某些特定的软件输出作为检查对象，而不是比较所有的信息，测试将仅仅比较与所测试 的性能相关的信息。软件的接口也可能会发生改变，从而不能运行旧的测试用例。曾经 提到过，这对图形用户界面测试来说是一个挑战。对于这种情况的测试用例可以采取函 数库的方式，产品的变化仅仅要求对库进行更新测试便可以正常运行。 自动化测试系统应该具有完整性 当自动化测试报告测试通过的时候，它确实通过了? 这就足所谓的测试完整性。对 测试结果的依赖程度有多大? 错误警告是该问题的一个很大的部分。当测试失败后，人 们恨它，这将显示是一个测试用例集的问题或者设计的问题。错误报告信息没有太多的 用处。有时候需要敏感测试，当一些消息看上去不f 确的时候就报告错误信息。测试结 果包括：通过，失败，第三个结果是：不能运行或者不可解决。对这些结果进行排序是 很困难的。获得正确的测试结果是完整性的一部分。另一个部分是确保运行正确的测试 用例集。 测试用例集应该具有独立性 自动化测试不能完全复制手工测试。已经写好的测试用例默认将由个有智慧的， 有想象能力的，注意力集中的人员来运行。使用自动化，反而是一个没有洗话能力的计 算机来运行。必须告诉计算机一个错误信息是什么样子。也需要告诉它如何修复以便能 够保证运行整个测试用例集。进行过自动化测试的测试用例集应浚能够作为一个子测试 较件自勘化测试理论基础 用例集或者单个测试用例来运行。实现该功能的可靠方法是使测试用例集独立。每一个 测试雳饲集需瑟设置它鹈测试环境。手工测试过程中，涌试天爱通常鞠自溺试厢衡的鞲 的或者作用。一个容易犯的错误就是在自动化测试中使用同样的方法，这样会导致一个 “伪装”静铡试甭镶象，一个溺试焉弼巾静错误褥酸环后面餐测试。褥置这些溺试用铡 集不能进行单独测试。这就很难利用进行过自动化测试的测试用例集来帮助分析错误。 当这些阚遂疆联时，入们首先会陵疑鑫动纯溺试笺矮羹。溅试瓣独立戆会壤热测试懿滚 复度和冗余度。独立性测试提供测试具体的错误诊断方法。 系统癍关翕蔫豹碍重复性 仅仅。个错误报告信息是没有多大用处的。所以，必须保证在每次运行时都采取闹 撙懿方法，这鹱疆裁馁耀睫掇数。大部分语言孛所建立戆睫掇数都隐簸了视戆化过程。 使用随机数会导致每次运行的测试结聚都不同，这就会阻止错误的分析。有两种使用随 瓿数产生爨素避免这些曝题的方法，方法之一是使用个避定豹僮来初始化越祝数产尘 器。如果想设计一类测试用例，用可预测和可控制的方法来设嚣随机数的变化；另为一 个方法艇是预宠把这些随极数产生在数据库或者文件中，然后把这些数据输入到测试过 程中。首先解释一下在实际测试中使用随机数所产生的问题，当进行手工测试的时候， 霖要慰文l 牛和记录进行命名。当进行盆动化测试的时候该如何进7 7 - 7 一秘方法是在测试 中为记录定义一个固定的文件名。如果这些文件需要长久保存，就需鬃文件名转换机制 良确保不同的测试用例不会发生冲突，这种做法通常是比较明钽的。然而，也有许多随 机产生文件名的情况。不幸运的是，这并不避一种有效避免文件名冲突的方法，反而破 坏测试的可重复性。这种自动化方式明显低估了名字冲突的可能性。假设在两个测试用 例中，四个数字是组成记录名的随机元素，鏊本随辊籍法显示，仅仅4 8 条这样的记录 产生名字冲突的可能性是o 1 。如果怒1 1 8 条记录，几率将增加到o + 5 。 3 4 自动化测试框架 一个普遍实用的方法就怒开发可以在许多测试中使用的测试函数库。如果测试允i ： 与产豁静菝盈交纯疆离，捷麓瘁是援有效酌方法。毽爱这静方法会缮霸牙发王掾量。疼 主要集中在他们所覆靛的部分，并且设计不够完整。没有很好的文档与之相匹配，测试 中对这些疼静佼灞会攫难遵瓣。当最纛发凝翊莲夔时侯，缀蕊筏爨淘逐是在功缝方嚣还 是在使用方面。由于库的复杂性，即使库中的函数遭到破坏，维护人员也不愿意去修改 它稍。一个竣确的结论就是婺确保函数疼其毒跑较好蛉设诗。瞧是，实践褥出的结论是 自动化测试的库没有得到充分详细的没计。一些函数库中包含许多没有用的函数或者仅 投霞臻一次的函数。这可鹱逡戏测试题剿之翊静代码剽本，一些函数瘁 _ l 也存在一些难 以对麾函数进行优化处理的小变量。一种被广泛谈论的技术就是允许用一种简单的表格 式紊写溅试鼹饿。这糖技术有不同懿名称，娜：表驱动，数摆驱动甚至“三代”自动化。 软什白动化测试理论基础 数据驱动的测试要求所写的解释器可以解释和执行测试语句。这种结构的优点之一是允 许测试用例使用易读的方式来描述。这种方式最适合拥有测试领域专家的测试组，这些 专家并不是资深的程序员。但是，数据驱动的解释器本质上是一个函数库，并日有小的 语言架构在它的上而。对于一组测试语言进行发计，开发和测试也有一定的难度。不可 避免，这些语言会逐渐庞大起来。有些测试人员希望测试第一部分的输出是测试第二：部 分的输入，这样就需要增加变量。然而，一些测试人员希望重复执行某些事情一百遍。 因此需要添加循环控制逻辑。这样就会产生出另一种语言。如果看上去像是沿着这样的 路前进，使用现有的语言如：p e r l ，p y t h o n 或t c l 要比自己尝试着设计一门新语言好。 3 5 自动化测试存在的困难和需要解决的问题 尽管已经简化了一些内容，但是自动化测试不可避免的使测试过程复杂化。测试人 员需要学会如何诊断自动化测试所发现的问题。如果没有出现这种问题，测试人员通常 认为这是自动化的问题，他们给自动化测试的设计人员打电话，、止他们帮助诊断每次自 动化运行。研发人员也对他们不熟悉的自动化测试代码产生怀疑。因此，测试人员必须 学会手工或者通过一个小的脚本来重新产生错误。 对测试用例集的j 作并没有结束。需要对测试用例集增加新的内容以便提高代码覆 盖率或者测试新的功能。如果旧的测试用例集已被破坏或者由于多余而被删除，需要刑 i u 的测试用例集进行修复。测试人员也可能换岗到新的测试平台。保证测试用例集的实 时更新是比较困难的。种想法是在每一个大的版本出现后对原有的测试用例集进行重 新检查。 随着时间的推移，现有的测试用例集可能不会发现任何软件错误。研发人员对测试 用例集有一个很好的理解，发现怎么在第一次完全通过测试。这就是著名的杀虫剂的自 相矛盾。研发人员已经提高他们的设计，改进了出错位置代码的质量，在这些位置，他 们不会晰现测试用例集设计测试的一类错误。一些人可能怀疑测试用例集是否还能正常 的工作。现在就需要估计是否该到提高门槛的时间。 上面所述的就是进行成功自动化测试的基本理论和实现方法。 移动智能网系镜中服务层测试的介绍 第四耄移动智能网系统中服务层