缺陷的代价 缺陷放大图：
缺陷产生的原因
疏忽造成的错误、不理解造成的错误。二义性造成的错误、遗漏造成的错误。
缺陷发现手段，怎样尽早发现缺陷
同行评审
是指在工作产品开发过程中，为了识别缺陷而由软件产品生产者的同行遵循已定义的规程对产品进行的技术评
审。
（1） 正式评审
正式评审也叫正规检视，通常是由同行评审培训的项目经理或PPQA主持，参与者应具有正规审查知识和了解被审查对象，因此因此也要经过培训。参见者包括来自开发、测试、质量保证部门或用户，作者必须参与，規模在3~7人或8人为宜。正式评审的目的在于定位并除去工作声品中的缺陥。
（2） 技术审查
技术审查也称内部评审或技术评审没有正式评审那么严格，通常由技术负责人或项目经理召集，作者或产品技术领域内的专家参与，3-5人为宜。
（3） 走查
又叫代码走查或代码走读，审查的范围根据需求的优先级通常由管理人员来确定，主要是静态质量分析和编程规则检查。通常是小型讨论会，两三个人参加，由作者主持，是三种评审方式里面最自由的方式。
软件测试
软件测试并不仅仅是为了找出错误。通过分析错误产生的原因和错误的分布特征，
可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也
能帮助我们设计出有针对性的测试方法，从而改善测试的有效性。
管理评审
管理评审(Management Review)是软件开发过程中经常需要进行的另一种评审，一
般包括里程碑评审、过程评审、项目问题总结等活动。
PPQA
PPQA（Product & Process Quality Assurance），即产品过程质量保证，简称 QA。
同行评审和测试是对软件开发过程的工作产品进行质量检查，而 QA 不仅检查工作产品的规范性和符合性，还要对开发中涉及的各个过程按照组织的标准和规范进行评
价。只有在保证开发过程正确的情况下，才能更好地发现缺陷，才能保证质量和进度、
成本，从而进一步保证产品质量。
项目组内部发现
项目组内部人员在开发过程中也会发现一些缺陷，主要反映在“问题报告”。
客户反馈
客户通过电话、邮件、访问售后服务系统等反馈来的信息，是对产品进一步升级换
代和改进的重要依据。从缺陷发现的角度讲，这也是缺陷发现的最后一道屏障。
缺陷的生命周期
（1） 识别
缺陷的识别是整个缺陷生命周期的第一个阶段,它可以发生在软件开发生命周期的任何一个阶段。缺陷的识别可以由参与项目的任何利益相关者完成,
（2） 调查
经过缺陷识别阶段后,需要对每个可能的缺陷进行调查。调查阶段主要是用来发现可能存在的其他问题以及相关的解决方案,解决方案包括"不采取任何行动"。
（3） 改正
根据缺陷调查阶段中得到的结果和信息,就可以采取改正措施解决引起缺陷的错误。采取的行动可能是修复缺陷,也可能是针对开发过程和测试过程的改进建议,以避免在将来项目中重复出现相似的缺陷。针对每个缺陷的修复,需要进行相关的回归测试和再测试，避免由于缺陷的修复而影响原有的功能。
（4） 总结
经过了上面的几个阶段后，缺陷生命周期就到了缺陷的总结阶段。总结阶段的主要活动包括:
记录:在缺陷总结阶段，需要对一些支持数据信息进行记录，例如:缺陷关闭时间、文档更新完成时间等。
分类:针对缺陷进行确认测试和相关的回归测试以后，就可以将缺陷的状态进行分类，例如:关闭状态、延迟状态或者合并到其他项目中去等。
确定影响:对在缺陷识别阶段、缺陷调查阶段和缺陷改正阶段中得到的影响分析进行合适的检查，并在需要的时候进行更新。
如何进行缺陷度量？ 为预防策略提供准备依据
缺陷度量是软件度量的一部分，其本身并不能发现缺陷、剔除缺陷，但是有助于这些问题的解决。另外，当正确、持续地进行了缺陷度量时，产品以及过程的质量属性的数据为实施和管理过程改进活动提供了有效的基础。有助于测试过程监控，对缺陷度量数据进行分析可以为缺陷预防策略提供准确依据。
软件产品的质量度量，主要集中在软件的缺陷度量上。
缺陷度量就是对项目过程中产生的缺陷数据进行采集和量化，将分散的缺陷数据统一管理，使其有序而清晰，然后通过采用一系列数学函数，对数据进行处理，分析缺陷密度和趋势等信息，从而提高产品质量和改进开发过程。
（1）组织级缺陷度量，目的是了解组织的整体缺陷情况，了解客户对组织的质量满意度，建立组织基线，确定改进活动。
（2）项目级缺陷度量，目的是了解项目实时质量情况（很多项目只在最后度量，包括那些迭代式开发的项目，实际上为时已晚），预测缺陷造成的发布后维护工作量，了解客户对项目的质量满意度。
3）个体缺陷度量，目的是了解个体缺陷产生的详细原因，并实施行动进行改进。
前两种度量大家接触较多，但第三种度量常常被忽略。这常常导致：项目反复得到关于自己的质量评价，但很难了解如何去提高；测试组常常能做一些改进（如增加测试覆盖、延长测试周期）来提高缺陷排除效率，但开发组没有降低缺陷产生数量的有效措施；软件开发遵循了编码规范，但似乎对提高质量没有太多帮助。
缺陷跟踪流程
缺陷被提交后可能会出现哪些结果。
| 编号 |
缺陷状态 |
描述 |
|
| 1 |
提交（Submitted或New） |
已提交的缺陷 |
|
| 2 |
打开（Open或Active） |
经审查后确认的缺陷，等待处理 |
|
| 3 |
拒绝（Rejected、Refuse或Not a bug） |
经审查确认不是缺陷、不需要修复或不需要提交 |
|
| 4 |
修复（Resolved或Fixed） |
或为Fixed。缺陷已被修复 |
|
| 5 |
关闭（Closed或Inactive） |
经审查确认已被修复的缺陷，可将其关闭 |
|
| 6 |
推迟（Later、Pending或Deferred） |
当前无法修复，以后条件具备时再解决，但要确定修复的日期 |
|
| 7 |
重新打开(Reopen) |
经过修复的缺陷未通过验证测试，或已关闭的缺陷重新出现 |
|
bug提交到缺陷库中会自动的被设置成New状态
Assigned（已指派）：
当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”
Open（已打开）：
开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”
Fixed（已修复）：
当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组
Rejected(被拒绝)：
测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”
Postponed（延期）：
有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”
Closed（已关闭）：
测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed” 如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”
书写优良的缺陷报告：
5C原则
(1)内容正确：每个组成部分的描述正确，不会引起误解;
(2)内容清晰(Clear) :每个组成部分的描述清晰，易于理解;
(3)步骤简洁(Concise) :只包含必不可少的信息，不包括任何多余的内容;
(4)结构完整(Complete) :包含复现该缺陷的完整步骤和其它本质信息
(5)风格一致(Consistent) :按照致的格式书写全部缺陷报告