1 / 5
文档名称:

BUG单填写规范.doc

格式:doc   大小:26KB   页数:5页
下载后只包含 1 个 DOC 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

BUG单填写规范.doc

上传人:szh187166 2019/1/5 文件大小:26 KB

下载得到文件列表

BUG单填写规范.doc

文档介绍

文档介绍:文档名
版本号
完成日期
作者/修改人
校对
评审
BUG单填写规范

2012-11-05
王雪
鞠晓勤
报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误,从而有利于分析错误产生的原因,定位错误,然后修正之。因此,报告软件测试错误的基本要求是准确、简洁、完整、规范。以下概括了报告测试错误的规范要求,主要根据QC上的内容项填写。
必填项:
1、Bug标题,简洁、准确,完整,揭示错误实质,记录缺陷或错误出现的位置,准确反映错误的本质内容,简短明了。
2、分配给,将bug分配给bug责任人,如新建的bug分配给开发或者产品,修复后的bug分配给bug的提出人员。
3、严重程度,选择bug的严重程度。1级为致命型,2级为严重行,3级为一般型,4级为建议型,5级为可议型。
4、浏览器,选择发现bug的浏览器,测试人员在发现可能是因为浏览器兼容性而引起的bug时,应当在每个有需求的浏览器下都进行验证。
5、缺陷描述/步骤,对bug进行详细的描述并且填写Bug重现的步骤,出现的结果和期望的结果。Bug单需要填写详细的复现步骤,方便开发人员重现Bug。如:(步骤)1. 打开云计算首页cloud..cn “登录” :howfly102@,“Enter”键。结果:操作没有反应。期望:邮箱提交成功,给出“新密码已发送到邮箱”提示。
选填项:
1、测试者,提交bug的人员,默认值是当前登录QC的账号。
2、模块,发现bug的模块。
3、缺陷状态,缺陷共有8个状态,分别是新建、打开、返回—给缺陷的提出人员、后续跟踪、拒绝—给缺陷的解决者、已关闭、已修正和重新打开,可下拉选择。新建缺陷时,缺陷状态的默认值为新建,被分配到bug的人员(一般为开发或者产品)如果认为此bug不是bug,可以将缺陷状态改为返回—给缺陷的提出人员。对于一些偶发性的bug,开发人员无法复现或者测试人员暂时无法确认bug是否已修复的bug,可
将缺陷状态改为后续跟踪。开发人员接受这个bug后,则将缺陷状态改为打开,修复完成后,将缺陷状态改为已修正,并将bug指回给bug提出的人员(一般为测试人员),bug提出人员确认bug修复后,将bug状态改为已关闭,如果经过确定后没有修复,则将缺陷状态改为拒绝—给缺陷的解决者(如果测试人员对被返回的bug有异议,也可以使用此缺陷状态)。如果已经关闭的bug需要重新打开,则可将缺陷状态置为重新打开。
4、实际修复时间,bug从新建到已修正的总时间,以小时为单位,QC会自行计算,也可以自己手动填写。
5、 Root_Cause,产生bug的原因,由bug的解决者填写,一般来说1、2级的bug必须要填写,其他等级的bug最好也能填写。
6、解决人员,解决bug的人员。
7、测试日期,提交bug的日期,默认为当天。
8、抄送,除了被分配bug的人外,可能还需要其他人员来关注这个bug,这时可选择/填写bug需要抄送的人员。
9、检测于版本,提交bug时项目所处的版本。
10、优先级,bug处理的优先级,共有3个等级,高、中和低。
11、系统,选择bug出现的操作系统,win7,xp,mac等。
12、解决方案,解决方案有6项,