• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

软件测试管理中常见的缺陷提交错误分析

发布: 2010-4-29 11:47 | 作者: 不详 | 来源: 领测软件测试编辑 | 查看: 53次 | 进入软件测试论坛讨论

领测软件测试网

软件测试管理中常见的缺陷提交错误分析

关于常见的缺陷提交错误分析。希望能给大家在日常工作中提个醒。

  1)常见错误

错误

错误列举

主观评价

使用“我”、“你”等人称代词。可以直接使用动词或必要时使用“User(用户)”代替

主观评价

使用情绪化的语言和强调符号,例如黑体、全部字母大写、斜体、感叹号、问号等。只要客观地反映出缺陷的现象和完整信息即可,不要对软件的质量优劣做任何主观性强烈的批评、嘲讽

语意模糊

“与**不同”、“有错误”、“不对”、“出错”等字眼等含义模糊的词汇,而需要报告确定的缺陷结果

主观评价

使用诸如“似乎”、“看上去可能”、“应该”等字眼

描述口语化

“程序后台直接down掉,没有反映”

语意模糊

例如“选择停止执行后,程序开始抽取”,“监控状态统计默认的是统计最近8天的告警信息”

缺陷未隔离

一个缺陷中记录了一个以上的问题

缺乏可读性

缺陷描述包含的内容,因为读者的文化、观念或岗位不同,很多内容在别人看来,往往难以准确理解,甚至可能引起误解。只需客观地描述缺陷的信息即可

习惯提交

将不确定的测试问题提交缺陷中。
如果对测试软件的某个现象不确定是否是软件缺陷,可以通过电子邮件或口头交流,确认是缺陷后再报告到数据库中。避免查询和统计结果的不准确性

建议模糊/主观评价

对于UI或者UE觉得不合理的地方,给出建议看法, 以“需调整”、“不合理”、“需要优化”去描述

  2)建议类缺陷

  针对建议类型缺陷,要解释建议的目的,并能给出提出建议的依据,包括易用性、人性化以及行业惯例等,便于开发人员接纳。

  3)缺陷改进与自查

 

检查项

改进

对于多人同时测试同一模块的情况,报Bug前先检查是否已有类似的Bug

Bug严重程度(Severity)必须准确

填写Subject字段,便于Dev Manager 分配给相应的开发人员;

项目中共性的问题,应及时纳入专项测试用例试行

多个相同的问题,如是一个Dev负责完成的,撰写一个缺陷报告就可以,但须指出问题发生的多个位置

对于Reject的有争议的Bug,尽可能保持开发人员沟通

自查

缺陷报告已经向读者包含完整、准确、必要的信息了吗?

一个缺陷报告中是否只报告了一种缺陷?

读者是否能容易的搜索该缺陷?

步骤是否可以完全复现而且表达清楚吗?

是否包含了复现该缺陷需要的环境变量或测试所用的数据文件?

读者是否能容易的搜索该缺陷?

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 管理 缺陷 软件测试


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网