黑盒测试
在过去的测试中，我们常从开发者的视角出发分 析代码和规格说明书。 规格说明书仅能给我们提供一部分风险类型，我 们必须在更广的范围内进行测试。 不同领域的专家能够看到不同的使系统产生缺陷 的机会，并设计出能够引发这些缺陷的测试用例。 跳出框框进行思考和设计，是黑盒测试的精髓。
模式与技术
测试技术是进行测试的方法。 测试模式指用于指导设计测试的思路，一种测试 模式可能会用到一种或多种技术。 设计任何测试需要包含五个方面的内容：
没有规格说明怎么办？
市场演示，产品概念推销 缺陷报告及回复 工程师对产品的审核会 个 项目经理
察看header文件，源代码，数据库表定义 察看header文件，源代码，数据库表定义 原型，实验室有关原型的记录
模式：风险测试
从可能发生的问题（风险）出发，设计测试 “先找最大的缺陷” 风险测试实例
经验丰富的开发人员 和本模块相关的开发人员 测试组和相关人员
审查（Inspection） 审查（Inspection）
由另外一名开发者进行讲解、其他开发者主要按 照Checklist进行提问并填表、本模块开发者回答 Checklist进行提问并填表、本模块开发者回答 问题并记录
不要现场修改
检查要点
检查代码
研究分析代码而不用实际执行
包括可执行的代码和非执行的代码
提供的信息
度量标准 容易产生错误的代码 代码规则的执行 流图和调用图的分析
!
80%的问题是由于20%的代码引起的
复杂度度量
McCabe Halstead 嵌套级别(最大/平均) 嵌套级别(最大/平均)
度量元
规格度量
行数 语句数 注释数 声明数 ……
边界值测试
边界值是一个等价类向另一个等价类过度的点。 程序在边界更容易出错，所以边界值和边界附近的值是最 佳的测试点。
优点
范围测试
可以通过较少的用例检测出最可能发生的错误 很直观的方法，易于普及
弱点
漏掉不位于边界或典型值的错误 边界不易确定
范围测试典型案例
三角型问题
输入：a, 输入：a, b, c – 分别为三角形的三个边长值 输出：该三角形为等边、等腰、或不等边
是否有歧义？ 可验证吗？
例3 如果可能的话，应当根据系统货物编号列 表，在线确认输入的货物编号。
“如果可能的话”是什么意思？
需求检查练习
例4 产品不应该提供将带来灾难性后果的查找 和替换选择。
真正的需求是什么？
例5 系统对标准XYZ 1.4.1的支持是可选的。 系统对标准XYZ 1.4.1的支持是可选的。
代码审核内容
分析容易产生错误的代码: 分析容易产生错误的代码:
控制流分析
非结构化的代码 死代码
数据流分析
未定义的数据的使用 未使用的数据
信息流分析 断言分析
代码审核内容
流图和调用关系图
作为理解代码的帮助 作为审核符合设计的帮助 作为测试设计的帮助 作为调试的帮助
代码规则的执行
针对不同语言的特征 格式和形式 命名规范 度量标准的强制
设计足够的测试用例，覆盖程序中所有可能的路径
黑盒测试
把测试对象看做一个黑盒子
不考虑程序内部的逻辑结构和内部特性 只依据程序的需求规格说明书 检查程序的功能是否符合它的功能说明
Input
Output
黑盒测试
在程序接口上进行测试 主要是为了发现以下错误
是否有不正确或遗漏了的功能? 是否有不正确或遗漏了的功能? 在接口上，输入能否正确地接受? 在接口上，输入能否正确地接受? 能否输出正确的结 果? 是否有数据结构错误或外部信息(例如数据文件) 是否有数据结构错误或外部信息(例如数据文件)访问 错误? 错误? 性能上是否能够满足要求? 性能上是否能够满足要求? 是否有初始化或终止性错误? 是否有初始化或终止性错误?
模式：规格说明测试
检查产品满足所有规格、需求文档中的每一条陈 述。 检查用户手册，安装步骤，操作范例。 优点
彻底分析每个被测功能项 避免向客户传递虚假或误导信息，减少支持成本/ 避免向客户传递虚假或误导信息，减少支持成本/客 户申告
弱点
未考虑交互影响 任何没有列入规格说明、和处理不当的问题
没有规格说明怎么办？
无二义性
会引起歧义吗
可验证性
测试用例怎么写？
实施无关性
需求检查练习
例1 产品必须在固定的时间间隔内提供状态信 息，并且每次时间间隔不得小于60秒。 息，并且每次时间间隔不得小于60秒。
完整吗？ 清晰吗？
例2 分析程序应该能生成HTML标记错误的报告， 分析程序应该能生成HTML标记错误的报告， 从而使HTML初学者可以用它来快速排错。 从而使HTML初学者可以用它来快速排错。
如何设计测试用例？
选择什么样的输入值
模糊边界问题
理论上说，等价类划分的任务是将输入分类成相 互独立并排斥的范围。 3D动画游戏 3D动画游戏
对显卡的要求
处理速度 画面效果 兼容性
必须测试游戏程序可支持的显卡
模糊边界问题（续）
如何从数目众多的显卡中选出典型的测试对象？ 分类的思路
市场占有率 时间范围 品牌、驱动 工业标准、芯片 支持的操作系统
非常有效的质量保证手段
越来越多地被采用
静态分析的主要内容
缺陷产生的原因 检查需求 检查设计 检查代码
其它
编码 需求
设计
检查需求
需求的标准
完整性
是否完整描述一个功能
需求规格说明的标准
完整性
是否包含所有需求 FURPS
正确性
是否正确反应客户要求
可行性 必要性
Gold plating?
一致性
相互矛盾 重复
失败模式和影响分析 从预报的缺陷清单中抽取测试用例 压力测试，安全性测试 测试预期的或担心的错误
优点
测试作用大 直观的测试
风险测试
弱点
没有识别或想像到的风险
主要任务
风险测试
识别风险因素（系统发生故障的情形） 对每一种风险因素，设计有足够能力对付它的测试 评估风险测试的覆盖率，查找测试工作的漏洞 评估测试结果和发现的缺陷，判断这些测试所针对的 风险是什么，考虑是否有更有效的测试方法。
检查代码
通过代码检查能够发现大部分的错误 通过检查代码发现模块中的错误
Discovery activity Faults found / 1000 lines of code 2.5 5.0 10.0 3.0 2.0
Requirem ent review Design review Code review Integration test Acceptance tests
Module 2. 软件测试技术
软件测试基本方法
静态分析 白盒测试 黑盒测试
主要内容
测试模式
范围测试 说明书测试 风险测试 情景测试 组合测试 探索测试
实际练习
什么是静态分析？
不实际运行程序，通过检查和阅读等手段来发现 错误并评估代码质量的软件测试技术。 作用
通过对代码标准及质量的监控提高代码可靠性 尽可能早地通过对源代码的检查发现缺陷 组织代码审核定位易产生错误的模块
客户的问题：
划分等价类
“等价类方法对那些要求支持所有OEM系统、所有声 “等价类方法对那些要求支持所有OEM系统、所有声 卡和显卡、所有操作系统、及所有技术（例如 DirectX 3和5）的人非常有用。 3和 那么测试人员怎样才能保证他的等价类表可以提供很 好的覆盖率？”
令人失望但真实的回答：
“即使分析和执行的过程非常好，我们也很可能错过 一个可能造成缺陷的设备或驱动，或它们的组合。”
所有存在的文档 内部版本的软件变更备忘录 用户手册草稿（或旧版本） 有关产品的文章 公布的样式指南或UI标准 公布的样式指南或UI标准 第三方产品兼容性测试系列 公布的规范 内部备忘录（项目经理给工程师的功能描述） 采访参与上一个版本开发的人员 查看旧版本的客户电话记录，查看现场发现的缺陷 易用性测试结果 Beta测试结果 Beta测试结果
由本模块的开发者进行讲解、回答问题并记录
不要现场修改
检查要点
逻辑错误 代码标准/规范/ 代码标准/规范/风格
审查（Inspection） 审查（Inspection）
开发组、测试组和相关人员(QA、产品经理等) 开发组、测试组和相关人员(QA、产品经理等)联 合进行。 采用讲解、提问并使用Checklist方式进行的查找 采用讲解、提问并使用Checklist方式进行的查找 错误的活动。 以会议的形式，制定目标、流程、规则和结果报 告。 相关资料要在会议前下发并阅读。 参加人员
设计需求 代码标准/规范/ 代码标准/规范/风格 文档的完整性和一致性
基于编码规则
自动化工具
Logiscope LDRA NuMega的 NuMega的CodeReview
基于质量度量
Logiscope McCabe LDRA
如何使静态分析更有效？
必须引入“别人”的眼睛 根据团队及项目的实际情况，设计合理的实施办 法 有准备地进行
Input
Output
白盒测试目标
尽可能高的覆盖率
对程序模块的所有独立的执行路径至少测试一次 对所有的逻辑判定，取“真”与取“假”的两种情况 都至少测试一次 在循环的边界和运行界限内执行循环体
测试内部数据结构的有效性 执行效率
逻辑覆盖
以程序内部的逻辑结构为基础的设计测试用例的 技术 主要包含以下几种情况
静态分析方法
审查：Inspection 审查：Inspection 走查：Walkthrough 走查：Walkthrough 自动化工具
走查（Walkthrough） 走查（Walkthrough）