读书笔记
1. 只有至少满足下列5个规则之一才称发生了一个Bug：
（1）软件未实现产品说明书（product specification）要求的功能。
（2）软件出现了产品说明书指明不应该出现的错误。
（3）软件实现了产品说明书未提到的功能。
（4）软件未实现产品说明书虽未明确提及但应该实现的目标。
（5）软件难以理解，不易使用，运行缓慢或者--从测试员的角度看--最终用户会认为不好。
2. 软件测试员的目标是尽可能早地找出软件缺陷，并确保其得以修复。
3. 次边界条件：2的幂，ASCII表等
默认值、空白、空值、零值和NULL
4. 测试软件兼容性时选择程序的标准：流行程度、年头、类型、生产厂商。
5. 优秀UI的7个要素：符合标准和规范、直观、一致、灵活、舒适、正确、实用。
6. DREAD Formula：潜在的危害、可反复性、可利用性、受影响的用户、可发现性。
7. Beta测试是将软件分发给选定的潜在客户群，让他们在实际环境中使用软件。Beta测试时寻找配置、兼容性和易用性缺陷的好方法，但对寻找普通软件缺陷表现很差。不能依靠Beta测试来代替实际测试。
8. 测试计划的目的：
规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务，每个任务的负责人，以及与计划相关的风险。
测试计划的最终目标是交流（而不是记录）软件测试小组的意图、期望，以及对要执行的测试任务的理解。重要的是计划过程，而不是产生的结果文档。
产品的质量和可靠性目标必须明确，必须绝对。
9. Alpha版本：意在对少数主要客户和市场进行数量有限的分发、用于演示目的的早期版本。
10. 报告软件缺陷的基本原则：
（1）尽快报告Bug
（2）有效描述Bug
（3）在报告Bug时不要做评价
（4）对Bug跟踪到底，跟踪其生命周期
11. 有效描述Bug：
（1）短小
（2）单一：一个报告只针对一个软件缺陷
（3）明显且通用。使用简明易行的步骤来描述发现Bug的过程，分离Bug
（4）可再现
12. 计划测试用例的4个原则：组织、重复性、跟踪和测试证实。
13. 分离和再现Bug
（1）不要想当然地接受任何假设，记下所做的每一件事
（2）查找时间依赖和竞争条件的问题
（3）查找边界条件、内存泄露和数据溢出问题
（4）状态缺陷仅在特定的软件状态中显露出来，重要的是事件的次序
（5）考虑资源依赖性和内存、网络、硬件共享的相互作用
（6）不要忽视硬件
14. 严重性：Bug的恶劣程度，当用户碰到该缺陷时影响的可能性和程度
1：系统崩溃、数据丢失、数据毁坏、安全性被破坏
2：操作性错误、结果错误、功能遗漏
3：小问题、拼写错误、UI布局、罕见故障
4：建议
15：优先级：修复Bug的重要程度和紧迫程度
1：立即修复，阻止了进一步测试
2：在产品发布前必须修复
3：如果时间允许应该修复
4：可能会修复，但即使有此Bug产品也能发布
16. 常用项目级Bug度量
（1）将Bug按发现的功能区域进行划分
（2）发现的Bug随时间推移的情况
（3）随时间推移累计发现的Bug。Resolved/Fixed Bugs
（4）需标明项目的进度和重大事件
17. 软件质量保证人员的主要职责是检查和评价当前软件开发的过程，找出改进过程的方法，以达到防止软件缺陷出现的目标。
18. 软件测试员不负责软件的质量，质量不是靠测试来解决的。
19. 假设自己是客户；像黑客一样考虑问题。
20. 产品说明书属性检查清单：完整；准确；精确，不含糊；前后一致；贴切；合理；代码无关；可测试性
21. 状态测试的方法：
（1）每种状态至少测试一次
（2）测试最常见和最普遍的状态转换
（3）测试最不常用的分置
（4）测试所有错误状态及其返回值
（5）测试随机状态转换
22. 硬件配置测试：明确与硬件配置有关的特性。
软件兼容性测试：测试程序之间不同的数据流动方式。
23. 网站测试
（1）首先建立状态表，把每个网页当做不同的状态，链接当做状态之间的连接线
（2）通过大幅缩放浏览器窗口来检查文字布局问题
（3）查找孤页，向网页设计人员索要网页清单
24. 半聪明的猴子：记录行为日志，只在被测试软件商运行，具备崩溃辨认能力
聪明的猴子：会阅读软件的状态转换图，能够验证遇到的情况。
（1）软件未实现产品说明书（product specification）要求的功能。
（2）软件出现了产品说明书指明不应该出现的错误。
（3）软件实现了产品说明书未提到的功能。
（4）软件未实现产品说明书虽未明确提及但应该实现的目标。
（5）软件难以理解，不易使用，运行缓慢或者--从测试员的角度看--最终用户会认为不好。
2. 软件测试员的目标是尽可能早地找出软件缺陷，并确保其得以修复。
3. 次边界条件：2的幂，ASCII表等
默认值、空白、空值、零值和NULL
4. 测试软件兼容性时选择程序的标准：流行程度、年头、类型、生产厂商。
5. 优秀UI的7个要素：符合标准和规范、直观、一致、灵活、舒适、正确、实用。
6. DREAD Formula：潜在的危害、可反复性、可利用性、受影响的用户、可发现性。
7. Beta测试是将软件分发给选定的潜在客户群，让他们在实际环境中使用软件。Beta测试时寻找配置、兼容性和易用性缺陷的好方法，但对寻找普通软件缺陷表现很差。不能依靠Beta测试来代替实际测试。
8. 测试计划的目的：
规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务，每个任务的负责人，以及与计划相关的风险。
测试计划的最终目标是交流（而不是记录）软件测试小组的意图、期望，以及对要执行的测试任务的理解。重要的是计划过程，而不是产生的结果文档。
产品的质量和可靠性目标必须明确，必须绝对。
9. Alpha版本：意在对少数主要客户和市场进行数量有限的分发、用于演示目的的早期版本。
10. 报告软件缺陷的基本原则：
（1）尽快报告Bug
（2）有效描述Bug
（3）在报告Bug时不要做评价
（4）对Bug跟踪到底，跟踪其生命周期
11. 有效描述Bug：
（1）短小
（2）单一：一个报告只针对一个软件缺陷
（3）明显且通用。使用简明易行的步骤来描述发现Bug的过程，分离Bug
（4）可再现
12. 计划测试用例的4个原则：组织、重复性、跟踪和测试证实。
13. 分离和再现Bug
（1）不要想当然地接受任何假设，记下所做的每一件事
（2）查找时间依赖和竞争条件的问题
（3）查找边界条件、内存泄露和数据溢出问题
（4）状态缺陷仅在特定的软件状态中显露出来，重要的是事件的次序
（5）考虑资源依赖性和内存、网络、硬件共享的相互作用
（6）不要忽视硬件
14. 严重性：Bug的恶劣程度，当用户碰到该缺陷时影响的可能性和程度
1：系统崩溃、数据丢失、数据毁坏、安全性被破坏
2：操作性错误、结果错误、功能遗漏
3：小问题、拼写错误、UI布局、罕见故障
4：建议
15：优先级：修复Bug的重要程度和紧迫程度
1：立即修复，阻止了进一步测试
2：在产品发布前必须修复
3：如果时间允许应该修复
4：可能会修复，但即使有此Bug产品也能发布
16. 常用项目级Bug度量
（1）将Bug按发现的功能区域进行划分
（2）发现的Bug随时间推移的情况
（3）随时间推移累计发现的Bug。Resolved/Fixed Bugs
（4）需标明项目的进度和重大事件
17. 软件质量保证人员的主要职责是检查和评价当前软件开发的过程，找出改进过程的方法，以达到防止软件缺陷出现的目标。
18. 软件测试员不负责软件的质量，质量不是靠测试来解决的。
19. 假设自己是客户；像黑客一样考虑问题。
20. 产品说明书属性检查清单：完整；准确；精确，不含糊；前后一致；贴切；合理；代码无关；可测试性
21. 状态测试的方法：
（1）每种状态至少测试一次
（2）测试最常见和最普遍的状态转换
（3）测试最不常用的分置
（4）测试所有错误状态及其返回值
（5）测试随机状态转换
22. 硬件配置测试：明确与硬件配置有关的特性。
软件兼容性测试：测试程序之间不同的数据流动方式。
23. 网站测试
（1）首先建立状态表，把每个网页当做不同的状态，链接当做状态之间的连接线
（2）通过大幅缩放浏览器窗口来检查文字布局问题
（3）查找孤页，向网页设计人员索要网页清单
24. 半聪明的猴子：记录行为日志，只在被测试软件商运行，具备崩溃辨认能力
聪明的猴子：会阅读软件的状态转换图，能够验证遇到的情况。
有关键情节透露
