第4章：程序错误分析
测试员要了解如何编写和表达自己的测试结果，以便读者能够真正得到结果。这个过程叫做“程序错误分析”。
经验55-文如其人
错误报告是大多数测试员的主要
工作产品。报告写的越好，测试员的声誉越高。
经验56-测试员的程序错误分析会推动改正所报告的错误
测试员的责任不是保证所有错误都得到改正，而是准确报告问题，使读者能够理解问题的影响。深入研究并写出好的报告，常常对错误改正的可能性产生巨大的影响。
经验57-使自己的错误报告成为一种有效的销售工具
错误报告都是一种推销工具，通过改正这个具体错误而带来质量改进。
销售策略一般包括两个目标：陈述种种好处，使得潜在客户想要它；向销售人员说明预期存在问题，并反驳他们。
经验58-错误报告代表的是测试员
经验59-努力使错误报告有更多的价值
丰富每个错误报告的信息，提高报告的可理解性。
经验60-产品的任何项目相关人员都应该能够报告程序错误
产品的项目相关人员是对产品的成功有既定利益的人，可以是公司员工，也可以是客户或用户。
经验61-引用别人的错误报告时要小心
经验62-将质量问题作为错误报告
对产品感到失望，感到产品不那么有价值，那么应该作为错误报告写出来。
经验63-有些产品的项目相关人员不能报告程序错误，测试员就是他们的代理
经验64-将受到影响的项目相关人员的注意力转移到有争议的程序错误上
写入错误报告，以引起其预算会受到这个程序错误影响的人的注意。
经验65-决不要利用程序错误跟踪系统监视程序员的表现
经验66-决不要利用程序错误奖励测试员
经验67-及时报告缺陷
经验68-永远不要假设明显的程序错误已经写入报告
经验69-报告设计错误
当发现设计问题时必须报告，很多设计问题要到系统几乎完成时才会被发现。
经验70-看似极端的缺陷是潜在的安全漏洞
经验71-使冷僻用例不冷僻
为了提高效率，常常要用到极值，测试员所发现的第一个错误常常是在边界处。
经验72-小缺陷也值得报告和修改
低成本修改（小缺陷）可以避免该产品一半以上的
技术支持
电话。一般性的修改对客户满意度有重要影响。小缺陷数量增加后，客户信心会下降，测试员及公司就会容忍越来越多的严重缺陷。
经验73-时刻明确严重等级和优先等级之间的差别
严重等级表示程序错误的影响或后果，优先等级表示什么时候要求修改错误；
经验74-失效是错误征兆，不是错误本身
当看到失效时，缺陷可能很小，但是内部问题可能会严重得多。因此，任何时候看到看起来很小的错误，都要：执行后续测试，以发现更多严重征兆；以发现更宽范围并且会被很多人看到；以确定使得该问题重现的关键条件，充分暴露可能问题。
经验75-针对看起来很小的代码错误执行后续测试
建议三种后续测试，变化自己的行为；变化程序选项和设置；变化软件和硬件环境；
经验76-永远都要报告不可重现的错误，这样的错误可能是时间**
经验77-不可重现程序错误是可重现的
程序错误要在特定条件下出现。有助于思考的条件例子；
经验78-注意错误报告的处理成本
在判断报告的内容和如何报告上做一点讨论，错误报告有处理成本。
经验79-特别处理与工具或环境有关的程序错误
已知弱点，而造成程序失效，失效完全在程序猿控制之外，决定不报告这样的程序错误是合理的。
经验80-在报告原型或早期个人版本的程序错误之前，要先征得同意
有时候程序员会给测试员一个个人版本，并要求进行单独测试。
经验81-重复错误报告是能够自我解决的问题
经验82-每个程序错误都需要单独的报告
经验83-归纳行是错误报告中的最重要的部分
归纳行是向这些经理推销程序错误的最佳工具；好的归纳应该包含：简要描述、简要指出程序错误的局限性或依赖关系、简要指出程序错误的影响或后果。挑选对于报告最重要的信息，把其它内容放入报告的信息描述部分
经验84-不要夸大程序错误
测试员的可信性是影响力的基础；
经验85-清楚的报告问题，但不要试图解决问题
测试员的工作是报告问题，而不是确定根源，不是奋力争取具体的解决方案。决定适用于特定程序错误的解决方案时产品设计师的事；很多测试员对提出的解决方案太感兴趣，以至于没有提供有关失效本身的清晰、准确的信息。
经验86-注意自己的语气，所批评的每个人都会看到报告
错误的报告带有责备或居高临下的语气是没有益处的。
经验87-使自己的报告具有可读性，即使对象是劳累和暴躁的人
经验88-提高报告撰写技能
经验89-如果合适，使用市场开发或技术支持数据
自己产品表现与竞争对手对比，在与客户接触时遇到的问题，与技术支持人员合作；
经验90-相互评审错误报告
核查关键信息；是否可复现；简化、概括或加强；
核查所有缺陷、自己发现的缺陷、同事发现的缺陷；
注意不要过多的增加评审测试员的负担，评审过程需要时间。
经验91-与将阅读错误报告的程序员见面
经验92-最好的方法可能是向程序员演示所发现的错误程序
经验93-当程序员说问题已经解决时，要检查是否真的没有问题了
在略有不同的环境下可能还会发现它失效。应该进行后续测试，以保证不会出现。
经验94-尽快检验程序错误修改
当测试员被告知所报告的程序错误被清除时，要尽可能迅速地检验。测试员等待的时间越长，程序员所记得的内容越少；
经验95-如果修改出现问题，应与程序员沟通；
经验96-错误报告应由测试员封存
除非经过测试员的评审和封存，否则任何程序错误都不能标示为已封存。
经验97-不要坚持要求修改所有程序错误，要量力而行
最重要理由之一就是风险；另一个是客户不愿意为修改付费；
经验98-不要让延迟修改的程序错误消失
经验99-测试惰性不能成为程序错误修改推迟的原因
如果测试经理要求程序员不要修改程序错误，只因为修改会影响太多的检查单、脚本或其它测试工作制品，因此要占用太多的管理时间，说明测试过程存在很大的缺陷；
经验100-立即对程序错误延迟决定上诉
经验101-如果决定据理力争，就一定要赢
所做的每个上诉都是有说服力的。
