软件缺陷：又称之为“Bug”。即计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。
表现形式A
软件没有实现产品规格说明书所要求的功能模块。
表现形式B
软件中出现了产品规格说明指明不应该出现的错误。
表现形式C
软件实现了产品规格说明中没有提到的功能需求。
表现形式D
软件没有实现虽然产品规格说明没有明确提及但应该实现的目标。
表现形式E
软件难以理解、不易使用、运行缓慢、用户体验不友好。
1、软件在使用过程中存在的任何问题都叫软件的缺陷。
2、缺陷不等同于bug。
3、缺陷的存在会导致软件产品在某种程度上不能满足用户的需求
4、只要你的软件让用户觉得不爽
软件未实现需求(规格)说明书中明确要求的功能 –少功能
软件出现了需求(规格)说明书中指明不应该出现的错误 -功能错误
软件实现的功能超出需求(规格)说明书指明的范围 -多功能
软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求 –隐性功能错误
软件难以理解，不易使用，运行缓慢，用户体验不好 -不易使用
需求阶段： 需求描述不易理解，有歧义、错误等
设计阶段： 设计文档存在错误或者缺陷
编码阶段 ：代码出现错误
运行阶段 ：软硬件系统本身故障导致软件缺陷
1、功能错误：软件没有达到需求文档的功能要求，或者功能异常
2、 界面错误：软件功能正常，但是界面不好看或者未达到规格说明中的要求
3、兼容性错误：软件和系统中的其他的程序冲突，导致软件无法运行
4、易用性错误：软件用起来不好用
5、 改进建议：改了更好，不改也没事
1.缺陷标识(ID)： 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。
2.缺陷类型 ： 缺陷类型是根据缺陷的自然属性划分的缺陷种类。功能 接口 需求 易用性..
3.缺陷严重程度 ：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。致命/严重/一般/建议
4.缺陷优先级： 缺陷的优先级指缺陷必须被修复的紧急程度。紧急/一般/不紧急
5.指派人：指这个bug交给谁来修复
6.缺陷状态 ：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
新建（打开）：测试人员或其他人员发现并确认提交的bug，如新提交的bug。
被否决：经过确认，提交的bug确认为不是bug.
待修复：开发确认bug的有效性，进行处理
处理中：开发确认bug的有效性，进行处理
已修复：已被开发人员找到原因并修复的缺陷。
关闭 （最终态）：测试人员在修复的版本中验证该问题确实已修复。
重新打开：测试人员在修复的版本中验证，确认仍存在该缺陷。
待跟踪：bug无法重现，开发不能定位到问题的原因
缺陷报告的重要组成
(1) 编号
提交缺陷的顺序
(2) 标题
简明扼要的描述缺陷
(3) 发现者
谁发现的缺陷，比如工号、用户名、姓名等
(4) 发现日期
提交缺陷的系统日期，一般是当天
(5) 所属模块
哪个功能模块发现的缺陷（方便开发经理根据模块定位该缺陷的负责人）
(6) 所属版本
在软件哪个版本发现的缺陷，如XX系统vYYYY-MM-DD;或XX系统version X.X.X
(7) 指派给谁
测试人员将缺陷指派给开发经理，开发经理会根据该缺陷所在模块再次指派给具体开发人员
(8) 缺陷状态
创建之后默认为激活状态（打开）
(9) 严重程度
准确评估bug的严重程度，评判标准参考公司的定义规范。
(10) 优先级别
准确评估bug的优先级程度。具体参照公司丢与优先级的定义。一般阻塞测试流程的问题为紧急，其它是情况而定
(11) 缺陷描述
把发现缺陷的过程、步骤、使用的数据等记录下来，使开发人员通过该描述再现该Bug
需注意问题：
① 单独记录每一个缺陷，不要把两个或者多个缺陷记录在一起
② 缺陷描述要清晰准确易读，使用必要、量少的步骤保证缺陷复现
③ 对缺陷的严重程度和优先级别的划分要准确、客观
④ 提交缺陷报告前要认真审核，确保提交的缺陷为有效缺陷
⑤ 不要为了引起开发人员的重视而夸大缺陷
⑥ 小的缺陷也需要记录缺陷报告
⑦ 及时报告缺陷（给开发人员留一些充足的修复时间）
⑧ 对发现的缺陷不做任何评价（随意评价缺陷，很容易伤开发人员的心哦）
⑨ 随机缺陷也要报告（随机缺陷不易重现，按照固定步骤时有时无，所以需要表明它是随机缺陷，尽量详细描述其出现的步骤，以及出现的频率等）
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
