转载一篇我发表在安全学术圈的论文阅读笔记。
继续分享基于LLM的自动bug修复，题目为："STEAM: Simulating the Interactive Behavior of Programmers for Automatic Bug Fixing"。
最近，研究人员已经证明了当任务被分解成一组具有精确查询的模块化单元时，LLM在生成有用结果方面的显著能力[1]，[2]。Bug修复是一项多方面的任务，其中每个发现的bug在被有效地解决之前通常都要经历一个特定而复杂的过程。然而，现有的基于LLM的错误修复方法通常将任务视为单阶段过程，忽略了程序员在解决软件错误过程中的交互和协作特性。如图1所示，STEAM旨在模仿程序员（即：测试人员、开发人员和评审人员）在bug的整个生命周期中表现出的协作解决问题的能力。有效的缺陷管理过程对于成功修复缺陷是重要的[3]。作者将任务分解为四个不同的阶段：缺陷报告、缺陷诊断、补丁生成和补丁验证。具体来说，有效的bug修复方案最初依赖于测试人员对bug的全面理解，从而形成详细的bug报告。该报告为开发人员成功修复bug提供了重要信息。在该框架中，开发人员有双重责任。首先，开发人员通过查阅历史bug语料库和进行自调试来参与诊断过程。其次，开发人员在前面阶段获得的信息的指导下生成候选补丁。由于无法保证第一次生成的候选补丁的正确性，测试人员参与STEAM变得至关重要。测试人员提供评审反馈，并在整个工作流程中与开发人员合作，在确保生成补丁的正确性。
STEAM的框架如图2所示，由三个ChatGPT代理（即：测试人员、开发人员和评审人员）组成，每个代理负责缺陷管理过程中的特定阶段（即：缺陷报告、缺陷分析、补丁生成和补丁验证）。
（1）Bug报告（Bug Reporting）：
在初始阶段，测试人员在发现源代码中的错误后，提交详细的报告，阐明错误的性质。实际上，bug报告在bug修复中起着至关重要的作用，因为它们为开发人员提供了bug的基本信息。这些具体的细节极大地帮助了开发人员解决bug [4]，[5]。为了模拟测试人员的行为，STEAM被设计为生成一个初始的bug报告，概述bug代码的潜在原因，然后分配给开发人员进行进一步的处理。
（2）Bug分析（Bug Diagnosis）：
从测试人员那里收到bug报告后，开发人员利用报告中提供的可用信息开始分析bug。实际上，当分配一个新发现的bug时，开发人员首先查阅历史bug语料库来提取bug修复模式，这些模式揭示了类似问题的原因和解决方案。这种挖掘过程有助于获得有价值的知识，这些知识与bug发生的原因和相应的修复方法有关[6]，[7]。此外，开发人员参与调试实践，逐行分析源代码，并用自然语言表达他们的发现。这种自我指导的方法提高了bug修复的效率，而不依赖于外部专家的指导[8]，[9]。为了模仿开发人员的分析行为，STEAM通过检索相关的bug修复示例来进行模式总结。然后，STEAM使用rubber duck（小黄鸭调试法）调试技术为源代码提供解释。这两种形式的指导有助于开发人员生成正确的补丁。
（3）补丁生成（Patch Generation）：
一旦确定了bug的根本原因，开发人员就可以开始创建补丁来修复所发现的bug。在以前的研究中，LLM被指示根据给定的错误代码直接生成补丁。然而，修复bug是一项复杂的任务，从头开始生成正确的补丁是一项挑战。在bug分析过程的指导下，开发人员利用bug修复模式和代码解释作为提示来生成候选补丁，该补丁随后被提交给评审人员进行进一步验证。
（4）补丁验证（Patch Cerification）：
对于复杂的软件错误，在一次尝试（也就是一次补丁生成流程）中生成正确的补丁是具有挑战性的。因此，补丁的评审过程作为软件同行评审中的一个关键活动具有相当重要的意义。当看到开发人员生成的候选补丁时，评审人员需要评估它解决所发现bug的有效性。在评审者没有通过候选补丁的情况下，表明发现的bug没有被成功修复，开发人员需要做进一步的修改。一旦评审者通过了候选补丁，发现的bug就被认为已经解决了。为了模拟审查者的行为，STEAM首先确定候选补丁是否能够作为bug代码的正确解决方案。如果候选补丁不符合要求的标准，STEAM会向开发人员提供评审反馈，以便补丁重新生成。这个补丁验证过程可能在审查者和开发者之间重复多次，直到候选补丁被认为是正确的。
接下来将对三个ChatGPT代理进行具体解读。
（1）测试人员
图3展示了在bug报告阶段模拟测试人员行为时的提示和相应的输出。系统指令（System Instruction）指定了ChatGPT代理在其响应中采用的角色。测试人员的主要目标是根据bug位置（即：bug行）报告给定bug方法的根本成因。为了获得高度相关的响应，Input Content向ChatGPT代理提供关键的细节和上下文。此外，使用分隔符（用橙色粗体突出显示）来清楚地指示Input Content的不同部分。在所提供的提示之后，测试人员产生一个bug报告，该报告描述了错误的性质及其对给定错误方法的影响。这些信息将被用来帮助开发人员解决bug。
（2）开发人员
在STEAM中，开发人员的职责主要包括四个方面：1）通过分析从历史代码语料库中检索出的类似示例来总结bug修复模式；2）使用小黄鸭调试法逐行解释给定的错误代码；3）使用来自bug报告的信息和从bug分析过程获得的指导来生成初始候选补丁；4）通过结合从审查者接收的反馈来改进候选补丁。
图4展示了示例提示以及在bug分析阶段模拟开发人员行为时获得的相应输出。
a. 模式总结
如图4的左侧所示，该过程的初始步骤包括基于给定的bug方法和bug行从历史代码语料库中检索相似的程序。为了实现这一点，STEAM利用BM25评分作为检索指标。BM25的功能是作为一个词袋检索方法，用于估计两个句子之间的词汇级相似性。BM25分数越高表明句子之间的相似性越大。具体来说，STEAM选择了前3个示例（包括bug方法和成对的buggy和fixed行），作为从历史语料库中检索的结果。基于选定的示例，开发人员总结了bug修复模式，提供了对类似问题的根本原因和解决方案的见解。
b. 小黄鸭调试法
如图4的右侧所示，这个调试过程模拟了人类程序员的普遍做法，他们用自然语言一行一行地解释代码。因此，开发人员通过描述代码实现来提供代码解释，这提高了调试效率，而不需要额外的指导（例如单元测试）。
如图5所示，开发人员在这一阶段的目标（在System Instruction中声明）是通过利用Input Content中列举的反馈产生单行补丁来修复有问题的行。STEAM为开发人员提供了一个引导性的bug报告和分析过程，使开发人员能够通过整合来自bug报告、bug修复模式和代码解释的信息来生成初始候选补丁。随后，生成的候选补片经过评审人员的进一步验证。
（3）评审人员
如图6中的System Instruction所描述的，评审人员获得由开发人员提供的有bug的方法和相关联的修复过程。在这个阶段，评审人员的目标是推断候选补丁的正确性，并向开发人员传递反馈消息，以便于后续的交互步骤。图6概述了在补丁验证阶段评审人员和开发人员之间的示例性交互过程。如果评审人员确定修复的行对于有bug的方法来说是不正确的补丁，则开发人员需要在考虑评审反馈的同时生成新的单行补丁。当审查者确认修复的行的正确性时，或者当达到最大允许验证轮次时，交互过程终止。
参考文献
[1] Wei J, Wang X, Schuurmans D, et al. Chain-of-thought prompting elicits reasoning in large language models[J]. Advances in Neural Information Processing Systems, 2022, 35: 24824-24837.
[2] Merow C, Serra-Diaz J M, Enquist B J, et al. AI chatbots can boost scientific coding[J]. Nature Ecology & Evolution, 2023: 1-3.
[3] Ohira M, Hassan A E, Osawa N, et al. The impact of bug management patterns on bug fixing: A case study of eclipse projects[C]//2012 28th IEEE International Conference on Software Maintenance (ICSM). IEEE, 2012: 264-273.
[4] Bettenburg N, Just S, Schröter A, et al. What makes a good bug report?[C]//Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering. 2008: 308-318.
[5] Zou W, Lo D, Chen Z, et al. How practitioners perceive automated bug report management techniques[J]. IEEE Transactions on Software Engineering, 2018, 46(8): 836-862.
[6] Osman H, Lungu M, Nierstrasz O. Mining frequent bug-fix code changes[C]//2014 Software Evolution Week-IEEE Conference on Software Maintenance, Reengineering, and Reverse Engineering (CSMR-WCRE). IEEE, 2014: 343-347.
[7] Tan S H, Li Z, Yan L. CrossFix: Collaborative bug fixing by recommending similar bugs[J]. arXiv preprint arXiv:2103.13453, 2021.
[8] Chen X, Lin M, Schärli N, et al. Teaching large language models to self-debug[J]. arXiv preprint arXiv:2304.05128, 2023.
[9] Paul R, Hossain M M, Hasan M, et al. Automated Program Repair Based on Code Review: How do Pre-trained Transformer Models Perform?[J]. arXiv preprint arXiv:2304.07840, 2023.
安全学术圈招募队友-ing
有兴趣加入学术圈的请联系 secdr#qq.com
