成功、挑战和反思关于移动应用众包测试的行业调查

成功、挑战和反思——关于移动应用众包测试的行业调查

引用

Ruizhi Gao,Yabin Wang,Yang Feng,Zhenyu Chen,W. Eric Wong. Successes, challenges, and rethinking – an industrial investigation on crowdsourced mobile application testing[J]. Springer US,2019,24(2).

摘要

众包（crowdsourcing）一词是 crowd（人群）和 outsourcing（外包）的复合缩写，它是一种新的范式，指利用人群的力量来推动使用传统方法耗时耗力的大规模任务。这一范式为移动应用公司提供了将测试活动外包给拥有各种测试设施和环境和不同技能和专业知识水平的众包测试人员的可能性。通过这种被称为移动应用众包测试（CMAT）的方式，一些在测试移动应用程序时的共同问题可以得到缓解，例如移动设备过多，设备模型的碎片化，各种操作系统版本，以及测试场景的多样性等。然而，CMAT 在实践中效果如何？在应用 CMAT 的过程中遇到了哪些挑战和问题？如何克服这些问题和挑战以改进 CMAT？尽管 CMAT 已经引起了学术界和工业的，但这些问题尚未得到大规模和现实工业研究的深入探讨。自 2015 年 6 月起，我们与 Mooctest（一个众包测试中介公司）合作，用他们的 CMAT 平台——Kikbug 测试 5 个真实的 Android 应用程序。在整个过程中，我们从 258 名人群测试者中收集了 1013 个 bug 报告，共发现 247 个 bug。本文将全面介绍我们的行业研究，并对 CMAT 应用的成功和挑战进行深入分析。

问题背景

众包最早定义为“一种将传统上由员工执行的任务以公开电话的形式外包给一大群人的理念”。自 2006 年以来，一些市场上最成功的新公司一直在利用这一理念。目前，众包软件测试是软件工程研究社区的新趋势。执行移动应用程序测试时，会遇到各种各样的困难，如 Android 设备数量众多、现有设备碎片化问题非常严重、兼容不同版本的 Android 等。众包移动应用测试（CMAT）可能是解决这些问题的一个好选择。通过利用 Mooctest 公司开发的强大的 CMAT 平台 Kikbug，我们进行了众包测试的行业调查。我们观察到，CMAT 可以有效地检测移动应用程序的 bug，但 CMAT 的应用仍处于起步阶段，仍有很大的改进空间。

CMAT的工作流程

下面是使用 Kikbug 作为 CMAT 平台的工作流程。总体而言，CMAT 的工作流程主要分为五个阶段，如图 2 所示。

·阶段 1:申请上传：客户将自己的应用程序上传到 CMAT 平台的应用广场并指定相应的测试任务和酬劳信息。

·阶段 2:任务选择和环境设置：测试任务的应用程序被激活后，众测人员就可以选择他们想要完成的任何任务。选择后测试人员将从平台上下载应用程序进行测试。

·阶段 3:提交 bug 报告：众测员开始根据选择的任务测试应用程序，对测试到的 bug 提交不完整的 bug 报告。

·阶段 4:生成最终测试报告：CMAT 平台收集补充信息，生成最终的 bug 报告。Kikbug 收集的补充信息包括：一般信息、设备信息、操作路径等。

·阶段 5:错误报告验证：客户将为他们的应用程序验证所有最终的 bug 报告，并决定如何酬劳每个提交 bug 报告的众包测试人员。

Mooctest 和 Kikbug

Mooctest 公司是一家位于中国南京的创业公司，成立于 2012 年。它专注于移动应用程序并提供众包软件测试服务。Mooctest 从 2014 年开始开发 Kikbug。目前，Kikbug 只支持针对 Android 应用程序的 CMAT。Mooctest 为中国 20 多个 IT 公司提供了 CMAT 服务，拥有多个小型和中型，以及一些大型企业的客户基础。到 2016 年 1 月，Mooctest 已经招募了超过 1000 名测试者。这些众包测试者大多年龄在 18 到 30 岁之间，约 90%的众包测试者拥有计算机科学或软件工程学士学位，约 30%拥有硕士学位，并且 75%的众测员参加过软件测试课程。

实验设置

在我们的研究中使用了来自不同公司的五款 Android 应用程序。表 2 给出了每个应用程序的名称、公司、类型和描述。目前，除了 SE-1800（由 Panneng 公司内部使用）之外，所有这些应用程序都已发布到 Android 市场。

公司将其应用程序的 beta 版本上传到 Kikbug，并定义测试任务。每个任务可能包含多个详细的需求。表 3 给出了每个应用程序的任务总数和需求。

这五个应用程序的所有任务都只有功能测试。检测 bug 的酬劳因任务不同而不同。当一个 bug 被多个众测者检测到时，只有第一个人会得到酬劳。

本次研究共涉及 258 名众测人员，共收集到 1013 份 bug 报告。表 5 给出了每个应用的详细数据（一个众测者可以接受多个测试任务）。

如图 4，258 名众测者的设备涵盖 29 个移动品牌，181 个安卓机型，22 个安卓版本，27 个屏幕尺寸。

数据展示

表 6 给出了每个应用程序和每个任务检测到的 bug 总数的详细信息。Sn,Jn,Un,Cn,SEn 分别表示 iShopping， JustForFun， UBook， CloudMusic，和 SE-1800 的第 n 个任务。我们从表 6 得出以下结论:

·CMAT 可以非常有效地检测 Android 应用程序中的 bug。众测者每个应用发现了超过 20 个 bug，在 iShopping 中发现了 95 个 bug，在 UBook 中发现了 54 个 bug。

·所有任务测试中检测到的 bug 总数不等于应用程序检测到的 bug 总数，在多个任务测试中经常检测到同一个 bug。造成这种情况的主要原因是不恰当的任务设计。如 U2 中的一些要求会被覆盖，检测出的 bug 也会有重复。

·同一个应用程序的不同任务中检测到的 bug 数量差异很大。如果一个任务的需求向众测人员表明这个任务测试很容易，那么该任务更有可能有很多人参与，从而更有可能检测到更多的 bug。

bug 类型

·功能 bug

应用程序没有按照测试任务中的描述运作，但是它仍然在运行并且没有退出。

·崩溃

应用程序在测试特定任务时停止正常功能执行并退出。

·性能 bug

应用程序功能能够完成，但是性能不足。

此外众测员还会提出一些提高应用程序质量的建议。

每个类别中检测到的 bug 以及建议的数量见表 7。大多数 bug 都是功能性 bug，且众测人员有强烈的意愿报告他们的体验。

表 8 给出了客户认可的与兼容性问题相关的 bug 数量，该表证明 CMAT 能够检测到与兼容性问题相关的 bug。

众包测试者的 Bug 检测能力

我们观察到许多众测者对于每个应用程序都有很好的 bug 检测能力。表 9 给出了众测员的数量，他们为每个应用程序检测出了一定数量的 bug。

对于这五种应用程序，超过 40%的众测者可以检测到不止一个漏洞。在 iShopping 发现的漏洞最多（95 个）。

众测者数量与检测到的 bug 数量的相关性

参与到一项任务中的众测员越多，就会发现更多的 bug。图 5 显示了参与众测人员的数量以及在所有应用程序的每个任务中检测到的 bug 数量。

为了进一步分析众测者数量与检测到的 bug 数量之间的相关性，我们计算了 Pearson 和 Spearman 相关系数（Hotelling1953）。如果 Pearson 和 Spearman 相关系数的值大于 0，则表示正相关。众测者数量与检测到的 bug 数量的正相关越强，Pearson 和 Spearman 相关系数越接近+1。在我们的研究中，Pearson 相关系数为 0.646，Spearman 相关系数为 0.504，表明在众测者数量和检测到的 bug 数量之间存在较强的正相关关系。

研究问题

RQ1：与传统的内部测试相比，CMAT 如何?

为了进行比较，我们在软件测试和质量保证高级研究中心（STQA）对所有五种应用程序进行了内部测试。9 名软件测试与质量保证专业博士生参与了本次测试计划。测试中心总共有 20 种不同的基于 Android 的设备。为了减少主观影响，我们采用以下两个先决条件:（1）对于每个应用程序，内部测试必须在与 CMAT 使用的时间相同的情况下完成。（2）对于每个应用程序，内部测试的总酬劳必须与 CMAT 相同。表 10 总结了我们的 CMAT 工业研究和内部测试的实验设置。

bug 检测数量的比较结果如表 11 所示。对于所有应用程序，内部测试检测到的 bug 总数都小于 CMAT。内部测试检测到的大多数 bug 也可以通过 CMAT 检测到。在检测兼容性问题 bug 上，CMAT 明显优于内部测试。然而，从表 10 和表 11 中，我们还可看出 CMAT 可以很容易地生成许多无效的错误报告。

RQ2: CMAT会导致许多无效的 Bug 报告吗?

我们从 5 个应用程序收集了 1013 个 bug 报告。我们将所有的 bug 报告分为三类。

——全部认可（AA）

客户认可 bug 报告中的全部 bug。

——部分认可（PA）

在 bug 报告中，至少有一个 bug 没有被客户认可。

——无意义（M）

bug 报告中的描述不完整或没有提供任何有意义的信息。

表 12 给出了每个类别的 bug 数量。我们发现众测者很少会提交无效的 bug 报告。然而，我们也注意到 PA 中的 bug 报告数量在 SE-1800 中相比其他应用较多。这是因为 SE-1800 专门为工程监测而设计的内部应用程序，众测者需要具备一定的领域知识，因此客户认为普通用户提交的大部分 bug 报告无效。这表明并不是每个应用程序都适合于 CMAT，取决于用户类型。

**RQ3:**目前的薪酬方案是否合理?

酬劳一般原则如下:

·如果众测者没有报告任何 bug 或者客户没有认可任何报告的 bug，他将得不到任何酬劳。

·如果多个众测者报告了同一个 bug 并且得到了客户的认可，那么只有第一个报告 bug 的众测者才会得到酬劳。

·如果一个 bug 得到了客户的认可，那么报告该 bug 的首个众测者将根据以下的一条或两条得到酬劳。

——客户会为任务中检测出一个 bug 给予固定的基本酬劳。这个数额因任务而异。客户在上传他们的应用程序时公布这些信息。

——如果众测者检测到 bug 或者给出了客户认为有价值的建议，那么众测者就会得到一笔浮动奖金。

从众测者的反馈来看，56.2%的人认为薪酬方案合理，40.3%的人认为薪酬过低，只有 3.5%的人认为薪酬过高。我们观察到众测者抱怨最多的是他们的努力没有得到客户的合理考量。如耗费不同时间找到的 bug 得到酬劳并无太大差别。

**RQ4:**重复的 Bug 报告在测试移动应用程序时是无用的吗?

表 13 给出了关于每个应用程序重复错误报告数量的详细信息。我们发现有很多众测者仍会提交重复 bug 报告，原因如下：（1）CMAT 的整个测试过程快速敏捷，让 CMAT 众测者检查所有的 bug 报告并避免重复很不现实。（2）只有来自不同设备的错误报告，才能说明应用兼容性问题。这告诉我们应该以恰当的方式利用重复错误报告的好处。

总结与未来工作

在过去的几年中，CMAT 在学术界和工业界受到了广泛的。尽管它很受欢迎，但关于 CMAT 在实践中如何有效，在应用 CMAT 时会遇到哪些主要挑战，以及如何解决这些挑战以进一步改进 CMAT 的有据研究仍然很少。为了调查这些问题，我们与 Mooctest 公司合作，参与 Mooctest 与五家公司在现实生活中的项目，用 CMAT 测试了五款 Android 移动应用程序。在本次研究中，我们从 258 名人群测试者中收集了 1013 个 bug 报告，共发现 247 个 bug。基于这些结果，我们发现 CMAT 可以非常有效地检测 bug。然而应用 CMAT 时，在如何提供合理的薪酬以及如何管理重复的错误报告方面仍然存在困难。我们为应对这些挑战提供了参考。目前，更多的工业性研究正在进行中，以进一步验证和改进我们提出的 CMAT 新工作流程。