Bug提交规范说明.docVIP

Bug提交规范说明 文档编号： Bug提交规范说明 密 级： [内部资料] 部 门： 测试部 版本 编写人/修改人 日期 说明 V1.0 王宝静 2006-04-07 初稿 V1.1 王宝静 2006-07-28 更新 V1.2 刘丽 2007-01-08 修改文档适用于BUGZILLA 修改BUG状态 bug提交规范目录一 引言 2 1.1 编写的目的 2 1.2 定义 2 二 Bug的组成因素 2 2.1 产品名称和组件名称 3 2.2 版本 3 2.3 Bug类型（由研发部标识） 3 2.4 关键字 3 2.5 Bug状态 4 2.6 Bug优先级（由产品部标识） 4 2.7 Bug摘要 4 2.8 Bug描述 5 2.8.1 能重现的bug 5 2.8.2 不能重现的bug 5 2.9 附件 6 三 提交格式规范 6 四 引发问题追朔版本标准 7 五 附录 8引言 编写的目的 RedOffice产品的多元化发展，bug数量的日益增多，那么提交bug的规范要求自然就要孕育而生。 经与研发部门相关负责人沟通后，制定了以下提交bug的一系列规范，希望测试人员能够严格按照此规范提交问题。 定义 我们一般把操作过程中发现不正确结果的问题称为bug。 Bug的组成因素 为了便于bug的管理、修改、查看，每条bug必须包含以下因素： 产品名称+组件名称+版本+产生时版本+类型+关键字+操作系统+级别+Bug摘要+Bug描述+附件 其中红色字因素书面的测试报告中不必包含，蓝色字因素提交到Bugzilla中时不必包括，但书面报告中要求涵盖。 产品名称和组件名称 产品名称：针对不同项目的不同立项； 组件名称：针对不同项目所划分的不同测试方向； 其中有关RedOffice的项目涉及到的组件名称，参见“svn://172.20.69.219/test/TTech/测试控制文档/测试规范”目录下的《RO40 Component.mht》。 “产品名称”和“组件名称”由项目经理统一制定，测试人员提交bug时只需选择所测试的项目及对应的模块名称即可。 版本 版本：不同产品的内部过渡版本号。 其中Office项目版本的制定标准：平台简称（W/L）+产品名称（RO/OO）+产品生产日期：年月日（060412），如：WRO060412。 “版本”由项目经理统一制定，测试人员提交发现的bug时，只需选择所测试的内部测试版本的版本号。 产生时版本：该问题在Office版本的存在状况及引发问题时的版本。 当该问题在OpenOffice能重现，则在Bug描述的备注中写入OpenOffice相应的版本号； 当该问题在OpenOffice不能重现，则在Bug描述的备注中写入，该问题开始产生时的RedOffice内部过渡版本的版本号。 Bug类型（由研发部标识） Bug类型主要分为以下几方面： 代码错误、界面优化、设计变更、新增功能、数据校对、事务跟踪、其他 关键字 最能体现该bug反应问题核心的功能点。 关键字已定义整理，在提交Bug时大家要在定位问题时尽量找到该问题涉及到的主要功能点。指定关键字时请和菜单中涉及到的功能叫法相同。 关键字文档参见“svn://172.20.69.219/test/TTech/测试控制文档/测试规范”目录下的《RO40 KeyWord.mht》。 Bug状态 严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。 在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。 Blocker：阻断性的缺陷，如：安装、卸载及操作时影响到系统其它的软件等； Critical：严重错误，如：死机、程序退出、死循环、内存溢出、程序错误、操作后导致的文档不能编辑、功能缺失、主要功能实现错误等； Major：较严重的功能缺陷，如：共用操作实现错误、基本功能实现错误、缺省值或默认属性错误等； Normal：一般的功能缺陷，如：可以通过绕过缺陷而操作的功能、操作界面错误、打印内容及格式错误、简单的输入限制未进行控制、非法操作未给出提示等； Minor：较轻的功能缺陷，如：界面显示不规范、辅助说明描述不清楚、提示窗口文字未采用行业术语、可输入区域和只读区域没有明显的区分标志、操作的响应时间较慢等； Trivial：产品外观上的问题或一些不影响使用的小毛病，如：菜单或对话框中的文字拼写或字体问题等； Enhancement：建议或意见。 注：如果在提交BUG时，遇到“死机、程序退出、崩溃”的问题，