DUG软件测试基础知识PPT课件
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
都至少测试一次 在循环的边界和运行界限内执行循环体
8
在编码开始前进行检查设计
检查功能设计说明，消除歧义
功能的用意、总体位置 输入、输出 可能的错误/例外 接口定义 交互细节 实施建议
2021/3/12
9
检查代码
通过代码检查能够发现大部分的错误
通过检查代码发现模块中的错误
D iscovery activity
Faults found / 1000 lines of code
例1 产品必须在固定的时间间隔内提供状态信 息，并且每次时间间隔不得小于60秒。
完整吗？
清晰吗？
例2 分析程序应该能生成HTML标记错误的报告， 从而使HTML初学者可以用它来快速排错。
是否有歧义？
可验证吗？
例3 如果可能的话，应当根据系统货物编号列 表，在线确认输入的货物编号。
202“1/3/1如2 果可能的话”是什么意思？
作用
通过对代码标准及质量的监控提高代码可靠性 尽可能早地通过对源代码的检查发现缺陷 组织代码审核定位易产生错误的模块
非常有效的质量保证手段
越来越多地被采用
2021/3/12
3
静态分析的主要内容
检查需求 检查设计 检查代码
缺陷产生的原因
其它 编码
需求
设计
2021/3/12
4
检查需求
信息流分析 断言分析
2021/3/12
13
代码审核内容
流图和调用关系图
作为理解代码的帮助 作为审核符合设计的帮助 作为测试设计的帮助 作为调试的帮助
代码规则的执行
针对不同语言的特征 格式和形式 命名规范 度量标准的强制
2021/3/12
14
静态分析方法
审查：Inspection 走查：Walkthrough 自动化工具
20
白盒测试
把测试对象看做一个透明的盒子
利用程序内部的逻辑结构及有关信息，设计或选择测 试用例，对程序所有逻辑路径进行测试
通过在不同点检查程序的状态，确定实际的状态 是否与预期的状态一致
Input
2021/3/12
Output
21
白盒测试目标
尽可能高的覆盖率
对程序模块的所有独立的执行路径至少测试一次 对所有的逻辑判定，取“真”与取“假”的两种情况
16
审查（Inspection）
开发组、测试组和相关人员(QA、产品经理等)联 合进行。
采用讲解、提问并使用Checklist方式进行的查找 错误的活动。
以会议的形式，制定目标、流程、规则和结果报 告。
相关资料要在会议前下发并阅读。
参加人员
经验丰富的开发人员
和本模块相关的开发人员
202测1/3/1试2 组和相关人员
基于质量度量
Logiscope McCabe LDRA
2021/3/12
19
如何使静态分析更有效？
必须引入“别人”的眼睛
根据团队及项目的实际情况，设计合理的实施办 法
有准备地进行
应该有包含所有关注要点的Checklist
把握会议时间
每次以 2小时为限 可以进行多次
2021/3/12
需求的标准
完整性
是否完整描述一个功能
正确性
是否正确反应客户要求
可行性 必要性
Gold plating?
无二义性
会引起歧义吗
可验证性
测试用例怎么写？
202实1/3/施12 无关性
需求规格说明的标准
完整性
是否包含所有需求 FURPS
一致性
相互矛盾 重复
5
需求检查练习
Module 2. 软件测试技术
2021/3/12
1
软件测试基本方法 主要内容
静态分析 白盒测试 黑盒测试
测试模式
范围测试 说明书测试 风险测试 情景测试 组合测试 探索测试
实际练习
2021/3/12
2
什么是静态分析？
不实际运行程序，通过检查和阅读等手段来发现 错误并评估代码质量的软件测试技术。
7
绝对的肯定 规格说明用语清单
总是、每一种、所有、没有、从不
注意隐含的假设
当然、因此、显然、必然
模棱两可的词
某些、有时、常常、通常、经常、太多、几乎
不可测的描述
良好、迅速、廉价、高效、稳定
隐藏的需求
已处理、已拒绝、已忽略、已消除
缺少的分支
202如1/3/1果2 …那么…（没有“否则…”分支）
!
80%的问题是由于20%的代码引起的
2021/3/12
11
复杂度度量
度量元
McCabe
Halstead 嵌套级别(最大/平均)
规格度量
行数
语句数
注释数
声明数
……
2021/3/12
12
代码审核内容
分析容易产生错误的代码:
控制流分析
非结构化的代码 死代码
数据流分析
未定义的数据的使用 未使用的数据
2021/3/12
15
走查（Walkthrough）
开发组内部进行的
采用讲解、讨论和模拟运行的方式查找错误的活动
限时 - 避免跑题
参加人员
经验丰富的开发人员
和本模块相关的开发人员 本项目组的新人
由本模块的开发者进行讲解、回答问题并记录
不要现场修改
检查要点
逻辑错误
202代1/3/码12 标准/规范/风格
17
审查（Inspection）
由另外一名开发者进行讲解、其他开发者主要按 照Checklist进行提问并填表、本模块开发者回答 问题并记录
不要现场修改
检查要点
设计需求 代码标准/规范/风格 文档的完整性和一致性
2021/3/12
18
基于编码规则 自动化工具
Logiscope LDRA NuMega的CodeReview
6
需求检查练习
例4 产品不应该提供将带来灾难性后果的查找 和替换选择。
真正的需求是什么？例5 系对标准XYZ 1.4.1的支持是可选的。
有歧义吗？
例6 当用户选择“紧凑内存”选项时，程序通 过Huffman解析矩阵方法将邮件列表数据压缩到 相应的大小。
可测吗？
202代1/3/1码2 无关吗？
R equirem ent review
2.5
D esign review
5.0
C ode review
10.0
Integration test
3.0
Acceptance tests
2.0
2021/3/12
10
检查代码
研究分析代码而不用实际执行
包括可执行的代码和非执行的代码
提供的信息
度量标准 容易产生错误的代码 代码规则的执行 流图和调用图的分析
8
在编码开始前进行检查设计
检查功能设计说明，消除歧义
功能的用意、总体位置 输入、输出 可能的错误/例外 接口定义 交互细节 实施建议
2021/3/12
9
检查代码
通过代码检查能够发现大部分的错误
通过检查代码发现模块中的错误
D iscovery activity
Faults found / 1000 lines of code
例1 产品必须在固定的时间间隔内提供状态信 息，并且每次时间间隔不得小于60秒。
完整吗？
清晰吗？
例2 分析程序应该能生成HTML标记错误的报告， 从而使HTML初学者可以用它来快速排错。
是否有歧义？
可验证吗？
例3 如果可能的话，应当根据系统货物编号列 表，在线确认输入的货物编号。
202“1/3/1如2 果可能的话”是什么意思？
作用
通过对代码标准及质量的监控提高代码可靠性 尽可能早地通过对源代码的检查发现缺陷 组织代码审核定位易产生错误的模块
非常有效的质量保证手段
越来越多地被采用
2021/3/12
3
静态分析的主要内容
检查需求 检查设计 检查代码
缺陷产生的原因
其它 编码
需求
设计
2021/3/12
4
检查需求
信息流分析 断言分析
2021/3/12
13
代码审核内容
流图和调用关系图
作为理解代码的帮助 作为审核符合设计的帮助 作为测试设计的帮助 作为调试的帮助
代码规则的执行
针对不同语言的特征 格式和形式 命名规范 度量标准的强制
2021/3/12
14
静态分析方法
审查：Inspection 走查：Walkthrough 自动化工具
20
白盒测试
把测试对象看做一个透明的盒子
利用程序内部的逻辑结构及有关信息，设计或选择测 试用例，对程序所有逻辑路径进行测试
通过在不同点检查程序的状态，确定实际的状态 是否与预期的状态一致
Input
2021/3/12
Output
21
白盒测试目标
尽可能高的覆盖率
对程序模块的所有独立的执行路径至少测试一次 对所有的逻辑判定，取“真”与取“假”的两种情况
16
审查（Inspection）
开发组、测试组和相关人员(QA、产品经理等)联 合进行。
采用讲解、提问并使用Checklist方式进行的查找 错误的活动。
以会议的形式，制定目标、流程、规则和结果报 告。
相关资料要在会议前下发并阅读。
参加人员
经验丰富的开发人员
和本模块相关的开发人员
202测1/3/1试2 组和相关人员
基于质量度量
Logiscope McCabe LDRA
2021/3/12
19
如何使静态分析更有效？
必须引入“别人”的眼睛
根据团队及项目的实际情况，设计合理的实施办 法
有准备地进行
应该有包含所有关注要点的Checklist
把握会议时间
每次以 2小时为限 可以进行多次
2021/3/12
需求的标准
完整性
是否完整描述一个功能
正确性
是否正确反应客户要求
可行性 必要性
Gold plating?
无二义性
会引起歧义吗
可验证性
测试用例怎么写？
202实1/3/施12 无关性
需求规格说明的标准
完整性
是否包含所有需求 FURPS
一致性
相互矛盾 重复
5
需求检查练习
Module 2. 软件测试技术
2021/3/12
1
软件测试基本方法 主要内容
静态分析 白盒测试 黑盒测试
测试模式
范围测试 说明书测试 风险测试 情景测试 组合测试 探索测试
实际练习
2021/3/12
2
什么是静态分析？
不实际运行程序，通过检查和阅读等手段来发现 错误并评估代码质量的软件测试技术。
7
绝对的肯定 规格说明用语清单
总是、每一种、所有、没有、从不
注意隐含的假设
当然、因此、显然、必然
模棱两可的词
某些、有时、常常、通常、经常、太多、几乎
不可测的描述
良好、迅速、廉价、高效、稳定
隐藏的需求
已处理、已拒绝、已忽略、已消除
缺少的分支
202如1/3/1果2 …那么…（没有“否则…”分支）
!
80%的问题是由于20%的代码引起的
2021/3/12
11
复杂度度量
度量元
McCabe
Halstead 嵌套级别(最大/平均)
规格度量
行数
语句数
注释数
声明数
……
2021/3/12
12
代码审核内容
分析容易产生错误的代码:
控制流分析
非结构化的代码 死代码
数据流分析
未定义的数据的使用 未使用的数据
2021/3/12
15
走查（Walkthrough）
开发组内部进行的
采用讲解、讨论和模拟运行的方式查找错误的活动
限时 - 避免跑题
参加人员
经验丰富的开发人员
和本模块相关的开发人员 本项目组的新人
由本模块的开发者进行讲解、回答问题并记录
不要现场修改
检查要点
逻辑错误
202代1/3/码12 标准/规范/风格
17
审查（Inspection）
由另外一名开发者进行讲解、其他开发者主要按 照Checklist进行提问并填表、本模块开发者回答 问题并记录
不要现场修改
检查要点
设计需求 代码标准/规范/风格 文档的完整性和一致性
2021/3/12
18
基于编码规则 自动化工具
Logiscope LDRA NuMega的CodeReview
6
需求检查练习
例4 产品不应该提供将带来灾难性后果的查找 和替换选择。
真正的需求是什么？例5 系对标准XYZ 1.4.1的支持是可选的。
有歧义吗？
例6 当用户选择“紧凑内存”选项时，程序通 过Huffman解析矩阵方法将邮件列表数据压缩到 相应的大小。
可测吗？
202代1/3/1码2 无关吗？
R equirem ent review
2.5
D esign review
5.0
C ode review
10.0
Integration test
3.0
Acceptance tests
2.0
2021/3/12
10
检查代码
研究分析代码而不用实际执行
包括可执行的代码和非执行的代码
提供的信息
度量标准 容易产生错误的代码 代码规则的执行 流图和调用图的分析