1、缺陷介绍
缺陷定义：软件在使用过程中出现的任何问题都叫软件的缺陷，简称bug
软件缺陷判定标准：
1、软件未实现需求（规格）说明书中明确要求的功能--也就是少功能
2、软件出现了需求（规格）说明书中指明不应高出现的错误--也就是功能错误
3、软件实现的功能超出需求（规格）说明书指明的范围--也就是多功能
4、软件未实现需求（规格）说明书中虽未指明但应该实现的要求--也就是阴性功能错误
5、软件测试人员认为：软件难以理解、不易使用、运行缓慢、用户体验不好--也就是不易使用
缺陷产生原因：
1、需求阶段：需求描述不易理解、有歧义、错误等。
2、设计阶段：设计文档存在错误或缺陷
3、代码阶段：代码出现错误
4、运行阶段：软硬件系统本身故障导致出现软件缺陷。
软件缺陷的生命周期：
缺陷核心内容（缺陷的描述【告诉别人缺陷是什么、发生在哪里、如何发生的】、缺陷的提交要素）：
1、缺陷的标题：描述缺陷的核心问题
2、缺陷的预置条件：缺陷产生的前提
3、缺陷的复现步骤：复现缺陷的过程
4、缺陷的预期结果：希望得到的结果
5、缺陷的实际结果：实际得到的结果
6、缺陷的必要附件：照片、日志等信息（证据）
缺陷提交要素：
缺陷类型：
1、功能错误
2、界面（UI）错误
3、兼容性
4、数据
5、易用性
6、改进建议
7、架构
2、回归测试
定义：添加新功能之后为了避免原有的功能无法使用，需要对之前已经测过的功能进行再次测试
常规测试：一般指测试新增功能所涉及的模块
非常规测试：例如军工、航天等，需要保持高度的严谨性，所以在添加新功能之后前面所有的功能都需要重新测一遍。
3、回归bug
指的是：在上一个版本当中出现过的bug，需要在新的版本当中进行再次验证。
4、缺陷编写
缺陷报告示例：
缺陷跟踪流程：
提交缺陷注意事项：
1、可重现（缺陷可以重新复现）
2、唯一性（一个缺陷只上报一个问题）
3、规范性（符合公司或者项目要求）
缺陷编写规范：
1、准确（描述的缺陷信息是正确的）
2、简洁易懂（缺陷信息描述简单、便于理解）
3、具体（有细节，且是真实特定的）
4、次序清晰（描述缺陷过程有条理，有先后顺序）
5、缺陷标题分析
缺陷标题的作用：让人明白是哪里错了
如何让人明白哪里错了：
描述测试数据+实际结果（预期结果）
描述测试数据+预期结果（实际结果）
描述测试数据+实际结果（需求）
6、使用Excel或工具对缺陷进行管理
Excel：
缺陷编号
缺陷标题
缺陷状态
严重程度（严重级别）
优先级（什么时候修复）
模块
缺陷描述
附件
其他：
指派人
缺陷类型
工具：
禅道（提交与关闭）：
介绍：开源免费、轻量级使用简单
特点：
三权分立：
产品部门--构想者
研发部门--执行者
测试部门--保证者
四角协调：
产品经理
项目经理
研发团队
测试团队
缺陷管理流程：
提交、验证、关闭