软件测试培训讲义-5软件测试技术概述.pptVIP

软件测试培训讲义-5软件测试技术概述.ppt

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
软件测试培训讲义-5软件测试技术概述

软件测试培训讲义 深圳市软件行业协会培训中心 课程目的 了解软件工程的基本概念和过程 了解软件质量定义和软件质量保证过程 深入掌握软件测试原理、方法、过程 通过实战掌握测试策略、技术 第二部分:软件测试的技术 第五章 软件测试技术概述 内容和目的 软件测试的基本方法 黑盒测试 白盒测试 静态测试 动态测试 测试策略 第二部分:软件测试的技术 第五章:软件测试技术概述 软件测试的基本方法 软件测试的基本方法 软件测试的方法和技术是多种多样的,对于软件测试技术,可以从不同的角度加以分类: 从是否需要执行被测软件的角度,可分为静态测试和动态测试。 从测试是否针对系统的内部结构和具体实现算法的角度来看,可分为白盒测试和黑盒测试; 静态测试 动态测试 动态测试 黑盒测试 黑盒测试 黑盒测试 黑盒测试方法主要有: 等价类划分 边值分析 因—果图 错误推测 主要用于软件确认测试 黑盒测试 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试 白盒测试 白盒测试 白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。 白盒测试 “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。 白盒测试 贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误 黑盒测试是从用户观点,按 规格说明书要求的输入数据与输 出数据的对应关系设计测试用例, 是根据程序外部特征进行测试。 白盒测试是根据程序内部逻辑结构进行测试。 不论黑盒还是白盒测试都不能 进行穷尽测试, 所以软件测试不可 能发现程序中存在的所有错误, 因 此需精心设计测试方案, 力争尽可 能少的次数,测出尽可能多的错误. 第二部分:软件测试的技术 第五章:软件测试技术概述 测试策略的制定方法 制定测试策略的目的 测试策略用于说明某项特定测试工作的一般方法和目标。 ?一个好的测试策略应该包括下列内容: 1.实施的测试类型和测试的目标 2.实施测试的阶段 3.技术 4.用于评估测试结果和测试是否完成的评测和标准 5.对测试策略所述的测试工作存在影响的特殊事项 确定测试策略的一般方法 1.确定测试的需求 2.评估风险并确定测试优先级 3.确定测试策略 确定测试的需求 测试需求所确定的是测试内容,即测试的具体对象。在分析测试需求时,可应用以下几条一般规则: 1.测试需求必须是可观测、可测评的行为。如果不能观测或测评测试需求,就无法对其进行评估,以确定需求是否已经满足。 2.在每个用例或系统的补充需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求;有些补充需求将派生一个或多个测试需求,而其他补充需求(如市场需求或包装需求)将不派生任何测试需求。 测试需求可能有许多来源,其中包括用例、用例模型、补充需求、设计需求、业务用例、与最终用户的访谈和软件构架文档等。应该对所有这些来源进行检查,以收集可用于确定测试需求的信息。 确定测试的需求 功能性测试需求 性能测试需求 可靠性测试需求 功能性测试需求 正如其名称所示,功能性测试需求来自于测试对象的功能性行为说明。每个用例至少会派生一个测试需求。对于每个用例事件流,测试需求的详细列表至少会包括一个测试需求。 性能测试需求 性能测试需求来自于测试对象的指定性能行为。性能通常被描述为对响应时间和/或资源使用率的某种评测。性能在各种条件下进行评测,这些条件包括: 1.不同的工作量和/或系统条件 2.不同的用例 3.不同的配置 性能测试需求 性能需求在补充需求中说明。检查这些材料,对包括以下内容的语句要特别注意: 1.时间语句,如响应时间或定时情况 2.指出在规定时间内必须出现的事件数或用例数的语句 3.将某一项性能的行为与另一项性能的行为进行比较的语句 4.将某一配置下的应用程序行为与另一配置下的应用程序行为进行比较的语句 5.一段时间内

文档评论(0)

sandaolingcrh + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档