（计算机应用技术专业论文）fxc+ng可追踪性测试实践.pdf

浙江人学硕十学位论文 摘要 软”测试在软件丌发过程中是。个非常重要方面，它并不仅仅限于在得到了开发完 成的代码后，对代码进行功能性测试。软件测试技术的不断发展，已经让它渗入到软件 生命周期的方方面面。从一开始对软件需求的评估和确定，到测试用例的设计，再到对 测试结果的分析和评估，乃至于对整个软件产品做出的质量评估，都成为软件测试的一 个蕈要组成部分。中国软件业的发展，不应该停留在对本身低廉劳动力的依赖上，而应 该不断的提高产品的质量以及服务的质量，这过程中，软件测试也应该不断发展以适应 不问的要求。 本文简要介绍了当前软件行业测试技术的发展，讨论了软件测试需求分析追踪和软 件测试覆盖率分析的技术，并通过在道富技术中心的多个项目的实践，提出b u t t o n u p ， u f ) d o w n 和s s u p 三种测试用例设计组织方法，分析比较了这三种方法的优缺点以及适合 的小同项目特点。同时，介绍了在道富技术中心实行的一些测试结果报告，通过对这些 测试结果的分析，能尽量发现项目开发以及团队协作之问的问题，达到对团队能力的改 进和提高。文章以f x cn g 项目的实践为例，在软件丌发牛命周期的不同阶段中分别应 用| 二述测试技术，建立测试用例与测试需求之间的l i ：追踪性联系，详细说明了如何将这 些技术应用项目，提高测试的质量和效率的实践经验。最后，总结目前的研究工作，提 出了不足和以后改进的方向。 关键词：软件测试，测试需求，测试覆盖率，测试用例，质量保证 第l 页 浙江大学硕十学位论文 a b s t r a c t s o f t w a r et e s t in g 1 i sav e r yi m p o r t a n ta s p e c ti ns o l t w a f e d e v e e p m e n t p re c e s s s o f t w a r et e s t i n gf o c u s e so nt h ef u n c t i o b st e s ta f t e rt h et e s t e r sg e t t 1 1e ：o d eb e f o r e ，a st h ed e v e l o p m e n to fs o f t w a r et e s t i n gt e c h n o l o g y ，iti sb e c o m e m o r ea n dm o r ei m p o r t a n tl ot h es u c c e s s ( ) fa p r o d u c t s t a r t i n gf r o mt h e w ：, r i f i c a t i o no f s o f t w a r er e q u i r e m e n t ，d e s i g nt h et e s t c a s e ，a n a l y s i st h et e s t r e s u l ta n dd e l i v e rt h eq u a l i t yr e p o r to fp r o d u c t ，s o f 。t w a r e t e s t i n gp l a y sa cr jt i c a lr o l ei nt h es o f t w a r ed e v e l o p m e n tp r o c e s s t h ec h i n e s es o f t w a r ei n d u s t r v s h o u l dn o tr e l yo nt h el o w c o s ta d v a n t a g eint h en e a rf u t u r e ：w em u s t i m p r o v e t h eq u a l l t yo ft h ep r o d u c t sa n dt h es e r v i c e s d u r i n gt h ep r o g r e s s ，s o f t w a r e t e s t i n gi sa l s od e v e l o p i n g t h i st h e sisg i v e sab r i e fi n t r o d u c t i o n0 fc u r r e n tt e s t i n gt e c h n o l o g ya n dt h e q u a li t ya s s u r a n c e i nt h ew e t l d ，d i s c u s s e st h es o f t w a r et e s tr e q u i r e m e n t tr a c e a b i l i t ya n dt e s tc o v e r a g ea n a l y s i st e c h n o lo g y t h et h e s isp r e s e n t st h r e e d if 、f e r e n tt e s tc a s es t r u c t u r ed e s i g nm e t h o d sa c c o r d i n gt ot h ep r a c t i c e sins t a t e s 【r e e tz h e j i a n gu n i v e r s i t yt e c h n o l o g yc e n t e r ，w h i c ha r es u i t a b l of o rd i f f e r e n t t y p eo f p r o j e c t s ，t om e e tt h et e s tr e q u i r e m e n ta n di m p r o v et h ep r o d u c t s q u a lit y t h et e s tr e p o r tm a t t i x e sa r ei 1 1 u s t r a t e di nch et h e s i s t oi m p r o v et h et e a m w o r k a l i dt h eq u a l i t y0 fp r o d u c t sw i t ht h ea n a l y s i so ft h et e s tr e p o r t b a s e do nt h e 【) r l c t i c eo f f x cn gp r o j e c t ，w eu s et h ea b o v et e c h n o l o g l e si nd i f f e r e n tp h a s e s 0 tt h ed e v e l o p m e n tp r o c e s s ，s e tu pt h et r a c e a b i l i t yf e l a t i o n s h i pb e t w e e nt e s t c a s ea n dt e s tr e q u r e m e n t ，a n dd e t a i l e dt h ee x p e r i e n c e so fh o wt 0i m p l e m e n tt h o s e t e c h n o l o g i e s 。1nt h el a s tp l a c e ，w ei m p l e m e nlt h ea b o v et e s tt e c h n o l o g i e st o f x cn g p r o j e c t ，w h i c hm a k et h et e s t e f f o r t m o r ee 1 1 e c t i v ea n di m p r o v et h e p r o d u c t sq u a i t y k e yw o r d s ：s o f t w a r et e s t i n g ，t e s tr e q u i r e m e n t ，t e s tc o v e r a g e ，t e s tc a s e ，f 4 u a lit y a s s t l ta n c e 第1 i 页 浙江大学硕：十一学位论文 1 1 软件质量问题 第一章引论 随着信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的质 避自然成为人们共同关注的焦点。不论软件的生产者还是软件的使用者，均生存 在竞争的环境中，软件开发商为了占有市场，必须把产品质量作为企业的重要目 标之一，以免在激烈的竞争中被淘汰出局。用户为了保证自己业务的顺利完成， 二5 然也希望选用优质的软件。质量不佳的软件产品不仅会使开发商的维护费用和 用户的使用成本大幅增加，还可能产生其他的责任风险，造成公司信誉下降，继 f 面冲击股票市场。在。些关键应用( 如民航订票系统、银行结算系统、证券交易 系统、自动飞行控制软件、军事防御和核电站安仝控制系统等) 中使用质量有问 题的软件，还可能造成灾难性的后果。 软件危机曾经是软件界甚至整个计算机界最热门的话题。为了解决这场危机， 软件从业人员、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的 软件危机实际上仅是一+ 平十状况，那就是软件巾有错误，正是这些错误导致了软件 jf 发在成本、进度和质量上的失控。有错是软件的属性，而且是无法改变的，因 为软件是由人来完成的，所有由人做的工作都不会是完美无缺的。问题在于我们 如何去避免错误的产生和消除已经产生的错误，使程序中的错误密度达到尽可能 低的程度。 给软件带来错误的原因很多，具体地说，主要有如下几点： 【、交流不够、交流上有误解或者根本不进行交流 在应用应该做什么或不应该做什么的细节( 应用的需求) 不清晰的情况下进行 _ j f 发。 z 、软件复杂性 图形用户界面( g u i ) ，客户n 务器结构，分布式应用，数据通信，超大型关 系型数据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现 代软件丌发经验的人很难理解它。 第5 页共6 2 页 浙汀人学硕+ 。学位沦史 文程序设计错误 象所有的人一样，程序员也会出错。 4 、需求变化 需求变化的影响是多方面的，客户可能不了解需求变化带来的影响，也可能 知道但又不得不那么做。需求变化的后果可能是造成系统的重新设计，设计人员 的日程的重瓤安排，已经完成的工作可能要重做或者完全抛弃，对其他项目产生 影响，硬件需求可能要因此改变，等等。如果有许多小的改变或者次大的变化， 项目各部分之间已知或未知的依赖性可能会相互影响而导致更多问题的出现，需 求改变带来的复杂性可能导致错误，还可能影响工程参与者的积极性。 5 、时间压力 软件项目的日程表很难做到准确，很多时候需要预计和猜测。当最终期限迫 近和关键时刻到来之际，错误也就跟着来了。 6 、自负人更喜欢说： 没问题 这事情很容易 几个小时我就能拿出来 太多不切实际的没问题，结果只能是引入错误。 7 、代码文档贫乏 贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多 错误。事实上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员 将代码写得清晰和容易理解，相反他们认为少写文档可以更快的进行编码，无法 理解的代码更易于工作的保密( “写得艰难必定读的痛苦”) 。 8 、软件开发工具 可视化工具，类库，编译器，脚本工具，等等，它们常常会将自身的错误带 到应用软件中。就象我们所知道的，没有良好的工程化作为基础，使用面向对象 的技术只会使项目变得更复杂。为了更好地解决这些问题，软件界做出了各种各 样的努力。 第6 贞共6 2 页 浙江人学硕士学位论文 1 2 测试生命周期 一个优化的s o a 测试生命周期包括了定义，计划，设计，执行和报告阶段。传 统的s q a 活动，一般足在软件开发的详细设汁完成之后j 介入的，然后在系统部 署到产品环境下结束。但是随着测试技术的发展，新的测试理念不断的产生，s o a 测试生命蒯期基奉上从项目一开始就介入，并且支持产品的后期维护。这样就要 求： 在软件开发周期中尽早的发现问题，来降低修复题所付出的代价； 利用并支持需求追踪能力； 使用包括工具，标准以及方法论来提供质量报告。 下面的图1 说明了传统测试和全生命周期测试的不同点： 图1 在全生命周期测试中，测试工作覆盖了软件，f 发的所有阶段，在需求分析阶段， 测试需求分析技术能够从测试工作的角度出发，提取测试的需求：在架构和开发 阶段，应用合理的测试用例设计方法和测试用例组织方法，设计出高效率的测试 用例，在保证测试覆盖率的前提卜，提高测试的质量和测试的效率。最后，为了 改进团队的能力，揭示产品中存在的问题，q a 团队还要提供一份直观清楚的测试 报告和缺陷分析。 第7 页共6 2 负 浙江人学硕士学位沦文 1 3t cq a 的介绍 道富银行浙江大学技术中心( s t a l es tf e e tz h e j i a n gu n i v e r s i t yt o c h n o l o g y ( e n t e r ，s s z u t c ) ，足由浙江大学和美国道富银行( s t a t es t r e e tc o r p o r a lj o f l ) 存2 0 0 1 年共同建立的，以浙江大学的科研力量为主体，而向国际和国内市场，致 力丁全球化金融证券信息系统的丌发和服务。 道富技术中心致力于开发开放式的、易 二移植的、高度灵活的一流软件以提高 道富公司的全球化和网络化金融服务能力；产学研相结合，将浙江大学的巨大智 力资源转化为实际成效。通过和道富公司4 年多来的合作，道富技术中心已经拥 柯超过3 0 0 人的开发团队，为道富公司承担3 0 多个项目的开发工作。 作为技术中心的一个独立的部门，q a 部门最初由各个项目组中经验丰富的开 发人员组成，在短短两年时间里，部门已经从不到1 0 人扩展到5 0 多人，工作内 容也从当初单一的功能测试，扩展到软件生命周期的各个阶段的质量保证工作。 部门非常重视和鼓励个人技术创新，小断学习新的软件测试技术和方法，掌握 和运用各种软件测试工具；同时，与s e p g 和p m o 部门及丌发部门紧密配合，通过 持续不断的软件过程改进及优化，保证软件开发过程的质量以及最终软件产品的 质量。在过去的两年多的时间里，我们经历了很多挫折与困难，也在艰难过后获 得了不少成功与快乐，在此，我想把我这两年来在q a 组内的研究和经验与大家分 t 苫。 第8 页共6 2 页 第二章测试需求分析与追踪技术 软件是开发出来给客户用的，软件开发团队要完成一个成功的软件丌发，首先 要清楚无误地了解用户的真实需要。同样地，软件测试跚队如果要完成一次成功 的软件测试，也要清楚无误地了解特定项日中的测试需求。而测试需求的提取， 往是通过对软件需求( 功能，性能，用户，平台等) 的分析，米实现对测试需 求的确定。因此，我们要通过对软件需求的分析，来获得软件的测试需求。 软件需求的特点，一般应包括以下几个方面： 正确性： 一个软件的需求应该是正确无误的。也就是晚，软件的需求能够客观 反映产品的现实需要，软件需求的描述应该要和现实世界的要求符合。 一致性：一个软件的需求应该是一致的。软件是一个整体，是一个各个部件互 相交互的系统。软件的需求在不同的部件中，要体现出一致性。 完整性：需求的说明应该是完整的，一个需求就是一个完整的功能，需求中的 饪何缺失都会引起开发团队和测试团队的不理解。 精确性：需求的描述应该是精确的。要详细说明具体的要求，不能含糊其词。 可读性：需求要可读性强。需求是提供给开发团队和测试团队的第一手资料， 要、止他们明白无误的理解需求，就要求需求本身要有很好的可读性。 可测试性：需求也要是可测试性的。如果一个需求没有可测试性，那就无法验 汪这个需求是否已经完成。 要从软件的需求中提取出测试的需求，需要进行细致的分析和系统的理解。下 向介绍了几种需求分析技术，为我们收集完整清楚的测试需求，形成有效的需求 追踪体系提供了很好的帮助 1 3 。 2 1 v o c t 测试需求分析技术 “客户声音表”v o c t ( v o i c eo fc u s t o m e rt a b l e ) 技术e 3 一般用于分析复杂 的客户需求，尤其是实际产品环境中的使用环境。这一技术要求洋细分析用户的 雠个需要，对于每个需求，都至少要吲答f 面这些问题： 浙江人学硕士学位论文 用，。在这个需求j ：要求得至f l t 么 用户什么时候需要这些需求 在哪种情况下，他们需要这些功能 为什么他们需要有这样的功能 他们想要这些功能怎么样的被实现 表1 是一个v o c t 的例子： 第1 0 页共6 2 页 u一皿四卜台宣。苗等u岫oooi搽 卫毫e 芑 重营 强 巴 臻 口) 竺 p i 善 藿耄| 舌 差8 罟 萋萋萋霎萋耋耋霎耄 里罡 卜o o 苫 霉 t o 厶 善 器 比 ； 当当 。 莹 案 。 兰 o a 芒 d z 9 尘 ko 山 口e j 姜8 c l 案 案 吝； 曩垒 事刁 。 蔷旦 呈兰 口。 8 善乒 i u 山 山 c 菌 j 霎主譬 暑 = 岳 l i i y 兰 一l l 堇 o o 山 u j j 差董：耋 童 量 璺 善薰 苟 巴 曩 翌 量 坐 重= 量耄 至 a 毋 q 臻 山 u au a山 j 口， 卫 三 善藿 墨叠 m-c_ 砉 量 a 历 曼i ； l 喜董 山 u ju i山u j 暑 l 萋重 o 罡 e 宴 王 它母 邕 e i l l n i l 誉 罨 避暑 重砉 罢星 u f 薹耋 蚕l 一 矗 e 鲁 8 戗智篷扑_；斗=匿鼎长=_【=舞 浙江人孕_ _ j ! 士学位论文 2 2k a n o 需求分析技术 k a 1 0 需求分析技术 2 是通过对输出，服务或者产品产出的特色，把用户的满 意度分成： 基本需求( 1 h r e s h o ld ，用户晶小的需要) 满意点( p e r f o r m a n c e ，可使用户高兴的额外的特色) 亮点( g x c i t e m e n t ，用户都没有希型得到的功能) 图2 通过二维坐标轴形象表示了这三种不同的需求存对用户的满意度的作用。 h 唔h ；| 哕哕 畦 f u l l yi m p l e m e l l t e d 焉丽a p r o d u c t u b c h o n 矧2k a n o 模型 革术需求的一些需求，是必须要实现的功能，如果这些需求没有实现，产品将 小会被用户所接受。满意点是有一定的附加价值的需求，如果这些需求没有实现， f ，能会降低用户的满意度，而如果实现，将会提高用户的满意度：，亮点则是用户 没有要求的功能，这此需求可能用户一丌始的时候并没有这样的要求，1 _ _ l 是实现 的几町能预见到了现实市场的发展，提前开发了些将米更自竞争力的功能。这 样，在以后的同类产品的竞争中，这些亮点功能将大大提高产品的竞争优势，从 ；毙带给客户虽大的满意度。当然，如果这些功能投有被实现，用户也并不会降 一面能带给客户最大的满意度。当然，如果这些功能没有被实现，用户也并不会断 第】2 页共6 2 页 浙江人学硕士学位论文 低满意度。 要使用k a n o 分析方法， 般都会问用户两个简单的问题： 1 如果这个产：品有了这个功能，会对你的满意度产叫i 怎么样的影响? 2 如果产品没有这个功能，你的满意度会有什么样的变化? 用户需要从下面几个选项中给出他们的回答： a ) 满意； b ) 一般： c ) 不满意； d ) 无所谓； 一般来说，基本需求会在第一个问题上得到b ，在第j 个问题上得到c ；而对 于满意点的答案，对于第一个问题会是a ，第二个则是c 。在这个时候，就需要跟 f h 户进行商量，是否愿意付出一定的代价来获得这些满意点的需求。对于亮点的 回答，则往往是第一个问题是a 或者d ，第二个则是d 。就是用户对有没有这种功 能无所谓，开发团队也不能马上决定要摒弃这些功能，因为很有可能这些功能将 存未来发挥更大的作用。 2 3 测试需求的追踪 在我们形成完整的测试用例之后，所有的软件需求都会至少被测试到一次， 般情况下有可能会多次测试到这些软件需求，因为这些需求在软件系统的很多部 分都会体现。这一关系呵以用图3 来表示： 第1 3 页茫6 2 页 浙江大学硕 一学传| 文 图3 需求追踪是要建立起测试需求和测试用例的联系，然后通过对测试用例覆盖权 值的计算，以及对每个测试 i i 例覆盖需求的情况，束分析得到软件的测试覆盖率， 这一技术将会在下。章软件测试覆盖率中进行详细介绍。 表2 是r 1 m 表的一个简单的例子： “e s tc a s e t lt 2t 3t 4t 5t 6t 7t 8t 9t l ot l lt 1 2 t 1 3 l 沁a uir e m e n tr 1xx x x x x r 2xxxxx r 3x xxx x x xx 表2 ：r e q u i r e m e n tl r a c e a b j1i t ym a t r i x 需求追踪表格( r t m ) 给出了一个功能说明和测试用例之间的联系，这个帮助 我们确定测试用例文档是否已经包括了所有的功能单元的测试。从这个表格里面， 我们也可以得出对一个测试过程来说，有多少l l i ，, j 是测试过的，有多少需求是没 有经过测试的。 从前面的分析，我们知道了要得出软件的测试需求，要通过肘软件需求的完整 系统的分析刁能达到，我们也要理解软件的测试需求的一个发展过程。图4 1 5 第1 4 页共6 2 页 浙江大学硕士学位论文 很形象的说明了如何从个现实世界的软件需要( n e e d s ) 来发展成为个软件测 试需求，并能够被我们的软件丌发人员或者测试人员所理解。 图4 对于道富技术中心的项目，大部分的软件需求都是通过b o s t o n 的同事拿到的， 但是往往我们拿到的都只有软件需求，并没有相应的测试需求，这就需要我们技 术中心的成员自行分析，来提取相应的测试需求。 对于软件测试需求文档，技术中心目前还没有一份j f 式发布的文档规范，因此， 我们只是在各个项目内部有一些非正式的文档撰写。下面，是一。份以技术中心内 的一个项e l 为背景，所使用的软件测试需求文档中的一个重要组成部分：需求测 试说明分类表。 通过对需求的分析，考虑实现这些需求的风险，对这些需求进行优先级排序， 时，提出对这些需求所应该要进行的测试。 表3 说明了我们的测试需求以及相应的分类。 r e q u i r e m e n t sd e s c r i p t i o np r i o r i t y t e s tc a s e i d r 1a na p p l i c a t i o ns p e c i f i cs e a r c hm e n uf o rg r o u p i n ga l lp 3t 1t 3t 4 d o c u m e n tc e n t r a lo b j e c ts e a r c hi t e m sn e e d st ob e 第1 5 页共6 2 页 浙江人学硕t 学位论文 c r e a t e d r 2ar l e wm e n ui t e mn e e d st ob ec r e a t e df o re a c ho ft h ep 3 t 2 t 4 t 6 f o l l o w i n g s e a m hi t e m se x i s t i n gi nt h ed o c u m e n t c e n t r a la p p l i c a t i o n ： l i b r a r i e s b o o k s h e l v e s b o o k s d o c u m e n t s r 3 t h en e w l yc r e a t e ds e a r c hm e n ua n dm e n uo b j e c t sp 1t 3t 4 n e e dt ob el i n k e dt ot h ee x i s t i n gg l o b a ls e a r c ha n d s p e c i f i co b j e c ts e a r c hm e n u s r 4t h es e a r c hr e s u l t sp a g ef o rt h es e a r c hd o n ew i l lb ep 2t 5 t 7 l e v e r a g e dt oi m p l e m e n tt h e “r e v i s es e a r c h “w h i c h i m p l e m e n t st h ef u n c t i o n a l i t yo fe a s yq u e u i n gb y p r o v i d i n ga nod t o nt os a v et h el a s tq u e r i e ds e a r c h r 5s e a r c hm e n uf r o m “m yd e s k ”l i n ko fd o c u m e n tp 1 t 2 t 6 c e n t m la p p l i c a t i o nw i l lb er e m o v e d 表3 需求测试说明分类表 表3 中列出了5 个不同的需求，以及相对应的7 个不同的测试用例，针对每个 需求，有一个或几个测试用例来测试这个需求。而每个需求的优先级，都是通过 对需求的分析，对功能以及实现进行风险分析，确定下来每个需求的优先级，并 以此作为这些需求的权值，利用r t m 的分析方法，来获得一定钡4 试卜的测试覆盖 率，具体方法将会在第四章测试覆盖率分析中进行介绍。 第1 6 页菸6 2 页 浙江人学硕士学何论文 第三章测试用例设计组织方法实践比较 测试甩例描述了一个输入、反应、或者是与箕相应的预期的响应，以便来半1 3 断 应用软件的工作是否正常。一个完整的测试用例，至少要包括：1 d 号，说明，测 试步骤，测试数据，预期结果，实际结果，版本号等等。没计测试用例，来确保 媾本路径集中的每一条路径的执行。根据判断结点给出的条件，选择适当的数据 以保证某一条路径可以被测试到。每个测试用例执行之厉，与预期结果进行比较。 如果所有测试用例都执行完毕，测试结果都与预期结果致，则应认为测试通过 了，产品具备了很好的质量。 设计测试用例有很多种方法 4 儿5 ，比较通用的测试用例设计方法有以下几 种： 一 等价类划分 一 边界值分析 一 错误推测法 因果图 等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的 内部结构，只依据程序的规格说明来设计测试用例。等价类划分方法把所有可能 的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代 表性的数据做为测试用例。 边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。人们从长期 的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在 输入范围的内部。因此针对各种边界情况设计测试用例，| 1 j 。以查出更多的错误。这 啦所说的边界是指，相当于输入等价类和输出等价类而言，稍高于其边界值及稍 低于其边界值的一些特定情况。使用边界值分析方法设计测试用例，首先应确定 边界情况。应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据， f 叮不是选耿等价类中的典型值或任意值做为测试数据。 人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编 ；检查这些错误的例子。这就是错误推测法。错误推测法的基本想法是：列举出 第1 7 页共6 2 页 浙江大学硕l 学位沦文 程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。 如粜在测试时必须考虑输入条件的各种组合，可使t 种适合r 描述对于多种 条件的绀合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。 果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。 3 1b u t t o n u p 设计方法 当测试用例完全设计完成之后，如果以程序的流程路径作为树枝，测试用例作 为叶，我们可以画出测试用例的图，这将是一个倒立的树型结构 9 。每个叶子将 是一个具体的测试用例，根据下面提到的黑盒测试用例设计方法，我们可以将这 些叶子分类，归成不同的等价类。下面介绍的几种方法，是考虑在不同的具体项 日要求下，结合测试需求和测试覆盖率分析技术，来得到最下面的叶子( 测试用 例) 的方法，力求提高更高的测试用例覆盖率，并比较他们的优缺点。 在一棵测试用例为叶的树形成之后，我们可以很简单的从中选取我们所需要的 测试用例进行测试，但是如何去形成这样一棵树，我们将根据不同的项目情况具 体考虑。 树有上卜结构，最底层的叶子就是我们具体的测试用例了。b u t t o nu p 设计方 法顾名思义就是从最底层的叶子出发，然后慢慢向e 衍生，最终到达程序的起始 点。b u t t o n u p 设计方法的特点是对系统的功能相当熟悉，能够直接考虑功能点的 最细致的地方，这样就可以很快的形成最具体的测试用例。 b u t t o n u p 设计的说明 下面举个简单伪码的例予： e g ( 1 ) i f ( 用户a 是! 正确用户，且密码破确) ( 2 ) a 正常登陆： ( 3 )i f ( a 有权限操作) ( 4 )a 操作： ( 5 ) e ls e 提示a 权限不够： ( 6 ) e l s o ( 第1 8 贞共6 2 页 浙江大学硕士学何论文 ( 7 )a 不能登陆： ( 8 ) i f ( 用户名不存在) ( 9 ) 提示用户名不存在： ( 1 0 )e l s e 提示密码不j 下确： 根据上面的例子，我们可以将程序流图画成如下图5 一l 所示 图5l 对于每条路径，我们都可以设计定的测试数据，确定一个或一个以上的测试 用例来满足这条路径的测试要求。如果将这些测试用例加到图5 - 1 上可得图5 2 ： 第1 9 页共6 2 页 浙江人学硕十学何沦文 幽5 2 理论上，测试用例a g 覆盖了所囱路径，并且测试j f 】例a ，b 是个等价类， 测试用例d 和e 也属于个等价类，这样，我们可以根据具体的需要，来选择合 适的测试用例集合来达到最有效的测试要求。 b u t t o n u p 设计方法从最底层的测试用例直接出发，根据设讨人员队系统的理 解，直接创建测试用例a g ，如图6 一l 所示： oo oo o 圈6 一t 所有的测试用例刚设计完成的时候，是混乱的，没有进行任何分类，这样不利 r 我们进行测试质量的衡量。因此，在完成所有的测试用例设计之后，要进干j ：评 审。评审要求将所有的测试用例分类，并且建立起与需求( 或工作流) 的联系。 在评审的过程中，会发现设计好的测试用例中有些是同一个等价类中的，要将他 们归到同一个等价类下，如图6 2 ： 图6 2 在归好等价类之后，我们就可以将这些不同的等价类与亡作流十同联系，即与图 5 - 1 结合后形成图5 2 中最终的测试用例树型结构a 总结优缺点 b u t t o n u p 设计方法有着明显的优缺点。它要求对系统有着丰富的理解，这样 能够在最短的时间内创建出尽可能完善的测试用例，并且，通过后期的评审，对 测试用例的覆盖率等方面进行补救。同样，它也存在很多不合理的氇方，比如它 依赖设汁人员对系统的理解，以及设计人员的个人经验，如果设计人员对系统理 解有误，要发现测试用例的问题，将会花费大量的时问。同时，由于开始建立 第2 0 页共6 2 缸 o 。、。 一q 、。 o 。、 一 ，。q、。一 浙江人学硕十学位沦文 起来的测试用例是混乱无序的，很有可能会有一一些无效的测试用例重复存在，这 也需要在评审过程中进行消除。在系统功能明了以及设计人员经验十富的情况下， 我们可以选用b u t t o n 一1 7 p 的设计方法，来尽快提交测试用例，满足项目的时问要 求。 3 2u p d o w n 设计方法 我们前面已经提到，对于所有的测试用例完成之后，将会形成个倒立的树型 结构，上面一节提高的b u t t o n u p 设计方法是从最底层的叶子出发，完成整个设 计；而这一节提出的u p d o w n 设计方法，则是从另外一个思路出发，先将系统主 要的功能测试点列出来，并将其与需求进行对应，在确认了功能测试点之后，再 对每个功能测试点进行进一步的深入解析，用等价类，边界值等方法来创建具体 的每个测试用例。 u pd o w n 设计方法能够在设计测试用例之初就考虑测试用例的覆盖程度，并且 能够将测试用例分成不同的优先级。这样，能够有效的保证测试用例的质量，减 ： 后期的改动。 u p d o w n 设 f 的说明 仍然考虑4 2 1 中举的例子。如果使用的是u p d o w n 设计方法，首先耍列出系 统的功能点和功能测试点。所谓功能测试点，是和相对于功能点( f u n c t i o np o i n t ) 而言的，来测试这个功能点的测试点。对于上述例子，我们先列出功能点： 1 ) 输入用户名； 2 ) 输入密码； 3 ) 进行操作； 然后，对于每个功能点，列出相对应的测试点： 1 )i f 确的用户名，不存在的用户名，等等； 2 ) 正确的密码，不正确的密码； 3 ) 正确的操作，错误的操作，无权限的操作，等等； 对于列出来的测试点，我们可以先进行一次评审，由于这些测试点是通过对功 能点的分析得出来的，即使是一些经验不是很丰富，对系统也不是很了解的没计 第2 1 页共6 2 页 浙江夫学硕士学位论文 人员，也可能设计出高覆盖率的测试用例。同时，如果系统的需求有了变化，即 相应的功能点进行了变化，我们也只需要对测试点进行改动，不会产 l - x , j 测试用 例的大量的改动。 在对测试点进行了评审后，系统基本的工作流程也可以定下来了。 一个树型框 架罔可以创建出来了： 图7 然后对于这些列出的测试点，运用等价类和边界值等方法，对每个测试点选择 不同的测试数据，进行扩展测试用例，便可得图5 2 的树形图，形成整个完整的 测试用例。 总结优缺点 u p - d o w n 设计方法利用功能测试点，在测试用例设计的起始阶段就将测试用例 所会覆盖到的方面展现出来，能够有利于起始时候对测试用例覆盖率的评估，尽 t t ，发现测试用例设计中的问题，更好地保证测试用例的质量。利崩功能测试点， 即使不是很有经验地设计人员，也能够进行测试用例地没计，因为就算在设计过 程中有些问题没有考虑到或者考虑不周全，在对功能测试点的评审中也能够及时 的发现问题，避免对测试用例的大量重复修改。第三点就是对于丌发团队或者是 用户来说，大量的测试用例评审也是不可能做到面面俱到的，这样，如果q a 团队 提供功能测试点，很清楚的指出对于哪些功能点，会设计什么样的测试用例来进 行测试，也能够更有效的帮助开发幽队和用户进行相应的工作。如果项目的需求 足不断的变更的，测试用例也会随着需求不断的改变，如果q a 团队能够预见到需 求的变更，那么也就并不需要去创建很多预见会修改( 丢弃) 的测试用例，而把 1 要精力放到对功能测试点的设计上，因为毕竟很多时候需求的改动并不会改变 第2 2 页共6 2 页 浙江大学硕 学位论文 功能，而仅仅是一些界面或者操作步骤的改变。 u p d o w n 设计方法可以应用在很多项目中，用来提高测试用例的质量，提高测 试的效率和质量。但是这种设计方法要比b u t t o n u p 的设讨方法多维护一份功能 洲试点的文档，如果维护不当，往往会使测试用例和功能测试点币一致，从而失 去了这个方法所具有的优势，反而带来更多混乱。 3 3s s u p 设计方法 s s u p ( s t a t es t r e e tu n i f i e dp r o c e s s ) 定义了一套自身的测试用例设计方法， 作为替s t a t es t r e e tb a n k 服务的i t 部门，我们必然有很多项目要遵循这种设计 方法。下面我就做一个介绍。 s s t l p 设计的说明 s s u p 要求将需求和测试用例建立联系，并定义t 5 个不同的层次。前3 个属于需 求层面，而后两个属于测试用例层面。 图8 ：s s u p 需求分级 需要( r e e d s ) ：市场上用户对系统的某种需要，存在与用户的思想中； 特色( f e a t u r e s ) ：用户希望系统提供的功能与特色，用户能够对这砦功能提 供、j k 务术语的描述； 第2 3 页共6 2 页 浙 t ：大学硕i 学位论文 用例( u s ec a s e ) ：以计算机从、i k 人员能够理解的语占对功能和特色进行描述； 情景( s c e n a r i o s ) ：从用例中提取出来的关于不同情况r 功能情景描述； 测试用例( t e s tc a s e ) ：根据不同的情景描述，选用不同的测试数据形成的 测试用例。 要建立一份符合s s u p 的测试用例，需要有份符合s s u p 的用例支持，q a 团队可 以根据这份用例，创建相应的情景和测试用例。 要说b 蝈s s u p 的测试用例设计方法，还需要建立些基本的术语，丰线，副线， 动作流图情景。 主线： i 最基本的。系列连续的动作组成，每一步都是正确执行的： 副线：在流程上有部分变化，包括了一些不经常出现的情况和错误情况： 动作流图：以虚拟过程的形式对用例进行描述的一种方式； 情景：由主线或者部分副线组成的一个动作流图称为个情景。 下面是由一个动作流图中抽取出来的6 个囊i 列的情景： 图9 ：动作流图情景 这6 个情景分别是： ( b ) ，( 1 3 ，a 1 ) ，d 3 ，a 2 ) ，( b ，a 3 ) ，( b ，a 3 ，a 4 ) ，( b ，a 1 ，a 2 ) 在定义了情景之后，将按照以下步骤得到具体的测试用例： 第2 4 页共6 2 页 文k卜n ，i。峄。，毒i。_，_ 3 _ l _ ri ”rl氛长 _ 妒上土土 - 妒iil l 土 站 r 一 ltl薹 浙i 1 大学硕l 学位论文 1 对于每一个动作，定义所需要的变量： 2 给每个变量赋1 i 司的等价值； ：j 将不同的等价值分类，选择必须进行测试的等价值； 4 将不同的等价值组合成为个测试用例； 5 根据不司的等价值，给每个变量赋不同的值。 例如情景( b ，a 1 ) ，在b 巾有v la v l j v 2 两个变量，v 1 是s t r in g 型，v 2 是n u m j j ， t r i a l 中则有v 3g u m 型和v 4c h a r 型，对于s t r i n g 型和c h a r 型，我们可赋给他们可接 收字符串和不可接收字符串两个等价值，对- 于n u m 型，我们可赋予正确的数值，错 误的数值以及非数值三个等价值，然后对这些等价值进行分类，有些变量的等价 值是不会在操作中出现的，我们可以将这些等价值去除，以减少复杂度。然后对 剩余的等价值进行a y j j 组合，每个组合即为一个测试用例，然后根据不同的等价 值，赋予每个变量相应的真实测试数据。 总结优缺点 s s u p 的设计方法其实也是u p - d o w n 设计方法的个变种，它更规范化了如何 获得功能测试点的过程，并建立一个很好的中间步骤一f 青景。在情景的指导f ， 不仅仅团队内的成员能够对测试用例进行有效的评审，真正的用户，业务部】、j 的 人员也能够对测试用例进行有效的评审，尽t 一提出修改意见。 作为u p d o w n 设计方法的变种，基本上它也具有u p d o w n 设计方法的所有优缺 点，当然，它也有自身一些特殊的改进方面。相比一般的u p 1 ) o w n 设计方法，s s u p 疗法能够提供更好的可跟踪性和更直观的覆盖率。同时，由于要进行s s u p 的设计， 对于用例的输入也是有很强的规范，于是，也能够在。定程度上促使q k 务分析人 员能够提供更加详细规范的需求文档，这个往往是项目开发中很难达到的个要 求。使用了s s u p 设计方法，能够产生大量的规范文档，也有利于公司的整体管理 和整个项目的后期维护。 当然，使用s s u p 设计方法也受到一些限制。如果没有规范的用例文档，就很 难使用这种方法，如果项目时问要求紧，町能就只能放弃对这些文档的要求。芬 执行过程中，会产生大量文档，虽说大量的文梢能够给后期的维护带来帮助，但 是现在的项目大都有很强的时间压力，往往没有条件去完成所有的文档，因此， 这种设计方法所能够实现的价值也有定的问题。 第2 5 页共6 2 页 浙江人学硕十学位论文 第四章测试结果分析 4 1 测试覆盖率分析 测试覆盖率 6 是说明一个测试对于所要求的功能点的覆盖率的一个技术指 标，它根据所要求的粒度的不司，可以分成下面这些不同的指标： 语句覆盖：语句覆盖就是设计若干个测试用例，运行被测程序，使得每一l | j 。执 行语句至少执行一次； 判断覆盖：判定覆就是设计若干个测试用例，运行被测程序，使得程序中每个 判断的取真分支和取假分支至少经历一次，又称为分支覆盖： 条件覆盖：条件覆盖就是设计若_ t 个测试用例，运行被测程序，使得程序中每 个判断的每个条件的可能取值至少执行一次： 判断一条件覆盖：判定一条件覆盖就是设计足够的测试用例，使得判断巾每个 条件的所有可能取值至少执行一次，每4 n 断中的每个条件的叫能取值至少执行 次； 路径覆盖：路径测试就足设计足够的测试用例，覆盖程序中所有可能的路径： 面向对象的覆盖：测试覆盖所有定义的对象说明； 函数覆