Tag: Ui测试
推送通知用户界面测试
如果您曾经尝试过手动测试推送通知，则知道它们会很痛苦。 首先，您必须将应用程序加载到设备（而不是模拟器）上，通过应用程序流程，确保已关闭/打开应用程序，等等。能够自动执行这种测试不是很好吗？ 确保您的应用一般设置为推送通知（已启用权利，从开发人员门户生成的推送证书） 确保在运行UI测试时将您的应用配置为指向localhost：8080作为其域 您应用的info.plist必须在App Transport Security Settings NSAllowsLocalNetworking的App Transport Security Settings NSAllowsLocalNetworking 。 没有此设置，您的应用将无法连接到localhost域。 模拟服务器 这里有几个Swift服务器库。 有一些用于生产就绪的Web服务器（例如Perfect，Vapor等框架），但是我们想要的是轻便的东西。 我一直在使用Swifter（https://github.com/httpswift/swifter），但是您也可以尝试使用Embassy（https://github.com/envoy/Embassy）。 本文中的示例使用Swifter。 在我的UI测试目标中，我为模拟服务器添加了以下类： 如果将它分解成小块，这很简单。 它只有3种方法：1）启动方法2）清理方法，以及3）设置设备令牌端点的方法（在此示例中为/pushEndpoint ） 现在，确保将设备令牌发送到模拟服务器 设置应用 在您的代码中，几乎可以肯定，您有一个将设备令牌发送到远程服务器的功能。 您必须做的是确保在运行UI测试时，将此URL请求的主机设置为localhost:8080 。 实际上，您应该做的是1）运行UI测试时通过启动选项发送一个标志，或者2）设置一个表明您正在运行要切换到的UI测试的编译器标志。 为了简洁起见，我只是在下面的AppDelegate类中对/pushEndpoint的请求进行硬编码localhost:8080 ： 我们设置的最后一步是设置一种方法，以从测试运行程序发送推送通知。 从测试运行器发送推送通知 以下是我用于从UI测试运行程序发送推送的代码（将此代码放入UI测试目标中）： 如您在上面看到的，我们要做的第一件事是将为推送通知生成的证书加载到内存中（确保它是沙箱版本！）。 您应该将此文件添加到项目中，并确保它是UI测试目标的一部分。 之后，剩下要做的就是通过NWPusher库发送您的推送通知。 请确保您的通知格式正确。 样本推送通知有效负载可能如下所示： {“ aps”：{“ alert”：“测试消息”，“徽章”：1}} 当然，通知会比这复杂得多，但这只是一个示例。 运行测试 现在终于可以进行测试了！ 这是一个示例测试： 您会在上面的测试中注意到，我们同时利用了之前创建的模拟服务器和triggerPushNotification(withPayload:)函数。 如果一切顺利，您的测试应启动该应用程序，然后将其放在后台，然后将推送通知发送到您的设备，然后在UI测试上点击它！ 而且我们完成了！ 设置所有这些有点麻烦，但是我认为这是值得的。 测试推送通知始终是一件繁琐的事情，我觉得很多开发人员可能做得还不够。 有了像我们在这里介绍的那样的测试框架，在修改应用程序中的推送通知逻辑时，您可以更加放心。 一旦您的第一个测试启动并开始运行，别忘了测试应用程序的状态，例如被暂停，应用程序完全关闭并对不同的应用程序状态/视图做出反应。 但我会将其留给读者作为练习。 […]
iOS应用程序的自动UI测试
在充满竞争的世界中，公司希望比以往更快地发布其软件。 原因是他们很害怕。 害怕屈居第二或失去市场份额。 试图越来越快地做出决定，通常将单元测试定义为“稍后”。 开发人员无需测试即可创建大量代码，并且对此感到非常满意。 X天到了，该发布产品了。 由于该软件还不算太大，因此他们可以在发布期间进行手动测试。 这里没事！ 认真地说，手动测试很棒！ 问题在几个月后开始。 在某些时候，手动测试花费的时间越来越长。 您的应用变得更加复杂，并具有更多功能。 此外，您必须检查回归。 这是他们先前的质量下降开始显现的地方。 发行周期突然不需要几个小时。 相反，它需要几个星期。 每两周发布一次，然后弹出一个问题： 测试使我们无法经常发布，该怎么办？ 这是一个具有多个选项的好问题。 只需忽略减少测试工作量的想法即可。 这是肯定的办法。 另一种选择是从开发人员级别开始。 让我们添加单元测试！ 哎呀……既然我们忽略了它们，那么一开始，我们的代码就不是那么容易测试了……要花一些时间为单元测试添加基础。 那我们还能做什么？ 在整个过程中，我们可以添加某种测试意识形态。 第一步是使用BDD进行此操作。 但是，这不会以快速而肯定的方式帮助我们。 如此众多的公司开始使用自动化的UI测试。 让计算机执行与手动测试应用程序相同的步骤。 我们可以每晚（或每次提交？）运行这些测试，这比让团队坐下来进行体力劳动要快得多。 在继续之前，让我这样说： 自动化的UI测试并不是解决问题的灵丹妙药！ 但这是整个机器的齿轮。 因此，仅因为这不是您的灵丹妙药，不要完全忽略它。 iOS上有很多不同的方法。 有些是本地人，有些则更少。 让我们单独看一下。 XCUI测试 几年前，苹果公司停止了其JavaScript自动化框架，并用XCUITest代替了它。 这是Apple支持的本机库，这意味着您可以用Objective-C或Swift编写UI测试。 我必须缠住头的一件事是，您不必检查包含值的元素（标签，按钮等）。 而是，您检查屏幕上是否存在该值。 因此，在测试是否显示文本时，它看起来像这样： XCTAssert（app.staticTexts [“ Welcome”]。exists） XCUITest在其自己的进程中运行。 这既有优点，也有缺点。 它可以看到屏幕上的所有内容，但您无法检查内部应用程序的状态是什么。 这非常好，因为它可以防止开发人员犯涉及普通用户没有的知识的错误。 另一方面，处于单独的进程也意味着需要一些时间来同步应用程序状态。 这会花费时间并减慢测试速度。 此外，当执行一些需要时间的操作时，由于XCUITest无法找到请求的元素，因此可能导致错误。 要在失败之前等待一小段时间，我们可以等待元素出现： […]
XCTest样本
在本教程中，您将尝试执行以下测试操作： 在视图控制器中测试方法。 检查视图是否存在。 在当前状态下捕获屏幕截图 如果您遇到以下任何问题，可以在此处下载完整的源代码项目。 1.在视图控制器中测试方法 首先，您需要阅读以下来自Apple的文章： XC测试 为Xcode项目创建并运行单元测试，性能测试和UI测试。 定义测试用例和测试方法 将测试用例和测试方法添加到测试目标，以确认您的代码行为符合预期。 了解测试方法的设置和拆卸 测试运行前准备初始状态，测试完成后执行清理。 addTeardownBlock（_ 🙂 注册一个拆卸代码块，以在当前测试方法结束后运行。 测试期望的异步操作 验证异步操作的行为符合预期。 使用2个选项创建一个新项目，其中包括“包括单元测试”和“包括UI测试”已选中： 要在视图控制器中测试方法，您需要对其进行初始化。 在这种情况下，我们将通过UIStoryboard对其进行初始化。 将以下代码片段添加到您的DemoTests.swift文件中： 现在，您可以调用视图控制器的方法： 按Cmd + U运行测试 2.检查视图的存在 首先，您需要阅读以下来自Apple的文章： 用户界面测试 当执行预期的操作时，请确保您应用的用户界面行为正确。 XCUIElementQuery 用于查找UI元素的查询。 XCUI元素 应用程序中的UI元素。 XCUI应用 可以启动和终止的应用程序的代理。 首先，要能够测试UI元素，您需要启动您的应用程序。 将以下代码片段添加到您的DemoUITests.swift文件中 现在，您可以使用app变量查询UI元素： 按Cmd + U运行测试 3.在当前状态下捕获屏幕截图 首先，您需要阅读以下来自Apple的文章： 将测试分为具有活动的子步骤 在测试方法中创建命名活动以简化测试报告。 为测试和活动添加附件 使用附件存储测试的输出数据以供以后分析。 XCUI画面 连接到设备的物理屏幕。 XCUI截屏 屏幕，应用程序或UI元素状态的捕获图像。 要捕获当前状态的屏幕快照，可以使用以下代码片段： 按Cmd + […]
