【兆隆IT云学院IT培训】软件测试的经验教训
不能报告程序错误的测试员，很像是只有当冰箱门被关上时才亮的冰箱灯。冰箱内是被照亮了，只是没有亮在点子上。测试员要提供信息服务，不过为了提供有效服务，测试员不光要填写报告模版，并假设报告能够被完全理解。要了解如何编写和表达自己的测试结果，以便读者能够真正得到结果。我们把这个过程叫做“程序错误分析”。

    经验1文如其人

    错误报告是大多数程序员的主要工作产品。测试员的读者通过这些文档认识测试员。报告写得越好，测试员的声誉越高。

    程序员通过测试员的报告得到关键信息。重要问题的良好报告会为测试员带来良好声誉，差的报告会为程序员带来额外（在程序员看来是不必要的）工作。如果测试员浪费了程序员太多的时间，程序员就会躲避测试员及其工作。

    程序员并不是测试员的唯一听众。项目经理和执行经理有时也阅读错误报告。人事管理问题会很快引起他们的注意，并刺激他们的神经。这些错误报告看起来像是解释不清、研究不充分或提出过于追究小问题的建议，这些都会使负责奖励和提升测试员的人产生消极印象。

    如果下功夫研究并写好报告，所有人都会受益。

    经验2测试员的程序错误分析会推动改正所报告的错误

    测试员写的错误报告是要求改正错误的分析文档。

    有些错误永远不会被改正。测试员的责任不是保证所有错误都得到改正，而是准确报告问题，使读者能够理解问题的影响。

    深入研究并写出好的报告，常常对错误改正的可能性产生巨大的影响。

    经验3使错误报告成为一种有效的销售工具

    不管测试员是否这样想，他们的错误报告都是一种推销工具，它劝导人们付出宝贵的资源来换取测试员所建议的好处。对于程序错误，资源就是时间和资金，好处就是通过改正这个具体问题而带来的质量改进。

    销售策略一般包括两个目标。

    陈述种种好处，使得潜在客户想要它。测试员的错误报告应该使读者明白为什么要改正这个错误。例如，可以解释问题会怎样影响产品的正常使用，会破坏什么数据，或人们如何经常遇到这个问题。测试员可以利用杂志上的评论或其他出版物中的有关批评，指出类似的问题给竞争对手带来的麻烦。可以引用技术支持统计数据，说明其他产品中的类似问题所带来的资金损失。还可以这个程序的以前版本通过了这个测试。（在有些公司这是一个关键问题）有人喜欢自行在产品中引入一些特征，这些特征可能有问题，要保证报告会引起这些人的注意。在很多情况下（参见下面的讨论），从看起来相对较小的错误开始，通过后续测试能够发现更严重的后果，不应该报告所看到的错误的第一个版本。

    向销售人员说明预期存在的问题，并反驳他们。问题太小、不可重视、不能理解、在实际环境中不太可能发生、问题只出现在没有人有的非常特殊的设备配置上、改正错误风险太大、不会影响产品的实际用户等。通过养成良好的报告编写习惯，测试员可以例行地说明这些潜在的问题：文字明确而简单，核实（并报告）程序错误出现在多种配置上。其他问题会随程序错误的不同而不同。测试员可以在报告中预测某种问题，并提供相关信息。也可以等一等，看看大家最初对报告有什么反应，在评审该程序错误时再提供补充信息。

    经验4错误报告代表的是测试员

    经验5努力使错误报告有更高价值

    经验6产品的任何项目相关人员都应该能够报告程序错误

    经验7引用别人的错误报告时要小心

    经验8将质量问题作为错误报告

    经验9有些产品的项目相关人员不能报告程序错误，测试员就是他们的代理

    经验10将受到影响的项目相关人员的注意力转移到有争议的程序错误上

    经验11决不要利用程序错误跟踪系统监视程序员的表现

    经验12决不要利用程序错误跟踪系统监视测试员的表现

    经验13及时报告缺陷

    经验14永远不要假设明显的程序错误已经写入报告

    经验15报告设计错误

    经验16看似极端的缺陷是潜在的安全漏洞

    经验17使冷僻用例不冷僻

    经验18小缺陷也值得报告和修改

    经验19时刻明确严重等级和优先级之间的差别

    经验20失效是错误征兆，不是错误本身

    经验21针对看起来很小的代码错误执行后续测试

    经验22永远都要报告不可重现的错误，这样的错误可能是时间炸弹

    经验23不可重现程序错误是可重现的

    经验24注意错误报告的处理成本

    经验25特别处理与工具或环境相关的程序错误

    经验26在报告原型或早期个人版本的程序错误之前，要先征得同意

    经验27重复错误报告是能够自我解决的问题

    经验28每个程序错误都需要单独报告

    经验29归纳行是错误报告中最重要的部分

    经验30不要夸大程序错误

    经验31清楚地报告问题，但不要试图解决问题

    经验32注意自己的语气。所批评的每个人都会看到报告

    经验33使自己的报告具有可读性，即使对象是劳累和暴躁的人

    经验34提高报告撰写技能

    经验35如果合适，使用市场开发或技术支持数据

    经验36相互评审错误报告

    经验37与将阅读错误报告的程序员见面

    经验38最好的方法可能是向程序员演示所发现的程序错误

    经验39当程序员说问题已经解决时，要检查是否真的没问题了

    经验40尽快检验程序错误修改

    经验41如果修改出现问题，应与程序员沟通

    如果程序错误修改反复失败，或在开发阶段的后期失败，不要仅仅通过错误报告反馈信息并在跟踪系统中归档，而应该直接找程序员。测试员的语气和态度应该友好、热心。要帮助程序员立即得到信息，并准备随时澄清报告中的任何不清楚的地方，如果程序员想看，应准备随时演示程序错误。

    经验42错误报告应该由测试员封存

    经验43不要坚持要求修改所有程序错误，要量力而行

    有两个原因导致不能修改所有错误：一是风险，二是客户不愿意为修改付费，定制、合同软件和内部软件开发尤其是这样。如果不能举出某个程序错误很重要的情况，或发现产品项目相关人员足够积极地支持测试员关于推迟特定程序错误修改的请求，我们建议还是把那个程序错误放在一边，先考虑其它问题。

    经验44不要让延迟修改的程序错误消失

    在测试新版本时首先要考虑测试上一版本遗留下来的问题。

    经验45测试惰性不能成为程序错误修改推迟的原因

    如果测试经理因为修改会影响太多的检查单、脚本或其他测试工作制品，因此要占用太多的管理时间而要求程序员不要修改程序错误（编码错误或设计错误），那么说明测试过程存在致命缺陷。

    经验46立即对程序错误延迟决定上诉

    经验47如果决定据理力争，就一定要赢