缺陷管理(软件测试与度量)讲解
软件测试Bug之“缺陷分析“篇
软件测试Bug之“缺陷分析“篇提到Bug，软件缺陷，除了记录一个问题出现的现象和原因以外，对于一个或者多个Bug的分析也非常重要，本文讲述了Bug分析的目的，介绍了IBM的ODC缺陷分析法，已提供给需要进行缺陷分析的测试小伙伴们参考。
Bug记录平台介绍Bug记录平台，用比较文绉绉的话说是软件缺陷跟踪系统（DefectTrackingSystem，DTS）是软件测试管理系统的核心部分。
这里拿华为的缺陷管理系统来举例，网易以及其他互联网公司大部分会使用比较轻量级的开源平台比如Jira平台等。
共同之处是对软件缺陷处理过程有一些最基本的要求，大概包括以下几个方面：1）整个处理过程应该是闭合的，即确保每一个被发现的问题在过程中都能得到解决，在整个过程中追踪缺陷的状态，问题记录在整个周期内都得到维护简单来说可以理解为Bug的状态流转，例如创建、进行中、已解决、关闭等2）每一个被发现的软件缺陷都应该按类别和优先级进行分类3）对软件缺陷的改正应该进行验证，以确保问题确实被解决、不利的影响已经被消除，并且解决该问题所引起的变化不会带来新的问题软件项目团队的全体成员就以软件缺陷跟踪系统（DTS）为工作的参照物，形成良好的工作流程和运行机制，构建如下所示的软件测试管理体系：1）测试人员向缺陷跟踪系统报告新bug，在新版本上执行回归测试验证bug 是否正确修改2）开发人员每天浏览属于自己需要修改的bug，修正bug后及时更新bug 的状态3）项目经理及部门经理根据缺陷跟踪系统的bug分布信息，跟踪和控制软件开发过程4）技术支持人员根据缺陷跟踪系统的bug状况，估计软件的发布期限BUG生命周期全流程：测试人员提交BUG->开发人员处理->测试回归->关闭问题单提交必填属性有：Bug主题、描述、重要性、测试类型、是否线上bug、影响的版本、经办人、回归人等Bug分析目的一、对测试执行过程进行度量和评估，给出版本质量评估及开发测试改进建议。
基于软件测试的缺陷分析及度量方法
基于软件测试的缺陷分析及度量方法摘要：随着用户需求的不断增加，许多软件产品被开发出来。
为了满足用户的需求，在源代码中添加了许多新的接口和类。
然而，软件维护和代码重构的任务非常复杂。
因此，在源代码中找到缺陷并纠正这些缺陷是很重要的。
挑战在于开发工具和技术来自动提取错误信息。
最近，计算机科学家致力于使用静态分析技术从源代码中发现缺陷。
静态分析，也称为静态代码分析，是一种通过检查代码而不执行程序来完成计算机程序调试的方法。
通常，静态分析用于检查源代码文件是否存在问题和不一致。
关键词：软件缺陷数据；软件测试；缺陷分类；分析方法引言目前，软件测试是一种检验软件产品或阶段性工作成果的手段，通过它可以验证软件是否符合事先的需求定义、设计要求以及代码规范等。
不管测试的定义如何，它都只能证明软件存在缺陷，不能证明软件不存在缺陷。
测试与质量密不可分，我国的软件质量标准体系以GB/T25000系列为主，根据现代系统论的思想，结合国际标准相关经验和国内实践情况，将标准体系分为测试过程管理、测试技术、测试工具以及测试文档4个方面。
软件测试人员需要结合软件的具体特点选择测试方法和类型，选择的结果应该在软件测试计划中予以明确，并通过测评项目组评审认可。
1软件测试技术概述软件测试是指通过人工或自动的方式对软件系统进行运行或检测，根据所得的数据来判断并验证其是否满足相关的标准，同时对其偏差进行评价，并进行改进的过程。
软件测试的概念包含了以下几点核心内涵：第一，软件测试的方式包含人工测试和自动化测试；第二，软件测试的主要内容就是通过测试数据来验证产品是否满足设计指标或用户需求；第三，软件测试的最终目标是要发现软件缺陷，并对其进行完善，提高软件质量。
可见，软件测试是防止软件缺陷流入使用环节的重要手段，在软件工程中发挥着极为关键的作用。
2软件测试的缺陷分析及度量方法2.1缺陷检测方法缺陷检测的改良可以通过更精准的对缺陷进行分类，并且依据用户反馈进行调整改良。
第3章缺陷管理
看似正确但却是错误
• • • 安装某个软件成功，但它破坏了操作系统的功能或 其他软件。 软件卸载过程中没有完全卸掉它的组件，有些会降 低系统运行的效率，有些会导致升级版本无法安装。 软件需要支持大多数的硬件配置，例如迪斯尼狮子 王游戏的教训，虽然软件本身没有错误，但是却影 响了多数用户的使用。
同一现象的2种可能
软件名称：软件测试工程师管 理信息系统 测试人员：王慧 日期：2006/3/15 2006/3/15 硬件平台：
怎样有效记录缺陷
• • • 方便阅读 站在开发人员的角度考虑问题 1.概述（Summary ） ：简洁、 准确，完整，揭示错误实质 2.步骤（Steps ）：完整，准 确，简短，保证快速准确的重 复错误， “完整”即没有缺漏，“准确” 即 步骤正确，“简短”即没有多 余的步骤。 3.尽量使用业界惯用的表达术 语和表达方法（term） 4.检查拼写和语法错误
缺陷概述：修改信息模块在默认状态下修改工 程师信息为添加工程师。 详细描述：运行软件工程师系统选“信息管理” 下的“修改信息”在对话框中添入默认的 信息后，按“确定”按钮，在随后出现的对话 框中选“确定”然后再选“信息管理”下的 “所有信息”能看到出现新记录。 缺陷记录 软件名称：软件测试工程 师管理信息系统 测试人员：赵国红 编译 号： 编号： 003 版本号：
上载的性能太慢 “序号”功能不起作用
点击“修改”的时候，原有 的公文消失了 盖章后不能打印
发文机关处没有反应
我在格式中定义了×××和×××为发文机关，但是在上载后没有任 何响应，我把图和原始文件放在附件中了。
盖章还是盖不了。×××的 能盖，但我上传的就是不 行 同一个章是不是在一处只能 盖一次？ 设计中该考虑的关系类型 我认为是这样的，因为一个章代表一个单位。
测试缺陷管理规范
测试缺陷管理规范引言概述：测试缺陷管理规范是软件测试工作中非常重要的一部份，它有助于确保软件质量和提高项目的成功率。
本文将详细介绍测试缺陷管理规范的五个部份，包括缺陷报告、缺陷分类、缺陷评估、缺陷修复和缺陷验证。
一、缺陷报告：1.1 缺陷报告的目的是记录和跟踪软件中发现的问题，以便于后续处理。
1.2 缺陷报告应包括准确的缺陷描述，包括问题现象、重现步骤和环境信息等。
1.3 缺陷报告还应包括必要的附件，如截图、日志文件等，以便于开辟人员更好地理解和定位问题。
二、缺陷分类：2.1 缺陷应按照严重程度进行分类，如致命缺陷、严重缺陷、普通缺陷和建议性问题等。
2.2 缺陷还可以按照类型进行分类，如功能性缺陷、性能缺陷、界面缺陷和安全性缺陷等。
2.3 缺陷分类的目的是为了更好地组织和管理缺陷，以便于分配和优先级排序。
三、缺陷评估：3.1 缺陷评估是对缺陷进行分析和评估，以确定其对软件功能和质量的影响程度。
3.2 缺陷评估应考虑缺陷的严重程度、影响范围、修复难度和紧急程度等因素。
3.3 缺陷评估的结果可以匡助项目团队决定缺陷的处理优先级，并制定相应的修复计划。
四、缺陷修复：4.1 缺陷修复是开辟人员根据缺陷报告和评估结果进行问题定位和修复的过程。
4.2 缺陷修复应按照优先级进行，首先修复致命和严重缺陷，然后再处理普通缺陷和建议性问题。
4.3 缺陷修复完成后，开辟人员应及时更新缺陷状态，并通知测试人员进行验证。
五、缺陷验证：5.1 缺陷验证是测试人员对修复后的缺陷进行验证和确认的过程。
5.2 缺陷验证应根据缺陷报告和修复说明进行，确保修复效果符合预期。
5.3 缺陷验证通过后，测试人员应及时关闭缺陷，并通知开辟人员和项目团队。
结论：测试缺陷管理规范对于软件测试工作的顺利进行和项目的成功交付至关重要。
通过合理的缺陷报告、分类、评估、修复和验证，可以提高软件质量，减少项目风险，并提高开辟人员和测试人员的工作效率。
因此，项目团队应该重视并遵守测试缺陷管理规范，以保证项目的成功实施。
软件缺陷管理
缺陷管理是软件开发及测试过程中对缺陷进行提交、沟通、修正、关闭、统计等一系列过程的总和，确保缺陷被跟踪管理，直到执行了缺陷管理的全生命周期。
在整个缺陷管理周期，主要包括以下几部分：1、缺陷发现：通过执行测试用例，发现软件缺陷的一种行为，是软件测试中非常重要的一个环节；只有发现了软件中的缺陷，才能涉及到之后的缺陷管理。
本次讨论的重点是缺陷管理，故缺陷发现部分简单介绍。
2、缺陷提交：缺陷的提交是整个缺陷管理中的重点，现市面上也有很多的缺陷管理工具，可以对缺陷进行提交、跟踪及管理。
在缺陷提交时，常见的缺陷描述如下：缺陷摘要（主题）：是缺陷提交中最重要的部分；好的摘要应该包括简要描述（测试环境、软件模块、执行动作、缺陷现象等）、简单指出程序错误的依赖关系、简要指出程序错误的严重程度；要言简意赅、描述程序员最关注的对象，要求程序员通过查看缺陷摘要即可以知晓缺陷的大部分信息；检测时间：发现时间需要标注，以便跟踪；检测人：缺陷的发现人必须注明；检测项目：描述对应的项目编号；检测版本：什么软件版本出现的缺陷；缺陷描述：软硬件环境；测试软件模块；执行用例；操作动作描述；有必要的话把关键信息、日志信息、系统信息拷贝下来，以便开发人员查看；缺陷类型：功能缺陷？性能缺陷？稳定性缺陷？可靠性缺陷？可用性缺陷？界面缺陷？第三方缺陷？缺陷状态：新发现、修正、列入FAQ、待返测、已指派、已修正、已关闭、已否决、已反测等；引入原因：编码错误、设计错误、需求偏差、编码需优化、其它；优先级：低、中、高、非常高、紧急；严重程度：建议、轻微、一般、严重、致命；可以对缺陷的严重程度进行描述；缺陷发现阶段：单元测试、集成测试、系统测试、用户测试、上线运维？缺陷所在领域：硬件接口？硬件逻辑？软件驱动？软件接口？系统总体？缺陷分配人：一般是项目经理或程序员，最好是先分配给项目经理，再由项目经理决定分配给某开发人员；缺陷关注人：一般是项目经理或程序员，最好是先分配给项目经理，再由项目经理决定相关关注人；可重现：是，否；标识缺陷是否可以复现；估计修复时间：由项目经理和程序员估计；实际修复时间：由最终修复人员填写；关闭时间：由测试人员关闭，不能由项目经理及程序员决定；关闭与版本：由测试人员关闭，不能由项目经理及程序员决定；计划关闭版本：由测试人员关闭，不能由项目经理及程序员决定；3、缺陷修正：缺陷由项目经理指定到相关开发人员后，开发人员会对缺陷进行查看，有必要的话需要对当时的操作及缺陷现象进行复现，以便开发人员定位分析，有几点需要注意。
软件测试中的缺陷管理和跟踪系统
软件测试中的缺陷管理和跟踪系统在软件开发过程中，测试是确保软件质量的一个重要环节。
而在测试过程中，发现并管理缺陷是必不可少的。
为了有效地管理和跟踪测试中的缺陷，很多组织采用缺陷管理和跟踪系统。
本文将探讨软件测试中的缺陷管理和跟踪系统的重要性、功能以及如何选择适合的系统。
一、缺陷管理和跟踪系统的重要性在软件测试过程中，缺陷的管理和跟踪对于项目的成功实施至关重要。
通过缺陷管理和跟踪系统，测试团队可以及时发现、记录和解决软件中的缺陷，确保项目进度和质量的可控性。
缺陷管理和跟踪系统可以提供以下几个重要的功能：1. 缺陷记录和跟踪：系统可以方便地记录缺陷并跟踪其处理状态，包括缺陷的发现时间、发现者、严重程度、步骤重现、解决方案等信息，以便后续定位和解决。
2. 缺陷分析和统计：系统可以对缺陷进行分类、汇总和统计，帮助测试团队了解缺陷的分布情况、影响范围和解决效果，从而进行合理的资源分配和优化测试策略。
3. 缺陷协同和沟通：系统可以提供协同工作、评论和通知功能，方便测试团队成员之间的沟通和合作，加速缺陷的解决过程，避免信息的丢失和延误。
4. 缺陷追踪和回归测试：系统可以记录缺陷的修复版本和验证结果，方便测试团队进行回归测试，确保已解决的缺陷不再出现。
二、如何选择合适的缺陷管理和跟踪系统选择合适的缺陷管理和跟踪系统对于测试团队的工作效率和项目进展至关重要。
以下是选择系统时需要考虑的几个关键因素：1. 功能完备性：系统应该提供基本的缺陷记录、跟踪和分析功能，并且可以根据团队的具体需求定制扩展功能，如自定义字段、报表和图表等。
2. 界面友好性：系统应该有直观、易用的用户界面，减少用户的学习成本，提高操作效率。
同时，界面应该美观整洁，让用户在使用过程中有良好的体验。
3. 集成性和兼容性：系统应该能够与其他工具和系统集成，如测试管理工具、版本控制系统等。
此外，系统也应该能够适应不同的开发环境和平台。
4. 安全性和稳定性：系统应该具有良好的安全性控制机制，保护敏感数据的安全和隐私。
测试缺陷管理规范
测试缺陷管理规范【测试缺陷管理规范】一、引言缺陷管理是软件测试过程中至关重要的一环，它涉及到对软件中发现的缺陷进行记录、跟踪和解决的过程。
本文将介绍测试缺陷管理的规范，包括缺陷的定义、缺陷管理流程、缺陷分类和优先级、缺陷报告的内容和格式等。
二、缺陷的定义缺陷是指软件系统中的错误、问题或不符合规范的行为，它可能导致系统功能无法正常运行、性能下降或安全性问题等。
缺陷可以由测试人员、开发人员或用户发现，并应该及时记录和解决。
三、缺陷管理流程1. 缺陷记录：测试人员在发现缺陷后，应该及时记录缺陷的详细信息，包括缺陷的描述、复现步骤、环境信息等。
2. 缺陷分类和优先级：根据缺陷的严重程度和影响范围，对缺陷进行分类和优先级划分，以便开发人员能够合理安排修复工作。
3. 缺陷分析和解决：开发人员对已记录的缺陷进行分析，并进行修复。
修复后，测试人员需要验证修复的效果。
4. 缺陷验证：测试人员对修复后的软件进行再次测试，以确保缺陷已经被解决。
5. 缺陷关闭：当缺陷被验证为已解决时，测试人员将缺陷关闭，并记录缺陷的关闭原因和解决方案。
四、缺陷分类和优先级1. 缺陷分类：根据缺陷的性质和影响范围，可以将缺陷分为功能性缺陷、性能缺陷、界面缺陷、安全性缺陷等。
2. 缺陷优先级：根据缺陷的严重程度和影响范围，可以将缺陷划分为高、中、低三个优先级。
高优先级的缺陷会对系统的功能或性能产生严重影响，需要尽快解决。
五、缺陷报告的内容和格式1. 缺陷报告的内容应包括缺陷的描述、复现步骤、环境信息、缺陷分类和优先级等。
2. 缺陷报告的格式应简洁明了，包括缺陷的标题、报告人、报告时间、缺陷状态、解决方案等字段。
六、缺陷管理工具为了更好地管理和跟踪缺陷，可以使用专业的缺陷管理工具，如JIRA、Bugzilla等。
这些工具可以帮助团队高效地记录、分配和解决缺陷，并提供缺陷统计和报告功能。
七、总结测试缺陷管理是软件测试过程中不可或缺的一环，它对于保证软件质量和用户满意度至关重要。
测试缺陷管理规范
测试缺陷管理规范引言概述：测试缺陷管理规范是软件测试过程中的重要一环，它能够帮助开发团队更好地管理和解决软件测试过程中的缺陷问题。
本文将从四个方面详细阐述测试缺陷管理规范。
一、缺陷管理流程规范：1.1 缺陷报告：测试人员在发现缺陷后，应及时记录并详细描述缺陷的现象、重现步骤和影响范围等信息，以便开发团队能够准确理解和复现该缺陷。
1.2 缺陷分类和优先级：根据缺陷的严重程度和影响范围，将缺陷进行分类和优先级划分。
常见的分类包括功能性缺陷、性能缺陷和安全缺陷等，优先级可分为高、中、低等级。
1.3 缺陷分派和跟踪：开发团队应及时接收并分派缺陷给相关人员进行处理。
同时，测试人员应跟踪缺陷的处理进度，并在解决后进行验证，确保缺陷得到有效解决。
二、缺陷管理工具规范：2.1 工具选择和配置：根据团队的需求和实际情况，选择适合的缺陷管理工具，并进行相应的配置。
常用的工具包括Bugzilla、JIRA等。
2.2 缺陷管理工具的使用规范：团队成员应熟悉并遵守缺陷管理工具的使用规范，包括正确填写缺陷报告、及时更新缺陷状态和注释等。
2.3 缺陷管理工具的统计和分析：通过缺陷管理工具可以进行缺陷的统计和分析，包括缺陷数量、解决速度等指标的监控和分析，以便优化测试和开发过程。
三、缺陷管理沟通规范：3.1 缺陷沟通渠道的建立：建立有效的缺陷沟通渠道，包括团队内部的沟通和与开发团队的沟通，以便及时沟通和解决缺陷问题。
3.2 沟通内容的明确和准确：在缺陷沟通中，应明确和准确地描述缺陷的现象和影响，避免产生歧义和误解。
3.3 沟通记录的保存和归档：对缺陷沟通的记录进行保存和归档，以便后续查阅和追踪，同时也为团队之间的知识共享提供便利。
四、缺陷管理的持续改进：4.1 缺陷管理过程的评估和反馈：定期对缺陷管理过程进行评估和反馈，包括缺陷管理的效果和团队成员对规范的遵守程度等，以便及时发现问题并进行改进。
4.2 缺陷管理经验的总结和分享：团队成员应及时总结和分享缺陷管理的经验和教训，以便其他成员能够借鉴和学习。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
重现的。对于有时不可重现的Bug，应当反复测试，直到
最终确定Bug的发生场景为止。
报告Bug的基本原则
尽快报告Bug
修改成本小、修改风险小 避免报告同类缺陷
有效描述Bug
简单、明确、具体 每个缺陷一份报告 简化和优化操作步骤 保证重现缺陷
不仅可以统一数据格式、完成数据校验，而且确 保每一个缺陷不会被忽视，使开发人员的注意力 保持在那些必须尽快修复的高优先级的缺陷上。
可以随时建立符合各种需求的查询条件，而且有 利于建立各种动态的数据报表，用于项目状态报 告和缺陷数据统计分析。
可以随时得到最新的缺陷状态，大家获得一致又 准确的信息，掌握相同的实际情况，消除沟通上 的障碍。
正在测试的软件哪个模块的问题最多？ 测试人员中谁报告的软件缺陷最多？ 测试人员中谁报告的软件缺陷准确率最高？ 各类缺陷所占的数量百分比分别是多少？ 开发人员能及时修正软件缺陷吗？ 开发人员一次正确修正缺陷的百分比是多少？ 有多少重复报告的缺陷？ 正在开发的软件能否在计划的时间内正常发布？
因为在测试工作中，大多数的缺陷都记录 了它的严重程度的等级和优先级，所以这 个问题通常都能够很好解决。例如，下图 所示的缺陷分布图表示软件缺陷在各优先 级上所应体现的分布方式。
各优先级上软件缺陷分布图
报告和管理缺陷
缺陷报告管理系统（缺陷跟踪系统）
过程强制 权限控制 质量记录 文档管理 信息共享 度量和统计
动态报表，及时更新数据 自动邮件机制
缺陷分析
作用 调整测试进度和项目进度 调整测试策略和项目资源分配 测试人员与开发人员考核 精心设计 谨慎使用 度量软件质量、评估测试过程的效率、预期发布 时间 数据最能反映真实情况 数据也最能制造假象
缺陷分析
关注对象
以不修复 形式解决
软件缺陷移交到测试员
测试员不同意，找出 通用失败案例
打开
软件缺陷移交到项目管理员
打开
以修复 形式解决
关闭
项目管理员现在同意 软件缺陷需要修复
软件缺陷移交到程序员
程序员修复软件缺陷 软件缺陷移交到测试员
测试员确认 软件缺陷得以修复 测试员关闭软件缺陷
缺陷的跟踪处理
密切跟踪缺陷状态的变化，及时处理缺陷， 使项目按预定的计划进行
缺陷分析工具
实时趋势分析 累积趋势分析 缺陷分布分析
实时趋势分析
实时数据，由每日或每周发生的数据构成的时间序列 对随时间变化的趋势进行分析
累积趋势分析
累积数据是将前面产生的数据不断累加起来 所构成的时间序列
累积曲线趋势特征更明显
/Kerryzh u
术的限制或第3方产品的限制，暂时没法修 正，其优先级就会低
缺陷的类型和来源
缺陷类型可以分为业务逻辑、数据处理、接 口、UI、性能、安全性、兼容性、配置、文 档等
缺陷来源，如需求说明书、设计规格说明书 、代码、用户手册等
缺陷关联的模块名，缺陷来自于产品的特定 模块的名称
缺陷发生的阶段，例如需求、系统架构设计 、详细设计、编码等
缺陷描述客观公正，不带评价和感情色彩 保证每个缺陷被报告和处理
有效描述Bug
单一准确，每个报告只针对一个软件缺陷 可以再现，不要忽视或省略任何一项操作步骤，特别是
关键性的操作一定要描述清楚，确保开发人员按照所描 述的步骤可以再现缺陷 完整统一，提供完整的软件缺陷描述信息 短小简练，如使用业务关键词 特定条件，必须注明缺陷发生的特定条件 不做评价，客观描述
发现阶段
缺陷
造成 需 阶段 求
总 体 设 计
详 细 设 计
编 码
单 元 测 试
集 成 测 试
系 统 测 试
验 收 测 试
试 运 行 产 品
发 布 产 品
需求 0 1 2 3 4 5 6 7 8 9
总体 设计
012345678
详细 设计
01234567
编码
பைடு நூலகம்
0123456
总计
表5-2显示了一个项目的缺陷分布情况（按 缺陷造成阶段和缺陷发现阶段）。
0 15 3 4 0 0 1 8 31
编码
0 62 16 6 2 3 20 109
总计 0 8 13 19 65 21 14 9 8 30 187
缺陷密度
缺陷密度是一种以平均值估算法来计算出 软件缺陷分布的密度值。程序代码通常是 以千行为单位的，软件缺陷密度是用下面 公式计算的：
软件缺陷密度
0 15 3 4 0 0 1 8 31
编码
0 62 16 6 2 3 20 109
总计 0 8 13 19 65 21 14 9 8 30 187
直方图
圆饼图
综合
缺陷分析
缺陷分析通常用以下三类形式的度量提供缺 陷评测： 缺陷发现率 缺陷潜伏期 缺陷密度
缺陷发现率
缺陷发现率是将发现的缺陷数量作为时间的函数 来评测，即创建缺陷趋势图，如下图所示。
Bug举例3
替换字符串长度未 作限定： Word2000中，如果 替换字符串长度过 长，则会引起程序 崩溃。
软件问题报告（Bug报告）
软件问题（Bug）报告是软件测试过程中最重要的文档。 它记录了Bug发生的环境，如各种资源的配置情况，Bug的 再现步骤以及Bug性质的说明。
更重要的是它还记录着Bug的处理过程和状态。Bug的处理 进程从一定角度反映了测试的进程和被测软件的质量状况 以及改善过程。
版本跟踪 提交时间 修正时间 验证时间 所属项目/模块 产品信息 状态
编写Bug摘要
Bug的摘要是要用一句话的形式简明扼要地将Bug描述出来， 要清晰指出Bug所在部位以及其错误类型，不能太笼统。
如“页面对非法输入有问题”可以修改为“流量信息查询 页面对于非法输入没有进行校验”。
退出后再次打开这个文 本文件时，刚才输入的
内容变成了乱码。
Bug举例2
共享文件夹名超长时提示错误：
Windows XP支持的最大共享文件 夹名长度为80个英文字母或40个 汉字，但设置共享文件夹名时可 输入的范围是80个英文字符或80 个汉字，如果共享文件夹名在 41～80个汉字之间，系统会提示 “该共享名包含无效的字符” 。 其实真正的原因是共享文件夹名 超长。
什么是Bug?
在IEEE 1983 of IEEE Standard 729中对 软件缺陷下了一个标准的定义：
（1）从产品内部看，软件缺陷是软件产品 开发或维护过程中所存在的错误、毛病等 各种问题；
（2）从外部看，软件缺陷是系统所需要实 现的某种功能的失效或违背。
Bug举例1
文本文件保存错误：
在WindowsXP桌面上新建 一个文本文档，输入 “联通”两个字，并保 存退出。
如果没有报告缺陷，后果？
第1份缺陷报告
判断Bug的规则
软件未达到产品规格说明书（需求）标明的功能。 软件出现了规格说明书指明不会出现的错误。 软件功能超出规格说明书指明的范围。 软件未达到规格说明书虽未指出但应达到的目标（隐含需
求）。 软件测试员认为软件难以理解、不易使用、运行速度缓慢，
可以将缺陷和测试用例、需求等关联起来，可以 完成更深度的分析，有利于产品的质量改进等。
一个简单的缺陷报告
缺陷报告的描述
缺陷的严重性和优先级 缺陷的类型和来源 缺陷附件 完整的缺陷信息列表
缺陷的严重性和优先级
严重性：缺陷对软件产品使用的影响程度 优先级：缺陷必须被修复的紧急程度 缺陷越严重，越要优先得到修正，缺陷严重
等级和缺陷优先级相关性很强 也有例外，如有些缺陷比较严重，但由于技
表 5-2
一个项目的缺陷分布情况
发现阶段
缺陷 造成 阶段
需 求
总 体 设 计
详 细 设 计
编 码
单 元 测 试
集 成 测 试
系 统 测 试
验 收 测 试
试 运 行 产 品
发 布 产 品
缺陷 总量
需求 0 8 4 1 0 0 5 6 2 1 27
总体 设计
0 9 3 0 1 3 1 2 1 20
详细 设计
缺陷附件
一张图片可能胜过千言万语 Log file 工具捕捉的其它数据文件等
完整的缺陷信息列表
ID 标题 前提 环境 操作步骤 期望结果 实际结果 频率
严重程度 优先级 类型 缺陷提交人 缺陷指定解
决人
来源 产生原因 构建包跟踪
软件缺陷的处理和跟踪
软件缺陷生命周期 缺陷的跟踪处理 缺陷状态报告
发现 打开 修复 关闭
缺陷状态
软件缺陷生命周期
复杂的软件缺陷生命周期
发现软件缺陷 测试员找到并登记软件缺陷
打开
软件缺陷被移交到程序员
程序员认为软件缺陷微不足道
打开
软件缺陷移交到项目管理员
项目管理员认为软件缺陷不重要
表 5-2
一个项目的缺陷分布情况
发现阶段
缺陷 造成 阶段
需 求
总 体 设 计
详 细 设 计
编 码
单 元 测 试
集 成 测 试
系 统 测 试
验 收 测 试
试 运 行 产 品
发 缺陷 布 总量 产 品
需求 0 8 4 1 0 0 5 6 2 1 27
总体 设计
0 9 3 0 1 3 1 2 1 20
详细 设计
软件缺陷数量 代码行或功能点的数量
下图显示了一个项目的各个模块中每千行 代码的缺陷密度。