module 2. 软件测试技术

74
Module 2. Module 2. 软软软软软软 软软软软软软

Upload: gitano

Post on 19-Mar-2016

136 views

Category:

Documents


8 download

DESCRIPTION

Module 2. 软件测试技术. 主要内容. 软件测试基本方法 静态分析 白盒测试 黑盒测试 测试模式 范围测试 说明书测试 风险测试 情景测试 组合测试 探索测试 实际练习. 什么是静态分析?. 不实际运行程序,通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。 作用 通过对代码标准及质量的监控提高代码可靠性 尽可能早地通过对源代码的检查发现缺陷 组织代码审核定位易产生错误的模块 非常有效的质量保证手段 越来越多地被采用. 缺陷产生的原因. 其它. 编码. 需求. 设计. 静态分析的主要内容. 检查需求 检查设计 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Module 2.  软件测试技术

Module 2. Module 2. 软件测试技术软件测试技术

Page 2: Module 2.  软件测试技术

主要内容主要内容 软件测试基本方法软件测试基本方法 静态分析静态分析 白盒测试白盒测试 黑盒测试黑盒测试

测试模式测试模式 范围测试范围测试 说明书测试说明书测试 风险测试风险测试 情景测试情景测试 组合测试组合测试 探索测试探索测试

实际练习实际练习

Page 3: Module 2.  软件测试技术

什么是静态分析?什么是静态分析? 不实际运行程序,通过检查和阅读等手段来发现不实际运行程序,通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。错误并评估代码质量的软件测试技术。 作用作用

通过对代码标准及质量的监控提高代码可靠性通过对代码标准及质量的监控提高代码可靠性 尽可能早地通过对源代码的检查发现缺陷尽可能早地通过对源代码的检查发现缺陷 组织代码审核定位易产生错误的模块组织代码审核定位易产生错误的模块

非常有效的质量保证手段非常有效的质量保证手段 越来越多地被采用越来越多地被采用

Page 4: Module 2.  软件测试技术

静态分析的主要内容静态分析的主要内容 检查需求检查需求 检查设计检查设计 检查代码检查代码 需求

设计

编码

其它缺陷产生的原因

Page 5: Module 2.  软件测试技术

检查需求检查需求 需求的标准需求的标准 完整性完整性

是否完整描述一个功能是否完整描述一个功能 正确性正确性

是否正确反应客户要求是否正确反应客户要求 可行性可行性 必要性必要性

Gold plating?Gold plating? 无二义性无二义性

会引起歧义吗会引起歧义吗 可验证性可验证性

测试用例怎么写?测试用例怎么写? 实施无关性实施无关性

需求规格说明的标准需求规格说明的标准 完整性完整性

是否包含所有需求是否包含所有需求 FURPSFURPS

一致性一致性 相互矛盾相互矛盾 重复重复

Page 6: Module 2.  软件测试技术

需求检查练习需求检查练习 例例 11  产品必须在固定的时间间隔内提供状态信 产品必须在固定的时间间隔内提供状态信息,并且每次时间间隔不得小于息,并且每次时间间隔不得小于 6060 秒。秒。 完整吗?完整吗? 清晰吗?清晰吗?

例例 22  分析程序应该能生成 分析程序应该能生成 HTMLHTML 标记错误的报标记错误的报告,从而使告,从而使 HTMLHTML 初学者可以用它来快速排错。初学者可以用它来快速排错。 是否有歧义?是否有歧义? 可验证吗?可验证吗?

例例 33  如果可能的话,应当根据系统货物编号列 如果可能的话,应当根据系统货物编号列表,在线确认输入的货物编号。表,在线确认输入的货物编号。 ““ 如果可能的话”是什么意思?如果可能的话”是什么意思?

Page 7: Module 2.  软件测试技术

需求检查练习需求检查练习 例例 44  产品不应该提供将带来灾难性后果的查找 产品不应该提供将带来灾难性后果的查找和替换选择。和替换选择。 真正的需求是什么?真正的需求是什么?

例例 55 系统对标准 系统对标准 XYZ 1.4.1XYZ 1.4.1 的支持是可选的。的支持是可选的。 有歧义吗?有歧义吗?

例例 66  当用户选择“紧凑内存”选项时,程序通 当用户选择“紧凑内存”选项时,程序通过过 HuffmanHuffman解析矩阵方法将邮件列表数据压缩到解析矩阵方法将邮件列表数据压缩到相应的大小。相应的大小。 可测吗?可测吗? 代码无关吗?代码无关吗?

Page 8: Module 2.  软件测试技术

规格说明用语清单规格说明用语清单 绝对的肯定绝对的肯定 总是、每一种、所有、没有、从不总是、每一种、所有、没有、从不

注意隐含的假设注意隐含的假设 当然、因此、显然、必然当然、因此、显然、必然

模棱两可的词模棱两可的词 某些、有时、常常、通常、经常、太多、几乎某些、有时、常常、通常、经常、太多、几乎

不可测的描述不可测的描述 良好、迅速、廉价、高效、稳定良好、迅速、廉价、高效、稳定

隐藏的需求隐藏的需求 已处理、已拒绝、已忽略、已消除已处理、已拒绝、已忽略、已消除

缺少的分支缺少的分支 如果…那么…(没有“否则…”分支)如果…那么…(没有“否则…”分支)

Page 9: Module 2.  软件测试技术

检查设计检查设计 在编码开始前进行在编码开始前进行 检查功能设计说明,消除歧义检查功能设计说明,消除歧义

功能的用意、总体位置功能的用意、总体位置 输入、输出输入、输出 可能的错误可能的错误 //例外例外 接口定义接口定义 交互细节交互细节 实施建议实施建议

Page 10: Module 2.  软件测试技术

检查代码检查代码 通过检查代码发现模块中的错误通过检查代码发现模块中的错误通过代码检查能够发现大部分的错误

Discovery activity Faults found / 1000lines of code

Requirement review 2.5

Design review 5.0

Code review 10.0

Integration test 3.0

Acceptance tests 2.0

Page 11: Module 2.  软件测试技术

检查代码检查代码 研究分析代码而不用实际执行研究分析代码而不用实际执行 包括可执行的代码和非执行的代码包括可执行的代码和非执行的代码

提供的信息提供的信息 度量标准度量标准 容易产生错误的代码容易产生错误的代码 代码规则的执行代码规则的执行 流图和调用图的分析流图和调用图的分析

80% 的问题是由于 20% 的代码引起的!!

Page 12: Module 2.  软件测试技术

度量元度量元 复杂度度量复杂度度量 McCabeMcCabe HalsteadHalstead 嵌套级别嵌套级别 (( 最大最大 // 平均平均 ))

规格度量规格度量 行数行数 语句数语句数 注释数注释数 声明数声明数 …………

Page 13: Module 2.  软件测试技术

代码审核内容代码审核内容 分析容易产生错误的代码分析容易产生错误的代码 :: 控制流分析控制流分析

非结构化的代码非结构化的代码 死代码死代码

数据流分析数据流分析 未定义的数据的使用未定义的数据的使用 未使用的数据未使用的数据

信息流分析信息流分析 断言分析断言分析

Page 14: Module 2.  软件测试技术

代码审核内容代码审核内容 流图和调用关系图流图和调用关系图 作为理解代码的帮助作为理解代码的帮助 作为审核符合设计的帮助作为审核符合设计的帮助 作为测试设计的帮助作为测试设计的帮助 作为调试的帮助作为调试的帮助

代码规则的执行代码规则的执行 针对不同语言的特征针对不同语言的特征 格式和形式格式和形式 命名规范命名规范 度量标准的强制度量标准的强制

Page 15: Module 2.  软件测试技术

静态分析方法静态分析方法 走查:走查: WalkthroughWalkthrough 审查:审查: InspectionInspection 自动化工具自动化工具

Page 16: Module 2.  软件测试技术

走查(走查( WalkthroughWalkthrough )) 开发组内部进行的开发组内部进行的 采用讲解、讨论和模拟运行的方式查找错误的活动采用讲解、讨论和模拟运行的方式查找错误的活动 限时 限时 - - 避免跑题避免跑题 参加人员参加人员

经验丰富的开发人员经验丰富的开发人员 和本模块相关的开发人员和本模块相关的开发人员 本项目组的新人本项目组的新人

由本模块的开发者进行讲解、回答问题并记录由本模块的开发者进行讲解、回答问题并记录 不要现场修改不要现场修改

检查要点检查要点 逻辑错误逻辑错误 代码标准代码标准 //规范规范 //风格风格

Page 17: Module 2.  软件测试技术

审查(审查( InspectionInspection )) 开发组、测试组和相关人员开发组、测试组和相关人员 (QA(QA 、产品经理等、产品经理等 ))联合进行。联合进行。 采用讲解、提问并使用采用讲解、提问并使用 ChecklistChecklist 方式进行的查方式进行的查找错误的活动。找错误的活动。 以会议的形式,制定目标、流程、规则和结果报以会议的形式,制定目标、流程、规则和结果报告。告。 相关资料要在会议前下发并阅读。相关资料要在会议前下发并阅读。 参加人员参加人员

经验丰富的开发人员经验丰富的开发人员 和本模块相关的开发人员和本模块相关的开发人员 测试组和相关人员测试组和相关人员

Page 18: Module 2.  软件测试技术

审查(审查( InspectionInspection )) 由另外一名开发者进行讲解、其他开发者主要按由另外一名开发者进行讲解、其他开发者主要按照照 ChecklistChecklist 进行提问并填表、本模块开发者回进行提问并填表、本模块开发者回答问题并记录答问题并记录 不要现场修改不要现场修改

检查要点检查要点 设计需求设计需求 代码标准代码标准 //规范规范 //风格风格 文档的完整性和一致性文档的完整性和一致性

Page 19: Module 2.  软件测试技术

自动化工具自动化工具 基于编码规则基于编码规则 LogiscopeLogiscope LDRALDRA NuMegaNuMega 的的 CodeReviewCodeReview

基于质量度量基于质量度量 LogiscopeLogiscope McCabeMcCabe LDRALDRA

Page 20: Module 2.  软件测试技术

如何使静态分析更有效?如何使静态分析更有效? 必须引入“别人”的眼睛必须引入“别人”的眼睛 根据团队及项目的实际情况,设计合理的实施办根据团队及项目的实际情况,设计合理的实施办法法 有准备地进行有准备地进行

应该有包含所有关注要点的应该有包含所有关注要点的 ChecklistChecklist 把握会议时间把握会议时间

每次以 每次以 22 小时为限小时为限 可以进行多次可以进行多次

Page 21: Module 2.  软件测试技术

白盒测试白盒测试 把测试对象看做一个透明的盒子把测试对象看做一个透明的盒子 利用程序内部的逻辑结构及有关信息,设计或选择测利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试试用例,对程序所有逻辑路径进行测试

通过在不同点检查程序的状态,确定实际的状态通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致是否与预期的状态一致

Input Output

Page 22: Module 2.  软件测试技术

白盒测试目标白盒测试目标 尽可能高的覆盖率尽可能高的覆盖率 对程序模块的所有独立的执行路径至少测试一次对程序模块的所有独立的执行路径至少测试一次 对所有的逻辑判定,取“真”与取“假”的两种情况对所有的逻辑判定,取“真”与取“假”的两种情况都至少测试一次都至少测试一次 在循环的边界和运行界限内执行循环体在循环的边界和运行界限内执行循环体

测试内部数据结构的有效性测试内部数据结构的有效性 执行效率执行效率

Page 23: Module 2.  软件测试技术

逻辑覆盖逻辑覆盖 以程序内部的逻辑结构为基础的设计测试用例的以程序内部的逻辑结构为基础的设计测试用例的技术技术 主要包含以下几种情况主要包含以下几种情况

语句覆盖语句覆盖 判定覆盖判定覆盖 条件覆盖条件覆盖 路径覆盖路径覆盖

Page 24: Module 2.  软件测试技术

逻辑覆盖逻辑覆盖 语句覆盖语句覆盖 设计若干个测试用例,使得每一可执行语句至少执行一次设计若干个测试用例,使得每一可执行语句至少执行一次

判定覆盖判定覆盖 设计若干个测试用例,使得程序中每个判断的取真分支和取设计若干个测试用例,使得程序中每个判断的取真分支和取假分支至少经历一次假分支至少经历一次 判定覆盖又称为分支覆盖判定覆盖又称为分支覆盖

条件覆盖条件覆盖 设计若干个测试用例,使得程序中每个判断的每个条件的可设计若干个测试用例,使得程序中每个判断的每个条件的可能取值至少执行一次能取值至少执行一次

路径覆盖路径覆盖 设计足够的测试用例,覆盖程序中所有可能的路径设计足够的测试用例,覆盖程序中所有可能的路径

Page 25: Module 2.  软件测试技术

黑盒测试黑盒测试 把测试对象看做一个黑盒子把测试对象看做一个黑盒子 不考虑程序内部的逻辑结构和内部特性不考虑程序内部的逻辑结构和内部特性 只依据程序的需求规格说明书只依据程序的需求规格说明书 检查程序的功能是否符合它的功能说明检查程序的功能是否符合它的功能说明

Input Output

Page 26: Module 2.  软件测试技术

黑盒测试黑盒测试 在程序接口上进行测试在程序接口上进行测试 主要是为了发现以下错误主要是为了发现以下错误

是否有不正确或遗漏了的功能是否有不正确或遗漏了的功能 ?? 在接口上,输入能否正确地接受在接口上,输入能否正确地接受 ? ? 能否输出正确的能否输出正确的结果结果 ?? 是否有数据结构错误或外部信息是否有数据结构错误或外部信息 ((例如数据文件例如数据文件 )) 访访问错误问错误 ?? 性能上是否能够满足要求性能上是否能够满足要求 ?? 是否有初始化或终止性错误是否有初始化或终止性错误 ??

Page 27: Module 2.  软件测试技术

黑盒测试黑盒测试 在过去的测试中,我们常从开发者的视角出发分在过去的测试中,我们常从开发者的视角出发分析代码和规格说明书。析代码和规格说明书。 规格说明书仅能给我们提供一部分风险类型,我规格说明书仅能给我们提供一部分风险类型,我们必须在更广的范围内进行测试。们必须在更广的范围内进行测试。 不同领域的专家能够看到不同的使系统产生缺陷不同领域的专家能够看到不同的使系统产生缺陷的机会,并设计出能够引发这些缺陷的测试用例。的机会,并设计出能够引发这些缺陷的测试用例。 跳出框框进行思考和设计,是黑盒测试的精髓。跳出框框进行思考和设计,是黑盒测试的精髓。

Page 28: Module 2.  软件测试技术

黑盒测试模式黑盒测试模式

Page 29: Module 2.  软件测试技术

模式与技术模式与技术 测试技术是进行测试的方法。测试技术是进行测试的方法。 测试模式指用于指导设计测试的思路,一种测试测试模式指用于指导设计测试的思路,一种测试模式可能会用到一种或多种技术。模式可能会用到一种或多种技术。 设计任何测试需要包含五个方面的内容:设计任何测试需要包含五个方面的内容:

测试什么?测试什么? 试图发现什么问题?试图发现什么问题? 如何判断测试通过或失败?如何判断测试通过或失败? 怎么进行测试?怎么进行测试? 谁来执行测试?谁来执行测试?

Page 30: Module 2.  软件测试技术

测试模式测试模式 范围测试范围测试 规格说明测试规格说明测试 风险测试风险测试 情景测试情景测试 探索测试探索测试 组合测试组合测试 ……

Page 31: Module 2.  软件测试技术

模式:范围测试模式:范围测试 采用“抽样”的策略,从众多的可能情况中抽取合采用“抽样”的策略,从众多的可能情况中抽取合理的典型用例理的典型用例 常见办法常见办法

等价类划分等价类划分 将输入划分成若干等价组。将输入划分成若干等价组。 从每一类中取一个代表值作为整个组的代表。从每一类中取一个代表值作为整个组的代表。 如果一个测试发现的缺陷,也能被另一个测试发现,则两个测如果一个测试发现的缺陷,也能被另一个测试发现,则两个测试等价。试等价。

边界值测试边界值测试 边界值是一个等价类向另一个等价类过度的点。边界值是一个等价类向另一个等价类过度的点。 程序在边界更容易出错,所以边界值和边界附近的值是最佳的程序在边界更容易出错,所以边界值和边界附近的值是最佳的测试点。测试点。

Page 32: Module 2.  软件测试技术

范围测试范围测试 优点优点 可以通过较少的用例检测出最可能发生的错误可以通过较少的用例检测出最可能发生的错误 很直观的方法,易于普及很直观的方法,易于普及

弱点弱点 漏掉不位于边界或典型值的错误漏掉不位于边界或典型值的错误 边界不易确定边界不易确定

Page 33: Module 2.  软件测试技术

范围测试典型案例范围测试典型案例 三角型问题三角型问题 输入:输入: a, b, c – a, b, c – 分别为三角形的三个边长值分别为三角形的三个边长值 输出:该三角形为等边、等腰、或不等边输出:该三角形为等边、等腰、或不等边

如何设计测试用例?如何设计测试用例? 选择什么样的输入值选择什么样的输入值

Page 34: Module 2.  软件测试技术

模糊边界问题模糊边界问题 理论上说,等价类划分的任务是将输入分类成相理论上说,等价类划分的任务是将输入分类成相互独立并排斥的范围。互独立并排斥的范围。 3D3D 动画游戏动画游戏

对显卡的要求对显卡的要求 处理速度处理速度 画面效果画面效果 兼容性兼容性

必须测试游戏程序可支持的显卡必须测试游戏程序可支持的显卡

Page 35: Module 2.  软件测试技术

模糊边界问题(续)模糊边界问题(续) 如何从数目众多的显卡中选出典型的测试对象?如何从数目众多的显卡中选出典型的测试对象? 分类的思路分类的思路

市场占有率市场占有率 时间范围时间范围 品牌、驱动品牌、驱动 工业标准、芯片工业标准、芯片 支持的操作系统支持的操作系统

Page 36: Module 2.  软件测试技术

划分等价类划分等价类 设备兼容性测试显示了多维空间无法明确划分的情设备兼容性测试显示了多维空间无法明确划分的情况。况。 范围测试成功的关键是记住“分区只是一种抽样策范围测试成功的关键是记住“分区只是一种抽样策略”。它的目标是从大量潜在的测试中,选出最为略”。它的目标是从大量潜在的测试中,选出最为合理并有价值的几个代表。合理并有价值的几个代表。 好的抽样策略依赖于我们对具体领域的了解,而不好的抽样策略依赖于我们对具体领域的了解,而不仅仅是说明书。仅仅是说明书。 如果你知道多种使程序出错的方法,那么对每一种如果你知道多种使程序出错的方法,那么对每一种错误,寻找最有可能使错误产生的设备(型号、版错误,寻找最有可能使错误产生的设备(型号、版本)。本)。

Page 37: Module 2.  软件测试技术

划分等价类划分等价类 客户的问题:客户的问题: ““ 等价类方法对那些要求支持所有等价类方法对那些要求支持所有 OEMOEM 系统、所有声系统、所有声卡和显卡、所有操作系统、及所有技术(例如卡和显卡、所有操作系统、及所有技术(例如 DirectX DirectX 33 和和 55 )的人非常有用。)的人非常有用。 那么测试人员怎样才能保证他的等价类表可以提供很那么测试人员怎样才能保证他的等价类表可以提供很好的覆盖率?”好的覆盖率?”

令人失望但真实的回答:令人失望但真实的回答: ““即使分析和执行的过程非常好,我们也很可能错过即使分析和执行的过程非常好,我们也很可能错过一个可能造成缺陷的设备或驱动,或它们的组合。”一个可能造成缺陷的设备或驱动,或它们的组合。”

Page 38: Module 2.  软件测试技术

模式:规格说明测试模式:规格说明测试 检查产品满足所有规格、需求文档中的每一条陈检查产品满足所有规格、需求文档中的每一条陈述。述。 检查用户手册,安装步骤,操作范例。检查用户手册,安装步骤,操作范例。 优点优点

彻底分析每个被测功能项彻底分析每个被测功能项 避免向客户传递虚假或误导信息,减少支持成本避免向客户传递虚假或误导信息,减少支持成本 //客客户申告户申告

弱点弱点 未考虑交互影响未考虑交互影响 任何没有列入规格说明、和处理不当的问题任何没有列入规格说明、和处理不当的问题

Page 39: Module 2.  软件测试技术

没有规格说明怎么办?没有规格说明怎么办? 所有存在的文档所有存在的文档 内部版本的软件变更备忘录内部版本的软件变更备忘录 用户手册草稿(或旧版本)用户手册草稿(或旧版本) 有关产品的文章有关产品的文章 公布的样式指南或公布的样式指南或 UIUI标准标准 第三方产品兼容性测试系列第三方产品兼容性测试系列 公布的规范公布的规范 内部备忘录(项目经理给工程师的功能描述)内部备忘录(项目经理给工程师的功能描述) 采访参与上一个版本开发的人员采访参与上一个版本开发的人员 查看旧版本的客户电话记录,查看现场发现的缺陷查看旧版本的客户电话记录,查看现场发现的缺陷 易用性测试结果易用性测试结果 BetaBeta 测试结果测试结果

Page 40: Module 2.  软件测试技术

没有规格说明怎么办?没有规格说明怎么办? 市场演示,产品概念推销市场演示,产品概念推销 缺陷报告及回复缺陷报告及回复 工程师对产品的审核会工程师对产品的审核会 个人采访个人采访

开发负责人开发负责人 技术写作人员技术写作人员 客户服务客户服务 领域专家领域专家 项目经理项目经理

察看察看 headerheader 文件,源代码,数据库表定义文件,源代码,数据库表定义 原型,实验室有关原型的记录原型,实验室有关原型的记录

Page 41: Module 2.  软件测试技术

模式:风险测试模式:风险测试 从可能发生的问题(风险)出发,设计测试从可能发生的问题(风险)出发,设计测试 ““ 先找最大的缺陷”先找最大的缺陷” 风险测试实例风险测试实例

失败模式和影响分析失败模式和影响分析 从预报的缺陷清单中抽取测试用例从预报的缺陷清单中抽取测试用例 压力测试,安全性测试压力测试,安全性测试 测试预期的或担心的错误测试预期的或担心的错误

Page 42: Module 2.  软件测试技术

风险测试风险测试 优点优点 测试作用大测试作用大 直观的测试直观的测试

弱点弱点 没有识别或想像到的风险没有识别或想像到的风险

Page 43: Module 2.  软件测试技术

风险测试风险测试 主要任务主要任务 识别风险因素(系统发生故障的情形)识别风险因素(系统发生故障的情形) 对每一种风险因素,设计有足够能力对付它的测试对每一种风险因素,设计有足够能力对付它的测试 评估风险测试的覆盖率,查找测试工作的漏洞评估风险测试的覆盖率,查找测试工作的漏洞 评估测试结果和发现的缺陷,判断这些测试所针对的评估测试结果和发现的缺陷,判断这些测试所针对的风险是什么,考虑是否有更有效的测试方法。风险是什么,考虑是否有更有效的测试方法。

Page 44: Module 2.  软件测试技术

哪里有风险?哪里有风险? 质量属性质量属性 能力能力 可靠性可靠性 易用性易用性 性能性能 易安装性易安装性 兼容性兼容性 可支持性可支持性 可测试性可测试性 可移植性可移植性 可维护性可维护性 ……

每一个质量属性都包含一个风险类别 ,例如:“系统不可靠的风险”

Page 45: Module 2.  软件测试技术

哪里有风险哪里有风险 从公布的缺陷统计和缺陷分类中,寻找你感兴趣从公布的缺陷统计和缺陷分类中,寻找你感兴趣的缺陷。的缺陷。 从清单中找出一个缺陷从清单中找出一个缺陷 分析你的软件是否会出现这个缺陷分析你的软件是否会出现这个缺陷 如果从理论上分析被测系统可能存在这个缺陷,思考如果从理论上分析被测系统可能存在这个缺陷,思考如何把它找出来如何把它找出来 思考这个缺陷存在的可能性有多大,及它的严重性思考这个缺陷存在的可能性有多大,及它的严重性 针对这类缺陷设计一个或多个测试针对这类缺陷设计一个或多个测试

公布的缺陷信息往往是过时的,且与你的被测系公布的缺陷信息往往是过时的,且与你的被测系统相差很大。应逐步积累并建立自己的缺陷模式。统相差很大。应逐步积累并建立自己的缺陷模式。

Page 46: Module 2.  软件测试技术

哪里有风险?哪里有风险? 需求:不完整、不正确、不清楚需求:不完整、不正确、不清楚 新东西:新功能可能出错新东西:新功能可能出错 新技术:新的概念可能引发新错误新技术:新的概念可能引发新错误 学习曲线:由于无知或习惯而造成的错误学习曲线:由于无知或习惯而造成的错误 修改:变更可能会破坏旧的代码修改:变更可能会破坏旧的代码 仓促的工作:经费和时间不足造成低质量工作仓促的工作:经费和时间不足造成低质量工作 疲劳的程序员:长时间的持续工作造成低效和错疲劳的程序员:长时间的持续工作造成低效和错误误 ……

Page 47: Module 2.  软件测试技术

模式:情景测试模式:情景测试 模拟真实使用情景的测试模拟真实使用情景的测试 情景测试实例情景测试实例

依照商业规范、客户数据、或竞争对手的结果,对产依照商业规范、客户数据、或竞争对手的结果,对产品进行评估测试品进行评估测试 生命周期测试生命周期测试

特点特点 很现实(来自真实用户或竞争对手的情形)很现实(来自真实用户或竞争对手的情形) 测试通过或失败的判定很明确测试通过或失败的判定很明确 测试覆盖多个特征或功能测试覆盖多个特征或功能 每个测试都关系到某些涉众(每个测试都关系到某些涉众( stakeholderstakeholder )的利益)的利益

Page 48: Module 2.  软件测试技术

情景测试情景测试 优点优点 复杂、真实的事件。可以处理那些不易模拟的情形。复杂、真实的事件。可以处理那些不易模拟的情形。 能暴露随时间发展而发生的问题能暴露随时间发展而发生的问题

弱点弱点 单个功能失败可以使测试效率降低单个功能失败可以使测试效率降低 必须仔细考虑测试的覆盖率必须仔细考虑测试的覆盖率

Page 49: Module 2.  软件测试技术

构造情景的方法构造情景的方法 目标驱动:某人想得到 目标驱动:某人想得到 XX。他怎么能得到 。他怎么能得到 XX?? 序列驱动:某人(或系统)通常按照某个顺序完序列驱动:某人(或系统)通常按照某个顺序完成任务 成任务 XX 。完成 。完成 X X 所要经历的常见顺序是什么?所要经历的常见顺序是什么? 交易驱动:我们想完成一桩交易,如开银行帐户交易驱动:我们想完成一桩交易,如开银行帐户或发送信息。完成这个交易的步骤,数据,输出或发送信息。完成这个交易的步骤,数据,输出和显示是什么?和显示是什么? 从竞争对手的产品中获取思路:文档,广告,帮从竞争对手的产品中获取思路:文档,广告,帮助等。所有关于如何最好或最新颖地使用产品的助等。所有关于如何最好或最新颖地使用产品的途径。我们的产品如何完成这些事情?途径。我们的产品如何完成这些事情?

Page 50: Module 2.  软件测试技术

构造情景的方法构造情景的方法 竞争对手的输出:嗨!看看他们生成的这些漂亮竞争对手的输出:嗨!看看他们生成的这些漂亮的文件。或者,瞧他们能够把语法错误的网页显的文件。或者,瞧他们能够把语法错误的网页显示出来。咱们的产品能吗?示出来。咱们的产品能吗? 客户的表格:这儿有几种客户在业务中使用的表客户的表格:这儿有几种客户在业务中使用的表格,我们的程序能处理(读、填写、显示、确格,我们的程序能处理(读、填写、显示、确认)它们吗?认)它们吗? 用例分析中提到的情景用例分析中提到的情景 XPXP开发过程中的客户故事开发过程中的客户故事

Page 51: Module 2.  软件测试技术

电视连续剧法电视连续剧法 基于实际生活经验构造情景,即用户基于实际生活经验构造情景,即用户 //客户的经客户的经验。验。 夸大其中的每一个方面:夸大其中的每一个方面:

例如,对每一个变量,输入一个极端的值例如,对每一个变量,输入一个极端的值 例如,如果一个情景包含一个重复的环节,那就重复例如,如果一个情景包含一个重复的环节,那就重复很多很多次很多很多次 将测试用例所处的环境设置得很糟糕(减少内存,减将测试用例所处的环境设置得很糟糕(减少内存,减少硬盘空间,网络故障,打印机分辩率低,视频分辨少硬盘空间,网络故障,打印机分辩率低,视频分辨率低,等等)率低,等等) 不要忘了所有可能发生问题的情形!不要忘了所有可能发生问题的情形!

将所有元素包含在一个“真实”的故事中。将所有元素包含在一个“真实”的故事中。

Page 52: Module 2.  软件测试技术

模式:组合测试模式:组合测试 系统化地对测试变量进行合理组合系统化地对测试变量进行合理组合 为使某些缺陷发生(或重现),你必须有意识地控制为使某些缺陷发生(或重现),你必须有意识地控制两个或多个变量的值。两个或多个变量的值。 将数目众多的组合减少到合理的程度将数目众多的组合减少到合理的程度

组合测试实例组合测试实例 组合多个变量的边界值组合多个变量的边界值 组合多个测试组合多个测试 ““因果图”测试因果图”测试

优点优点 可以用很少的测试达到很高的测试覆盖率可以用很少的测试达到很高的测试覆盖率

弱点弱点 可信度可信度

Page 53: Module 2.  软件测试技术

组合测试实例组合测试实例 一个汽车保险公司的保险购买系统一个汽车保险公司的保险购买系统 保险的档次分为:保险的档次分为:

11类(高风险)类(高风险) 22类(中等风险)类(中等风险) 33类(低风险)类(低风险)

系统根据用户的年龄及驾龄,判断应给予哪一类系统根据用户的年龄及驾龄,判断应给予哪一类的保险。的保险。

Page 54: Module 2.  软件测试技术

组合测试实例组合测试实例 保险公司政策保险公司政策 年龄 年龄 < 18< 18,驾龄不计 :,驾龄不计 : 拒绝服务拒绝服务 18 <= 18 <= 年龄 年龄 < 22< 22 ,且 驾龄 ,且 驾龄 < 1 < 1 : : 11类类 18 <= 18 <= 年龄 年龄 < 22< 22 ,且 ,且 1<= 1<= 驾龄 :驾龄 : 22类 类 22 <= 22 <= 年龄 年龄 < 55< 55,且 驾龄 ,且 驾龄 < 1 < 1 : : 11类类 22 <= 22 <= 年龄 年龄 < 55< 55,且 ,且 1<= 1<= 驾龄 驾龄 < 3 < 3 :: 22类 类 22 <= 22 <= 年龄 年龄 < 55< 55,且 ,且 3<= 3<= 驾龄 :驾龄 : 33类类 55 <= 55 <= 年龄 年龄 < 75< 75,且 驾龄 ,且 驾龄 < 1 < 1 : : 11类类 55 <= 55 <= 年龄 年龄 < 75< 75,且 ,且 1<= 1<= 驾龄 :驾龄 : 22类 类 75 <= 75 <= 年龄 ,驾龄不计 :年龄 ,驾龄不计 : 拒绝服务拒绝服务

Page 55: Module 2.  软件测试技术

组合测试实例组合测试实例 组合表组合表

Test 9Test 8Test 7

………Test 62219Test 52118Test 410.819Test 310.818Test 2

Deny317Test 1期望输出驾龄年龄测试用例

Page 56: Module 2.  软件测试技术

模式:探索测试模式:探索测试 测试文档缺少或不足的软件时,测试人员必须在测试文档缺少或不足的软件时,测试人员必须在测试的过程中学习产品,及测试用例测试的过程中学习产品,及测试用例 //策略可能策略可能发现的缺陷。发现的缺陷。 边学边计划,边测试边学边计划,边测试 探索测试实例探索测试实例

对整个产品进行熟练的探索测试对整个产品进行熟练的探索测试 游击式测试(对某个方面进行一段苛刻的测试)游击式测试(对某个方面进行一段苛刻的测试) 紧急测试紧急测试 第三方构件测试第三方构件测试 故障排除故障排除 //发现缺陷后的补充测试发现缺陷后的补充测试

Page 57: Module 2.  软件测试技术

探索测试探索测试 在同一时间段里:在同一时间段里: 了解产品了解产品 了解市场了解市场 了解导致产品失败的途径了解导致产品失败的途径 了解产品弱点了解产品弱点 学习如何测试产品学习如何测试产品 测试产品测试产品 报告问题报告问题 要求修复要求修复 在对产品已有了解的基础上,设计新测试在对产品已有了解的基础上,设计新测试

Page 58: Module 2.  软件测试技术

探索测试探索测试 优点优点 关注用户,关注风险关注用户,关注风险 利用测试者的能力利用测试者的能力 应变能力强应变能力强 可以避免重复的分析和测试可以避免重复的分析和测试 高缺陷发现率高缺陷发现率

弱点弱点 知道的越少,错过的缺陷越多知道的越少,错过的缺陷越多 受测试者弱点的限制(可通过好的协调管理减轻受测试者弱点的限制(可通过好的协调管理减轻 对个人能力要求很高,没有监督的初期测试人员不能对个人能力要求很高,没有监督的初期测试人员不能很好完成任务很好完成任务

Page 59: Module 2.  软件测试技术

需要注意的问题需要注意的问题 适应程度会影响发现问题的可能适应程度会影响发现问题的可能 缺乏足够信息会阻碍探索缺乏足够信息会阻碍探索 昂贵或困难的系统设置可能增加探索的耗费昂贵或困难的系统设置可能增加探索的耗费 探索的反馈环节可能会比较慢探索的反馈环节可能会比较慢 问题可能会重复出现问题可能会重复出现 如果没有完善的测试用例和过程,如果没有完善的测试用例和过程, MTBFMTBF (( MeMean Time Between Failurean Time Between Failure )可能较低)可能较低

Page 60: Module 2.  软件测试技术

探索的风格探索的风格 经验丰富、老练的探索者形成自己特有的风格。经验丰富、老练的探索者形成自己特有的风格。 通过观察这些经验丰富的探索者,可以发现非常通过观察这些经验丰富的探索者,可以发现非常不同的风格。不同的风格。

Page 61: Module 2.  软件测试技术

配对测试(配对测试( Paired TestingPaired Testing)) 与与 XPXP开发模式中的开发模式中的 Paired ProgrammingPaired Programming类似类似 两个测试人员工作结伴完成测试工作两个测试人员工作结伴完成测试工作

自愿结合自愿结合 负责某项测试任务的人,征召一个或多个同伴(每次负责某项测试任务的人,征召一个或多个同伴(每次一人)辅助自己的工作一人)辅助自己的工作

一个测试人员负责操作,另一人负责提供思路、一个测试人员负责操作,另一人负责提供思路、意见、做记录,询问问题,找参考资料,等。意见、做记录,询问问题,找参考资料,等。探索测试模式的推荐方法

Page 62: Module 2.  软件测试技术

配对测试过程配对测试过程 从项目概要出发,选择一个需要化一天或更少时间完成从项目概要出发,选择一个需要化一天或更少时间完成的任务的任务 略述将要进行的一期测试活动略述将要进行的一期测试活动

测试什么测试什么 用什么工具用什么工具 使用什么测试方法使用什么测试方法 可能有哪些风险可能有哪些风险 关注什么样的缺陷关注什么样的缺陷 检查什么文档检查什么文档 期望的结果是什么期望的结果是什么 ……

每期测试活动一般持续每期测试活动一般持续 60 – 9060 – 90 分钟分钟

Page 63: Module 2.  软件测试技术

配对测试的好处配对测试的好处 有利于开发思路,产生建议的活动有利于开发思路,产生建议的活动 启发式,开放式,多维的启发式,开放式,多维的

迫使测试人员解释的思路,或对别人的建议做出反应迫使测试人员解释的思路,或对别人的建议做出反应 交流的过程能够促使更多的想法产生交流的过程能够促使更多的想法产生

鼓励创造性思维鼓励创造性思维 有助于获得更多深入的信息有助于获得更多深入的信息 有助于让一个测试人员集中精力,进行持续的测试。有助于让一个测试人员集中精力,进行持续的测试。

非操作的测试人员可以:非操作的测试人员可以: 收集和记录思路和零星的想法收集和记录思路和零星的想法 在第二台机器上再现某个事件在第二台机器上再现某个事件 获取执行测试所需要的资源:查手册、工具,打电话,找开获取执行测试所需要的资源:查手册、工具,打电话,找开发人员,等等。发人员,等等。

Page 64: Module 2.  软件测试技术

配对测试的好处配对测试的好处 提供缺陷报告的质量提供缺陷报告的质量 重现的可能更大重现的可能更大 所有报告的内容都有第二个人审阅所有报告的内容都有第二个人审阅 对每个设计问题进行合理性检查对每个设计问题进行合理性检查

有效的培训方式有效的培训方式 对新手极有效的培训对新手极有效的培训 不断从别人那里学习新知识不断从别人那里学习新知识 对经验丰富的测试人员快速掌握新领域很有帮助对经验丰富的测试人员快速掌握新领域很有帮助

还有一些技术上的益处还有一些技术上的益处 可以在两台机器上进行同样的测试可以在两台机器上进行同样的测试 人工的负载测试人工的负载测试 易于完成一些需要多角色交互的测试易于完成一些需要多角色交互的测试

Page 65: Module 2.  软件测试技术

一些建议一些建议 应允许初级测试人员执行操作和发表看法,而不应允许初级测试人员执行操作和发表看法,而不只是做一些杂物。只是做一些杂物。 责任应当明确。配对测试组中的一人应对任务的责任应当明确。配对测试组中的一人应对任务的完成付责任。完成付责任。 有些内向的人可能需要一些独立思考和工作时间,有些内向的人可能需要一些独立思考和工作时间,以准备团队的合作。 以准备团队的合作。 有些人有很强的思维主导性,不愿意接受别人的有些人有很强的思维主导性,不愿意接受别人的意见。需要接受一定的培训。意见。需要接受一定的培训。

Page 66: Module 2.  软件测试技术

测试模式小结测试模式小结 测试模式只是辅助测试人员构思测试的框架,并测试模式只是辅助测试人员构思测试的框架,并不局限于列举的这些。不局限于列举的这些。 模式相互可以重叠,例如你可以采用:模式相互可以重叠,例如你可以采用:

基于规范说明的组合测试基于规范说明的组合测试 基于风险的情景测试基于风险的情景测试 探索式的范围测试探索式的范围测试 ……

最重要的是思考的方式,而不是教条。你可以总最重要的是思考的方式,而不是教条。你可以总结自己的模式,并不断提高。结自己的模式,并不断提高。

Page 67: Module 2.  软件测试技术

黑盒测试技术练习黑盒测试技术练习

Page 68: Module 2.  软件测试技术

Broadband GatewayBroadband Gateway

互联网服务器

ISP Router

用户电脑

被测系统

Page 69: Module 2.  软件测试技术

规格说明及相关信息规格说明及相关信息 具有具有 44 个个 10/100Base-T Ethernet10/100Base-T Ethernet端口,可与端口,可与 PCPC网卡相连网卡相连 LANLAN侧支持侧支持 DHCPDHCP协议,可给协议,可给 PCPC分配动态分配动态 IPIP WANWAN侧通过一个宽带口与侧通过一个宽带口与 ISPISP路由器相连,最高可支持双方路由器相连,最高可支持双方向速率向速率 1.5Mbps1.5Mbps WANWAN侧支持侧支持 Network Address TranslationNetwork Address Translation(( NATNAT)协议)协议 有一个电源开关有一个电源开关 RouterRouter启动后,自动与启动后,自动与 ISP RouterISP Router 取得连接,获得取得连接,获得 WANWAN侧侧IPIP 地址、默认网关地址、及地址、默认网关地址、及 DNSDNS 。。 用户电脑可同时通过该用户电脑可同时通过该 RouterRouter 访问互联网,进行上传及下访问互联网,进行上传及下载载 前面板有三个指示灯,分别显示前面板有三个指示灯,分别显示

电源开启,电源开启, ISPISP连接,网络数据活动(连接,网络数据活动(WANWAN侧连接)侧连接)

Page 70: Module 2.  软件测试技术

规格说明及相关信息规格说明及相关信息 需要在一台机器上安装管理软件,并通过需要在一台机器上安装管理软件,并通过 EthernetEthernet连连接在接在 RouterRouter 上设置以下参数:上设置以下参数: LAN IPLAN IP 地址范围,默认为:地址范围,默认为: 192.168.0.1 – 192.168.0.255192.168.0.1 – 192.168.0.255 RouterRouter的的 LANLAN端端 IPIP 地址,默认为:地址,默认为: 192.168.0.1192.168.0.1 管理员名称和密码,默认为:管理员名称和密码,默认为: admin/1234admin/1234 可以启动防火墙功能,进一步进行设置(略)可以启动防火墙功能,进一步进行设置(略)

用户可通过管理软件查看网络使用情况用户可通过管理软件查看网络使用情况 LANLAN侧 侧 IP IP 分配分配 WANWAN侧侧 IPIP 及及 DNSDNS 信息信息 与与 ISPISP连接的实际带宽连接的实际带宽

Page 71: Module 2.  软件测试技术

分组练习分组练习 分别按照下面模式设计测试用例分别按照下面模式设计测试用例 规范说明模式规范说明模式

根据前面的说明,及你对根据前面的说明,及你对 RouterRouter的了解,分析被测系统可能的了解,分析被测系统可能具备的功能具备的功能 对每个功能,设计可能发现缺陷的测试用例对每个功能,设计可能发现缺陷的测试用例

风险模式风险模式 列出被测系统可能出现的问题(风险)列出被测系统可能出现的问题(风险) 对每种可能的问题,设计相应的测试用例对每种可能的问题,设计相应的测试用例

情景模式情景模式 构想被测系统可能经历的情景,包括每一种情景中可能出现的构想被测系统可能经历的情景,包括每一种情景中可能出现的“意外”“意外” 设计一组情景的测试用例设计一组情景的测试用例

Page 72: Module 2.  软件测试技术

测试练习分析测试练习分析 对每个测试用例,分析 – 对每个测试用例,分析 – 可能发现的问题可能发现的问题 是否有其它的方法发现同样问题?是否有其它的方法发现同样问题? 哪种更有效哪种更有效

汇总几种模式所产生出的测试,分析 – 汇总几种模式所产生出的测试,分析 – 各模式的长短处各模式的长短处 相互补充能力相互补充能力

Page 73: Module 2.  软件测试技术

回顾回顾软件测试技术

静态测试 动态测试

代码走查 代码审查 代码评审 黑盒测试 白盒测试

规范说明测试 情景测试 探索测试 语句覆盖 分支覆盖 路径覆盖范围测试 风险测试

Page 74: Module 2.  软件测试技术

End of Module 2.End of Module 2.