2024年软件测试最新【网安AIGC专题10(3)，2024年最新软件测试面试必备的集合源码详解

本文链接：https://blog.csdn.net/2401_84715732/article/details/138514391

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

方法： 该框架首先为三个不同角色的大型语言模型分配任务，包括分析员（analyst，负责需求分析）、程序员（coder，负责编写代码）、测试员（tester，负责检验效果），然后通过软件开发方法（SDM）规定了这些角色之间的交互方式。

结果： 通过所提出的自协作框架，相较于ChatGPT3.5，实验结果显示在四种不同基准测试中，Pass@1的性能提高了29.9%至47.1%。

在这里插入图片描述

成果和贡献

提出LLM的自协作框架，以应对“在复杂任务上生成正确的代码”的挑战

根据SDM实例化初始团队，在software development环节分配三个角色负责不同stage

由GPT3.5组成的自协作虚拟团队在各种代码生成的基准测试上，性能超过了GPT-4

在现实场景下，自协作模式有效完成复杂任务

自协作框架原理

1、DOL任务分配

根据任务分配角色指令，然后将对应的任务传递给角色
在这里插入图片描述

2、共享黑板协作

不同角色间，将输出的信息共享

在这里插入图片描述

3、Instance实例化

1）采用SDM中的经典瀑布模型 [Petersen et al., 2009]，简化为三个阶段：分析、编码、测试。
2）分析员：生成一个高维的计划，着重指导程序员。程序员：根据分析员的计划写代码；根据测试员的测试报告修改代码。测试员：从功能性、可读性和可维护性评判程序员的代码
3）终止条件：达到最大交互次数n或者测试员报告没有错误

在这里插入图片描述

案例说明

简单任务：基本操作

1）分析员：分解任务
+制定high-level计划
2）程序员：按照计划生成对应代码
3）测试员：检验代码的功能性和边缘测试情况，反馈错误让程序员修改

在这里插入图片描述

复杂任务：游戏开发

未展示训练过程，仅说明结果
满足所有游戏逻辑，保障了精确的角色控制，设置正确的碰撞检测，必要的游戏资产加载和适当的图像缩放。此外，注意到了没有直接规定但是符合常识的游戏逻辑，比如炸弹掉落至底部后会被重置位置
单个LLM只能生成脚本的粗略草稿
在这里插入图片描述

实验

设置

在这里插入图片描述

数据集

四个基准测试（数据集）

1）MBPP(sanitized version) [Austin et al., 2021]

427个Python编程任务，属于调用标准库功能函数的基础代码生成任务
包含：自然语言描述+编程计划提示+3个测试用例

2）HumanEval [Chen et al., 2021]

164个编程任务
包含：自然语言描述+函数签名+函数主体+单元测试

3）MBPP-ET

4）HumanEval-ET

比原本的数据集多100余个测试，包含边缘案例

实验结果1：与其他代码生成方法比较

在这里插入图片描述

输入：自然语言+函数签名+公共的测试用例
分析：相较于GPT-3.5增长了29.9%-34.6%；在后两个数据集上表现更佳，证明自协作代码生成的可靠性。
原因可能为：成员多可以考虑更多边界条件和处理常见bug。

实验结果2：评估不同角色的影响

在这里插入图片描述

输入：自然语言
分析：在HumanEval基准测试上三角色团队效果最好，在MBPP基准测试上coder-tester团队表现最好，
原因是：MBPP的两个数据集任务较简单，不需要计划

实验结果3：评估有无角色的影响

在这里插入图片描述
few-shot prompting：每个阶段给予一些案例提示
zero-shot：给予指令删除角色，不给予提示
分析：角色指令的特定的上下文语境限制了LLM的生成空间，令其在场景约束下进行推理，生成与命令一致的结果。few-shot比zero-shot表现差的原因是有限的例子提示不能完全反映目标反而让LLM的理解产生偏差，此外提示太长阻碍了LLM的理解。