江苏省建设档案网站,html怎么学,网站图片模板源码,简要叙述如何规划建设一个企业网站1. 为什么你需要Defects4j#xff1f;从零开始的认知 如果你是做软件测试、程序分析或者软件工程研究的#xff0c;尤其是对自动化缺陷定位、测试用例生成或者程序修复感兴趣#xff0c;那你肯定绕不开一个东西#xff1a;真实可靠的缺陷数据集。这玩意儿就像练武的木人桩 print \DBI module is ready!\n\;如果没有任何错误输出就说明模块加载成功。如果很不幸你因为系统源或其他罕见原因apt确实装不上libdbi-perl那才考虑使用Conda作为最后手段。但务必先进入一个Conda环境再安装conda install -c conda-forge perl-dbi安装后你可能需要确认当前终端会话中perl命令指向的是Conda环境下的版本。不过我还是强烈推荐优先使用系统apt安装的方式最干净也最不容易出后续问题。3. 步步为营Defects4j的安装与初始化好了依赖问题解决我们可以正式开始安装Defects4j本体了。这个过程分为三步克隆、初始化、配置环境变量。3.1 克隆仓库与初始化第一步找一个你喜欢的目录比如你的家目录~或者专门的项目目录~/projects把Defects4j的官方仓库克隆下来。git clone https://github.com/rjust/defects4j.git克隆完成后进入目录运行初始化脚本。这一步非常关键也非常耗时。因为Defects4j为了保持Git仓库的精简并没有把所有缺陷项目的完整代码库和外部依赖jar包都放进去。init.sh这个脚本的任务就是去下载这些缺失的“大块头”数据。cd defects4j ./init.sh你需要耐心等待。脚本会依次下载像 Commons Lang、Math、Chart 等项目的多个版本仓库以及它们所需的各种第三方库。网络状况好的话可能十几二十分钟慢的话可能需要更久。期间保持网络连接稳定即可。这是“一次性”的痛苦初始化完成后以后就不用再做了。3.2 配置环境变量让命令随处可执行初始化完成后Defects4j的所有可执行文件都放在defects4j/framework/bin/目录下。为了方便我们在任何目录下都能直接使用defects4j这个命令需要把它加入到系统的PATH环境变量中。你可以选择只对当前终端会话生效临时export PATH$PATH:/path/to/your/defects4j/framework/bin请务必将/path/to/your替换成你实际的路径例如我克隆在家目录那就是~/defects4j/framework/bin。更推荐的做法是把这行命令添加到你的shell配置文件中这样每次打开终端都自动生效。如果你用的是bash默认编辑~/.bashrc文件echo export PATH$PATH:~/defects4j/framework/bin ~/.bashrc source ~/.bashrc如果你用的是zsh则编辑~/.zshrc。添加完成后执行source命令让配置立即生效。现在你可以在任何地方输入defects4j命令了。马上我们来验证一下安装是否真的成功了。3.3 验证安装第一次亲密接触让我们运行Defects4j最常用的一个信息查询命令来测试整个环境是否工作正常defects4j info -p Lang这个命令的意思是查询项目Lang即 Apache Commons Lang的基本信息。如果一切顺利你会在终端看到一大段输出内容包括项目简介、可用的缺陷ID列表、每个缺陷的简要说明等。这证明从Perl脚本执行到项目数据加载整个链路都通了。如果这一步你看到了之前提到的Perl DBI错误请返回3.2节检查模块安装。如果看到“command not found”请检查环境变量PATH是否设置正确。如果输出正常那么恭喜你Defects4j已经成功在你的系统上安家落户了4. 初窥门径Defects4j核心使用命令详解安装只是开始会用才是关键。Defects4j提供了一套命令行工具让你能够像操作积木一样灵活地检出、编译、测试任何一个缺陷版本。下面我挑最核心、最常用的几个命令结合实例给你讲明白。4.1 信息查询了解你的“故障博物馆”在动手操作具体缺陷前先看看这个博物馆有哪些“展品”。defects4j info就是你的导览手册。查看所有支持的项目虽然没直接提供defects4j list-projects这样的命令但你可以通过查询已知项目来测试。常见的项目有LangMathChartTimeClosure等。查看某个项目的所有缺陷defects4j info -p Lang输出会列出Lang项目下所有可用的缺陷编号如1, 2, 3...以及每个缺陷的简要描述。这是你选择实验对象的第一步。查看某个特定缺陷的详细信息defects4j info -p Lang -b 1这会展示Lang项目第1号缺陷的详细信息包括触发它的测试类和方法、修复补丁信息等。在做深入分析时非常有用。4.2 检出缺陷版本创建你的实验沙盒这是最核心的操作。我们以Lang项目的第1个缺陷为例你需要一个干净的工作目录来存放这个有bug的代码版本。defects4j checkout -p Lang -v 1b -w /tmp/lang_1_buggy我来拆解这个命令-p Lang指定项目是 Commons Lang。-v 1b指定版本。这里的1b代表第1个缺陷的“有bug”版本b for buggy。对应的还有1f代表修复后的版本f for fixed。-w /tmp/lang_1_buggy指定工作目录。Defects4j会把检出代码、依赖库、构建脚本等所有必要文件都准备好放到这个目录下。你可以把/tmp/lang_1_buggy换成任何你有写权限的路径比如~/experiments/lang_bug_1。执行成功后你就拥有了一个完整的、可独立构建和测试的Java项目而且它包含一个已知的真实缺陷。4.3 编译与测试运行并观察故障进入你刚检出的工作目录进行编译和测试。cd /tmp/lang_1_buggy defects4j compile defects4j testdefects4j compile这个命令会调用项目本身的构建系统可能是Ant或Maven来编译源代码和测试代码。它帮你屏蔽了不同项目构建方式的差异非常方便。defects4j test运行该项目的测试套件。对于有bug的版本1b运行测试预期会失败并且失败信息中会明确指出是哪个些测试用例失败了。这些失败的测试就是Defects4j预先标记好的“触发测试”trigger tests正是它们暴露了这个缺陷。如果你检出的修复后版本-v 1f那么defects4j test的结果应该是全部通过。这一正一反的对比正是缺陷定位和程序修复研究的基础。4.4 理解目录结构数据是如何组织的当你多次使用Defects4j后可能会好奇它内部是怎么管理这些数据的。我们回到克隆的defects4j根目录看看defects4j/ ├── project_repos/ # 各个缺陷项目的完整版本控制仓库git repo ├── major/ # Major变异测试框架 ├── framework/ # Defects4j框架的核心 │ ├── bin/ # 命令行工具我们用的defects4j命令就在这里 │ ├── core/ # 核心Perl模块 │ ├── lib/ # 依赖的Java库 │ ├── util/ # 工具脚本 │ └── projects/ # **重点**每个项目的元数据 │ ├── Lang/ │ ├── Math/ │ └── ... └── ...对于研究者而言framework/projects/下的内容尤其值得关注。以Lang/1/为例里面通常包含trigger_tests一个文件列出了触发此缺陷的所有测试方法如org.apache.commons.lang3.math.NumberUtilsTest::testCreateNumber。modified_classes一个文件记录了修复此缺陷时需要修改的源代码类如org.apache.commons.lang3.math.NumberUtils。loaded_classes或relevant_classes修复缺陷时JVM需要加载的所有相关类。relevant_tests所有执行时会加载modified_classes的测试类。这比trigger_tests范围更广。patches/src.patch标准的diff格式补丁文件清晰地展示了如何将buggy版本代码修改为fixed版本。-开头的行表示在修复版本中删除即buggy版本中多余的错误代码开头的行表示在修复版本中添加即正确的代码。理解这些文件你就能手动复现缺陷修复过程也能更精准地设计你的实验例如只关注与缺陷相关的类和测试而不是整个庞大的项目。5. 进阶实战与疑难排坑掌握了基本命令你已经可以开展大部分工作了。但实际研究中你可能会遇到一些更具体的情况。这里分享几个我遇到过的场景和解决办法。5.1 在IDE中运行测试命令行defects4j test很方便但有时我们想在IntelliJ IDEA或Eclipse里调试测试代码更直观地跟踪程序状态。这需要把检出的项目导入IDE。以IDEA为例检出项目后其目录本身通常就是一个完整的Maven或Ant项目。你可以直接用IDEA打开/tmp/lang_1_buggy目录。关键点在于编译环境JDK版本不同缺陷项目可能依赖不同版本的Java。Lang、Math等老项目可能兼容Java 8而Closure可能需要Java 11。在IDEA的Project Structure中设置正确的Project SDK。一般Java 8或11的兼容性较好。Maven版本如果项目是Maven构建的大部分是我亲测Maven 3.8.1是工作良好的。曾经有同学用Maven 3.6遇到依赖解析问题升级到3.8.1后解决。你可以在IDEA的Maven设置中指定本地Maven路径和版本。在IDE中运行trigger_tests里指定的测试方法你应该能复现测试失败。对照src.patch文件你可以在IDE里直接修改源代码验证修复后测试是否通过。这种交互式体验对理解缺陷本质非常有帮助。5.2 获取修复版本代码虽然可以用defects4j checkout -p Lang -v 1f直接检出修复版本但有时我们想基于buggy版本手动修复再验证。这时src.patch文件就是你的“修复说明书”。你可以用文本编辑器打开patches/src.patch它会精确显示需要修改的文件、行号以及具体的代码变更。例如--- a/src/main/java/org/apache/commons/lang3/math/NumberUtils.java b/src/main/java/org/apache/commons/lang3/math/NumberUtils.java -123,7 123,7 // 省略上下文... - if (str null) { if (StringUtils.isEmpty(str)) { return null; }解读-行表示在buggy版本中存在但在修复版本中被删除的代码if (str null)。行表示在修复版本中新添加的正确代码if (StringUtils.isEmpty(str))。你只需要在buggy版本的NumberUtils.java第123行附近做出对应的修改即可。手动修改后再次运行defects4j test你会发现测试通过了。这个过程不仅能让你得到修复版本更能深刻理解这个缺陷的根源和修复思路对于做自动程序修复的研究者来说是绝佳的学习材料。5.3 其他可能遇到的问题init.sh下载速度慢或失败由于需要从海外仓库下载大量数据网络不稳定是常态。可以考虑配置网络代理或者寻找一些国内镜像是否有备份的project_repos数据但这需要一定的技术能力去手动替换。最朴素的解决办法就是多试几次或者选择在网络通畅的时间段进行初始化。内存不足导致编译失败一些大型项目如Closure编译时需要较多内存。如果defects4j compile失败并提示内存相关的错误可以尝试设置更大的堆内存。例如对于Ant项目你可以通过设置环境变量ANT_OPTS来实现export ANT_OPTS-Xmx2g -Xms1g然后再执行编译。不熟悉的项目构建系统Defects4j虽然抽象了compile和test命令但如果你需要深度定制构建过程比如引入新的库可能还是需要去了解对应项目原始的构建方式是build.xml还是pom.xml。这时候去project_repos下找到对应项目的仓库研究其构建脚本是必经之路。Defects4j是一个强大的工具也是一个复杂的生态系统。第一次安装和配置可能会遇到些波折但一旦打通它就为你打开了通往基于真实缺陷的软件工程研究的大门。我建议你在自己熟悉的Ubuntu环境下严格按照上述步骤操作遇到报错不要慌仔细阅读错误信息大部分都能在本文找到解决方案。当你成功运行起第一个缺陷版本的测试并看到它如预期般失败时那种感觉就像解锁了一个新成就。剩下的就是利用这个宝库去探索你感兴趣的研究问题了。