上工治未病之病，中工治欲病之病，下工治已病之病。-- 孙思邈 .《千金方药方》
    释译：未病之病：未病，未发之病（及早干预，防止病发）；欲病之病：小病，病初起之时（症状不明显，病人无痛苦时）；已病之病：重病，病情严重时。

1. 软件缺陷

• 从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。  -- IEEE729-1983 
• 计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
• 软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求。

2. 常用述语

• 错误，Error。软件生命周期内不希望或不可接受的人为痕迹（人为过程、错误，外部行为），错误导致缺陷的产生。（异常、矛盾）
• 缺陷，Defect / Bug。（缺点、偏差 variance、问题 problem） -- 那张有名的BUG图，Harvard Mark II计算机里的一只飞蛾（来源：网络）

• 故障，Fault。软件运行过程中出现的不希望或不可接受的运行结果（内部行为）。
• 失效，Failure。软件运行过程中出现的不希望或不可接受的系统外部表现（外部行为）。（失败）
• 事故，Incident。软件运行失效后出现的不希望或不可接受的损失。（外部行为）

       错误 -- 导致 --> 缺陷 -- 激活 --> 故障 -- 未处理 --> 失效

3. 发现软件缺陷

• 发现人
  
  - 用户、客户；需求、设计、开发、测试、运维、市场；随机“苦力”。。。。。 。
  - 软件生命周期中的所有参与者都可能发现软件缺陷
• 发现阶段
  
  - 业务；需求、设计、开发、测试、构建、发布。。。。。。
  - 软件缺陷存在于软件生命周期的每一个阶段，随着生命周期中软件运行状态的变化，会产生新的非预期缺陷
• 发现方法
  
  - 有计划、有策略的执行：测试用例
  - 总结与经验：探索式测试、验收测试、系统试运行（并行）、业务高危维护
  - 随机发现：Ad-hoc测试、Monkey测试、走廊测试。。。。。。
  - 快速验证：冒烟测试（Smoking Test）、主流程测试、专项测试
  - 手工测试 + 工具/自动化测试

4. 软件缺陷生命周期

5. 新建软件缺陷属性（参考 JIRA 缺陷新建页面）
    - 说明
      * 缺陷类型，由测试执行的版本类型决定，也可在提交页面中自定义，如 功能、UI、接口、配置、集成、性能、文档。。。。。。
      * 产生原因（Root Cause），可由开发人员修复缺陷后确认 或 测试人员关闭缺陷时确认，后期用来对缺陷分布进行分析，从而持续改进质量。如，
        > 过程阶段（客户；需求、架构、设计、编码、测试、发布）
        > 过程管理（时间、成本、范围、办公环境、沟通/管理方式。。。）
        > 团队/人力（沟通、能力、责任心。。。）
        > 文档（需求分析、详细设计、测试用例。。。）
        > 业务（服务器、数据库、接口、代码）
        > 环境（平台、网络、浏览器、工具。。。）
        > 硬件（型号、版本、驱动。。。）
        > 软件（版本、配置。。。）

 6、新建软件缺陷注意点

• 概要/Summary
  
  - 精炼、短小。标识（统一、格式化、提前定义） + 简述（哪类用户，做了什么，系统响应情况）
  - 例：缺陷注册人，未输入概要，点击提交按钮后系统正常提交
• 描述
  
  - 可再现/复现（指导）
  - 客观：只描述、不评价，缺陷现象描述避免使用形容词、副词
  - 条件：缺陷操作产生条件，环境 + 数据 + 角色 + 配置。。。。。。
  - 结果：预期结果 + 实际结果；对比需求/设计，明确缺陷现象
  - 完整、清晰、条理、准确、详细、简洁
  - 步骤使用序号排列，每个步骤只描述一个操作，实际结果描述准确
  - 描述语句使用：简单句、陈述句、主动句（以操作对象为主语，描述实际系统表现； 与测试用例区别：多使用被动句，避免使用具体人称）
  - 建议建立一定格式要求，保证缺陷描述内容完整
• 附件
  
  - 截图（强烈建议），缺陷发生快照（辅助缺陷描述）：保留必要的缺陷发生时的快照 + 添加必要提示、描述（圈示、标号、说明）
  - 录屏，缺陷复现操作复杂、现象难于清晰描述、或难于再现时，可进行录屏，供缺陷修复人原分析、定位缺陷
  - 测试数据，特别设计的测试数据 或 特殊测试所用数据

7. 软件缺陷管理

• 软件缺陷管理，即软件缺陷生命周期管理，参考 3. 软件缺陷生命周期
• 软件缺陷登记/注册/提交时，应关连对应的测试用例，以确保每一条用例都经过验证
• 不放过任何的缺陷，每一个缺陷都应被有效记录、跟踪 和 解决
• 应充分利用工具，以提高软件缺陷发现率，提升测试覆盖率
  
  - 缺陷管理工具：Excel（microsoft相关组件）；JIRA、Bugzilla、Mantis、禅道、Redmine 。。。。。。
  - 测试脚本开发：针对测试对象，使用开发语言开发专项测试工具，如 python, java, ruby。。。。。。
  - 专业测试工具：Loadrunner（性能测试套件）、Jemeter（功能+性能测试）、Postman（接口测试）。。。。。。
• 软件过程管理，将软件缺陷管理纳入软件生命周期管理的有机部分

8. 软件缺陷分析
    说明：
    * 以测试代评，通过缺陷分析评价软件对象质量
    * 缺陷分析指标，应以项目目标为基础，充分考虑 时间、成本、范围 在质量间的平衡关系

• 缺陷数量
• 缺陷状态
  
  - New、Processing、Fixed、Won't fix、Duplicate、Delay。。。。。。
  - 提交缺陷与修复缺陷关系，燃尽图（Burn Down 剩余工作 / Burn Up 完成工作）
• 缺陷分布
  
  - 版本
  - 功能
  - 模块（缺陷聚集效应）
  - 类型（功能、性能、UI、易用性、可用性。。。。。。）
  - 时间（日期）
  - 严重度
  - 产生来源
  - 提交者
  - 开发者（谁开发谁维护）
• 质量评价

参考：

1. 1044-1993 - IEEE Standard Classification for Software Anomalies. | IEEE Standard | IEEE Xplore
2. 【分享】软件缺陷生命周期 - 基智地
3. 软件缺陷的详细整理 - 知乎