测试新手提交Bug时的注意点

1.缺陷摘要（Summary）

简单明了，便于理解。

长度一般不超过30个单词。

尽可能讲明：什么情况，导致了什么问题。

便于他人定位Bug，杜绝重复报相同的Bug。

2.缺陷描述（Descrīption）

重现步骤（Actions）

详细描述重现该问题的关键步骤；

省略无关的操作，力求做到：所有重现步骤是充分的和必要的。

容易理解的常规步骤，可以一句话带过，比如“以管理员身份登录，进入后台用户管理页面”。

和环境有关的问题，给出特定的条件，比如某某操作系统，某某浏览器。

实际结果（Actual Result）

描述实际出现的错误结果；

可借助截屏来表达；

不是总能重现的Bug，给出发生频率或规律。

期待结果（Expected Result）

可选，当Spec上没有对实现方式做详细要求时，用于测试人员表达自己的看法。

3.截屏/附件（Attachment）

针对文字难以表达的或UI方面的问题；

图片格式使用JPG格式；Windows画图工具的默认BMP图片太大，不建议使用；

在图片上用醒目的颜色，标出问题所在区域；

也可考虑配上简短的文字。

4.其它

对于多人同时测试同一模块的情况，报Bug前先检查是否已有类似的Bug（TD提供了简单的Find Similar Defects的功能）。

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

Bug优先级(Priority)必须准确（具体请参考公司标准文档）。

填写Module/Function字段，便于Dev Manager分配给相应的开发人员。

项目中共性的问题，纳入Common Module。

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

对于Reject的有争议的Bug，尽可能和Dev当面沟通。

Windows截图快捷键：

截图类型截图快捷键说明

全屏幕PrintScreen键

当前活动窗口ALT + PrintScreen键按住Alt键，然后按下PrintScreen键

局部窗口系统不支持可借助截屏软件，如HyperSnap

_staa���c��