缺陷的基本概念、缺陷报告
缺陷的基本概念：
定义：从内部看，软件缺陷试产品开发或者维护过程中存在的错误、毛病等各种问题。
从外部看，软件缺陷是系统所要实现的某种功能的失效或者违背
总的来说，缺陷就是问题，最终表现为所需要的功能没有完全实现，没有满足用户的需求。
具体包含（程序、数据、文档)：
未达到需求规格说明书中的功能
出现了需求规格说明数中指名不会出现的错误。
功能超出了需求规格说明书的范围。
未达到需求规格说明书中虽然没有指明，但应该达到的目标。
测试人员或者用户认为软件难以理解、不易使用、运行速度慢或者最终用户认为不好。
表现形式：
功能、特性没有实现或者部分实现
设计不合理。功能特性不明确，逻辑不清楚或者存在矛盾。
产品实际结果和所期望的结果不一致
没有达到需求规格说明书所规定的性能指标。
运行出错，中断、奔溃、界面混乱
数据不正确、精度不够，不完整，格式不统一。
用户不能接受的其他问题，超时、界面丑陋。
硬件或者系统软件上存在的其他问题
缺陷产生的原因：
缺陷不可避免，主要原因如下
需求解释或者记录错误。
用户需求定义错误。
需求说明存在错误。
编码说明、程序代码有无。
硬件或者系统存在错误。
文档错误、内容不正确、拼写错误。
缺陷产生的根源：
交流不充分。
软件的复杂性。
开发任务的错误。
需求的变化。
进度压力。
缺陷的修复费用：
缺陷报告
缺陷报告的一些字段及说明（红的必须有）：
缺陷状态：
1.new-测试人员发现缺陷
2.assigned -由开发经理或者其他人员，将修复职责指定为某位开发人员
3.开发人员阅读缺陷报告，可能得到如下结果：
open测试人员是正确的，准备修复
duplicate与其他bug为同一原因，修正好一个后,这个也就修复了- reject测试人员理解错误，其实这不是bug
fixed 经过一段时间开发人员修复了bug，就会标记为此状态- postpone 小问题,目前没有时间修复
4.测试人员检验缺陷状态
closed再次测试,发现错误已经修复。
closed reject的错误,经过沟通核实后,确认无需修复
reopen原来修复后的缺陷，经过回归测试后又出现了，标记原先的缺陷为此状态
缺陷报告的作用：
1、记录测试结果
2、方便开发人员进行缺陷的定位
3、为后期统计缺陷提供依据
内容：
测试环境描述。
步骤：
1、加上编号
2、一个步骤不要包含太多步骤·可能将多个步骤合为一个
3、可以包含该步骤后的一个中间结果
4、可使用短语或者短句，不需要复杂句式。
实际结果清楚，不笼统
期望结果根据需求文档，应该出现的结果。
附件截图、录屏、测试中需要的数据
解决方案/可能的原因（非必须)如果测试人员能够给出解决方案则更好了。
缺陷统计
通过缺陷统计,我们可能得出以下信息
缺陷分布:找出系统的薄弱环境
缺陷状态:根据变化,检查测试和开发的工作传况。
人员水平:开发人员出错的数量，测试人员测出的数量。
比较历史:对人员水平有所把握
模块难度:较难的模块出问题的可能较大
修复时间:平均修复缺陷需要的时间,越短越好。
未修复的缺陷数目:
作用：
风险评估:能否在计划内的时间发布。
缺陷原因:避免反复出现同类型的缺陷
员工技能提升:根据开发和测试人员表现出来的问题，可有针对性提升。
团队配置:根据缺陷修复时间,可知道团队配合强弱
缺陷密度：单位缺陷数量/kloc ( kilo lines of code)计算总缺陷数量/总代码行数/1000
原则:5C准则
准确:每个组成部分的描述准确不会引起误解。
简洁:只包含必不可少的信息，不包括任何多余的内容.
清晰:每个组成部分的描述清晰，易于理解。
完整:包含复现该缺陷的完整步骤和其他本质信息。
一致:按照一致的格式书写全部缺陷报告。
一个缺陷-一个报告：便于分配，便于验证
