缺陷的定义
①软件未达到需求规格说明书表明的功能
②软件出现了需求规格说明书明确指定不能出现的错误
③软件功能超出了需求规格说明书指明的范围（多做的功能是画蛇添足）
④软件未达到需求规格说明书未明确指定却应该达到的功能（手机一重启App数据就丢失）
⑤测试人员认为软件难以理解、不易使用、速度慢或最终用户认为不好（甲方拿钱，乙方干工程）

缺陷的表现形式
①功能特性没有实现或部分实现
②设计不合理，功能不明确，逻辑不清楚，存在矛盾
③产品实际结果和预期结果不一致
④没有达到需求规格说明书所规定的性能指标
⑤运行出错，运行中断，系统崩溃，界面混乱
⑥数据不正确，精度不够，数据不完整或格式不统一
⑦用户不能接受的其他问题，比如存取时间过长，界面不美观

格式组成
1）缺陷ID：就是唯一的编号，ID具有唯一性，可以根据ID追踪到具体缺陷
2）缺陷状态：就是BUG修复过程的进展情况 ☆（不同公司定义不同）
提交（New）：已提交完成的缺陷，开发没有确认
打开（Open）：开发已经确认是缺陷
修复（Fixed）：开发已经修复好缺陷，等待测试人员回归测试
打开（Reopen）：修复完的BUG依然有问题，指定开发重新修改
关闭（Closed）：通过回归测试，BUG被成功修复
拒绝（Rejected）：开发认为不是缺陷，拒绝修改（可能无法重现，或步骤不明确）
延后（Delay）：开发认为暂时不需要修复，或等待下个版本修复
3）缺陷标题：简洁描述缺陷的内容（总结性语言）

4）缺陷严重等级：该缺陷对产品影响的程度
1级（Low）：表面性错误，如错别字，显示格式不规范
2级（Medium）：影响相对独立的功能，在特定条件下会发生，断断续续出现问题
3级（High）：功能点没有实现，不符合用户需求，提交后数据丢失（大多数BUG）
4级（VeryHigh）：频繁死机，系统大部分功能不可用
5级（Critical）：系统瘫痪，异常退出，死循环，严重的计算错误

5）缺陷优先级：
优先级：指的是缺陷被修复的先后顺序（给开发人员的建议）
P0紧急：不能满足产品要求，核心功能明显未实现或完全不可用，阻塞测试流程与进度
P1高：产品的功能实现和需求不符合，没有达到预期的效果，但不阻塞测试进度
P2中：比较小的功能、UI或交互问题，可以绕过此类问题来进行测试
P3低：一些可修改或不可修改，或者是还不确定能否修改成功的BUG，均不影响用户体验使用

6）缺陷类型：
功能缺陷：无法实现，不符合需求（最常用）
兼容性缺陷：系统兼容、浏览器兼容、分辨率兼容（常用）
界面缺陷：删除操作未给出提示，界面不规范，文字图片位置（常用）
系统缺陷：死机、崩溃、异常退出、程序错误
数据缺陷：数据计算错误、输入输出错误
数据库缺陷：连接错误、表中有冗余、表中有过多空字段（设计）、约束错误
接口缺陷：接口返回异常，传参类型错误
安全性缺陷：超时限制（session）、访问权限、无加密
性能缺陷：未达到性能指标（并发量，负载量，压力指标）

6.缺陷修改说明
说明：并不是所有的缺陷，都需要修改☆
①由于市场动态竞争，使得产品需要提前发布，没有充分的时间修复BUG（优先级）
②修改此BUG，会影响其他模块较多，会带来的风险较大，所以延迟到后续版本再修复
③修改性价比太低，也就是耗费时间长，浪费人力物力财力，效果还不明显
④缺陷难以重现，重现概率低，周期性很长

7.缺陷报告的注意事项
说明：缺陷报告是提交给开发人员用于BUG修复，如果报告含糊不清，会误导开发人员，影响缺陷修复速度，进而影响软件研发进度。同时也会影响测试人员本身的声誉，影响团队协作
注意事项：
①要保证缺陷可以重现
②文件简单明确、专业完整，确保开发迅速定位问题
③一个缺陷对应一个报告
④避免使用“似乎”、“可能”、“大概”、“差不多”等含义模糊的词语，需要写出确定的结果
⑤避免使用自己认为“很幽默”的词语，只需客观描述缺陷信息

加油