iOS应用程序的自动UI测试

在充满竞争的世界中，公司希望比以往更快地发布其软件。 原因是他们很害怕。 害怕屈居第二或失去市场份额。 试图越来越快地做出决定，通常将单元测试定义为“稍后”。 开发人员无需测试即可创建大量代码，并且对此感到非常满意。 X天到了，该发布产品了。 由于该软件还不算太大，因此他们可以在发布期间进行手动测试。 这里没事！ 认真地说，手动测试很棒！

问题在几个月后开始。 在某些时候，手动测试花费的时间越来越长。 您的应用变得更加复杂，并具有更多功能。 此外，您必须检查回归。 这是他们先前的质量下降开始显现的地方。 发行周期突然不需要几个小时。 相反，它需要几个星期。 每两周发布一次，然后弹出一个问题：

测试使我们无法经常发布，该怎么办？

这是一个具有多个选项的好问题。 只需忽略减少测试工作量的想法即可。 这是肯定的办法。 另一种选择是从开发人员级别开始。 让我们添加单元测试！ 哎呀……既然我们忽略了它们，那么一开始，我们的代码就不是那么容易测试了……要花一些时间为单元测试添加基础。 那我们还能做什么？

在整个过程中，我们可以添加某种测试意识形态。 第一步是使用BDD进行此操作。 但是，这不会以快速而肯定的方式帮助我们。

如此众多的公司开始使用自动化的UI测试。 让计算机执行与手动测试应用程序相同的步骤。 我们可以每晚（或每次提交？）运行这些测试，这比让团队坐下来进行体力劳动要快得多。

在继续之前，让我这样说：

自动化的UI测试并不是解决问题的灵丹妙药！

但这是整个机器的齿轮。 因此，仅因为这不是您的灵丹妙药，不要完全忽略它。

iOS上有很多不同的方法。 有些是本地人，有些则更少。 让我们单独看一下。

XCUI测试

几年前，苹果公司停止了其JavaScript自动化框架，并用XCUITest代替了它。 这是Apple支持的本机库，这意味着您可以用Objective-C或Swift编写UI测试。

我必须缠住头的一件事是，您不必检查包含值的元素（标签，按钮等）。 而是，您检查屏幕上是否存在该值。 因此，在测试是否显示文本时，它看起来像这样：

  XCTAssert（app.staticTexts [“ Welcome”]。exists） 

XCUITest在其自己的进程中运行。 这既有优点，也有缺点。 它可以看到屏幕上的所有内容，但您无法检查内部应用程序的状态是什么。 这非常好，因为它可以防止开发人员犯涉及普通用户没有的知识的错误。 另一方面，处于单独的进程也意味着需要一些时间来同步应用程序状态。 这会花费时间并减慢测试速度。 此外，当执行一些需要时间的操作时，由于XCUITest无法找到请求的元素，因此可能导致错误。

要在失败之前等待一小段时间，我们可以等待元素出现：

 让goLabel = app.staticTexts [“开始！”]
 let exist = NSPredicate（格式：“存在== true”）
期望（对于：存在，评估对象：goLabel，处理程序：无） 

这将等待带有文本“ Go！”的元素。 如果在5秒钟之内存在，则继续测试。 否则，它将失败。

另一个常见的用例是与元素交互。 点击按钮非常简单：

  app.buttons [“添加”] .tap（） 

将文本写入文本字段是类似的：

 让textField = app.textFields [“ Username”]
 textField.tap（）
 textField.typeText（“ ”） 

让我感到困惑的最后一件事是系统对话框的默认处理。 如果弹出UIAlert，XCUITest将在短时间后自动选择默认按钮。 这样，您无需自动化诸如提供对用户媒体库访问的操作。

自从引入以来，每个Xcode版本都在不断进行改进。 最新版本添加了以下选项：

• 同时启动多个应用程序（查看它们如何交互）
• 热启动（将应用发送到后台并取回）
• 截屏
• 更好的异步测试

因此，即使您确定XCUITest不是适合您的工具，您也可能希望对其进行跟踪。

格雷伯爵茶

2016年初，Google发布了EarlGrey。 XCUITest和此UI自动化框架之间的区别是EarlGrey，该应用程序共享相同的过程。 在这种称为GreyBox的测试中，该测试会影响共享内存，从而更改应用程序的运行时行为。

Google在其Github存储库中提供了详细的设置说明。

让我们看一下它与XCUITest的比较！

测试文字：

  EarlGrey.select（elementWithMatcher：grey_text（“ Welcome”）） 

与按钮互动：

  EarlGrey.select（elementWithMatcher：grey_accessibilityID（“ Add”））。perform（grey_tap（）） 

将文本写入文本字段：

  EarlGrey.select（elementWithMatcher：grey_accessibilityID（“ Username”））。perform（grey_typeText（“ ”）） 

关于同步。 Google声称由于EarlGrey共享相同的过程，因此它确实负责同步。 尽管您可以访问它，但您可能不需要它。

阿皮

与XCUITest和EarlGrey相比，Appium有所不同。 它是跨平台的，您不必使用本机语言。 因此，其想法是让您的测试工程师或您以首选语言编写测试，并在所有受支持的平台上使用它们。 这可以将编写和维护测试的时间减少一半，因为在理想情况下，测试可以在Android和iOS上正常工作。 如果您曾经开发过支持两个平台的应用程序，那么您已经知道了结果。 这是不现实的。 而是，您为两个平台编写相同的测试。

最让我失望的是速度。 一个简单的登录测试：

1. 启动应用
2. 输入凭证
3. 按登录
4. 检查是否已登录

这花费了Appium 5（换句话说：五分钟）来完成。 在XCUITest或Appium上不到10秒（仍然很长的时间）就可以完成相同的操作。

其他选择

除了上面列出的以外，还有更多选项。 如果您想保持本机，可以选择KIF和Frank。 否则，如果您喜欢黄瓜，则有一个iOS版本支持葫芦。

在设备场上运行

有很多不同的设备场，但我认为，您应该坚持使用大型设备。 亚马逊就是其中之一。 遗憾的是，它还不支持EarlGrey。 另一个选择是Xamarin测试云。

这种情况一直在变化，因此与较小的测试云提供商相比，我在AWS方面的经验很棒。

结论

在使用了大多数工具之后，我会坚持使用XCUITest或EarlGrey，但这在很大程度上受到优先考虑。 XCUITest与AWS一起运行，但是由于其额外的过程和由此产生的同步工作，它的速度较慢。 另一方面，EarlGrey速度更快，但无法在AWS上运行。

掌握基础知识的速度非常快，而且在这些之间进行切换应该没有任何问题。 我仍然对执行速度和稳定性不满意。 想象一下有100个测试平均每个测试15秒。 您在25分钟时得到结果。 与一天进行5人人工测试相比，声音听起来相当快。 但是有更快的方法，例如无UI验收测试，我们将在以后的文章中详细介绍。

UI测试失败的原因有多种。 有时设备/模拟器处于错误的初始状态。 有时Xcode无法连接到应用程序。 通常在您的应用中这是错误的。 不管这些原因是什么，每次发生故障时都需要检查原因。 这可能很乏味，并阻止您进行其他工作。

由您决定在发布测试期间减少99％的时间是否值得在一天之内解决问题，每次构建/测试运行失败时都必须检查。

进一步阅读

• XCUITest作弊表
• EarlGrey备忘单
• 新的Xcode UITesting功能

上一篇：行为驱动开发

Next：在UI测试中模拟网络请求