缺陷的基本概述
缺陷的定义
- 软件未实现产品说明书要求的功能；
- 软件出现了产品说明书指明不应该出现的功能；
- 软件实现了产品说明书未提到的功能；
- 软件未实现产品说明书虽未明确提及但应该实现的目标；
- 软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户会认为不好的。
缺陷的属性
- 缺陷类型（Type）：缺陷类型是根据缺陷的自然属性划分的缺陷种类；缺陷类型描述功能（Function）影响了各种系统功能、逻辑的缺陷用户界面（UI）影响用户界面、人机交互特性、包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷文档（Document）影响发布和维护，包括注释、用户手册、设计文档软件包（Package）由于软件配置库、变更管理或版本控制引起的错误性能（Performance）不满足系统可测量的属性值，如执行时间、事务处理速率等系统/模块接口（System/Interface）与其他组件、模块或设备驱动程序、调用函数、控制块或参数列表等不匹配、冲突注意：需求分析、设计阶段，文档类型的缺陷多；集成测试阶段，一般接口类型的缺陷多一些；系统测试阶段，功能、界面类型的缺陷多一些；验收测试阶段，更多的关注性能缺陷；实施过程，可能会遇到一些软件包的缺陷。
- 缺陷严重程度（Severity）：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度；缺陷严重等级描述致命（Fatal）系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危及人身安全严重（Critical）系统的主要功能部分丧失，数制不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响一般（Major）系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题较小（Minor）是操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题
- 缺陷优先级（Prionty）：缺陷的优先级指缺陷必须被修复的紧急程度；缺陷优先级描述立即解决（P1）缺陷导致系统几乎不能使用或测试不能继续，需立即修复高优先级（P2）缺陷严重，影响测试，需要有限考虑正常排队（P3）缺陷需要正常排队等待修复低优先级（P4）缺陷可以在开发人员有时间的时候被纠正缺陷的严重程度和优先级没有任何直接的关系，如果优先级和严重程度都高的缺陷，纯属巧合。
- 缺陷状态（Status）：缺陷状态指缺陷通过一个跟踪修复过程的进展情况；缺陷状态描述激活或打开问题还没有解决，存在源代码中，确认”提交的缺陷“，等待处理，如新报的缺陷已修正或修复已被开发人员检查，修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证关闭或非激活测试人员验证后，确认缺陷不存在之后的状态重新打开测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复推迟这个软件缺陷可以在下一个版本中解决保留由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷不能重现开发不能再现这个软件缺陷，需要测试人员检查缺陷复现的步骤需要更多信息开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等重复这个软件缺陷已经被其他的软件测试人员发现不是缺陷这个问题不是缺陷需要修改软件规格说明书由于软件规格说明书对软件设计的要求，必须要修改软件规格说明书
- 缺陷起源（Origin）：缺陷起源指缺陷引起的故障或事件第一次被检测到的阶段；缺陷起源描述需求在需求阶段发现的缺陷架构在系统架构设计阶段发现的缺陷设计在程序设计阶段发现的缺陷编码在编码阶段发现的缺陷测试在测试阶段发现的缺陷用户在用户使用阶段发现的缺陷
- 缺陷来源（Source）：缺陷来源指缺陷的起因；缺陷来源描述需求说明书需求说明书的错误或不清楚引起的问题设计文档设计文档描述不准确，和需求说明书不一致的问题系统集成接口系统各模块参数不匹配，开发组之间缺乏协调引起的缺陷数据流（库）由于数据字典、数据库中的错误引起的缺陷程序代码是编码中的问题所引起的缺陷
- 缺陷根源（RootCause）：缺陷根源指发生错误的根本因素。缺陷根源描述测试策略错误的测试范围，误解了测试目标，超越测试能力等过程、工具和方法无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等团队/人项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等硬件硬件配置不对、缺乏或处理器导致算术精度丢失，内存溢出软件软件设置不对、缺乏或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫的问题等工作环境组织机构调整，预算改变，工作环境恶劣，如噪音过大
缺陷的生命周期
- 由测试人员发现BUG；
- 测试人员确定是BUG后，提交BUG；
- 产品经理或开发组长收到BUG后，一般会根据谁的缺陷谁负责，将BUG分配给开发、UI设计甚至是产品经理；
- 分配好BUG后，第一步是确认是否是BUG，是则确认BUG；
- 确认BUG后进行BUG修复，修复后报告测试人员；
- 测试人员收到开发修复好后，进行回归测试，验证缺陷是否修复成功；
- 修复成功后由测试人员关闭BUG，否则出了问题，测试一律不背锅。
缺陷的识别
- 通过测试用例中的预期结果进行识别；
- 通过需求规格说明书进行识别；
- 通过用户手册及其他文档进行识别；
- 通过同行业相类似成熟的商业软件来识别；
- 通过和开发人员的沟通进行识别；
- 通过和有经验的测试人员沟通进行识别；
- 参照同行业隐式需求进行识别；
缺陷报告
编写目的和预期读者
编写目的：
- 易于搜索软件测试报告的缺陷；
- 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确；
- 软件开发人员希望获得缺陷的本质特征和复现步骤；
- 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。
预期读者：
开发人员、质量管理人员、市场人员、运维人员……
报告编写准则
- 准确（Correct）：每个组成部分的描述准确，不会引起误解；
- 清晰（Clear）：每个组成部分的描述清晰，易于理解；
- 简洁（Concise）：只包含必不可少的信息，不包括任何多余的内容；
- 完整（Complete）：包含复现该缺陷的完整步骤的其他本质信息；
- 一致（Consistent）：按照一致的格式书写全部缺陷报告。
缺陷描述准则
- 单一准确
- 可以再现
- 完整统一
- 短小简练
- 特定条件
- 补充完善
- 不做评价
缺陷管理方式和模板
缺陷报告模版：
- 缺陷编号：Bug_项目名称_模块名称_功能名称_001；
- 所属模块：一级模块/二级模块/……；
- 优先级：P1>P2>P3>P4；
- 严重程度：S1>S2>S3>S4；
- 缺陷概述：用一名话描述缺陷的基本情况；
- 提交人：谁提交写谁名；
- 备注：该缺陷的特殊情况，一般是BUG的截图。
缺陷跟踪系统：
- 禅道
- QC
- Bygzilla
- JIRA
- Bugfree
- TAPD