软件缺陷描述规范
软件缺陷描述规范
软件缺陷描述规*一、缺陷基本定义软件缺陷（Software Defect）：软件缺陷是对软件产品预期属性的偏离现象。
它包括检测缺陷和残留缺陷。
缺陷的优先性，分为5级，参考下面的方法确定：1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。
2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑；3)一般优先级(Major)，例如，本地化软件的*些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复；4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正；5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。
二、缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。
一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。
否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。
缺陷描述的原则：有效的缺陷描述有以下几个原则：➢可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；➢定位准确：缺陷描述准确，不会引起误解和歧义；➢描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；➢完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见"缺陷的格式”；➢短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。
如"在新建任务窗口中，选择直接下达，负责人收不到即时消息”中"新建任务窗口”、"直接下达”、"即时消息”等是关键词；➢特定条件：许多软件功能在通常情况下没有问题，而是在*种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或*种设置等），能够提供帮助开发人员找到原因的线索。
缺陷等级划分规定
缺陷等级划分规定１．缺陷等级划分规范１．１Bug等级种类及定义:Bug等级可分为:致命,严重,一般的,微小的四种.致命（critical）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失严重（major）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明一般的（normal）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。
如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等１．２等级划分步骤:1) 功能方面结合”缺陷发生率”(Exposure Risk)和”影响强度”(Impact Intensity)对Bug进行等级划分.”缺陷发生率”是指在运用产品过程中,出现某个缺陷的频率, 可分为四种:不可避免,经常,偶尔,很少.不可避免(Unaviodable):只要运行系统或应用程序,或者使用软件主要功能,该缺陷就能出现. 经常(Frequent):在使用软件过程中,需要通过几步操作出现,或者是一些不常用的非主要功能的缺陷,或者出现该缺陷的频率在30-70%的.偶尔(Occasional):缺陷出现的前提是通过多次操作或多个步骤,或者缺陷出现的概率在2%-30%.很少(Rare):低频率操作,或者出现的前提是通过N次操作或N个步骤,或者缺陷出现的概率低于2%的.“缺陷影响强度”是指在运用产品过程中,某个缺陷影响产品使用的程度,可分为三种:灾难性,障碍性,干扰性.灾难性(Disastrous):测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现；关键性能指标达不到要求；障碍性(Obstruction):系统的次要功能点或需求点没有实现；数据丢失或损坏。
软件缺陷分类标准
软件缺陷分类标准
软件缺陷可以根据不同的标准进行分类。
以下是一些常见的软件缺陷分类标准：
1. 功能性缺陷：指软件功能无法正常工作或不符合预期要求的问题，如某个功能无法启动、不能正确计算结果等。
2. 易用性缺陷：指软件在用户界面方面存在问题，使用户难以理解、操作或导航。
例如，界面布局混乱、操作流程不直观等。
3. 性能缺陷：指软件在执行过程中出现的性能问题，如响应时间过长、运行速度慢等。
4. 兼容性缺陷：指软件与其他系统、平台或设备之间的兼容性问题，如不能在特定操作系统上运行、与其他软件不兼容等。
5. 安全性缺陷：指软件存在的安全风险和漏洞，可能被黑客攻击或滥用。
例如，密码泄露、权限控制不完善等。
6. 可靠性缺陷：指软件在长时间运行或高负载情况下出现的故障、崩溃或数据丢失等问题。
7. 可维护性缺陷：指软件代码或结构设计方面存在的问题，使软件难以维护、扩展或修改。
例如，代码冗余、缺乏注释或文档等。
8. 其他缺陷分类标准：根据不同的软件类型和行业特点，还可以使用其他分类标准，如移动应用程序中的交互性缺陷、电子商务网站中的支付缺陷等。
对于软件开发团队来说，合理分类和标记缺陷是非常重要的，可以帮助他们更好地理解和解决问题，提高软件质量和用户满意度。
软件测试缺陷的定义、产生原因、缺陷报告格式、缺陷报告
软件测试缺陷的定义、产⽣原因、缺陷报告格式、缺陷报告软件缺陷的定义错误静态存在于说明⽂档中的表述或编码错误缺陷存在于代码中或硬件系统中的错误BUG被测对象实际表现与⽤户显性需求或隐性需求中的差异功能实现错误功能实现遗漏功能实现多余功能实现不好失效因缺陷激发后导致功能的异常，⽆法使⽤的现象（动态的，不⼀定会发⽣）缺陷产⽣的原因1. 需求表达理解、解码过程中⼀起的错误2. 系统设计架构引起的错误3. 开发过程中缺乏有效的沟通及监督4. 程序员编码过程产⽣的错误5. 软件开发⼯具本⾝的问题6. 软件需求、复杂度越来越⾼7. 与⽤户需求不符合，即使本⾝不存在某种意义上的错误缺陷的报告的书写格式缺陷ID：⽤来唯⼀表⽰缺陷的字段，⼀般使⽤阿拉伯数字，缺陷ID不可重复，并且不可服⽤概要描述：概括描述缺陷的表象或存在的形式，便于开发⼈员快速推测缺陷的产⽣原因发现⼈：缺陷的发现⼈员⼀般为测试⼯程师，也有可能是项⽬的开发⼈员，如开发⼈员、项⽬经理、维护⼈员，甚⾄是客户发现时间：缺陷发现的时间修复时间：缺陷修复的时间所属版本：发现缺陷的版本，便于后期统计不同版本之间发现的缺陷数量，以及确定测试版本的发布风险所属模块：缺陷所在的功能或业务模块，便于后期统计每个功能或业务模块的缺陷分布情况，从⽽利于回归测试投⼊确定或研发资源分配缺陷状态缺陷所存在的状态，⼀般分为6种new：缺陷尚未进⼊缺陷管理流程时，定义为new，如新发现或新提交的bugopen：经过确认后确认是BUG，缺陷正式进⼊管理流程，fix：开发⼈员却认为BUG，并且做了修复活动，ciose：缺陷经过校验，确认已被修复或⽆需处理reject：开发⼈员需对open状态的BUG进⾏判断，如果确认是缺陷，则需要进⾏修复活动，如果因需求变化，设计变化等原因导致缺陷已经不存在，则可reject次缺陷reopen：当以fix或close的缺陷未能成功修复或再次发⽣时再次打开缺陷严重度缺陷引发后果的严重程度low：缺陷导致的后果不是很严重，⼀般⽽⾔，仅是使⽤户感觉使⽤不⽅便、界⾯不美观等感受medium：⼀般的错别字，字体错误，显⽰错误，⼦功能实现错误或冗余high：某个具体功能不能正常使⽤，如查询功能错误、排序功能错误等very high：导致⼤⾯积功能⽆法使⽤urgent：⼤⾯积功能不能使⽤，终⽌性错误、初始化错误缺陷的优先级：有开发⼈员确认，决定缺陷修复的先后时间详细描述：对概要描述的补充，说明缺陷产⽣的步骤，测试数据、系统的截图等等下⼀步处理⼈：缺陷接下来由谁处理缺陷的管理⾓⾊定义定义管理流程中所涉及到的⾓⾊、主要职责、⼯作内容、范围等等如测试⼯程师、测试经理、开发⼯程师、开发经理、项⽬经理流程定义定义流程中所有⾓⾊应遵守的规则1. 测试⼯程师发现并提交BUG2. 测试经理进⾏缺陷的过滤1. 缺陷描述是否正确2. 是否是因为对需求不理解⽽造成的误提交3. 描述中是否带有个⼈感情⾊彩的词语4. 缺陷定义级别是否定义合理3.测试经理将缺陷指派给开发经理4.开发经理将缺陷指派给响应的开发⼈员5.开发⼯程师确认缺陷，如果是缺陷，则fix，如果不是缺陷，则reject并给出理由6.如果缺陷状态为fix，则测试⼯程师进⾏确认活动，如果成功，则将缺陷状态改为close，如果没有fix，则将状态改为reopen7.如果开发⼈员认为不是缺陷，测试⼈员应说明认为是缺陷的原因，如果意见不能⼀致，则由项⽬经理协调处理⼯具应⽤采⽤哪种缺陷管理⼯具，如开源（Bugzilla、jira、matins、Excel等）还是商业（QC/ALM、禅道等）模型选择ODC四象限Gompertz。
软件缺陷报告
软件缺陷报告软件缺陷报告报告编号：F2022-001报告日期：2022年10月1日1. 缺陷概述在进行软件版本1.0的测试过程中，发现了以下缺陷问题：- 缺陷名称：用户界面显示异常- 缺陷编号：D001- 缺陷等级：一般- 缺陷描述：在使用软件时，发现在某些分辨率下，用户界面显示异常，图标和文本显示错位，并且影响了用户的正常操作。
- 缺陷重现步骤：1. 在系统分辨率设置为1280x720的情况下启动软件。
2. 进入主界面，观察图标和文本的显示情况。
2. 缺陷影响范围该缺陷主要影响使用分辨率为1280x720的用户，导致用户界面显示异常，影响用户的正常操作。
3. 缺陷原因分析经过初步分析，该缺陷可能是由于软件界面的布局在不同分辨率下没有进行适配造成的。
在低分辨率下，元素的位置计算错误，导致显示异常。
4. 缺陷修复建议为了修复该缺陷问题，建议采取以下措施：- 在软件开发的初期，进行分辨率适配的设计，在不同分辨率下保持界面元素的位置稳定。
- 在软件发布前，进行全面的兼容性测试，确保在不同分辨率下都能正常显示。
5. 缺陷修复计划为了修复该缺陷问题，我们制定了以下修复计划：- 预计修复时间：2022年10月10日- 修复方式：开发团队将对软件界面进行适配调整，修复图标和文本错位的问题。
- 修复验收标准：修复后的软件在分辨率1280x720下应能正常显示，图标和文本位置稳定。
6. 缺陷验证计划为了验证修复效果，我们将进行以下验证计划：- 验证时间：2022年10月11日至2022年10月15日- 验证步骤：1. 设置系统分辨率为1280x720。
2. 安装修复后的软件版本。
3. 进入主界面，观察图标和文本的显示情况。
4. 与修复前的软件对比，确认是否修复成功。
7. 其他建议为了提高软件的稳定性和用户体验，建议开发团队在后续版本迭代中加强对不同分辨率的兼容性测试，避免类似问题的再次出现。
本缺陷报告将在修复后进行关闭，并确认修复效果。
软件缺陷分类标准(最新)
软件缺陷分类标准修订历史记录目录1. 引言 (3)1.1 编写目的 (3)1.2 定义与缩写 (3)1.3 参考资料 (4)2. 软件缺陷分类标准 (4)2.1 问题类型 (4)2.2 缺陷属性 (4)2.3 缺陷类型 (4)2.4 缺陷严重程度 (6)2.5 缺陷优先级 (8)2.6 缺陷状态 (8)2.7 缺陷来源、起源 (9)2.8 缺陷根源 (9)2.9 缺陷产生可能性 (10)1.引言1.1编写目的制定本标准的目的是为软件测试提供确信分类的标准。
本文档说明了问题类型、缺陷属性、确缺陷类型、缺陷严重级别、缺陷优先级、缺陷状态、缺陷修改次数、缺陷原因。
其预期的读者是测试人员、开发人员、开发经理。
1.2定义与缩写1.3参考资料表格1-2 参考资料列表2.软件缺陷分类标准2.1问题类型表格2-1 问题类型表格2.2缺陷属性软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷状态、缺2.3缺陷类型2.4缺陷严重程度缺陷严重程度:指因缺陷引起的鼓掌对软件产品的影响程度。
2.5缺陷优先级2.6缺陷状态2.7缺陷来源、起源缺陷来源：缺陷引起的故障或事件第一次被检测的阶段，有需求说明书、设计文档、系统集成接口、数据流（库）、程序代码。
缺陷起源：在团建生命周期中软件缺陷占的比例：需求和构架设计阶段占54%、设计阶2.8缺陷根源缺陷根源：测试策略，过程、工具和方法，团队\人，缺乏组织和通讯，硬件，软件，工作环境等造成上述错误的根本因素，以寻求开发、测试人员可改进的地方。
2.9缺陷产生可能性表2-9 缺陷产生可能性。
软件缺陷管理制度
软件缺陷管理制度软件项目测试组修订历史记录目录软件缺陷管理制度····························································································错误!未定义书签。
修订历史记录····································································································错误!未定义书签。
缺陷管理工具CQ使用规范
11.1 缺陷记录信息对缺陷的描述包含以下的内容：展现层错误、未实现、未容错 控制层错误、未实现、未容错 业务层错误、未实现、未容错 数据层错误、未实现、未容错功能性1 惟一的缺陷 ID ，可以根据该 ID 追踪缺陷 缺陷的状态，分为 11 种(见 3.2.8 节) 对缺陷简单描述缺陷所属类型(见 3.2.1 节)缺陷的严重程度， 普通分为“致命”、 “严重”、 “一 般”、“轻微”和“其它”五种(见 3.2.2 节) 引入缺陷的开辟阶段(见 3.2.3 节) 发现缺陷时所属的阶段(见 3.2.4 节) 重现缺陷的步骤对缺陷的详细描述； 因为对缺陷描述的详细程度直接影 响开辟人员对缺陷的修改，描述应该尽可能详细 发现缺陷时产品的内部版本号发布给客户使用的版本号。
在缺陷提交后，由项目经理/开辟经理指定修复缺陷的 责任人项目经理/开辟经理指定修复缺陷的截止日期缺陷的紧急程度， 修复的优先级， 从 1－3，1 是优先级 最高的等级， 3 是优先级最低的等级(见 3.2.6 节) 对修复内容(将什么改成什么)的描述，如果对代码进行 了修改，要求在此处体现出修改排除缺陷的解决方案类型(见 3.2.7 节) 修复缺陷时所属的阶段(见 3.2.5 节) 估计修复该缺陷所需的工时 修复该缺陷实际使用的工时缺陷关闭后，项目经理/开辟经理评估修复缺陷所花的 工作量和修复缺陷的工作质量项目经理/开辟经理对缺陷修复工作量和工作质量的评 估赋予必要的解释说明缺陷 ID 缺陷状态 标题 缺陷类型严重程度缺陷来源 发现阶段 重现步骤现象描述内部版本号外部(正式)版本号修复责任人修复期限优先级修复描述解决方案 排除阶段 估计工时 实际工时 工作分数 工作量系数 工作质量系数 工作分数评估描述功能实现不完整 功能实现错误 数据不一致数据不完整 数据重复信息填充错误 业务流程操作繁琐 界面布局不合理 操作不习惯 tab 键顺序不合理尽量保证一屏能显示，横向滚动条尽量避免，违反此规范的缺陷提示信息不充分，或者不友好，甚至错误提示 按钮摆放位置不符合正常习惯设计图标，展示不符合常规，给人误解 布局设计不合理(静态页面显示) 风格不统一图片、色调不符合业务系统要求 系统的故障恢复艰难可维护性系统的升级操作艰难 系统的响应时间差 并发处理性能差 过负荷处理处理机制差致命是指系统任何一个主要功能彻底丧失，或者用户数据受到破坏，造成 系统崩溃、悬挂、死机或者危机人身安全。
软件缺陷等级标准
软件缺陷等级标准按照CMM5中定义的规范，BUG一般分致命，严重，一般和提示。
致命是严重影响产品的BUG，比如操作手册的错误，需求的错误等。
严重是产品中使功能无法实现的BUG，比如某个功能无法运行，GUI长时间僵死没有响应。
一般是某个BUG的发生，只影响了一个功能，而其他功能可以正常运行。
提示就是一些GUI的问题，或者友好性的问题。
更为详细的划分如下:A类—严重错误，包括以下各种错误：1．由于程序所引起的死机,非法退出2．死循环3．数据库发生死锁4．因错误操作导致的程序中断5．功能错误6．与数据库连接错误7．数据通讯错误-----------------------------------------------------------B类—较严重错误，包括以下各种错误：1．程序错误2．程序接口错误3．数据库的表、业务规则、缺省值未加完整性等约束条件-----------------------------------------------------------C类—一般性错误，包括以下各种错误：1．操作界面错误（包括数据窗口内列名定义、含义是否一致）2．打印内容、格式错误3．简单的输入限制未放在前台进行控制4．删除操作未给出提示5．数据库表中有过多的空字段-----------------------------------------------------------D类—较小错误，包括以下各种错误：1．界面不规范2．辅助说明描述不清楚3．输入输出不规范4．长操作未给用户提示5．提示窗口文字未采用行业术语6．可输入区域和只读区域没有明显的区分标志 E类—测试建议。
软件测试缺陷管理规范
目录1 背景 (2)1.1 推行目的 (2)1.2 适用范围 (2)1.3 术语定义 (2)2 缺陷分类标准 (2)2.1 缺陷类型 (2)2.2 缺陷严重程度 (3)2.3 缺陷优先级 (3)2.4 缺陷状态 (3)2.5 缺陷来源 (4)2.6 缺陷复现率 (4)3 缺陷提交规范 (4)3.1 缺陷所属 (4)3.2 缺陷标题 (5)3.3 缺陷内容 (5)3.4 缺陷指派 (5)3.5 缺陷类型 (5)3.6 缺陷严重程度和优先级 (6)3.7 缺陷来源 (6)4 缺陷管理规范 (6)4.1 缺陷所属管理 (6)4.2 缺陷时效化 (6)4.3 未关闭缺陷的处理 (6)4.4 非系统测试缺陷的处理 (7)1 背景1.1 推行目的缺陷是产品与规定要求不相符的部分，会存在于软件产品的整个生命周期中，本文规范软件测试过程中的出现的缺陷，通过测试活动及早发现软件系统中的缺陷，并确保缺陷被有效标识、跟踪、和修改，保证软件系统能够达到要求的质量。
1.2 适用范围本文档适用于公司项目研发以及项目运行过程中的缺陷管理。
1.3 术语定义2 缺陷分类标准2.1 缺陷类型2.2 缺陷严重程度2.3 缺陷优先级2.4 缺陷状态2.5 缺陷来源2.6 缺陷复现率3 缺陷提交规范3.1 缺陷所属在提交缺陷时，需要严格按照缺陷所属的产品、项目、版本、模块进行填写，不能不进行填写，此举是为了在后续进行总结时进行缺陷分析。
3.2 缺陷标题注意：在提交一条缺陷前，应检查缺陷库是否已经存在此缺陷，避免重复提交。
缺陷标题应该尽量简洁明了，以最少的文字描述出缺陷结果，标题应该避免长篇大论、文字过多，具体复现步骤和补充说明可以放在缺陷内容描述中。
必要时缺陷标题中可以加入约定好的标签信息，如模块、类别等。
以下为缺陷标题举例：3.3 缺陷内容缺陷内容主要包括操作步骤、实际结果、预期结果。
操作步骤：按照分步的方式描述复现缺陷的操作以及数据、环境等信息。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件缺陷描述规范一、缺陷基本定义软件缺陷（Software Defect）：软件缺陷是对软件产品预期属性的偏离现象。
它包括检测缺陷和残留缺陷。
缺陷的优先性，分为5级，参考下面的方法确定：1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。
2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑；3)一般优先级(Major)，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复；4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正；5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。
缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。
一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。
否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。
缺陷描述的原则：有效的缺陷描述有以下几个原则：可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；定位准确：缺陷描述准确，不会引起误解和歧义；描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见“缺陷的格式”；短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。
如“在新建任务窗口中，选择直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“即时消息”等是关键词；特定条件：许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。
如“网站在和的兼容问题”；不做评价：在软件缺陷描述不要带有个人观点，对开发软件进行评价。
软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。
1.缺陷的格式：提交一条缺陷后，最好能够再检查一遍缺陷格式是否有问题。
常见的格式问题如下：问题摘要中不能有句号；问题摘要后不要有空格，直接填写内容；问题摘要比较长时，可以用“，”分隔；详细描述中序号后面“.”一定是半角的宋体，不是全角符号，并且后面不要再有空格；详细描述中分号一定要使用全角的分号；详细描述中的“->”应统一。
应在英文输入法的半角状态下输入箭头；注意缺陷中不要出现错别字，例如“登陆”应写为“登录”。
2.缺陷描述常见的问题：问题摘要过长，不够简练、准确；问题摘要与详细描述的内容不一致；详细描述不清楚，无法复现；详细描述冗长，不宜于理解；缺陷定位不正确；缺陷等级定位错误；缺陷的类型定位不正确；不是缺陷。
三、 缺陷管理1. 缺陷跟踪缺陷的提交人，实时跟踪缺陷状态，对开发人员提出的疑问，及时作出回答； 及时更新缺陷状态。
缺陷生命周期开发人员项目经理测试人员发现BUG提交BUG判断修复缺陷关闭缺陷回归测试确认缺陷Open AssignReOpenedClosedWon't FixFixed四、缺陷示例缺陷优先级会涉及从Critical到Trivial，严重程度等级会涉及从S1到S5。
一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。
有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。
例如，公司名字和软件产品徽标是重要的，一旦它们误用了，这种缺陷是用户界面的产品缺陷，并不影响用户使用。
但是它影响公司形象和产品形象，因此这也是优先级高的软件缺陷。
通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。
但实际上，优先级和严重程度是有联系也有区别。
严重程度高的，必然优先级也要高，但优先级高的，严重程度却并非也一定高。
1.功能性：1）S1级/Critical导致系统崩溃：执行正常操作或者误操作后，导致整个系统，或者大部分模块无法正常使用：问题摘要：为一个子部门设置一个网站签收员，再在人事管理中将该用户删除，导致程序加载不上详细描述：1.组织架构中，新建一个部门，为该部门指定一个网站签收员；2.进入人事“用户后台管理”，找到该用户，并将该用户删除；3.重新登录，系统提示断开，无法登录系统。
导致死机：执行正常操作或者误操作后，导致死机：问题摘要：通过地址簿填写多个收信人时导致所有程序无法响应详细描述：1.建立新邮件，单击“收信人”按钮，查找电子邮件地址；2.双击添加多个联系人地址时，程序无法响应，同时也无法执行其他应用程序，必须重新启动机器。
主业务流程出现断点：业务流程可以分为主业务流程和一般业务流程，是根据功能在流程中的重要程度进行区分的，例如在OA办公系统中，发文后无法收文应该是主业务流程的问题，收文后归档存在问题，则是流程的一个分支，属于一般业务流程：问题摘要：打开公文时，系统报错详细描述：1.公文流转中，选择一个公文双击打开，系统报错：有关调用实时(JIT)调试而不是此对话框的详细信息，请参见此消息的结尾。
************** 异常文本 **************……************** 已加载的程序集 **************出现不可挽救的数据丢失或损坏；内存泄漏；2）S2级/Blocker：发现影响被测模块正确运行的严重问题；导致程序模块丢失或未实现：执行正常操作或者误操作后，导致部分模块丢失，或者某个模块功能未实现：问题摘要：火炬计划中的“项目管理”模块功能未实现详细描述：登录系统，进入火炬计划->项目管理，其页面为“项目（课题）授权管理”的页面，“项目管理”功能未实现。
被测数据处理错误：如果数据处理错误导致模块级的问题，或者对系统的影响重大，例如下例中职工住房补贴重要的数据计算出错，缺陷的等级应该是S2；如果数据错误造成的影响不大，则可以定义为S3；问题摘要：补贴方式为达标、超标的职工的二次职级晋升出错详细描述：1）进入补贴管理->信息维护->职级晋升维护；2）选择补贴方式为达标或超标的职工进行第一次晋升，使级差面积大于0；3）再次进行晋升，查看级差面积，预期结果：级差面积=这次晋升的标准-上次晋升的标准（或最高标准）；实际结果：级差面积=这次晋升的标准-原始的标准。
软件错误导致数据丢失：问题摘要：工作表最大行数的兼容问题详细描述：1.在Office XP工作表中最大行数为65536行，而共创Office 2005的电子表格中工作表最大行数为32000行；2.当用共创Office 2005打开Office XP文档时会自动去掉32000行以后的行数以及数据，造成数据丢失。
用户需求未实现：没有实现用户需求规格说明书或者特定文档中规定的功能：问题摘要：编码管理员不应具有问题管理的权限详细描述：按照《权限角色设定》，编码管理员不应具有“问题管理”模块的权限。
以编码管理员的身份登录系统，可以执行“问题管理”的所有操作。
一般业务流程出现断点：问题摘要：国家重点新产品中无法浏览项目详细信息，造成流程出现断点详细描述：1.登录系统，点击国家重点新产品->新产品申请表；2.点击某记录的“项目名称”，出现页面“Error 404-Not Found”，功能没有实现，造成流程出现断点。
异常退出：执行正常操作或者误操作后，系统异常退出：问题摘要：编辑邮件回复时系统异常退出详细描述：1.打开收件箱中的任意邮件，选择编辑->选中所有文字；2.点击“回复”，系统异常退出。
直接点击“新建”按钮，建新邮件也会出现同样问题。
3）S3级：发现影响被测功能正确实现的问题；功能未实现：某项功能点的功能没有实现，例如点击某个按钮系统没有响应、设置某项功能后无效、无法执行某项操作等等：问题摘要：执行码表管理中“新增码表数据”系统无响应详细描述：1.进入“参数管理模块->码表管理->类型A”；2.点击“新增码表数据”系统无反应，无法实现此功能。
“类型B”页面存在同样问题。
问题摘要：角色授权无效详细描述：1.进入“权限管理模块->角色授权”，授权给角色“sss”以“全部可以查询”的权限；2.在“角色分配”中分配给该角色以人员“1”；3.使用人员“1”登录系统，查看各模块，仍然可以编辑修改信息，不是仅查询的权限。
问题摘要：实时信息中“最新提交报告信息”页面的返回按钮没有效果详细描述：1.进入“决策支持->实时信息服务”，直接显示“最新提交报告信息”页面；2.点击“返回”，系统刷新后仍显示本页面，返回按钮没有效果。
问题摘要：退单受理时无法提交详细描述：1.进入“综合值班->值班事件->退单受理”；2.选择一条退单数据，显示“退单事件修改”；3.点击“完成”，系统提示错误信息“为空或不是对象”，无法提交受理退单。
功能实现不正确；问题摘要：系统配置打印机校准设置的问题详细描述：1.进入系统->系统配置；2.在“打印机校准”方式中选择“启动时自动校准打印机”，点击“确认”；3.重新进入系统配置页面，打印机校准方式并不是刚才保存的“启动时自动校准打印机”，而是“不校准打印机使用操作系统默认值”。
问题摘要：发件箱中按“所属城区”查询错误详细描述：1.进入“测试委办局->发件箱”；2.设置“所属城区”查询条件，查询结果显示“没有符合条件的数据”，而实际存在符合条件的数据。
问题摘要：信息发布中“发布”功能问题详细描述：1.进入“市政基础设施资源管理系统->报表管理->信息发布->内部报表->期末燃气用户拥有量”页面；2.设置“2006”年“3”月，点击“发布”，显示“期末燃气拥有量”表，表中无有效数据，但页面下方的统计图显示效果和图中数据与上表不符。
其它信息发布页面中的“发布”功能存在同样问题。
数据处理错误，但对系统的影响不大；问题摘要：查询发件箱中统计结果不正确详细描述：1.进入“测试委办局->发件箱”；2.设置查询条件，查询后的统计结果比实际结果少一条记录。
问题摘要：班级成绩统计中，某些平均成绩的值没有进行四舍五入详细描述：班级成绩统计中，某些平均成绩的值没有进行四舍五入，例如：1.在“参数设置与库操作”界面中，执行“导入样品数据库”操作；2.在一班中增加两条学生记录，学号39，姓名a，语文75，数学0，物理0，化学0，英语0；学号40，姓名b，语文0，数学0，物理0，化学0，英语0；3.在“班级成绩”界面中，显示班级总人数40人，语文总成绩，平均成绩的值应该为40=，四舍五入后为，但界面中实际结果为，没有进行四舍五入。