产品测试缺陷管理作业指导书A版

LOGO作业指导书文件编号WITE004版本A产品测试缺陷管理页数第1页共5页生效日期2019-08-20产品测试缺陷管理作业指导书制定/日期XXX审核/日期XXX批准/日期XXX修改记录修改状态时间修改内容概要修改人审核批准A2019-08-20流程整理，新发行XXXXXXXXX1.0目的1.1明确对缺陷的一致性认识及明确各角色的职责。1.2建立可追溯的BUG系统。1.3根据项目的缺陷数量收敛趋势、严重程度分布情况对项目进行有效的质量保证,及时了解并跟踪每个被发现的缺陷。2.0适用范围适用于研发人员、测试人员、项目管理人员。3.0定义BUGzilla:缺陷管理系统。测试标准：企业标准及客户标准。缺陷严重程度:致命、严重、一般、提示。缺陷状态：新问题、待验证、待解决、重新打开、重复问题、非问题、待评审、不做修改。4.0职责4.1测试工程师/技术员：负责缺陷记录和提交。4.2测试负责人：负责缺陷的审核。4.3研发经理：负责缺陷的确认及任务分配。4.4研发工程师：缺陷的修复。4.5产品经理：对有争议的问题发起评审。5.0运作程序5.1有效的缺陷描述有以下几个原则5.1.1可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让研发人员容易看懂；5.1.2定位准确：缺陷描述准确，不会引起误解和歧义。5.1.3描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；对于需要3个以上的操作步骤，用序号分步描述。5.1.4完整统一：提供完整、前后统一的缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见“缺陷的格式”。5.1.5短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。如“抗车头灯光测试，6500LUX闪灯时，红外探测器出现误报”中“抗车头灯光测试”、“6500LUX”、“闪灯”等是关键词。5.1.6特定条件：许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助研发人员找到原因的线索。如“平台在IE7.0和IE8.0的兼容问题”。5.1.7不做评价：在缺陷描述不带有个人观点，对研发进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。5.1.8添加附图：复杂的问题应附截图补充说明或直接通知指定的修改人，考虑到网络数据传输效率，截图的文件格式建议用jpg或gif，不建议用bmp；报告中避免使用抽象语句：比如“可能出现”、“是不是？”、“请研发人员确认”之类。5.2缺陷描述内容的格式【项目】（必填）:所属项目（型号，产品名称）。【模块】（必填）:所属项目的子模块划分。【版本】（必填）:发现缺陷时的版本号。【严重程度】:致命、严重、一般、提示。【类型】:客户端、服务器端、嵌入式、算法、数据库、硬件等。【问题类别】:功能、性能、可靠性、兼容性、结构工艺、安装等。【优先级别】:高、中、低。【问题状态】（必确认）:依实际情况进行选择，如：新问题、已解决、待处理等。【处理人】:计划提交给谁处理。【抄送】:需要知会的人。【默认抄送】:由管理员在建立项目时设置。【预算时间】:修复问题时估计的需要的时长。【截止时间】:计划修复问题的时间。【别名】:缺陷的简单名称，方便后续用此关键字搜索。【网址】:问题单的网址，或B/S类问题现象的网址。【摘要】（必填）:问题单的标题。【描述】（必填）:问题单的详细描述。【附件】:对问题现象不好表达清楚或感觉截图更能简明说明问题时，可附截图。【要先修复这些Bug】:解决此问题的前置条件。【会阻塞这些Bug】:此问题会阻塞其他哪些问题。5.3由测试工程师提交测试缺陷5.3.1负责报告系统缺陷记录,并协助项目人员进行缺陷定位。5.3.2负责验证缺陷修复情况,并填写缺陷记录中相应信息。5.3.3负责执行系统回归测试,对已修复的缺陷进行验证。5.3.4对缺陷后续状态进行跟进，包括相关人员对这个缺陷相关信息的询问回答。5.3.5对研发人员标记为重复、非问题、不做修改的问题要进行分析，及时定位问题，督促更新状态；可新增、修改缺陷，不能删除缺陷；负责整个缺陷流程的跟踪。5.4在BUGzilla管理系统内提交缺陷报告，需初步定义此缺陷的等级，缺陷严重程度：缺陷（另称：Bug）的严重程度是指因缺陷引起的故障对产品的影响程度。说明致命产品不符合产品安全标准。产品基本功能不可用，且通过复位无法恢复。产品达不到目标市场法律法规的强制性要求。可能导致批量性市场或生产故障。涉及影响公司形象。6、可能引起媒体负面报道。严重1、产品基本功能不可用，但用户可通过复位自行恢复。2、产品资料明确提供的基本功能无法实现。3、产品与测试标准存在严重偏差，或普通用户能够觉察到。一般1、产品与测试标准存在较小差距，且普通用户无法觉察到。2、基本功能操作用户界面提示错误。3、产品功能可以实现，但用户使用不便。提示1、产品与测试标准存在稍小差距，且普通用户难以觉察到。2、非基本功能用户界面提示错误。3、只会影响用户的喜好度，不会影响用户使用的问题，如颜色、界面风格等。5.5在BUGzilla管理系统内提交缺陷报告后，由测试负责人于一个工作日内完成审核：5.5.1审核提交的缺陷内容及严重程度。5.5.2整合重复、描述不清的问题，并将缺陷提交给研发负责人。5.6在BUGzilla管理系统内审核完成后，由研发经理在一个工作日内完成对缺陷的判断和任务分配。5.6.1对缺陷进行确认和分配，判断问题的优先级。编号问题状态描述1待解决发人员解决。2重复问题确认缺陷和某个已经提交的缺陷属于同一个问题，更新状态为“重复问题”，并在注释中说明与XXbug重复。3非问题bug，需求中没有要求，项目组也没有计划研发，和测试负责人确认后更新状态为非问题，并在注释中说明原因。4不做修改由于受某些技术难题、控件或研发语言等限制，无法修改或暂不修改的问题；在注释中注明原因。5.6.2将缺陷分配给相应的研发人员。5.6.3Bug的优先级是指缺陷必须被修复的紧急程度。优先级说明高会对系统引起重大问题，紧急度最高，阻止相关测试人员的进一步测试活动，阻止于此密切相关功能的进一步测试，研发必须立即解决。中正常排队，顺序解决，一般要求转下一轮测试前解决。低继高、中优先级后，资源充沛、时间允许时解决。5.7在BUGzilla管理系统内,研发工程师收到分配任务后：5.7.1分析研发负责人分配的缺陷，写出问题原因，修复缺陷。5.7.2对于重复、非问题、不做修改类等问题做标记，并在研发回复中填写原因。5.7.3对修改后的缺陷在提交测试人员正式测试验证之前进行验证测试。编号问题状态描述1已修复对缺陷已进行修复，将状态更新为“已修复。2重复问题确认缺陷和某个已经提交的缺陷属于同一个问题，更新缺陷状态为“重复问题Xg3非问题法重现时，更改状态为非问题，并在注释中说明原因。4不做修改由于受某些技术难题、控件或研发语言等原因，无法修改或暂不修改的问题；在注释中注明原因。5.7.4对有争议的缺陷（BUG）,申请产品经理组织相关人员发起缺陷评审，在缺陷评审会议上决议。5.8BUGzilla管理系统注意事项5.8.1所有缺陷的关闭必须由提单人处理为“已关闭”。5.8.2缺陷各阶段的处理人必须谨慎设置缺陷的下一状态。5.8.3项目成员在更改“问题状态”或“处理人”时，需要增加注释。5.8.4研发人员在修复问题时，务必填写【原因分析】和【修改说明】。5.8.