ISTQB基础知识软件测试设计技术 ppt课件
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据和状态的变化，以及其他的测试结果。
软件测试开发过程（续）
测试执行阶段
在测试实现阶段，测试用例的开发、实现、确定优先级和组织都应该 包含在测试规程规格说明中。
测试规程（或者手工测试脚本）描述了测试用例执行的顺序。 如果使用测试执行工具(test execution tool)进行测试，这种测试的
软件功能性测试概述
任何程序都可以看作是将从输入定义域映射到输出值域的函数，将 系统看作是黑盒。
黑盒的内容(实现)是不知道的，而用输入和输出表示的黑盒函数。
软件功能性测试依据
软件的规约（规格说明） 功能性测试用例的优点
功能性测试与软件如何实现无关，所以如果程序的具体实现发生变化， 测试用例仍然有用；
Edward Miller在为结构性测试辩护时写道：“如果达到85％或更好的水平，判 断覆盖率[一种结构性测试覆盖率指标]发现的缺陷，一般是‘直觉’[功能性]测 试找出的缺陷的两倍”(Miller，1991)。
两种方法单独使用都是不充分的
功能性测试只利用规格说明设计测试用例，而结构性测试使用程序源代码(实现) 作为测试用例设计的基础。
边界值
临界值 刚好超出临界值 刚好小于临界值
因果图与判定表
复杂条件构成因果图 根据因果图形成判定表
用例（Use Case）测试
用例描述了参与者（包括用户与系统）之间的相互作用，并从这些交互产生一 个从系统用户或客户的角度所期望和能观察到的结果。
根据业务流程，确定测试场景
状态转换测试
如果所有已描述行为（规格说明书）都没有被实现，则结构性测试永远也不会 认识到这一点。
如果程序实现了没有被描述的行为，功能性测试用例永远也不会揭示这一点。
因此，需要结合两种方法，两种方法的组合提高功能性测试的有效性，以及结 构性测试的度量。
由于功能性测试常常会有冗余和漏洞两方面的问题。如果功能性测试结合结构 性测试覆盖率指标执行，则这两个问题都会被发现并解决。
动作顺序将在测试脚本中描述（自动化的测试规程）。 试执行进度计划(test execution schedule) 。
不同的测试规程和自动化测试脚本要体现在测试执行进度计划 (test execution schedule)中，该计划定义了不同测试规程和可 能的自动化测试脚本的执行顺序、执行的时间esign Specification (测试设计规格说明/测试规 约)
根据测试需求编写的指导测试设计的文档，包括测试 设计策略、设计方法、设计范围的文档
义和使用。 测试覆盖指标明确描述了测试用例对所测程序的覆盖情况，便于测试
管理和度量。
缺点
测试用例集合完全局限于已实现的程序行为集合中。 由于结构性方法依靠的是程序，不能设计出程序没有实现的功能的测
试用例。
软件功能性测试与结构性测试的比较
哪种测试方法更好？
对于结构性测试，Robert Poston写道：“这种工具自20世纪70年代以来一直在 浪费测试人员的时间……[它]不支持好的软件测试实践，应该从测试人员的工具 包中剔除”(Poston，1991)。
测试用例设计(Test Case)是重要的测试设计内容，决定测试的覆盖度 和测试效率
三类软件测试技术的特点
基于规格说明的测试技术特点
使用正式或非正式的模型来描述需要解决的问题、软件或其组件等。 根据这些模型，可以系统地导出测试用例。
基于结构的测试技术特点
根据软件的结构信息设计测试用例，比如软件代码和软件设计规格说 明文档。
测试执行进度计划同时考虑了其他的因素，比如回归测试、测试 优先级以及技术和逻辑的依赖等。
软件测试技术
测试技术分类
黑盒测试技术（基于规格说明的测试技术 ） 白盒测试技术（基于结构的测试技术） 基于经验的测试技术
测试设计的内容
测试规约设计（测试规格说明） 测试用例规格说明设计 测试用例设计 测试管理文档模板设计 辅助测试工具设计
可以通过已有的测试用例测量软件的测试覆盖率，并通过系统化的导 出设计用例来提高覆盖率。
基于经验的测试技术特点
测试用例根据参与人员的经验和知识来编写。 测试人员、开发人员、用户和其他的利益相关者对软件、软件使用和
环境等方面所掌握的知识作为信息来源之一。 对可能存在的缺陷及其分布情况的了解作为另一个信息来源。
测试条件是能通过一个或多个测试用例进行验证的一个条目或事件 （比如功能、事务处理、质量特征或结构元素等）。
建立从测试条件到需求的可追溯性，有助于需求变更时的影响分析 (impact analysis)和测试用例集的需求覆盖率分析。
测试设计阶段
在测试设计阶段，要定义和记录测试用例和测试数据。 完成测试设计规格说明（包含测试条件）和测试用例规格说明 预期的测试结果应该作为测试用例规格说明的一部分，同时包含输出、
ISTQB基础知识
软件测试设计技术
目录
软件测试的基本过程 什么是测试用例？ 测试用例的作用 测试用例的组成 测试用例的表现形式 什么是良好的测试用例 测试用例的认识误区
软件测试开发过程
测试分析阶段
在测试分析(test analysis)阶段，要对测试基础文档进行分析，从而 决定测试什么，也就是明确测试的条件。
根据软件的状态、状态间的转换、触发状态变化（转换）的输入或事件以及从 状态转换导致的可能的行动来进行测试。
软件结构性测试
概述
结构性测试是用于设计测试用例的基本方法。 与功能性测试相比，结构性测试有时叫做白盒(或甚至叫做透明盒)测
试。 了解程序是如何实现的，理解程序并设计测试用例。 由于具有很强的理论基础，结构性测试本身又引出测试覆盖指标的定
测试用例开发可以与实现并行进行，因此可压缩总的项目开发时间。
功能性测试的缺点
测试用例之间可能存在严重的冗余 可能会存在未测试的软件漏洞。 由于功能性方法基于已描述行为，因此很难保证这些方法能够设计出
没有被描述的行为所对应的测试用例。
软件功能性测试用例设计方法
等价类划分
有效等价类 无效等价类
软件测试开发过程（续）
测试执行阶段
在测试实现阶段，测试用例的开发、实现、确定优先级和组织都应该 包含在测试规程规格说明中。
测试规程（或者手工测试脚本）描述了测试用例执行的顺序。 如果使用测试执行工具(test execution tool)进行测试，这种测试的
软件功能性测试概述
任何程序都可以看作是将从输入定义域映射到输出值域的函数，将 系统看作是黑盒。
黑盒的内容(实现)是不知道的，而用输入和输出表示的黑盒函数。
软件功能性测试依据
软件的规约（规格说明） 功能性测试用例的优点
功能性测试与软件如何实现无关，所以如果程序的具体实现发生变化， 测试用例仍然有用；
Edward Miller在为结构性测试辩护时写道：“如果达到85％或更好的水平，判 断覆盖率[一种结构性测试覆盖率指标]发现的缺陷，一般是‘直觉’[功能性]测 试找出的缺陷的两倍”(Miller，1991)。
两种方法单独使用都是不充分的
功能性测试只利用规格说明设计测试用例，而结构性测试使用程序源代码(实现) 作为测试用例设计的基础。
边界值
临界值 刚好超出临界值 刚好小于临界值
因果图与判定表
复杂条件构成因果图 根据因果图形成判定表
用例（Use Case）测试
用例描述了参与者（包括用户与系统）之间的相互作用，并从这些交互产生一 个从系统用户或客户的角度所期望和能观察到的结果。
根据业务流程，确定测试场景
状态转换测试
如果所有已描述行为（规格说明书）都没有被实现，则结构性测试永远也不会 认识到这一点。
如果程序实现了没有被描述的行为，功能性测试用例永远也不会揭示这一点。
因此，需要结合两种方法，两种方法的组合提高功能性测试的有效性，以及结 构性测试的度量。
由于功能性测试常常会有冗余和漏洞两方面的问题。如果功能性测试结合结构 性测试覆盖率指标执行，则这两个问题都会被发现并解决。
动作顺序将在测试脚本中描述（自动化的测试规程）。 试执行进度计划(test execution schedule) 。
不同的测试规程和自动化测试脚本要体现在测试执行进度计划 (test execution schedule)中，该计划定义了不同测试规程和可 能的自动化测试脚本的执行顺序、执行的时间esign Specification (测试设计规格说明/测试规 约)
根据测试需求编写的指导测试设计的文档，包括测试 设计策略、设计方法、设计范围的文档
义和使用。 测试覆盖指标明确描述了测试用例对所测程序的覆盖情况，便于测试
管理和度量。
缺点
测试用例集合完全局限于已实现的程序行为集合中。 由于结构性方法依靠的是程序，不能设计出程序没有实现的功能的测
试用例。
软件功能性测试与结构性测试的比较
哪种测试方法更好？
对于结构性测试，Robert Poston写道：“这种工具自20世纪70年代以来一直在 浪费测试人员的时间……[它]不支持好的软件测试实践，应该从测试人员的工具 包中剔除”(Poston，1991)。
测试用例设计(Test Case)是重要的测试设计内容，决定测试的覆盖度 和测试效率
三类软件测试技术的特点
基于规格说明的测试技术特点
使用正式或非正式的模型来描述需要解决的问题、软件或其组件等。 根据这些模型，可以系统地导出测试用例。
基于结构的测试技术特点
根据软件的结构信息设计测试用例，比如软件代码和软件设计规格说 明文档。
测试执行进度计划同时考虑了其他的因素，比如回归测试、测试 优先级以及技术和逻辑的依赖等。
软件测试技术
测试技术分类
黑盒测试技术（基于规格说明的测试技术 ） 白盒测试技术（基于结构的测试技术） 基于经验的测试技术
测试设计的内容
测试规约设计（测试规格说明） 测试用例规格说明设计 测试用例设计 测试管理文档模板设计 辅助测试工具设计
可以通过已有的测试用例测量软件的测试覆盖率，并通过系统化的导 出设计用例来提高覆盖率。
基于经验的测试技术特点
测试用例根据参与人员的经验和知识来编写。 测试人员、开发人员、用户和其他的利益相关者对软件、软件使用和
环境等方面所掌握的知识作为信息来源之一。 对可能存在的缺陷及其分布情况的了解作为另一个信息来源。
测试条件是能通过一个或多个测试用例进行验证的一个条目或事件 （比如功能、事务处理、质量特征或结构元素等）。
建立从测试条件到需求的可追溯性，有助于需求变更时的影响分析 (impact analysis)和测试用例集的需求覆盖率分析。
测试设计阶段
在测试设计阶段，要定义和记录测试用例和测试数据。 完成测试设计规格说明（包含测试条件）和测试用例规格说明 预期的测试结果应该作为测试用例规格说明的一部分，同时包含输出、
ISTQB基础知识
软件测试设计技术
目录
软件测试的基本过程 什么是测试用例？ 测试用例的作用 测试用例的组成 测试用例的表现形式 什么是良好的测试用例 测试用例的认识误区
软件测试开发过程
测试分析阶段
在测试分析(test analysis)阶段，要对测试基础文档进行分析，从而 决定测试什么，也就是明确测试的条件。
根据软件的状态、状态间的转换、触发状态变化（转换）的输入或事件以及从 状态转换导致的可能的行动来进行测试。
软件结构性测试
概述
结构性测试是用于设计测试用例的基本方法。 与功能性测试相比，结构性测试有时叫做白盒(或甚至叫做透明盒)测
试。 了解程序是如何实现的，理解程序并设计测试用例。 由于具有很强的理论基础，结构性测试本身又引出测试覆盖指标的定
测试用例开发可以与实现并行进行，因此可压缩总的项目开发时间。
功能性测试的缺点
测试用例之间可能存在严重的冗余 可能会存在未测试的软件漏洞。 由于功能性方法基于已描述行为，因此很难保证这些方法能够设计出
没有被描述的行为所对应的测试用例。
软件功能性测试用例设计方法
等价类划分
有效等价类 无效等价类