软件缺陷管理规范.docx

《软件缺陷管理规范.docx》由会员分享，可在线阅读，更多相关《软件缺陷管理规范.docx（14页珍藏版）》请在三一办公上搜索。

1、软件缺陷管理规范(IS09001： 2022)1 .目的本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规 范性，以保证项目研发质量。2 .合用范围合用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规 范。3 .定义3 . 1术语缺陷(Defect)：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。Bug：缺陷一种表现形态，系统或者程序存在的任何一种破坏正常运转能力的问题。4 .2缺陷定义(1)软件未达到需求规格说明书的功能；(2)软件浮现了需求规格说明书指明不会浮现的错误；(3)软件功能超出需求规格说明书的范围；(4)软件未达到需求规格说明书未指出但

2、应达到的目标；(5)测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认 为不好。4 .缺陷生命周期4.1 缺陷生命周期图4.2缺陷状态说明缺陷状态状态说明激活状态缺陷的初始状态，或者重新被激活的状态。激活状态的缺陷可以通过编辑来修改缺陷内容，并指派给合 适的工程师处理。解决状态缺陷被解决之后的状态。激活状态的缺陷经过成功修复以后，由开辟工程师操作为解 决状态，系统将自动指派回创建者。关闭状态解决状态的缺陷在验证通过后关闭，缺陷状态变为关闭，生命周期结束。如果验证未修复或者新版本又发生，则重新激活，缺陷状态重新变为激活。5 .缺陷处理过程5.1 正常处理过程(1)创建问题在测试管理

3、系统中，所实用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清晰，并选择正确的选项，详细请参考5. 4和5. 5。(2)指派问题创建问题时，创建者通常要指派给该项目开辟负责人，再由其指派任务，或者 直接指派给相应模块的开辟工程师。如果指派人是错误的，或者需要他人确认或者匡助，则可以重新指派给合适的 工程师，写上相关备注。(3)确认问题通常开辟工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug, 则选择“确认状态”；如果认为非Bug,则注明原因并指派回创建者。当创建者收到确认指派时，需要进行及时确认。如果允许为非bug,则及时关闭 它；如果不允许，则需要注明理

4、由并指派回相关工程师。如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考 5.2o(4)解决问题此为开辟工程师的主要职责，包括BUg的复现、修改和修改验证。 开辟工程师需要及时对确认状态BUg进行分析和解决，并自己验证通过，则操作 为解决状态，解决方案规则请参考5.4中解决方案定义部份，在缺陷管理系统中 解决方案选择相应的选项，解决后系统将自动指派回给创建者。如果BUg无法解决或者修改影响比较大，可申请进入“延期解决”流程，请参考 5.2中延期处理部份。(5) 验证问题创建者需要及时对解决状态的BUg在对应版本上面进行验证。如果验证通过，则 可关闭Bug；如果验证不通过，则激

5、活此Bug,系统将自动指派回给解决者。验证通过准则：相同的操作步骤，进行一定次数的验证测试都没有发生。验证不通过准则：相同的操作步骤，全部或者部份实际结果还会发生，验证不 通过则激活Bug0(6)关闭问题通过验证的Bug,验证者需要注明验证结果并进行关闭操作，系统将指派给 Closedo如果关闭状态的BUg在之后版本又会发生，则激活此Bug,系统将自动指派回给 解决者。5. 2特殊处理过程(1)客户问题客户反馈的问题可以由客户直接反馈或者项目经理、市场部等了解到的客户问题, 经确认后的BUg提交到测试管理系统，按照以上处理流程进行处理，由创建者或 者测试组进行跟踪验证关闭。创建客户问题时，创建

6、者需要在BUg标题开头标记为客户问题,测试组负责检 查和更正。(2)争议处理当开辟和测试工程师对某问题有争议并且多次沟通无果时(暂定为6次)，可以 注明双方的理由，并指派给项目经理进行处理。项目经理可以召开评审会议，或者直接与双方沟通了解，并根据项目情况给出 专业意见和最终决定。开辟和测试工程师根据项目经理的最终决定执行。(3)延期解决当开辟工程师对确认BUg进行解决时，发现或者评估其解决时间紧或者风险比 较大 等，可以说明原因或者理由并指派给项目经理来确认。项目经理可以召开评审会议，或者直接沟通了解，并根据项目情况给出最终决 定。如果不允许，项目经理将此BUg指派回开辟工程师，开辟工程师继续

7、分析和 解决。如果允许，项目经理需要在BUg标题开头标记为延期解决和在处理状态 选择“延期解决”，然后注明解决时间计划并指派回开辟工程师，开辟工程师根 据解决时间计划来规划和解决此Bug。5. 3缺陷管理工具软件测试过程中所有缺陷要提交到公司测试管理系统进行跟踪管理。(1) 管理工具的作用a.确保每一个被发现的缺陷都能够被跟踪与处理。 b.采集缺陷数据并根据缺陷趋势曲线识别或者报告测试状态。c.采集缺陷数据并在其上进行数据分析，作为测试评估的依据。(2)缺陷驱动原则缺陷管理系统主要通过指派状态来驱动相关开辟工程师、测试工程师和项目经 理尽快地处理问题，以提高研发效率，所以会特殊关注缺陷指派给谁

8、和停留时 间，并反馈在定期报告。所以，缺陷驱动原则：尽量不要让缺陷挂在你身上。5. 4.缺陷属性定义(1)缺陷相关属性缺陷属性说明缺陷ID缺陷ID是标记某个缺陷的一组符号。每一个缺陷必须有一个 唯一的TD缺陷类型缺陷斗型是根据副陷的自缺属性划分的缺陷种举严重程度缺陷语重程序显指因缺陷引赳的失效对软件产品的影响租席发生概率rid / JttMRU5 日 try J Vf C O JA 1 J， UU 0 JmU i fX. U皓陷发牛概率指缺陷按照测试樨作步骤发牛的概率情况C解决方案缺陷解决 方案显指缺陷被解冲掠 的处珅方案缺陷描述UjrvrfclTVW ZJ VFi ti J N lX. P5

9、 BX/tT IJ- UV 9kL上(2) 缺陷类型说明类型名称说明设计缺陷由于软件设计或者代码实现所产生的功能或者流程的问界面问题题。系统页面的展示的问题。数据问题系统数据的来源，处理及处理结果的问题。需求问题软件需求测试发现的问题，也包括之后需求变更的问题。安装部署软件安装部署过程的错误。性能问题软件性能相关的缺陷。文档问题用户使用手册，软件匡助文档等浮现的问题常识问题系统用户的正常使用习惯相关问题。安全问题系统漏洞安全问题。优化建议针对操作过程逻辑或者界面显示的优化性建议。其他除前面分类的其他问题(3)严重程度定义严重程度定义和说明致命妨碍开辟或者测试工作继续进行的系统性故障，例如：实现

10、的功能与产品定义或者软件需求规格严重不符。A系统无法执行、崩溃、冻结，死循环等。A程序引起的死机，非法退出。A主要功能模块严重错误。A数据库链接错误，严重数据计算错误通讯错误等。严重系统浮现的严重错误，但不影响当前测试工作的错误。例如：A模块功能错误，模块功能未实现，乱码等；A功能错误，如链接模块有误，基本按键使用有误等。A数据错误，如用户数据丢失、破坏、计算、保存有误等。普通不影响用户使用的非严重问题A次要功能未实现或者与需求不符。A操作界面错误，如界面图表或者字符的普通性错误，但彳 影响操作。A提示信息错误，辅助说明不清晰。A数据错误，数据边界、格式约束未实现或者需求不一致建议测试过程中发

11、现不利用户操作的优化建议。A界面字符或者提示与的显示不恰当。A页面或者操作习惯的优化性建议。A功能操作更好的实现方式。注：严重等级由创建者在创建缺陷时根据此定义来选择，之后都不能随意更改。(5)优先级的定义优先级定义和说明立刻妨碍测试工作无法进行，需要开辟工程师即将解决问题。A所有的致命问题都需要立刻解决；A时间急迫时影响版本上线的问题等；紧急不影响测试工作的严重问题，下个测试版本发版前必须解 决。A所有严重问题；A常用模块功能、业务逻辑或者数据错误；A明显的性能问题；尽快普通性功能错误，版本发布前应该解决的问题。A大多数普通问题；A页面显示，页面的字符，界面图标、文字显示、链接有 误，不影响

12、使用。如错别字，图标显示异常等；普通不影响版本上线的问题，部份问题允许不修改。A非常用界面或者字符的显示错误或者不恰当注：立刻、紧急、尽快的问题都要求在系统上线前解决。发生概率定义发生概率定义说明验证问题最小次数必现100%o测试5次，浮现5次。5次时常100%&=30%o测试5次，浮现34次；或者测试10次，浮现3次及以上；或者测试15次，浮现5次及以上。10次偶尔30%fe=10%o测试10次,浮现2次；或者测试15次，浮现2次。20次4随机10%o测试15次，浮现1次。30次处理状态说明处理状态相关规则确认中当问题确认过程时，可以选择这状态来说明。解决中开辟工程师设置此状态。当Bug正在

13、分析或者解决时，可选 这状木平不明复现中TJtl p*zu当正在复现问题，或者正在跟踪测试问题，可以选择这状态 来说明。验证中当验证随机问题等需要长期，可以选择这状态来说明。延期解决项目经理才干设置此状态，参考5.2(8)解决方案定义与规则解决方案方案说明相关规则已经解决缺陷被修复或者更正，并 过其验证测试。开辟工程师权限，解决时需要填 写“解决版本”和注明Bug原因 等。重复缺陷相同的缺陷别人已经提交，或者开辟认为原因是相同的开辟工程师权限，解决时需要填 写正确的重复缺陷ID。无效缺陷设计如此，不是问题，优 化建议不采用，没法解决 的第三方问题。开辟工程师需要与创建者沟通说 明，直到创建者允

14、许，开辟工程 师才干选择此方案。无法复现开辟和测试工程师没法 复现又不能解决的问题， 并且跟踪测试二个以上 版本也不能复现。开辟和测试工程师经过努力也不 能复现，并由测试工程师跟踪测 试二个以上版本，开辟工程师才 能选择此方案。延期解决开辟工程师BUg进行解决时，发现或者评估其解决 时间紧或者风险比较大等， 向项目经理的权限，项目经理综合 通过考虑解决问题的时间、风险、 市场需求等多方面要素决定是否 选择此方案注：无法复现问题将作为风险评估点。5. 5缺陷描述规范(1)缺陷标题缺陷标题是对所提交缺陷的概述，需要简短而准确的描述出缺陷概要信息，并 使用一些精炼的关键词，主要内容包括：位置+对象+

15、动作+现象。a.环境关键词：包括数据环境，时间环境，地点环境条件环境，描述缺陷发生 时所处的背景环境，或者正在执行的操作或者所处的界面环境，如“在”页 面，当时”，在过程中”等；b.动作关键词：引起缺陷所执行的操作，如“点键” “选选项”等；c.对象的关键词：描述缺陷浮现的对象，“页面”，“显示框”，“图表” 等；d.现象的关键词：描述缺陷浮现的现象，如“显示为负数”，“卡死”等。 根据上述关键词的组合来描写缺陷标题。(2)重现步骤在描述缺陷重现步骤的过程中，通常需要通过描述前提条件，测试步骤，实际 结果，期望结果这四个方面清晰详细的描述缺陷。a.前提条件外部环境，这里包括网络环境，硬件环境和

16、软件环境的状态。默认情况下，无 需特殊说明，前提条件均为“系统正常运行”，其含义为网络正常，电脑硬件 环境能支撑软件运行，系统软件配置情况正常。需要注意，软件环境有可能引 发缺陷的功能模块所处的状态，以及重现该缺陷需要的模块相关状态或者特殊 设置情况应该前在前提条件中做说明。数据环境，对缺陷产生的所在案件或者引起bug现象的数据输入和数据设计等应 该在前提条件中做相应说明。总之，这里对缺陷现象重现密切相关的预先设置，或者与缺陷模块相关联的预 先设置都应该在前提条件中说明。b测试步骤这里需要详细描述出重现缺陷的操作步骤，以便于重现缺陷，修复和验证缺陷。 在描写测试步骤时应该注意以下几点：精简：只

17、描述缺陷必须的细节；单一：每一个缺陷单只报告一个缺陷； 步骤清晰：详细的、有序的描述出每一个步骤，包括输入的数据情况，执行的 操作以及执行操作的界面。操作量化：对操作次数的描述需要量化，如“连续3次点确认键”等，尽量避免 浮现“多次”等含糊的词。C.实际结果实际结果是指按照测试步骤操作后实际反映的情况，这里指的是缺陷的表现现 象。这里应该详细描述出错误的现象，包括页面错误，连接错误，字符错误， 业务流程错误，数据错误等。d.期望结果期望结果是指按照测试步骤操作，正常情况下正确执行测试步骤后应该满足设 计要求的结果。对于不确定的期望结果就需要用到如建议，提示等关键字。(3)附件为了方便开辟工程师分析和解决，创建缺陷时需要添加必要的附件，包括缺陷 现象图、测试的数据文档，测试时用到的其他特殊文件，测试脚本，操作步骤 的录相等。所以，测试人员在测试的过程中，要求每一个缺陷有现象截图，以便协助开辟 人员快速定位问题。