文档详情

如何编写有效的缺陷报告 软件测试资料大全.pdf

发布:2017-08-09约8.43千字共8页下载文档
文本预览下载声明
如何写有效的缺陷报告 这是翻译一个名字叫做Kelly Whitmill 的人写的文章,他在写这篇文章之前有18 年的 软件测试经验,18 年中主要做为team leader 来负责通过寻找并且实施有效的测试方法和测 试工具来达到系统的要求,擅长利用有限的资源来尽可能的模拟环境,在自动测试上有浓厚 的兴趣。从大公司到小公司都有过丰富的经历,现在在IBM 公司工作。 介绍 缺陷报告是测试过程中可以提交的最重要的东西。它的重要性丝毫不亚于测试计划,并 且比其他的在测试过程中的产出文档对产品的质量的影响更大。所以很有必要学习如何写出 有效的缺陷报告。有效的缺陷报告将能够: 减少开发部门的二次缺陷率 提高开发修改缺陷的速度 提高测试部门的信用度 增强测试和开发部门的协作 为什么测试人员从开发那里得到的反馈比从其他部门得到的更多?一定程度上这个答 案就是缺陷报告,依照一些简单的规则可以使整个过程更加顺畅。但是我们的目标并不是写 一个非常完美的缺陷报告,而是能够传达正确的信息,让工作得以完成并且能够简化流程的 有效的缺陷报告。 这篇文章主要讲述缺陷报告的两个方面:1)描述的注释;2 )摘要。首先我们先来看 注释。 缺陷注释 下面是确保你下一篇缺陷报告是有效的几个关键点: Condense -精简,清晰而简短 Accurate -准确,这到底是不是一个bug ?还是用户操作错误,或者是理解错 了,等等? Neutralize -用中性的语言描述事实,不带偏见,不用幽默或者情绪化的语言。 Precise -精确,这到底是什么问题? Isolate -定位,这到底是个什么样的问题?尽量缩小这个问题的范围。 Generalize-还有没有其他的某些地方存在这样的问题? Re-Create -如何引发和重现这个bug ?(环境,步骤,前提条件) Impact -影响,这个缺陷对客户有何影响?对测试有什么影响? Debug -怎么做才可以让开发更容易来修改这个bug ?(跟踪,截图,日志, 直接访问等等) Evidence -证据,如何证明确实存在这个bug ? 写有效的缺陷报告并不需要很好的文字功底,只要确认你正确回答了上面的问题,关键 就是确认你覆盖了所有的你的缺陷报告的查看者关注的要点就好了。 有效缺陷注释的要点 精简 清晰而简短。首先,去掉不必要的词;其次,不要添加无关的信息。包含相应的信息是 最重要的,但是确保这些信息都是有用的。不管什么原因,对于那些没有描述清楚如何重现 或者难以理解的问题,你都应该提供更多的信息。写过多的不必要的信息也是问题的一种。 精简的例子 缺陷注释 不要这样写: 当我正在专心测试的时候,报内存错误,这 TMI (Too Much Information ) 时我发现一个我不熟悉的 GUI,我试了好多 边界值以及错误的条件,但是运行正常。最 后我请空了数据,并且点击了前进按钮,这 时系统异常中止了,多次的反复尝试证明, 在任何情况下,只要“产品描述”这个字段 没有数据,点击前进或者退出甚至取消,系 统都会中止。 要这样写: 在产品信息页面,如果产品的描述字段为空, 前进,退出和取消的功能会使系统意外中止。 准确 确信你正在提交的确实是一个bug ,如果你因为安装问题或
显示全部
相似文档