用 Appraise 自动化视觉测试

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

在开发界面外观是成功关键的应用程序时，自动化视觉测试会带来很大的帮助。Appraise 是在麻省理工学院授权的 GitHub 上的一款开源工具，它将实例化需求的应用于视觉方面。它帮助团队使用视觉检查来审查审批对 web 页面的更改。

Appraise 的创始人 Gojko Adzic 在 2018 年欧洲测试会议上发表了题为“无痛视觉测试”的主题演讲。InfoQ 采访了 Gojko，讨论了视觉测试的难点是什么，并询问了他一些关于 Appraise 的问题。

InfoQ: 在测试可视化时，测试人员经常会遇到什么问题?

Gojko Adzic: 从历史上看，测试应用程序的视觉方面需要人的眼睛和人的判断。这使得视觉测试变得昂贵和缓慢，所以有好的启发式方法来实现适当的覆盖率是非常重要的。

对于视觉效果，通常很难表达怎么算是正确的。有人可以设计很多特定的检查，比如元素大小、定位和样式，但是屏幕上的整体组合可能仍然是错误的、怪异的或者就是很难看的。虽然人们可以很容易地发现什么东西有问题，但因为很难表达预期的结果，所以传统的自动化并不是很有帮助。

即使预期的结果是明确定义和确定的，测试可视化常常需要构建和部署应用程序的整个堆栈，从而使测试变得缓慢而脆弱。

InfoQ: 测试人员如何处理这些问题?

Adzic: 一个常见的解决方案是在用户界面下尽可能地自动化，让人们把精力集中在剩下那些需要肉眼的部分上。由于用户界面自动化往往是缓慢而脆弱的，软件团队倾向于将功能从外观和感觉上分离出来，并尽可能地在可视化界面下进行测试。为此，Mike Cohn 率先提出了著名的测试自动化金字塔，它在今天的软件测试自动化中非常有用。

对于业务应用程序或企业软件来说，这很有效，因为用户界面并不是其真正的特别之处。但是在界面外观是成功关键的应用程序中，这个庞大的任务仍然摆在开发团队的面前，团队并没有很多处理此类问题的技巧和实践。从技术上讲，有很多工具可以检查应用程序的视觉方面，但是把人排除到这个方程式之外仍然是不可能的。

在做 MindMup 的时候，我们最终解决了这个问题。因为它是一个消费者应用程序，而且用户群的大部分都是学龄儿童，视觉和界面外观对整体体验至关重要。我们是一个构建、支持和维护应用程序的小团队。随着代码库的增长，测试视觉效果所需要的时间确实会带来负面影响，使我们无法抽身去做新的特性。我们有大量的自动化测试，甚至对应用程序的大部分可视化方面进行了测试，这些测试都是使用浏览器内的测试来检查 DOM 元素的，但是这些测试很难维护。

例如，改变一些常见的思维导图可视化风格，如字体或页边距，会导致数百个测试中断。每一个测试用例都是确定的，给我几个小时和一个计算器，我可以很容易地计算出新的期望状态，但是我更愿意把时间用在改进产品上，而不是修改测试用例。当然, 我们可以抽象这些东西, 设计更小的单元测试, 不依赖于真实的视觉界面外观的样式, 但是如果有些东西没那么怪那么丑，那么这种方法也验证不出什么，所以我们仍然需要审查最终可视化结果, 这花了很多的时间。

事实上，因为其他的测试都很脆弱，我们最终会有一打左右的思维导图来展示所有的关键界面外观，然后手动加载它们以验证看起来是否正常。如果存在问题，我们只是会从面向代码的测试中复制出实际结果，并为其声明新的期望值。

这让我们思考，我们如何能够加速这个过程，也许设计一个自动化流水线来帮助我们做视觉评估能让我们更快更有效地完成它。我们认为设计自动化测试的目的并不是为了取代人类，但是如果我们能够设计出一些自动化来帮助我们做这件事，就太好了。

人类在评估某样东西是否正常时很在行，但我们不需要参与收集所有信息的过程，所以我们开始将所有事情都自动化，除了最后的决定。我们构建了一个工具，它可以执行为应用程序设置的那些简单枯燥的工作来尝试许多不同的视觉测试用例，然后将它提交给我们进行审批。我们有了这个，就可以评审比之前多得多的案例了。而不是那十几二十个思维导图来帮我们在同一时刻检查很多东西的，我们可以围绕各个方面设计测试，让自动化部分仅仅呈现出不同效果，有那么点视觉单元测试的意思。

InfoQ: Appraise 是什么?

Adzic: Appraise 是我们为 MindMup 构建的工具，并最终开源，这样其他人就可以使用类似的方法来解决同样的问题了。

Appraise 采用了实例化需求的方法，但将其应用于视觉效果。我们举一些具体的例子，通过一个自动化层来创建可执行的规格说明，然后使用无头的 Chrome 来截屏，并将其与预期的结果进行比较。不同于通常的实例化需求的工具，我们无法认定预期和实际结果之间的差异就是错误，Appraise 采用了审批测试的方法。它把所有存在差异的地方显示给人类，让人来判定差异是否正确，如果是，就批准它。

批准失败的测试用例使实际结果成为下一个测试运行的预期，因此维护测试的成本就很低廉了。我只需按下一个按钮，而不是重新花时间计算 SVG 位置，就可以让新的屏幕截图成为我新的期望状态。因此，我们从有效的测试设计和自动化实例化需求的工具，以及对典型的批准测试的简单测试维护中获得了很多好处。这意味着我们可以快速地做大量的测试用例，并能很容易地管理它们。

Appraise 可以帮助团队肉眼快速审查审批对 web 页面、视觉布局和浏览器组件的更改。它的设计目的是使视觉语言的接受 / 回归测试自动化，而不是 xUnit 风格的代码，因此设计人员、测试人员、UX 专家和产品经理的跨职能组可以在测试中进行协作。

此外，通过采用具体的示例方法，评价团队可以通过可视化的例子创建易于维护的、可验证的开发人员文档。该工具使用 Markdown 作为可执行的规范格式，这意味着团队可以轻松地将其现存的文档发布到 Github 或作为静态 HTML 站点。

Appraise 是在麻省理工学院授权的，并且代码是托管在 GitHub 上。该产品的当前还是 alpha 版本。我要说的是，它对我们的用例非常有用，我们使用它帮助测试 MindMup 的界面外观，但是可能需要再打磨打磨才能对其他产品和团队工作流程有用。它目前仅限于 JavaScript 和在 Chrome 中运行，但要把它扩展到其他浏览器和运行时执行应该也不难。

InfoQ: 测试人员如何使用 Appraise 进行视觉测试?

Adzic: 它不是主要针对测试人员的工具，而是跨职能团队。人们可以从使用草图的可视化示例开始，无论是用手绘、线框图还是图形工具，然后对相关的例子、边界值和边界情况进行充分地讨论。这种讨论，就是 BDD 和实例化需求的真正威力所在。

然后把这些草图放入 markdown 文档来创建一个可执行的规范，这将成为一个半自动化的测试。然后，开发人员将构建这些特性和一些可能的测试夹具，类似于 FitNesse 夹具或 Cucumber 步骤，将这些示例联系到应用程序中。

Appraise 会运行应用程序，抓取截屏并剪辑它们，然后与预期的视觉效果进行比较。如果一切顺利，它就会什么也不提。如果发现有任何差异，就会将其抛出来请人来审批。当然，对于手工绘制的草图来说，测试最初会失败，但是我们已经把比较差异弄得很简单了，因此，用户体验设计师或产品专家可以评审并批准正确的内容，而这将成为下一个运行的基线。对于不正确的程序，开发人员在 Chrome 中使用典型开发工具很容易检查什么出错了，并修复它。

通过这种方式, 评价的目的是支持跨职能的对话和方便人们识别和评审的差异。

另一个可以用于视觉测试的工具是 Applitools Eyes。它使用模拟人眼和大脑的人工智能。在 Applitools Expands Application Visual Management Capabilities 中可以找到有关最近发布的更多信息。

有一些用于视觉测试工具还正处于发展阶段，例如 Chromatic 和 Screener。

查看英文原文： Automating Visual Testing with Appraise