摘要

随着用于访问万维网的设备的数量和种类呈指数级增长，无论用于浏览网页的设备如何，确保正确呈现网页都是一项重要且具有挑战性的任务。当开发人员采用响应式网页设计（RWD）技术时，网页会修改其外观以适应设备的显示限制。但是，目前缺乏自动化支持意味着在针对不同窗口大小进行渲染时，可能无法检测到页面布局中的显示故障。一个核心问题是难以提供自动Oracle来验证RWD布局，这意味着在实践中检查故障主要是手动过程，这导致许多实时响应式网站的布局故障。本文介绍了一种自动故障检测技术，该技术可检查响应页面布局在一系列窗口宽度上的一致性，从而避免了对显式Oracle的需求。在一项实证研究中，该方法在所研究的26个真实产品页面中的16个中发现了故障，总共检测到33个不同的故障。

关键词

响应式网页设计，显示故障，布局故障

1 介绍

响应式网页设计（RWD）是最近的一种设计和实现方法，它使开发人员能够构建无论设备大小如何都能提供等效用户体验的网页。RWD使网页能够动态地修改其布局以适应或“响应”设备显示器的大小，而不是要求用户平移太宽而不适合较小屏幕的页面，或缩放在桌面显示器上清晰可读，但在手机上太小的部分。如果内容多于可用空间，则用户只需垂直滚动页面。因此，在RWD的上下文中，浏览器窗口宽度是关于网页布局应如何调整的关键决定因素。

鉴于RWD的明显优势，自动检查显示故障的问题——网页渲染中的视觉差异导致其偏离其预期外观——是一个重要的问题。由于网站的美学和布局已被证明会影响其感知的可用性[26]和可访问性，提高其可信度，并产生用户忠诚度，因此在一个组织的网站中可见的故障可能导致收入损失并不令人惊讶。

针对这些问题，我们提出了一种自动化技术，可以检测在实际生产页面中普遍存在的五种类型的响应式布局故障，而无需显式的Oracle，例如一系列模型映像，复杂的布局规范或要比较的页面的图形模型。我们的方法依赖于常见的响应故障类型的隐式Oracle知识，自动检查响应式网页的布局，并在不同的窗口宽度上比较元素相对于彼此的位置。

例如，两个网页元素可能由于预期的图形效果而重叠，或者因为它们已经“碰撞”，因为水平屏幕空间已经减少。我们的方法通过检查连续窗口宽度的布局行为来区分两者。如果元素总是重叠，则开发人员在手动检查中可能意图和/或容易注意到该效果。然而，如果元素经常重叠，则可能发生微妙的RLF。我们的方法应用类似的原则来检测不一致的元素包装；仅存在一个或两个窗口宽度的布局；和内容的间歇性突出到其他元素，或完全从窗口出来。总的来说，我们定义了四种检测这五种RLF的算法。

我们将自动化技术应用于26个真实产品网页。实验表明，我们的方法可以在16个网页中找到故障，总共检测到33个不同的故障。我们的评估进一步表明，在当前可用工具的帮助下应用手动检查过程错过了我们的技术可以自动检测的19％至34％的RLF。

总结来说，本位的重要贡献如下：

（1）可发现的五种不同类型的响应布局故障（RLF）的分类，而不需要明确的Oracle。

（2）四种算法，可以自动检测响应设计的网页中的五种类型的布局故障。

（3）包含26个随机选择的产品网页的实证研究，显示所识别的RLF类型在实时站点中普遍存在，并且我们的算法能够检测它们，总共发现了33个不同的故障。

2 响应式网页设计的自动化故障检测

本节定义了五种不同类型的响应式布局故障（RLF），它们对于RWD都是有问题的，并且可以通过不需要显式Oracle的算法自动识别，例如网页的替代参考版本，模型图像或布局约束的复杂规范。

相反，我们的方法通过自动提取网页响应布局的模型，然后通过在不同的窗口宽度交叉检查其布局来分析该模型的潜在故障。我们首先介绍网页模型（第3.1节）。然后，我们介绍了响应式网页中普遍存在的五种类型的RLF，以及可用于通过网页模型检测它们的四种算法的定义（第3.2节）。

2.1基本概念：rRLG

我们的RLF检测过程的基础是页面的响应布局模型，它是响应布局图（RLG）的改进。RLG不同于网页的其他布局图模型（例如，Choudhary等人的“对齐图”[38]和Alameer等人的“布局图”），因为它模拟了一个窗口宽度范围内的网页——而不是一个静态宽度——以捕获其响应式设计。

通过查询网页的文档对象模型（DOM）来自动获得RLG，以在不同的窗口宽度处找到页面中涉及的HTML元素及其坐标。RLG根据其响应式设计，组织此信息以跟踪这些HTML元素的动态可见性和相对对齐，因为页面布局根据窗口宽度进行调整。“精制RLG”（rRLG）与我们原始的RLG的不同之处在于它不通过“宽度约束”对网页元素的宽度进行建模。虽然设计用于在页面中捕获回归问题，但宽度约束无助于检测本文中介绍的五种常见类型的RLF；因此rRLG不对它们进行建模。

图2提供了一个rRLG的示例，用于通过线框在两个不同的窗口宽度上绘制的网页。该页面涉及HTML元素div[1]-div[3]，这些元素相互堆叠用于窄窗口，要求用户滚动以将每个视图放入视图中。对于更宽的窗口，它们并排排列，并附有横幅图像img。

2.2响应式布局故障的常见类型及检测算法

一旦为响应式网页创建了rRLG，就可以检查我们接下来介绍的五种RLF中的每种类型以及可用于检测它们的算法。 每种算法的目的不仅是识别故障，还要识别涉及哪些HTML元素以及特定窗口宽度，以帮助开发人员诊断故障。

RLF1：元素碰撞。当响应设计的页面的窗口变得更窄时，考虑宽度损失的一种设计策略是将水平对齐的页面元素移动得更靠近。但是，当窗口收缩时，元素可能会相互碰撞，导致其内容重叠。这可能导致意外的效果，例如重叠的文本或图像，或隐藏的内容或功能元素，从而损害页面可用性。

图1和MidwayMeetup页面显示了一个示例。在更宽的窗口（第1d部分），输入框和按钮并排存在。然而，当窗口变得太窄时，元素发生碰撞，使最左边的按钮变暗（第1c部分）。

RLF2：元素突出。在实现响应式设计时，一个问题是确保随着窗口变得更窄，HTML元素的大小也会适应，因此它们仍然足以容纳其内容。当元素没有正确调整大小时，它们的内容可能不再“适合”，因此会突出到页面的周围部分。图1的PDFescape示例及其导航链接块显示在页面的右上角（第1f部分）。随着窗口变窄，水平空间不再足以适合徽标旁边的链接块。链接突出显示包含的HTML元素，对用户（第1e部分）不可见，因为容器具有CSS属性“overflow: hidden”集。因此，链接变得不可点亮，并且页面在特定大小的设备上是不可用的，并且窗口尺寸是固定的。

RLF3：窗口突出。当窗口空间被挤压时，元素可能不仅开始溢出其容器，而且还开始从页面的根表示HTML元素（即身体标签）中突出，从而出现在水平可视部分之外。这页纸。如第2节所介绍的图1的ConsumerReports网页展示了这种故障类型

RLF4：小范围布局。响应式设计的网站倾向于使用许多CSS规则，这些规则由不同的媒体查询激活和停用。对于给定的窗口宽度，CSS规则中的多个媒体查询可以同时评估为真。例如，两个规则，一个在窗口宽度超过768像素时激活，另一个规则在窗口低于1024像素时激活，将在769-1023像素范围内激活。对于给定的元素集和窗口大小，当一系列规则“开启”或“关闭”时，管理的逻辑可能很快变得复杂，开发人员可能经常犯错误导致在窗口中应用CSS规则宽度与意想的不同。当开发人员混合使用最小宽度和最大宽度限定符来定义布局中的更改时，就会出现这种类型的常见错误。例如，开发人员可以编码媒体查询“@media（max-width：768px）{...} “和另一个”@media（min-width：768px）{...}”。由于这两个表达式定义的窗口范围是包含的，因此两者都将在768像素窗口宽度处激活。媒体查询的这种冲突可能导致奇怪的布局效果，因为当只有一个集合时，将激活两组规则。开发人员难以发现这些类型的故障，因为它们仅出现在可以查看页面的整个窗口宽度范围的小范围内。图1的Cloudconvert示例是小范围RLF的示例。在单个窗口宽度处，页面的顶部菜单模糊了公司的徽标和标语（第1g部分）。

RLF5：包装元素。如果网页上的包含元素不足以容纳其子元素，但仍然“足够”或具有灵活的高度，则其中包含的水平对齐元素将“换行”以形成其他元素，不受欢迎的元素行 - 以及不需要的表现效果。图1和BugMeNot网页显示了错误包装的示例。在较宽的窗口（第1j部分），放大镜按钮出现在搜索框旁边。然而，随着窗口变窄，按钮会包裹到下一行（第1i部分）。

3 实证评估

为了评估我们技术的有效性和效率，我们将其应用于生产使用的26个真实网页，最终目的是回答以下三个研究问题：

RQ1：我们的算法在检测故障方面的效果如何？

我们的算法在响应式设计页面中检测常见类型的响应式布局故障的效果如何？

RQ2：使用“spotchecking”工具可以检测到多少次故障？

在窗口大小调整工具的帮助下，与我们的方法相比，“抽样检查”过程的效果如何？

RQ3：应用于响应式设计的网页时，我们的技术需要运行多长时间？

对于将在实际的RWD网页开发过程中应用该技术的开发人员来说，检测布局故障的时间是否合理？

RQ1：表1b使用每种检测算法分解了ReDeCheck针对每个网页生成的故障报告的分类。我们的每个算法都发现了TP（即实际的RLF），26个受试者中有16个至少有一个TP。鉴于对象是包括Duolingo和StumbleUpon等已建立的商业运营的实时和运营网站，这是一个令人信服的结果，因为我们推测，这些网站将进行内部测试过程，错过了由ReDeCheck。我们的算法报告的五个故障是我们用于激励示例的故障。这些故障是消费者端口离屏突出的内容示例（图1a，算法2检测到）；表单元素相互遮挡，降低了MidwayMeetup的功能（图1c，由算法1检测到）；导航链接由于其父元素为PDFescape的突出而消失（图1e，也被算法1检测到）；为Cloudconvert打破媒体查询和模糊布局（图1g，由算法3检测），以及BugMeNot的包装元素（图1i，由算法4检测）。

TP的进一步分析显示，这些报告总共汇总了33个不同的故障，如表1b的“Distinct RLFs”栏所报告，从而揭示了ReDeCheck结果的重复程度。一个极端的例子是Accountkiller。在这里，由算法3生成的147个小范围报告是TP，但更仔细的分析显示所有报告都对应于单个明显的故障。该页面涉及图标网格，每个图标对应于rRLG节点，其中对齐约束连接每对。对于一个小窗口范围，ReDeCheck检测网格中未按一致排列的元素，导致相对对齐的变化和一些小范围约束，这些约束导致算法触发每个单独的故障报告。另外，可以通过不同的算法检测相同的不同故障。例如，对于Cloudconvert，元素仅在小范围内发生碰撞，从而触发算法1和算法3的报告。

RQ2：Spotcheck分析显示我们的方法已经发现RLF作为RQ1的一部分，但没有新的额外故障。表2报告了在每个工具建议的窗口宽度之一处或通过随机选择窗口宽度而显示的这些不同RLF的数量。如表所示，工具显示了66％到81％的这些故障，具体取决于他们建议检查的窗口宽度集。由于这些预设宽度对应于常用设备，因此该结果显示ReDeCheck能够显示将在这些设备上显示的故障以供用户查看。尽管点测工具提示了检查网页的窗口宽度，但仍然需要手动识别故障——相比之下，Re-DeCheck减轻了开发人员的一些努力。结果还表明，我们的技术确定的故障率为19％至34％。即使使用了所有的抽查工具，并通过一定程度的进一步随机抽查来补充，我们的方法最初确定的五种不同的RLF也找不到。

RQ3：图3显示了ReDeCheck在30个试验中每个网页的执行时间中位数。几乎所有页面（26个中的25个）都是由我们的工具在中位数大约三分钟内处理的，15页需要60秒或更少。 Airbnb花了将近4.5分钟——但它是最复杂的对象页面之一，如表1a所示。一般来说，图表显示，花费最多时间的对象要么是最复杂的一部分（即，就CSS元素而言是Airbnb，而在CSS声明方面是Duolingo），或者产生最多的问题（即Accountkiller和PepFeed），因此，在捕获故障屏幕截图和生成带注释的图形报告（针对TP，FP和NOI）或者网页复杂性和报告的问题数量（即，ConsumerReports）的混合时，会产生额外的时间成本。

4 结论以及未来工作

响应式网页设计（RWD）倡导创建具有跨多个窗口宽度的增强用户体验的网页[32]。由于根据RWD原则[20]实施网页具有挑战性，我们之前的工作提出了一种回归检查技术，该技术比较了页面的两个模型并提出了任何差异[40]。专注于处理与检查响应式网页的问题正交的问题，其他先前的工作（例如，[17，18]）没有采用设计用于检查多个窗口的Oracle。相比之下，本文的自动化方法利用隐式Oracle信息来检测响应式布局故障。实验表明它是有效的：在8个网页中发现2个或更多的故障，它在一个网页中发现了6个故障，在26个对象中检测到总共33个不同的故障。

致谢

此文由*京大南**学软件学院2016级本科生虞圣呈翻译转述。