自己总结的关于报BUG方面的注意点:
1. 缺陷摘要(Summary)
n 简单明了,便于理解
n 长度一般不超过30个单词
n 尽可能讲明:什么情况,导致了什么问题
n 以便于他人定位Bug,杜绝不重复报相同的Bug
2. 缺陷描述(Description)
n 重现步骤(Action)
Ø 详细描述重现该问题的关键步骤
Ø 省略无关的操作,力求做到:所有重现步骤是充分的和必要的
Ø 容易理解的常规步骤,可以一句话带过,比如“以管理员身份登录,进入后台用户管理页面”
Ø 和环境有关的问题,给出特定的条件,比如某某操作系统,某某浏览器
n 实际结果(Actual Result)
Ø 描述实际出现的错误结果
Ø 可借助截屏来表达
Ø 不是总能重现的Bug,给出发生频率或规律
n 期待结果(Expected Result)
Ø 可选,Spec上没有做详细要求,用于测试人员表达自己的看法
3. 截屏/附件(Attachment)
Ø 针对文字难以表达的或UI方面的问题
Ø 图片格式使用JPG格式;BMP图片太大,不建议使用
Ø 在图片上用醒目的颜色,标出问题所在区域
Ø 也可考虑配上简短的文字
4. 其它
n 对于多人同时测试同一模块的情况,报Bug前先检查是否已有类似的Bug (TD提供了Find Similar Defects的功能)
n Bug严重程度(Severity)必须准确
n Bug优先级(Priority) 必须准确(具体请参考公司标准文档)
n 填写Module字段,便于Dev Manager 分配给相应的开发人员
n 项目中共性的问题,纳入Common Module
n 多个相同的问题,如是一个Dev负责完成的,撰写一个缺陷报告就可以,但须指出 问题发生的多个位置
n 对于Reject的有争议的Bug,尽可能和Dev当面沟通
Windows截图快捷键:
截图类型 | 截图快捷键 | 说明 |
全屏幕 | PrintScreen 键 |
|
当前活动窗口 | ALT + PrintScreen 键 | 按住 Alt 键,然后按下 PrintScreen 键 |
局部窗口 | 系统不支持 | 可借助截屏软件,如HyperSnap |
chicochen@hotmail.com
http://www.ChinaQA.com
转载请说明出处,谢谢!