摘要
众包测试已被广泛采用,以提高各种软件产品的质量。众包工人通常执行测试任务,并通过测试报告报告他们的经验。虽然众包测试报告提供真实使用场景的反馈,但检查如此大量的报告是一项耗时但不可避免的任务。为了提高这项任务的效率,现有的广泛使用的问题跟踪系统,如 JIRA、Bugzilla 和 Mantis,已经提供了基于关键字搜索的方法来帮助用户识别重复的测试报告。然而,在移动设备(如手机)上,众包测试报告往往包含不充分的文本描述,但是有丰富的截图,因为数据已经发生了根本的变化,这些基于文本分析的方法变得不那么有效。
在本文中,我们不再仅仅关注基于文本描述的检测重复,而是提出了 CTRAS:一种利用重复来丰富 bug 描述的内容并提高检查这些报告的效率的新方法。CTRAS 能够根据文本信息和截图自动聚合重复的测试报告,并进一步将重复的测试报告总结为一个全面和可理解的报告。为了验证 CTRAS,我们使用从 12 个工业众包项目收集的超过 5000 份测试报告进行了定量研究。实验结果表明,CTRAS 自动检测重复报告的准确率平均为 0.87,优于经典的基于最大覆盖率和 Jensen Shannon 散度度量下的 MMR 总结方法。此外,我们进行了一项 30 人参与的基于任务的用户研究,结果表明 CTRAS 可以平均节省近 30%的时间成本,而不会丢失正确性。
1 介绍在本文中,我们提出了一种名为 CTRAS 的方法,它能够利用重复测试报告的信息来帮助开发人员理解测试报告。与传统的 bug/测试报告处理技术不同的是,我们的技术不是劝阻开发人员提交重复的文件并过滤掉它们,我们的技术旨在利用它们提供的附加信息,并从分组的重复文件中总结文本和图像信息,形成一个全面的、可理解的报告。

CTRAS 通过测量文本描述和屏幕截图的相似性来自动检测和聚合重复的报告。根据汇总结果,对于每个重复的报告集群,它识别信息最丰富的报告,我们称之为主报告,并总结补充文本和屏幕截图。这些补充品按权重排序,CTRAS 通过结合主报告和补充报告生成最终的总结报告,为开发人员提供每个测试报告副本组的可理解概述。
为了验证 CTRAS,我们使用从 12 个移动应用程序收集的超过 5000 份测试报告进行了定量和定性实验。结果表明,CTRAS 通过利用文本描述和屏幕截图信息可以准确地检测和聚合 87%的重复报告。与仅基于文本和屏幕快照的方法相比,它将重复报告检测和聚合准确性分别提高了 6%,提高了 44%。同时,根据我们的评价结果,与经典的 MCB 和 MMR 总结方法相比,CTRAS 生成了更多的描述性总结。此外,我们对 30 名参与者进行了基于任务的评估,结果表明 CTRAS 可以在不丢失正确性的情况下平均节省 30%的时间成本。

本文有以下贡献:
1.
我们提出了 CTRAS,一种移动众包测试报告处理技术,以帮助开发人员。据我们所知,CTRAS 是第一个旨在将多个重复的测试报告聚合为丰富的、总结的报告的研究。CTRAS 的实现是公开的。
2.
基于 CTRAS,我们提出了一种方法来检测利用图像信息的重复测试报告。实验结果表明,图像信息可以提高重复检测和聚合的性能。
3.
我们对来自 12 个工业众包项目的超过 5000 份测试报告进行了全面研究,以验证 CTRAS,并发现 CTRAS 在聚类准确性、总结性、使用效率和可用性方面表现良好。
2 背景A. 移动众包测试报告
与传统的桌面软件应用程序 bug 库相比,移动众包测试的 bug 报告库通常具有更高的重复率、更简短的文本描述和更丰富的截图。
高重复率:
众包测试在移动应用程序测试中很流行,因为它使开发人员能够在真实使用场景下评估他们的软件产品的性能。然而,在实践中,众包工作者往往被要求在给定的短时间内完成众包任务,完成任务的数量影响着众包工作者的报酬。因此,人群工作者不太可能主动过滤掉重复的内容,他们被鼓励提交尽可能多的报告。这些因素使得众包测试比传统测试包含更高的重复率。
简短的文本和丰富的截图:
此外,在几乎所有的移动设备上,图像在分享、表达和交换信息中扮演着至关重要的角色。终端用户可以很容易地截屏,而众包工作人员倾向于用直接的截屏和简短的描述来描述 bug,而不是冗长复杂的文本描述,这很大程度上是因为截屏很容易,而在移动虚拟键盘上输入较长的描述相对比较困难。在移动平台上,截图通常捕获定义良好的应用程序视图,而且不会遇到桌面应用程序截图那样多的困难,比如不同的分辨率、缩放、遮挡和窗口大小。在这种情况下,上述问题得到了改进,主要问题是错误消息对话框的提示、GUI 元素的移位或一些元素根本没有显示。
B. 动机
前面提到的手机众包测试报告的特点,即高重复率、短文本描述和丰富的截图,促使我们提出一种利用重复报告中的文本和图像信息的方法,以增强开发者对 bug 的理解。
此外,在软件开发实践中,一个常见的和传统的信念是重复测试报告的报告是一个不好的实践,因此被认为是有害的。反对重复测试报告的长期和频繁的争论是,它们使问题跟踪系统紧张和浪费软件维护人员的努力。因此,基于这一论点,先前的研究人员提出了许多技术来帮助开发人员避免在重复的内容上浪费时间。然而,也有相反的观点。Zimmerman 等人认为信息的缺失,比如复制步骤和环境设置,是开源项目测试报告中最严重的问题之一。他们发现,开发人员经常需要花额外的时间与报告者互动,以确定缺失的信息,并获得对 bug 的足够理解。Bettenburg 等人的提供的经验证据表明,重复提供了描述 bug 的额外信息,而这些信息有助于故障定位和修复。这些发现符合移动众包测试的情况,它已被广泛应用于现代移动应用的质量保证。
3 目标和初步定义在本节中,我们将强调我们的主要目标,并提供随后将使用的定义和符号。我们的总体目标是聚合重复的测试报告,并提供一个可理解的小组概述。特别是对于移动软件,我们寻求提供一种技术,这种技术在聚类测试报告时既稳健又有效,这些测试报告可能包含简短的文本描述,但也可能包含显示故障症状的屏幕截图。
4 方法
我们在图 1 中给出了 CTRAS 的流程。CTRAS 由两个主要组件组成:聚合器和总结器。聚合器被设计用来计算测试报告和聚合到 组的副本之间的距离。我们使用层次聚类来完成这个任务。为了帮助开发人员快速理解重复组的内容,总结器首先选择一个最好地例证了聚集的测试报告组的测试报告,然后它通过逐步提取补充信息来补充信息,这些补充信息包含主报告未包含的主题或特性。
A. 聚合器
聚合器首先计算测试报告的距离,并输出距离矩阵。在距离计算方面,我们采用 Feng 等人提出的混合策略,通过结合图像相似度和文本相似度来度量测试报告之间的距离。在文本描述方面,采用自然语言处理(NLP)技术包括标记化、同义词识别和关键字向量构建,来计算文本相似度。对于截图,采用空间金字塔匹配(SPM)技术提取图像特征,计算截图相似度。所有报告之间的混合距离矩阵建立在这两种相似度的加权调和均值之上。应用 SPM 算法从一个截图中提取特征通常只需要 1-2 秒,计算两个截图之间的距离需要毫秒。
基于距离矩阵,聚合器能够测量测试报告之间的相似性,并进一步对重复报告进行分组。考虑到实际中无法预测组的数量,我们采用分层聚类(Hierarchical Agglomerative Clustering, HAC),它可以根据阈值距离值确定组的数量,对重复的报告进行分组。
B. 总结器
总结器是 CTRAS 的核心组件。对于每个重复的测试报告组 ,它执行以下三个步骤来生成总结,以帮助开发人员形成对 中所有报告的全面理解:(1)识别主报告 r,(2)生成补充,(3)形成并生成最终的总结。
为了便于解释,我们以实证研究中包含 6 个测试报告的真实组为例,并在图 2 中说明每个子步骤。我们在图 2-a 的示例组中列出了 6 个类似的报告。请注意,所有这些报告都描述了一个包含通过第三方工具登录到应用程序的问题的相同的 bug。这个组的每个报告都由它的基本属性组成,比如报告名称、创建时间、文本描述和几个屏幕截图。
1. 主报告识别:
为了帮助开发人员简明地理解小组内测试报告的主题,我们识别主报告 r。在第一步。我们将每个测试报告组抽象成一个图,其中每个节点代表一个单独的报告。两个节点之间的边的权值表示这两个报告之间的相似性。因此,我们可以应用 PageRank 算法,它可以计算一个数值等级分数,并测量每个测试报告组上加权图中的每个节点的重要性。CTRAS 确定具有最大页面排名分数的测试报告作为组的主报告。
示例:
图 2-b 显示了代表示例性组的图表,表格显示了每对报告之间的混合相似性。我们通过应用 PageRank 算法计算每个节点的权重。我们发现 report-3 的权重最高,因此我们选择 report-3 作为这六份报告的主报告(标记为 r)。通过阅读 report-3 的内容,开发人员可以对整个测试报告组有一个较高的了解,即存在一个 bug,用户因为 QQ 没有通过认证,被视为非官方软件,无法通过 QQ 社交登录服务登录 App。
1. 补充生成:
即使我们已经确定了主报告 r,并帮助开发人员获得 组中信息最丰富的报告,但是从其他角度描述相同的 bug 并提供补充材料对开发人员正确修复 bug 至关重要。因此,我们进一步分析其他报告,找出它们之间共享的内容作为补充点。在这个过程中,我们进行了两个子步骤来识别补充项:(1)从 中识别候选项;(2)将候选项进行分组,形成补充材料。
识别候选项目:
因为句子在语言学理论中被认为是直接的整体单位,一些旨在分析测试/bug 报告以帮助开发人员理解 bug 描述的研究工作选择了句子作为基本单位。因此,我们也相应地这样做,并通过计算两个句子的关键字向量之间的 Jaccard 距离来度量两个句子之间的相似度。Jaccard 距离是一个比较两个集合的相似性和多样性的有用度量,如下面公式所示。
示例:
如图 2-c 所示,我们将文本项目标注为矩形,将截图项目标注为菱形。CTRAS 从示例组中确定了 8 个候选句子和 4 个候选截屏。
候选项目细化:
通过候选项目识别,识别出所有与主报告中任何项目不相似的候选项目。但是,其中有些项目可能过于简短导致难以理解,或者它们彼此相似。因此,我们将其提炼为简洁、有代表性的补充材料。
CTRAS 的提炼过程包括三个子步骤:步骤 1 对相似的候选项进行聚类;步骤 2 提供候选集群的一个附加集群;步骤 3 对聚类中的候选对象进行加权,由此确定最具代表性的候选对象。
在步骤 1 中,我们对相似的候选项进行分组,以消除冗余并提高补充条目的简洁性。在此步骤中,我们将层次凝聚聚类方法应用于候选句集合上,形成一些候选句集群。同样,我们可以对候选截图集应用相同的策略,并使用本节 A 部分中描述的方法空间金字塔匹配获得候选截图集群。此外,我们记录每个候选句的来源信息,以便我们可以将候选句映射到报告,反之亦然。这些信息不仅对下一步骤中进一步聚合候选句子簇很有用,而且对开发人员在实践中追回原始报告也很有帮助。
在步骤 2 中,我们进一步对步骤 1 中的候选集群进行分组。这一步的目的是恢复上下文。这种额外的分组级别特别适用于单例集群(因为包含不同的信息,所以单例集群只包含一个候选句子)。我们基于原始信息合并集群:包含来自相同测试报告的大部分内容的候选集群被再次集群。我们定义两个候选项集群之间的距离 t 和 s,如下列公式所示
这里,每个集群可以是候选句子集群或候选屏幕截图集群。 代表的候选项集群 t 所对应的测试报告集合。当候选项集群之间的距离小于阈值 θ,它们就被聚合到补充材料中。原始的补充材料不应该提供给最终用户,因为它们包含太多的冗余。
在步骤 3 中,我们在每个补充集群中确定最具代表性的候选项。根据我们对句子相似度和截图相似度的定义,我们将一个补充材料集群内的所有句子和截图分别抽象成两个加权图,并将相似度值作为各边的权值。给定这两个加权图,我们应用 PageRank 算法,得到每个节点的 PageRank 得分,即句子和截图。在下一阶段的内容提取中,将使用这些权重来突出每个补充集群最相关和最具代表性的信息。
示例:
图 2-d 显示了所有候选项的细化结果
1. 内容提取器:
在主报告和补充材料的基础上,进一步细化,生成简洁的总结。
在许多文本总结技术中,压缩比 K 控制最终总结的简洁性。在以前的著作中,计算压缩比是用来当作选择关键字的数量与原始文档中总关键字的数量之比。但是,因为 CTRAS 的目标是在文本和屏幕截图上生成总结,所以我们扩展了这个经典定义。对于文本,我们定义压缩比为所选唯一词的个数与补充材料内唯一词的总数的比值。类似地,对于截图,压缩比是被选中的截图数量与补充材料的截图总数的比率。我们让文本和截图的权重相等,从而利用这两个压缩比的平均值作为整个总结的压缩比。
为了生成最终的总结,我们首先包含主报告,然后按照补充材料中句子所对应的测试报告的数量以降序排序。对于每个补充,我们根据候选精炼阶段步骤 3 计算的权重,迭代地选择句子或截图,并将其包含到总结中,直到达到用户设定的总结压缩比。
示例:
详细的汇总过程如图 2-e 所示。
C. 实现
我们已经实现了一个基于 web 的测试报告管理工具,它不仅提供了测试报告总结,而且扩展了许多经典的测试报告管理功能,如自动重复检测、项目报告仪表板、关键字搜索、bug 分类和最佳修复建议。
我们在图 2-f 中展示了其总结可视化页面的截图,其中显示了来自示例性重复组的最终总结的可视化结果。在该页面的顶部,我们显示了关于聚合报告的属性信息(例如在该集合中提交报告的所有人群测试人员的集合、bug 类别、严重性)。然后,我们显示来自主报告的信息,目的是帮助用户获得所有副本的概述。在主报告窗格下面,列出了补充的主题。我们突出显示了每个补充部分的代表性句子、短语和屏幕截图,这使得最终用户能够一目了然地了解该补充部分的主要主题。此外,终端用户可以通过单击这些补充主题来查看详细信息,包括所有的句子、屏幕截图和补充内容所对应的原始报告。
8 总结诊断大量测试报告问题是众包测试的一个基本挑战。为了缓解这一问题,本文提出了 CTRAS,一种用于聚合和汇总众包测试报告的新方法。CTRAS 利用重复的报告来协助专业测试人员去管理和理解众包测试报告。它克服了以下几个缺点:(1)聚合副本以支持批处理,(2)从副本中总结补充主题以方便开发人员理解报表。评估结果显示,CTRAS 能够协助人们检测和筛选众包测试报告。
致谢本文由南京大学软件学院 2021 级博士研究生肖媛翻译转述。