5.1 软件缺陷
* 定义：是存在于软件之中的那些不希望或不可接受的偏差，即软件质量问题
* 软件故障（内部状态的一种行为），软件失效（外部行为结果），缺陷是故障和失效的源头
* 软件缺陷：
-- 未实现要求的功能
-- 出现指明不该出现的错误
-- 实现未要求的功能
-- 未实现说明书未说明但应实现的目标（隐性需求）
-- 软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户认为不好
* 缺陷来源
l 需求（Requirement）：由于需求说明书的错误或不清楚的问题引起的缺陷
l 架构（Architecture）：由于架构考虑不周问题引起的缺陷
l 设计（Design）：由于设计文档描述不准确，和需求说明书不一致的问题引起的缺陷
l 编码（Coding）：纯粹在编码中问题引起的缺陷
l 集成（Integration）：由于系统个模块参数不匹配、开发组之间缺乏协调问题引起的缺陷
l 数据流（库）（Database (data stream)）：由于数据字典、数据库中的错误引起的缺陷
l 测试(Test)：由于测试覆盖少问题引起的缺陷
l 用户（Customer）：由于用户问题引起的缺陷
l 其他（Other）：由于其他问题引起的缺陷
* 软件缺陷描述：
-- 缺陷id、缺陷标题、缺陷严重程度、缺陷紧急程度、缺陷提交人、缺陷提交时间、缺陷所属项目/模块、缺陷解决人、缺陷处理人、缺陷处理结果描述、缺陷处理时间、缺陷验证人、缺陷验证结果描述、缺陷验证时间、测试环境说明、必要附件（图片等）
-- 从统计角度：缺陷引入阶段、缺陷发现阶段等
* 缺陷严重程度：
1）Critical：不能执行正常鬼能或重要功能，或者危机人身安全
2）Major：严重影响系统要求或基本功能的实现，且无法更正
3）Manor：严重影响系统要求或基本功能的实现，但存在合理更正办法
4）Cosmetic：造成操作者不便或遇到麻烦，但不影响执行工作或重要功能
5）Other：其他错误
* 缺陷优先级：
-- 处理和修正软件缺陷先后顺序的指标
-- 3个等级：High（立即解决），Middle（正常排队），Low（方便的时候）
-- 严重程度高的优先级不一定高，严重程度低的优先级不一定低
* 缺陷管理
-- 确保缺陷被解决；数据分析，作为组织的过程财富
-- 管理流程：
* 缺陷状态：
l Submitted：测试人员提交新的错误到库
l assigned：已分派
l Rejected：拒绝“提交的缺陷”，不需要修复（Wont Fix）或不是缺陷（Invalid）
l Fixd or Resolved：已解决但还没有被测试人员验证
l Closed：测试人员验证后，确认缺陷不存在并关闭
l Reopen：重新激活缺陷
l Duplicate：重复缺陷
l Invalid：无效缺陷
l Delay：延期修复
* 缺陷类型
l 功能问题：影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如指针循环，递归，功能等缺陷。
l 接口问题：与其他组件、模块或设 备驱动程序、调动参数、控制块或参数列表相互影响的缺陷。
l 逻辑问题：需要进行逻辑分析，进行代码修改，如循环条件等。
l 计算问题：等式、符号、操作符或操作数错误，精度不够、不适当的数据验证等缺陷。
l 数据问题：需要需改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。
l 用户界面问题：人机交互特性：屏幕格式，确认用户输入，功能有特性，页面排版等方面的缺陷。
l 文档问题：影响发布和维护，包括注释等缺陷。
l 性能问题：不满足系统可测量的属性值，如：执行时间，事物处理速率等缺陷。
l 配置问题：由于配置库、变更管理或版本控制引起的错误。
l 标准问题：不符合各种标准的要求，如编码标准、设计符号等缺陷。
l 环境问题：由于设计、编译和运行环境引起的问题。
l 兼容问题：软件之间不能正确的交互和共享信息。
l 其他问题：以上问题所不包含的问题
5.2 软件缺陷的度量、分析和统计
* 对缺陷数据采集和量化，将分散数据统一管理，有序而清晰，通过数据函数，对数据处理，分析密度和趋势等，从而 提高产品质量 和 改进开发过程
* 主要度量：缺陷密度（规模上的分布）、缺陷率（时间上的分布）、整体缺陷清除率、阶段性缺陷清除率、缺陷趋势、预期缺陷发现率等
缺陷度量：
-- 缺陷密度
* 缺陷多的地方，还有更多的缺陷将被发现，漏掉的缺陷可能性也会更大
* 如果缺陷密度比上一个版本相同或更低，应该分析当前版本的测试效率是不是降低了？
如果不是，意味着质量的前景是乐观的；
如果是，就需要额外进行测试，还需要对开发和测试的过程进行改善
* 如果缺陷密度比上一个版本高，就该考虑，在此之前是否为提高效率而进行了有效策划并在本次测试中实施？
如果是，虽然需要开发人员做更多努力去修正缺陷，但质量还是得到更好的保证；
如果没有，意味着质量恶化、质量很难得到保证。要保证质量，就要投入更多资源或延长开发周期
* 定义： 缺陷密度=已知缺陷的数量/产品规模
产品规模的单位可以是文档页、代码行、功能点。（比如千行bug率）
* 主要作用：设定产品质量目标、支持软件可靠性规模、预测潜伏的软件缺陷进而对软件质量进行跟踪和管理、支持基于缺陷计数的软件可靠性增长模型，从而对软件质量目标进行跟踪并评判能否结束软件测试。
-- 缺陷率
* 通用概念：一定时间范围内的缺陷数/错误几率 （不是太理解）
* 之前培训老师说道的一个公式：一个版本内发生缺陷/需求总数
-- 缺陷清除率
* 可用作缺陷的 预测和分析
* 分为整体和阶段清除率，阶段可反映整体
* 缺陷清除率=已发现的/潜在的
由于潜在的不容易确定，所以缺陷清除率 ≈ 已发现的/（已发现的+以后发现的）
* 整体清除率
F=功能点数；D1=开发过程中发现的所有缺陷数；D2=软件发布后发现的缺陷数；D=总缺陷数=D1+D2
质量（每功能点的缺陷数）=D2/F
缺陷注入率=D/F
整体缺陷清除率=D1/D
-- 缺陷趋势：一定周期时间或一定阶段内，产生或发现缺陷的动向和规律，通常用趋势图表示
-- 缺陷发现率
* 描述在特定时间段内发现缺陷数的一种度量指标，预期将来可能发现的缺陷个数，有些组织把发现率作为判断测试是否可以结束、预测产品发布日期的重要度量
* 缺陷发现率 = 测试人员各自发现的缺陷数总和 / 各自花费的测试时间总和
缺陷分析：
-- 缺陷分析的好处：
* 可以发现各类缺陷发生的概率
* 掌握缺陷集中的区域、明确缺陷发展趋势、挖掘缺陷产生的根本原因
* 有针对性的提出遏制缺陷发生的措施、降低缺陷数量
缺陷报告中的分析：
* 对当前软件质量状况的评估
* 判定软件能否按期发布或交付使用的重要依据
* 评估当前软件的可靠性，并预测软件的可靠性变化
* 达到缺陷预防的目的，是缺陷管理的核心任务之一
-- 着眼点：寻找缺陷的共性原因。实现缺陷预防，不断提高整个开发团队的技能和实践经验。
-- 缺陷预防策略：
* 测试活动尽量提前，及时消除前期的缺陷，防止在后期被放大
* 分析已有却缺陷，找出技术上的不足和流程上的不足（缺陷的根源），寻找方法改进不足，预防再次出现。
-- 缺陷分析步骤：
* 记录缺陷，不能仅满足于表面症状，要深入源代码，理解产品的设计和实现
* 缺陷分类，分析产生的根源，针对性制定改进措施。这一阶段的成果，开发人员可以预防缺陷的发生
* 缺陷预防分析，整个分析过程的核心。这以及诶单总结出的时间可在更广泛的范围内预防潜在的缺陷。两个重要参数：缺陷数量的趋势、缺陷修复的趋势
* 编写缺陷分析报告，绘制缺陷分析图。报告中的数据统计及分析是对软件质量的权威评估，也是确定测试是否达到测试标准、判定测试是否已达到客户可接受状态和判定软件是否能发布或交付使用的重要依据。
5.3 软件缺陷报告
原则：
* 尽快报告软件缺陷
* 有效描述软件缺陷
* 报告缺陷时不做任何评价
* 确保缺陷可以复现
