第一部分 软件测试综述
第1章 软件测试的背景
1.1 软件缺陷bug的官方定义
至少满足以下5个规则之一才称为发生了一个软件缺陷（software bug）
* 软件未实现产品说明书要求的功能
* 软件出现产品说明书 指明不该出现的错误
* 软件实现了产品说明书未提到的功能（增加测试的工作，甚至可能带来更多缺陷）
* 软件未实现产品说明书虽未明确提及但应该实现的目标
* 软件难以理解、不易使用、运行缓慢或者——从测试员角度看——最终用户会认为不好
1.2 为什么会出现软件缺陷
主要原因：产品说明书 > 设计 > 编码 > 其他
1.3 软件缺陷的修复费用
随时间推移，指数增长。
1.4 软件测试员究竟做什么
软件测试员的目标是
尽可能早地找出软件缺陷并确保其得以修复
第2章 软件开发的过程
2.1 产品的组成部分
2.1.1 软件产品需要投入多少
用于描述制造出来并交付他人的软件产品组件的术语是可交付的部分（deliverable）
客户需求
采取问卷调查、收集软件以前版本反馈信息、收集竞争产品信息、收集期刊评论、收集焦点人群的意见及其他诸多方式。（利用焦点人群的审视软件功能）
产品说明书
客户需求的研究结果只是原始资料。产品说明书综合上述信息以及没有提出但必须要实现的需求，真正定义产品是什么、有哪些功能、外观如何。
进度表
Gantt图表。
软件设计文档
结构文档：描述软件整体设计的文档，包括软件所有主要部分的描述以及相互之间的交互方式
数据流图：表示数据在程序中如何流动的正规示意图
状态转换图：把软件分解为基本状态或者条件的另一种正规示意图，表示不同状态转换的方式
流程图：用图形描述程序逻辑的传统方式
代码注释
测试文档
测试计划(test plan)：描述用于验证软件是否符合产品说明书和客户需求的整体方案。包括质量目标、资源需求、进度表、任务分配、方法等。
测试用例(test case)：列举测试的项目，描述验证软件的详细步骤。
缺陷报告(bug report)：描述执行测试用例找到的问题。通常记录在数据库中
测试工具和自动测试(test tool and automation)：使用自动化测试工具测试软件必须文档记录
度量、统计和总结(metric，statistic，summary)：测试过程的汇总。图形表格报告等形式
2.1.2 软件产品组成
帮助文档、用户手册、样本和示例、标签和不干胶、产品支持信息、图标和标志、错误信息、广告和宣传资料、安装、说明文件等，都需测试。
2.1.3 软件项目成员
项目经理、程序经理、监制人员：编写产品说明书，管理进度，重大决策
架构师、系统工程师：技术专家
程序员、开发人员、代码制作者
测试员、质量保证QA
技术作者、用户协助专员、用户培训专员、手册编写员、文案专员：编制软件产品附带的文件和联机文档
配置管理员、构建员：合成软件包
2.3 软件开发生命周期模式
最常用的4种模式：
1.大爆炸模式：计划、进度、正规开发过程、测试几乎没有，测试员报告发现的问题让客户知道
2.边写边改模式：默认的开发模式。适合原型范例、演示程序等小项目
3.瀑布模式
构思—>分析—>设计—>开发—>测试—>最终产品
非常强调产品定义
各步骤独立无交叉
无法回溯
4.螺旋模式
每一次循环的6个步骤：
确定目标、可选方案、限制条件
明确并化解风险
评估可选方案
当前阶段开发和测试
计划下一阶段
确定进入下一阶段方法
（5.敏捷软件开发/快速原型/极限编程/进化开发）
第3章 软件测试的实质
3.1 测试的原则
3.1.1 完全测试程序是不可能的
主要原因：
输入量太大
输出结果太多
软件执行路径太多
软件说明书是主观的，从旁观者来看是缺陷
如果某些测试条件是重复的、无必要的，或为了节省空间而将其剔除，采用不完全测试。
3.1.2 软件测试是有风险的行为
目标：找到最优测试量
3.1.3 测试无法显示潜伏的软件缺陷
任何情况下都不能保证软件缺陷没有了。
3.1.4 找到的软件缺陷越多，就说明软件缺陷越多
原因：
程序员心情不好
程序员往往犯同样的错误
某些软件测试缺陷其实是冰山一角
3.1.5 杀虫剂怪事
反复使用系统的测试软件最后使软件具有抵抗力。
不断编写不同的、新的测试程序，对程序的不同部分进行测试，找到更多软件缺陷。
3.1.6 并非所有软件缺陷都要修复
没有足够的时间
不算真正的软件缺陷
修复风险太大
不值得修复
3.2 软件测试的术语和定义
3.2.1 精确和准确
取决于产品是什么
准确：命中
精确：聚集
3.2.2 确认和验证
确认：保证软件符合产品说明书
验证：保证软件满足用户要求
3.2.3 质量和可靠性
质量：满足客户要求
可靠性是质量的一个方面
3.2.4 测试和质量保证
软件测试员：尽可能早地找出软件缺陷并确保其得以修复
软件质量保证人员：创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法
第二部分 测试基础
第4章 检查产品说明书
4.1 开始测试
4.1.1 黑盒测试和白盒测试
黑盒测试（功能性测试/行为测试）
软件测试员只需知道软件要做什么，无法看到盒子里的软件如何运行。输入，得到输出。
白盒测试（透明盒测试）
可访问程序员的代码，并通过检查代码的线索来协助测试。
因为要已适应代码操作来制定测试，容易形成偏见和无法进行客观测试。
4.1.2 静态测试和动态测试
静态测试
测试不运行的部分，只是检查和审核
动态测试
使用和运行软件
4.1.3 静态黑盒测试——测试产品说明书
通过询问软件的设计者和编制者甚至可以测试没有写出来的产品说明书。
4.2 对产品说明书进行高级审查
测试产品说明书第一步是站在一个高度上进行审查，找出根本性问题、疏忽或遗漏之处。
4.2.1 假设自己是客户
4.2.2 研究现有的标准和规范
标准比规范更加严格。
公司惯用语和约定、行业要求、政府标准、图形用户界面GUI、安全标准。
软件测试员的任务是观察，“检查”采用的标准是否正确，有无缺漏。
4.2.3 审查和测试类似软件
审查竞争产品时注意的问题：
规模
复杂性
测试性
质量和可靠性
安全性
4.3 产品说明书的低层次测试技术
4.3.1 产品说明书属性检查清单
完整
准确
精确、不含糊、清晰
一致
贴切
合理
代码无关
可测试性
4.3.2 产品说明书用于检查清单
总是、每一种、所有、没有、从不：绝对或肯定的描述。要考虑违反这些情况的用例
当然、因此、明显、显然、必然：意图说服接收假定情况，留意！！！
某些、有时、常常、通常、惯常、经常、大多、几乎：太模糊，无法功能测试
等等、诸如此类、以此类推、例如：以这样的词结束的功能清单无法测试
良好、迅速、廉价、高效、小、稳定：无法量化，无法测试
处理、进行、拒绝、跳过、排除：可能隐藏大量需要说明的功能
如果……那么……（没有否则）：思考如果没有的情况
第5章 带上眼罩测试软件
5.1 动态黑盒测试：带上眼罩测试软件
在没有产品说明书时使用探索测试：了解软件、设计测试、执行测试同时进行。
5.2 通过性测试和失效性测试
通过性测试：确认软件至少能做什么，不会考验其能力。（在设计和执行测试用例时，首先进行通过性测试）
失效性测试/错误强制测试：为了破坏软件而设计和执行的测试用例
5.3 等价类划分
选择测试用例的方法是等价类划分/等价分类：分步骤地把海量（无限）的测试用例集缩减得很小，但过程同样有效。
一个等价类或等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例
目标：把可能的测试缩减到可控制且仍然足以测试软件的小范围内
5.4 数据测试
根据关键原则进行等价类划分。
5.4.1 边界条件
软件运行在计划操作界限的边界的情况
边界条件类型
考虑数值、速度、字符、尺寸等数据类型，考虑最XX等特征，如最大、最小、最长等。
测试边界
边界内部的最后一两个合法的数据点+边界之外一两个非法数据点（第一个数-1/最后一个数+1……）
5.4.2 次边界条件（内部边界条件）
2的幂
建立等价划分时，应考虑等价划分中是否包含2的幂的边界条件。
如在1-1000范围内，为了覆盖任何可能的2的幂的次边界，还要包含靠近4位边界的14、15、16，及靠近字节边界的254、255、256
ASCII表
/—>47
0-9—>48-57
：—>58
A-Z—>65-90
a-z—>97-122
5.4.3 默认、空白、空值、零值和无
建立单独的等价划分
5.4.4 非法、错误、不正确和垃圾数据
数据测试的最后一种类型：垃圾数据。搞破坏！
5.5 状态测试
通过不同方式验证程序的逻辑流程
软件状态：软件当前所处的条件或模式
必须测试程序的状态及其转换
5.5.1 测试软件的逻辑流程
不完全测试
等价划分技术选择状态和分支
建立状态转换图
软件可能进入的每一种独立状态（如果不能判断是否为独立状态，它就可能是，发现不是之后再剔除）
从一种状态转入另一种状态所需的输入和条件
进入或退出某种状态时设置条件及输出结果
减少要测试的状态及转换的数量
方法：
每种状态至少访问一次。
测试看起来是最常见和最普遍的状态转换。
测试状态之间最不常用的分支。
测试所有错误状态及其返回值。
测试随机状态转换。
怎样进行具体测试
确定要测试的状态及其转换之后，就可以定义测试用例。
测试状态及其转包括检查所有的状态变量——与进入和退出状态相关的静态条件、信息、值、功能等。
状态变量也许看不到，却很重要，如文档涂改标志。
5.5.2 失败状态测试
以上的状态测试都属于通过性测试，测试包括审查软件、描绘状态、尝试各种合法可能性、确认状态及其转换正常。
以下是相反的做法，找到测试软件失败的案例
竞争条件和时序错乱
几个事情恰巧挤在一起，由于软件未预料到运行过程会被中断，以致造成混乱。
查看状态转换图中的每一个状态，找出哪些外部影响会中断该状态。考虑要使用的数据没有准备好或者在用到时发生了变化，状态会怎么样。
可能的情况：两个不同程序同时保存和打开同一个文档、共享同一台大演技、通信端口或其他外围设备、当软件处于读取或改变状态时按键或单机鼠标、同时关闭或启动软件的多个实例、同时使用不同的程序访问一个共同的数据库。
重复、压迫和重负
重复测试
不停地启动、关闭程序；反复读写数据或反复选择同一个操作。
主要原因：检查是否存在内存泄漏，如果计算机内存被分配进行某些操作，但是操作完成时没有完全释放，结果时最后程序耗尽了它赖以工作的内存空间。
压迫测试
使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制解调器速率低等，观察软件对外部资源的要求和依赖程度。将支持降到最低限度，尽可能地限制软件的必要条件。
重负测试
与压迫测试相反。尽量提供条件任其发挥，让软件处理可能大的数据文件。最大限度地发掘软件能力，让它不堪重负。
时间也是一种重负测试
以上三种测试应联合使用，同时进行。
5.6 其他黑盒测试技术
5.6.1 像笨拙的用户那样做（无经验用户或新用户）
5.6.2 在已经找到软件缺陷的地方再找找
5.6.3 像黑客一样考虑问题
5.6.4 凭借经验、直觉和预感
第6章 检查代码
6.1 静态白盒测试：检查设计和代码
静态白盒测试/结构化分析：在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找到软件缺陷的过程。
6.2 正式审查
正式审查4个基本要素：
确定问题：出错项目、遗漏项目
遵守规则：代码量、时间、哪些内容要做评价
准备
编写报告
6.2.1 同事审查
6.2.2 走查
更正规化。
审查人员应该在审查之前接到软件拷贝以便检查并编写备注和问题。至少有一位资深程序员。
6.2.3 检验
最正式的审查类型，高度组织化。
6.3 编码标准和规范
标准是建立起来、经过修补和必须遵守的规则，
坚持标准或规范：可靠性、可读性/易维护、移植性
6.3.1 编程标准和规范示例
标准的4个主要部分：标题、标准、解释说明、示例
6.3.2 获取标准
6.4 通用代码审查清单（重点！！！）
6.4.1 数据引用错误
使用未经正确声明和初始化的变量、常量、数组、字符串或记录而导致的软件缺陷。如缓冲区溢出错误。
6.4.2 数据声明错误
不正确地声明或使用变量和常量
6.4.3 计算错误
6.4.4 比较错误
比较和判断错误很可能由于边界条件问题。
6.4.5 控制流程错误
通常由于计算或者比较错误直接或间接造成
6.4.6 子程序参数错误
6.4.7 输入/输出错误
文件读取、接受键盘或鼠标输入以及向打印机或屏幕等输出设备写入错误。
6.4.8 其他检查
第7章 带上X光眼镜测试软件
7.1 动态白盒测试/结构化测试
不仅查看代码运行情况，还包括直接测试和控制软件。包括以下4个部分：
直接测试底层函数、过程、子过程和库，API
以完整程序的方式从顶层测试软件，根据软件运行的了解调整测试用例
从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，强制软件以正常测试难以实现的方式运行
估算执行测试时“命中”的代码量和具体代码，然后调整测试，去掉多余的测试用例，补充遗漏的用例
7.2 动态白盒测试和调试
动态白盒测试：寻找软件缺陷 （属于测试）
调试：修复缺陷（属于编程）
软件测试员应该把问题缩减为能演示软件缺陷的最简化测试用例。
7.3 分段测试
7.3.1 单元测试和集成测试
在底层进行的测试称为单元测试/模块测试。单元测试并修复缺陷后，对模块的组合进行集成测试。不断加入软件片段，直至整个产品（至少是产品的主要部分）在称为系统测试的过程中一起测试。
两条路径：
自底向上：编写测试驱动模块，调用正在测试的模块。测试驱动模块以和将来真正模块相同的方式挂接，向测试的模块发送测试用例数据，接受返回结果，验证结果是否正确。测试驱动模块可以代替实际软件，对底层模块进行更有效的测试。
自顶向下：测试桩向处于测试的模块发送数据
7.3.2 单元测试示例
在进行白盒测试之前，一定要根据说明书建立黑盒测试用例。如果先从白盒角度建立而是用例，检查代码，就会偏向于以模块工作方式建立测试用例。
根据白盒只是增减测试用例其实是根据程序内部信息对等价划分的进一步提炼。
7.4 数据覆盖
7.4.1 数据流 data flow
数据流覆盖：在软件中完全跟踪一批数据
7.4.2 次边界
7.4.3 公式和等式
7.4.4 错误强制
可以利用调试器来强制赋值。
强制显示错误提示信息
好处：迫使软件中的所有错误提示信息显示出来。
7.5 代码覆盖
代码覆盖：测试程序的状态以及程序流程
调试器单步执行程序查看代码
对大多数程序进行代码覆盖测试要用到代码覆盖率分析器的专用工具。
代码覆盖率测试挂接在正在测试的软件中，当执行测试用例时在后台执行。利用测试数据可看出：
测试用例没有覆盖软件的哪些部分。
哪些测试用例是多余的。
为了使覆盖率更好，需要建立什么样的新测试用例。
若测试用例覆盖了软件90%而未发现任何软件缺陷，有可能质量好，也有可能是由于杀虫剂现象，增加新的测试可能会暴露余下10%具有非常多的缺陷。
7.5.1 程序语句和代码行覆盖
保证程序中每一条语句最少执行一次
7.5.2 分支覆盖
路径覆盖：试图覆盖软件中的所有路径
路径测试最简单的形式为分支覆盖测试
代码覆盖100%不等于测试了所有分支！
7.5.3 条件覆盖
条件覆盖测试将分支语句的条件考虑在内。
第三部分 运用测试技术
第8章 配置测试
8.1 配置测试综述
配置测试：使用各种硬件来测试软件运行的过程
Windows的PC配置的可能性：
个人计算机、部件（系统主板、部件板卡、其他内部设备：磁盘驱动器、CD-ROM驱动器、DVD读写器等构成）、外设、接口、可选项和内存、设备驱动程序（所有不见和外设通过设备驱动程序的底层软件与操作系统和软件应用程序通信）。
准备开始进行软件的配置测试需要考虑哪些配置与程序的关系最密切
8.1.1 分离配置缺陷
方法：在另外一台有完全不同配置的计算机上一步步执行导致问题的相同操作。若缺陷没有产生，就极有可能是特定的配置问题，在独特的硬件配置下才会暴露出来。
无论问题出现在哪里，解决问题都是开发小组的责任。
8.1.2 计算工作量
等价划分吧配置的可能性减少到尽可能控制的范围。
8.2 执行任务
8.2.1 确定所需的硬件类型
联机注册应考虑调制解调器和网络通信
8.2.2 确定有哪些厂商的硬件、型号和驱动程序可用
确定要测试的设备驱动程序，选择操作系统附带的驱动程序、硬件附带的驱动程序、硬件或者操作系统公司网站上提供的最新的驱动程序
8.2.3 确定可能的硬件特性、模式和选项
8.2.4 将确定后的硬件配置缩减为可控制的范围
8.2.5 明确与硬件配置有关的软件唯一特性
只需要测试与硬件交互时互不相同（不同等价划分）的特性即可
8.2.6 设计在每种配置中执行的测试用例
8.2.7 在每种配置中执行测试
8.2.8 反复测试直到小组对结果满意
8.3 获得硬件
8.4 明确硬件标准
8.5 对其他硬件进行配置测试
第9章 兼容性测试
9.1 兼容性测试综述
检查软件之间是否能够正确地交互和共享信息。交互可以在同时运行于同一台计算机的两个程序之间，或者不同的计算机的两个程序之间。
9.2 平台和应用程序版本
9.2.1 向后和向前兼容
向后兼容：可使用以前版本
向前兼容：看使用未来版本
9.2.2 测试多个版本的影响
在进行兼容性测试之前，需要对所有可能的软件组合等价划分，使其成为验证软件之间正确交互的最小有效集合
决定要选择的程序的原则：
流行程度
年头（近3年）
类型（把软件分为绘图、文字输入、财务、数据库、通信等类型，从每种类型中选择要测试的软件）
生产厂商
对新平台进行兼容性测试，检查现有程序使用它是否正常工作
对新应用程序的兼容性测试，要求在多个平台和多个应用程序上进行
9.3 标准和规范
9.3.1 高级标准和规范
若某个应用声称与某平台兼容，就必须遵守该平台自身的标准和规范。
9.3.2 低级标准和规范
低级兼容性可以视为软件说明书的扩充部分。
9.4 数据共享兼容性
DDE动态数据交换；OLE对象来链接和嵌入。
剪贴和复制是手工操作，DDE和OLE数据可以实时在两个程序之间流动。
第10章 外国语言测试
10.1 使文字和图片有意义
考虑语言、地域等，本地化测试
10.2 翻译问题
10.2.1 文本扩展
好的规则：每个单词长度预计增加100%，语句和短小段落预计增加50%
正确换行？截断？连字符位置？
注意屏幕？窗口？框体？按钮……
对其他语言文本信息分配空间不足
10.2.2 ASCII、DBCS和Unicode
ASCII只能表示256种不同字符
采用代码页，每一种语言采用不同的代码页，实质上使ASCII表的替换
DBCS双字节字符集对超过256个字符的语言支持
但存在兼容性问题。采用Unicode标准。
10.2.3 热键和快捷键
10.2.4 扩展字符
测试扩展字符方法：把扩展字符加入测试的标准字符所在的等价划分中。
10.2.5 字符计算
文字排序
大小写转换
10.2.6 从左向右和从右向左读
10.2.7 图形中的文字
10.2.8 让文本与代码脱离
所有文本字符串、错误提示信息和其他可以翻译的内容都应该存放在与源代码独立的文件中
确保没有任何嵌入的字符串未出现在外部文件
当代码动态生成文本信息时，会发生混乱。不要把字符串直接放进代码也不要代码来连接字符串。
10.3 本地化问题
10.3.1 内容
范例文档、图标、图片、声音、视频、帮助文件、有边界争端的地图、市场宣传文件、包装、Web链接等
10.3.2 数据格式
货币、时间、度量、电话好吗等
10.4 配置和兼容性问题
10.4.1 国外平台配置
键盘、打印机等外设
10.4.2 数据兼容性
所有度量单位和扩展字符转换和处理，可能存在软件缺陷。
10.5 测试量有多大
项目一开始就计划本地化？
本地化版本中是否更改程序代码？
第11章 易用性测试
11.1 用户界面测试
用于与软件程序交互的方式称为用户界面或UI。
11.2 优秀UI由什么构成
7个要素：
11.2.1 符合标准和规范
11.2.2 直观
11.2.3 一致
快速键和菜单选项
术语和命名
听众
如OK和Cancel按钮的位置
11.2.4 灵活
有选择但不要太多
11.2.5 舒适
恰当、错误处理、性能（错误提示信息不该一闪而过，操作缓慢应向用户反馈操作持续时间并显示其正在工作）
11.2.6 正确
市场定位偏差、语言与拼写、不良媒体、WYSIWYG
11.2.7 实用
具体特性是否实用
11.3 为残障人士测试：辅助选项测试
11.3.1 法律要求
11.3.2 软件中的辅助特性
在测试产品的易用性，一定要专门为辅助选项建立测试用例。
第12章 文档测试
12.1 软件文档的类型
readme、包装文字和图形、市场宣传材料、广告及其他插页、授权/注册登记表、EULA（最终用户许可协议）、标签和不干胶条、安装和设置指导、用户手册、联机帮助、指南、向导和CBT（计算机基础训练）、样例、示例和模板、错误提示信息。
12.2 文档测试的重要性
提高易用性、提高可靠性、降低支持费用
12.3 审查文档时要找什么
通用部分：听众、术语、内容和主题
正确性：紧扣事实、逐步执行
检查的内容：图表和屏幕抓取、样例和示例、拼写和语法
12.4 文档测试的实质
第13章 软件安全性测试
13.1 战争游戏——电影
13.2 了解动机
挑战/成名、好奇、使用/借用、恶意破坏、偷窃
13.3 威胁模式分析
构建威胁模式分析小组—>确认价值—>创建一个体系结构总体图（确认在不同技术和证明之间的信任边界、为了访问数据进行授权）—>确认威胁—>记录威胁—>威胁等级评定（恐怖公式DREAD）
13.4 软件安全时一项功能吗？软件漏洞是一个缺陷吗？
失效性测试，像黑客语言攻击被测试的软件
13.5 了解缓存区溢出
数据引用错误
13.6 使用安全的字符串函数
安全字符串函数
13.7 计算机取证
潜在数据：URL记录、Google工具条的自动填充功能、RAM损耗、磁盘损耗
第14章 网站测试
14.1 网页基础
14.2 黑盒测试
14.2.1 文本
网页文本应该当作文本对待，依据“文档测试”所述的方法进行测试。
特别是文字标签，用于替代文字，有声阅读程序通过计算机的扬声器朗读文字标签
通过大幅度缩减浏览器窗口来检查文字布局问题。
14.2.2 超级链接
检查每一个链接确保跳转到正确的目的地，查找孤页。
14.2.3 图片
载入网页时性能如何？网页是否有太多图片？是否正确载入图片？
14.2.4 表单
14.2.5 对象和其他各种简单的功能
14.3 灰盒测试
把软件当作黑盒来测试，但通过简单查看软件内部工作机制作为补充。
14.4 白盒测试
动态内容
数据库驱动的网页
用编程方法创建的网页
服务器性能和加载
安全性
14.5 配置和兼容性测试
硬件平台
浏览器软件和版本
浏览器插件
浏览器选项
视频分辨率和色深
文字大小
调制解调器速率
14.6 易用性测试
盲目使用不成熟的新技术
滚动文字、滚动块和不停运行的动画
滚动显示的长页面
非标准的链接颜色（未看过的蓝色，已经看过的红色或紫色）
过期信息
下载时间过长（0.1s赶紧系统反应速度的极限；1s用户思路不间断的极限；10s用户完全丧失兴趣的最长响应时间）
缺少导航支持
孤页（所有网页一定要包含本身所述网站的明确指示，每个网页都应该与主页链接以及它在信息空间结构的位置指示）
复杂的网站地址URL
使用框架
第四部分 测试的补充
第15章 自动测试和测试工具
15.1 工具和自动化的好处
重复执行测试的过程称为回归测试
速度、速率、准确度和精确度、节省资源、仿真和模拟、坚持不懈
有时手工测试是不可替代的。
15.2 测试工具
非入侵式工具：工具仅用于监视和检查软件而不对其进行修改
入侵式工具：工具以任何方式修改了程序代码或控制了操作环境
测试员通常设法使用侵入式尽量小的工具，以减少工具影响测试结果的可能性。
15.2.1 查看器和监视器
代码覆盖率分析器（入侵式工具）
通信分析器（允许查看通过网络或其他通信电缆传输的原始协议数据，只是监听线路提取经过的数据在另一台计算机显示，非入侵式，也成为嗅探器**）
编译器
15.2.2 驱动程序
驱动程序是控制和操作被测试软件的工具。
批处理文件：依照先后顺序执行的程序或命令的一个简单清单
脚本
15.2.3 桩
桩：接收或相应软件发送的数据
当软件需要与外部设备进行通信时经常要用到桩。
桩是仿真器的超集。
15.2.4 压力和负载工具
压力程序可以分别设置内存量、磁盘空间大小、文件数量、及在该机器上运行软件的其他可用资源。当这些值设置为0或近似于0，会使软件执行不同的代码分支以试图处理这种紧迫限制。
负载工具和压力工具相似，为软件创造了用其他方式难以创造的环境条件。
15.2.5 干扰注入器和噪声发生器
类似于压力和负载工具，但行为更具有随机性。
模拟所有由数据中断、噪声或者电缆损坏等因素导致的通信错误。
15.2.6 分析工具
文字处理软件
电子表格软件
数据库软件
文件比较软件
抓屏和比较软件
调试器
二进制-十六进制计算器
秒表
录像机或照相机
15.3 软件测试自动化
15.3.1 宏录制和回放
Mac：Quickeys程序
Windows：Macro Magic程序
回放位置设置为相对于程序窗口比设置为屏幕的绝对位置更好。
15.3.2 可编程的宏
虽然仍然无法验证测试结果，但可以暂停执行，向测试员提示预期结果。
解决录制宏的时序问题。
15.3.3 完全可编程的自动化测试工具
屏幕捕获：若保存的屏幕画面和当前屏幕画面比较两者不同，出现意外，自动化工具会把它标记为软件缺陷
控件值：检查软件窗口中各种控件的值
文本和其他输出
15.4 随机测试：猴子和大猩猩
模拟用户可能的操作的自动化工具称为测试猴子
15.4.1 笨拙的猴子
随机地点击鼠标或敲击按键。 不会进行验证，直至完成循环或软件、操作系统崩溃。可能会暴露内存泄漏等软件缺陷。
15.4.2 半聪明的猴子
增加日志文件
15.4.3 聪明的猴子
有目的的敲，会阅读软件状态转换图。
查找崩溃缺陷、查看数据、检查操作结果、找出其与预期结果的差别
15.5 使用测试工具和自动化的实质
不要过分依赖自动化。
第16章 缺陷轰炸和beta测试
16.1 让别人测试你的软件
16.2 测试共享
在缺陷轰炸中，选择软件中某一个区域，左右测试员集中测试这个区域或这组特性。
确定普通测试是否会遗漏软件缺陷，代码编写质量如何。
16.3 beta测试
软件分发给选定的潜在客户群，让他们在实际环境中使用软件。
16.4 外包测试
配置和兼容性测试、本地化测试
第五部分 使用测试文档
第17章 计划测试工作
17.1 测试计划的目标
软件测试计划是软件测试员与产品开发小组交流的主要方式。
软件测试文档的目的：规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险。
计划是副产品，并非计划过程的根本目的。
17.2 测试计划主题
17.2.1 高级期望
测试计划过程和软件测试计划的目的是什么？
测试的是什么产品？
产品的质量和可靠性目标是什么？
17.2.2 人、地点和事
17.2.3 定义
构造：程序员放在一起需要测试的代码和内容的搜集。测试计划应该定义构造的频率以及预期的质量等级。
测试发布文档TRD：程序员法不的文档。对每一个构造都声明新特性、不同特性、修复问题和准备测试的内容。
alpha版：对少数主要客户和市场进行数量有限的分发，用于演示目的的早期构造。
beta版：想前在客户广泛分发的正式构造。
说明书完成：说明书预计完成并且不再更改的日程安排。
特性完成：程序员不再向代码增加新特性，集中修复缺陷的日期安排。
软件缺陷会议：由测试经理、项目经理、开发经理和产品支持经理组成的团队。
17.2.4 团队之间的信任
17.2.5 哪些要测试，哪些不要测试
17.2.6 测试的阶段
明确每一个预定的测试阶段，并告知项目小组。
17.2.7 测试策略
17.2.8 资源需求
计划资源需求是确定实现测试策略必备条件的过程。考虑人员、设备、办公室和实验室空间、软件、外包测试公司、其他设备
17.2.9 测试员的任务分配
17.2.10 测试进度
采用相对日期的测试进度
17.2.11 测试用例
17.2.12 软件缺陷报告
17.2.13 度量和统计
17.2.14 风险和问题
第18章 编写和跟踪测试用例
18.1 测试用例计划的目标
组织
重要性
跟踪
测试（或者不测试）证实
18.2 测试用例计划综述
18.2.1 测试设计
标识符
要测试的特性
方法：描述测试软件特性的通用方法
测试用例确认：对用于检测特性的具体测试用例的高级描述和引用。不定义实际测试用例值，
通过/失败规则：描述测试特性的通过和失败由什么构成。哪些可以接受，哪些不可以接受。
18.2.2 测试用例
编写用于输入的实际数值和预期输出结果的数值。测试用例还应该明确指出使用具体测试用例产生的测试程序的任何限制。
标识符
测试项
输入说明
输出说明
环境要求
特殊过程要求
用例之间的依赖性
以上是推荐的文档格式，应该当作指南。表达测试用例其他选择：简单列表、大纲、状态表或数据流程图之类的图表。
18.2.3 测试程序
明确指出为实现相关测试设计而操作软件系统和试验具体测试用例的全部步骤
测试程序或测试脚本定义一下内容：
标识符
目的
特殊要求
程序步骤
日志
设置
启动
程序
度量
关闭
重启
终止
重置
偶然事件
18.3 测试用例组织和跟踪
管理和跟踪系统的4中方法：
脑子（不要）
书面文档（非常小的项目）
电子表格
自定义数据库（测试用例管理工具——一种为处理测试用例而专门编程设计的数据库）
第19章 报告发现的问题
19.1 设法修复软件缺陷
不修复软件缺陷的原因：
没有足够的时间
不算真正的软件缺陷
修复风险太大
不值得修复
无效的软件修复报告
基本原则
尽快报告软件缺陷
有效描述软件缺陷
有效软件缺陷的描述：
短小
单一
明显并通用
可再现
在报告软件缺陷时不要做评价
对软件缺陷报告跟踪到底
19.2 分离和再现软件缺陷
不要想当然地接受任何假设
查找时间依赖和竞争条件的问题
边界条件软件缺陷、内存泄漏和数据溢出等白盒问题
状态缺陷仅在特定软件状态中显露出来
考虑资源依赖性和内存、网络、硬件共享的相互作用
不要忽视硬件
19.3 并非所有软件缺陷生来就是平等的
给软件缺陷划分严重性和优先级
严重性：软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度
优先级：修复缺陷的重要程度和紧迫程度
19.4 软件缺陷的生命周期
打开状态：软件缺陷首先被软件测试员发现时，被记录报告并指定给程序员修复
解决状态：程序员修复了程序，报告又指定回到测试员手中
关闭状态：测试员执行验证测试，确认缺陷得到修复
19.5 软件缺陷跟踪系统
19.5.1 标准：测试事件报告
记录软件缺陷
标识符
总结
事件描述
影响
19.5.2 手工软件缺陷报告和跟踪
19.5.3 自动化软件缺陷报告和跟踪
第20章 成效评价
20.1 使用软件缺陷跟踪数据库中的信息
20.2 在日常测试中使用的度量
20.3 常用项目级度量
第六部分 软件测试的未来
第21章 软件质量保证
21.1 质量是免费的
一致性费用：与一次性计划和执行测试相关的全部费用，用于保证软件按照预期方式运行
非一致性费用
内部失败
外部失败
21.2 工作现场的测试和质量保证
21.2.1 软件测试
21.2.2 质量保证
21.2.3 软件测试团队的其他名称
21.3 测试的管理和组织结构
21.4 能力成熟度模型
CMM
1.初始的
2.可重复的
3.定义的
4.可管理的
5.不断优化的
21.5 ISO 9000
ISO国际化标准组织
目标在于开发过程而不是产品
只决定过程的要求是什么，而不管如何达到