缺陷的JIRA管理文档.doc

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