多测师是一家拥有先进的教学理念,强大的师资团队,业内好评甚多的接口自动化测试培训机构!

17727591462

联系电话

您现在所在位置:接口自动化测试培训 > 新闻资讯

iOS自动化测试的那些干货

更新时间:2022-04-08 09:50:21 作者:多测师 浏览:140

  测试是发布之前的最后一道关卡。如果bug不能在测试中发现,那么bug就会抵达用户,所以测试的完整性和可靠性十分重要。

iOS自动化测试的那些干货

  目前,大多数App还停留在人工测试阶段,人工测试投入的成本最低,能够保证核心功能的使用,而且测试人员不需要会写代码。

  但是,在很多测试场景下,人工测试的效率太低,容易出错。举两个常见的例子:

  一个App的核心功能,在每一次发布版本前的测试必定会跑一遍所有的测试用例,不管对应的业务在当前版本有没有变化(天知道开发在做业务A的时候,对业务B有没有影响),如果这次测出新的bug,测试人员在下一次发版测试中,又不得不做这些重复的工作。

  开发在写API请求相关代码的时候没有做数据容错,测试在人工测试的时候都是正常的数据,所以测试通过。上线了之后,后台配置数据的时候出了点小问题,导致大面积崩溃,boom~。

  然后,老板就要过来找你了

  本文所讲解的均是基于XCode 8.2.1,有些概念可能不适用于低版本的XCode

  自动化测试

  自动化测试就是写一些测试代码,用代码代替人工去完成模块和业务的测试。

  其实不管是开发还是测试,如果你在不断的做重复性工作的时候,就应该问自己一个问题:是不是有更高效的办法?

  自动化测试有很多优点:

  测试速度快,避免重复性的工作

  避免regression,让开发更有信心去修改和重构代码(个人认为最大的优点)

  具有一致性。

  有了自动化测试,持续集成(CI)会变得更可靠。

  迫使开发人员写出更高质量的代码。(自动化测试不通过,代码不允许合并)

  当然,自动化测试也有一些缺点。

  开发和维护成本高。

  不能完全替代人工测试。

  无法完全保证测试的准确性 - 让代码去判断一段逻辑是否正确很容易,但是,让代码判断一个控件显示是否正确却没那么容易。

  所以,在做自动化测试之前,首先要问自己几个问题?

  这个测试业务的变动是否频繁?

  这个测试业务是否属于核心功能?

  编写测试代码的成本有多少?

  自动化测试能保证测试结果的准确么?

  通常,我们会选择那些业务稳定,需要频繁测试的部分来编写自动化测试脚本,其余的采用人工测试,人工测试仍然是iOS App开发中不可缺少的一部分。

  测试种类

  从是否接触源代码的角度来分类:测试分为黑盒和白盒(灰盒就是黑盒白盒结合,这里不做讨论)。

  白盒测试的时候,测试人员是可以直接接触待测试App的源代码的。白盒测试更多的是单元测试,测试人员针对各个单元进行各种可能的输入分析,然后测试其输出。白盒测试的测试代码通常由iOS开发编写。

  黑盒测试。黑盒测试的时候,测试人员不需要接触源代码。是从App层面对其行为以及UI的正确性进行验证,黑盒测试由iOS测试完成。

  而iOS测试通常只有以下两个层次:

  Unit,单元测试,保证每一个类能够正常工作

  UI,UI测试,也叫做集成测试,从业务层的角度保证各个业务可以正常工作。

  框架选择

  啰里八嗦讲的这么多,自动化测试的效率怎么样,关键还是在测试框架上。那么,如何选择测试框架呢?框架可以分为两大类:XCode内置的和三方库。

  选择框架的时候有几个方面要考虑

  ●测试代码编写的成本

  ●是否可调式

  ●框架的稳定性

  ●测试报告(截图,代码覆盖率,…)

  ●WebView的支持(很多App都用到了H5)

  ●自定义控件的测试

  ●是否需要源代码

  ●能否需要连着电脑

  ●是否支持CI(持续集成)

  …

  我们首先来看看XCode内置的框架:XCTest。XCTest又可以分为两部分:Unit Test 和 UI Test,分别对应单元测试和UI测试。有一些三方的测试库也是基于XCTest框架的,这个在后文会讲到。由于是Apple官方提供的,所以这个框架会不断完善。

  成熟的三方框架通常提供了很多封装好的有好的接口,笔者综合对比了一些,推荐以下框架:

  单元测试:

  以下三个框架都是BDD(Behavior-driven development) - 行为驱动开发。行为驱动开发简单来说就是先定义行为,然后定义测试用例,接着再编写代码。 实践中发现,通常没有那么多时间来先定义行为,不过BDD中的domain-specific language (DSL)能够很好的描述用例的行为。

  Kiwi 老牌测试框架

  specta 另一个BDD优秀框架

  Quick 三个项目中Star最多,支持OC和Swift,优先推荐。

  UI测试

  KIF 基于XCTest的测试框架,调用私有API来控制UI,测试用例用Objective C或Swift编写。

  appium 基于Client - Server的测试框架。App相当于一个Server,测试代码相当于Client,通过发送JSON来操作APP,测试语言可以是任意的,支持android和iOS。

  篇幅有限,本文会先介绍XCtest,接着三方的Unit框架会以Quick为例,UI Test框架侧重分析KIF,appium仅仅做原理讲解。

  XCTest

  对于XCTest来说,最后生成的是一个bundle。bundle是不能直接执行的,必须依赖于一个宿主进程。关于XCTest进行单元测试的基础(XCode的使用,异步测试,性能测试,代码覆盖率等),我在这篇文章里讲解过,这里不再详细讲解。

  iOS 单元测试之XCTest详解

  单元测试用例

  比如,我有以下一个函数:

  //验证一段Text是否有效。(不能以空字符开头,不能为空)

  - (BOOL)validText:(NSString *)text error:(NSError *__autoreleasing *)error{

  }

  那么,我该如何为这个函数编写单元测试的代码?通常,需要考虑以下用例:

  输入以空白字符或者换行符开头的,error不为空,返回 NO

  输入正确的内容,error为空,返回YES

  输入为nil,error不为空,返回 NO (边界条件)

  输入为非NSString类型,验证不通过,返回NO (错误输入)

  特殊输入字符(标点符号,非英文等等)

  UI测试

  UI测试是模拟用户操作,进而从业务处层面测试。关于XCTest的UI测试,建议看看WWDC 2015的这个视频:

  UI Testing in Xcode

  关于UI测试,有几个核心类需要掌握

  XCUIApplication 测试应用的代理

  XCUIElement 一个UI上可见的视图对象

  XCUIElementQuery 查找XCUIElement

  UI测试还有一个核心功能是UI Recording。选中一个UI测试用例,然后点击图中的小红点既可以开始UI Recoding。你会发现:

  随着点击模拟器,自动合成了测试代码。(通常自动合成代码后,还需要手动的去调整)

  在写UI测试用例的时候要注意:测试行为而不是测试代码。比如,我们测试这样一个case

  进入Todo首页,点击add,进入添加页面,输入文字,点击save。

  对应测试代码:

  - (void)testAddNewItems{

  //获取app代理

  XCUIApplication *app = [[XCUIApplication alloc] init];

  //找到第一个tabeview,就是我们想要的tableview

  XCUIElement * table = [app.tables elementBoundByIndex:0];

  //记录下来添加之前的数量

  NSInteger oldCount = table.cells.count;

  //点击Add

  [app.navigationBars[@"ToDo"].buttons[@"Add"] tap];

  //找到Textfield

  XCUIElement *inputWhatYouWantTodoTextField = app.textFields[@"Input what you want todo"];

  //点击Textfield

  [inputWhatYouWantTodoTextField tap];

  //输入字符

  [inputWhatYouWantTodoTextField typeText:@"somethingtodo"];

  //点击保存

  [app.navigationBars[@"Add"].buttons[@"Save"] tap];

  //获取当前的数量

  NSInteger newCount = table.cells.count;

  //如果cells的数量加一,则认为测试成功

  XCTAssert(newCount == oldCount + 1);

  }

  这里是通过前后tableview的row数量来断言成功或者失败。

  等待

  通常,在视图切换的时候有转场动画,我们需要等待动画结束,然后才能继续,否则query的时候很可能找不到我们想要的控件。

  比如,如下代码等待VC转场结束,当query只有一个table的时候,才继续执行后续的代码。

  [self expectationForPredicate:[NSPredicate predicateWithFormat:@"self.count = 1"]

  evaluatedWithObject:app.tables

  handler:nil];

  [self waitForExpectationsWithTimeout:2.0 handler:nil];

  //后续代码....

  Tips: 当你的UI结构比较复杂的时候,比如各种嵌套childViewController,使用XCUIElementQuery的代码会很长,也不好维护。

  另外,UI测试还会在每一步操作的时候截图,方便对测试报告进行验证。

  查看测试结果

  使用基于XCTest的框架,可以在XCode的report navigator中查看测试结果。

  其中:

  ●Tests 用来查看详细的测试过程

  ●Coverage 用来查看代码覆盖率

  ●Logs 用来查看测试的日志

  点击图中的红色框指向的图标可以看到每一步UI操作的截图

  除了利用XCode的GUI,还可以通过后文提到的命令行工具来测试,查看结果。

  Stub/Mock

  首先解释两个术语:

  ●mock 表示一个模拟对象

  ●stub 追踪方法的调用,在方法调用的时候返回指定的值。

  通常,如果你采用纯存的XCTest,推荐采用OCMock来实现mock和stub,单元测试的三方库通常已集成了stub和mock。

  那么,如何使用mock呢?举个官方的例子:

  //mock一个NSUserDefaults对象

  id userDefaultsMock = OCMClassMock( [NSUserDefaults class]);

  //在调用stringForKey的时候,返回http://testurl

  OCMStub([userDefaultsMock

  stringForKey:@"MyAppURLKey"] ).andReturn( @"http://testurl");

  再比如,我们要测试打开其他App,那么如何判断确实打开了其他App呢?

  id app = OCMClassMock([UIApplication class]);

  OCMStub([app sharedInstance]).andReturn(app);

  OCMVerify([app openURL:url]

  使用Stub可以让我们很方便的实现这个。

  以上内容为大家介绍了iOS自动化测试的那些干货,本文由多测师亲自撰写,希望对大家有所帮助。了解更多自动化测试相关知识:https://www.aichudan.com/xwzx/

联系电话

17727591462

返回顶部