实践四_评估LLM对约束表达式的匹配能力 实验报告

实验要求

在实践二中，大家已经将约束表达式交由大语言模型去生成相应的测试用例输入，而在现实的工程环境 下，并没有所谓的正确代码，只有需求文本（即功能说明注释）与待测试的代码，这时我们可以将待测 试代码的约束表达式交由大语言模型，让其辅助判断是否与功能说明相符，是否有错误或遗漏。

本次实践的主要任务是模拟在没有标准代码的情况下，通过将待测试代码的约束表达式与功能说明注释 交给大语言模型，让其判断是否相符，以评估大语言模型对约束表达式的理解能力与匹配能力，从而探 索待测代码的约束表达式能否直接交给大语言模型判断对错，使得测试代码更加方便，准确。

本次实践的原材料依旧为上交实践一成果后分发到的约束，要求大家将每份代码的约束表达式与对应的 功能说明注释交给大语言模型，设计提示语，让其判断是否相符，是否有遗漏等匹配情况，记录下大语 言模型的判断结果（正确/错误/遗漏/……）并计算其判断正确率。

为了防止大语言模型的惯性回答，要求将分发得到的约束表达式进行一定的变异（比如故意改成错 的），来测试其判断正确率。也可以将功能说明进行一定的改动，使其与约束表达式不相符。对于一份 正确的约束，要求至少变异为一份错误的/遗漏的约束。 同时由于大语言模型的不稳定性，在评估判断正确率时，应用相同的提示语多次向大语言模型提问（无 上下文，开新的对话框提问才算为多次），取平均值，本次实践要求每份正确/错误的约束至少重复提 问 3 次，方可评估其判断正确率。

本次实践的成果要求为一份实验报告，包含你所设计的提示语（prompt）、每条约束表达式及判断结 果（文本形式记录）与大语言模型对话的截图（两三张即可），并记录下大语言模型对于约束表达式判 断正确率（请按照上述要求重复生成后再计算正确率）。

实践三_通过LLM生成测试用例输出 实验报告

实验任务

本次实践的主要任务是模拟在没有标准代码的情况下，通过将测试用例输入（实践二得到的）与功能说明注释交给大语言模型，让其生成一系列的测试用例输出，以评估大语言模型在解析能力与计算能力， 同时连同实践二的内容一起，探索该借助大语言模型生成完整测试用例集的方法的可行性。

而大语言模型基于测试用例输入与功能说明注释所生成的输出并不一定是正确的，因此需要检查其生成的输出（即以实践一所转换的 Cpp 代码运行测试用例输入来核对其输出是否正确），并将正确的输出作为最终的测试用例输出，也请记录大语言模型生成的测试用例输出的准确率，由于大语言模型的不稳定性，在评估准确率时，应用相同的提示语多次向大语言模型提问（无上下文，开新的对话框提问才算为多次），取平均值，本次实践要求每份代码生成测试用例输出时至少重复提问 3 次，方可评估准确率。

本次实践的成果要求与前两次实践类似，为各份代码各个输入所对应的测试用例输出（由大语言模型生成的多份 + 由程序跑出来的一份），与实验报告。实验报告需包含你所设计的提示语（prompt）与大语言模型对话的截图（两三张即可），并记录下大语言模型生成的测试用例输出的准确率（请按照上述要求重复生成后再计算准确率）。

实践二_通过约束生成测试用例输入 实验报告

实验任务

本次实践的主要任务是将实践一转换得到的 CPP 代码通过约束求解得到的约束，借助大语言模型得到相 应约束的测试用例输入，一是进一步评估大语言模型对于抽象表示的识别能力，二是探索生成测试用例 输入的新方法，在下述样例中会详细阐述。 在上交实践一成果后，助教会生成好对应代码的约束，分发给各位同学作为实践二的原始材料，不需要 大家去仔细学习约束求解的过程，大概了解约束是怎样的东西即可，想了解的同学也可以查看附录内容 自行探索。

实践一_ 利用大模型将python程序转换成C++程序 实验报告

实验任务

请大家将认领到的程序, 尝试借助大语言模型将本文件夹中的 Python 代码转换为 C++ 的代码。应该提 交: 1.原始python代码, 2.大模型输出的C++代码 (标注由哪个模型输出, 以及驱动大模型的prompt), 3.以 及手动修正后的C++代码(需要通过编译, 且可执行, 执行结果正确.)

输入的 Python 代码均由两部分组成，主要功能函数（函数名不确定，函数中含有功能说明注释）与测 试函数（ check(candidate) 函数）; 手动修正后的 C++ 代码由三部分组成，由主要功能函数（函数名 不确定，请手动将功能说明注释同样补充在其中, 粘贴过去即可）与主函数（ main 函数，用于调用主 要功能函数来进行测试，不需要包含原有 check(candidate) 中的所有用例）。

开始

在第二章中，我们讲了如何将 Hexo 生成的网页部署到 GitLab Pages，但有一个比较麻烦的地方：每次改写网页或新增 Markdown 文件后，运行 hexo deploy 部署时，都需要重新在 GitLab 项目中上传 .gitlab-ci.yml 文件以触发流水线。这无疑非常麻烦。

经过两小时的研究，我发现问题的根源在于：通过 hexo deploy 部署网站实际上是 GitHub Pages 的惯用方式，而 Hexo 官方文档中对于 GitLab Pages 的部署建议则是另一种方法。

本章将讨论部署到 GitHub Pages 和 GitLab Pages 的区别，以及当我们错误地使用 GitHub Pages 的方式部署到 GitLab Pages 时（是的，这种“粗心”就是我了），有没有快捷的补救办法来避免每次上传 .gitlab-ci.yml 文件。

说明：这里所说的部署是指改写网页或新增 Markdown 文件后，重新部署更新网站，而非从零开始的部署流程。

概要：

Maven 是 Java 项目中常用的构建工具，提供了强大的依赖管理机制。Maven 的依赖管理涵盖依赖传递、依赖范围、依赖排除等多个方面，帮助开发者轻松地管理项目中的第三方库和模块化代码。本文详细介绍了 Maven 的依赖机制及其使用场景，借助简单示例演示了 Maven 如何自动解析和解决复杂的依赖问题。

1. 前言

Maven 是 Java 项目最常用的构建工具之一，其强大的依赖管理功能使得开发者无需手动管理各种库和框架的版本、路径以及相互依赖关系。通过 pom.xml 文件，Maven 可以自动处理项目的所有依赖关系。本文将详细介绍 Maven 的依赖机制，包括依赖传递、依赖范围、依赖排除等核心概念，并配以简单的示例进行说明。

2 Maven 依赖管理机制概述

在 Maven 项目中，依赖关系通过 pom.xml 文件定义，依赖项可以从远程仓库自动下载，并放入本地仓库进行缓存。一个项目可以包含直接依赖和间接依赖（即传递依赖）。Maven 会递归解析项目所依赖的库，确保所有必需的库都被正确导入。

依赖管理的核心包括以下几个概念：

• 依赖传递性
• 依赖范围
• 依赖排除
• 版本冲突解决

《大数据理论与实践Ⅰ》实验报告①

实验编号 3

实验名称： Hive基础使用

实验内容：

第1步：启动TDH Client 。

第2步：连接Hive（Inceptor）。

《大数据理论与实践Ⅰ》实验报告①

实验编号 1

实验名称： HDFS基本操作

实验内容：

第1步：启动 TDH Client，执行 TDH Client 的 init.sh 脚本，启动 TDH Client。

围棋规则及入门

注：本篇是用组会报告时的ppt转来的，因此更像是一份ppt而不是博客。

围棋规则介绍

围棋棋盘：围棋使用 19 × 19 路棋盘，棋子落在横竖线交叉点上。

星位：九个标志点，便于定位棋子的布局。

天元：棋盘中央的圆点。

黑白交替落子

围棋由黑白双方对弈，遵循以下规则：

黑方先手：黑棋在每盘棋中率先落子。

交替落子：双方轮流下子，直至棋局结束。

实验要求

使用American Fuzzy Lop(http://lcamtuf.coredump.cx/al/)工具挖掘C/C++程序漏洞。完成实验报告。

实验过程

1. 下载并安装AFL。

   1 2 3 4

   wget wget https://lcamtuf.coredump.cx/afl/releases/afl-2.52b.tgz tar -xvzf afl-2.52b.tgz make sudo make install

   阅读全文 »