福利彩票销售系统的测试设计与测试结果分析

福利彩票销售系统的测试设计与测试结果分析 广东工业大学 硕士学位 论文 政研论文下载论文大学下载论文大学下载关于长拳的论文浙大论文封面下载 福利彩票销售系统的测试设计与测试结果分析 姓名:金慧峰 申请学位级别:硕士 专业:软件工程 指导教师:张益新 20070413 摘要 软件测试是软件工程的一个重要阶段，也是保证软件质量的重要手段。随着 人们对软件质量要求的提高，软件测试技术也被重视起来。笔者所在企业面 临一 个较大型的软件项目，希望将更全面的软件测试技术应用起来，以保证软件 质量。 本文就是笔者对软件测试技术作出全面研究并综合运用的结果。 笔者系统地学习和研究了软件测试理论体系知识域，把软件测试理论归纳为 测试设计部分和测试管理部分。测试设计部分可以看作是软件测试的技术和 测试 策略的组合;测试组织管理领域则包括了测试管理和测试组织活动等。在具 体的 项目测试管理过程中，笔者制定出适合企业开发特点的软件测试管理体系。比之 前的测试模式更早地进入项目，在软件需求分析等前期阶段，测试组就进入分析 测试需求，制定整体的测试 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 。综合运用几种测试模型的优点来指导软件测试 过程;考虑企业实际开发过程，重新设计了企业的软件测试管理方法，在不同的 测试阶段选择最适合的测试技术，不同的软件模块采用不同的测试优先级;综合 运用多种黑盒测试法来设计测试用例;白盒测试阶段以开发组测试为主，针对关 键模块进行代码级测试。 按照笔者制定的测试管理体系进行完成测试工作后，一改往常开发耽误测 试，测试耽误项目进度的情况，顺利完成全部的测试工作而不耽误进度。目前该 项目顺利通过更高要求的第三方独立测试，且没有发现更深层次的缺陷。一定程 度上证明了新的测试管理方法和测试技术运用的正确性和可行性。 在软件测试过程中，由于BUG修改而引发更新的缺陷，一直是测试管理难以 控制的地方;需要研究更好的测试管理技术来解决类似的测试管理问题。 关键词:软件测试，测试管理，测试模型，测试阶段，黑盒测试法，白盒测 试法 Abstract Softwaretestingsanimportantstageinsoftwareengineering，and animportantmeansofassuringsoftwarequality(Thesoftwareenterprise thatI’minfacedalarge?scaleenterprisesoftwareprojects。wantamore comprehensiveapplicationofsoftwaretestingtotakeSoftwarequality assurance(Theauthorofthisp印eristomakeacomprehensivestudyof thesoftwaretestingtechnologyandtheintegratedusoftheresults( Theauthorsystematicallystudythetheoryofsoftwaretesting knowledge，tosumthesoftwaretestingassoftwaretestinddesigna d softwaretestingmanagement(Inthetestprojectmanagementprocess，the authorsformulatesuitableforthecharacteristicsofthedevelopmentof enterprisesoftwaretestingmanagementsystem(?reearlyenterinthe softwarep oject(Assoftwaredevelopmentgroupdesigningthetesting groupisbegingtomaketestplan(Severaladv ntagesoftheintegrated useofthetestmodelguidedthesoftwaretestingprocess(Useda combinationofmethodstodesignedblack?boxtestingcase( Accordingtotheauthor’Stestmanagementsystemafterthecompletion ofthetests，ithaschangedtheusualdelaysinthedevelopmentoft st( Thehigherthesmoothpassageofthecurrentproject，thethird?party independenttesting，butitisnotfounddeeperflaws(Tosomeextent provedthathenewtestmanagementandtesthecorrectnessand feasibilityoftheuseoftechnology( Inthesoftwaretestingprocess，asamendedBugupdatecausedthe defectshabeendifficulttotestmanagementco rol:needtolookat bettertestingmanagementtosolvemanagementproblemssimilartest( keywords:SoftwareTesting，Testingmanagement，TestingModel，Testing stage，Black?BoxTesting，White?BoxTesting ? 独创性卢明 独创性声明 秉承学校严谨的学风与优良的科学道德，本人声明所呈交的论文是我个人在 导师的指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别 加以 标注和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果， 不包 含本人或其他用途使用过的成果。与我一同工作的同志对本研究所作的任何 贡献 均己在论文中做了明确的说明，并表示了谢意。 本学位论文成果是本人在广东工业大学读书期间在导师的指导下取得的，论 文成果归广东工业大学所有。 申请学位论文与资料若有不实之处，本人承担一切相关责任，特此声明。 指导教师签字: 论文作者签字: 丐弛谚 仑萼旌 2007年辋fz日 第一章绪论 第一章绪论 1(1 课题来源及研究的意义 我国的软件测试技术研究起步于“六五”期间，无论是测试理论还是测试行 业都和国际先进水平差距比较大。国内软件项目过程不规范，导致重视编码和轻 视测试，对于软件测试的重要性、测试流程和方法等还有很多错误认识。随着我 国软件产业的发展以及对软件质量的重视，软件测试也越来越被重视。软件企业 不断发展和进步，对软件质量的重视程度越来越高，无论从管理上，理论上还是 技术上都更加重视软件测试工作。传统的测试理论和对软件测试的实施方法上还 存在局限，不利于软件测试的实施和保障软件质量。 笔者所在企业从事福利彩票销售系统开发，产品属于行业定制软件，缺乏相 关的测试 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 和测试要求，有着独特的行业特点和质量要求。企业在软件开发过 程中放松对软件文档的要求，忽视软件开发阶段的规划，测试工作草草应付等， 越来越不利于企业发展壮大。如何去控制这种特殊类型的产品质量，缺乏系统有 效的管理办法。 福利彩票销售系统是笔者所在企业为我国省级福利彩票发行中心定制的，集 福利彩票销售、兑奖、多种投注方式一体的计算机管理软件。该管理软件不同于 一般的“企业管理软件”，一是由于政策调整灵活，用户不对需求做系统的调查 分析;二是企业对于系统未来的功能设想不明，缺乏行业参考标准，急于满足用 户要求而上马一个项目。当用户需求有调整时，整个软件的体系架构往往需要调 整。因此带来的后果是频繁的定制某个小的功能管理系统，频繁修改用户需求成 为习惯。如何把先进的软件(预4试模型、具体的测试方法、测试管理运用到该管理 软件的生产过程中，有效指导项目需求分析，减少重复开发，是一个比较大的课 题。 另一方面，由于该管理系统软件，对于系统的可靠性要求高;终端销售系统 用户数量众多，一个省级的终端数量可能就达到数千个，对终端系统操作界面的 易用性要求高;如何保证如此众多数量的终端系统的可靠性和易用性，既是企业 需要面对的课题，也是保证软件质量不可或缺的部分。 1 广东T业大学T程硕‘学位论文 作为企业的软件i烫4试人员，基于不同的立场，有两种不同的测试目的。从用 户的角度来看，希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可 以接受该产品。从软件生产企业的角度考虑，则希望通过测试成为表达产品不存 在错误的过程，验证该软件已正确的实现了用户的需求，确立用户的信心。因此 笔者的论文研究有着非常现实的意义，首先要满足实际生产的需要，灵活运用现 有的测试理论，并希望能在研究过程中提出适合企业应用的改进。 1(2 论文的内容及特色 本论文通过对现有测试理论学习，明确测试需求分析的重要性，分析主流的 溅试模型的特点，讨论测试阶段和软件开发阶段的关系，总结常见的软件测试技 术。在一个完整的项目测试流程中，将两种测试模型的特点，并充分考虑软件开 发的特点，综合运用成功指导整个软件测试过程。在测试设计部分，笔者合理选 择测试技术，有效避免大量的路径测试;利用歼发语言的特点，选择低成本的白 盒测试工具，测试人员开发简单实用的自动测试工具;测试管理设计部分，考虑 软件开发的特点，根据企业的管理要求重新制定了测试交接流程，设计适合企业 应用特点的文档模版，BUG管理流程等，使得测试工作顺利达到预期目标。 在确定测试优先级时，笔者考虑业务流程的特点，选择用户使用频率最高的 部分，即投注机销售系统为最高级别，其余的模块优先级依次为中心管理系统， 后台业务予模块，以及随机数分布分析。 选择测试模型时，采取w和H测试模型的优点而综合运用，既避免了由于 畏4试阶段的划分而干扰开发过程，在不同的开发阶段对应的测试阶段结束时，要 求产生对应的文档或者阶段性的确认书，保证了W模型的优势得到应用;又能 保证测试就绪点成熟时测试人员及时进入测试。 测试环境的选择，由于软件开发环境和实际运行的环境对硬件要求太高，测 试环境重新准备一套测试环境的意义不大，笔者选择了在数台高性能的PC上运 行虚拟机的办法，从功能上满足福利彩票系统需要多台离性能服务器的要求;在 进行性能测试时候才征用开发环境的高性能服务器，有效解决了功能测试和开发 相干扰的困境。 黑盒测试技术应用方面，笔者综合运用多种测试技术，如在注码输入区的测 2 第一章绪论 试用例设计时，首先运用错误推测法分析软件可能出错的区域，进一步采用等价 类划分的办法避免了大量的输入数据测试;在设定了有效的等价类输入区域后， 吸取了正交试验法的特点，选用了一组最接近的正交数列来设定输入数据，最后 将该区域的输入数量从352000条压缩至30条用例。 白盒测试技术应用方面，采用开源的测试工具，针对几个关键模块进行结构 测试，其余部分的模块以开发人员测试主。 测试工具的开发，从后台核心子模块的运行环境考虑，测试人员分析性能测 试的特点，编写简单的测试工具，可以按照要求设定登陆不同的服务器ip，端口 号，不同的登陆站点数量，登陆方式，自动汇总的测试结果记录并以文本的形式 记录下来，实现大规模并发用户的售票、登陆业务功能，通过设置不同数量级的 测试终端数，不同级别的测试数据，可以达到测试后台核心子模块的性能;通过 长时间的连续测试实现系统的疲劳度测试。 随机数部分的测试方法，由于需要一份随机数生成的情况分析。所以单独安 排测试人员完成该部分的分析，从系统需要的随机数的数量考虑，分别从1天， l周，1月，l季度以及1年的数据来统计分析，通过以上五组不同数量级的数 +据统计和分析，可以证明该随机数的分布均匀和稳定; 模版的设计，为了强化测试交接过程和测试阶段，笔者重新设计了此次项目 的文档交接模版，特别是对于用例和错误报告交接部分，考虑本软件的开发特点， 比如用例模版会严格要求用例标识符的意义，因此在用例模版上并没有具体的版 本或软件名称这样的细节项;而是增加了功能项或功能点这样的描述性测试特 性，并且在用例设计的时候，要求在测试条件或环境项中描述用例之间的依赖关 系，以及用例产生的测试程序限制等条件，有效地缩减了模版的格式，方便了测 试过程。同时还另外设计了用例执行表格，严格要求测试执行人和验证人签字， 并且可以跟踪到某条测试用例执行过程中发现的bug，一定程度上保证了用例执 行的可靠性。 Bug管理流程及交接流程，针对企业的软件项目交接过程不清晰，开发人员 在软件版本暴露错误后随意修改等问题。此次笔者和软件开发部门共同讨论，重 新设计了Bug管理和交接流程，减少了bug的严重等级，要求bug在提交之后， 必须由测试经理确认，由开发人员填写汇总表的原因分析以及处理 意见 文理分科指导河道管理范围浙江建筑工程概算定额教材专家评审意见党员教师互相批评意见 ，一方面 广东T业大学1程硕J‘学位论文 保证了程序版本不能随意修改，重大问题的修改必须讨论影响域，并经过评审组 织的评审;另一方面保证测试人员可以获得最新的bug状态，合理分配进一步的 工作任务。 其他。用例预演的办法，通过笔者向客户的技术人员，开发人员，软件测试 设计人员等项目等组成的评审组简明扼要地讲解用例设计原则，关键模块的 用例 设计等，达到了用例评审的效果。 1(3论文的组织结构 为了清晰地描述论文的研究及应用成果，将论文分成三个部分: 第一部分，为理论研究部分，系统研究了软件测试技术的策略、模型、方法 等。 第二部分，测试技术综合运用，分为测试设计，测试管理。 第三部分，测试结果分析部分，分析测试过程中发现的错误及缺陷的处理情 况;以及对于系统需要用到的随机数的测试过程分析。 1(4 本章小结 本章是论文的绪论部分，主要介绍了论文的相关领域情况和论文的基本情 况，并简单介绍了论文的内容与特点。 4 第二章软件测试技术概述 第二章软件测试技术概述 1972年在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试 的会议。在1975年，JohnGoodEnough和SusanGerhnrt在IEEE上发表了“测 试数据选择的原理”的文章，软件测试才被确定为一种研究方向。 GlenfordJ(Myers认为测试应该首先认定软件是有错误的，他于1979年提 出 了软件测试的定义:“测试是为发现错误而执行的一个程序或者系统的过 程。” Myers还给出了与测试相关的三个重要观点，那就是: 测试是为了证明程序有错，而不是证明程序无错误; 一个好的测试用例是在于它能发现至今未发现的错误; 一个成功的测试是发现了至今未发现的错误的测试。 2002年，Rick和Stefan在《系统的软件测试》SystematicSoftwarTeging 一书中对软件测试做了进一步定义:“测试是为了度量和提高被测软件的质 量， 对测试软件进行工程设计、实施和维护的整个生命周期过程”。随着软件技 术的 进步，软件测试技术研究提出了的V模型，w模型，在单元测试、自动化测 试 以及测试管理方面涌现了大量的软件测试工具。 2004年6月，美国IEEE协会和ACM的联合网站上公布了软件工程知识体 SWEBOK2004版全文，软件测试技术作为软件工程的一部分，可供参考。下 图是来自软件测试的知识域分解图: 技术 图2-1软件测试知识域的主题分解 Fi和m2-1BreakdownoftopicsfortheSoftwareTestingKA 5 广东T业大学丁程硕E学位论文 从上图的软件测试五个子域的主题可以做这样的归纳: 1(测试设计，包括前四个子域，系统地描述软件测试的内容，包括测试模 型选 定、实旌的测试类型和测试的目标、实施测试的阶段和技术、评估测试结果和测 试是否完成的评测和标准; 2(测试管理，由第五个子域引申出来，从技术管理角度探讨如何确保软件测试 技术在软件生命周期内得到高效实施，并产生预期的效果。测试组织建设，结合 考虑人和资源的因素。 因此我们可以这样定义一个软件测试体系或测试 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 :由测试管理指导下的 测试组织执行涣5试设计的系统过程。 2(1软件测试的对象和目的 确定溉试对象 根据软件的定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程 序测试。软件测试应贯穿整个软件的生命周期。软件测试不再被认为是仅仅在编 码阶段完成后才开始的活动;而是一种应该包括整个开发和维护过程的活动，它 本身是实际产品构造的重要部分。 确定测试需求和目的 确定测试需求也就是确定测试内容，或者说确定测试的具体对象。可以帮助 我们确定测试需求包括软件需求、用侈!『、架构设计文档以及详细设计文 档等。 “功能性测试需求”。是对于系统中描述的功能性行为有哪些地方需要测试。 这部分内容我们在项目早期就可以通过对软件需求规约和用例的分析来获得。一 个明确要求的功能性特性可以生成一条测试需求。用例中基本流或基本流同某些 备选流的组合也可以生成一条测试需求。我们还要关注用例间的相互关联和依赖 性，这些多个用例间的不同联系也可以分别生成一条测试需求。对于“性能测试 需求”，通常都是包含在“补充需求”中的“非功能性需求”中的，大多是对于 某项业务执行时响应时闻，或者资源占用率方面的要求。 就产品而言，不仅需要考虑质量属性，如功能测试需求和性能测试需求;非 功能需求还应包括系统与外部世界的外部界面，以及对设计与实现的约束。 明确测试目的 6 第一二章软件测试技术概述 软件测试的目的，是以最少的人力、物力和时间找出软件中潜在的各种错误 和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于前在的软 件缺陷和错误造成的隐患和风险。 同时，软件测试又是一个程序或者系统属性为目的的活动，对软件质量的度 量和评估，以验证软件的质量满足用户的需求程度，为用户选择软件提供依据。 2(2 软件测试模型 在软件开发的几十年实践过程中，人们总结了许多开发模型，但是都没有充 分强调测试的作用，无法有效地把软件测试结合起来。软件测试专家通过实践总 结出很多很好的测试模型，下面对主要的测试模型作简单介绍。 2(2(1 V模型和_模型 V模型是最具代表意义的测试模型。v模型的软件测试策略既包括底层测试 又包括了高层测试，底层测试为了源代码的正确性，高层测试是为了使整个系统 满足用户的需求。其左边每个开发活动都与右边的测试活动相对应，描绘了软件 开发过程中，需求、总体设计、详细设计和编码逐步实现，针对这些阶段的测试。 V模型的局限在于: 圈2-2软件测试v模型 Fig(re2-2VTestingModel 7 广东T业人学T程硕卜学位论文 1(V模型是等到编码结束才开始进行单元测试，不利于发现设计阶段错误; 2(测试过程和开发过程相对独立，可能导致开发团队和测试团队工作量相 对集中，不利于人力资源的安排;同时这样不利于测试计划、测试用例、错 误统计和最终分析报告等文档的管理。 V模型的局限性之一就是没有及早地进入测试;根据软件的需求和设计阶段 的澳试活动应遵循IEEEs'td1012(1998《软件验证和确认v&v》的原则，人 们提出了W模型。 图,,-3软件测试w模型 Figure2-,3WTestingModel 在弥补V模型不足前提下，w模型使得软件测试伴随着整个软件开发周期， 同时扩大了软件测试的范围，需求、功能和设计都被纳入测试的范畴。当然，如 果测试文档能够尽早提交，那么测试的准备工作就得以同步。同时参与测试的团 队就能尽早地找出缺陷所在，从而帮组改进项目内部的质量。但是W模型也有 局限:甚至和V模型一样，如果文档不到位:那么这里所提出的w模型就变得 和V模型没什么却掰了。因为这两者都把软件开发过程视为: 需求、设计、编 码等一个线性的流程。 S 第-二章软件测试技术概述 2(2(2 H模型和X模型 由于实际的软件开发过程，很少能有这样的流程能够完整地按照需求、设计、 编码等阶段清晰地进行。一旦这个次序被打乱，那么之前所设计的W模型都受 到干扰。H模型将软件测试活动完全独立出来。 图2-4软件测试H模型 l?igure2-4HT鳓ingModel 据2'4图，H模型根本就是一个生产周期中某个层次上的布局循环。图中的 其他流程可以是软件设计流程，也可以是开发流程。H模型是针对测试条件而言， 向上的箭头表示在某个时间点，由于“其他流程”的进展而由于先后关系引 发或者由于因果关系触发了测试就绪点，测试执行活动就可以开始。 概括而言，H模型模糊了测试进程和开发进程的对立，从测试层次强调被测 物的就绪情况。但H模型无法引导项目的全过程，Marick提出了X模型的基本 思想。RobinEGoldsmith进一步做出了该模型的完整描述。下图是x模型图示: 图2-5软件测试X模型 Fibre2-5XTestingModel 9 广东工业人学T程捌j十学位论文 x模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试， 此后将进行频繁的交接，通过集成最终合成为可执行的程序。右上半部分，这 些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用 户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以 在各个部分发生。 由上图中可见，x模型还定位了探索性澳试右下方。这是不进行事先计 划的特殊类型的测试，诸如“我这么测一下结果会怎么样?”，这一方式往往能 帮助有经验的钡5试人员在测试计划之外发现更多的软件错误。 2(2(3 测试模型选择 首先要说的是，前面几种测试模型都不是完美的，但对于指导测试工作具有 重要的意义。我们应该尽可能地应用模型对项目有实用价值的方面。下面的论述 不足以构成一个改进的测试模型，但是可以为项目应用提供进一步的参考。 在这些模型中，V模型强调了在整个软件项目开发中需要经历的若干个测试 级另Jj，但忽略了测试对象不仅仅指程序，而应包括软件的需求、设计进行测试， 也可以指确认和验证。这一点在w模型中得到体现，但w模型同样也没有对于 软件测试的流程加以说明，仅是沿着软件开发的阶段进行工作。实际上。现 在的 软件测试工作越来越趋向于有一个独立的组织来完成，这就需要一个独立的操作 流程，接着的H模型中体现了该点需求，使得测试表现的十分独立。只要测试 条件满足，就可以进行测试执行。而X模型又结合了实际项目中??经常有变 更发生，例如需要重新访问前一阶段的内容，或增加新功能。 一个模型的主要目标应该是描述如何把某件事情做好。当一个模型所规定的 基本要求还不完整的时候，模型可以帮助我们认识到这些不足，这也是其价值所 在。虽然我们承认，在没有足够多的需求的前提下，系统开发还可以继续下去， X模型可能会提倡付出额外的努力来进行更多的实践行为。例如，开发者有时并 不真正去研究如何更好地定义用户的业务需求，而是简单地认为这样的工作是不 现实的，因为“用户并不真正知道他们要什么”，或者认为“需求始终是要变化 的”。于是，这些开发人员可能进,步宣称不了解需求的做法是合理可行的，因 为他们可以使用一些更高级的做法，例如原型法。虽然这样的技术对确认需求， lO 第-二章软件测试技术概述 达成理解上的一致是有用的，但实际上这不是一条直接通向编码的捷径。这种情 况下，编码是非常低效的、要耗费很多工作量来发现真正的用户业务需求。 实际工作中。一个比较折中的办法就是:在w模型的框架之下，结合H模 型的思想独立进行测试。同时结合实际开发进度，寻找恰当的就绪点并反复迭代。 细化到工作内容来说，模型应该要求测试计划人制定明确的规定，对已交接的交 接内容，新的交接，以及交接内容的变更进行负责。 2(3 测试类型和测试阶段 2(3(1 测试类型 如果说测试模型的选择还不足以体现测试设计的要点，那么测试类型和测试 目标的确定就可以明显地体现出这是对测试过程建立控制。软件测试可以针对不 同的特性，设计不同的测试用例来检查是否正确实现了功能规格说明，这在文献 中被称为遵从性测试、正确性测试、功能性测试。但是如果考虑到我们在确定测 试需求时候的探讨，不仅仅需要考虑功能性需求还要考虑其他非功能性需求，这 样我们的测试目标就需要包括:性能、可靠性、可使用性等。 其他的测试目标还应包括:可靠性度量、可用性评价和接收，测试目标随 着测试对象变化而变化。 2(3(2 测试阶段 我们讨论测试阶段的划分，这是针对软件开发过程而言的，因为软件开发过 程是一个自顶向下，逐步细化的过程。而测试过程则正好相反，安排自底向 上， 逐步集成的过程。低一级测试为上一级测试准备条件，当然也不排除两者平 行的 进行测试，否则前文讨论的H羽5试模型就没有意义。如下图所示: 广东丁业大学T程硕七学位论文 设计 总体结构 不 断 细 中层结构 化 中层结构 图2-6软件设计过程和测试过程 Figure2-6SoftwareDesignProcessandTestingProcess 按照上图由整体到局部的过程，我们按照阶段分析最清楚地测试模型v模 型来阐述。这些阶段是从测试小的构件单元测试到测试整个系统系统测试 不断向前发展的; l，单元测试。单元涣4试在早期实施，侧重于核实软件的最小可测试元素。单元 测试通常应用予实施模型中的构件，核实是否己覆盖控制流和数据流，以及 构件是否可以按照预期工作。 2(集成测试。执行集成测试是为了确保当把实施模型中的构件集成起来执行用 例时，这些构件能够正常运行。测试对象是实施模型中的一个包或一组包。 要集成的包通常来自于不同的开发组织。 3(系统测试。当将软件作为整体运行或实施明确定义的软件行为子集时，即可 进行系统测试。这种情况下的目标是系统的整个实施模型。 4(验收,确认测试。验收测试是部署软件之前的最后一个测试操作。验收测试的 目的是确保软件准备就绪，可以供用户用于执行软件的既定功能和任务。 下图反映了他们和开发阶段的对应关系: 图2(7测试和开发过程的关系 Figure2-7RelationshipbetweenTestandSoftwareDevelopment 按照上图的对应关系，首先开始单元测试，集中对源代码实现的每一个程序 12 第二章软件测试技术概述 单元进行测试，检查各个程序是否正确实现了规定的功能。然后把已通过测 试的 模块组装起来，进行集成测试，对设计相关的软件体系结构的构造进行测试，主 要进行正确性和程序结构等方面进行检查。确认测试泽主要检查已实现的软件是 否满足需求规格说明中确定的各种需求，以及软件配置是否完整。最后是系统测 试阶段，应该说系统测试充分考虑了系统环境，包括测试环境、测试数据、测试 习惯等多方面的因素。 下图可以简单描述个测试阶段的进展: 2(4测试技术 图24软件测试过程 Figure24SofteareTestingprocess 测试技术是为了更好地揭示潜在的失效和错误，试图通过运行一个或多个被 认为是等价类的测试，来“中断”程序，其主要原理是尽可能系统化的标识程序 行为的代表性集合，例如，考虑输入域、场景、状态和数据流等子类。 测试技术的分类可以从这样的角度:静态方法与动态方法，黑盒法和白盒法 等。这些分类的不同仅仅是从不同的出发点考虑。 如果依照swebok2004版，对于测试技术的分类会有更多个方向。 2(4(， 基于测试工程师的直觉和经验 严格来说，这样的方法似乎不成为,个独立的技巧和方法。难以书面表达成 广东1业大学丁程硕t学位论文 有效的规则，但是这往往是实际上比较常用到的技巧之一，因为任何的可描述的 测试用例集或者测试角度都无法取代直觉和经验。简单来说，就是列举出程序中 所有可能的错误和容易发生错误的特殊情况，根据他们选择测试用例。比如，输 入数据和输出数据都为0的情况，或者表格为空格、只有一行，这些都是容易发 生错误的情况。可以选择这些情况下的用例进行测试。 特别要注意的是，可以提倡一种“探索性测试”技术，它的定义是这样的， 边学习、边设计测试和边执行测试，即在没有在制定测试计划中实现定义测试， 而是动态的设计、执行和修改测试。探索性测试的效果依赖于工程师的知识，这 些知识来源大概有:溺试中观察到的产品行为、对应用、对平台和失效过程的了 艇、可能的错误和失效类型、与特定产品相关的风险等等。 2(4(2 基于规格说明法 基于规格说明法郎指常说的黑盒’预0试技术。黑盒测试是指在完全不考虑程序 内部结构和内部特性的情况下，测试者只知道输入和输出之问的关系，他必须依 靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例，和推断测 试结果的正确性。 2(4(2(1 等价类划分法 等价类划分的办法是把程序的输入域划分成若干个部分，然后从每个部分中 选取少数代表性的数据作为测试用例。每一类代表性的数据在铡试中的作用等价 于这一类中的其他值。如果某类的一个用例中发现了缺陷，这一等价类中的其他 例子也能发现同样的错误;反之，如果这一类的用例没有发现错误，则认为这一 类的用例也不会找到错误。等价类划分两种情况: 有效等价类，对于程序的规格说明来说是合理的、有意义的输入数据构成的 集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。 无效等价类，与有效等价类定义相反。 最后强调一点，两个不同的用例设计人员设计出来的等价类可能会有不同的 区间。只要审查等价区间的人认为他们足以覆盖测试对象即可。 14 第二章软件测试技术概述 2(4(2，2 边界值分析法 从黑盒测试的原理考虑，所有的被测程序都可以看作是一个“函数”，根据 函数的定义我们主要考虑函数的值域和定义域;这里定义域对应于黑盒测试的输 入条件，而值域对应于黑盒测试的输出条件。边界值测试的原理是错误更可能出 现在输入变量的极值附近。边界值分析的基本思想是使用最小值、略高于最小值、 正常值、略低于最大值和最大值出输入变量值。根据已有的约定分别将这些值记 为mln,mm+’,',Om'm舣(，懈。 下面我们根据两个输入变量而，X2会有一些边界; 口?而S6 f?五?d 则区间k川和【c明分别对应而，X2的输入域，那么这两个变量的边界值分 析测试用例是: 五。。互柚'五。。鼍。时'五?五一，五?鼍。。， 五?鼍。，五IIIi?五一’墨。i斛五一，五?五一， 墨。戤(置一’五。。^。。 下图用星点表示取值，直观标示出边界值分析出的用例。 囡 囡 图2-9边界值分析法 Figure2-9Borderanalysis 沿着这,思路，我们可以继续扩展边界值分析法，除了五个边界值分析取值 15 广东T业大学T程硕卜学位论文 外，还要加上一个路大于最大值+，以及一个略小于最小值1nj曲一，测 试超过极值时系统的表现。 2(4(2(3 因果图法 之前所提到的测试技术着重考虑输入条件，并没有考虑到输入情况的各种组 合，以及输入之间的不足。因果图法也需要仔细分析程序规格说明书，从中 找出 因输入条件和果输出或程序状态的改变。利用因果图生成测试用例的基 本步骤: 1(分析软件规格说明描述中那些是原因，那些是结果，并给每个原因和结 果赋予一个标识符; 2(分析软件规格说明描述的语义。找出原因和结果之间、原因和原因之间 的关系，根据这些关系，画出因果图; 3(在因果图上用一些记号表明约束或限制条件; 4(把因果图转换为判定表; 5(把判定表的每一列拿出来作为依据，设计测试用例。 但是，有时很难从软件需求规格说明中得到我们需要的因果关系。又或者往 往因果关系非常庞大，以至于据此因果图而得到的测试用例数目多的惊人， 给软 件测试带来沉重的负担。因此所有的前提都是软件需求规格说明书的完备、 准确 和清晰的基础上。 2(4(2(4 场景法 提出这种测试思想的是Rational公司，并在RUP2000中文版当中有其详尽 的解释和应用。 用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有 基本流和备选流。下面采用一个常见的例子简单说明如何运用场景法。 16 第二章软件测试技术概述 秀撼纛爨 2 簟豢焉僚 图2(13一个场景法的例子 Figure2?13anExampleofScenarioDesigned 图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流， 是经过用例的最简单的路径。备选流用不同的彩色表示，一个备选流可能从 基本 流开始，在某个特定条件下执行，然后重新加入基本流中如备选流l和3; 也可能起源于另一个备选流如备选流2，或者终止用例而不再重新加入到某 个流如备选流2和4。 按照上图中每个经过用例的路径，可以确定以下不同的用例场景: 场景1:基本流 场景2:基本流备选流1 场景3;基本流各选流l备选流2 场景4:基本流备选流3 场景5;基本流备选流3备选流l 场景6:基本流备选流3备选流1备选流2 场景7:基本流备选流4 场景8:基本流备选流3备选流4 注:为方便起见，场景5、6和8只考虑了备选流3循环执行一次的情况。 17 广东T业丈学T程硕叶二学位论文 2(4(3 基于代码结构法 基于程序的代码结构法也就是白盒测试法。基于代码结构的测试方法可以分 为静态的结构分析法，动态的结构分析法。 在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、 数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模 块控 制流图、内部文件调用关系图、子程序表等各类图形图表，可以清晰地标识 整个 软件系统的组成结构，然后通过分析这些图表，检查软件有没有存在缺陷或 错误。 自盒测试的动态结构分析法根据程序的控制结构设计测试用例，其原则是: 1(保证每个模块中的所有独立路径至少被使用一次; 2(对所有逻辑值均需测试true和false; 3(对上下边界及可操作范围内运行所有循环; 4(检查内部数据结构以确保其有效性。 这里主要讨论两类方法:一类是逻辑覆盖法，包括语句覆盖方法、分支覆盖 方法、条件覆盖方法、条件判定组合覆盖法、多条件覆盖法;另一类是基本 路径 测试法。 自盒测试的开销相比黑盒测试要大的多，一般情况下，我们不会对每个模块 都进行自盒测试，只是选择重要的个别模块进行。 2(4(3(1 逻辑覆盖法 逻辑覆盖是通过对程序逻辑结构的遍历实现程序盼覆盖。它是一系列测试过 程的总称。从覆盖源程序的详尽程度分析，逻辑覆盖标准包括以下不同的覆 盖标 准:语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖。 下面采用一个简单的子流程图来说明这几种覆盖方法。 18 第二章软件铡试技术概述 h d 亡 圈2-14一个子流程图 Figure2?14aDiagramofSonProcess 语句覆盖StatementCoverage 为了使上述程序中每条语句都能至少执行一次，构造如下的用例即可实现上 述子流程的语句: A2，B0，X4 判定覆盖DecisionCoverage 设计的测试用例使得程序中的每个判定至少都获得,次“真值”或“假值”， 或者使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此 判定 覆盖又称为分支覆盖。按要求构造如下的用例可以实现上述子流程的判定覆 盖: A2，Bo’X4 彳1，B1，X1 条件覆盖ConditionCoverage 构造一组用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。 在设计程序中，一个判定语句由多个条件组合两成的复合判定。 例中有两个判定表达式，每个表达式有两个条件，为了做到条件覆盖，应该 选取测试数据使得在a点有下述结果出现: A1，ASl，口O，B?0 19 广东1业丈学T程石负L学位论文 在b点有下述各种结果出现: 彳2，彳?2，XI,XSl 所以需要组合考虑，按照要求构造如下的用例可以实现上述子流程的条件覆 盖: 彳2，Bo’z4 彳1，Bl，X1 条件判定组合覆盖ConditionDecisionCoverage 设计足够的测试用例，使得判定中每个条件的所有可能至少出现一次，并且 每个判定本身的判定结果也至少出现一次。 根据上面的程序，我们分析所有所有可能的条件取值组合 彳1(B0 A1(13?0 A?LB;0 A?1(B?0 A2，X1 彳2(X?1 A?2(J1 彳?2(X?t 下面的四组测试数据可使上面列出的八种条件组合每种至少出现一次: 422，丑20，z4针对1，5两种组合，覆盖sacbed 一2,B1，Z1针对2，6两种组合，覆盖sated Al，BO，X2针对3，7两种组合，覆盖sabed Al，B1，石l针对4，8两种组合，覆盖sabd 2(4(3(2 基于路径测试法 在实际问题中，一个不太复杂的程序，其路径的组合都是一个庞大的数字。 该方法通过分析控制流程图的环路复杂性，导出程序基本路径集合中的独立 路径 条数，这是确保程序中每个可执行语句至少执行,次所必须的测试用例数目 的上 界，然后据此设计测试用例。 第二章软件测试技术概述 控制流图示描述程序控制流的一种方法，其中基本的控制结构对应的图形符 号如下图所示。在下图中，圆圈表示控制流图的一个结点，表示一个或多个 无分 支的语句或源程序语句。 回田国回回 图2(1s控制流程图 Figure2-15DiagramofProcessConh'oling 采用逻辑覆盖部分的例子来说明，共有四条可能的执行路径，1(2(3;l?267; 145(3;1-4?567。因此，为了做到路径覆盖必须设计四组测试数据。 S 丑 b d C e 图2(16一个例子的路径图 Flgure2-16?ExampleofProcedurePath 2l ?b占固 广东1业大学t程硕七学位论文 2(4，4 基于使用领域 图形用户界面部分的测试主观性比较强。界面测试可分整体的界面测试和界 面中的元素测试。界面中的元素主要包括窗口、菜单、图标、文字和鼠标等。 整体界面测试是指对界面的规范性、一致性等进行评测。 1(规范性测试，如Microsoft标准等，可以参考。对于特殊行业，需要考 虑系 统使用环境和用户的习惯; 2(合理性，主要是观察界面的颜色和布局是否协调; 3(一致性，既包括标准的控件，也指相同信息的表现方法，如在字体、标 签风 格、颜色、显示错误信息等方面确保一致。 界面元素测试一般针对Windows平台的应用软件。 1(窗口测试，可以从窗口空间的大小，窗口是否正确地被关闭，当新窗口 被覆 盖并重新调用是否正确再生，以及按钮与界面的布局等: 2(菜单测试，主要考虑菜单是否符合需求，顺序是否准确，图形的布局等; 3(图标测试，主要考虑不同的目标是否采用不同的图标，这一点的主观性比较 强: 4(鼠标测试，主要考虑鼠标的移动、进出窗口、按下、释放鼠标是否准确等; 5(文字测试，主要钡5试软件中的拼写是否准确易懂。 2(5 评估测试 评估测试的