概念：
软件缺陷：软件或程序中存在的各种问题及错误；
软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需求执行测试用例时，实际结果与预期结果不一致；
构成要素：
1、缺陷ID：唯一
2、缺陷的标题：缺陷的概要描述；
3、缺陷的截图：实际与预期；
4、缺陷的预置条件：缺陷发生的前提条件；
5、缺陷的重现步骤：缺陷再次出现的步骤；
6、缺陷的实际结果：缺陷的实际表现细节；
7、缺陷的期望结果：软件本应达到的功能/表现；
8、缺陷日志：缺陷的记录；
9、缺陷的状态：当前软件的修复阶段；
10、缺陷的严重程度：评估软件的质量；
11、缺陷的优先级：软件缺陷的修改顺序；
12、所属模块：缺陷发现的所属模块；
13、缺陷类型：缺陷是什么样的错误；
软件缺陷必须符合的原则：
1、软件未达到产品说明书表明的功能；
2、软件出现了产品说明书指明不会出现的错误；
3、软件功能超出了产品说明书指明范围；
4、软件未达到产品说明书虽然但应达到的目标；
5、软件测试人员认为难以理解，不易使用，运行速度缓慢，或者最终用户觉得不好；
软件产生的原因：
1、需求分析出现偏差；
2、设计过程中缺乏有效的沟通或者没有沟通，导致对需求的理解出现偏差或者设计人员设计能力低；
3、软件复杂越来越高；
4、编码环节产生错误（程序错误或者开发人员对设计的理解不一致）；
5、需求不断变更；
6、项目进度的的压力；
7、不重视开发文档；
8、软件开发工具本身隐藏的问题；
9、白盒测试可能修改代码引入缺陷；
缺陷分类：
代码问题：不满足需求、功能实现错误，对产品或项目质量有影响的BUG可统一划入；
设计缺陷：页面美观性，协调性，错别字等；
用户体验：对产品，项目的建议性意见，不强制要求修改；
性能问题：进行性能测试时使用，网络延时，内存问题，CPU占用，硬盘问题；
安全问题：业务功能存在的安全问题；
接口问题：涉及有模块间数据传递时使用
配置问题：由于提供的配置不当或者配置不能够满足设计要求二出现的问题；
解决办法：
1、尽早参与评审，与用户，分析人员，设计人员，编码人员沟通交流；
2、测试准备工作尽早开展；
3、尽早预防，做缺陷分析；
缺陷的生命周期及状态流程过程：
缺陷的处理过程或缺陷的生命周期就是一个去诶信息案从创建到关闭的全过程；
这个过程中根据开发与产品的策略，一个缺陷可能会经历以下几种不同的处理场景：
场景1:确认BUG解决：
测试提交缺陷【New】->开发确认缺陷【Open】->开发解决缺陷【Fixed】->测试回归缺陷->关闭缺陷【Closed】
场景2：验证未通过，缺陷仍存在
测试提交缺陷【New】->开发确认缺陷【Open】->开发解决缺陷【Fixed】->测试回归缺陷->指派给开发重新解决【Reopen】
场景3：重新打开
【Closed】的缺陷，再次出现，测试人员把关闭的缺陷【Reopen】
场景4：开发延期处理
测试提交缺陷【New】->开发确认缺陷【Open】->延期处理【Later】
场景5：拒绝处理
测试提交缺陷【New】->开发确认缺陷【Open】->拒绝处理【Reject】
其他：duplicate（重复bug,之前已经发现），worksforme（该bug无法重现），won't fix（是bug，但不值得修改），bydesign（就是这样设计的，无效的的bug），invalid（无效的bug），external（外部因素造成的的，浏览器，操作系统等第三方软件）
缺陷分析与报告：
怎样判断是不是软件缺陷？
1、用户体验感不好；
2、界面上有明显的错误信息；
3、功能不完备，导致功能缺失；
4、功能不完善；
5、逻辑不正确，与需求说明书不符；
6、模块之间的交互性不好，与其他的模块做集成性测试时遇到问题；
7、程序的性能不够好，不能承载压力考验；
当发现一个缺陷时，应该怎么确认的确是一个缺陷？
1、可以将软件需求说明书，用户手册以及联机帮助作为识别和判断缺陷的辅助工具；
2、通过增加自己对测试软件产品的行业背景知识的了解来发现被忽视的问题；
3、通过沟通的方式来收集，学习和分享其他人判断缺陷的方法和经验；
怎样处理无法再现的缺陷：
1、应当对这样的的缺陷进行详细的记录，并尽快提交给开发人员；
2、对于寻找难以再现的缺陷要合理的的安排时间；
3、在测试过程中对未再现缺陷予以关注；
缺陷分析报告内容：
1、测试目的：主要发现哪些模块的问题；
2、测试概要：本次测试的依据，主要覆盖的测试用例，编写了多少测试用例，发现了多少bug，最终的测试结果；
3、测试周期：版本，各个版本的测试周期，测试人员等；
4、测试内容：测试模块及负责人，用例执行情况；
5、缺陷统计：各模块缺陷统计，缺陷类型统计，人员缺陷统计；
6、建议与要求：产品经理，开发人员，测试人员；
7、优化问题与建议：包含优化问题，影响，改进意见等项；