目录
软件在使用过程中存在的任何问题（如：错误、异常等），都叫软件的缺陷，简称bug。
软件缺陷的判定标准
- 软件未实现需求说明书中明确要求的功能
- 软件出现了需求说明书中指明不应该出现的错误
- 软件实现的功能超出需求说明书指明的范围
- 软件未实现需求说明书中虽未明确指明但应该实现的要求（一般指国际/国家/行业/企业标准规范或者法规的要求）
- 软件难以理解，不易使用，运行缓慢，用户体验不好
软件缺陷的核心内容
- 缺陷的标题------描述缺陷的核心问题
例如：后台会员管理输入正确的手机号添加会员添加失败，提示：手机号码有误
缺陷的预置条件------缺陷产生的前提
缺陷的复现步骤------复现缺陷的过程
缺陷的预期结果------希望得到的结果
例如：输入正确的手机号添加会员应该能够成功
- 缺陷的实际结果------实际得到的结果
例如：输入正确的手机号添加会员提示手机号码有误
- 缺陷的必要附件------图片、日志等信息（证据）
构成缺陷的基本要素
- 缺陷编号：缺陷的唯一性标志
- 缺陷状态：表示缺陷当前处于哪个阶段
常见缺陷状态
new：新建，表示缺陷刚创建
open：打开，表示已经指派或者开发认领了bug
inprogress：进行中，表示开发正在修改中
fixed：已修复，表示测试可以验证了
closed：已关闭，表示测试验证通过
rejected：已拒绝，表示开发拒绝了当前bug
postpone/delay：已延迟，表示开发延迟修复该bug
- 缺陷所属模块：缺陷属于哪个被测的模块
- 缺陷严重程度：该缺陷的破坏程度或者影响程度
critical
major
medium
minor
tiny
- 缺陷优先级：处理该缺陷的优先程度
urgent priority
veryhigh priority
high priority
medium priority
low priority
缺陷报告
缺陷管理
提交缺陷注意事项
- 可重现：缺陷可以复现
- 唯一性：一个缺陷上报一个问题
- 规范性：符合公司或者项目要求，准确（描述的信息是正确的），具体（有细节且真实特定） ，简洁易懂（描述简单容易理解） ，次序清晰（描述缺陷过程有条件，有先后顺序）
缺陷的跟踪流程
- 新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此 时就需要测试人员对缺陷进行回归测试，验证问题是否修复。
- 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如"该缺陷已 解决"。
- 如果已经关闭的问题再次出现，则测试人员将该缺陷的状态修改为重新打开；
项目管理工具--禅道
国产、免费、开源、简单、轻量级
三管融合（产品管理、项目管理、质量管理）
测试人员使用禅道
管理用例：创建用例、评审用例
管理缺陷：缺陷的创建
禅道三权分立
核心的三种角色：产品经理、研发团队和测试团队
- 新建用例
测试视图--->用例--->建用例
- 导入用例
用例可以通过表格导入到禅道系统中
第一步：导出测试用例模板
第二步：按照模板编写测试用例
第三步：导入编写好的用例文件
- 评审用例
用例的评审功能，禅道里默认是关闭的。
用例评审是一个线下活动，线下开会评审用例后，由测试人员将评审通过后的用例导入禅道即可。
- 提Bug
测试视图--->Bug--->提Bug