读书笔记(十四)核心测试过程：计划，准备和完善

第14章
错误报告
14.1 一个错误报告的过程
错误报告的过程：

步骤序号	步骤内容	完成？
1.	使用结构化，小心谨慎的测试技术运行每个测试
2.	重现任何与期待的行为不符的偏差
3.	通过检查主要的变化的影响来隔离错误，并寻找绕开问题的方法
4.	寻找通用案例，特别是更严重或更令人讨厌的情况
5.	与在相似条件下在这个或以前的测试版本中的系统的行为来比较观察到的异常行为。
6.	总结失败，包括对于顾客或用户的影响。
7.	压缩报告，删除不必要的信息。
8.	表达清楚，删除混淆的，误导的或不精确的用词。
9.	中和处理错误报告，合理和公平地表达意见。
10.	提交错误报告供同行复查，解决发现的所有问题，然后将错误报告检入到错误跟踪系统。

Bug Reporting Process

Step #	Step	Done?
1.	Run each test using structured, careful testing techniques.	¨
2.	Reproduce any deviations from expected behavior.	¨
3.	Isolate the bug by checking the effect of key variations, looking for workarounds as well.	¨
4.	Look for the general case, especially one more severe or objectionable.	¨
5.	Compare the abnormal behavior observed with the behavior of the system under similar conditions on this or previous test releases.	¨
6.	Summarize the failure, including the effect on customers or users.	¨
7.	Condense the report, removing unnecessary information.	¨
8.	Disambiguate, removing confusing, misleading, or imprecise words.	¨
9.	Neutralize the bug report, expressing ideas impartially and fairly.	¨
10.	Submit the bug report to a peer review, resolve any problems found, then enter the bug report into the bug tracking system	¨

1. 结构化-好的错误报告由强有力的，组织化的测试为起点。懒散的测试产生懒散的错误报告。
2. 重现性。
3. 隔离-很多因素可以影响软件的行为，而且这些因素中的一些会影响错误的症状。好的错误隔离给测试人员建立可信度，并给程序员的调试提供了指导。
4. 广义化-第一次发现错误时，看到的症状不是最经常出现的情况。进入深入研究后，试图发现错误如何发生的通用规则。
5. 比较-测试经常覆盖相同的地方，这种情况同时发生在测试人员针对后来的软件版本运行相同的测试，和测试人员运行测试来覆盖相似的地方。
6. 结论-要考虑与每个错误相关的商业风险，作为决定是否要修复它的一部分。
7. 压缩-最好的错误报告既不是秘密的注解，也不是单调的，冗长的，空洞无力的文档。只使用需要的词，只描述真正的与报告相关的步骤和信息。
8. 明确化-删除混淆和误导性的词。
9. 中和-在错误报告中镇定地和耐心地表达自己的意见。
10. 复查-同行评审，审查，浏览以及类似的或是强大的工具，用于及早地探测所有类型的文档中的缺陷。
14.2 在大构建中的错误
14.3 超越对于失败的描述
14.4 认识好的错误报告的过程
14.4.1 有效的交流有用的信息
l 测试历史---除非在测试用例之间重新启动用来运行测试的整个网络，始终存在这样的一种机会，以前运行的测试能够影响当前错误的行为。
l 屏幕截图（屏幕抓图）
l 数字图像
l 内存中的内容（内核转存）：一些系统可以被配置为当系统探测到内部的错误时，会保存内存中所有内容，包括寄存器，到一个特定的文件中。
l 内部跟踪信息。
l 工作文件（草稿文件）-一些系统在操作的过程中生成可运行的文件。这些文件经常存放在特别的目录中。
l 错误日志—有些程序在崩溃时会生成错误的日志。

14.4.2 每个报告描述一个症状，并给每个症状提交一份报告
14.4.3 明确地区分测试和调试
14.5 处理挑战
当运行的测试看上去与现实的顾客使用情况并不相关时，测试人员应该查找方法来将发现的任何错误与真实的使用情况联系起来。
鼓励测试人员采取主动角色，区分错误，属性和“那又怎么样”，而不是仅仅在错误跟踪数据库中堆积错误报告，而忽视来自程序员或在项目组中的其他人员关于在信号中出现了如此多噪声的抱怨。

14.5．2 处理偶然修复的错误和不可重现的症状
14.5.3 将噪声从信号中分离出来
14.5.4 建立与程序员之间的信任和可信度
1. 维护一个项目范围内，面向服务的模式；
2. 在与程序员，经理和其他项目组成员讨论错误报告时保持冷静的头脑；
3. 用开发的头脑来讨论错误报告，接受你可能是错误的可能性，但是也要合理的顾客期待进行辩护；
4. 只提交高质量的错误报告，并对于提高你的错误报告的质量持开放的态度；
5. 在提交和报告错误时要有灵活性；

14.5.5选择正确的错误跟踪工具
14.6 实现改进
1. 首先要改正任何测试人员的不良态度；
2. 错误报告是测试人员提供的最实质性的信息产品；
3. 使用错误跟踪工具；
4. 检查在发现，修复和确认错误已经修复时实际发生的工作流程，并与你当前的错误跟踪工作所允许你做的流程进行比较；
5. 应用一套好的错误报告过程，但是要有灵活性且对优先级敏感；
6. 同行复审错误报告；
7. 考虑引入一种亮度来帮助测试错误报告的质量。