测试的基本目的之一，是对被测对象进行质量评估。换言之，是要提供关于被测对象质量的“确定性”。因此，我们很忌讳在测试设计中引入“不确定性”，比如采用不可靠的测试工具、自动化测试代码逻辑复杂易错、测试选择假设过于主观等等。

近期，我们看到了很多利用大模型辅助测试的研究和实践。尽管大模型在提升测试效率、提高测试用例可读性等方面展现出不错的潜力，但其决策结果所固有的不可解释性，对测试所期求的“确定性”产生了直接冲击。如果我们将测试设计的底座构筑在这种工具上，质量评估结论的可信性问题就会变得非常突出。

那么，大模型辅助测试的正确打开方式究竟是什么呢？目前来看，“利用大模型的生成能力、遵循用例多样化的设计路线、拓展测试集的缺陷检出能力”，似乎是一个相对靠谱的答案。

在这方面，Deng等人利用大模型开展模糊测试的一项工作[1]，给我们提供了一个颇具参考价值的示例。我们具体来看看。

假设被测对象是一组API接口，那么测试用例的表现形式，就是调用这些API的测试代码。通过多样化的测试代码，我们能够验证这些API在各种调用行为中的表现是否符合预期，并找到可能存在的缺陷。

我们知道，为了实现用例的多样化，一种常用的手段是模糊测试方法。然而，对于代码形式的用例而言，如果直接对种子代码进行随机变异，大概率将导致编译错误或运行时错误，因此传统的模糊测试手段并不适用。这时，具备代码生成能力的大模型就派上用场了。

在代码生成领域，常见的大模型有两类：生成式大模型仅根据上文（如自然语言描述或前序代码）生成完整的代码片段；填充式大模型则可以在包含占位符的代码片段中进行填空。综合利用这两类大模型，我们就能够完成模糊测试中种子生成和变异的任务：首先用Codex这样的生成式模型，生成调用目标API的种子测试代码，继而用INCODER这样的填充式模型，对种子测试代码进行演化式的变异，得到更多模糊测试代码。最后，分别在CPU和GPU服务器上执行模糊测试代码，采用差分测试策略探查缺陷。整个过程如下图所示：

以下算法描述了演化式的模糊测试用例生成过程（上图中间部分）：

该算法中包含如下要点：

1. 在初始化部分，使用Codex生成的种子测试代码Seeds对种子银行进行初始化。种子银行中维护着目前为止生成的所有目标API测试代码。另外，需要对各个变异操作符的概率分布进行初始化，这个概率分布将在后续的迭代中不断更新，用以选取最合适的变异操作符；

2. 在演化迭代中，首先从种子银行中选取一个种子，选取策略是先选出适应值最高的N个种子，然后采用softmax函数对这N个种子的适应值进行归一化，籍此评估每个种子最终被选中的概率，概率最高的种子中选；

3. 根据变异操作符的概率分布，选取概率最高的变异操作符；

4. 使用选定的变异操作符对种子测试代码进行变异，也就是将种子测试代码中的一个或多个位置（譬如API参数、方法名、调用前序代码、调用后序代码等）替换为<span>占位符。不同的替换位置，对应着不同类型的变异操作符：

   

5. 将变异后的代码提交给INCODER模型，要求其对占位符位置进行填空。INCODER模型可能会给出多种不同的填空结果。如果填空之后得到的代码能够编译通过，那就是一个有效的模糊测试用例，否则就是无效的。之前我们对种子进行变异的目的，就是为了得到多样化的、有效的模糊测试用例。而对不同的待测API来说，适用的变异操作也是不同的。能够通过填空生成的有效代码数量越多，说明当前选定的变异操作符越适用。因此，我们可以用有效和无效用例的数量，对变异操作符的概率分布进行动态更新。这种思路实际上来自多臂老虎机（Multi-Armed Bandit, MAB）算法；

6. 每一个填空生成的有效模糊测试用例，都将进入种子银行，成为下个迭代中的备选种子。在此之前，我们需要先评估这一段测试代码的数据流图最大深度D，并统计其中调用各种不同API的次数U-R（R是重复调用的次数），由此算出该用例的适应值得分。通常认为，那些涉及一长串不同API调用的用例，能够更充分地覆盖API之间的交互事件，因此也就更有可能发现API的潜在缺陷。适应值函数FitnessFunction(C) = D + U - R就是根据这一思路来定义的。

参考文献：

[1] Deng Y, Xia C S, Peng H, et al. Large language models are zero-shot fuzzers: Fuzzing deep-learning libraries via large language models[C]//Proceedings of the 32nd ACM SIGSOFT international symposium on software testing and analysis. 2023: 423-435.