Tag: 软件测试

iOS自动化测试：Xcode UI测试入门

如何编写iOS自动化测试？ 如何使用Xcode UI测试框架通过Screen Object Pattern编写可靠且可维护的测试？ 阅读本文以了解答案。 XCUITest框架简介 第一步，我们需要选择自动化框架。 在本教程中，我们将利用XCUITest Framework。 一个允许测试用户与屏幕实际交互的框架。 它由Apple开发，为用户界面和集成测试提供了强大的功能。 设置Xcode项目以进行UI测试 Xcode UI测试要求访问应用程序源代码，并且必须在计算机上安装Xcode。 首先，我们需要创建UI测试目标： 打开Xcode项目 文件>新建>目标 选择iOS UI测试套件 输入您的组织信息并选择一种编程语言（本教程中将使用Swift） 使用XCUI Test Recorder编写第一个测试 XCUI Test Recorder允许我们记录用户与屏幕的交互并在测试中使用生成的代码： 导航到测试导航器 选择要记录的测试功能 按下UI记录器按钮 在设备上执行测试 为了完成我们的测试，我们应该添加断言来进行验证，以确保预期元素显示在主屏幕上 //预期显示的元素 让玩家= app.collectionViews.staticTexts [“测试”] //声明该元素已显示 XCTAssertTrue（player.exists） 使用辅助功能检查器检查元素 XCUI测试记录器非常适合简单的测试，但是记录器生成的代码需要修改，有时它不能为Element提供正确的定位器。 更好的方法是使用辅助功能检查器： 开放辅助功能检查器 单击开始检查按钮 检查元素以定义定位器 当我们知道Element调试描述时，我们可以根据该值编写Locator： 让playerBalance = app.staticTexts [“ $ 99.999”] 获取屏幕调试描述的另一种方法是在Xcode控制台中打印可访问性层次结构： print(app.debugDescription) 屏幕对象模式简介 在编写用户界面和集成测试时，我们希望使用可读代码创建可维护的测试。 […]

iOS自动化测试：并行运行测试

如何通过在物理设备和模拟器上并行运行来减少测试执行时间？ 如何使用屏幕截图生成测试报告并通过命令行界面运行测试？ 阅读本文以了解答案。 Xcode UI测试简介 本文是5月6日我文章的延伸，我们在那里学习了如何为您的项目设置XCUI框架并开始使用Swift编写Xcode UI测试。 进行检查以使您对该主题更加熟悉。 Fastlane工具入门 Fastlane是功能强大的开源工具，将帮助我们通过命令行界面执行测试，以及为我们提供测试，构建，签名和部署库的集合。 首先，我们需要安装它们： 打开终端 执行[sudo] gem install fastlane -NV 导航到您的项目目录并运行fastlane init 输入4以选择手动设置 等待安装完成 现在，我们已经安装了Fastlane工具。 您的项目中应该具有创建了Appfile和Fastfile fastlane目录。 通过命令行执行测试 为了在Continuous Integration Server上运行测试，我们需要通过命令行界面执行它。 此任务有多种方法，在本教程中，我们将使用Fastlane Scan操作。 让我们进行设置： 导航到创建的fastlane目录cd fastlane/ 在文本编辑器（例如Atom）中打开Fastfile 根据您的项目方案名称设置方案 指定测试设备 车道：test do 扫描（ 方案：“ BoardBank”，＃项目方案名称 clean：true，＃测试执行前清理项目文件夹 设备：“ iPhone 8”＃用于测试的模拟器 ） 结束 恭喜，我们已经成功配置了项目以执行测试，而Fastlane工具将为我们完成其余工作。 要运行测试： 执行快速fastlane test 等待测试执行 您将在fastlane/test_output目录中找到生成的HTML和Junit报告。 改善测试报告 Fastlane仅允许生成简单的测试报告，其中不包括屏幕截图和设备日志。 […]

领iPhone Beta指南

欢迎使用Collar iPhone beta版程序！ 在下面，您将找到安装应用程序的分步指南。 如果您尚未收到邀请，请发送电子邮件至support@collar-technologies.com，以表明您对iPhone版Collar测试版计划感兴趣。 收到电子邮件后，我们将向该计划发送邀请。 收件箱中应显示加入iPhone彩色测试版计划的邀请。 点击“在TestFlight中查看”按钮以打开应用程序。 这将在您的Internet浏览器中打开一个窗口，该窗口将提供代码以在TestFlight应用程序中兑换，以下载iPhone版Beta版Beta。 从应用商店下载TestFlight。 此应用程序将使您能够下载和安装当前处于Beta版的应用程序。 导航到TestFlight应用程序，然后点击右上角的“兑换”。 输入并提交代码后，“ iPhone版领”测试版应出现在您的应用列表下方。 您现在就可以开始测试了！ 请向support@collar-technologies.com提交任何问题或反馈。 如果您想在使用应用程序时记录屏幕以提供更详细的反馈，我已提供了以下步骤。 1.将iPhone插入计算机 2.打开QuickTime Player 3.解锁iPhone，然后从文件下拉菜单中选择“新电影录制” 此时，您应该看到一个反映iPhone屏幕的窗口。 单击记录并开始使用该应用程序。 您还可以在使用该应用时随时提供评论。 完成后，保存文件并将其发送到support@collar-technologies.com。

测试Marvel的View Code项目..具有100％的代码覆盖率！

在项目中采用视图代码确实可以帮助它变得更加模块化。 几周前，我写了一篇文章，展示了如何迁移使用情节提要+ xibs构建的Marvel项目来查看代码，您可以在此处进行检查。 在那篇文章中，我描述了这样做的一些好处，其中之一就是与测试有关。 视图代码更易于测试，因此，当您采用视图代码时，您的测试服会越来越多。 今天，我将展示如何为项目编写测试以及在此过程中进行的一些重构。 您可以在此处通过测试检查存储库。 **这个Marvel的项目是在一系列的帖子中创建的，如果您错过了查看的话。 为什么测试更容易？ 首先，查看代码使您可以控制代码的初始化过程。 这似乎没什么大不了，但请相信我。 现在，您可以编写一个与给定类型一起使用的自定义初始化程序，这有几个好处： 您可以在测试环境中使用setter注入，例如，提供伪造的实现（模拟）而不是真实的实现。 这可以帮助您独立运行测试，稍后再介绍。 现在，您可以控制初始化过程，您可以使用let删除一些可选参数并将变量定义为常量。 语义上更正确，比方说您正在创建角色视图控制器。 现在，您可以强制要求有人在视图控制器初始化过程中提供字符，这很有意义。 经过所有的重构和测试编写，我设法将应用程序的代码覆盖率提高到100％ 。 代码覆盖率本身不应达到某个特定数字。 而是应将其用作地图，该指南显示了可以在项目中改进的地方的提示。 在某种程度上，代码覆盖率的真正价值是回答这个问题， 接下来我要测试什么？ 以同样的方式，您的测试应用于重构代码并使之更好。 更好的代码意味着： 更具模块化 更可重用 封装好 明确而单一的目的 易于开发的代码 易于维护的代码 测试之所以能够帮助您“使代码变得更好”，是因为它们使您可以从接口的角度来了解代码的调用者。 如果要在后台做很多事情，通常很难测试，因此需要重构。 有无视图代码..！ 现在，让我们将在早期版本的项目中使用Storyboard + xibs进行的测试与在该版本中的视图代码进行比较。 这将使我们能够检查两种方法之间的好处和区别。 使用Storyboard进行CharacterViewController测试 使用查看代码的CharacterViewController测试 您现在可以看到，使用视图代码，我们可以摆脱以前用于获取视图控制器的许多样板代码。 以前，我们无法控制初始化过程，因此我们必须从情节提要中恢复它，并重复相同的旧配方。 好吧， 不再了！ 第二个版本不需要测试不是从视图控制器给出字符的情况，因为现在它是init进程的参数，这意味着如果有人想要一个CharacterViewController，他们将需要为该字符提供一个字符。在里面。 CharactersViewController测试.. 现在我们可以控制视图控制器的初始化过程了，我们可以将apiManager作为视图控制器的参数来提供，使设置器注入变得轻而易举，同时使用let可以将控制器中apiManager的变量保持不变。 在没有视图代码的先前版本中，我们必须将其保留为var进行注入，将其返回时我们无法控制初始化。 没有查看代码.. 与查看代码.. 能够控制初始化过程是如此重要，它使您可以更好地控制代码！ 您可以使用下面的视图代码检查对CharactersViewController的改进测试。 CharacterTableCell规格.. characterTableCell测试也得到了极大的增强，没有视图代码，我们不得不使用cellForRow方法从数据源中恢复它，这意味着我们不得不重复同样的方法，从情节提要中加载视图控制器。 不再！ […]

iOS测试的一些有用的提示和技巧

在为iOS开发的那些年里，我一直不愿意在我的应用程序上使用测试。 我不认为这是必要的，并且还认为这样做会浪费我的大量开发时间。 但是，反复进行手动测试和错误修复使我有了新的工作机会。 结果不只是正面的，但我不得不承认，开始并不容易。 由于这是进行开发的一种新方法，因此在编写代码之前，我们必须更改思维方式。 在这篇文章中，我将告诉您我们如何在LateralView中工作，为我们开发的应用程序创建测试。 工具类 Xcode有自己的框架来编写测试，但是我更喜欢使用一个友好的库来促进BBD。 它的名字叫Quick，它是Swift和Objective-C的一个行为驱动的开发框架。 我用于测试创建的另一个工具是OHHTTPStubs，这是一个旨在非常轻松，非常有用地对网络请求进行存根的库。 要测试什么？ 添加到模型中的每个功能都是测试的目标。 特别是，我喜欢从用户的角度测试动作的完整行为。 这就是BDD所讲的，这也是我创建测试所依赖的过程。 按照这个原则，我不会测试激活按钮的特定功能，而是在用户按下按钮后测试应用程序的最终状态。 改变我们开始开发应用程序功能的方式非常重要。 总是最好： 编写测试 执行测试 等待测试失败（因为尚未编码解决方案） 编码解决方案 为测试编写足够的代码以使其正常工作 如我之前所说，BDD的主要思想是测试应用程序的行为。 这意味着我们将不匹配函数的结果或模型对象的属性。 相反，我们将专注于为用户提供可见和有形的元素。 我们将根据用户在应用程序上的实际响应以及响应后的最终状态进行测试。 斑点结构 BDD为编写测试提出了一种更具叙述性的语法。 第一组测试是Spec，通过使用Quick，其结构如下： 对于测试用例的语法，更重要的块是它 ， describe和beforeEach 。 它的功能是代表接受标准以验证所需的最终状态。 describe块使我们可以指定场景并将测试序列分组。 例如，可以将它们分组，因为它们共享相同的初始设置。 此设置可以写在另一个重要的块中： beforeEach ，这是将在每个代码之前执行的代码，并包含第一个describe所包含的describe块。 有关“快速”功能的更多信息，请转到“带有快速示例和示例组的有组织的测试”。 期望功能是负责验证期望结果的功能，它将向我们显示测试是否成功。 如果您想了解更多关于Expect函数的用法，请查看Nimble的github。 一个例子 在此示例中，产品所有者请求一个带有电子邮件和密码输入的登录屏幕。 它应确认电子邮件有效，否则应在标签中显示错误消息。 它还具有一个导航到“注册”屏幕的按钮。 这是一个非常基本的示例，但足够有趣，可以从测试和BDD领域入手。 在beforeEach块（1）中，我们编写代码以初始化将要测试的导航控制器和视图控制器。 第一个测试是应该显示错误消息的测试，如描述所指示（2），我们模拟用户按下登录按钮而不填写电子邮件字段。 然后，在it块（3）中，我们使用断言来演示应用程序的行为。 在此示例中，我们希望标签的文本等于“无效的电子邮件”。 另一个简单的示例是测试，该测试包括在发生某些情况后导航到另一个屏幕。 在这种情况下，我们希望应用程序在用户按下注册按钮（4）之后进入注册屏幕。 为此，我们在beforeEach函数中模拟按钮的TuchUpInside事件。 在it块中，我们必须使用类匹配器beKindOf断言topViewController等于期望的类（ […]

Swift中的TDD简介

我的第一篇英文著作，所以开始吧begin 在本文中，我将尝试向您介绍TDD（测试驱动开发）。 那是什么 TDD是一种软件开发技术，仅要求您先编写测试，然后编写实际代码才能通过您之前编写的测试。 如果您的代码必须处理其他情况，或者要向软件中添加新功能，或者要修复该错误，那就很简单。 只需再次编写不同的测试，然后编写代码以再次通过该测试。 因此，如果您实施TDD，则您的开发周期将像这样 编写并运行测试 编码 重构 重新运行测试 如果您的开发阶段尚未完成，请返回第一。 使TDD更快捷 在您的Swift项目（iOS应用程序或macOS应用程序）中实现TDD非常简单。 您将只编写从XCTestCase类继承的类，定义您的测试用例，然后运行该测试。 我将向您展示如何进行测试，在本示例中，为简单起见，我将使用Xcode Playground进行所有这些测试。 在此示例中，我将创建解决该简单问题的算法。 您是游戏开发人员。 您将构建一个简单的格斗游戏，其中涉及2名战士互相斗殴。 每个战士都可以攻击他的对手，并拥有生命力计和伤害力。 如果战斗机受到攻击，他的生命量将因对手的伤害力而减少。 示例对象 塞纳570 60 RKO 510 65 第1栏是战斗机的名称，第2栏是战斗机的寿命表，最后一个是战斗机的伤害力 步骤1 定义战斗机 为了使您的代码通过该测试，您必须在Player类上修改attack(opponent:) 霍雷！ 您的测试已通过

使用Fastlane生成CircleCI测试摘要

创建人： Jeremy Sherman 持续集成的核心是运行测试。 每当测试失败时，您都想知道为什么要尽快解决，以便您进行更正。 每当CI构建失败时，您都希望查看失败的测试及其失败方式。 CircleCI的“测试摘要”功能将此信息放在首位，因此您可以直接响应测试失败，而不会遇到任何麻烦。 诀窍是按预期方式为CircleCI提供测试信息。 构建日志可能很好启动。 您展开失败的步骤，滚动到页面的末尾，然后向上滚动直到遇到测试失败。 这还不错。 首先。 但是，对于一个足够大的项目，构建和测试日志会变得太长而无法在网页上就地查看。 然后，您会发现自己先下载了日志文件。 有时，失败的测试实际上并不是在文件末尾附近。 然后，您会四处寻找它。 在一个长期项目中的许多开发人员中，这段时间和精力加起来。 如果要构建iOS应用程序，并且将粘贴的示例配置复制并粘贴到CircleCI上，那么您应该会感到幸运。 但是，在以下情况下，您将希望更好地了解“测试摘要”功能正在寻找什么： 您的测试摘要会省略您想要的信息，例如棉绒输出。 测试摘要不适用于您，您想修复它。 您不是在使用Fastlane构建iOS应用，其他示例配置之一无法满足您的需求。 CircleCI的“收集测试元数据”文档指出了一件大事： 使用JUnit的XML格式报告测试。 store_test_results步骤参考引用了另一个： 您的测试报告应位于另一个“所有测试”目录的子目录中。 此子目录名称用于标识测试套件。 不过，还有一个要求是我从未在任何地方看到过文档： JUnit XML测试报告文件必须在字面上具有xml扩展名。 对于测试摘要，文件名的其余部分似乎无关紧要，但是如果您使用错误的路径扩展名，则不会看到任何测试摘要。 您将得到一个目录布局，例如： /用户/蒸馏器/项目/ └──快车道 └──test_output └──xctest └──junit.xml3目录，1个文件 这打勾了所有框： XML文件： junit.xml “测试套件”目录： xctest “所有测试套件”目录： test_output （Fastlane仅生成单个测试报告，因此，“在文件夹中报告”的嵌套看起来有点愚蠢。） 扫描提供了许多配置旋钮。 您可以通过运行fastlane action scan查看完整列表的表及其默认值。 我们需要安排三件事： 报告格式：JUnit 报告文件名：junit.xml 报告文件应写入的目录：fastlane / test_output […]

测试，测试，1、2、3，测试

我是卫斯理大学（’18）的计算机科学和戏剧双专业，整个暑假都在Flatiron学校（FS）学习。 由于我一生都是学生，所以我习惯于进行测验，学习测验，在测验前拖延，以及受到测验的情绪影响（无论好坏）。 我认为大多数人都可以同意的事实是测试很糟糕。 但是，就编码而言，从长远来看，测试可以节省时间和金钱，并且可以产生更完善，更完美的应用程序。 要进行大量测试，对于一篇博客文章而言，测试太多了，但让我们对其进行分解。 我们都很熟悉XCode向我们提供的红色或绿色小菱形，其中包含支票或’x’。 我们都看着颜色从红色变成绿色，有时又回到红色。 最后，我们全都翻了个白眼，甚至在看到红色的眼睛时甚至撞到了墙上，而在看到绿色的眼睛时就为喜悦而跳了起来。 作为程序员，成功是保持我们编码的动力。 小小的成功是使头脑振奋值得的。 想象一下，如果等到所有编程完成后才知道代码是否按预期进行编译和运行，您会头疼。 这就是为什么测试是一种绝妙的做法。 测试使我们能够构建声音产品并对其功能进行检查。 对于新编码员，养成优雅的习惯很重要。 测试是一种习惯，可能会改变您对编程的看法。 编写测试可能有些繁琐，因此尽早开始很重要。 您越早开始编写和练习进行测试，就会越好。 测试方式 这是几个不同测试选项的简要说明。 Specta和Expecta是不错的选择，因为它们不需要您输入返回类型，并且可读性强。 “总体Specta和Expecta使得语法更加简单，易于编写和阅读。 这直接转化为开发人员的生产力” （ Harry Hornreich ）。 XCode提供了一个测试构建框架，使编写测试更加容易。 XCode框架很好，但是IMO最多不过是万不得已，因为它总比没有好。 XCode框架的问题在于，无法知道您正在包括最有意义的测试。 有很多UITesting工具（例如XCode）作为唯一的测试源都不可靠。 有意义的测试 测试有各种形状和大小。 编写测试可能并不像提出测试那样困难。 例如，假设我们在Pig-Latin中编写代码字。 “ in”和“ as”之类的词保持不变。 如果程序员不熟悉该语言，则他们可能会忽略此细节，并让其代码返回“ niay”和“ saay”。 或者，他们可能会记住该规则，却忘记了以元音或以“ sh”或“ ch”开头的单词在其中辅音必须保持在一起的单词的规则。 这种代码中有太多的出错机会，这就是为什么使用测试有益的原因。 如果没有遵循的准则，没有规则，那么如何使程序员避免使程序充满错误？ 测试的目的是消除运行时错误（与语法等编译器问题相对）。 测试不是为了弄清楚如何使用内存空间，也不是为了提高速度和效率。 测试以二进制形式进行：您通过或失败，直到通过。 有被迫失败的事情。 强制失败用于指示代码是否朝着不应执行的方向行进。 如果存在某种情况，您担心会发生并且不希望发生，那将是包括强制性失败的充分理由。 右BICEP Right-BICEP是我经过多年编程学习的一种助记符设备。 Right-BICEP是考虑编写代码的绝佳方法。 正确是指检查结果是否正确。 […]

并行测试：更早获得反馈，更快发布

作为负责测试Azimo iOS应用程序的唯一人员，我遇到了各种问题。 当我四年前开始在Azimo工作时，测试是100％手动的。 一个完整的测试周期最多可能需要两天的时间。 某些功能根本没有经过测试，更不用说在不同的设备和操作系统上了。 如今，只有15％的测试是手动的。 自动化使我们更快，更高效。 在2018年，我们99.9％的用户没有崩溃。 但是，由于我们应用程序的复杂性，整个测试周期大约需要八个小时。 这段时间的一半以上是由自动化测试占用的。 鉴于我们每周至少发布一次，因此我们需要找到一种方法来进一步缩短测试周期。 幸运的是，6月5日，一场革命来到了。 在WWDC 2018大会上，Apple宣布支持Xcode 10中的并行测试。这将我们250项自动测试的周期减少到大约55分钟，使我的生活压力减轻了很多。 在本文中，我将指导您了解并行测试的好处，因为我们在Azimo上已经体验过它们。 我将概述测试内容，机器配置方式以及遇到的问题。 我还将提供一些技巧，以帮助您充分利用并行测试。 在Xcode 9中为iOS设备引入了并行测试。从那时起，我们就能够在不同设备上并行测试不同的类。 但是，Xcode 9版本要求我们使用带有适当参数的命令行。 Xcode 10的革命性功能是自动化测试器-能够直接从Xcode级别在多个模拟器上同时运行不同的测试类，而无需人工测试。 就像启用该功能一样简单： 在这种模式下，Xcode将创建同一模拟器的多个克隆（例如，如果我们使用iPhone X模拟器，则Xcode将创建模拟的iPhone X克隆）。 这仅适用于模拟设备。 我们将在本文后面讨论物理设备上的并行测试。 好处： 简单直观的配置 更快的测试执行 更快的反馈 允许更多版本 同时检查多台设备上的应用程序服务器（请求，超时等） 无需创建其他测试目标，即可在它们之间分配测试类 与CI完美集成 缺点： 如果后端服务器/应用程序服务器不稳定，则可能发生超时（同一时间的多个请求可能会导致更长的响应） 保持模拟器稳定所需的大量处理能力 脱皮-如果发生上述任何问题 克隆相同的设备/系统配置，无法同时在几种不同的配置上进行测试（我们必须使用命令行） 假设： 使用并行测试必须满足的基本条件是测试用例的独立性。 例如： 我们不能仅在测试A完成后才开始依赖测试B 更快的执行速度或测试B的结果不会影响测试A的结果，反之亦然 有用的参数： maximum-concurrent-test-simulator-desstinations NUMBER要在同时启用并行测试 的情况下测试的模拟器目标的最大数量YES | NO覆盖方案parallel-testing-worker-count方案中的每个目标设置NUMBER确切的测试数量并行测试期间将产生的测试运行程序maximum-parallel-testing-workers编号并行测试期间将产生的最大测试运行程序数 有效的测试划分 […]

测试可观察的dengan RxTest

Setelah merefresh bagaimana caranya memakai RxSwift untuk keperluan开发iOS，supaya tidak lupa dan空白。 Saya sekalian aja belajar bagaimana melakukan testing可观察的memakai RxTest。 在UICollectionView中无限滚动UICollectionView UIAPIView的内容，并在API API dari Pokeapi中显示。 Jadi，Yang akan di test，apakah data pada集合视图akan bertambah sebanyak 20项目，setiap menyentuh akhir dari UICollectionView 。 Misalkan saya punya视图模型sederhana seperti ini 拜克拉（Baiklah），北穆莱（kula mulai）buat kasus ujinya dulu，塞德拉（sederhana saja）… 事件：-（0，（））-（100，（））-（150，（））-（200，（））-（250，（））—>预期结果：5 * 20项= 100项 好吧，bagaimana langkah […]