分享
分享赚钱 收藏 举报 版权申诉 / 148

类型软件测试理论基本.ppt

  • 上传人:weiwoduzun
  • 文档编号:4195769
  • 上传时间:2018-12-15
  • 格式:PPT
  • 页数:148
  • 大小:1.41MB
  • 配套讲稿:

    如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。

    特殊限制:

    部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。

    关 键  词:
    软件测试理论基本.ppt
    资源描述:

    1、软件测试基本概念 软件测试的分类 软件测试的常识 软件的生命周期,?什么是软件,软件=程序+文档,软件的分类,按功能划分系统软件 应用软件 按技术架构划分单机版软件C/S结构软件B/S结构软件 按用户划分产品软件项目软件 按开发的规模划分小型、中型、大型,软件测试,定义:使用人工或自动手段,来运行或测试某一系统的过程。其目的在于检验它是否满足规格需求或弄清预期结果与结果之间的差别。 必要性:软件在生活中无处不见,由于软件问题造成的损失也就相当的惊人.美国的GDP的一部分就被软件问题吃掉了金融系统的一些安全问题导致客户资金损失 资料失窃发现号航天飞机空难 软件测试=文档测试+程序测试,测试环境,

    2、测试环境=软件+硬件+网络,怎样搭建测试环境,1.真实 2.干净 3.无毒 4.独立,要点:,分类:,1.软件开发环境 2.软件生产运行环境,测试用例,定义:英文为Test Case,缩写为TC,指在测试执行之前设计的一套详细的测试方案,包括测试环境、测试步骤、测试数据和预期结果。测试用例=输入+输出+测试环境 测试用例模板1.Excel2.Word,编写测试用例的注意事项,1.为什么要写用例 2.什么时候写用例 3.由谁来写测试用例 4.根据什么写测试用例,Bug,我们判断一个软件问题是否是Bug的唯一标准:软件中不符合用户需求的问题,类型:1. 完全没有实现的功能2.基本实现了用户的需求功

    3、能3.实现了用户不需要的功能,测试部门的组织结构,测试人员与开发人员的比例: 国内:1:91:15;国外:1:1以上 国内中小公司测试部门的实际情况 外包软件测试公司测试部门情况,从业人员素质,三心,二意,一能力: 细心,耐心,信心,服务意识,团队合作意识,沟通能力 好的软件测试工程师是十分难得的.(需要了解整个系统的需求,并找出系统的隐患和瓶颈.有些需要读代码 需要自己开发测试工具),测试工程师发展建议,拓宽知识面(把计算机硬件,网络,操作系统,数据库等知识学好) 学会使用各种测试技术 参看优秀的测试用例来提高用例设计水平 高手不是瞎写东西的,是凝结着智慧的,能看到是福气 参看bug系统来熟

    4、悉系统常见问题,测试方法,拓宽测试思路 发现新的测试动机: 1.发现bug的环境 2.bug的基本描述 3.开发人员的解决方法,什么是SQA,SQA的定义:为确保软件开发过程和结果符合预期要求而建立的一系列规程,以及依照规程和计划采取的一系列活动及其结果评价 CMM/CMMI的简单介绍1.capability maturity model 能力成熟度模型,由卡耐基梅隆大学与上世纪80年代,共5级2.一种标准质量模型,SQA根据这种模型定义的各种规则来检测项目的 SQA与测试的关系: 测试是发现问题,SQA是在预防问题仅仅测试是不能保证软件质量的,软件测试基本原则,Zero Bug& Good

    5、Enough对投入、产出进行一种权衡;但good enough的标准又很难确定 不要穷举测试 开发人员不能又是运动员有是裁判员 软件测试要尽早介入1.需求分析阶段引入的缺陷最多,而修复成本最低2.设计阶段也会引入很多缺陷,3.随着流程,越往后面的阶段,修复缺陷的成本越大 软件测试应该追溯需求1. 2. 缺陷的免疫性和修复缺陷导致新缺陷的特征 缺陷的2/8现象,生命周期概念,什么叫软件的生命周期?概念是:软件开发、测试全部过程、活动和任务的结构框架,是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程,最后被淘汰,生命结束。 1.软件开发的生命周期:需求分析概要设计详细设计编码维护

    6、 2.软件测试的生命周期:测试计划测试设计测试执行测试评估,软件生命周期模型,1.瀑布模型:最早的一种模型,特点:阶段清晰,强调早期计划和需求调查,适合需求稳定的产品开发。缺点:依赖早期需求调查,不适应需求变化;单向流程,不可逆;风险集中到后期,失去及早纠正机会,测试仅是编码后的一个阶段。 2.迭代模型:可看作是重复多次执行的瀑布模型,并在每一个开发阶段引入严格的风险控制,风险消除后才进入下一阶段的开发工作。 3.V model:,V模型:,软件测试的主要流程 软件测试流程 开始 测试项目确认 测试计划 测试执行 问题修正与跟踪 测试关闭 结束 测试执行的流程 开始 获取可测版本 获取安装及功

    7、能手册 搭建测试环境 测试数据,测试用例就绪 按测试用例输入 检查输出 记录测试用例执行结果 编制测试报告 测试报告通知相关部门评审 结束 测试计划的流程 开始 确定测试环境 确定测试策略 编制测试计划 测试计划评审与批准 编写测试用例 测试用例评审与批准 结束,软件测试整体流程图,2018/12/15,需求分类及模型定义 缺陷管理 测试核心活动,2018/12/15,软件需求:系统必须完成的事以及必须具备的品质 需求是以一种清晰,简洁,一致且无二义性的方式,对待开发的各个有意义方面的陈述的集合。 软件需求包括: 业务需求 用户需求 功能需求和非功能需求,24,Template Documen

    8、tation,2018/12/15,需求分类,业务需求:反映了组织机构或用户对系统、产品高层次的目标要求,他们在项目试图与范围文档中予以说明。 用户需求:描述了用户使用产品必须完成的任务,这在用例文档或方案脚本说明中给以说明。 功能需求和非功能需求:开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务的需求。非功能需求包括产品必须遵从的标准、规范和合约;外部界面的具体细节、性能要求;设计或实现的约束条件及质量属性。,25,Template Documentation,2018/12/15,约束条件,业务需求,项目视图与范围文档,业务需求和用户需求是软件需求分析的基础,也是软件构建

    9、的前提。 需求的三个层次和非功能需求的内容构成了完整的软件需求,规格化后成为“软件规格说明书”。,26,Template Documentation,2018/12/15,什么是好的需求,一致性 (无歧义) 可理解性 完备性 可行性(现实性) 必要性(需求是用户所需要的) 正确性(准确和完整) 可跟踪性要使每项需求都能回溯至某项客户的输入 可测试性 划分优先级给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。,27,Template Documentation,2018/12/15,需求工程,需求开发:需求捕获需求分析编写规格说明书需求验证 需求管理:定义需求基线处理

    10、需求变更需求跟踪 成果:“软件需求规格说明书”、“测试计划”、“用户手册”,28,Template Documentation,2018/12/15,需求开发,需求获取:一个确定和理解不同用户类的需求和限制的过程,主要活动有编写项目视图和范围,用户分类,选择产品/客户代表,分析工作流程,确定用例和需求重用等工作。 需求分析方法:绘制系统关联图,创建开发原型,可行性分析,绘制图形分析模型,数据字典,质量功能调配,划分需求优先级。 软件需求文档:软件需求规格说明书+需求分析报告。,29,Template Documentation,2018/12/15,需求开发,需求验证 审查需求文档组织一个由不

    11、同代表(分析人员、客户、设计人员、测试人员等)组成的小组,对系统需求规格说明书及相关模型进行仔细的检查。 依据需求编写测试用例 编写用户手册在需求开发早期即可起草一份用户手册,用它作为系统需求规格说明的参考并辅助需求分析。 确定合格的标准,30,Template Documentation,2018/12/15,需求规格说明书的说明,完整性不能遗漏任何必要的需求信息 一致性是指与其他需求或高层(系统、业务)需求不矛盾 可修改性在必要时或为维护每一需求变更历史记录时,应该修订SRS 可跟踪性应能在每项需求与它的根源和设计元素、源代码、测试用例之间建立起链接。,31,Template Docume

    12、ntation,2018/12/15,需求分析的工作任务,控制系统上下文范围关系图 创建用户接口原型 分析需求的可行性 确定需求的优先级 为需求建立模型 创建数据字典 使用质量功能调配,32,Template Documentation,2018/12/15,需求分析的方法和结果,典型的需求分析的方法有结构化分析方法(SA)和面向对象方法(OOA) SA:广泛的使用的过程驱动的需求分析方法。结构化分析是以过程为中心的、建立系统用户需求模型的方法。它将系统分解为过程、输入、输出和文件,它为业务问题建立了一种面向输入-处理过程-输出的模型。 OOA:运用面向对象的方法,对问题域和系统责任进行分析和

    13、理解,对其中的事物和他们之间的关系产生正确的认识,找出描述问题域及系统责任所需要的类及对象,定义这些类和对象的属性和服务,以及它们之间所形成的结构、静态联系、动态联系。OOA建立的主要模型包括:用例图、类图、顺序图、状态图等。 需求分析的结果是系统需求规格说明书。,33,Template Documentation,2018/12/15,需求管理,需求管理的过程是控制和维护需求的约定,管理产品和产品构件的需求,并识别需求与项目计划及工作产品的不一致,从而保证项目开发过程的一致性,使用户得到所需产品的过程。 需求管理的过程开始从获取需求贯穿于整个项目生命周期,一般包括需求变更控制,需求配置管理,

    14、需求跟踪,需求状态跟踪。 需求管理的几项基本任务:(1)获得对需求的理解(2)获得对需求的承诺(3)管理需求变更(4)维持需求的双向可跟踪性。,34,Template Documentation,2018/12/15,需求管理,需求管理的方法:(1)确定需求变更控制过程(2)进行需求变更影响分析(3)需求基准版本和需求控制版本文档(4) 维护需求变更的历史记录(5)跟踪每项的状态(6)衡量需求的稳定性。,35,Template Documentation,2018/12/15,需求管理,需求追踪矩阵的部分功能: (1)建立并维护产品需求与初始需求的对应关系; (2)建立并维护产品需求与系统测试

    15、用例的关系;(3) 建立并维护产品需求与设计的关系; (4)建立并维护设计与集成测试用例的关系; (5)建立并维护设计与编码的关系; (6)建立并维护编码与单元测试用例的关系。使用需求跟踪矩阵的优点是很容易发现需求与后续工作产品之间的不一致性,有助于卡发人员即使纠正偏差,避免返工。,36,Template Documentation,2018/12/15,需求管理,需求追踪矩阵的填写: (1)罗列所有详细功能点,而与流程无关; (2)也可列入有关功能限制; (3)陈述应避免用冗长的描述性语言,这样不容易将功能点划开; (4)每个功能点用一句简短的话来描述,如果一个功能点需要两句话才 能描述清楚

    16、,则将其划为两个功能点。 (5)在需求追踪矩阵中,所有内容必须忠实与整理出来的需求文档。如果需求文档的内容不足以得到完整细致的范围矩阵,则需要回头来完善需求文档;如果实在确定不下来内容,则可以在范围矩阵中标出来,待以后确定。 需求变更规则制定。,37,Template Documentation,2018/12/15,模型的定义,瀑布模型(waterfall model) 螺旋模型(spiral model) V模型(V model),38,Template Documentation,2018/12/15,瀑布模型,瀑布模型是20世纪70年代提出的较早的一种生命周期模型。 特点: 强调阶段的

    17、划分及顺序性; 强调各阶段工作及其文档的完备性; 是一种严格线性的、按阶段顺序的、逐步细化的开发模式。,39,Template Documentation,2018/12/15,瀑布模型,瀑布模型步骤:计划需求设计编码测试维护 瀑布模型的优点: 开发的各阶段比较清晰 强调早期计划及需求调查 适合需求稳定的产品开发,40,Template Documentation,2018/12/15,瀑布模型,瀑布模型的缺点: 依赖于早期的需求调查,不适应需求的变化 单一流程,不可逆 风险往往迟至后期才显露,失去及早纠正的机会 测试仅仅是编码后的一个阶段,41,Template Documentation,

    18、2018/12/15,螺旋模型,螺旋模型是在瀑布模型的基础上提出来的,之所以叫做螺旋模型,是因为这是一个迭代开发的过程,每一个迭代过程均由需求、设计、编码、测试、集成等几个阶段组成。 特点:比较适合需求经常变化的软件项目,42,Template Documentation,2018/12/15,V模型,43,Template Documentation,2018/12/15,V模型,优点:详细表示了测试的各个阶段以及参考依据单元测试参考的是详细设计集成测试参考的是概要设计系统测试参考的是需求规格说明书验收测试参考的是实际用户需求,44,Template Documentation,2018/1

    19、2/15,V模型,V模型的缺点:没有说明在项目的前期测试需要做哪些工作(编写测试计划、测试用例等),而且和瀑布模型一样,流程也是单向的,不可逆。每一种模型都有其优缺点,没有普遍使用的模型,我们需要根据项目的实际情况,并结合每一种模型的优点,来制定我们项目的软件开发和测试模型。,2018/12/15,第5章 缺陷管理,软件测试技术,46,Template Documentation,2018/12/15,第5章 缺陷管理,Bug的分类 缺陷报告 提交缺陷报告的注意事项 Bug的处理流程,47,Template Documentation,2018/12/15,Bug,Bug的定义软件中的Bug是

    20、指软件中(包括程序和文档)不符合用户需求的问题 判断Bug的唯一标准:是否符合用户的需求,48,Template Documentation,2018/12/15,Bug的分类,按严重程度(Severity)由高到低划分5个等级:系统崩溃严重一般次要建议,49,Template Documentation,2018/12/15,Bug的分类,按优先级由高到低:高(high): 立即修复的Bug中(middle):在产品发布前修复的Bug低(low): 如果时间允许应该修复的或者可以暂 时存在的Bug,50,Template Documentation,2018/12/15,Bug的分类,按照测

    21、试种类划分:逻辑功能类(function)性能类(performance)界面类(UI)易用性类(usability)兼容性类(compatibility),51,Template Documentation,2018/12/15,Bug的分类,按Bug生命周期划分新建(new)确认(confirmed)解决(fixed)关闭(closed)重新打开(reopen),52,Template Documentation,2018/12/15,缺陷报告,缺陷报告的模板:Word、Excel或者是缺陷管理工具自带的模板 缺陷报告的基本形式:参考课本P79-P80 缺陷报告的读者: 开发人員: 关注B

    22、ug的详细描述 项目管理者: 关注Bug的概述和严重程度,关注整个系统中各种严重级别的Bug的分布比例,53,Template Documentation,2018/12/15,提交缺陷报告的注意事项,确保重现Bug对于严重程度较高的Bug,一般要重复测试两次以上;对于随机产生的Bug,要在其他机器上测试一下,看看是否是自己机器的原因。 要用最少且必要的步骤描述Bug原因:为了减少开发人员定位问题的时间,54,Template Documentation,2018/12/15,提交缺陷报告的注意事项,简洁、准确、完整 缺陷概述(Summary):简洁、准确、完整,揭示错误实质,最好用陈述句,一

    23、般不超过15个字。 详细描述(Description):简洁、准确、完整,保证快速准确的重复错误,“简洁”即没有多余的步骤;“准确”即步骤正确;“完整”即没有缺漏。 尽量使用业界管用的表达术语和表达方法。 检查拼音和语法错误。,55,Template Documentation,2018/12/15,提交缺陷报告的注意事项,一个Bug一个报告原因:便于分配Bug便于回归测试(尽量一个缺陷报告只包含一个Bug),56,Template Documentation,2018/12/15,Bug处理步骤,测试人员发现并提交一个Bug,状态为新建; 将Bug分配给相应的开发人员,开发人员接受,状态变为

    24、已分配; 开发者修改Bug,完成后状态变为已解决,将新版本提交给测试人员; 测试人员对新版本进行回归测试,若Bug确已修改,将其设为已关闭。若未通过回归测试,则发给开发人员继续修改。,57,Template Documentation,2018/12/15,Bug处理流程,58,Template Documentation,2018/12/15,缺陷管理工具,Bugzilla:Mozilla公司向我们提供的一个开源的免费缺陷跟踪工具 。它包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。 TestDirector:MI公司开发的测试管理工具,具有进行测试计划管理

    25、、测试用例管理、缺陷管理、测试总结管理等功能。 TestManager:IBM Rational公司开发的测试管理工具,具有同TestDirector类似的功能。,59,Template Documentation,2018/12/15,Bugzilla的使用,登录模块创建帐户,创建组。 创建新的Bug建立新的产品(项目), 为产品添加模块等。 Bug的提交分配给谁、版本、优先级、初始状态等。 查看和修改Bug高级查询和普通查询,可以将Bug的状态修改为关闭等。,60,Template Documentation,2018/12/15,Bugzilla的使用,Bug的统计报告大部分的缺陷管理工

    26、具都具备功能强大的图标统计功能,Bugzilla也可以采用三维坐标,在多个表中分别加以显示。 (具体参考P88-P96),61,Template Documentation,2018/12/15,要点,软件生命周期 软件测试计划 软件测试用例设计和实施 软件测试评估 测试团队建设,62,Template Documentation,2018/12/15,软件开发的生命周期,软件开发的一般生命周期 需求分析概要设计详细设计编码维护 IBM软件开发生命周期,63,Template Documentation,2018/12/15,软件测试的生命周期,Planning 计划阶段这是产品测试概念定义的

    27、阶段 Analysis 分析阶段根据得到的信息,去创建测试的框架和文档 Design设计阶段测试内部文档,测试用例的基本描述。测试用例并不能够在本阶段完成。由于新功能的添加,具体功能的实现方法,修改等因素,测试用例只能不断的更新。 Construction 书写阶段编码的同时,最终完成系统预先设置的各种测试用例的阶段 Testing Cycles 测试阶段利用测试用例进行测试 Final Testing完成阶段最后的验证测试 Implementation 执行阶段书写一些最终的报告,64,Template Documentation,2018/12/15,65,Template Documen

    28、tation,2018/12/15,软件测试计划,在测试中最关键的活动就是测试计划 一个计划包括:1)需要做什么2)怎么去做3)需要花费多长时间4)需要的资源(人力、测试环境和工具)5)成本6)如果不能完成计划会造成的影响7)测试的优先级8)每一部分的测试由谁来负责9)计划中每一部分相互之间联系的风险10)关键的检查点数据11)测试的入口和退出的标准,66,Template Documentation,2018/12/15,12)对测试过程的主要执行者和贡献者 13)如果项目能提前完成将有的潜在利益 测试计划要尽早开始。可以在需求定义过程开始时就开始测试计划。 测试计划的活动包括:从测试输入中

    29、收集信息形成一个测试策略和一个风险管理策略定义测试范围决定资源需求制定进度表定义测试入口和退出标准,67,Template Documentation,2018/12/15,测试计划的目的是处理以下重要的问题: .测试策略.资源利用.风险.优先级 测试计划的类型 主测试计划 子计划,68,Template Documentation,2018/12/15,主测试计划,整个测试过程的指导性文档 系统验证测试计划 功能验证测试计划 单元测试计划 集成测试计划 可用性测试 在大约需求说明和项目计划形成时就可以开始主测试计划,69,Template Documentation,2018/12/15,风

    30、险评估,一个测试计划成功的关键的一点就是去识别和评估项目风险。 风险就是那些会出错从而影响项目造价和进程的概率。在测试中,风险既包括那些项目的失败的可能性也包括由失败造成的影响。它具有不确定性和代价巨大的特征。 风险评估就是估计项目障碍发生的可能性和潜在影响。在一个风险分析活动中,对于一个项目管理者来说,就是通过输入或是输出提高风险鉴别能力。,70,Template Documentation,2018/12/15,风险有很多种形式,以下是两种主要的分类:应用软件程序不能满足最终用户的期望(说明的或是未说明的);应用软件程序不能按时(可以是合同约定的时间也可以是市场上投资后得不到预期回报)交给

    31、客户。 不能管理的风险能导致很多问题,包括:增加测试成本测试周期延长服务停止矫正维护费用过多,71,Template Documentation,2018/12/15,测试策略,当需求和项目的风险被充分理解后, 测试计划的下一步是确定测试策略。 测试策略回答了一下问题: 我们为什么测试? 我们计划做什么以及不做什么? 我们将如何做测试?,72,Template Documentation,2018/12/15,软件测试评估,软件测试评估,也就是测试总结,是软件测试生命周期的最后一个环节。 测试评估主要分为两种:对覆盖(过程)的评估和对缺陷(结果)的评测。 两种覆盖:对源代码的覆盖和对需求的覆盖

    32、。,73,Template Documentation,2018/12/15,对源代码的覆盖: 指的是在单元测试过程中所测试到的源代码占代码总数的百分比,一般有语句覆盖、分支覆盖、条件覆盖、路径覆盖等。 一个通用的标准是:关键模块的语句覆盖率为100%,分支达到85%以上。 对需求的覆盖 指的是在测试过程中,所测试到的功能和非功能需求占到需求总数的百分比。 一个通用标准是: TESTcase的执行率为100% Testcase的通过率为95%以上,74,Template Documentation,2018/12/15,测试总结报告的一般内容有: 测试项目概述 测试机构和人员 测试用例统计结果

    33、 缺陷分类统计结果 测试结论,黑盒测试技术,1等价类技术(Equivalence Class Testing),等价类划分法是一种黑盒测试技术,它不考虑程序内部结果,只是根据需求说明来对输入的范围进行细分,然后再从分出的每一个区域内选取一个有代表性的测试数据。 等价类的定义:1.有效等价类:符合需求规格说明书,合理地输入数据集合。2.无效等价类:不符合需求规格说明书,无意义地输入数据集合。3. 等价类:是指某个输入域的子集合。在该集合中,各个输入数据对于揭露程序中的 错误都是等效的。,等价类划分的步骤:1.先考虑输入数据的数据类型(合法类型和非法类型)。2.再考虑数据范围(合法类型中的合法区间

    34、和非法区间)。3.画出示意图,区分等价类。 4.为每一个等价类编号。5.从一个等价类中选举一个测试数据构造测试用例。,常用的等价类划分方法:1.如果规定了输入值的范围,可以分为一个有效等价类,两个无效的等价类,如1x100,则有效等价类为“1x100”,无效等价类则为输入范围两边的值。2.如果输入是布尔表达式,可以分为一个有效等价类和一个无效等价类,如要求密码非空,如3.如果规定了输入数据的一组值,而且程序对不同输入值做不同的处理,则每个允许的输入值是一个有效的等价类,此外还有一个无效的等价类(任意一个不允许的输入值)。4.如果规定了输入数据必须遵循的规则,可以划分出一个有效的等价类(符合规则

    35、)和若干个无效的等价类(从不同的角度违反规则)。,2边界值技术,“错误隐含在角落”(error hide in the corner),大量的测试实践经验表明,边界值是最容易出现问题的地方,也是我们测试的重点。且在白盒测试中也应用到了边界值的测试思想。,3因果图法(Cause-Effect Graphs),因果图法也是一种黑盒测试技术,不如等价类、边界值那样常用,其比较适合输入条件比较多的情况,测试所有的输入条件的排列组合。 因果图的步骤:(1)找出所有输入条件和输出条件,并编号。(2)分析输入条件之间的关系,是互斥还是可以同时 满足。(3)画出输入条件的排列组合情况。(4)编写测试用例。,因

    36、果图的应用场合:当软件的输入条件比较多的时候,我们可以考虑用因果图来设计测试用例,考虑输入的所有排列组合情况,防止遗漏。 因果图的局限性:假如有N个条件,每个条件有真或假两种取值,那么理论上就有2的N次方种排列组合,这就大大增加了测试用例的数目,不便于维护。我们可以根据实际情况尽量精简输入条件的个数。,4流程图法(Workflow Method),流程图是针对整个系统业务功能流程的。 流程图法的步骤:(1)详细了解需求。(2)根据需求说明或界面原型,找出业务流程的各个页面以及个页面之间的流转关系。(3)画出业务流图(路径图)。(4)写用例,覆盖所有的路径分支。,流程图法一般不是针对具体某个页面

    37、或是某个模块的测试,而是将被测系统看作一个完整的系统,从宏观上来分析其业务流程,然后画出流程图来。其好处在于:能够使测试人员对被系统有一个总体的把握,防止测试的时候有遗漏的页面或者模块。,5黑盒测试技术的综合运用,综合利用前面所学到的黑盒测试技术去测试,比如:首先应用等价类的思想来划分输入范围(重点测试边界值),如果涉及多个输入条件的组合情况,我们再应用因果图法考虑所有情况的排列组合。 例如:课本P72页案例9.,白盒测试技术简介,测试工具的分类,黑盒测试工具以及定义黑盒测试工具是指测试软件功能或性能的工具,主要用于系统测试和验收测试,其又可分为功能测试工具和性能测试工具。( QTP, Loa

    38、dRunner,QARun等) 白盒测试工具以及定义测试软件的源代码的工具,可以实现代码的静态分析,动态测试,评审等功能,主要用于单元测试。(JUnit , C+ Test, JTest 等 ) 测试管理工具以及定义管理整个测试流程的工具,主要功能有测试计划的管理,测试用例的管理,缺陷跟踪,测试报告管理等,一般贯穿于整个软件测试的生命周期。(Bugzilla,QC),白盒测试技术概述,白盒测试与黑盒测试比较黑盒测试不考虑程序内部的逻辑结构,只需检验软件的外部功能是够符合用户的实 际需求。分为功能呢个测试和性能测试。百盒测试需要深入到软件的内部,去查看源代码,去分析程序的内部结构,如数据类型,算

    39、法,异常处理等。单元测试:百合测试;集成测试:黑盒和百合测试相结合;系统测试和验收测试:黑盒测试。 白盒测试的分类 静态测试技术(代码走查,代码审查,技术评审。其中代码审查和技术评审有正式的计划详细的流程和结果报告.静态分析工具:Logiscope,C+ Test) 动态测试技术与静态测试相对应,是白盒测试的重点,也是发现缺陷的主要手段。方法有边界值,罗技驱动覆盖,路径图法等。,边界值测试,边界值测试:最基础最常用的方法。软件的缺陷往往出现在输入范围的边界上,而不是输入 范围的内部。数据类型的边界值(整型的范围,单精度数的范围等) 数组的边界值 分支判断语句的边界值(if(a=o)中的a=0)

    40、,逻辑驱动覆盖技术,程序的主要结构顺序结构:较简单,秩序构造适合的测试用例,使程序的每条语句都执行一 遍即可;分支结构、循环结构:路径和循环次数较多,测试比较复杂。,分支结构测试,语句覆盖测试 分支覆盖测试 条件覆盖测试 分支条件覆盖测试 条件组合覆盖测试 路径覆盖测试,以下面的函数为例进行讲解#include Void main() float A,B,X;scanf(“%f%f%f”, ,图中存在4条不同路径: L1:SACBED; L2:SABD; L3:SABED; L4:SACBD.,语句覆盖测试,定义:设计若干测试用例,使得程序中的每条语句至少执行一次。程序的路径应是SACBED.

    41、我们可以设计这样一条测试用例(A=2,B=0,X=2),这条用例同时满足(A1)两条语句都被执行。 优点:可以直观地从源代码得到测试用例,无需细分每条判定表达式。 缺点:对于隐藏的条件和可能到达的饮食逻辑分支,是无法测试的。,分支覆盖测试,定义:设计若干个测试用例,使得程序中每个分支的取真分支和去甲分支至少执行一次。能够分别覆盖路径SACBED和SABD或SACBD和SABED的两组测试数据,都满足判定覆盖标准。覆盖SACBED和SABD的测试用例:(1)A=2,B=0,X=2(SACBED) (2) A=1,B=1,X=1(SABD)(3)A=3,B=0,X=3(SACBD) (4)A=2,

    42、B=1,X=1(SABED)优点:比语句覆盖多几乎一倍的测试路径,具有更强的测试能力,也具有和语句覆盖一样的简单性,无需细分每个判定就可以得到测试用例。缺点:仅判断各判定语句的最总结果,而忽略每个条件的取之情况,必然会遗漏测试路径。,条件表达式,定义:选取足够多的测试数据,使被测试程序中不仅每条语句至少执行一侧,而且每个判定表达式中的每个条件都取到各种可能的结果。 程序的条件判断语句:(A1)&(B=0)和(A=2)|(X1);共四个条件,其中每个条件有真和假两种可能,因此共有如下8个条件状态:在A点:A1,A1,X=1我们只需要构造足够到的测试用例,使得这8个条件状态都被测到即可。设计测试用

    43、例如下:(1)A=2,B=1,X=4(SABED) (2)A=-1,B=0,X=1(SABD),条件覆盖测试,优点:条件覆盖比分支覆盖增加了对符合判定情况的测试,增加了测试路径。 缺点:没能保证分支覆盖,比如上面的两个测试用例就没有覆盖到第一个判定条件(A1)&(B=0)的取真分支,分支条件覆盖测试,定义:选取足够多的测试数据,使得程序中每个分支的取真分支和去假分支各执行一侧,而且每个判定表达式中的每个条件都读到各种可能的结果。分支测试和条件测试的结合。 可以设计用例如: (1)A=2,B=0,X=4(SACBED) (2)A=1,B=1,X=1(SABD) 这两条用例既覆盖了程序的两个取真分

    44、支和取假分支(SACBED和SABD),有覆盖了每个判定表达式中条件的取真和取假两种情况,即:A1,A1,X=1 优点:满足判定覆盖准则和条件覆盖准则,弥补了两者的不足。 缺点:未考虑条件的组合情况。,条件组合覆盖测试,定义:选取足够多的测试数据,使得判定表达式中条件的各种可能组合都至少出现一次。 这个程序有四个条件: (A1)&(B=0)和(A=2)|(X1)。它们两两一组构成条件组合如下(1)(A1,B=0) (2)(A1,B!=0) (3)(A1) (6)(A=2,X1) (8)(A!=2,B=1)以上8中可能的条件组合,根据这些条件组合可以设计测试用例如下:(1)A=2,B=0,X=4

    45、(SACBED,1,5) (2)A=2,B=1,X=1(SABED,2,6)(3)A=21,B=0,X=2(SABED,3,7)(4)A=1,B=1,X=1(SABD,4,8),条件组合覆盖语句,优点:满足分支覆盖,条件覆盖和分支条件覆盖准则。更改的分支条件覆盖要求设计足够到的测试用例,使得判定中每个条件的所有可能结果至少出现一次,每个判定本身的所有可能结果也至少出现一次,并且每个条件都显示能单独影响判定结果。 缺点:线性地增加了测试用例的数量。,路径覆盖测试,定义:选取足够多的测试数据,使得程序的每条可能路径都至少执行一次。通过上面的分析已经知道,该程序有四条不同的路径:L1:SACBED;

    46、 L2:SABD; L3:SABED; L4:SACBD. 我们的任务就是设计足够到得测试用例使得程序的这四条路径都被执行到。设计用例如下:(1)A=2,B=0,X=2(SACBED)(2)A=1,B=1,X=1(SABD)(3)A=3,B=0,X=3(SACBD)(4)A=2,B=1,X=1(SABED),路径覆盖测试,优点:路径覆盖式经常要用到的测试方法,它比普通的分支覆盖和条件覆盖的覆盖率都要高。 缺点:路径覆盖不一定能保证条件组合覆盖,如上米娜的测试用例中的A=0,B=0这个条件组合就没有被测试到。,逻辑驱动覆盖技术,上面的6中测试方法中,没有十全十美的测试覆盖方法,每一种方法都有其优

    47、点和缺点。 在实际项目中,程序内部的逻辑存在着不确定性和无穷性,尤其对于大规模复杂软件。因此这里不能穷举所有的逻辑路径,需要读者根据实际情况去选择合适的覆盖测试方法。 其中语句覆盖,分子覆盖和路径覆盖时用的最多的。往往对测试人员设计的测试用例有如下要求:语句覆盖率:100%分支覆盖率:85%路径覆盖率:80%,循环语句测试,简单循环 串接循环 嵌套循环 不规则循环,面向对象测试,Java简单介绍 面向对象测试概述 面向对象程序的单元测试,单元测试的评估和总结,编写目的 被测单元描述 测试环境 测试过程 测试结果 质量评估,面向对象测试,面向对象是一种软件开发的思想,在整个软件生命周期都要遵循这

    48、种思想,根据软件生命周期的各个阶段,可以讲面向对象测试分为以下几种:面向对象分析的测试(OOA Test)面向对象设计的测试(OOD Test)面向对象编码的测试(OOP Test) 面向对象程序的单元测试,单元测试的评估与总结,测试总结不一定只在项目的后期进行,测试的每一阶段,如单元测试,集成测试结束后都可以进行总结,总结的目的不仅仅是应付领导的检查,更多的是评估项目的质量,看是否可以进入下一阶段,以及总结测试过程中的经验和教训。通常单元测试和集成测试的总结一起进行,统称为单元测试报告。一般单元测试报告主要包括以下内容1、编写目的2、被测单元描述3、测试环境4、测试过程5、测试结果6、质量评

    49、估,107,Why plan,做测试计划的目的并不是创建一长系列的测试用例,而是处理一要要的问题:. 测试策略.资源利用.责任.风险.优先级,IRUP (IBM统一开发过程)测试计划模板中需要包含的条目 目标 范围 评估失误 目标测试条目 对已计划测试的概览 测试方法 进入和退出的标准 环境需求 责任感 团队和训练需求 计划风险 可信度 假定 约束,做测试计划的好处1让测试者早点进入开发过程会产生更好的测试计划。在测试计划上的早开 始有助于将重点放在防止错误同时移除错误。这样的规划前期费用将在长远的后期节省时间。2 回报在测试计划所花的时间能回收多次更高效更有效的测试。测试计划为所有的测试活动、包括跟踪、设置所有测试确定的活动范围和商定奠定了基础。,

    展开阅读全文
    提示  道客多多所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
    关于本文
    本文标题:软件测试理论基本.ppt
    链接地址:https://www.docduoduo.com/p-4195769.html
    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

    道客多多用户QQ群:832276834  微博官方号:道客多多官方   知乎号:道客多多

    Copyright© 2025 道客多多 docduoduo.com 网站版权所有世界地图

    经营许可证编号:粤ICP备2021046453号    营业执照商标

    1.png 2.png 3.png 4.png 5.png 6.png 7.png 8.png 9.png 10.png



    收起
    展开