4. 评估
4.1 数据集
目前没有现成的测试用例集可用，我们通过挖掘 GitHub 上 2017 至 2018 年的开源项目构建了一个候选测试用例集 CTC，其包含超过 13，000 个依赖意识的测试用例。表 1 显示了 CTC 中不同 JUnit 版本对应的测试用例数。
4.1.2 查询主题
为了便于评估，我们简单的将推荐看作为测试用例搜索过程。在这种情况下，我们将新的测试目标视为查询用于搜索过程，查询结果是推荐的测试用例。我们从开源项目构建了一个查询集合 Q，其包含 50 个测试目标。这些测试目标的选择满足以下条件：（1）测试目标必须有方法注释。方法注释对于开发者理解方法要做什么非常有用。（2）测试目标应该具有高可理解性。只有测试目标是可理解的，我们才能判断是否推荐的测试用例是真的相关的。（3）测试目标是不重复的。
此外，在实践中，不同的开发者有不同的编程风格。因此，无论候选测试用例集有多丰富，其也无法保证包含与新待测方法相同的测试目标。我们对 Q 中的每个查询进行了很小的修改产生新的 50 个查询 Q’，包括使用同义词替换方法名中的动词或缩写扩展。我们旨在构建一个实际的应用场景，那就是对于每个查询，CTC 中都不存在与其完全相同的测试目标。对于 Q 和 Q’ 中的每个查询，我们雇佣研究生进行两阶段检查。首先，每个查询有两名研究生独立的检查以确保测试目标是高可理解的。所有被标记为不同结果的查询将提供给本文第一作者进一步确定。
4.2 对比测试推荐技术
（1）SM-based（Baseline）。基于方法签名精确匹配的推荐方法，换句话说，如果两个测试目标的方法签名是相同的，那么它们可以重用彼此的测试用例。该方法最易于实现，因此我们将其视为基线技术。
（2）ESM&R-based（TestTenderer）。传统的方法签名可以唯一表示同一个类中的方法，但是无法唯一表示不同类中的方法。 TestTenderer 提出的测试用例推荐方法将扩展的方法签名和松弛策略相结合。表 2 显示了扩展的方法签名示例。松弛算法用于匹配算法中的递归调用，由四个级别组成：1）搜索查询的精确匹配；2）给方法名增加通配符；3）移除方法仅搜索类名；4）给类名添加通配符。
（3）Clone-based（NiCad-based）。基于克隆检测的推荐方法，换句话说，如果两个测试目标是克隆对，那么它们可以重用彼此的测试用例。Mostafa 等人使用了成熟的克隆检测器 NiCad 来实现基于克隆检测的测试用例推荐。
（4）TBooster。我们提出的推荐方法，其从多个层面度量测试目标相似性，目的是提高推荐的准确性。
4.3 评估指标
（1）FRank：结果列表中第一个提示结果的排名。
（2）SuccessRate@k：度量在前 k 个排名的结果中超过一个正确结果的查询的百分比，公式（10）用于计算 SuccessRate@k，其中
是一个函数，如果输入是 true 其返回 1 否则返回 0。
（3）Precision@k：度量前 k 个排名结果中相关结果的百分比。公式（11）用于计算 Precision@k，其中 |RTC| 表示 k 个推荐中相关的测试用例数。
（4）MRR：一组查询 Q 的结果的倒排名的平均值。公式（12） 用于计算 MRR。
4.4 实验结果
表 3 显示了四种技术在 Q 上的整体性能。列 R@1，R@5，R@10 显示了当 k 为 1，5，10 时的 SuccessRate@k。列 P@1，P@5，P@10 显示了当 k 为 1，5，10 时所有查询的平均 Precision@k。列 MRR 显示了四种技术的 MRR 值。对于 SuccessRate@5 和 SuccessRate@10，TBooster 在 TestTenderer 上提高了 11% 和 35%。图 7 显示了 Precision@k 的统计，符号‘+’表示平均值。我们可以发现对比与其他三种技术，TBooster 实现了较好的整体精度。
表 4 显示了四种技术在 Q’ 上的整体性能。我们可以发现，四种技术受到了修改导致的不同程的影响。其中 Baseline 基本失效了，NiCad-based 和 TBooster 受影响最小。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
