1、平台质保_缺陷的 JIRA管理版本版 本 历 史日期 版本 说明 作者 参与者2008年 4月 11日 V1.0 完成文档初稿 王一帆2008年 4月 29日 V1.1 修改文档部分内容 王一帆2010年 6月 28日 V2.0 完善缺陷的级别定义 毛也2010年 11月 12日 V3.0 修改版本维护说明，修改缺陷处理流程说明 张萍目 录1. 文档简介 41.1 编写目的 42. 缺陷填报规范 42.1 缺陷填报步骤 42.2 缺陷优先级的判定 62.3 缺陷描述的格式 62.4 缺陷提案的补充内容 63. 缺陷提案的版本维护 73.1 影响版本 73.2 修正版本 74. 缺陷处理原则 8
2、4.1 缺陷处理流程 84.2 缺陷关闭原则 94.3 缺陷注释原则 91. 文档简介1.1 编写目的 规范缺陷上报及处理流程 规范缺陷版本维护流程 提高缺陷质量 提高工作效率对于测试人员，要严格按照“提案填报规范”中的要求填写上报缺陷；开发人员和测试人员，要严格按照“提案处理原则”中对于各种状态缺陷的处理约定，及时对缺陷进行相应处理；对于测试负责人，要严格按照“提案版本维护”中的要求对提案版本进行相应处理。2. 缺陷填报规范2.1 缺陷填报步骤（用红色标识的是提案的必填项）A选择项目和提案类型【项目】选择所要填入的缺陷库【提案类型】缺陷方面的提案选择“问题”用户体验方面的提案选择“增进建议”
3、B. 输入提案的详细信息【概要】缺陷或建议的标题，是对提案具体描述的概括，应言简意赅【优先级】ABCDE 五级区分，严重级别由 A 到 E 递减。 划分标准见 【预期日期】提案解决的日期，最长为下一轮测试开始的日期。可以不填写【组件】问题所在部件【影响版本】第一次发现问题的项目版本，以测试开始邮件中说明的版本为准【修正版本】同“影响版本” 新报提案时，修正版本与影响版本选择一致【被分配人】提案的解决人：以测试开始邮件中说明的“缺陷分配”人为准【环境】测试环境：操作系统+浏览器版本【描述】对问题或建议的具体描述，格式参见2.2 缺陷优先级的判定平 台 质 保 _测 试 缺 陷等 级 定 义 .d
4、ocx2.3 缺陷描述的格式【四个要素】测试帐号/url、操作步骤、预期结果、实际结果举例：2.4 缺陷提案的补充内容【附加截屏】上传发现 bug 时的截屏到提案中，上报 Bug 时建议多采用粘贴截图附件的方式来形象呈现发现的缺陷【附加文件】上传与提案相关的文件到提案中，该文件能够为提案的解决起到帮助作用3. 缺陷提案的版本维护提案版本维护由测试负责人，在每轮缺陷评审会议之后，进行操作3.1 影响版本影响版本是指，某缺陷的发现版本，至该缺陷验证关闭的所有版本后期版本维护，不修改提案的影响版本。3.2 修正版本修正版本是指，该问题的解决版本。后期版本维护，不需修改修正版本：4. 缺陷处理原则4.
5、1 缺陷处理流程A置状态时机：新报的提案，自然就是“open”状态置状态人：报提案者B置状态时机：在开发环境中解决完缺陷置状态人：开发者处理：点击【解决提案】【Bug 已修正】已解决此提案描述的 Bug。【Bug 无法修正】此提案描述的 Bug 出于技术原因，无法解决。【任务达成】完成任务类型的提案。【是重复的】此提案描述的问题，之前已另有提案阐明，需注释重复的提案号。【不完整】提案的描述内容不清楚，关键步骤缺失。【无法再现】提案描述的 Bug 无法重现。【Not a Bug 】 经产品人员确认后，确定提案描述的 Bug 不是 Bug，产品定义就是如此。【延迟处理】提案由于时间进度、上线等原因
6、，经三方确认后，不在当前解决。【放弃处理】提案由于技术、时间进度等原因，经三方确定后，放弃处理。C置状态时机：在测试环境中验证缺陷，发现缺陷中所描述问题还存在置状态人：测试工程师DClosed置状态时机：在测试环境中验证缺陷，发现缺陷中所描述问题已修改置状态人：测试工程师4.2 缺陷关闭原则开发人员不得关闭提案。提案只能由测试人员关闭。若发现开发人员关闭提案，应及时沟通，之后予以“重开提案”等操作。4.3 缺陷注释原则关闭提案，注释为：XXX 第 X 轮系统测试（之冒烟测试 X）验证通过重开提案，注释为：XXX 第 X 轮系统测试（之冒烟测试 X）验证失败，原因 XXXXX或以测试开始信中说明为准
