网站制作要钱吗,seo的培训网站哪里好,自己如何做网站,做网站域名的成本客户端 UI 自动化测试是大多数测试团队的研究重点#xff0c;本文介绍猫眼测试团队在猫眼 iOS 客户端实践的基于 KIF 的 UI 自动化测试和持续集成过程。 一、测试框架的选择 iOS UI 自动化测试框架有不少#xff0c;其中 UI Automation 是 Apple 早期提供的 UI 自动化测试解决… 客户端 UI 自动化测试是大多数测试团队的研究重点本文介绍猫眼测试团队在猫眼 iOS 客户端实践的基于 KIF 的 UI 自动化测试和持续集成过程。 一、测试框架的选择 iOS UI 自动化测试框架有不少其中 UI Automation 是 Apple 早期提供的 UI 自动化测试解决方法用 JavaScript 编写测试脚本通过标签和值的可访问性获得 UI 元素来完成相应的交互操作。 一些第三方 UI 解决方案以 UI Automation 为基础对其进行补充和优化包括扩展型 UI Automation 和驱动型 UI Automation。 扩展型 UI Automation 采用 JavaScript 扩展库方法提高 UI Automation 的易用性常见的框架有 TuneupJs、ynm3k。驱动型 UI Automation 在自动化测试底层使用了 UI Automation 库通过 TCP 等通信方式驱动 UI Automation 来完成自动化测试。这种方式下编辑脚本的语言不再局限于 JavaScript 。常见的框架有 iOSDriver、Appium。还有一些其他的第三方解决方案常见的框架类型有私有 API 型和注入编译型。 私有 API 型框架直接使用 Apple 私有 API 对 UI 界面进行操作。常见的框架主要有 KIF。注入编译型框架在编译时注入一个 Server 到 App 内部通过 Server 对外通信完成 UI 操作指令的执行。常见的框架有 Frank、Calabash。Xcode 7发布后Apple 提供了一种新的 UI 自动化测试解决方法——UI Testing它基于 XCTest 测试框架通过控件的可访问性来定位和获取控件并提供了多种 UI 操作 API使用源码语言能方便地进行调试。 我们在以上分类中挑选具有代表性的自动化框架UI Automation、Appium、KIF、Frank、UI Testing 进行对比下表是这几种测试框架的特点对比 考虑选择测试框架的几种影响因素。首先使用的语言和框架决定了测试人员的持续性学习成本iOS 测试人员对 Objective—C 和 XCTest 熟悉和掌握程度高不需要消耗额外的学习成本人员更替时的接手成本也相对较低其次测试框架支持的 UI 操作的丰富性决定了测试用例的覆盖完整度使用私有 API 的测试框架支持的 UI 操作较为全面而同时支持 UIWebView 的测试框架则更占优势另外App 程序 UI 变化快使用开发效率高、调试方便的测试框架能使我们在适应新 UI 变化、新需求时获得更小的投入产出比。 综合以上考虑KIF 框架已经展现了他的优势并且 KIF 使用 XCTest 框架使得其测试流程 iOS 程序的单测无异可完全复用单测的持续集成流程维护持续集成的成本相对降低另外KIF 是一个活跃的开源测试框架可扩展性好升级更新快有活跃社区来探讨和解决使用过程中遇到的问题。鉴于上述优势我们选择了 KIF 作为 iOS 的 UI 自动化测试框架。 二、KIF 自动化实施 KIF 利用 Apple 给所有控件提供的辅助属性 accessibility attributes 来定位和获取元素完成界面的交互操作结合使用 Xcode 的 XCTest 测试框架拥有 XCTest 测试框架的特性使得测试用例能以 command line build 工具运行并获取测试报告。 下面介绍如何进行 KIF 自动化实施。 1. KIF 搭建 KIF 以第三方库的形式编译运行于工程中搭建 KIF 之前应该确保工程在 Xcode 上编译运行通过。 KIF 基于 XCTest 框架继承了 XCTest 的所有特性。和 XCTest 一样我们首先应该在工程项目中创建基于 Cocoa Touch Testing Bundle 模板的 Target 并确保创建的 Target 的属性有如下设置 “Build Phases”设置 Target Dependencies UI 自动化测试固然要依赖应用程序的 App 产物所以需保证应用程序 Target 被添加在 Test Target 的 Target Dependencies 中。“Build Settings”: 设置 “Bundle loader” 为$(BUILT_PRODUCTS_DIR)/MyApp.app/MyApp 设置 “Test Host” 为$(BUILT_PRODUCTS_DIR) 设置 “Wrapper Extensions” 为xctest。项目的设置准备好后需要安装 KIF 库源码到项目。即可开始 KIF 编写用例之旅。 KIF 通过属性值AccessibilityLabel, AccessibilityIdentifier, AccessibilityTraits,Value…在界面中定位元素。为了获取到目标元素我们必须先设置元素的 accessibility 属性。如下想要获取程序中一个列表的 cell 元素我们给列表的 cell 控件设置 accessibility 属性如左图所示设置为“Section XX Row XX”编译运行即可获得历史列表的 cell 元素用模拟器的 Accessibility Inspector 抓取到了这个历史列表元素如右图所示 KIF 为我们提供了对有 accessibility 属性控件的操作接口如下最简单的两个操作接口 点击一个元素- (void)tapViewWithAccessibilityLabel:(NSString *)label等待一个元素的出现- (UIView *)waitForViewWithAccessibilityLabel:(NSString *)label。在新建的 Target 同名目录下增加一个继承自 KIFTestCase 的类类中编写我们的用例完成对界面的点击和验证如下 以上步骤都完成后 基于KIF的简单用例便搭建完成点击 Product-Test 或者快捷键 (⌘U) 即可看到我们的用例自动运行起来了。 2. 用例编写与组织 1accessibility 属性设置 accessibility 属性是 Apple 给视觉障碍人群提供完全无障碍使用的基本属性该属性表明了 UI 元素的可访问性、是什么、做什么以及会触发什么样的操作。原生的 UIKit 控件默认提供了这些信息然而自定义的控件则需要对该属性进行设置设置方式可参考下面几点 设置方式找到页面元素所属的代码文件再到代码中找到该类的实现在相应代码处添加其属性。查看方式设置好后开启模拟器的 Accessibility Inspector 功能即可看到控件的 accessibility 属性。设置建议设置的 AccessibilityLabel 属性值要有实际意义用户可理解因为设置这个属性后用户可以通过 VoiceOver 访问用户不可访问的控件比如某些放置控件的容器等应该设置为 AccessibilityIdentifier 。2用例常用操作接口 UI交互操作( KIFUITestActor.h 中可查阅) tapThisView: - (void)tapViewWithAccessibilityLabel:(NSString *)label;waitForView: - (UIView *)waitForViewWithAccessibilityLabel:(NSString *)label;注意函数返回了对应View的指针可以对返回值取数据从而进行一些判断enterTextIntoView: - (void)enterText:(NSString *)text intoViewWithAccessibilityLabel:(NSString *)label;tapRowOnTableView: - (void)tapRowAtIndexPath:(NSIndexPath *)indexPath inTableViewWithAccessibilityIdentifier:(NSString *)identifier NS_AVAILABLE_IOS(5_0);dismisses a system alert: - (void)acknowledgeSystemAlert;扩展我们还可以对 KIFUITestActor 类进行扩展利用 KIFUITestActor 中的私有函数使 AccessibilityIdentifier 代替 Label 识别元素完成 tapThisView 、waitForView 等操作。 用例集操作( KIFTestCase.h 中可查阅) - (void)beforeAll; 在本类中第一个 test case执行前执行一次用处执行本类中各个测试函数的公共操作注意因为不能保证这个方法与 test case 是同一个类实例所以不能用来设置实例变量的值但是可以设置静态变量- (void)beforeEach; 在每一个 test case 执行前执行一次用处执行各个函数需要的测试环境注意因为确保这个方法与 test case 是同一个类实例所以可以用来设置实例变量- (void)afterEach; 在每一个 test case执行后执行一次用处用来将 App 恢复至 test case 之前的状态可以包含一些条件判断逻辑从失败的 test case 中恢复以确保不影响之后的测试- (void)afterAll; 执行完测试类的最后一个 test case 后执行一次用处用于将 App 恢复至测试的初始状态系统的功能实现( KIFSystemTestActor.h 中可查阅 模拟用户旋转设备 - (void)simulateDeviceRotationToOrientation:(UIDeviceOrientation)orientation;对当前屏幕截图并存储到硬盘中- (void)captureScreenshotWithDescription:(NSString *)description;3用例组织 设计实现单个测试用例步骤如下: * a. 设置测试所需要的环境 * b. 测试用例的测试逻辑 * c. 恢复App至此次测试前状态。 a、c步骤可用 beforeEach、afterEach 来实现这样保证了每个用例之间的独立性和用例运行的稳定性。 一般来说可将用例按功能分成若干个用例集每个用例集按校验点或者功能点分成若干个用例这样方便测试用例的管理和维护。 某些含有耗费时间多、耗费资源多的公共操作的用例可以集合成一个用例集在用例集运行前统一执行。设计实现用例集步骤如下 a. 设置用例集需要的环境、公共操作b. 设计各个用例c. 恢复 App 至用例集测试的初始状态。a、c步骤可用 beforeAll、afterAll 来实现下图展示了一个用例集的书写示例 #import TimerTests.h
#import KIFUITestActorAccessibilityLabelAddition.h
#import KIFUITestActorIdentifierAdditions.h
#import KIFUITestActorTimerAdditions.h
implementation TimerTests
- (void)beforeAll
{[tester setDebugModel];
}
- (void)afterAll
{[tester resetDebugModel];[tester clearHistory];
}
- (void)beforeEach
{[tester setDebugModel];
}
- (void)afterEach
{[tester clearParams];
}
- (void)testNameedTask
{[tester enterText:myTask intoViewWithAccessibilityLabel:Task Name Input];[tester enterWorktime:10 Breaktime:4 Repetitions:5];[tester tapViewWithAccessibilityLabel:Start Working];[tester waitForViewWithAccessibilityLabel:myTask];[tester waitForViewWithAccessibilityLabel:Start Working];
}
- (void)testnoNameTask
{[tester enterWorktime:10 Breaktime:4 Repetitions:5];[tester tapViewWithAccessibilityLabel:Start Working];[tester waitForViewWithAccessibilityLabel:myTask];[tester waitForViewWithAccessibilityLabel:Start Working];
}
- (void)testPresetTask
{[tester tapViewWithAccessibilityLabel:Presets];[tester tapRowAtIndexPath:Classic inTableViewWithAccessibilityIdentifier:Presets List];[tester tapViewWithAccessibilityLabel:Start Working];[tester waitForViewWithAccessibilityLabel:myTask];[tester waitForViewWithAccessibilityLabel:Start Working];
}
end上述代码中我们看到许多封装函数。为保证用例结构清晰明朗我们借鉴 selenium pageObject 的设计方式 遵循如下规则 a. 将页面上的对元素的发现、操作处理抽象为相应的类返回操作结果b. 封装尽可能多的工具类c. 测试用例只关注用例逻辑步骤尽量简洁。如下图所示在用例集 test suite 中我们只保持清晰的用例逻辑非用例逻辑的动作封装成相应地用例集的类 test suite additions 因为 KIF 的开源性我们还可以利用 KIF 的私有 API 封装我们需要的工具 Tools 类。 4用例的运行独立和 retry 机制 失败用例是不可避免的上述用例的组织方式降低了用例间的依赖性但是并不能完全消除失败用例对后续用例执行的影响。如果能让每个用例独立启动 App 执行 case则能保证后执行用例不受先执行失败用例的影响。如果在 case 运行失败后还可以进行 retry 重试则能提高用例运行的稳定性。xctool 工具能给我们带来这样的功能我们用 xctool 命令先 build-tests 构建 app然后循环启动 app 来 run-tests 用例用例失败后重新执行。下面是一个 xctool 独立运行用例的简单示例 xctool build-tests -workspace myApp.xcworkspace -scheme myKIFTestScheme -sdk iphonesimulator -configuration Debug -destination platformiOS Simulator,OS8.3,nameiPhone 6 Plusarray( TimerTests HistoryTests )for data in ${array[]}
doxctool -reporter pretty -reporter junit:tmp/test-report-tmp.xml -workspace myApp.xcworkspace -scheme myKIFTestScheme run-tests -only myKIFTestTarget:${data} -sdk iphonesimulator -configuration Debug -destination platformiOS Simulator,OS8.3,nameiPhone 6 Plus
done三、KIF 自动化的持续集成 1. 持续集成的意义与 UI 自动化测试的用例选择 持续集成是一个自动化的周期性的集成测试过程从检出代码、编译构建、运行测试、结果记录、测试统计等都是自动完成的无需人工干预。我们的项目都是团队协作开发采用持续集成的优势显而易见 尽早尽快地发现集成错误保证团队开发人员提交代码的质量减轻软件发布时的压力自动完成集成中的环节有利于减少集成过程的重复工作以节省时间、费用和工作量持续集成最大的好处在于能够尽早高效发现问题降低解决问题的成本。而发现问题的手段主要就是测试。 根据 Martin Fowler 的测试理论测试应该遵循如下测试金字塔组合测试金字塔最底层是单元测试然后是集成测试继而是面向应用程序服务层的中间层测试最高层是面向用户的业务逻辑测试  测试自动化的测试层级越多持续集成平台就能产生越大的价值。 UI 测试目标是覆盖最核心的代码尽可能去掉依赖让不稳定因子降到最低这样既保证自动化测试层级的全面性又保证持续集成的稳定构建降低测试的投入产出比。因此在我们的 UI 自动化测试中我们选择核心功能的冒烟用例来完成持续集成中的测试金字塔。 2. Jenkins 上完成基于 KIF 的 UI 自动化持续集成搭建 Jenkins 是一个开源的持续集成工具提供了一种易于使用的持续集成系统使开发者从繁杂的集成中解脱出来专注于更为重要的业务逻辑实现上。 Jenkins 以 Job 为单位运行项目一个 Job 的工作流程为在指定的时机选择合适的 salve 节点从版本管理系统上获取对应的源码使用命令行脚本或者 maven 或者 ant 进行构建构建后归档文件处理报告如果构建失败那么就通过邮件进行反馈等。 Job 的触发时机主要有3种选择 “Build after other project are build”表示在其他某个项目build后触发比如我们可以在某个提测Job构建之后立即构建我们的 UI 自动化来验证这个提测的可行性“Build periodically”表示按时间触发我们可以选择这个让 Job 做 Daily Build 来进行持续构建观察“Poll SCM”表示允许用户让 Jenkins 定期查询某一个项目的代码库如果有代码变动则触发执行任务这种触发非常适合集成测试项目以此验证代码库变动是否能测试通过。我们希望在代码改动发生的时候就做到尽早发现代码改动带来的问题所以使用 “Poll SCM” 在当代码仓库有新的 pull request 的时候触发相应 Job 完成构建Job 的执行结果作为这个 pull request 能否合入的衡量指标之一同时为支持客户端支持 daily build Job 使用 “Build periodically” 在每天 daily build 打包前完成一次自动构建。 Job 需要支持命令行构建才能实现持续集成如上一部分提到我们可以借助 xcodebuild/xctool 实现单命令行构建。同时为了衡量 Job 的执行结果我们需要在 Job 执行完成后生成相应的测试报告和代码覆盖率报告使用 xcodebuild/xctool 这样的命令行工具只需要配置相关的参数即可获取相应的 XML 测试报告文件。 Jenkins 中 JUnit Plugin 插件可以将 XML 形式的测试报告转化成一种随时间推移的测试结果图表向我们展示测试的结果和测试的稳定性 Cobertura plugin 插件可以将 XML 形式的覆盖率文件转化成一种随时间推移的代码覆盖率图表。如下图是 Job 中测试报告的代码覆盖率和测试结果的示例通过下面的图表我们可以清晰地看到测试是否通过检查代码的测试覆盖范围并对比历史的测试结果和代码覆盖率来推断和定位问题。 3. KIF 自动化测试在 Jenkins 持续集成过程中遇到的问题 (1)设备重置 我们的测试用例覆盖了第一次安装启动的操作。在初期这个用例经常失败。经过排查发现持续集成系统中的模拟器设备重置操作并没有覆盖所有的设备UI 测试 Job 运行时Job 选择的模拟器设备上可能遗留了其他 Job 构建的相同的 app 产物导致我们的 Job 构建产物并不是第一次安装启动。所以在脚本中我们遍历所有模拟器设备将其进行重置。 (2)键盘敲击延迟 我们的测试用例在输入框输入文字时经常出现输入不全而导致失败的问题。比如在输入框中输入 ‘beijing’ 失败后提示Failed to get text in field; instead, it was ‘beiji’ 。经过排查发现持续集成系统中的机器性能有高有低在低性能机器中更容易发生此问题再研究 KIF 框架源码发现KIF 默认设置的键盘敲击时延为一个常数对于低性能机器来说这个敲击时延较短容易漏掉输入所以我们在 KIFTypist.m 源码文件中适当增加 (NSTimeInterval) keystrokeDelay 的时长来避免输入不全的问题。 (3)多个系统弹窗确认 前面我们提到过KIF 支持对系统弹窗的处理即接口 acknowledgeSystemAlert 它能帮我们确认一个系统弹窗。但是我们的应用程序在启动时系统弹窗并不止一个并且在不同设备上因系统设置不同系统弹窗的个数是不确定的。所以直接使用 acknowledgeSystemAlert 并不能帮我们解决问题。因为 KIF 的开源性我们在 KIF 框架源码 acknowledgeSystemAlert 函数中做了一次 while 循环处理处理了出现的任意多个系统弹窗的情况从而解决了问题。 参考文献 Automate UI Testing in iOShttps://developer.apple.com/library/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.htmlAppium 官网介绍http://appium.io/slate/cn/v1.2.0/?ruby#appiumFrank 官网介绍http://www.testingwithfrank.com/KIF 源码库https://github.com/kif-framework/KIFiOS UI Testing with KIFhttp://www.raywenderlich.com/61419/ios-ui-testing-with-kifThe current state of iOS automated functional testinghttp://watirmelon.com/2013/11/04/the-current-state-of-ios-automated-functional-testing/Page Objecthttp://martinfowler.com/bliki/PageObject.htmlTest Pyramidhttp://martinfowler.com/bliki/TestPyramid.htmlContinuous Integrationhttp://www.martinfowler.com/articles/continuousIntegration.htmlxcodebuildhttps://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/xcodebuild.1.htmlxctoolhttps://github.com/facebook/xctoolJenkins 官网介绍https://wiki.jenkins-ci.org/display/JENKINS/HomeJUnit Pluginhttps://wiki.jenkins-ci.org/display/JENKINS/JUnitPluginCobertura pluginhttps://wiki.jenkins-ci.org/display/JENKINS/CoberturaPluginXcode 7 UI Testinghttps://developer.apple.com/videos/play/wwdc2015/406/
