基于GJB 5000B 的软件缺陷管理

0 引言

GJB 5000B—2021 《军用软件能力成熟度模型》 （以下简称GJB 5000B） 标准于2022年正式发布实施，标准规定了军用软件能力成熟度的模型，并规定了军用软件论证、研制、试验和维护活动中的相关实践，是目前军用软件能力成熟度评价和过程改进的事实依据 [1]。军用软件能力成熟度模型是军用软件全生命周期过程技术和管理zuijia实践的集合，能够指导组织实施精细化过程管理，不断改进组织过程，提高质量和过程绩效 [2]。验证与确认属于GJB 5000B工程类实践域，标准规定了该实践域在规范级 （即二级） 和全面级 （即三级） 的目标、实践，以及活动和工作产品实例 [1]。本文依据GJB 5000B对验证与确认过程域要求，结合软件测试实践经验，对软件缺陷生命周期管理，以及过程和方法的适当使用进行研究，帮助测试经理和其他项目干系人深入了解缺陷在整个开发生命周期中的状态，通过持续收集和分析数据，帮助识别测试和开发过程的改进机会。

1 缺陷工作流程和状态

实施GJB 5000B的组织大部分使用缺陷管理工具对缺陷报告实施管理。在整个缺陷生命周期中缺陷会历经一系列状态。大多数状态下，项目中某一成员或某角色作为缺陷报告责任人，负责执行某个任务，任务完成时缺陷进入下一状态，即分配给下一个责任人，当缺陷报告进入被关闭（通常意味着该报告指出的缺陷已被修复，修复的结果已经通过确认测试验证）、被取消 （通常意味着该缺陷报告无效）、无法重现 （通常意味着未能重复观察到失效现象） 和延期 （通常意味着该异常与一个实际存在的缺陷相关，但该缺陷在项目中无法得到修复） 等Zui终状态时，将不再需要进一步处理，也不再拥有责任人。

对于测试中发现的缺陷，以下3种状态需要测试团队采取相应行动：

a） 初始/打开/新状态

该状态下，一名或者多名测试人员为负责解决缺陷的人员收集必要信息，重现异常。

b） 退回/拒绝/澄清状态

该状态下，报告接收人拒绝接收报告或者向测试人员询问进一步的信息，该状态表明初始状态的信息收集过程或者测试本身存在不足，测试人员必须提供补充信息，或确认该报告应该被拒绝。如果出现过高的缺陷报告退回率、该状态发生聚集现象，组织应考虑加强测试过程监督 [3]。

c） 确认/验证测试状态

该状态下，测试人员会运行确认测试 （一般按照缺陷报告中重现失效的步骤），判断缺陷是否得到了修复，问题是否已解决。如果确认测试表明缺陷已被修复，测试人员应关闭缺陷报告。如果确认测试显示缺陷没有被修复，测试人员应该再次打开缺陷报告，缺陷负责人继续修复缺陷。

2 无效缺陷的管理

某些情况下，失效状况的发生并非由缺陷引发，而是因为测试环境、测试数据和测试件的其他要素，甚至测试人员自己的误解。如果测试人员建立缺陷报告后发现其内容与被测试工作产品缺陷无关，则属于误报。这类报告一般应被取消或者作为无效缺陷报告被关闭。另外，有时候测试人员发现的多个表面看来完全无关的故障现象、或是在不同测试点发现的问题，有可能是由同一缺陷导致，如果事后发现两个或以上缺陷报告是由相同的根本原因引起的，通常只保留其中一个缺陷报告，其他的可视为重复缺陷报告被关闭。

尽管无效缺陷报告和重复缺陷报告代表了一定程度的低效率，但一定数量的此类报告是不可避免的，组织应予以接受 [4]。倘若组织试图消除所有的无效和重复缺陷报告，测试人员往往会由于担心出错而不敢填写缺陷报告，从而使得测试团队整体的缺陷发现有效性下降，导致漏报数量增加，从而与组织实施GJB 5000B验证与确认过程域的关键目标相背离。

3 跨职能缺陷管理

测试组织和测试经理是整个缺陷管理过程和缺陷管理工具的所有者，除此之外，还会有跨职能的小组负责管理整个项目所报告的缺陷。一个缺陷管理团队可以包括以下几个角色。

a） 测试人员

测试人员是缺陷管理的主要参与者，他们负责发现、报告、验证和关闭缺陷，以及提供缺陷的相关信息和建议。测试人员应该具备良好的测试技能、沟通技能、分析技能和解决问题的能力，以及对软件的功能、性能、安全和兼容性等方面的充分了解 [4]。

b） 开发人员

开发人员是缺陷管理的重要参与者，他们负责确认、解决和验证缺陷，以及提供缺陷的相关信息和建议。开发人员应该具备良好的开发技能、沟通技能、分析技能和解决问题的能力，以及对软件的架构、设计、代码和测试等方面的充分了解。

c） 需求分析人员

需求分析人员是缺陷管理的辅助参与者，他们负责提供和维护软件的需求文档，以及参与缺陷的确认和解决，特别是涉及到需求变更的缺陷。需求分析人员应该具备良好的需求分析技能、沟通技能、文档编写技能和协调技能，以及对软件的业务、用户和场景等方面的充分了解。

d） 设计人员

设计人员是缺陷管理的辅助参与者，他们负责提供和维护软件的设计文档，以及参与缺陷特别是设计缺陷的确认和解决。设计人员应该具备良好的设计技能、沟通技能、文档编写技能和协调技能，以及对软件的结构、模块、接口和算法等方面的充分了解。

e） 客户代表

客户代表是缺陷管理的辅助参与者，他们负责提供和维护软件的用户需求和期望，以及参与缺陷的确认和解决，特别是涉及到用户满意度的缺陷。客户代表应该具备良好的沟通技能、协调技能和决策技能，以及对软件的价值、目标和风险等方面的充分了解。

当测试人员发现缺陷并记录在缺陷管理工具中后，缺陷管理委员会需要判断缺陷的有效性和是否要修复或延期。在做决策时缺陷管理委员应当综合考虑修复缺陷与否的效益、风险和成本。若决定修复缺陷，还需确定修复该缺陷的优先级，必要时，测试团队可对缺陷重要性提出建议并提供相应的有效客观信息。缺陷跟踪工具不应替代沟通交流，缺陷管理委员会的会议也不应替代缺陷跟踪工具。组织要实现有效且高效的缺陷管理，充分的沟通交流、必要的工具支持、定义明确的缺陷生命周期和缺陷管理委员会的充分参与都是bukehuoque的。

4 缺陷报告

当识别出缺陷或者观察到失效时，相关人员应该收集相应数据并记录在缺陷报告中。收集的缺陷数据包括缺陷发现人、缺陷等级、测试类型、测试追踪、问题描述、重现失效的步骤、实际结果和预期结果等，具体需要收集哪些信息视测试依据的标准而定 [3，5]。另外，测试人员在记录信息时，必须确保信息完整、简明、准确、客观、相关、及时。即便个别数据不符合要求带来的问题通过人工干预或者面对面交流能够克服，但Zui终还是会给项目状态、测试进度和过程能力的正确评估埋下隐患。

在实施GJB 5000B的组织中，应鼓励缺陷生命周期涉及的相关人员遵循以下几个原则。

a） 及时性

及时地报告、分配、确认、解决、验证和关闭缺陷，以及及时地通知、反馈、咨询和协商缺陷的相关事宜，避免缺陷的延误和遗漏。

b） 准确性

准确地描述、记录、分析、解决和验证缺陷，以及准确地提供、获取、核实和更新缺陷的相关信息，避免缺陷的误报和漏报。

c） 完整性

完整地涵盖、考虑、评估和处理缺陷的所有方面，如缺陷的原因、影响、风险、解决方案和验证方法等，以及完整地保存、归档、查询和分析缺陷的所有信息，避免缺陷的遗漏和重复。

d） 清晰性

清晰地表达、理解、解释和说明缺陷的相关内容，如缺陷的定义、分类、优先级、状态、责任人、报告方式、跟踪方式、解决方式和验证方式等，以及清晰地展示、查看、比较和总结缺陷的相关数据，如缺陷的数量、密度、发现率、解决率和遗留率等，避免缺陷的模糊和混乱。

e） 诚信性

诚信地对待、承认、接受和改正缺陷，以及诚信地沟通、协作、支持和尊重缺陷的相关人员，避免缺陷的隐瞒和推诿 [6]。

5 过程改进

缺陷报告对于组织评估测试能力和实施过程改进具有重要意义，组织通过缺陷数据的采集、统计和分析，多维度评估软件开发过程、测试过程的有效性和效率 [7-8]。

a） 根据缺陷引入的阶段、识别的阶段和消除的阶段的信息，或者按阶段来划分，评估阶段缺陷密度，并提出改善各阶段缺陷发现有效性的方案。

b） 根据缺陷引入阶段的信息，对引入缺陷Zui多的阶段进行帕累托图 （Pareto） 分析，使改进更具针对性，减少缺陷总数。

c） 根据缺陷根本原因信息确定缺陷引入的潜在原因，以减少缺陷总数，支持过程改进。

d） 根据缺陷引入、识别和消除的信息进行质量成本分析，降低与缺陷相关的成本。

e） 根据缺陷组件信息进行缺陷聚集分析，以便更好地理解技术风险和重新设计问题较多的组件。

6 结束语

，在软件开发生命周期中任何时间点和工作产品中都可能引入缺陷。因此，软件开发周期的每个阶段都要包括发现和移除潜在缺陷的活动。越早识别并移除缺陷，系统整体的质量成本越低，在缺陷引入阶段解决该缺陷，是质量成本Zui低的做法 [9-10]。对于实施GJB 5000B的组织而言，科学管理软件缺陷、充分利用缺陷数据可以帮助组织有效评估软件开发和测试过程，实现持续改进目标。