1. Defects4J的使用——基本属性介绍

Defects4J的使用

Defects4J的更多信息在：https://github.com/rjust/defects4j
该系列用于学习使用Defects4J过程的记录，有空就会进行补充和更新，欢迎同研究软件测试 错误定位的朋友一起交流学习。
本文主要是翻译了github上的介绍。

The bugs

Identifier	Project name	Number of bugs
Chart	JFreeChart	26
Closure	Closure compiler	133
Lang	Apache commons-lang	65
Math	Apache commons-math	106
Mockito	Mockito	38
Time	Joda-Time	27

每个bug有以下这些属性：

• 问题归档在问题相关的追踪器中，追踪器对此进行判别、识别。
• 可以由一次提交修复。
• 最小化：Defects4J的维护者们手动排除掉了无关紧要的变化（比如重构或者功能添加）
  （以保证修复后的版本和错误版本的差异最小）
• 通过修改源代码来修复（而不是修改配置文件、文档或者测试文件。）
• 存在触发测试用例，即修复前执行fail，修复后执行pass——测试用例的失效不是随机或者依赖执行顺序。

错误以及修复的程序版本分别用b和f来标记。（是一个整数）

在命令行界面，Defects4J的命令：

Commands	简介
info	查看特定程序或bug的配置信息
checkout	检查指定的程序版本
compile	编译源代码以及开发人员为出错或修复的程序版本编写的测试
test	在错误或修复的程序版本上，执行单独的测试用例方法或者一个测试用例集
mutation	在错误的或修复的程序版本中，进行变异分析
coverage	在错误的或修复的程序版本中，进行代码覆盖分析
monitor.test	运行单个测试用例或测试用例集时，监测类加载器
export	输出特定版本的属性，比如classpaths, directories, list of tests

输出特定版本的属性：

在工作目录下使用defects4j export -p [-o output_file]命令，来得到特定版本的属性信息：

Property	Description
classes.modified	由bug修复的类
cp.compile	编译运行程序的Classpath
cp.test	编译运行开发者写的测试的Classpath
dir.src.classes	类的源目录位置（相对于工作目录）
dir.bin.classes	类的目标目录位置（相对于工作目录）
dir.src.tests	测试or测试用例？ 的源目录（相对于工作目录）
tests.all	开发人员写的全部测试类列表
tests.relevant	"相关"测试类的列表（执行时JVM只要加载了至少一次修复的类就认为该类是"相关"的）
tests.trigger	触发该bug的方法列表

测试执行框架：

生成测试用例集的测试执行框架(framwork/bin)提供了以下脚本：

Script	Description
defects4j	主要脚本，前面已经描述过了
run_bug_detection	测定真实错误检测率
run_mutation	测定变异分数
run_coverage	测定代码覆盖率（语句及分支覆盖）
run_evosuite	使用EvoSuite生成测试用例集
run_randoop	使用Randoop生成测试用例集