软件测试教程宫云战第3章精品PPT课件
合集下载
软件测试第3章 白盒测试 教学PPT
3.1.2 判定覆盖
判定覆盖的作用是使真假分支 均被执行，虽然判定覆盖比语 句覆盖测试能力强，但仍然具 有和语句覆盖一样的单一性。
3.1.2 判定覆盖
以3.1.1节程序为例，设计判定覆盖测试用例。
测试用例 x y z 执行语句路径
test1
2 -1 1
acd
test2
-3 1 -1
abd
test3
3.1.1 语句覆盖
语句覆盖的目的是测试程序中的代码 是否被执行，它只测试代码中的执行 语句，这里的执行语句不包括头文件、 注释、空行等。
3.1.1 语句覆盖
语句覆盖在多分支的程序中，只能覆 盖某一条路径，使得该路径中的每一 个语句至少被执行一次，但不会考虑 各种分支组合情况。
3.1.1 语句覆盖
3.1.1 语句覆盖
语句覆盖无需详细考虑每个判断表达式， 可以直观地从源程序中有效测试执行语 句是否全部被覆盖，由于程序在设计时， 语句之间存在许多内部逻辑关系，而语 句覆盖不能发现其中存在的缺陷，因此 语句覆盖并不能满足白盒测试的测试所 有逻辑语句的基本需求。
3.1.2 判定覆盖
判定覆盖(Decision Coverage) 又称为分支覆盖，其原则是设 计足够多的测试用例，在测试 过程中保证每个判定至少有一 次为真值，有一次为假值。
3.1.3 条件覆盖
以图3.1.1节程序为例，设计条件覆盖测试用例，在该程序中，有2个判 定语句，每个判定语句有2个逻辑条件，共有4个逻辑条件，使用标识 符标识各个逻辑条件取真值与取假值的情况，如下表。
条件1 x>0 x<0 y<0 y>0
条件标记 S1 -S1 S2 -S2
条件2 x>2 x<2 z>0 z<0
软件测试第03章
测试专家 • 协调人职责
– 为代码审查分发材料(程序清单、设计规范)，安 排进程
– 在代码审查过程中起主导作用 – 记录发现的所有错误 – 确保所有错误随后得到改正
静态测试-代码审查和走查
• 代码审查过程：
– (1)协调人提前把代码审查常见错误列表、设计规格说明书、控制流 程图、程序文本及有关要求、规范等分发给小组成员，作为评审的 依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
3.1 黑盒测试与白盒测试
•
任何工程产品都可以使用
白盒测试和黑盒测试两种方法
之一进行测试。
• 1．黑盒测试
•
黑盒测试：在测试时，把
被测程序视为一个不能打开的
黑盒子，完全不考虑程序的内
部结构和内部特性下进行的测
试。
• 已知产品的功能设计规格和 用户手册，可以进行测试证明 每个功能是否实现、每个实现 了的功能是否符合要求，以及 产品的性能是否满足用户的要
– 静态测试不实际执行程序，静态测试的主要目的是检查软件 的表示和描述是否一致，没有冲突和歧义。
– 动态测试需要实际运行测试用例，以发现软件中的错误。白 盒测试中的动态测试主要包括功能确认与接口测试、覆盖率 测试、性能分析、内存分析等。
静态白盒测试
1. 程序的静态测试是在不执行程序的条件下， 有条理地仔细审查软件设计、体系结构和 代码，从而找出软件错误的过程。
– 常见错误列表：把以往所有可能发生的常见错误罗列出来，供与会 者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表， 它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能 多的典型错误，然后把它们制成表格，供在会审时使用。
静态测试-代码审查和走查
• 代码审查过程：
– 为代码审查分发材料(程序清单、设计规范)，安 排进程
– 在代码审查过程中起主导作用 – 记录发现的所有错误 – 确保所有错误随后得到改正
静态测试-代码审查和走查
• 代码审查过程：
– (1)协调人提前把代码审查常见错误列表、设计规格说明书、控制流 程图、程序文本及有关要求、规范等分发给小组成员，作为评审的 依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
3.1 黑盒测试与白盒测试
•
任何工程产品都可以使用
白盒测试和黑盒测试两种方法
之一进行测试。
• 1．黑盒测试
•
黑盒测试：在测试时，把
被测程序视为一个不能打开的
黑盒子，完全不考虑程序的内
部结构和内部特性下进行的测
试。
• 已知产品的功能设计规格和 用户手册，可以进行测试证明 每个功能是否实现、每个实现 了的功能是否符合要求，以及 产品的性能是否满足用户的要
– 静态测试不实际执行程序，静态测试的主要目的是检查软件 的表示和描述是否一致，没有冲突和歧义。
– 动态测试需要实际运行测试用例，以发现软件中的错误。白 盒测试中的动态测试主要包括功能确认与接口测试、覆盖率 测试、性能分析、内存分析等。
静态白盒测试
1. 程序的静态测试是在不执行程序的条件下， 有条理地仔细审查软件设计、体系结构和 代码，从而找出软件错误的过程。
– 常见错误列表：把以往所有可能发生的常见错误罗列出来，供与会 者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表， 它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能 多的典型错误，然后把它们制成表格，供在会审时使用。
静态测试-代码审查和走查
• 代码审查过程：
软件测试教程(第3版)第3章
软件测试教程（第3版） 第3章 软件静态测试技术
4
3.1 软件静态测试
3.1.1 静态测试技术概要
2．静态测试内容及过程
内容及过程主要有：测试需求分析、测试概要设计、测试详细设计、测 试执行与结果分析。 （1）测试需求分析。静态测试过程首要阶段，主要完成静态测试需求分析工 作。需求分析所依据的主要是软件开发计划、需求文档，确定测试的需求， 建立测试基础与评审基础，建立标准测试计划，细节的设计、数据库的测试。 （2）测试概要设计。在需求分析基础上完成测试方案制定，包括测试内容、 测试策略、测试方法、测试目标。还将建立测试详细设计基础与测试评审基 础，并与需求分析一起进入静态测试评审阶段。 （3）测试详细设计。该阶段在完成测试需求分析和概要设计并通过静态测试 评审阶段之后而进入的下一过程。静态测试的详细设计主要任务是完成测试 进程的各项具体安排和测试实施的具体细节考虑，包括测试用例设计、测试 环境搭建、测试工具选用、测试人员组织及测试进度安排等。 （4）测试执行与结果分析。根据已制定完成的静态测试计划进行静态测试执 行过程，落实和完成各项测试具体任务，并提交测试工作的交付物。
手工评审分为正式评审和非正式评审，正式评审是执行检查过程（技术评审），
非正式评审主要为走查过程。 （2）静态测试检查 对静态测试每个过程都进行检查，以确保静态测试的有效性和测试的质量。
检查过程的内容：从所指定测试计划开始，检查测试的初始工作和测试的准备情
况，检查以会议的形式进行，根据检查结果决定是否需要重新开始制订计划或其 后的某项环节及工作。若检查通过，则继续测试过程。
软件测试教程（第3版） 第3章 软件静态测试技术
8
3.1 软件静态测试
3.1.2 静态测试技术
软件测试教程宫云战 PPT课件
• 所设计的测试用例是否完整、是否考虑边界条件、能否达到其
覆盖率要求；
第9页/共42页
8.2测试管理的基本内容
• 测试执行阶段: 建立和设置好相关的测试环境，准备好测试数据，开始执行测试。测试执行可以手工进行，也可以自动进 行。自动化测试借助于测试工具，运行测试脚本，达到测试结果，所以管理比较简单，而手工测试的管理 相对要复杂些。
第24页/共42页
8.4测试管理的实践
• 策划测试过程 • 需求分析 • 变更控制 • 度量与分析 • 测试过程可持续改进
第25页/共42页
8.4测试管理的实践
• 策划测试过程 • 该系统的三个阶段具有相对的独立性，所以可采用“独立、迭代”的测试原则，对测试过程进行 独立策划，以每一阶段完成所提交的阶段性产品作为系统测试准备的就绪点，在就绪点及时开展 测试。 • 因此，在该系统开发过程中，系统测试组可开展三个阶段的系统测试，每个阶段系统测试具有不 同的侧重点，目的在于更好地配合开发工作尽早地发现软件故障，降低软件成本。
8.2测试管理的基本内容
• 8.2.4测试文档管理 • 测试文档的类型
• 测试计划：详细规定测试的要求，包括测试的目的和内容、方法和步骤，以及 测试的准则等。
• 测试分析报告：用来对测试结果进行分析说明。软件经过测试后，应给出评价 的结论性意见，软件的能力如何，存在哪些缺陷和限制等等。
• 测试文档的管理
SQAP SVVP
DTP TDS
TPS
动一个。
•MTP：主确认测试计划，每个SVVP
MTP
DTP TDS
TPS
一个。
每确认活动 一个或多个
TCS DTP TDS
TCS DTP
•DTP：详细确认测试计划，每个活 TC 动一个或多个。
软件测试》第3章课件
场景法
根据用户场景设计测试用例， 模拟用户实际操作流程。
判定表法
将条件和结果进行逻辑组合， 生成全面的测试用例。
测试流程与步骤
01
02
03
需求分析
明确测试目标、范围和需 求。
制定测试计划
确定测试资源、时间、人 员和进度安排。
设计测试用例
根据需求设计详细的测试 用例。
测试流程与步骤
执行测试
按照测试用例执行测试，记录 测试结果和缺陷。
缺陷跟踪与修复
跟踪缺陷状态，验证缺陷修复 情况。
回归测试
验证缺陷修复后，相关功能是 否正常。
结束测试
评估测试覆盖率、缺陷关闭率 等指标，撰写测试总结报告。
03
白盒测试
定义与特点
定义
白盒测试也称为透明盒测试或开 放盒测试，是一种针对软件内部 结构和内部工作过程的测试方法 。
特点
白盒测试要求测试人员对被测软 件的内部实现细节有所了解，以 便设计针对软件内部结构的测试 用例。
测试用例设计
基于程序内部逻辑
白盒测试的测试用例设计通常基于程 序的内部逻辑，包括条件、循环、分 支等。
覆盖率
白盒测试的目标是实现高覆盖率，确 保软件中的所有代码路径都被测试到 。
测试方法与技术
结构覆盖
通过分析程序的内部结构， 设计测试用例以覆盖所有 代码路径、条件和循环。
功能覆盖
基于软件的功能需求，设 计测试用例以覆盖所有功 能模块和子系统。
详细描述
灰盒测试可以采用多种测试方法和技术，如等价类划分、边界值分析、因果图等。这些方法和技术可 以帮助测试人员更全面地覆盖程序的输入和输出，提高测试的效率和准确性。通过合理地运用这些方 法和技术，可以有效地发现程序中的缺陷和错误。
软件测试第三章PPT课件
3.1 软件开发模型
原型模型
软件开发人员根据用户提出的需求，快速地开发出一 个原型，向用户展示待开发软件系统的全部和部分功能及 性能，征求用户对原型的意见，以确定用户真正需求，统 一开发人员和用户对软件项目需求的理解。
问题定义 需求分析
原型开发 原型评价 最终设计
系统实现
3.1 软件开发模型
另一种常用的软件开发模型是螺旋模型，该模型 加入了风险分析在内。
优点：支持结构化软件开发、控制软件开发的复杂 性、促进软件开发工程化等方面起着显著作用。
缺点：缺乏灵活性，无法通过开发活动澄清本来不够 确切的软件需求，这些问题可能导致开发出的软件并不是 用户真正需要的软件，只能要进行返工或不得不在维护中 纠正需求的偏差，为此必须付出高额的代价，为软件开发 带来了不必要的损失。
出错处理检测——检测模块出错处理是否有效。
3.2.1 单元测试
2.单元测试过程
单元测试一般在编码之后进行。 由于每个模块在整个软件中并不是孤立的，在对每个 模块进行单元测试时，需要考虑它和周围模块的相互 联系。为模拟这一联系，在进行单元测试时，必须设 置若干个辅助测试模块。这些辅助模块分为两种： ● 驱动模块（driver）: 用以模拟被测模块的上级模块，
消除或减少风险的损害。
3.1 软件开发模型
由软件开发的螺旋模型可以看出：每一螺旋包括 四方面的活动，即：
①制定计划——确定软件项目开发的目标，选定实 施方案，弄清项目开发的限制条件；
②风险分析——分析所选的实施方案，指出如何识 别并降低风险；
⑧实施方案——实施软件开发； ④评估方案——评价开发工作，提出修正建议。
模块 单元 测试
模块 单元 测试
模块 单元 测试
软件测试全套课件和教案-第3章-单元测试精选全文完整版
书》或需求跟踪 记录
代码静态检查记 录
《正规检视报告 》
问题记录
问题跟踪和解决 记录
软件代码开发版 本
《单元测试报告 》
《软件编码与单 元测试任务总结
报告》
Classified as Business
本章小结
单元测试不但保证局部代码的质量，同时使开发过程自 然而然地变得"敏捷"。单元测试对项目或产品的整个生 命周期都具有积极的影响： 对需求分析、设计的影响：自动回归测试可以发现
错误处理测试
出错的描述难以理解； 出错的描述不足以对错误定位和确定
出错的原因； 显示的错误与实际的错误不符； 对错误条件的处理不正确； 在对错误进行处理之前，错误条件已
经引起系统的干预； 如果出错情况不予考虑，那么检查恢
复正常后模块可否正常工作。
Classified as Business
模块接口
调用所测模块的输入参数与模块的形式参数在个数、属性、 顺序上是否匹配； 所测模块调用子模块时，它输入个子模块的参数与子模块的 形式参数在个数、属性、顺序上是否匹配； 是否修改了只做输入用的形式参数；
输出给标准函数的参数在个数、属性、顺序上是否匹配；
全局变量的定义在各模块中是否一致；
限制是否通过形式参数来传送。
驱动模块（Driver） 桩模块（Stub）
Classified as Business
主要单元测试 方法
人工静态分析 自动静态分析 自动动态测试 人工动态测试
Classified as Business
测试过程中各种人员的作用
系统分析设计人员 进行需求跟踪，确保系统需求的实现和更新。进行软件单元 可测性分析，确定单元测试的对象、范围和方法。
代码静态检查记 录
《正规检视报告 》
问题记录
问题跟踪和解决 记录
软件代码开发版 本
《单元测试报告 》
《软件编码与单 元测试任务总结
报告》
Classified as Business
本章小结
单元测试不但保证局部代码的质量，同时使开发过程自 然而然地变得"敏捷"。单元测试对项目或产品的整个生 命周期都具有积极的影响： 对需求分析、设计的影响：自动回归测试可以发现
错误处理测试
出错的描述难以理解； 出错的描述不足以对错误定位和确定
出错的原因； 显示的错误与实际的错误不符； 对错误条件的处理不正确； 在对错误进行处理之前，错误条件已
经引起系统的干预； 如果出错情况不予考虑，那么检查恢
复正常后模块可否正常工作。
Classified as Business
模块接口
调用所测模块的输入参数与模块的形式参数在个数、属性、 顺序上是否匹配； 所测模块调用子模块时，它输入个子模块的参数与子模块的 形式参数在个数、属性、顺序上是否匹配； 是否修改了只做输入用的形式参数；
输出给标准函数的参数在个数、属性、顺序上是否匹配；
全局变量的定义在各模块中是否一致；
限制是否通过形式参数来传送。
驱动模块（Driver） 桩模块（Stub）
Classified as Business
主要单元测试 方法
人工静态分析 自动静态分析 自动动态测试 人工动态测试
Classified as Business
测试过程中各种人员的作用
系统分析设计人员 进行需求跟踪，确保系统需求的实现和更新。进行软件单元 可测性分析，确定单元测试的对象、范围和方法。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3.４程序变异测试
程序变异测试技术的基本思想是： 对于给定的程序P，先假定程序中存在一些小错误，每假设一个错误， 程序P就变成P′，如果假设了n个错误：e1，e2，…，en，则对应有 n个不同的程序：P1，P2，…，Pn，这里Pi称为P的变异因子。 存在测试数据Ci，使得P和Pi的输出结果是不同的。因此，根据程序P 和每个变异的程序，可以求得P1，P2…，Pn的测试数据集C={C1， C2，…，Cn}。运行C，如果对每一个Ci，P都是正确的，而Pi都是 错误的，这说明P的正确性较高。如果对某个Ci，P是错误的，而Pi是 正确的，这说明P存在错误，而错误就是ei。
路径覆盖准则
部分覆盖准则间的关系
复合谓词覆盖准则
分支--谓词覆盖准则
分支覆盖准则
原子谓词覆盖准则
语句覆盖准则
3.２数据流测试
一、基本概念
变量的定义性出现：若一个变量在程序中的某处 出现使数据与该变量相绑定，则称该出现是定义 性出现。
变量的引用性出现：若一个变量在程序中的某处 出现使与该变量相绑定的数据被引用，则称该出 现是引用性出现。
选择[Browse | Quality | Criteria Level ]菜单项，Logisciop会显示Audit 对所测源程序的各项质量标准的检测结果，具体包括：系统的质量标 准、类的质量标准、函数的质量标准。
选择[ Browse | Quality | Quality Report ]菜单项，可生成网页风格的 系统质量评价报告。
二、动态工具
静态测试工具类型：
1.功能确认与接口测试
测试包括对各模块功能、模块间的接口、局部数据结构、主要执 行路径、错误处理等方面进行的测试。
2.覆盖测试
覆盖分析对所涉及的程序结构元素进行度量，以确定测试执行的 充分性。
动态工具应用实例
Rational PureCoverage 应用：
Rational PureCoverage是面向VC、VB或者Java开发的测 试覆盖程度检测工具，它可以自动检测测试的完整性和 那些无法达到的部分。作为一个质量控制工程，可以使 用PureCoverage在每一个测试阶段产生详尽的测试覆盖 程度报告
程序强变异测试
变异测试的缺点是它需要大量的计算机资源来完成测试充分性分析。 对于一个中等规模的软件，所需的存储空间也是巨大的，运行大量
变异因子也导致了时间上巨大的开销。
程序弱变异测试
弱变异和强变异有很多相似之处。其主要差别在于：弱变异强调的 是变动程序的组成部分，根据弱变异准则，只要事先确定导致C与C′ 产生不同值的测试数据组，则可将程序在此测试数据组上运行，而 并不实际产生其变异因子。 弱变异测试方法的主要优点是开销较小，效率较高。
3.５白盒测试工具
一、静态工具
静态测试工具类型：
1.代码审查
2.一致性检查
3.错误检查
4.接口分析
5.输入/输出析
8.单元分析
9.复杂度分析
静态工具应用实例
1. Logiscope的软件质量分析工具 Audit应用：
Audit是审查程序代码质量的，它通过一个文本文件来定义质量模 型。文件中首先定义了若干个度量元，并为这些度量元设定了数 值范围，接着通过组合若干个度量元形成质量标准，最后又通过 组合质量标准，形成最后的质量因素。这个过程与软件质量模型 中由底层到高层、由细节到概括的结构恰好对应。
选择[ Project | Start Viewer ]菜单项，启动“Logiscope Viewer”，通过 点击工具条上的按钮，可以查看Audit所提供的对函数的各种分析信息。
２. Logiscope的代码规范性检测工具 RuleChecker应 用：
使用RuleChecker来检查代码的规范性分为两个步骤：首先是建立 被检测代码的RuleChecker项目，然后是分析RuleChecker给出的代 码书写规范性检测结果，得出报告。
PureCoverage 主界面
选择“file”中的run 后，出现对话框Run Program。在Program name中 选择被测对象的路径后，点击Run，运行程序。运行完程序后，会出 现运行后的结果数据。
被测程序的函数覆盖和代码覆盖情况
双击Coverage Browser 窗口中的任何一个文件或函数，或者选择view 的Function List，即可看到相应的程序代码。
（1）根据向导建立RuleChecker项目 RuleChecker界面
（２）查看检测结果 选择[ Browse | Rule | Rule Violations ]菜单命令，RuleChecker会在 树状视图中列出代码中所有违反编码规范的地方。
点击[ Browse | Rule | Rule Violations Report ]菜单命令，会生成 RuleChecker的检测报告。
（1）在Logiscope studio中建立Audit项目
Logiscope studio环境
点击[]菜单项， 并根据新建项目向导建立项目： 新建项目对话框
新建项目向导
新建项目结束
（２）查看检测结果 选择[ Browse | Quality | Factor Level ]菜单项，Logisciop会显示Audit 对所检测源程序质量水平的评价结果，评价结果包括系统的质量、类 的质量、函数的质量。
第3章 白盒测试
3.1控制流测试
一、基本概念
有向图
路径
完整路径
e1
简单路径
基本路径
子路径 回路 无回路路径 连接 覆盖
e6
e2
e3 e5
e7
e4
路径覆盖关系举例
二、控制流覆盖准则
语句覆盖准则 分支覆盖准则 谓词测试
原子谓词覆盖准则 分支－谓词覆盖准则 复合谓词覆盖准则
二、数据流覆盖准则
定义覆盖测试准则 引用覆盖测试准则 定义－引用覆盖测试准则
3.３程序插装
程序插装技术的研究涉及下列几个问题：
(1)探测哪些信息？ (2)程序的什么位置设置探测点？ (3)需要多少探测点？
程序插装类型：
用于测试覆盖率和测试用例有效性度量的程序插装 用于断言检测的程序插装