软件缺陷的表现形式（分类）
- 软件没有做到规格说明书上要求要做到的事情
- 软件产生规格说明书上规定不能出现的错误
- 软件做了规格说明书上没有要求做的事情
- 软件没有做产品规格说明书上没有提到的但应该完成的事情
- 软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
什么是缺陷报告？
当测试人员发现了一个缺陷，需要填一份“缺陷报告”来记录这个缺陷，并通过这个缺陷报告知道发生的问题–缺陷报告是测试人员与开发人员交流沟通的重要工具
缺陷报告的组成
| 1. 缺陷编号（Defect ID） | 表示提交缺陷的顺序（一个项目组统一编号） |
| 2. 缺陷标题（summary） | 简明扼要的描述一下该bug |
| 3. 缺陷发现者 Detected By | 一般是自己 |
| 4. 发现缺陷的日期(Detected on date) | 一般就是当天 |
| 5. 缺陷所属的模块 subject | 在测试哪个功能模块的时候发现的bug，开发经理会根据bug所在的模块找到指定的负责人 |
| 6. 发现缺陷的版本（Detected in release） | 在那个版本发现的bug，版本号一般由开发组确定 |
| 7. 指派给谁处理（Assigned to） | 测试人员指派给开发经理，开发经理会根据bug所在模块，再指派给具体的开发人员修复bug |
| 8. 缺陷状态（status） | 表示bug目前所属的状态或处理情况 （1）测试人员发现bug，提交给开发经理，把缺陷状态写成：new（新提交的bug） （2）开发经理验证新提交的bug，如果是bug，把缺陷的状态改为：open（打开的缺陷，开发组承认的bug）然后指派给具体的开发人员修复bug；如果不是bug，把状态改为rejected（拒绝的bug） （3）开发人员对bug进行修复，修复完成后把bug的状态改为：fixed（已经修复的bug，待返测的bug） （4）测试人员对已经修复的缺陷进行反侧，如果返测通过，把bug状态改为close（关闭的bug，归档的bug，返测成功的bug），如果反侧失败，把bug状态改为：reopen（重新打开的bug，返测失败的bug） （5）这个过程我们称作缺陷报告的处理流程或者叫做一个缺陷的生命周期：new–>open–>fixed–>close |
| 9. 缺陷的严重程度（severity） | （1）Urgent：造成死机，重启，异常终止等问题。 （2）Veryhigh：非常严重的问题 （3）High：严重的问题 （4）Medium：中等程度的问题 （5）Low：小的问题 |
| 10. 缺陷的优先等级（priority） | （1）Urgent：立即修复，否则影响开发或者测试进度。 （2）Veryhigh：版本解决 （3）High：下版本解决 （4）Medium：在发布之前解决 （5）Low：在发布之中允许存在 影响优先级的因素： （1）缺陷的严重程度，一般严重程度越高，优先级越高。 （2）缺陷的影响范围，影响范围越广优先级越高。 （3）参考开发组的任务安排 （4）解决缺陷的成本（时间） |
| 11. 缺陷描述（description） | 把发现的缺陷步骤数据记录下来，让开发人员通过这些描述可以再现该bug |
缺陷报告的用途
1.记录bug
2.对bug进行分类（发现者，日期 模块 版本 状态 严重程度 优先级）
3.对缺陷进行跟踪（new–>close）
4.对缺陷进行分析及总结
如何识别一个bug
- 参考测试用例的预期结果
- 参考相关文档（需求 开发 用户手册）
- 讨论
- 参考缺陷的5点定义（什么是软件缺陷？错误，毛病，功能的失效与违背，使用中的错误，异常）
处理缺陷注意事项
- 一个报告只提交一个缺陷
- 缺陷描述清晰易读，准确，使用最少，必须的步骤，保证缺陷重现
- 提交缺陷报告之前一定要认真审核，确保提交缺陷是有效缺陷，而不是因自己疏忽或操作不当造成的缺陷
- 不要为了引起开发人员注意夸大缺陷
- 小的bug也要报告
- 及时报告bug
- 对于不可重现的bug也要报告
- 不做任何评价
- bug修复后不能只复测修改的问题，还要回归改动代码所涉及到的地方
- bug修复后产生新的bug的后，重新提bug，不可在原缺陷报告中修改
- 经常出现的问题要拉上开发一起沟通如何避免这些问题
- 缺陷报告描述能多详细就多详细，减少复现和沟通成本
缺陷定位
第一步：定位问题是前端还是后端
1、前端请求该接口是否正确（对照接口文档），校验 请求方法 协议域名 路径 参数报文头
2、后端处理校验看日志和数据库的数据，主要看日志打印和数据库交互的过程是否有问题、拿的SQL还是noSQL
3、后端返回是否正确（对照接口文档），校验 状态码 响应头 响应体、响应体和数据库中的数据是否一致
4、前端是否处理返回的数据、处理的是否正确，处理后是否有渲染页面
第二步：根据传入参数进行代码走查定位代码问题
定位到代码行数后截图填入缺陷报告中，也可以附带解决方式
缺陷的生命周期
测试人员------>提交缺陷报告------>new
↓
开发经理 分配缺陷报告------>open
↓
开发人员 处理缺陷报告------>fixed
↓
测试人员 返侧报告
↓ ↓
返测通过 返测不通过
↓
测试人员 关闭缺陷报告-->close