51Testing软件测试论坛

标题: 如何写软件测试缺陷管理的报告 [打印本页]

作者: merry1103 时间: 2010-6-21 15:07
标题: 如何写软件测试缺陷管理的报告
　软件缺陷的描述是是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。

　　一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。准确报告软件缺陷是非常重要的，因为：清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量提高软件缺陷修复的速度，使每一个小组能够有效的工作提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应加强开发人员，测试人员和管理人员的协同工作，让他们可以更好的工作在多年实践的基础上，我们缺陷的有效描述规则，主要是：

　　1. 单一准确每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。

　　2. 可以再现提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。

　　3. 完整统一提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。

　　4. 短小简练通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。

　　5. 特定条件许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。

　　6. 补充完善从发现bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。

　　7. 不做评价在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。

作者: merry1103 时间: 2010-6-21 15:08

作者: msnshow 时间: 2010-6-21 19:54
很多时间写一个BUG需要花很多的时间，要是口头描述的话，可能会更快一些

作者: 风逝 时间: 2010-6-22 09:18
写的很好哦！

作者: chengning 时间: 2010-6-22 11:06
标题: 回复 3# 的帖子
口头当然有口头的好处，但是不好回归。也容易忘记

个人意见

作者: mymarvell 时间: 2010-6-30 22:45
标题: 回复 3# 的帖子
口头描述缺点很多
1。很多时候口头描述是一种很奢侈的事，因为很多协同工作是在不同部门甚至不同城市之间
2。口头描述很容易遗漏一些事项
3。问题要报给很多的部门与人员，口头描述是做不到的
4。口头描述不利于Bug的跟踪与回归

作者: msnshow 时间: 2010-7-2 20:53
标题: 回复 5# 的帖子
要看缺陷的具体情况了，我觉得记录是有必要的，但用什么方法去描述得看效率

作者: 千里 时间: 2010-7-3 13:58
凡事有好的方面也有不好的方面，这就是两面性。
关键靠我们来权衡，不要让自己的思维僵化了。

作者: chengning 时间: 2010-7-7 12:30
标题: 回复 7# 的帖子
要是整个团队的素质都能上的去的话口头确实很省事也很清楚啊

作者: 楠族开心果 时间: 2010-7-7 14:07
标题: 回复 9# 的帖子
但是口头容易遗忘呀~

作者: chengning 时间: 2010-7-7 22:06
标题: 回复 10# 的帖子
还是千里那句话有利就有弊嘛看侧重那个了

作者: 影儿2009 时间: 2010-7-23 16:58
虽然记录下来会花时间，但是不容易忘记。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)