iOS开发教程:iOS UI自动化测试iOS开发教程:iOS UI自动化测试.doc

iOS开发教程:iOS UI自动化测试iOS开发教程:iOS UI自动化测试.doc

  1. 1、本文档共10页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
iOS开发教程:iOS UI自动化测试iOS开发教程:iOS UI自动化测试

iOS开发教程:iOS UI自动化测试 一、关于iOS UI自动化测试? 要测试一个已成型的应用,从用户所见的角度来做自动化收益还是比较高的。 目前了解的UI测试方法分为两类,一种是iOS4提供的UI Automation,一种是把测试代码注入到应用中。 1)iOS4的UI Automation   用JavaScript驱动在应用上模拟用户行为,由 Instruments的Automation工具执行。具体的可以参考这篇文章在iOS 4 中实现UI自动测试,操作很简单,先编写自动化测试的Javascript文件,在Automation工具中选择这个文件,选择测试的target(模 拟器和真机都可以),然后点Record(这个名字起得很坑爹,我一度以为它支持录制,像Selenium一样转化为js代码呢),此时会运行所选的应用 同时自动化脚本也开始运作了。   API可以在SDK Developer Document里找到,主要的是UIAElement、UIAElementArray、UIALogger这几个。但是API不是很完善,比如我要得 到整个elementTree可以通过UIATarget.localTarget().logElementTree()得到,但是没有API能获取所 有的Element,获取Element只能以获取子控件的形式一级一级查找,最后的代码可能就会变成这样:   window.tableViews()[0].cells()[1].buttons()[2].tap();   即使可以通过button的name直接找到这个button也需要写成这样:   window.tableViews()[0].cells()[1].buttons().firstWithName(search);   非常难看难维护。我尝试遍历一个view上的所有控件整整运行了两分钟。   另外推荐一个测试框架,Working with UIAutomation这篇文章中提供了tuneup_js这样一个框架,封装得非常简单,除了没有before after之类的封装外对我来说暂时已经够用了(需要每个case执行完后或者执行开始前恢复默认状态,不过这个很容易实现),可以参考。 2)测试代码注入到应用代码中   大致的思路是,新建一个测试的target,在 applicationDidFinishLaunching最后创建一个测试对象,这个对象封装在测试的代码中,那么此时这个target就是应用+测 试的新的东西了,安装后可以看到应用一直在模拟用户行为,也就是测试代码在运行。   这种测试方法其他部门的同事在研究,这里可以介绍几个测试框架:   FoneMonkey,这是我最早接触的iOS自动化框架,支持录制回放,但是不知道怎么对结果做验证。如果仅仅是录制回放的话,UI Recorder已经挺好用了。   Bromine,这个框架还不错,封装到最后只需要填几个Plist就可以完成testcase,只是不方便扩展,可以模拟用户行为无法做数据验证,同事基于这个框架在做定制,想法是做成C/S模式,这样如果server端没有发送请求测试就不会进行。   Google Toolbox for Mac (GTM),Google的一个开源项目。GTM + TestMerge.app = UI testing bliss据说也是类似的思路。 总结存在的问题:   iOS4的UI Automation有一个硬伤,就是4.0以下iOS不支持,这对自动化来说是打点折扣的。但是既然是Instruments的工具,不知道能否和其他 工具一起使用,比如用leak检测内存泄露,比如用UI Recorder记录操作,然后回放到低版本的iOS设备或者模拟器上,可行性没了解过。   第一种方案使用Javascript,相对第二种方案的Objective C上手还是要简单一些。   需要解决的问题还有,如果应用crash,测试就不能继续了。如果crash后重跑下一个case,那就不能有case之间的耦合。如何重新运行app有待研究。   另外以上两种方案最后都要做到可持续集成,第一种方案需要做的是把 build app、run app testcase、generate testresult整个流程串起来,Automation这个工具提供可以测试报告,Instruments可以Shell运行,是否可行还需要研究, 如果行不通的话可以尝试用Apple Script运行;第二种方案难点在于如何生成报告,需要把测试的log重定向到某个文件输出,这也是他们准备做成C/S结构的原因之一,可以在 server端直接得到测试结果。 PS:如果测试的不是客户端而是web应用的话

文档评论(0)

cduutang + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档