移动应用程序的特定故障分类并用于集中质量保证

张文龙，张志翔

（四川大学计算机学院，成都 610065）

0 引言

由于移动设备的不断发展和扩散，几乎所有领域都在开发新的应用程序。特别是在移动商务应用的领域，应该充分利用某些优点，如更高的可用性、新信息的快速分发和更快的反应时间。这些特征表明，移动商务应用程序不仅仅是一个转移的桌面应用程序、游戏应用程序或内容查看应用程序。移动商务应用程序通常是根据移动设备如智能手机或平板电脑（不是笔记本电脑），集成到现有的IT 基础设施，是面向任务的和集中于一个清晰的和有限的功能范围，以及基于公司业务流程的流动潜力[1]。事实上，考虑到当今市场上有大量的应用程序执行显著的相似功能[2]，应用程序的设计和用户体验往往是导致成功或失败的区别因素[3]。

因此，移动商务应用程序的质量是非常重要的，以避免损失收入或降低效率等负面影响。设想一个用于生产过程控制的移动应用程序，它提供关于当前状态的信息来监视生产并提供决策支持，例如，环境参数的收集和解释。如果应用程序失败，它可能会导致错误的决策或意外的生产效果，由于生产过程的高启动时间而造成非常严重的后果。

Muccini 等人[5]认为，智能手机和平板电脑等移动设备上的应用程序的主要特点是：有限的资源（如电池）、用户界面（如触摸屏）、上下文感知（如移动连接）和多样性（如设备和操作系统）。此外，该论文贡献了一个研究问题：移动应用程序是否不同于传统应用程序，是否需要不同的、专门的新测试技术。讨论移动应用程序的特点和结论（关于测试的移动应用程序），存在着许多挑战与移动应用程序的上下文环境和移动性有关，而且性能、安全性、可靠性和能量都受到移动设备所处环境变化的强烈影响。

因此，移动商务应用程序的失败与桌面应用程序的失败是不同的。关于移动应用程序的典型故障模式的类型，发生的频率，及其在质量保证方面的考虑，还没有确定的规则。所以，这对移动应用程序质量保证造成了一点的负面影响，并可导致：

●移动应用程序中存在的潜在故障风险

●重复的修复移动应用程序的这个迭代过程将对公司的开发过程产生代价高昂的结果

在现有的移动应用程序的故障类型中，是从面向编程的角度来对故障进行分类的[6-10]，这就要求分析人员具备一点专业的IT 知识，才能正确的去识别这些故障类型。假如我们从人视觉分析的角度去考虑这个问题，将移动应用程序故障轻量化，仅仅只考虑GUI 图形，那么对于移动应用程序的质量保证会不会产生正面积极的影响？

假设经典桌面应用的质量保证方法与移动应用的质量保证方法没有显著差异，那么移动应用的故障

模式存在哪些主要的、有区别的特征，这导致了研究问题：

●RQ1：如何对检测到的移动设备故障进行分类?

●RQ2：存在哪些典型故障类型，如何将它们集成到故障分类中?

1 典型的移动应用程序故障

关于分类，本文使用术语fault 作为故障的起源，并使用术语fault aspect 作为导致移动应用程序特定故障的测试用例的焦点。

1.1 移动设备故障的文献综述

根据Kitchenham[6]的一篇文献综述，作者阐述了这种技术的现状，并回答了关于移动应用程序失败的问题。

包含IEEE Xplore 和ACM 数字图书馆内容的书目数据库 Scopus[7]在 2006 年 1 月至 2014 年 1 月期间发表了计算机科学领域的1001 项结果。查找相关出版物的搜索字符串是基于失败和移动相关的术语。2006年和2014 年的搜索结果中没有相关的出版物。从数据库的结果可以找出26 份出版物来支持这项贡献。来自这些出版物的信息将被考虑用于故障分类，包括典型故障方面。其他相关的出版物也在故障检测和故障方面支持了这一贡献，但是它们描述的观点基本相似。

支持这一贡献的部分出版物主要介绍了基于度量的移动电话故障特征，并确定了移动应用程序的主要故障类型，研究了错误报告中报告的故障，或集中于具体的错误主题，如资源限制器或触发器。

1.2 文献中的故障分类

Mauser 等人在文献[7]中收集了有关移动应用程序领域之外的故障（故障、错误等）分类的相关工作，重点是人机接口（Human Machine Interfaces，HMI）。考虑到移动设备也是HMIs，与HMI 相关的出版物基本都与这一贡献相关。在这里，失败分类的主要类是行为、设计和内容，它们根据上下文被划分为子类。这项工作的分类是由IBM[8]在20 世纪90 年代早期创建的正交缺陷分类（ODC）所开发的。

IEEE 软件异常的标准分类[9]描述了一种基于每个故障报告属性列表的方法。其目的是定义一个通用的词汇表，不同的人和组织可以使用它进行交流，并建立一套通用的属性，以支持分析软件缺陷和故障数据[6]的行业技术。这不是本文的目标，本文主要关注一种更轻量级的分类方法。然而，该标准中的故障属性值包含了可能的错误、丢失和额外值的section 模式，这被认为是移动应用程序故障子类的一个有说服力的划分。

1.3 基于GGUUII的移动应用程序故障分类

从相关工作的研究和质量保证项目的经验中获得的见解使基于GUI 的故障分类成为可能，其中包括到典型故障方面的映射。首先，无论移动应用程序处于开发之前还是投入使用期间，移动应用程序通常采用图形用户界面（GUI）的形式来表示，所以，我们可以根据基于GUI 来找出存在于移动应用程序中的显著故障。故障方面的类别定义如图1 所示。

图1 故障分类及其子类

一个完整的移动应用程序由很多个屏幕原型组成，这些屏幕存在着嵌套的关系，而每一个屏幕原型都是由相对应的组件组成，如，在Android Studio[11]开发中频繁使用的 View、TextView、Button、EditText 组件和在Apple's Xcode IDE[12]开发中频繁使用的UIView、UILabel、UIButton、UITextField 控件，他们仅仅只是因为操作系统的不同，而导致对象名不同，而实质上是同一个组件。因此，移动应用程序故障的分类可以根据组件进行故障分类。

因为一个组件有其特有唯一的属性，包括有在屏幕上显示的位置，包含以下信息：①＜x-position，y-position＞、②＜height，width＞、③＜text＞、④＜image＞。这里四个元素述了组件的边界框的左上角的位置，而高度和宽度属性描述了边界框的大小。文本属性对应于组件显示的文本，而图像属性表示组件的图像，其边界依附于前两个属性。

由于每一个组件都有一个且唯一的元素属性，我们可以设定某一种阈值对其进行比较，来对移动应用程序中屏幕出现的故障进行判定和分类。

在本文的故障分类中，可以有效的进行第一类故障类别是布局故障。要检测布局故障的类别，主要与两个属性有关：①组件位置（即＜x，y＞的位置），和②尺寸（即边界框的＜h，w＞）。通过比较 x 或 y 维度中数值的差异是否大于某一个布局阈值，从而判断是否出现布局故障，同时输出故障类型。

可以有效地识别出的第二类故障类别是文本故障。通过对以下属性进行处理：①组件位置（即＜x，y＞的位置）、②尺寸（即边界框的＜h，w＞）、③文本（即＜text＞显示内容）。首先对基于文本位置的边界框大小进行裁剪，然后对裁剪后的推行进行图形处理，得到基于像素的差异，就可以判断其是否存在字体颜色和样式故障。其次，为了检测不正确文本故障，可以对文本text的内容进行预处理，以处理空白和规格化字母大小，并执行字符串比较。如果字符串匹配失败，则输出不正确文本的故障类型2c。

同样的，可以准确的分类的第三类故障类别是资源故障。需预处理4 个元素的所有信息，然后进行合理分析、解释，最后给出与其对应的输出类型。假如我们现在存在一个缺失的控件，那么在屏幕中，在对应的＜x，y＞位置上就不存在一定＜h，w＞的边界框，从而出是资源故障中的缺失或额外组件。同理，可以根据属性中的＜image＞信息，进行图像预处理技术，得到其对应的故障类型。

2 讨论

在实际开发过程中，故障的发生通常主要以屏幕中的某一区域的组件由于某种不可控的原因而导致其发生改变造成的，比如：水平方向的移动可能使用应用程序时发生故障。这样的问题在很多情况下不是由开发人员引起的，而是由需求工程师引起的。由于缺少规范，就像在这个故障方面的情况中一样，允许对功能进行解释或忽略。

通过对项目的实证研究，这证实了基于GUI 的故障分类的充分性，并导致了子类的派生，以及在应用于评估中移动应用程序后对典型故障方面的扩展。关于子类的扩展总是关于调整子类的定义。对于用于应用分类的移动应用程序，没有必要再细分，只需要对故障方面进行少量扩展。最终，每个报告的故障都可以链接到一个已定义的故障类。没有不相关的故障报告。由于开发者没有实时报告每次检测到的故障，为了评估在应用程序集中的分类的完整性，以及每个被访谈的开发人员的个人开发经验，我们与几个在程序开发领域有几年相关工作经验的开发人员讨论了分类。

因此，本文提供了一个初始分类，如果需要，可以根据故障类及其相应的故障方面的集合和定义对其进行调整和扩展。

有关特定于移动设备的故障类及其与每个故障类的典型故障方面的关系的知识可用于集中质量保证活动，如系统和集成测试。Holl[7]已经提出了一种适合的质量保证方法，该方法基于使用检验和测试技术的整体方法。该方法能够对测试用例进行有重点的推导，考虑到频繁的故障模式和通过检查方法进行的缺陷检测，该方法适用于通常不充分且不断变化的需求规格。

3 结论和相关工作

这项工作产生了一个基本的基于GUI 的故障特定分类，它可以用来集中质量保证，从而减少移动应用程序中遗留的，潜在的故障风险。这可以防止依赖于业务流程范围的代价高昂的后果。此外，派生的分类鼓励对未来工作主题的研究。

第一个研究问题是，如何对检测到的移动设备故障进行分类?根据项目经验和故障分类的相关工作回答。第二个研究问题，存在哪些典型的故障方面，如何将它们整合到故障分类中?根据项目经验和有关移动设备故障的文献综述，回答了这个问题。对这两个研究问题的研究导致了信息的重叠和信息的互补。结合其他分类方案的知识，可以创建基本的特定于移动设备的故障分类，包括分类典型故障方面。将此分类应用于多个移动应用程序开发，可以成功地对其进行评估和优化。

作为未来的工作，对开源项目报告数据库的调查将是全面评估这一分类的下一步工作之一，如果能够找到新的见解，还可以扩展它。此外，还将探讨可能根据故障报告中所报告的频率来推导故障分布的可能性。进一步的步骤将是提出的质量保证方法[7]，基于派生的故障分类，以评估整体集中的质量保证方法。