一、软件测试综述
1.第一章：软件测试的背景
1.1 软件缺陷
只有至少满足下列5个规则之一才称为发生了一个软件缺陷
- 软件未实现产品说明书要求的功能
- 软件出现了产品说明书指明不应该出现的错误
- 软件实现了产品说明书未提到的功能
- 软件未实现产品说明书虽未明确提及但应该实现的目标
- 软件难以理解、不易使用、运行缓慢或者从测试员的角度感觉对用户不友好
要记住：要全面，最重要的是要客观评价，并非所有测试发现的缺陷都要修改
1.2 为何会出现软件缺陷
导致软件缺陷的最大的原因是产品说明书
软件缺陷的第二大来源是设计
剩下的都可以归为一类，就是把误解（把本来正确的）当成缺陷
简单点来说就是开发项目小组没有很好的沟通，为软件做计划是非常重要的，如果没做好，软件缺陷就会出现
要记住：说不出来就做不到
1.3 beta测试
把软件初期版本分发给一小部分客户进行试用就叫beta测试。这样的话，那些被挑选出来代表庞大市场的客户就可能会发现问题从而进行反馈给开发人员。
1.4 软件测试员的工作
软件测试员的目标是尽可能早地找出软件缺陷，并确保其得以修复，以便降低修复成本
2.第二章：软件开发的过程
2.1 较为重要的测试提交清单
- 测试计划：描述用于验证软件是否符合产品说明书和客户需求的整体方案。包括质量目标、资源需求、进度表、任务分配、方法等
- 测试用例：列举测试的项目，描述验证软件的详细步骤
- 缺陷报告：描述执行测试用例找出的问题。
- 测试工具和自动测试
- 度量、统计和总结：测试的汇总，采用图形、表格和报告等形式
2.2 软件开发生命周期模式
软件产品从最初构思到公开发行的过程称为软件开发生命周期模式，以下是四种最常用的模式
- 大爆炸模式：优点是简单，计划、进度安排和正规开发过程几乎没有，所有的时间精力都花在了开发软件和编写代码上。大爆炸模式几乎没有什么测试，有的话也要挤到产品发布前进行。
- 边写边改模式：是项目小组在未刻意采用其他开发模式时默认的开发模式，，边写边改模式适合意在快速制作而且用完就扔的小项目，测试需要陷入无休止的循环往复，几乎每天都能拿到新版本的软件进行测试。
- 瀑布模式：采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时，都需要项目小组组织审查。瀑布模式有三点需要强调：1.瀑布模式非常强调产品的意义。2.瀑布模式各步骤是分立的，没有交叉。3.瀑布模式无法回溯。该模式的目标是在编写代码之前解决所有的未知问题并明确所有细节
- 螺旋模式：总体思想是一开始不必详细定义所有细节。从小开始，定义重要功能，努力实现这些功能。接收客户反馈，然后进入下一个阶段。重复上述操作，直到得到最终产品。每一次循环包括6个步骤：1.确定目标、可选方案和限制条件 2.明确并化解风险 3.评估可选方案 4.当前阶段开发和测试 5.计划下一阶段 6.确定进入下一阶段的方法。软件测试员喜欢该模式，因为通过参与该最初的设计阶段，可以尽早的影响到产品
3.第三章：软件测试的实质
3.1 测试的原则
- 完全测试程序是不可能的，原因有四：输出量太大，输出结果太多，软件执行路径太多，软件说明书是主观的
- 软件测试是有风险的行为：需要针对风险做出明智的抉择，哪些测试重要，哪些不重要
- 测试无法显示潜伏的软件缺陷： 可以报告软件缺陷存在，却不能报告软件缺陷不存在
- 找到的软件缺陷越多，就说明软件缺陷越多
- 并非所有的软件缺陷都需要修复，原因有四：1.没有足够的时间 2.不算真正的软件缺陷 3.修复的风险太大 4.不值得修复
- 什么时候才叫缺陷难以说清（回顾一下第一章所述的软件缺陷定义规则）
- 产品说明书从没有最终版本
3.2 软件测试的术语和定义
- 精准和准确
- 确认和验证: 确认是保证软件符合产品说明书的过程；验证是保证软件满足用户要求的过程
- 质量和可靠性：可靠性仅仅是质量的一个方面
- 测试和质量保证(QA)：软件测试的目标是尽可能早地找出软件缺陷，并确保缺陷得以修复。软件质量保证的主要职责是创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法
二、测试基础
1.第四章：检查产品说明书
1.1 黑盒测试和白盒测试
黑盒测试有时又被称为功能性测试或者行为测试。黑盒测试中，软测人员只需要知道软件要做什么，而无法看到盒子里的软件是如何运行的。只要进行一些输入，就能得到某种输出结果，他不知道软件是如何运行的，只知道程序做了什么。
白盒测试有时被称为透明盒测试，可以看到盒子的内部，测试人员根据代码检查结果判断或多或少可能出错的数目，并据此定制测试
1.2 静态测试和动态测试
静态测试是指测试不运行的部分，只是检查和审核，动态测试是指通常意义上的测试，使用和运行软件
1.3 静态黑盒测试和测试产品说明书
测试产品说明书属于静态黑盒测试，软测人员利用书面文档进行静态黑盒测试，认真查找其中的缺陷。
1.4 审查和测试类似软件
了解软件最终结果的最佳方法是研究类似软件，在审查竞争产品的时候要注意以下问题：
- 规模
- 复杂性
- 测试性
- 质量和可靠性
- 安全性
1.5 产品说明书术语检查清单
- 看到绝对或肯定的描述时，需要考虑违法这些情况的用例。例如：总是、每一种、所有、没有、从不
- 一些意图说服你接受假定情况，不要中了圈套。例如：当然、因此、明显、显然、必然
- 太过模糊的话无法测试。例如：某些、有时、常常、通常、惯常、经常、大多、几乎
- 等等、诸如此类、以此类推、例如。以这样的词结束的功能清单无法测试。清单要绝对或解释明确，以免让别人产生迷惑。
- 一些无法量化的词，无法进行测试。例如：良好、迅速、廉价、高效、小、稳定
- 如果…那么…（没有否则）需要想一想如果没有发生咋办
2.第五章：带上眼罩测试软件
2.1 动态黑盒测试
不深入代码细节测试软件的方法称为动态黑盒测试，动态黑盒测试常被称为行为测试，因为测试的是软件在使用过程中的实际行为。这种不必了解软件”盒子“内发生的事情，只需知道输入A输出B得到结果C即可
2.2 测试用例
测试用例是指进行测试的时候使用的特定输入，以及测试软件的过程步骤。
2.3 通过性测试和失效性测试
测试软件有两种基本方法：通过性测试和失效性测试。通过性测试是确认软件至少能做什么，而不会考验其能力。失效性测试是纯粹为了破坏软件而设计和执行的测试用例。
2.4 等价类划分
等价类划分是指分步骤的把海量（无限）的测试用例集减得很小，但过程同样有效。在寻找等价划分的时，考虑把软件具有相似输入、相似输出、相似操作的分在一组，这些组就是等价划分。
2.5 数据测试
2.5.1 边界条件
边界条件是特殊情况，因为编程很容易在边界上产生问题。如果软件测试问题包含确认的边界考虑一下以下可能出现的边界条件：
- 第一个|最后一个
- 最大值|最小值
- 开始|完成
- 超过|在内
- 空|满
- 最短|最长
- 相邻|最远
如果要选择在等价划分中包含哪些数据，就根据边界来选择
2.5.2 边界测试
建立两个等价划分就可以找出更多的软件缺陷。第一个划分包含认为应该正确的数据——在边界内部最后一两个合法的数据点。第二个区间包含认为可能出现错误的数据——边界之外一到两个非法的数据点
提出边界条件时，一定要测试临近边界的有效数据，测试最后一个可能有效的数据，同时测试超过边界的无效数据。
2.5.3 次边界条件
有些边界在软件内部，最终用户几乎看不到，但是软测员工仍有必要进行检查，这样的边界条件就叫次边界条件或者内部边界条件
2.5.4 默认、空白、空值、零值和无
一定要考虑建立处理默认值、空白、空值、零值或者无输入等条件的等价划分，不要把他们与合法情况和非法情况混在一起，而要建立单独的等价划分。
2.5.5 非法、错误、不正确和垃圾数据
数据测试最后一种类型是垃圾数据。这是失效性测试的对象。经过边界测试、次边界测试和默认值测试等通过性测试证实软件能够工作之后，就该进行垃圾数据测试了
2.6 状态测试
软件状态是指软件当前所处的条件或模式，软件测试员必须测试程序的状态及其转换。
2.7 测试软件的逻辑流程
对于软件测试，解决方法是运用等价划分技术选择状态和分支
2.7.1建立状态转移图
状态转换图应该表示出以下项目
- 状态可能进入的每一种状态
- 从一种状态转入到另一种状态所需的输入和条件
- 进入或退出某种状态时的设置条件及输出结果
2.7.2 状态变量
状态变量包括进入和退出状态相关的静态条件、信息、值、功能等。
2.7.3 失效性测试
- 重复测试：不断执行同样的操作。进行这种重复测试的主要原因是检查是否存在内存泄漏
- 压迫测试：使软件在不够理想的条件下运行，例如说内存小，磁盘空间少、CPU速度慢，调制调解器速率低等。
- 重负测试：与压迫测试相反，尽量提供条件任其发挥。eg.让软件处理尽可能大的数据文件。
重复、压迫、重负测试应该联合使用，同时进行，这是找出以其他方式难以发现的严重缺陷的一个可靠的方法。
3.第六章：检查代码
3.1 静态白盒测试：检查设计和代码
静态白盒测试是指在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找到软件缺陷的过程，有时称为结构化分析。
3.2 正式审查
正式审查就是进行静态白盒测试的过程。
正式审查有4个基本要素：
- 确定问题
- 遵守规则
- 准备
- 编写报告
3.3 通用代码审查清单
- 数据引用错误：使用未经正确声明和初始化的变量、常量、数组、字符串或记录而导致的软件缺陷
- 数据声明错误：不正确地声明或使用变量和常量
- 计算错误：计算无法得到预期结果
- 比较错误：比较和判断错误很可能是因为边界条件问题
- 控制流程错误：编程语言中循环等控制结构未按预期方式工作，通常由计算错误或者比较错误直接或间接造成
- 子程序参数错误：软件子程序不正确的传递数据
- 输入/输出错误
4.第七章：带上X光眼镜测试软件
4.1 动态白盒测试(结构化测试)
动态白盒测试是指利用查看代码功能和实现方式得到的信息来确定哪些需要测试，哪些不需要测试，如何开展测试。
动态白盒测试包括以下4个部分：
- 直接测试底层函数、过程、子程序和库。
- 以完整程序的方式从顶层测试软件
- 从软件或者读取数据变量和状态信息的访问权，以便确定测试与预期结果是否相符。同时，强制软件以正常测试难以实现的方式运行。
- 估算执行测试时“命中”的代码量和具体代码，然后调试测试，去掉多余的测试用例，补充遗漏的用例。
4.2 动态白盒测试和调试
不要把动态白盒测试和调试弄混。动态白盒测试的目标是寻找软件缺陷，调试的目标是修复缺陷。在隔离软件缺陷的位置和原因上两者确实存在交叉现象。
4.3 分段测试
4.3.1 单元测试和集成测试
在底层进行的测试称为单元测试或者模块测试。单元测试经过测试，底层缺陷被找出并修复之后，就集成在一起，对模块的组合进行集成测试。
4.4 代码覆盖测试
代码覆盖测试必须设法进入和退出每一个模块，执行每一行代码，进入软件每一条逻辑和决策分支。代码覆盖测试最简单的形式是利用编译环境的调试器通过单步执行程序查看代码。
4.4.1 代码行覆盖
代码覆盖的最直接形式就称为语句覆盖或者代码行覆盖，目标就是保证程序的每一条语句最少执行一次。误导：可以说即使全部语句全部都执行了，但是不能说走遍了软件的全部路径
4.4.2 分支覆盖(只要执行该分支即可)
试图覆盖软件中的全部路径称为路径覆盖，路径测试最简单的形式称为分支覆盖测试。大多数代码覆盖率分析器将根据代码分支，分别报告语句覆盖和分支覆盖的结果，使软测人云更清楚测试效果。
4.4.3 条件覆盖(需要执行该分支的所有情况)
条件覆盖测试将分支语句的条件考虑在内，主要是针对于较为复杂的条件，需要将所有情况罗列在内。
三、运用测试技术
1.第八章：配置测试
配置测试是指使用各种硬件来测试软件运行的过程
标准windows的pc机的配置可能性：
- 个人计算机
- 部件
- 外设
- 接口
- 可选项和内存
- 设备驱动程序
软测需要确认项目所需的硬件类型，比如应用程序需要打印吗，需要的话就需要测试打印机。如果应用程序要发出声音，就需要测试声卡，如果是照片或图片处理程序，就需要测试扫描仪和数码相机等等。
2.第九章：兼容性测试
软件兼容性测试是指==检查软件之间是否能够正确地交互和共享信息。==交互可以在同时运行于同一台计算机上的两个程序之间，甚至在相隔几千公里、通过因特网连接的不同计算机的两个程序之间进行。
2.1 兼容性测试介绍
兼容性测试主要关注以下方面：
- 操作系统兼容性
- 浏览器兼容性
- 设备兼容性
- 分辨率和屏幕尺寸兼容性
- 网络兼容性
2.2 向后和向前兼容
向前兼容是指可以使用软件的以前版本，向后兼容是指可以使用软件的未来版本
3.第十章：外国语言测试
3.1 使文字和语言有意义
开发软件时，考虑用户的国家和地理位置，使软件适应特定地域特征，照顾到语言、方言、地区习俗和文化的过程称为本地化。测试此类软件称为本地化测试。
3.2 翻译问题
- 文本扩展：把英语翻译成其他语言时，通常会发生长度变长的情况。这时按钮、标题栏、和文本框是否容纳的下是个问题
- ASCII、DBCS和Unicode：Unicode为每一个字符提供唯一编号，无论何种平台、何种程序以及何种语言。
- 热键和快捷键：本地化测试要测试这些键是否工作正常以及检查英文热键和快捷键是否被禁用。
- 扩展字符：英文字母A-Z/a-z之外的字符。找出软件中所有接受字符输入和输出之处，测试扩展字符能否与常规字符一样处理。
- 字符计算：字符排序、大小写转换和拼写检查等。
- 从左向右读和从右向左读：有些文字（阿拉伯和希伯来）是从右向左读的。
- 图形中的文字：要在开发早期找出图形文本软件缺陷，而不是留到最后发现。
- 让文本与代码脱离：不要把字符串直接放在代码中，而是用读取文件的方式显示字符串
3.3 本地化问题
内容
解决本地化问题需要审查的内容：范例文档、图标、图片、声音、视频、帮助文件、有边界争端的地图、市场宣传材料、包装、Web链接
数据格式
单位、日期、电话、大小、度量衡等
3.4 配置与兼容性问题
国外平台配置
在设计等价划分时，不要忘记应该考虑构成平台的所有硬件和软件，包括硬件本身、设备驱动程序和操作系统。
数据兼容性
在应用程序间移动数据时需要改变格式会发生什么，格式会自动转换，还是会提示用户做出判断，还是会显示错误提示还是坚持移动数据并更改单位？
4.第十一章：易用性测试
4.1 优秀UI具备的7要素
- 符合标准和规范
- 直观性：用户界面是否洁净、不唐突、不拥挤，界面的组织和布局合理等等。
- 一致性： 快捷键一般要具有通用性，如F1为系统帮助，还有按钮的位置和等价的按键等等
- 灵活性：灵活的软件实现同意功能状态转换有多种方式，用户愈来愈希望有多种方式实现数据的输入和输出。
- 舒适性： 对于用户的每一步操作，都应有相应的提示，方便用户了解当前的状态的等等。
- 正确性：软件有没有多余的或者遗漏的功能，或者某些功能执行结果与实际需求不符等等
- 实用性：在测试过程中，检查每一功能点的UI是否具有实际实用价值，是否能够有助于用户执行软件相应的功能，否则就被认为实用性不好，为实用性缺陷。
5.第十二章：测试文档
5.1 文档测试的重要性
- 提高易用性
- 提高可靠性
- 降低支持费用
5.2 审查文档时需要找什么
非代码
测试这些部分时，与第4章“检查产品说明书”和第6章“检查代码”所述的静态过程类似。可以视之为技术编辑和技术校对
文档和代码紧密结合
动态测试，利用第5章“戴上眼罩测试软件”和第7章“带上X光测试软件”的技术进行测试
文档是软件驱动
需要像软件其余部分一样进行测试。检查索引表是否完整，搜索结果是否正确。超级链接和热点是否跳转到正确的页面，利用等价划分技术确定尝试哪些测试用例
6. 第十三章：软件安全性测试
6.1 了解黑客进攻动机
- 挑战/成名
- 好奇
- 使用/借用
- 恶意破坏
- 偷窃
6.2 威胁模式分析
6.2.1 威胁模式分析步骤
- 构建威胁模型分析小组
- 确认价值
- 创建一个体系结构总体图
- 分解应用程序
- 确认威胁
- 记录威胁
- 威胁等级评定
6.2.2 威胁等级评定
威胁等级评定是由恐怖公式(DREAD)定义的;
- 潜在的损害
- 可反复性
- 可利用性
- 受影响的用户
- 可发现性
简单用1表示低，2表示种等，3表示高。将此应用到上面五项得到的总和来评估安全等级。
7.第十四章：网站测试
7.1 黑盒测试
在测试网站时，首先应该建立状态表（第5章），把每个网页当作不同的状态，超级链接当作状态之间的连接线。完整的状态图有利于对整个任务更好地进行审视。查找具体网页缺陷的思路：
- 文本：把网页文本当做文档对待，根据文档测试方法进行测试，测试网站上所有与文字有关的部分，千万不要遗漏文字标签
- 超链接：链接可以与文字或图片拴在一起，每一个链接都需要检查，确保它跳转到正确的目的地。超链接一定要明显，文字链接一般有下划线，鼠标经过任何类型的超链接时应该发生变化(常变成手形指针)。注意网站的孤页需要测试。
- 图片：确保所有的图片都能正确的显示。如果图片和文字环绕，要改变浏览器的大小看环绕是否有问题。载入网页是否会因图片数量导致过慢。
- 表单：表单是指网页中用于输入和选择学习的文本框、列表框和其他域。需要关注的有：域的大小正确吗？是否正确接收数据，拒绝错误信息？在最后enter时正确确认了吗？可选域是否真正可选？如果输入9999999999999999999999会怎样？
- 对象和其他简单功能：网页可能包含其它如单击计数器、滚动文本选择框、变换的广告和站内搜索等特性。测试时要根据测试知识具体问题具体解决。需要关注的有：有自己的状态吗？处理数据吗？有范围和边界吗？运用什么测试用例，怎样进行等价划分。
7.2 灰盒测试
灰盒测试把白盒测试和黑盒测试的界限打乱了，仍把软件当做黑盒来测试，但是通过简单查看软件内部工作机制作为补充。网页可以视为灰盒进行测试，在进行黑盒测试时，查看网页背后的HTML语言作为补充测试。
7.3 白盒测试
根据代码内容设计测试用例，一些重要的特性测试：
- 动态内容：根据当前条件变化的文字和图片——例如日期时间、用户喜好或者特定用户操作。
- 数据库驱动的网页：HTML提供Web内容的简单布局，而数据则是从网站服务器上的数据库提取出来插入到网页中。
- 编程方法创建的网页
- 服务器性能和加载
- 安全性
7.4 配置和兼容性测试
测试一个网站，需要考虑可能会影响网站运行和外观的硬件和软件配置。以下是需要考虑的内容清单：
- 硬件平台：MAC机、PC机、PDA、MSNTV还是WIFI手表
- 浏览器软件和版本：web浏览器和版本有很多种，需要查看是否支持
- 浏览器插件
- 浏览器选项
- 视频分辨率和色深：是否支持能在各种屏幕分辨率和颜色模式下显示
- 文字大小：是否调节好还能正常显示
- 调制解调器速率
7.5 易用性测试
一些网站易用性的注意点：
- 盲目使用不成熟的新技术
- 滚动文字、滚动块和不停运行的动画
- 滚动显示的长页面
- 非标准的链接颜色
- 过期信息
- 下载时间过长
- 缺少导航支持
- 孤页
- 复杂的网站地址url
- 使用框架
四、测试的补充
1.第十五章：自动测试和测试工具
1.1 回归测试
==回归测试是指在软件项目中，开发人员在修改了软件的代码以修复已经发现的bug后，测试人员在需要重新测试前面已经测试过的内容，以确认此次修改没有引入新的错误。==回归测试的目的就是检查开发人员在修复已有bug时是否又导致新的bug
1.2 工具和自动化的好处
在使用工具进行自动化测试时，主要有以下几个有点：
速度快；效率高；准确度和精准度高；节省资源；仿真和模拟效果；
1.3 测试工具
非入侵工具：工具仅用于监视和检查软件而不对其进行修改
入侵式工具：工具以任何方式修改了程序代码或者控制了操作环境。
工具的主要分类和使用方式：
- 查看器和监视器:能够看到正常情况下看不到的软件运行的细节
- 驱动程序：控制和操作被测试软件的工具
- 桩：桩和驱动程序本质是相反的，桩不控制或者操作被测试软件，相反，它接受或者响应软件发送的数据
- 压力和负载工具：用于向被测试软件增加压力和负载
- 干扰注入器和噪声发生器：类似于压力和负载工具，但是在行为上更有随机性
- 分析工具
1.4 软件测试自动化
软件测试自动化是启动、执行几乎不用人工干预，它们可以执行测试用例、查找软件缺陷、分析看到的信息、记录结果。
下面是几种不同类型的自动化
- 宏录制和回放
- 可编程的宏
- 完全可变成的自动测试工具
2.第十六章：缺陷轰炸和beta测试
2.1 缺陷轰炸
缺陷轰炸是在一段时间内整个测试小组停下指定的常规测试任务，参与轰炸。在缺陷轰炸中，选择软件中某一区域，所有测试员集中测试这个区域或者这组特性。选择区域可能是软件缺陷聚集之处，看是否还有更多潜伏的问题；也可能是怀疑不存在软件缺陷的区域。
2.2 beta测试
Beta测试 是由软件的
多个用户在一个或多个 用户的实际使用环境下 进行的测试。开发者通常不在测试现场，这是在开发者无法控制的环境下进行的测试。由用户记录下遇到的所有问题，定期向开发者报告。Beta测试 是以模拟真实的使用环境从而发现缺陷的一种测试。
五、使用测试文档
1.第十七章：计划测试工作
1.1 测试计划的目标
软件测试计划是软件测试员与产品开发小组交流意图的主要方式
测试计划只是创建详细计划过程的一个副产品，重要的是计划过程，而不是产生的结果文档，最终目标是交流软件测试小组的意图，期望，以及对将要执行的测试任务的理解。测试计划需要明确在项目中工作的人，他干什么，怎么和他联系。
1.2 计划资源需求
计划资源需求是确定实现测试策略必备条件的过程。在项目期间测试可能用到的任何资源都要考虑到。例如
- 人员
- 设备
- 办公室和实验室空间
- 软件
- 外包测试公司
- 其他配备
2.第十八章：编写和跟踪测试用例
2.1 软件用例计划综述
2.1.1 测试设计
以下是测试设计说明的部分内容：
1.标识符：用于引用和标记测试设计说明的唯一标识符。
2.要测试的特性：测试设计说明所包含的软件特性描述。
1）该部分将明确指出作为主要特性的辅助特性需要间接测试的特征。
2）还要列出不被测试的特征，即计划中由于错误分析包进来的特征。
3.方法：描述测试软件特征的通用方法
4.测试用例确认：对用于检查特性的具体测试用例的高级描述和引用
5.通过/失败规则：描述测试特性的通过和失败由什么构成。
2.1.2 测试用例
以下是测试用例应该包含在内的重要信息：
1.标识符：由测试设计过程说明和测试程序说明引用的唯一标识符。
2.测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更为具体。
3.输入说明：列举送到软件执行测试用例的所有输入内容或条件。
4.输出说明：描述进行测试用例预期的结果
5.环境要求：环境要求是指执行测试用例必备的硬件、软件、测试工具、实用工具、人员等。
6.特殊过程要求：描述执行测试必须做到的特殊要求。
7.用例之间的依赖性
2.1.3 测试程序
以下是测试程序需要定义的内容：
1.标识符：把测试程序与相关测试用例和测试设计捆绑在一起的标识符
2.目的：程序的目的以及将要执行的测试用例的引用信息。
3.特殊要求：执行程序所需的其他程序、特殊测试技术或者特殊设备
4.程序步骤：执行测试的详细描述
日志：用什么方式、方法记录结果和现象
设置：说明如何准备测试
启动：说明用于启动测试的步骤
程序：描述用于运行测试的步骤
度量：描述如何判断结果
关闭：说明由意外原因挂起测试的步骤
重启：如何在恰当的事件启动重启
终止：描述测试正常停止的步骤
重置：说明如何把环境回复到测试前的状态
偶然事件：说明如何处理计划之外的情况
2.2 特别测试
有一种软件测试称为特别测试，描述在没有实际计划下执行测试——没有测试用例计划，有时候甚至没有高级测试计划。特别测试就是测试员坐在软件面前开始乱敲键盘。
3.第十九章：报告发现的问题
3.1 报告软件缺陷的基本原则
- 尽早报告软件缺陷：软件缺陷发现得越早，在进度中留下的修复时间就越多。
- 有效描述软件缺陷
- 短小：只解释事实和演示、描述软件缺陷必须的细节。
- 单一：每一个报告只针对一个软件缺陷
- 快速技巧提示：当出现疑问时，单个地报告软件缺陷。
- 明显并通用：用使用者容易看懂的、简单易行的步骤描述的软件缺陷的一个用例，得到修复的机会比较大。
- 可再现：软件缺陷报告必须展示其按照预定步骤可以使软件达到缺陷再次出现的相同状况。
- 在报告软件缺陷时不要做评价：报告缺陷时需要不带倾向性、个人观点和煽动性。
- 对软件缺陷报告跟踪到底
3.2 繁杂步骤的软件缺陷的一些提示和技巧
- 不要想当然地接受任何假设：记下所做的每一件事——每一个步骤、每一次停顿、每一件工作。
- 查找时间依赖和竞争条件的问题：注意软件缺陷是否只是在特定时间出现，是否取决于输入数据的速度，要考虑时序等等
- 边界条件软件缺陷、内存泄漏和数据溢出等白盒问题可能会慢慢自己显露出来
- 状态缺陷仅在特定软件状态中显露出来
- 考虑资源依赖性和内存、网络、硬件共享的相互作用。
- 不要忽视硬件：与软件不同，硬件可能降级，不按预定方式工作。
4.第二十章：成效评价
4.1 使用软件缺陷跟踪数据库中的信息
用于描述软件项目特定属性评价的术语是 软件度量。
注意：如果项目中使用软件缺陷跟踪数据库，就要和测试经理和项目经理讨论要收集什么信息，如何使用它们，以免出现意外。
4.2 在日常生活中使用的度量、
软件缺陷跟踪数据库最常用的特性（除了输入软件缺陷外）可能就是执行查询，获得感兴趣的软件缺陷清单。
这个软件缺陷数据库的查询构造器和其他大多数数据库一样，利用逻辑与、逻辑或和括号构建特定的查询请求。
4.3 常用项目级度量
- 平均每天发现的软件缺陷数目。
- 目前发现的软件的软件缺陷总数。
- 修复的软件的软件缺陷总数和所发现软件缺陷的比例。
- 严重性1和优先级1的软件缺陷总数和全部发现的软件缺陷总数的比例。
- 从解决状态到关闭状态的时间。
六、软件测试的未来
1.第二十一章：软件质量保证
1.1 质量是免费的
质量的费用分为两类：一致性费用和非一致性费用
- 一致性费用：是指与一次性计划和执行测试相关的全部费用，用于保证软件按照预期方式运行
- 非一致性费用：如果软件缺陷被遗漏并且落到客户手里，结果就是代价昂贵的产品支持电话，可能还需要修复，重新测试和发布软件，更糟糕的情况下，产品召回或者卷入官司。这些外部失败的费用就属于非一致性费用。