《软件测试经验与教训》读书笔记（二）

程序错误分析（编写表达BUG报告）

55）错误报告，文如其人。

56）好的错误报告，能推动错误的改正。测试员的责任不是保证所有错误都得到改正，而准确报告问题，使读者能够理解问题的影响。

57）使自己的错误报告成为一种有效的“销售工具”。因为错误报告劝导人们付出宝贵资源来换取测试员所建议的好处。对于程序错误，资源就是时间和资金，好处就是通过改正这个错误而带来质量改进。销售策略一般有两个目标：其一：陈述种种好处，使得潜在客户想要它。其二：向销售人员说明预期存在的问题，并反驳他们。

58）错误报告代表的是测试员。

59）努力使错误报告有更高的价值。例如：

报告缺陷，并帮助程序员定位内部问题。

报告规格说明、测试文档、用户文档或开发工具中的问题。

为技术文档编写员提供背景信息，编写员要编写手册或公司网站中的问题定位部分。

报告提示需要通过客户培训解决的问题。

报告为客户售后支持人员提供关键信息，如他们会遇到哪些没被解决或不完全解决的问题。

报告和管理员提供正在开发的产品状态和质量信息。

报告在开始计划产品下一个版本时，提供初始改进建议。

60）任何产品/项目的相关人员都应该能够报告程序错误。

61）引用别人的错误报告时要小心。注意：一方面：如果没得到允许，可以补充评论，但不能编辑别人的材料，即使错误报告很糟糕也不要擅自修改因为很可能会遗漏重要信息的风险；另一方面，任何时候要在（特别是其他人的）错误报告做补充，都要注明自己的姓名和日期。

62）将质量作为错误报告。（质量对于个人来说就是价值。）测试员的任务就是帮助项目相关人员写出清晰的其对产品感到没价值的意见。

63）有些产品/项目相关人员不能报告程序错误，测试员就是他们的代理，所以应站在他们的立场理解要报告的内容。例如：测试员必须研究用户使用产品的方式，以及他们喜欢这种产品的什么，不喜欢什么。

64）将受到影响的项目相关人员的注意力转移到有争议的程序错误上。例如：如果测试员认为很难说服程序员改正错误，但是测试员希望改正，可以考虑公司中如果这个错误被改正能够受益的其他人。

65）决不要利用BUG管理系统监视程序员的表现。例如：使用该系统估算修改代码的时间，这样会使程序员感到为难外，其他程序员也就防备这个系统，最有可能的结果是，程序员争辩设计问题并不是程序错误，类似的错误是重复的等。

66）决不要利用BUG管理系统监视测试员的表现。例如：如果测试经理用BUG数作为考核依据，测试员也许会报告容易发现、更肤浅的BUG，也许更愿意报告同个BUG多个实例；他们会不愿意花时间指导其他测试员；程序员更有可能认为测试员是为了BUG数而不质量。

67）及时报告BUG。因为BUG报告拖延的时间越长，BUG被修复的可能性就越小；另一个风险是：项目其它相关人员就错误地以为已测功能点没BUG很稳定。

68）永远不要假设明显的BUG别人已提过。

69）测试员应报告设计错误。

70）极端的缺陷是潜在的安全漏洞。

71）使冷僻用例不冷僻。例如：极值测试思想：如果程序能够在这种条件下存活，那么在不那么极端的情况下也可以存活。因些可以通过少量极端测试了解很多东西。

72）小缺陷也值得报告和修改。Kaner和David Pels研究发现小缺陷（指修改BUG在4小时以内的BUG）修改可避免该产品一半以上的技术支持成本。

注意：任何产品都会残留一些小缺陷。但随着小缺陷数量增加，客户信心会下降，更糟糕的是容忍这些缺陷的腐蚀作用。当连报告小缺陷的行为都停止后，测试员和公司就会容忍越来越多的严重缺陷，长此以往，最终会使产品失败。

73）时刻明确严重等级和优先等级间的区别。严重等级：指BUG的影响或后果；优先等级：指什么时候要求修复。

74）失效是错误征兆，而不是错误本身。因此，任何时候看起来很小的错误，都要：执行后续测试，以发现更严重的征兆或以发现更一般的场景。当问题很难重现时，可执行后续测试，以确定使该问题重现的关键条件，然后执行后续测试，以充分暴露现在已可重现的问题。

75）针对看起来很小的代码错误执行后续测试。如果看到的是小失效，不要只是重现该失效并写入报告。程序处于脆弱状态，尝试利用这一点，继续测试，并可能发现内部缺陷的实际影响是糟糕得多的失效，例如系统崩溃或数据损坏。

对于每个认为反映了编码错误的失效至少要做几分钟的后续测试，要相信自己的判断。建议尝试如下三种后续测试：

a变化自己的行为。（通过改变操作方式改变条件）

b变化程序选项和设置。（通过改变被测试对象的条件）例如：使用不同的数据库，改变持久变量的取值等。

c