51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2650|回复: 11
打印 上一主题 下一主题

[原创] 如何写软件测试缺陷管理的报告

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-6-21 15:07:59 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
 软件缺陷的描述是是软件缺陷报告的基础部分,也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。

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

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

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

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

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

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

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

  7. 不做评价在软件缺陷 描述不要带有个人观点,对开发人员进行评价。软件缺陷 报告是针对产品、针对问题本身,将事实或现象客观地描述出来就可以,不需要任何评价或议论。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

12#
发表于 2010-7-23 16:58:41 | 只看该作者
虽然记录下来会花时间,但是不容易忘记。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2010-7-7 22:06:02 | 只看该作者

回复 10# 的帖子

还是千里那句话 有利就有弊嘛  看侧重那个了
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    6 天前
  • 签到天数: 544 天

    连续签到: 1 天

    [LV.9]测试副司令

    10#
    发表于 2010-7-7 14:07:19 | 只看该作者

    回复 9# 的帖子

    但是口头容易遗忘呀~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2010-7-7 12:30:02 | 只看该作者

    回复 7# 的帖子

    要是整个团队的素质都能上的去的话 口头确实很省事也很清楚啊
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    8#
    发表于 2010-7-3 13:58:15 | 只看该作者
    凡事有好的方面也有不好的方面,这就是两面性。
    关键靠我们来权衡,不要让自己的思维僵化了。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    7#
    发表于 2010-7-2 20:53:04 | 只看该作者

    回复 5# 的帖子

    要看缺陷的具体情况了,我觉得记录是有必要的,但用什么方法去描述得看效率
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2010-6-30 22:45:56 | 只看该作者

    回复 3# 的帖子

    口头描述缺点很多
    1。很多时候口头描述是一种很奢侈的事,因为很多协同工作是在不同部门甚至不同城市之间
    2。口头描述很容易遗漏一些事项
    3。问题要报给很多的部门与人员,口头描述是做不到的
    4。口头描述不利于Bug的跟踪与回归
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2010-6-22 11:06:16 | 只看该作者

    回复 3# 的帖子

    口头当然有口头的好处,但是不好回归。也容易忘记  个人意见
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2010-6-22 09:18:10 | 只看该作者
    写的很好哦!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    3#
    发表于 2010-6-21 19:54:19 | 只看该作者
    很多时间写一个BUG需要花很多的时间,要是口头描述的话,可能会更快一些
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    2#
     楼主| 发表于 2010-6-21 15:08:06 | 只看该作者
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-10-5 22:25 , Processed in 0.120255 second(s), 29 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表