《软件测试经验与教训》读书笔记---第四章

《软件测试经验与教训》读书笔记--目录

第一章 测试员的角色
第二章 按测试员的方式思考
第三章 测试手段
第四章 程序错误分析
第五章 测试自动化
第六章 测试文档
第七章 与程序员交互
第八章 管理测试项目
第九章 测试小组的管理
第十章 软件测试职业发展
第十一章 计划测试策略

第四章  程序错误分析

了解如何编写和表达自己的测试结果----程序错误分析

经验55.文如其人

经验56.测试员的程序错误分析会推动改正所报告的错误
测试员的责任，准确报告问题

经验57.使自己的错误报告成为一种有效的销售工具

• 陈述种种好处，使得潜在客户想要它。
• 向销售人员说明预期存在问题，并反驳他们

经验58.错误报告代表的是测试员
测试报告是程序员说服别人改正错误的主要途径。

经验59.努力使错误报告有更高的价值

• 报告提示大家注意缺陷，并帮助程序员定位内部问题
• 为技术文档编写员提供背景信息
• 报告提示需要通过客户培训解决的问题
• 报告为客户售后支持人员提供关键信息
• 报告向管理层提供正在开发的产品的状态和质量信息
• 报告在开始计划产品下一个版本时，提供初始改进建议

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

经验61.引用别人的错误报告时要小心
如果没有得到允许，可以补充评论，但不能编辑别人的材料

经验62.将质量问题作为测试报告
不同的人对于产品有不同的期望，但是如果产品的合法项目相关人员由于产品做得或没做的事而对产品感到失望，感到产品不那么有价值，那么应该作为错误报告写出来

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

经验64.将受到影响的项目相关人员的注意力转移到有争议的程序错误上
例如用户界面的不一致对于程序员来说可能是个小问题，程序员不想改正，可以写到错误报告里，以引起会受到这个错误影响的人的注意。

经验65.决不要利用程序错误跟踪系统监视程序员的表现
使用该系统，程序员会防备，或者可能引起争辩

经验66.决不要利用程序错误跟踪系统监视测试员的表现
可能为了提高程序错误，测试员会报告容易发现、更肤浅的错误。

经验67.及时报告缺陷
延迟报告的风险，会让别人认为这部分功能稳定

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

经验69.报告设计错误

经验70.看似极端的缺陷是潜在的安全漏洞
例如通过在预期接受一个1~99的字段中，输入65535个9会导致程序崩溃

经验71.使冷僻用例不冷僻
例如，为了测试期望接受一个0~999的输入字段，也许要检查-1、0、999和1000

经验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.如果据理力争，就一定要赢

参考《软件测试经验与教训》