Tag: 持续集成

Xcode Server 8提示和技巧: Xcode Server —苹果公司用于自动化软件静态分析，单元测试和构建归档的连续集成系统已经存在了一段时间，但它从未得到应有的重视。从历史上看，设置Xcode Server是一个相当繁琐且耗时的过程。这使得一些人放弃了与Xcode IDE无缝集成的所有强大功能，并可以替代现有的CI服务器。今年在WWDC的高级测试和持续集成会议上，Apple宣布了令人兴奋的功能和Xcode Server 8的改进。这些新的增强功能使Xcode Server 8成为您应该考虑在团队中设置的重要工具。在此博客文章中，我想分享一些在我们团队中设置Xcode Server时学到的技巧。我希望这些技巧将帮助您使Xcode Server成为开发团队可以依赖并从中受益的强大CI服务器。免责声明这篇博文不是分步教程，而是我在设置Xcode Server时学到的最佳实践的全面摘要。如果您正在寻找详细的分步教程，请查看Honza Dvorsky撰写的大量Xcode Server教程。另外，如果您仍然不确定自行托管自己的构建服务器以及为什么要在那里使用Xcode Server而不是其他CI服务器（云服务器或自行托管），请查看我之前的文章iOS / Mac开发的自行托管CI。。 TL; DR 专用于Xcode Server的分离机为集成用户创建专用用户帐户为集成用户创建专用的GitHub / Bitbucket帐户在项目中使用Bundler安装确切的Ruby gem和版本在Xcode Server上使用Ruby版本管理器来管理Ruby gem 始终在集成前触发器中安装和更新Ruby gems和CocoaPods 使用Buildasaur macOS应用进行拉取请求测试使用Fastlane部署在集成前触发器中执行的应用入门 Xcode Server是一项在macOS Server应用程序中运行的服务，其中包括FTP，Wiki，缓存等其他有用的服务。它可以从Mac App Store下载，价格为$ 19.99。但是，如果您已在Apple Developer […]

排名前五的Cloud iOS持续集成服务器奥运: iOS应用程序的持续集成（也称为CI）是我最喜欢的主题之一。随着iOS团队中开发人员的增加，持续集成对于每个iOS项目都至关重要。到目前为止，我对用于iOS项目的自托管CI服务器（如Xcode Server，TeamCity和Jenkins）具有深刻的经验。但是，市场上仍然存在着一系列基于云的CI服务，这些服务在最近几天变得越来越流行。这些基于云的CI服务有很多文章和推文。我热衷于尝试这些服务，并通过将它们与我最喜欢的个人项目结合使用来获得一些机会 XCFit 。为了做到这一点，我决定参加一场奥运会比赛，其中涉及大多数基于云的iOS持续集成服务候选人。目的除了TravisCI，我参加过的大多数服务都是我以前从未使用过的。对我来说，这将是个很好的机会，让我自己熟悉那些CI服务并使用我的个人项目XCFit比较它们。这次奥运会的目的是分享我对基于云的iOS CI服务的经验和第一印象。请注意，本竞赛的目的不是推荐您应为iOS项目使用的特定服务。竞赛的全部目的是尝试分享这些基于云的iOS CI服务的第一印象。免责声明：所表达的观点仅是我个人的观点，并不代表这个世界上任何其他人的观点或意见。此评估仅针对 XCFit 项目执行，并且可能因项目而异。奥运选手参加奥运会的选手是最常用的基于云的CI服务器，它支持iOS和macOS平台。当前列表中有这些球员 BuddyBuild 比特里斯 TravisCI 永不编码 CircleCI XCFit：游戏这项奥林匹克竞赛将与XCFit项目进行竞争，我们将使用该库来尝试上述CI服务的功能。这是我最喜欢的宠物项目XCFit之一，该项目是一个小型库，使我们能够以行为驱动开发（又称为BDD）的方式编写XCUITests。此项目是CI服务器测试的有趣候选者，因为它包括随CocoaPods和Carthage发行的Swift框架可以通过Swift Package Manager分发的Swift Package 使用Carthage构建的XCFit框架的示例应用程序使用RubyGems分发的Ruby包下载Xcode模板由于该项目涉及很多工作，因此有趣的是，看看所有这些基于云的CI服务器如何对待该项目以在各自的平台上运行构建。奥运田径奥林匹克运动会，我们将用于本届比赛的是注册和项目设置默认构建配置生成执行建立人工制品和测试报告真实设备测试构建定制并行化和并行构建建立管道基础架构即代码 […]

为iOS项目设置Travis CI: 在本文中，我将指导您为iOS项目设置Travis CI。什么是持续集成（CI）？持续集成是一种经常合并小的代码更改的实践，而不是在开发周期结束时合并大型的更改。目的是通过以较小的增量开发和测试来构建更健康的软件。开始一个新的XCode项目在GitHub上创建存储库准备好存储库后，将代码推送到存储库。测试xcodebuild命令 xcodebuild 干净的构建测试– 项目 Travis_CIDemo / Travis_CIDemo.xcodeproj – 方案 Travis_CIDemo – sdk iphonesimulator – 目标 “平台= iOS Simulator，OS = 12.1，名称= iPhone 6” ONLY_ACTIVE_ARCH = NO CODE_SIGNING_REQUIRED = NO 我们将使用此命令为travis-ci创建yml文件。 xcodebuild 要了解有关xcodebuild的更多信息，可以使用终端帮助进行详细的文档记录。在终端上，只需输入：男子 xcodebuild 特拉维斯CI 作为一个持续集成平台，Travis CI通过自动构建和测试代码更改来支持您的开发过程，并提供有关更改成功的即时反馈。 Travis CI还可以通过管理部署和通知来自动化开发过程的其他部分。先决条件 1.一个GitHub帐户。 2.托管在GitHub上的项目的所有者权限。 Travis CI入门 […]

如何免费为多个项目存储库配置TravisCI: Travis CI是针对Github存储库的出色托管连续集成服务。特别适用于快速测试。当我将Trabase CI与Firebase iOS快速入门挂钩时，我不得不实施一些技巧。因为我们， 1个回购中有多个项目，使用CocoaPods 1.0（默认值为0.5），在测试中将Google plist文件包含到每个项目中，更新每个测试项目的info.plist，跨虚拟机并行构建，缓存捆绑程序和依赖项（荚）。构建生命周期 Travis CI的构建包括两个步骤： install ：安装所需的任何依赖项 script ：运行构建脚本您可以在安装步骤（ before_install ）之前，脚本步骤之前（ before_script ）或之后（ after_script ）运行自定义命令。在before_install步骤中，您可以安装项目所需的其他依赖项，例如Ubuntu软件包或自定义服务。所以我在这里安装CocoaPods 1.0（默认为0.5）进入每个示例文件夹并安装Pod 复制到模拟的Google plist文件中使用sed更新Google plist和info.plist 将Google plist文件添加到每个目标中。（使用ruby和xcodeproj） -gem卸载cocoapods -a — gem install cocoapods -v’1.1.1′ — gem install xcpretty — cd $ […]

Bitrise上的Xcode 9代码签名: 最近，出现了一些新的代码签名问题，但问题已经解决，因此请在Bitrise上更新适用于iOS的Xcode存档和导出步骤，看看是否可行。如果不是这样，请参阅下面的说明和本文末尾的说明。您可以在几周前的“ Xcode 9中的新导出选项Plist”中阅读有关IPA导出选项的更改。由于IPA导出过程已解锁了一些新选项，因此Xcode会自动检测并处理其中的大多数选项，但是从Xcode 9开始，我们需要手动定义它们。第一个变化是，从此Xcode版本开始，我们需要为您的应用程序中的每个可执行目标列出，Provisioning Profile应该对其进行签名。 exportOptions中此属性的名称为provisioningProfiles ，在某些情况下，如果不定义此属性，您将收到以下错误： “Error Domain=IDEProvisioningErrorDomain Code=9 \”\”ios-simple-objc.app\” requires a provisioning profile.\” UserInfo={NSLocalizedDescription=\”ios-simple-objc.app\” requires a provisioning profile., NSLocalizedRecoverySuggestion=Add a profile to the \”provisioningProfiles\” dictionary in your Export Options property list.}” 用例：您正在尝试使用手动签名从存档中导出IPA文件。如果是自动签名（在导出过程中），则无需定义此属性。在用于建筑物的Bitrise虚拟机上，您无法使用凭据登录Xcode，这就是为什么您无法执行IPA自动导出的原因。但是，如果您使用“本地自动导出”并且Xcode为您生成了代码签名文件，则可以在Bitrise上使用这些代码签名文件来导出IPA。因此， Xcode Archive & Export for iOS为Xcode 9 Xcode Archive & […]

为什么需要在2018年将移动DevOps保留在内部: 最初发布在XCBlog网站上，请阅读原始博客以获得更好的图形！信不信由你，建立和管理DevOps工具是一项令人费解的活动。对于Web和移动应用程序开发都是如此。它需要对服务器和网络技术，具有复杂脚本的自动化，云技术和24 x 7监控支持的深刻理解。这使许多企业家，项目或计划经理感到头疼，以至于许多人选择将此流程完全外包给其他公司或使用基于云的提供商来处理。 DevOps活动成为Web和移动应用程序开发中的大人物。应用程序开发人员不具备处理DevOps工具的技能，并且拥有专门的DevOps团队对于企业而言过于昂贵，因为它不会直接产生业务收入。在这篇文章中，我们将看到为什么您急需在2018年考虑内部移动DevOps。是的，在2018年，因为您可能会受到新年开始时Apple购买的BuddyBuild的影响。希望在本文结尾处，您将看到使用内部移动DevOps的一些好处那么DevOps到底是什么呢？那是一百万美元的问题，简称为“没人知道”，也就是说，DevOps在任何地方都没有具体定义。关于DevOps的说法有很多。有人说这是一套工具，这是新的开发方法，是管理CI / CD的团队，是职务或职位，但没有一个是正确的。我对DevOps的理解非常简单，无论是接受还是抛出，但是我对DevOps的定义是 “您为加快免费软件发布的速度而采取的一切操守都被视为DevOps” DevOps庞大，有数百万篇博客文章，数千篇白皮书，数百本书籍，并且有新颖的作品来解释DevOps的概念。 OMG有一个名为“凤凰计划：有关IT，DevOps和帮助您的业务成功的小说”的小说，这个名字很长，但是它包含了DevOps的细节。我强烈建议所有想要了解DevOps的人员使用此工具。无需遵循针对DevOps实践的预定义流程，技术或工具，但是，DevOps在小说中提到了三个应该遵循的支柱，即系统思考，放大反馈循环，持续实验和学习。开发网站和手机应用程序是两项完全不同的活动。它们在技术，基础架构，流程，工具和技能方面各不相同，因此很难将两者融合在一起。结果，用于Web和移动设备的DevOps实践或工具也有所不同。管理Web和DevOps的技术和过程可以相同，但是工具上存在一些主要差异。我们将在这里介绍5个基本差异浏览器与设备 Web应用程序必须支持各种桌面/移动操作系统和浏览器，而移动应用程序必须支持具有多种变体的特定于平台的移动操作系统。移动应用程序的各种环境目标。移动必须支持多种变体。例如，iOS在iPhone，iPhone +和iPad变体上具有各种iOS版本。 App Store与托管服务器移动应用一旦发布，便托管在AppStore或Play商店中，但是Web应用需要在数据中心或云中托管服务器。如今，大多数Web应用程序都托管在AWS，Azure或类似的云中。 Web应用程序始终需要操作和监视，但是移动应用程序不需要监视托管，因为AppStore或PlayStore将负责托管。拉与推部署 Web应用程序始终具有推送部署，这意味着可以按需部署新版本的网站，并且用户无法选择接受或拒绝更新。但是，移动应用程序具有拉式部署，除非强制执行，否则用户可以选择是否更新到新版本。如果发布移动应用程序，则不会回滚。另一件事是，在移动世界中没有持续的部署，因为苹果或谷歌必须在发布新版本的应用程序之前等待几天才能批准应用程序。移动应用程序的发布比Web应用程序的风险更大。技术领域用于开发Web和移动应用程序的工具和技术存在主要差异。用于移动原生开发的编程语言是Swift，iOS和Java的Objective-C或Android的Kotlin。还有其他一些混合框架可用于一起开发Web和移动。但是，可以使用数百万种编程语言（例如Java，Ruby，PHP，Python，JavaScript等）来开发Web应用程序。平台之间的持续集成工具也相差很大。例如，詹金斯（Jenkins）是一种非常流行的工具，可以将Web应用程序部署到任何地方，但是对于移动持续集成而言，它并不总是一个好的选择。后端服务不幸的是，不可能将所有必需的数据放入应用程序中，因此Web和移动应用程序都依赖某种向其提供数据的后端服务或API。这些服务可能设计也可能不设计为同时服务于Web和移动应用程序，因此找出后端服务中的任何更改可能会影响到移动应用程序或Web应用程序或两者都必不可少。移动应用程序也需要单独注意。 […]

为iOS Release Train构建增量技术: XCBlog上的原始帖子在这里持续交付iOS应用对于保持在竞争市场中的重要性至关重要。拥有基础架构以在向客户发布功能后立即向客户发布功能的公司赢得了公司之间的竞争，他们必须从本地Xcode的人那里进行手动发布。在“持续交付”模式下，我们应该不断将iOS内部版本上载到iTunes Connect或TestFlight，以获取发布中涉及的所有技术人员和非技术人员的反馈。只要我们具有适当的构建和版本控制过程，将构建上传到iTunes Connects不会有任何危害。在这篇文章中，我们将看到在持续交付管道中自动递增内部版本号的最佳技术。在进入iOS应用程序的自动内部版本号之前，我们将了解将iOS应用程序提交到App Store时版本号，内部版本号和发行火车的工作方式。 Apple拥有有关每个iOS开发人员都应了解的版本号和内部版本号的出色文档。版本号和内部版本号的组合唯一标识一个应用程序向应用程序商店提交的内容。版本号 iOS应用的版本号与以前的版本不同。我们需要为新的应用发布创建单独的版本号。它类似于使用语义版本控制在Github上创建发行版。合法版本号将是1.0，1.1.1等，但是您不能将字母和数字（如abc.123）组合在一起，这将是非法版本号。版本号无法重复使用，因此您必须预先确定主要版本和次要版本。新版本号值必须大于以前使用的值，并且随后应递增。当前版本号的值可以通过CFBundleShortVersionString键在iOS应用程序的Info.plist文件中找到，或者如果是上载的iOS应用程序，我们可以在iTunes Connect中进行检查以找到版本号。我们可以使用Apple的agvtool命令行工具检查当前版本号 $ xcrun agvtool what-marketing-version 内部编号可以为特定的版本号上载多个版本，但是，为特定的版本号上载的版本号应该是唯一的，并且应该是递增的。内部版本号的值可以重新用于其他版本号。使用CFBundleVersion键可在iOS应用程序的Info.plist文件中找到当前内部版本号的值。我们可以使用Apple的agvtool命令行工具检查当前版本号 $ xcrun agvtool what-version 发布火车针对特定版本的特定版本表单的发布版本提交的构建数量。在发行版中，内部版本号按递增顺序排列且唯一。该火车可以使用特定功能进行多个构建，并且如果需要，我们可以将任何构建升级到App Store。简而言之，发布火车是持续交付的基础。在发行系列中，很少有用于增加内部版本号的策略。我们将看到它们中的每一个，并讨论哪一个最适合发布火车。 1. agvtool 苹果有本机命令行工具来处理版本和内部版本号。我们可以启用agvtool并编写脚本来自动增加特定发行版中的内部版本号。为了启用agvtool，我们需要确保在目标构建设置中正确设置了“ 当前项目版本”和“ 版本控制系统”属性。选择目标构建设置，然后搜索“版本”。现在，将“ 当前项目版本”设置为1，并将“ 版本控制系统”值选择为“ […]

与Jenkins，Xcode和GitHub的基本持续集成: 在上一篇文章中，我论证了为什么单元测试和代码审查很有价值。在这一篇中，我将向您展示如何建立一个自动化系统来执行这些原则。在允许PR合并之前，我们将要求有人对其进行审查，并且所有单元测试都已通过。开发人员在提交PR之前不应该运行单元测试吗？是的，但是拥有护栏并没有什么可耻的。专家通常会忘记一两个细节。看看医院开始允许护士对医生实施检查清单时发生了什么。 2001年，约翰·霍普金斯医院的重症监护专家Peter Pronovost决定尝试[检查清单]……他和他的团队说服医院管理部门授权护士在发现医生跳过检查清单的步骤时停止医生治疗…… Pronovost和他的同事们监视了一年后发生的事情。结果是如此惊人，以至于他们不确定是否要相信：十天的线感染率从11％降至零。因此，他们又跟踪患者十五个月。在整个时期内仅发生了两次线感染。他们计算出，在这家医院中，清单已预防了43次感染和8例死亡，并节省了200万美元的成本。 https://www.newyorker.com/magazine/2007/12/10/the-checklist 由于可能会出现错误，为什么不解释这些错误呢？我们可以告诉计算机强制执行我们自己设计的清单。有3个主要部分可实现这一目标：设置Jenkins以构建和测试iOS应用获取GitHub以加入Jenkins以触发构建并报告测试结果配置GitHub阻止PR，直到所有检查通过您将需要Jenkins在Mac上运行。如果您不能这样做，请立即保释。 👋 Jenkins有大量的插件可以使您的生活更轻松。我们想要的是： GitHub，GitHub API，GitHub身份验证和GitHub Pull Request Builder —与GitHub交互 JUnit —报告单元测试结果 Xcode集成-帮助我们构建iOS应用要安装插件，请转到主页->管理Jenkins->管理插件。然后检查“可用/已安装”选项卡。您可能已经安装了其中一些！首先，让我们构建我们的应用程序。进行Freestyle作业，然后输入您的回购URL和凭据并指定您的主分支：接下来，浏览至Xcode部分，并将其放入常规设置。该插件的作用是在您的项目中运行xcodebuild ，并使其易于配置参数。现在转到Advanced Xcode build options-> Advanced build settings 看到“目的地”参数了吗？这指向您要测试的特定设备。 […]

iOS应用程序的自动UI测试: 在充满竞争的世界中，公司希望比以往更快地发布其软件。原因是他们很害怕。害怕屈居第二或失去市场份额。试图越来越快地做出决定，通常将单元测试定义为“稍后”。开发人员无需测试即可创建大量代码，并且对此感到非常满意。 X天到了，该发布产品了。由于该软件还不算太大，因此他们可以在发布期间进行手动测试。这里没事！认真地说，手动测试很棒！问题在几个月后开始。在某些时候，手动测试花费的时间越来越长。您的应用变得更加复杂，并具有更多功能。此外，您必须检查回归。这是他们先前的质量下降开始显现的地方。发行周期突然不需要几个小时。相反，它需要几个星期。每两周发布一次，然后弹出一个问题：测试使我们无法经常发布，该怎么办？这是一个具有多个选项的好问题。只需忽略减少测试工作量的想法即可。这是肯定的办法。另一种选择是从开发人员级别开始。让我们添加单元测试！哎呀……既然我们忽略了它们，那么一开始，我们的代码就不是那么容易测试了……要花一些时间为单元测试添加基础。那我们还能做什么？在整个过程中，我们可以添加某种测试意识形态。第一步是使用BDD进行此操作。但是，这不会以快速而肯定的方式帮助我们。如此众多的公司开始使用自动化的UI测试。让计算机执行与手动测试应用程序相同的步骤。我们可以每晚（或每次提交？）运行这些测试，这比让团队坐下来进行体力劳动要快得多。在继续之前，让我这样说：自动化的UI测试并不是解决问题的灵丹妙药！但这是整个机器的齿轮。因此，仅因为这不是您的灵丹妙药，不要完全忽略它。 iOS上有很多不同的方法。有些是本地人，有些则更少。让我们单独看一下。 XCUI测试几年前，苹果公司停止了其JavaScript自动化框架，并用XCUITest代替了它。这是Apple支持的本机库，这意味着您可以用Objective-C或Swift编写UI测试。我必须缠住头的一件事是，您不必检查包含值的元素（标签，按钮等）。而是，您检查屏幕上是否存在该值。因此，在测试是否显示文本时，它看起来像这样： XCTAssert（app.staticTexts [“ Welcome”]。exists） XCUITest在其自己的进程中运行。这既有优点，也有缺点。它可以看到屏幕上的所有内容，但您无法检查内部应用程序的状态是什么。这非常好，因为它可以防止开发人员犯涉及普通用户没有的知识的错误。另一方面，处于单独的进程也意味着需要一些时间来同步应用程序状态。这会花费时间并减慢测试速度。此外，当执行一些需要时间的操作时，由于XCUITest无法找到请求的元素，因此可能导致错误。要在失败之前等待一小段时间，我们可以等待元素出现： […]

移动自动化测试: 通过查看上图可以最好地理解我们的系统。蓝色突出显示的部分显示了测试的运行位置。开发人员检入经过本地测试的代码更改，这些更改将由同级审查并提交给master分支。该分支建立在Jenkins服务器上，并且在此阶段再次运行整套UI测试。通过QA评估成功的构建，并在测试失败时报告新的错误。为了防止一次实施UI测试并在启动失败后将其忘记，我们需要对自动化UI测试采用相同的CI / CD方法。这意味着我们所有的测试代码都与我们的应用程序在同一个项目中，因此是持续集成管道的一部分。当有新功能添加到应用程序时，新的UI测试可以同时添加到测试中。当UI测试失败时，可以修复该错误并将其集成到主分支中，然后我们可以确保测试通过。因此，上面显示的流程与用于正常代码更改（用于功能，错误修复等）以及添加和修复测试代码的流程相同。将项目代码和测试代码都放在同一个CI系统中，可以提供高效的反馈系统，从而可以尽早发现错误并可靠地验证构建。 iOS测试框架对于UI测试，我们使用Earlgrey 2.0。 Earlgrey是Google开发的一种测试框架，用于测试iOS的Google应用程序，并与XCTest（Apple的官方测试框架）集成在一起，该框架集成在XCode中。在单独使用Earlgrey和XCTest进行了编写测试之后，我们决定使用Earlgrey。做出此选择的主要原因是Earlgrey由于内置的功能而更加稳定，例如，在与元素进行交互之前等待视图完全加载，以及检查元素是否真正可见，而不仅仅是在UI堆栈中。页面对象模型设计模式对于我们的UI测试，我们决定遵循Page Object Model设计模式。这种模式将用于识别UI元素的类与测试类分开。每个“页面”或用户看到的屏幕都有自己的页面对象。每个页面对象都有一些通用方法，例如verifyUIElements() ，只需调用这些方法即可验证屏幕上应该显示的所有元素是否可见。它还具有代表用户操作的方法，例如tapDone()或inputEmail() 。然后，测试类可以调用这些方法以进行测试流程，例如导航到登录页面，验证元素，输入电子邮件地址，然后点击“登录”。这种方法减少了指定UI元素的代码重复。此外，如果UI元素得到更新，则更新测试是对页面对象的单行更改，并且测试类不受影响。这种分离也意味着测试类更具可读性。请参阅以下示例在登录页面上进行UI测试。上面是要测试的登录屏幕。首先，我们制作了表示屏幕上UI元素的屏幕对象以及与这些元素进行交互的方法。然后，我们编写了使用屏幕来测试登录流程的测试用例。第一个测试用例是他们是否点击了“忘记密码”按钮，第二个是当他们输入有效的密码时。测试套件我们将测试套件分为健全性测试，冒烟测试和回归测试。健全性测试将检查最少数量的功能，以确保构建实际上正在构建并正在运行。如果这些测试失败，那么我们将陷入大麻烦。冒烟测试检查了我们应用程序的更多基本功能，而回归测试则覆盖了我们应用程序的更多粒度和较少使用的功能。进行健康与烟雾测试大约需要7分钟。因此，我们希望开发人员在本地运行这两个套件，以确保在着陆更改之前，该构建适用于基本功能。如果冒烟或健全性测试套件中的任何测试失败，则开发人员应在构建进行质量检查之前对它们进行检查，因为这可能表明存在重大问题。由于回归测试套件大约需要30分钟，因此我们的Jenkins服务器每晚都会运行这些测试，并在第二天检查结果。回归测试结果也很重要，但并不像健全测试和冒烟测试那样重要，因为每次测试都必须通过，因为对粒状细节的测试会变得更加脆弱。模块化测试设计我们努力设计测试，以使每个测试都尽可能模块化。这意味着一个测试失败不会导致其他测试失败。为了确保这一点，每个测试方案都以登录开始，并以注销结束。一个测试场景可能是“以15％的小费收取Discover信用卡付款”，另一种情况是“以15％的小费收取MasterCard付款”。即使Discover测试失败，我们也会使用XCTest的teardown（）函数返回屏幕上带有注销按钮，然后在开始下一个测试之前注销。模块化在编写测试时为我们提供了帮助，因为您可以单独运行测试，并且调试速度更快。查看测试结果时，这种模块化也有助于查明问题。当测试失败时，测试框架将截屏显示失败的时间，失败之前的堆栈跟踪以及屏幕的整个UI层次结构。 […]