BUG说明语言规范.docVIP

BUG描述规范 一、目的 清晰简单描述好缺陷，编写有效的缺陷实例，帮助开发人员有效的进行缺陷定位，重现错误，从而去有效的定位错误，修改错误。 二、目标 减少开发人员的二次缺陷率 提高开发人员修改缺陷的速度 提高测试质量部门的信用度 增加开发与测试的协作 有效提高产品的质量 三、范围 本文档适合于系统产品部门所有的人员 四、缺陷的要素 描写格式：填写缺陷的时候，若为软件的模块名称、页面元素和按钮、关键步骤、附件则应由对应的“ [ ] “ 进行描写，描述中出现的缺陷错误需用引号+粗体+红颜色进行标记； 描写步骤：缺陷描述的时候要分层次，首先是描述缺陷发生的位置和条件，其次描述缺陷发现的步骤，再描述缺陷发生的结果，给出缺陷修改建议，最后必须[附上结果的附件或快照]； 描述方法：填写缺陷的时候，尽量采用书面语，不能采用口语、歧义性语言，激动的语言（毁谤性）；缺陷的状态改变，需注释对应的用户名、时间、原因，才能改变状态； 附件和快照标准格式： 附件根据需要对缺陷的过程和结果进行[标注]和[文字说明]，说明过程需用[红色箭头]对缺陷过程进行[描述]和[说明]； 缺陷主题描述：简单清晰的描述在什么样的位置，什么样的条件下，发生什么样的结果，不能完全复制详细描述中的语言； 缺陷描述标准格式： 缺陷描述规范： 缺陷主题： 缺陷位置+缺陷结果（在什么样的位置，什么样的条件下，发生什么样的结果） 参数设置： 定位好缺陷类型，项目优先级，程序优先级，缺陷状态等TD必填字段 详细描述： 缺陷发生在哪里：[标准格式：在[XXX模块]—[YYY子模块]下]； 缺陷发生的步骤/条件：通过对什么样的操作，进行了什么样步骤； 缺陷发生的结果：出现了[ZZZ]的错误现象，见附件 [NNN]； 针对问题的建议：根据判断，给出缺陷解决的建议，建议对此缺陷进行怎样的修改或者对应的处理方式，针对建议需要给出解决的方法和过程； 缺陷必须要有附件或快照（其中必须对其按照标准格式进行标注和文字说明） 五、缺陷描述的案例 案列一： 缺陷主题： [集成管理]模块的[项目注册管理]页面， 查看项目立项信息时，出现“未能加载类型“ProjectGeneralView”错误 参数设置： 定位好缺陷来源，检测版本，所属模块，严重程度、优先级 详细描述： 1）在[集成管理]— [项目注册管理]页面下； 2）选择[已发布]TAB页； 3）在GRID列表中，选择任意一条项目立项信息，点击[查看]按钮； 4）系统页面弹出：按钮报错信息“未能加载类型“ProjectGeneralView“， 见附件[1.JPG]、[2.JPG]； 1.jpg 2.jpg 六、测试属性定义 测试优先级 高：在所有的测试项中排在首位、最核心也是最能影响整体的被测对象或功能 中：主要的涉及到细节化的被测对象或功能 低：不影响系统运行和整体架构的被测对象或功能 BUG严重级 高：引起系统崩溃或无法正常运行和安装 中：需求说明书中要求的功能未实现或不符，或流程数据错误 低：显示差错、风格差异或建议 BUG优先级 高：非常紧急且无法继续测试，必须马上修复 中：不影响主要流程但在发布版本前必须修复 低：时间允许的情况下修复，也可在下一个版本再修复