软件缺陷属性与度量

资料来源：https://zhuanlan.zhihu.com/p/127769236

一、软件缺陷属性

（一）缺陷严重程度定义

S1 致命（Fatal）：导致系统崩溃、数据丢失或安全漏洞的bug，必须立即修复（Immediate）24小时内修复。例如软件严重崩溃，导致用户无法进行任何操作；执行相关操作必 然引起，对业务流程产生严重阻碍。

处理优先级：最高，需立即修复并重新测试。

严重级别（Critical）

描述：
S2 严重（Critical）：缺陷导致核心功能基本无法使用，严重影响软件正常使用；严重影响开发和测试流程的推进，须在致命缺陷修复后优先修复 两天修复。这类缺陷可能导致部分功能无法测试或开发工作停滞，如关键模块的功能异常，使得相 关功能的联调与软件的整体集成测试无法进行。

示例：

• 1. 系统崩溃或无法运行：软件在启动过程中直接崩溃，无法进入主界面，出现此类问题的概率约占总缺陷数的 5% 10%。例如，在对某大型企业级管理软件进行测试时，约 8%的测试用例执行过程中出现系统崩溃情况，导致整个测试流程无法继续推进。
• 2. 数据丢失或严重损坏：数据是软件的核心资产，一旦出现数据丢失或严重损坏，将对业务造成毁灭性打击。此类问题出现比例大概在 3% 7%。如某金融交易软件测试中，约 5%的交易操作出现数据丢失情况，直接影响交易记录的完整性和准确性。
• 3. 关键功能完全无法使用：关键功能是软件实现核心业务价值的功能模块，若无法使用，软件基本失去意义。这类缺陷占总缺陷数的 10% 15%。以电商购物软件为例，约 12%的测试发现购物车结算功能完全无法使用，严重影响用户购物流程。

处理优先级：高，需优先修复。

重要级别（Major）

描述：
S3 重要（Major）：，严重影响主要功能，但不会导致系统崩溃的bug，需要尽快修复 一周内修复。

示例：

• 1. 主要功能部分异常：主要功能虽可使用，但存在部分异常情况，影响业务流程的正常进行，此类问题占比约 15% 20%。例如在办公文档编辑软件测试中，约 18%的测试用例发现文档保存功能出现异常，虽不影响整体使用，但可能导致数据丢失风险。
• 2. 性能严重不达标：性能问题严重影响用户体验，当响应时间过长、吞吐量过低等性能指标严重不达标时，属于重要级别缺陷。在对某在线视频播放软件测试时，约 16%的测试场景下视频加载时间超过 10 秒，严重影响用户观看体验，此类问题占总缺陷数的 12% 18%。
• 3. 安全漏洞威胁较大：涉及用户信息泄露、数据传输加密问题等安全漏洞，对用户和企业造成较大威胁。此类安全相关缺陷约占总缺陷数的 8% 12%。如某社交软件测试中，约 10%的测试发现存在用户聊天记录传输未加密情况，可能导致信息被窃取。

处理优先级：高，需在版本发布前修复。

一般级别（Moderate）

描述：
S4 一般（Moderate）：对软件次要功能有一定影响，但不影响当前版本的发布和主要业务使用， 可不必优先修复，应在合适的时机修复（Normal）。例如一些不太常用的功能出现异常，但不影响核心业务流程。

示例：

• 1. 次要功能异常：不影响核心业务流程，但会给用户带来一定不便的次要功能问题，占总缺陷数的 20% 30%。例如在某音乐播放软件中，约 25%的测试发现歌词显示功能存在偶尔错位的情况，虽不影响音乐播放，但影响用户体验。
• 2. 界面显示问题较明显：界面布局混乱、元素显示不全、颜色搭配不合理等问题，影响软件的美观度和易用性。此类问题出现比例约为 18% 25%。如某移动应用测试中，约 22%的界面存在按钮显示不全的情况，导致用户操作困难。
• 3. 兼容性问题较突出：在主流操作系统、浏览器、设备上出现兼容性问题，影响部分用户使用。此类问题大概占总缺陷数的 15% 20%。例如某网页应用在部分主流浏览器测试中，约 18%的测试出现页面显示异常情况。

处理优先级：中等，可在后续版本中修复。

轻微级别（Minor）

描述：
S5 轻微（Minor）：对软件功能和用户体验影响较小，在时间和资源允许的情况下，如有剩余时间，可按需修复，也可在后续版本中修复。。如界面上一些不影响操作的微小显示瑕疵或是一些优先度低的优化建议/易用性缺陷。

示例：

• 1. 界面小瑕疵：如文字排版不整齐、图标显示模糊等细微问题，对用户体验影响较小，此类问题占总缺陷数的 30% 40%。在某办公软件界面测试中，约 35%的界面存在文字间距不一致等小瑕疵。
• 2. 操作提示不清晰：操作提示信息不明确、不准确，可能让用户产生疑惑，但不影响正常操作。这类问题出现概率约为 25% 35%。例如在某软件的新手引导环节，约 30%的提示信息存在表述模糊的情况。
• 3. 小功能使用不便：一些辅助功能使用起来不太方便，但不影响核心功能和主要业务流程，占总缺陷数的 20% 30%。如某软件的搜索功能，搜索结果排序规则不太合理，给用户查找信息带来一定不便。

处理优先级：低，可根据资源和时间情况安排修复。

 

S6 建议/优化（Suggestion/Enhancement）：不影响功能，但可以改进的地方，可以考虑在未来版本中优化。

描述：用户提出的改进意见或建议，不涉及现有功能的错误。

示例：增加新功能；改善用户界面设计；提高系统性能。

处理优先级：最低，可作为未来版本的功能规划参考。

 

（二）紧急程度（Urgency）及优先级定义

• P0. 立即解决（ Immediate ）：软件出现严重崩溃、数据丢失或核心功能完全不可用的情况，且每次执行相关操作时必然触发。此类缺陷直接导致软件无法正常使用，对业务流程产生严重阻碍，
  例如核心操作功能失效、软件闪退等问题。在客户交付时间临近时，客 户重点关注的软件功能模块相关缺陷或客户环境特现缺陷也应当调整为此优先级。
  
  
• P1. 高优先级（High）：缺陷影响软件主要功能的正常使用，但不会导致软件崩溃或数据丢失， 且并非每次操作都会触发。
  这类问题虽不影响软件整体运行，但会对用户的关键业务操作造成困扰。
  
  
• P2. 中优先级（Medium）：影响软件部分次要功能的正常使用或对用户体验产生一定负面影响，仅在特定条件下才会触发。
  此类缺陷不会影响用户完成核心业务，但会降低用户使用软 件的满意度，如某些特定操作路径下的功能异常或界面显示异常。
  
  
• P3. 低优先级（Low）：属于建议性的优化内容，对软件当前的功能和使用无明显影响。
  在开发资源和时间充裕的情况下进行处理，例如对软件界面布局的微调建议、操作流程的优化设想等。

（二）复现概率定义

• 必现（ 100%）：按照相同的复现条件和操作步骤，无论由谁进行测试，重复测试 5 次及以上，每次都能出现相同的缺陷结果，不存在任何偶然因素。
• 大概率复现（＞50%）：在重复测试 5 次的情况下，出现 3 - 4 次缺陷。复现条件和 操作步骤明确，但可能受到一些不稳定因素的影响，导致偶尔无法复现。
• 小概率复现（＞0%且＜50%）：重复测试 5 次，出现 1 - 2 次缺陷。此类缺陷受特 定条件的限制较大，难以稳定复现，需要仔细排查复现条件。
• 偶现（仅出现一次）：在测试过程中仅出现过一次，之后按照相同的条件和步骤再次 测试，均无法复现该缺陷。

（三）缺陷类别定义

1. 功能问题

• - 功能错误 ：软件功能的实际实现与需求规格说明书不一致，产生错误的结果。
• - 功能缺失 ：软件未实现需求规格说明书中明确要求的功能。
• - 功能异常 ：软件功能在运行过程中出现异常行为，如操作无响应、报错等。
• - 功能冗余 ：软件中存在一些不必要的功能，增加了软件的复杂度和维护成本。
• - 算法错误 ：软件所使用的算法在计算或处理数据时出现错误，导致结果不准确。
• - 逻辑错误 ：软件内部的业务逻辑出现错误，导致功能流程不符合预期。
• - 数据错误 ：数据在输入、存储、处理或输出过程中出现错误，如数据丢失、数据 不一致等。
• - 计算错误 ：涉及数值计算的功能出现计算结果错误的情况。

2. 性能问题

• - 响应时间慢 ：软件对用户操作的响应时间过长，影响用户体验和工作效率。
• - 处理速度慢 ：在执行特定任务（如标注、出图等）时，软件的处理速度明显低于 预期。
• - 资源占用率高 ：软件在运行过程中过度占用系统资源（如 CPU、内存、磁盘 I/O 等），导致系统性能下降。

3. 接口问题

• - 模块间接口问题 ：不同模块之间进行数据交互或调用时出现的接口不匹配、数据 传输错误等问题。
• - 模块内接口问题 ：模块内部各个子功能之间的接口出现异常，影响模块的正常运 行。
• - 公共数据使用问题 ：多个模块共享公共数据时，出现数据竞争、数据不一致等问 题。

4. 安全问题

• - 许可证伪造 ：软件许可证被伪造或破解，导致非法使用软件。
• - 认证和授权缺陷 ：用户认证、授权机制存在漏洞，可能导致未经授权的用户访问 受限功能或数据。
• - 数据保护缺陷 ：软件在数据存储、传输过程中，数据的保密性、完整性和可用性 未得到有效保障。
• - 代码安全缺陷 ：代码中存在安全漏洞。
• - 恶意软件缺陷 ：软件被植入恶意软件，对用户系统造成损害。
• - 版权和知识产权缺陷 ：软件存在侵犯他人版权或知识产权的问题。

5. UI 问题

• - 界面风格不统一 ：软件界面的颜色、字体、图标等风格不一致，影响整体美观度 和用户体验。
• - 界面信息不可用 ：界面上的某些信息（如按钮、菜单、提示信息等）无法正常显 示或使用。
• - 界面信息错误 ：界面上显示的信息与实际情况不符，容易误导用户。
• - 界面布局和操作不合常规 ：界面布局不符合用户操作习惯，操作流程复杂或不直 观。
• - 布局不合理 ：界面元素的布局影响用户操作效率，如重要操作按钮位置不显眼。
• - 样式不符合设计规范 ：界面元素的样式（如颜色搭配、字体大小等）未遵循设计 规范。
• - 交互反馈不明确 ：用户进行操作后，界面没有及时给予明确的反馈，使用户不清 楚操作是否成功。
• - 动画效果不流畅 ：界面中的动画效果出现卡顿、闪烁等不流畅现象。

6. 兼容性问题

• - 操作系统不兼容 ：软件在特定操作系统上无法正常运行或出现功能异常。
• - 分辨率不兼容 ：软件在不同屏幕分辨率下，界面显示异常或功能受限。
• - 文件格式不兼容 ：软件无法正确读取或处理特定格式的文件。
• - 版本兼容性问题 ：新版本软件无法使用旧版本的配置文件或项目文件。

7. 易用性问题

• - 错误提示信息不明确 ：软件出现错误时，给出的提示信息模糊不清，用户难以根据提示解决问题。
• - 操作繁琐 ：完成一项操作需要经过过多的步骤，操作流程复杂，增加用户的使用 成本。
• - 导航复杂 ：软件的导航系统不清晰，用户难以快速找到所需功能。

（四）缺陷原因定义

1. 基本场景测试不足

• 1. 测试用例未随需求变更更新 ：需求变更后，未及时更新测试用例，导致基本功能和 常用场景的测试覆盖不全面。
• 2. 需求不明致使测试用例设计不完整 ：需求不明确，使得测试用例设计不完整，无法 涵盖所有基本场景。
• 3. 测试阶段用例覆盖不足 ：测试阶段，测试用例覆盖范围不足，遗漏了部分基本场景 的测试。
• 4. 测试人员执行不规范 ：测试人员未严格按照测试用例执行测试，导致基本场景中的 缺陷未被发现。
• 5. 测试用例本身不完善 ：测试用例本身不完善，无法检测出明显的缺陷。
• 6. 需求理解不一致 ：开发与测试人员对需求的理解不一致，导致测试方向出现偏差。
• 7. 测试遗漏：测试用例设计或执行时遗漏了某些关键场景，导致缺陷未被发现。

2. 特殊场景未覆盖

• 1. 测试用例缺失特殊场景 ：测试用例未包含特殊场景的测试，使得特定场景下的缺陷 未被发现。
• 2. 软件设计考虑不周 ：软件设计阶段未充分考虑特殊情况，导致软件在特殊场景下出 现异常。
• 3. 需求验收不完整 ：验收测试阶段未覆盖特殊场景，导致缺陷遗留到发布阶段。

3. 重复问题

• 1. 问题根源定位错误 ：未准确找出问题根源，采用错误的解决方法，导致缺陷再次出 现。
• 2. 缺陷记录与跟踪缺失 ：对已发现的缺陷未进行有效记录和跟踪，遗忘问题处理情 况，造成相同问题重复出现。
• 3. 回归测试不充分 ：缺陷修复后，未进行充分的回归测试，未能及时发现修复过程中 引入的新问题或原问题未彻底解决。
• 4.修复缺陷引入 ：修复缺陷时未全面分析影响范围，导致修复过程中引入新的问题。

4. 新需求引入缺陷

• 1. 开发测试方向不一致 ：需求变更导致开发和测试方向不一致，开发人员按照新需求 开发，而测试人员仍依据旧需求进行测试。
• 2. 新需求影响现有功能 ：新需求的引入对现有功能产生影响，在集成测试过程中未充 分发现和解决问题。
• 3. 需求合理性验证不足 ：需求分析阶段未对新需求的合理性进行充分验证，导致设计 和开发出现偏差。
• 4. 设计评审不详细 ：设计阶段未进行详细的设计评审，未能及时发现新需求与现有系 统的兼容性问题。
• 5. 成员沟通不充分 ：项目成员之间沟通不充分，对新需求的理解存在偏差，导致开发 和测试工作不协调。
• 6.新功能引入：新功能开发时未充分考虑与现有系统的兼容性，导致集成时出现问题。

5. 代码修改引入缺陷

• 1. 编码规范与审查缺失 ：编码阶段缺乏代码规范和代码审查，代码质量参差不齐，容 易在修改过程中引入新的缺陷。
• 2. 回归测试不到位 ：代码修改后，未进行充分的回归测试，未全面验证修改对软件其 他功能的影响。
• 3. 版本控制与分支管理不当 ：在使用版本控制工具时，未正确进行分支管理，导致代 码合并时出现大量冲突，引发缺陷。
• 4. 开发过程中的缺陷 ：开发人员在编码过程中出现逻辑错误、语法错误或边界条件处理不当，导致缺陷。

6. 接口变更问题

• 1. 接口集成不匹配 ：多个接口或模块集成时，出现接口不匹配、数据交互错误等问 题。
• 2. 接口变更沟通不畅 ：项目成员之间沟通不充分，对接口变更的理解存在偏差，导致 相关模块的开发和集成出现问题。
• 3. 接口变更通知不及时 ：接口设计变更后，未及时通知相关模块的开发人员，使得代 码修改不及时，引发缺陷。
• 4. 接口变更管理缺失 ：缺乏接口变更的版本控制和文档更新，导致开发和测试人员对 接口的最新情况不了解。

7. 非缺陷情况

• 1. 误判正常行为或配置问题 ：误将软件的正常行为或配置问题当作缺陷报告。例如， 用户对软件默认配置不熟悉，误判为功能异常。
• 2. 需求或功能理解有误 ：测试人员或开发人员对需求或功能理解有误，导致误报缺 陷。
• 3. 测试误操作 ：测试过程中的误操作导致软件功能异常，并非软件本身存在缺陷。
• 4. 环境配置问题 ：环境配置问题导致软件出现异常，如测试环境的系统设置、CAD 平 台配置等不符合软件运行要求。
• 5. 用户操作不当 ：用户未按照正确操作流程使用软件，导致功能异常，而非软件缺陷。

二、软件缺陷度量

（一）可分析的缺陷因子

1. 缺陷严重程度

• Fatal(致命的)
  致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失等。
• Critical(严重的)
  严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。
• Major(重要的)
  不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。
• Minor(次要的)
  一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。

2. 缺陷产生模块

记录对应模块，所产生的缺陷，不同的项目<模块>的颗粒度不一样，可视情况选择。

• 按照系统子模块进行划分
  颗粒度较细，适用于小型项目，20个模块左右的适用此维度。
• 按按照大组件模块进行划分
  颗粒度适中，适用于中型项目，一个组件下面有多个模块，组件个数5+以上。
• 按照应用服务进行划分
  颗粒度较大，适合微服务类型项目，但不建议超过20+以上的分类。
• 按照前端、后端、接口服务等进行划分
  颗粒度太大，不建议使用，问题主要分为为前端、后端、对外接口。

3. 缺陷产生原因

• 需求设计问题
  模糊不清的需求、说不明白的PRD、分析不到位等
• 开发设计漏洞
  设计缺失、功能遗漏、场景未考虑、容错性不高等
• 代码编写漏洞
  纯属开发个人技能不娴熟、编码质量不高、方法函数应用补数量、调试脚本未清除等。
• 部署配置问题
  配置方案不完整、集成出错、配置缺失遗漏、受其它外在资源的影响等。

4. 缺陷产生阶段

• 需求分析：对应缺陷产生余需求分析设计阶段
• 开发设计：对应缺陷产生于开发详细设计阶段
• 开发自测：开发自测产生的缺陷
• 产品部署：安装过程中发现的缺陷
• 提测阶段：需求测试阶段
• 上线应用：线上反馈的问题，更多来源于客户

5. 缺陷类型

• 服务接口
• 数据计算
• 数据校验
• 数据显示
• 业务功能
• 业务流程
• 参数配置
• 安全问题
• 性能问题

6. 缺陷修复周期

对应不同严重程度问题的解决效率与周期。
根据大型网站的可用性指标0,999-0.999999，对于致命性问题的修复时间限定在5分钟到500分钟之间不等。
不过日常生产过程中，没有这么高的要求，但高效率的团队尽量要做到：致命性问题当天内要得到解决；严重问题两天内得到解决；

• Fatal(致命的) ：当天内修复
• Critical(严重的) ：两天修复
• Major(重要的)：一周内修复
• Minor(次要的)：根据其它问题的修复情况，如有剩余时间，可按需修复

7. 缺陷修复率

整个项目阶段所产生的缺陷的修复情况统计，可对比历史项目或版本的数据。

可统计维度：对应模块问题的修复率、对应缺陷等级问题的修复率、对应责任人产生缺陷的修复率等等。

8. 缺陷责任人

对应缺陷的责任人：可能是产品、开发、项目、测试、运维或客户自身。

9. 缺陷投入

各职能人员在缺陷上的投入，包含产品、研发、测试、运维等。

 

（二）缺陷分析维度

上述缺陷因子中，单一因子的分析，这里就不多介绍，使用中直接使用饼图分析即可。

重点从多因子组合的情况有哪些维度可以分析统计。

1、缺陷等级

 图片来源：链接

2、缺陷等级&缺陷责任人

根绝不同缺陷等级进行预设分数，结合缺陷责任人产生缺陷的数量进行分数评估。

对项目组各成员对产品质量的“贡献”，有数据上的评判--可参考。

3、缺陷等级&缺陷产生模块&缺陷修复率

根绝不同缺陷等级进行预设分数，结合对用模块产生缺陷的数量进行分数评估。

对项目各功能模块质量有一个量化的认识，便于针对性的开展质量改进与分析总结。

各模块缺陷等级分布

4、缺陷产生模块&缺陷类型

分析模块缺陷数量以及对应什么问题类型较多，便于后续版本或项目有意识规避类似问题，引起相关人员的重视。

5、缺陷等级&缺陷产生阶段

分析各阶段不同等级缺陷分布情况。

6、缺陷产生阶段&缺陷等级&缺陷投入

在缺陷产生阶段及缺陷等级的基础上延伸，可以统计各阶段在缺陷上的消耗。