2_软件缺陷管理
软件工程中的软件质量控制与缺陷管理
软件工程中的软件质量控制与缺陷管理软件质量控制与缺陷管理是软件工程中至关重要的环节，它们对于保证软件开发项目的顺利进行以及交付高质量的软件产品具有重要意义。
本文将从软件质量控制和缺陷管理两个方面进行探讨，以帮助读者更好地理解和应用于实践中。
一、软件质量控制软件质量控制是指在软件开发过程中，通过不断监测、评估和改进，确保软件产品达到既定质量要求的过程。
软件质量控制包括以下几个关键的环节：1. 需求管理：在软件开发的初期，清晰、明确地定义用户需求是确保软件质量的基础。
需求管理包括需求获取、需求分析、需求验证和需求变更控制等环节。
在需求获取过程中，开发团队与用户积极沟通，确保获取准确的需求信息；需求分析阶段则通过分解和整合需求，将之转化为可执行的任务；需求验证和需求变更控制则确保最终交付的软件产品与用户期望一致。
2. 设计评审：在软件设计过程中，进行设计评审是确保软件质量的重要手段。
设计评审旨在评估软件设计的正确性、完整性、可行性以及可维护性等方面，通过检查和评估设计文档、源代码等，发现潜在的设计缺陷并及时纠正。
3. 编码规范：编码规范对于软件质量的控制具有重要作用。
通过制定统一的编码规范，确保团队成员在开发过程中遵循相同的编码风格，减少因为编码规范不一致而导致的错误和缺陷。
4. 单元测试：单元测试是对软件开发过程中最小的可测试单元进行测试，以确保各个单元的功能正确性和稳定性。
单元测试通常由开发人员编写，并在代码提交到版本控制系统之前进行。
通过单元测试，可以尽早地发现并解决代码中的错误和缺陷，提高软件的质量。
5. 集成测试：集成测试是在软件开发的后期，对各个组件或模块进行整合测试的过程。
通过集成测试，可以发现各个组件之间的接口问题，保证整个软件系统的功能正确性和稳定性。
6. 系统测试：系统测试是在软件开发的末期，对整个软件系统进行测试的过程。
系统测试旨在评估软件是否满足用户需求，并验证其在不同环境下的性能、稳定性和可靠性等方面。
软件测试中的缺陷跟踪与管理
软件测试中的缺陷跟踪与管理在软件开发的过程中，软件测试是一个不可或缺的环节。
而在软件测试中，缺陷的跟踪与管理显得尤为重要。
本文将介绍软件测试中的缺陷跟踪与管理的重要性，并探讨如何有效地进行跟踪与管理。
一、缺陷跟踪与管理的重要性在软件测试中，缺陷是无法避免的。
而对于这些缺陷，合理地进行跟踪与管理可以带来以下几个重要的好处：1. 提高软件质量：通过及时发现和解决缺陷，可以大幅度提高软件的质量。
跟踪和管理缺陷可以帮助开发团队更好地理解和分析缺陷，进而采取相应的措施进行修复。
2. 提升开发效率：在软件开发过程中，开发人员往往需要对已发现的缺陷进行修复。
而对于未经跟踪和管理的缺陷，开发人员可能会出现对同一个缺陷进行重复修复的情况，这样会浪费开发资源并降低开发效率。
通过缺陷跟踪和管理，可以准确地记录和追踪缺陷，避免重复修复，提升开发效率。
3. 促进团队协作：软件测试是一个团队合作的过程，缺陷跟踪与管理可以促进团队成员之间的协作与沟通。
通过记录和共享缺陷信息，不同角色的团队成员可以更好地理解和协作，从而提高整个团队的工作效率。
二、缺陷跟踪与管理的具体方法在软件测试中，可以采用多种方法进行缺陷跟踪与管理。
下面将介绍几种常用的方法：1. 缺陷报告：缺陷报告是记录和描述缺陷的关键工具。
一个有效的缺陷报告应该包含以下信息：缺陷的描述、复现步骤、环境信息、严重程度评估、优先级评估等。
通过准确地描述缺陷的特点和现象，有助于开发团队更好地理解和解决缺陷。
2. 缺陷管理工具：使用专业的缺陷管理工具可以提高缺陷跟踪与管理的效率和准确性。
这类工具通常具备以下功能：缺陷报告的创建与分配、缺陷状态的管理与更新、缺陷统计与分析等。
通过使用缺陷管理工具，可以更好地跟踪和管理缺陷，并对整个软件测试过程进行有效的监控。
3. 定期会议：定期召开缺陷相关的会议可以促进团队成员之间的交流与合作。
在会议中，可以对已发现的缺陷进行讨论，并共同决定下一步的解决方案。
如何进行软件缺陷管理
如何进行软件缺陷管理在软件开发过程中，难免出现各种各样的错误和缺陷。
如果不及时发现和处理这些问题，不仅会影响软件的稳定性和质量，而且也会给用户带来极大的困扰甚至造成经济损失。
所以，对软件缺陷的管理至关重要。
那么，如何进行软件缺陷管理呢？一、制定缺陷管理计划制定缺陷管理计划是软件开发的必要步骤。
制定计划可以让开发团队对缺陷的处理有一个清晰的认识，明确责任分工，为后续的缺陷管理工作打下基础。
制定缺陷管理计划需要考虑以下内容：1. 缺陷管理流程；2. 缺陷管理工具的选择；3. 缺陷管理的时间和资源预算；4. 缺陷管理工作的人员分配；5. 缺陷管理的角色和责任；6. 缺陷管理报告的生成和发布。
二、实施缺陷管理实施缺陷管理是软件开发的重要步骤之一。
在实施缺陷管理过程中，需要遵循以下原则：1. 及时发现缺陷：团队中的每个成员都应该积极关注软件的运行情况，发现任何问题应立即上报；2. 记录所有缺陷：对于发现的每一个缺陷都应该进行记录，以便后续的跟进和追踪；3. 对缺陷进行分类和重要性排序：对缺陷进行分类可以更好地进行优先级的排序，为软件缺陷的修复提供有力的支持；4. 确定缺陷的责任人：每一个缺陷都应该有一个负责人，负责对缺陷进行跟踪和处理；5. 完成缺陷修复并验证：对于已经修复的缺陷，应该进行验证，确保缺陷已经被完全修复。
三、缺陷管理要点1. 缺陷报告格式缺陷报告应该以清晰简洁的形式呈现，报告应该对软件bug进行详细描述，并尽可能包含以下内容：1)缺陷原因。
2)缺陷的状态。
3)缺陷的优先级。
4)缺陷的等级。
5)修复缺陷所需时间。
6)负责人。
7)其他备注信息。
2. 缺陷管理分类在软件开发过程中，对缺陷管理进行分类有助于更好地对缺陷进行处理和跟踪。
通常，缺陷的分类可以分为以下几个方面：1)缺陷的严重程度；2)缺陷的软件模块；3)缺陷的来源（内部或外部）。
3. 缺陷管理工具缺陷管理工具是缺陷管理不可或缺的组成部分。
软件缺陷管理
缺陷管理是软件开发及测试过程中对缺陷进行提交、沟通、修正、关闭、统计等一系列过程的总和，确保缺陷被跟踪管理，直到执行了缺陷管理的全生命周期。
在整个缺陷管理周期，主要包括以下几部分：1、缺陷发现：通过执行测试用例，发现软件缺陷的一种行为，是软件测试中非常重要的一个环节；只有发现了软件中的缺陷，才能涉及到之后的缺陷管理。
本次讨论的重点是缺陷管理，故缺陷发现部分简单介绍。
2、缺陷提交：缺陷的提交是整个缺陷管理中的重点，现市面上也有很多的缺陷管理工具，可以对缺陷进行提交、跟踪及管理。
在缺陷提交时，常见的缺陷描述如下：缺陷摘要（主题）：是缺陷提交中最重要的部分；好的摘要应该包括简要描述（测试环境、软件模块、执行动作、缺陷现象等）、简单指出程序错误的依赖关系、简要指出程序错误的严重程度；要言简意赅、描述程序员最关注的对象，要求程序员通过查看缺陷摘要即可以知晓缺陷的大部分信息；检测时间：发现时间需要标注，以便跟踪；检测人：缺陷的发现人必须注明；检测项目：描述对应的项目编号；检测版本：什么软件版本出现的缺陷；缺陷描述：软硬件环境；测试软件模块；执行用例；操作动作描述；有必要的话把关键信息、日志信息、系统信息拷贝下来，以便开发人员查看；缺陷类型：功能缺陷？性能缺陷？稳定性缺陷？可靠性缺陷？可用性缺陷？界面缺陷？第三方缺陷？缺陷状态：新发现、修正、列入FAQ、待返测、已指派、已修正、已关闭、已否决、已反测等；引入原因：编码错误、设计错误、需求偏差、编码需优化、其它；优先级：低、中、高、非常高、紧急；严重程度：建议、轻微、一般、严重、致命；可以对缺陷的严重程度进行描述；缺陷发现阶段：单元测试、集成测试、系统测试、用户测试、上线运维？缺陷所在领域：硬件接口？硬件逻辑？软件驱动？软件接口？系统总体？缺陷分配人：一般是项目经理或程序员，最好是先分配给项目经理，再由项目经理决定分配给某开发人员；缺陷关注人：一般是项目经理或程序员，最好是先分配给项目经理，再由项目经理决定相关关注人；可重现：是，否；标识缺陷是否可以复现；估计修复时间：由项目经理和程序员估计；实际修复时间：由最终修复人员填写；关闭时间：由测试人员关闭，不能由项目经理及程序员决定；关闭与版本：由测试人员关闭，不能由项目经理及程序员决定；计划关闭版本：由测试人员关闭，不能由项目经理及程序员决定；3、缺陷修正：缺陷由项目经理指定到相关开发人员后，开发人员会对缺陷进行查看，有必要的话需要对当时的操作及缺陷现象进行复现，以便开发人员定位分析，有几点需要注意。
软件质量保证和缺陷管理
软件质量保证和缺陷管理软件质量保证是软件开发过程中非常重要的一环，它确保软件的功能和性能满足用户的期望。
缺陷管理则是在软件开发过程中发现、记录和修复软件缺陷的活动。
本文将就软件质量保证和缺陷管理进行探讨，包括其定义、重要性、方法和最佳实践。
一、软件质量保证的定义和重要性软件质量保证，简称SQA（Software Quality Assurance），是指通过一系列计划、标准、流程和工具，保证软件产品的质量。
软件质量保证的重要性不言而喻。
首先，软件质量保证可以提高软件产品的稳定性和可靠性。
通过审查和验证，可以发现并修复软件中的错误和缺陷，从而降低软件产品出错的概率。
其次，软件质量保证可以提高软件的可用性和用户满意度。
通过不断优化软件的性能和用户体验，可以增强用户对软件产品的信任和满意度。
最后，软件质量保证可以节约成本和资源。
及时发现和修复软件缺陷可以避免因软件错误引发的额外开支，同时提高软件开发效率和产品质量。
二、软件质量保证的方法软件质量保证的方法多种多样，下面将介绍几种常用和有效的方法。
1. 质量计划质量计划是软件质量保证的基础。
它包括制定质量目标、制定测试策略、确定质量标准和规范等。
通过明确质量目标和细化质量标准，可以有效指导软件开发过程中的质量保证活动。
2. 质量评审质量评审是一种基于团队合作的质量保证方法，目的是通过多位参与者的审查和讨论，发现并修复软件中的错误和缺陷。
质量评审可以采用多种形式，如代码评审、需求评审、测试方案评审等。
通过质量评审，可以提高软件产品的质量和稳定性。
3. 自动化测试自动化测试是一种高效和可重复性较强的软件质量保证方法。
通过编写测试脚本和使用自动化测试工具，可以自动执行各种测试用例，并对软件进行验证和评估。
自动化测试不仅可以提高测试效率，还可以降低人工测试的误差率。
4. 性能测试性能测试是一种专门针对软件系统性能进行评估的质量保证方法。
通过模拟用户负载和压力，可以测试软件系统在不同负载下的性能表现和响应速度。
软件故障缺陷管理制度
软件故障缺陷管理制度一、总则为了提高软件产品的质量和稳定性，保障用户的利益，及时有效地解决软件故障缺陷，特制定本制度。
二、适用范围本制度适用于公司所有软件产品的故障缺陷管理工作。
三、管理机构公司设立故障缺陷管理委员会，负责软件故障缺陷的管理工作。
委员会成员包括公司高级技术人员、产品经理和客户服务代表等。
四、故障缺陷管理流程1.故障缺陷发现软件故障缺陷可以由用户反馈、内部测试人员发现、开发人员自测等渠道发现。
用户反馈的故障缺陷应该及时记录并进行分类整理。
2.故障缺陷确认故障缺陷由开发人员进行故障确认和分类，确认故障严重性、影响范围和紧急程度。
3.故障缺陷分析对确认的故障缺陷进行分析，找出故障产生的原因和可能的解决方案。
4.故障缺陷解决根据故障缺陷的严重性和紧急程度，制定相应的解决方案和时间表，由开发团队进行故障修复和测试。
5.故障缺陷验证软件故障缺陷修复结束后，需要进行验证确认是否解决了故障缺陷，并确保修复过程没有引入新的问题。
6.故障缺陷发布修复后的软件需进行测试确认没有新的故障缺陷并发布到正式环境供用户使用。
7.故障缺陷记录所有故障缺陷的发现、确认、分析、解决和验证过程均需记录并进行归档。
五、故障缺陷管理的责任1.故障缺陷管理委员会成员有责任对软件故障缺陷管理工作进行监督和协调。
2.开发团队有责任对软件故障缺陷进行确认、分析、解决和验证工作。
3.测试团队有责任对软件故障缺陷进行记录和测试确认。
4.客户服务团队有责任对用户反馈的故障缺陷进行及时的记录、分类和转交给开发团队。
5.产品经理有责任对故障缺陷的严重性和紧急程度进行评估和决策。
六、故障缺陷管理的指标1.故障缺陷发现速度：单位时间内发现的故障缺陷数量。
2.故障缺陷解决速度：单位时间内解决的故障缺陷数量。
3.故障缺陷修复效果：修复后故障缺陷再次发生的比例。
4.用户满意度：用户对软件故障缺陷处理的满意程度。
七、附则本制度自发布之日起正式执行，如有需要修改，需经故障缺陷管理委员会讨论通过并报公司领导审批。
软件评测缺陷管理
软件评测缺陷管理软件评测是软件开发过程中不可或缺的一环，它可以帮助开发团队及时发现和解决软件中的缺陷，提高软件的质量和用户体验。
然而，如果在评测过程中缺乏有效的缺陷管理措施，将难以达到评测的预期目标。
本文将探讨软件评测缺陷管理的重要性，并介绍一些实用的方法来有效管理缺陷。
一、软件评测缺陷管理的重要性软件评测过程中的缺陷管理对于软件开发团队和最终用户来说都具有重要意义。
首先，缺陷管理能够帮助开发团队及时发现和解决软件中的问题，提高软件质量。
通过及时处理缺陷，开发团队能够减少后期维护和修复的成本，提高开发效率。
其次，缺陷管理有助于改进软件的用户体验。
当用户在使用软件过程中遇到问题，能够及时反馈给开发团队，并得到解决，用户对软件的满意度将会提高。
缺陷管理还能帮助开发团队了解用户需求和体验，为软件的改进提供有价值的反馈。
二、软件评测缺陷管理的方法1. 缺陷追踪系统的使用缺陷追踪系统是一种用于收集、管理和跟踪软件缺陷的工具。
通过使用缺陷追踪系统，开发团队能够方便地记录缺陷的详细信息，包括缺陷的描述、复现步骤和优先级等。
同时，开发团队也可以通过系统中的状态跟踪功能随时查看缺陷的处理情况。
2. 缺陷分类和优先级管理在软件评测过程中，对于发现的缺陷进行合理的分类和优先级管理非常重要。
通过对缺陷进行分类，开发团队可以更好地了解缺陷的性质和影响范围，有针对性地进行处理。
而通过设定缺陷的优先级，可以确保开发团队能够优先解决影响软件核心功能和稳定性的重要缺陷，提高软件的可用性。
3. 缺陷分析和复现对于发现的缺陷，开发团队需要进行详尽的分析和复现。
通过分析缺陷产生的原因和背后的问题，可以为解决方案的制定提供参考。
同时，通过在测试环境中复现缺陷，开发团队可以更好地理解缺陷的现象和触发条件，有针对性地制定解决方案。
4. 缺陷修复和验证在开发团队解决了缺陷后，需要进行缺陷修复和验证工作。
修复缺陷后，开发团队需要再次验证修复效果，确保缺陷已经得到有效解决。
软件缺陷管理制度
软件缺陷管理制度软件项目测试组修订历史记录目录软件缺陷管理制度····························································································错误!未定义书签。
修订历史记录····································································································错误!未定义书签。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求 概要设 计
0
3 6
9 8
116/27 62/20
详细设 计
编码 总计
0
15
0
6
62
12
32
0
18
0
8
6
15
42
120
81/31
255/109 514/187= 2.7
常熟理工学院软件工程系
6.5 缺陷密度
缺陷数量 缺陷密度= 代码行数或功能点数
我们把什么当作缺陷 是否将较小的缺陷和严重缺陷作同等对待，是否 加权。 我们是否计算单元测试的bug数量？还是只计算以 后发现的bug数量？ 计算在评审/审查期间发现的bug数量？ 度量模块的大小也是一个问题，代码行的数量会因为编程人员 的技术水平和所使用的语言的不同而不同。
3
Minor
4
Cosmetic
5
Other
常熟理工学院软件工程系
3.3 按照缺陷的优先级划分缺陷
# 解决优先级 描述
1
Low
低（不影响系统的功能实现，如提示信息错误，错别字等）
2
Medium
中（某些非总要的功能未能实现，但不影响其他功能）
3
High
高（不符合系统的设计或某一主要功能无法实现）
4
Very High
常熟理工学院软件工程系
3 软件缺陷的分类
按照缺陷关联的软件制品划分缺陷 按照缺陷的严重程度划分缺陷 按照缺陷优先级划分缺陷 按照缺陷的起源划分缺陷 按照缺陷发生的根本原因划分缺陷
常熟理工学院软件工程系
3.1 按照缺陷关联的软件制品划分缺陷
缺陷类型 编号 10 缺陷类型 F- Function 描述 影响了重要的特性、用户界面、产品接口、硬件接口 和全局数据结构。并且设计文档需要正式的变更。如 逻辑，指针，循环，递归，功能等缺陷 需要修改少量代码，如初始化或控制块。如声明、重 复命名，范围、限定等缺陷 与其他组件、模块或设备驱动程序、调用参数、控制 块或参数列表相互影响的缺陷。 提示的错误信息，不适当的数据验证等缺陷。 由于配置库、变更管理或版本控制引起的错误
常熟理工学院软件工程系
6.2 缺陷消除率（DRE）
造成的Bug数量
200 120 提出 需求 80 50 130 100 130 代码/ 单元 测试 100 集成 测试 20 110 系统 测试 50 60 30 验收 测试 30
产品
设计
40
发现的bug数量
DRE=(80+40+100+20+50+30)/(80+40+100+20+50+30+30)=91% 系统测试的DRE=系统测试发现的bug数量/（系统测试发现的bug数量+验收 测试和产品中发现的bug数量）=50/（50+30+30）=45%
常熟理工学院软件工程系
3.5 按照缺陷生成的根本原因划分缺陷
缺陷原因
描述
目标
如：错误的范围，误解了目标，超越能力的目 标等 如：无效的需求收集过程，过时的风险管理过 程，不适用的项目管理方法，没有估算规程， 无效的变更控制过程等。 如：项目团队职责交叉，缺乏培训。没有经验 的项目团队，缺乏士气和动机不纯等。
20 35 120 80 40 10 15 320
20 5
14 0 15 15 60 60
25
14
15
15
60
60
常熟理工学院软件工程系
6.1.3 其他度量缺陷数量的方法
统计分析用户或客户发现的缺陷数 统计分析软件发布前尚未修复的缺陷数
常熟理工学院软件工程系
6.2 缺陷消除率（DRE）
在我们可能发现的bug集合中，我们到底发现了多 少bug?
常熟理工学院软件工程系
5 软件缺陷管理
7、问题修复了吗？ 现在系统能通过 以前的测试吗？ 系统的其余部分 仍然正常工作吗？ 1、我能再现故障吗？ 2、测试错误还是系统 错误？ 3、哪些因素影响了故 障？ 缺陷报告 4、根本原因是什么？ 5、如何不引入新问题 的情况下修复缺陷？ 6、修复是否正确调试 了？
过程，工具和方法
人
常熟理工学院软件工程系
4 软件缺陷的生存周期
缺陷状态
New 新建缺陷
描述
Open
Fixed
被确认并分配相关开发人员处理
开发人员已确认修改，等待测试人员处理
Rejected
Deferred
拒绝修改缺陷
被确认，但延期修改缺陷
Closed
缺陷已被修复
常熟理工学院软件工程系
4 软件缺陷的生存周期
编码
总计 0 8 13
0
19
62
65
16
21
6
14
2
9
3
8
20
30
109
187
常熟理工学院软件工程系
6.4 缺陷损耗
缺陷损耗是使用阶段潜伏期和缺陷分布来度量缺陷消除活 动的有效性的一种度量。
缺陷损耗= 缺陷数量 * 发现的阶段潜伏期 缺陷总数
缺陷损耗的数值越低，说明发现过程越有效。 作为一个绝对值，损耗几乎没有任何意义；但是，当用损 耗来度量测试有效性的长期趋势时，它就会显示出自己的 价值。
所有的Bug并不都是均等的。有必要对bug进行 “加权”或采用影响等级分类。 最初存在的数量对发现的bug数量由着重要的应影 响
常熟理工学院软件工程系
6.1.1 与类似项目的缺陷数量进行比对 采用类似项目的缺陷数量的缺陷数据与目标项目 的缺陷数据比来度量
发 现 的 缺 陷 数 量
时间
项目A 项目B
常熟理工学院软件工程系
6.4 缺陷损耗
示例：由缺陷潜伏期加权的缺陷数
造成阶 段 需 求 概 要 设 计 8 0 详 细 设 计 8 9 编 码 单 元 测 试 0 0 发现阶段 集 成 测 试 0 4 系 统 测 试 30 15 验 收 测 试 42 6 试 点 产 品 16 14 产 品 损耗
测试人员
错误报告和测 试发布过程中 的交互和劳动 分工明确
开发人员
测试小组
缺陷修复
开发小组
常熟理工学院软件工程系
6 软件缺陷度量
缺陷数量 缺陷消除率 缺陷潜伏期 缺陷损耗 缺陷密度
常熟理工学院软件工程系
6.1 缺陷数量
用缺陷数量作为软件质量度量、测试有效性度量 时应关注如下问题：
影响发布和维护，包括注释。
算法错误。 人机交互特性：屏幕格式，确认用户输入，功能有效 性，页面排版等方面的缺陷 不满足系统可测量的属性值，如：执行时间，事务处 理速率等。 不符合各种标准的要求，如编码标准、设计符号等。
常熟理工学院软件工程系
3.2 按照缺陷的严重程度划分缺陷
#
1
缺陷严重等级
Critical
常熟理工学院软件工程系
7 缺陷管理工具
BugFree BugZilla IBM Reational ClearQuest TestDirector
常熟理工学院软件工程系
Q&A
常熟理工学院软件工程系
常熟理工学院软件工程系
6.3 缺陷潜伏期
项目缺陷的造成与发现示例
造成阶段 需 概要 求 设计 需求 概要设计 详细设计 0 8 0 详细 设计 4 9 0 编 码 1 3 15 单元 测试 0 0 3 发现阶段 集成 测试 0 1 4 系统 测试 5 3 0 验收 测试 6 1 0 试点 产品 2 2 1 产 品 1 1 8 总量 27 20 31
常熟理工学院软件工程系
2 软件缺陷的属性
属性名称 缺陷摘要 (Summary) 缺陷描述 (Description) 指定的负责人 (owner/assignee) found in fixed in 解决办法（ resolution ） verified in 附件（ attachment ） 描述 用一句话概要地描述缺陷的现象 详细的描述缺陷重现的环境、前置条件、步骤、期望结果、实际 结果等。 通常是负责修复该缺陷的开发人员，在有的系统中也支持开发人 员修复好缺陷修改其在缺陷跟踪系统中的状态后把它指定（assign） 给相关的测试人员。 缺陷被发现的版本 缺陷被修复的时候由开发人员填写。 由开发人员修复缺陷的时候填写。 反映缺陷的修复在哪个版本被验证了 附加的屏幕截图、服务器或客户端日志等相关文件，便于开发人 员定位缺陷的原因。
常熟理工学院软件工程系
6.2 缺陷消除率（DRE）
使用该度量时，应注意：
必须考虑Bug的严重程度和分布状况。 我们怎么才知道客户到什么时候会发现所有的bug? 这种度量是“马后炮”性质的度量。对当前项目的 测试有效性度量无意义，但有利于组织的测试有效 性的长期趋势度量。 我们什么时候开始计算Bug? 有些Bug在测试中发现不了！受测试环境的影响， 发现不了的bug是否需要考虑度量。
很高（缺陷造成数据丢失或死机）
5
Urgent
紧急（缺陷必选立即被解决，否则无法测试下去）
常熟理工学院软件工程系
3.4 按照缺陷起源的软件生存周期阶段划分
缺陷起源 Requirement Architecture Design Code Test 描述 在需求阶段发现的缺陷 在构架阶段发现的缺陷 在设计阶段发现的缺陷 在编码阶段发现的缺陷 在测试阶段发现的缺陷
常熟理工学院软件工程系
1 什么是软件缺陷(Bug)?
IEEE (1983) 729 软件缺陷一个标准的定义：
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错 误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。