软件缺陷修复流程初探

在介绍软件缺陷修复流程之前，首先需要了解软件生命周期中发现的缺陷数量的变化趋势。如下图所示，在软件生命周期中，所发现的软件缺陷数量呈现周期性变化的规律。在一个周期内，由于进行软件开发活动（需求分析、设计和编码）引入了缺陷，导致在软件测试和使用中发现的缺陷数量大幅增长，再通过缺陷修复活动可以使得发现的缺陷数量降低到一个可接受的水平。在一个缺陷增减周期内，发现的缺陷数量可能会出现多次波浪式的反复，出现这种现象是由于软件测试活动受到测试资源、测试经验和测试技能的限制，在一段时间内能够发现的缺陷数量有限，并且随着测试时间的增长可以发现更多的缺陷；而同期进行的缺陷修复活动，降低了已发现的缺陷数量。但是由于缺陷修复也是一种开发活动，它也可能引入新的缺陷。



因此，在保证软件质量的前提下，要想减少]软件测试和缺陷修复的时间，从而缩短软件开发周期，降低软件开发成本，主要从两个方面着手，一个方面是通过增加测试资源、积累测试经验和提升测试技能来增强软件测试能力，在有限的时间内发现更多的缺陷，特别是发现严重的缺陷；另一方面是增强软件缺陷的修复能力，提高修复效率，这正是本文要探讨的内容。

软件缺陷修复是一种开发活动，因此软件缺陷修复也应该遵循一定的开发流程，来保证软件缺陷修复的质量。规范的流程如下：
1）确定缺陷产生的原因。定位缺陷产生的原因，首先要能重现缺陷，这就要求缺陷描述信息完整准确清晰，以便于重现。对于随机出现的缺陷，需要耐心细致的分析蛛丝马迹，才能抓住缺陷的尾巴。在确定缺陷产生的原因后，还要分析确认软件中是否存在类似的缺陷，举一反三，这样发现了更多的缺陷，提高测试效率。
2）缺陷修复方案设计和评审。依据产生缺陷的原因，结合现有的软件结构，制定出缺陷修复方案。软件模块是相互关联的，甚至会牵一发而动全身，因此，缺陷方案设计需要通盘全面考虑，要用联系的观点分析问题，要确保修复方案所涉及的模块保持业务逻辑的正确性和一致性，避免出现“按下葫芦浮起瓢”的情况（这也是软件缺陷修复活动产生新的缺陷的主要原因）。除了依据需求文档和设计文档进行业务逻辑分析之外，还可以借助工具来分析和验证代码。例如，修改了一个函数，可以使用源代码静态分析工具查看对该函数的所有调用，确认修改后的函数是否保持了逻辑的完整性。
3）缺陷修复编码和自测。缺陷修复的自测不仅仅要测试缺陷所在的模块，还应该测试缺陷修复编码所涉及到的模块及其关联模块。
4）缺陷修复代码自查。缺陷修复代码自查是缺陷修复者检查修复代码，以期发现代码中的错误。经验表明，缺陷修复代码自查发现的错误主要是编码错误，特别是隐蔽较深的不易暴露的编码错误，以及一部分的设计错误。因此，建议无论缺陷修复的难易度如何，都要进行缺陷修复代码自查。缺陷修复代码自查需要注意三点：一是代码自查要遵循人往往只看到自己希望看到的心理学原理，以尽可能多的发现代码错误为目的，而不是以证明代码正确为目的，避免先入为主的求证心理；二是代码自查应该安排在时间充裕和精力充沛的时候，并且代码自查的时间点应该与代码改造完成间隔一段时间（建议间隔一天），这时可能会有了一些新的思路，从新的角度检查代码就可能发现更多的错误；三是代码自查的重点应该集中在代码改造的地方，因为代码修复通常是对已有的代码进行改造。可以借助文件比较工具，对改造前后的代码进行比较，标示出修改了的代码，进行重点检查，这样可以收到事半功倍的效果。
5）缺陷修复代码审查。缺陷修复代码审查的方式和方法与普通的代码审查相同，缺陷修复代码审查的注意事项与缺陷修复代码自查的相同。
6）缺陷修复验证测试。缺陷修复验证测试的范围至少应该与缺陷修复自测的范围相同。在目前采用的开发人员参与完成迭代测试和发布测试的模式下，可以由专业的软件测试工程师确定验证范围和验证方案，由软件开发工程师交叉验证修复的缺陷。需要注意的是，验证测试人员应该以尽可能多的发现缺陷的目的来进行测试，而不是以证明缺陷被正确修复的目的来完成测试，避免先入为主的求证心理，才能尽可能多的发现问题。

软件缺陷修复作为一种开发活动应该遵循规范的流程。软件缺陷修复流程可以依据实际情况进行适当裁减，对于简单的软件缺陷修复可以考虑省略缺陷修复设计方案评审和缺陷修复代码审查步骤，但是对于修复难度大、改动量大和影响范围广的软件缺陷修复，则应该采用规范的流程，确保软件缺陷修复的质量。