速记:SFDC 2016 - SegmentFault 温盛章 《说说 Android UI 测试的那些事儿》.docxVIP

速记:SFDC 2016 - SegmentFault 温盛章 《说说 Android UI 测试的那些事儿》.docx

  1. 1、本文档共8页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
主题:2016杭州开发者大会—移动端分会场 时间:2016年12月10日下午1:40 会场主持人:独立开发者(奇点微博) 图拉鼎 议题:《说说 Android UI 测试的那些事儿》 讲师:SegmentFault 温盛章 温盛章:问一下有一个比较好玩的问题,各位做安卓开发或者IOS开发任何客户端开发有多少是做UI测试或者单元测试有做过,基本上不多,我讲这个东西就比较有意义。 今天要讲的东西是安卓一个测试的东西,包括现在是SegmentFault现在正在做,首先感谢到SegmentFault的会场,我作为一个工作人员又是嘉宾,非常感谢这么多人来听大会,我的英文名gemini,中文名叫温盛章,在SegmentFault担任移动端的开发,说一下自己的东西,我一个大概简介就是这个,Gemini,外号已婚,我是SegmentFaultFor为安卓的开发者,是我一个人完成的,抬头是移动端的负责人,是安卓开发者,但是是果粉,最近爱研究Engine IO。我在接受自己人采访的时候曾经说过一句话,程序员的使命是使人失业,现在做的事情需要人工做的东西全部做成自动化,自动化的过程是人力淘汰的过程,所有客户端其实是淘汰人员一个过程,我们所做的一切事情都是使人失业。这就是关于我的一个介绍。 今天看一下整个的目录,我讲这个分享的时候,当时的一个问题也是这样,我们六七个安卓开发者聚在一起,我突然抛出一个问题,我说你们公司有做测试,无论大公司还是小公司你们公司有做测试或者写单元测试,跟刚刚一样六七个要么没有人举手,刚刚这边有一两个人举手。看到所有开发者去测试这个项目,可能没有人重视这个事情,可能测试这个东西无关紧要,或者抛给测试人员去完成就行了,这里说的测试的意义,如果用机器做完所有的测试我会觉得非常的爽,这是一个程序员对自己价值的一个实现。 接下来介绍一下测试的颗粒度,这里简单的介绍前两个非常细颗粒度的测试,单元测试和集成测试,会介绍今天的重点UI测试,接下来介绍一下Mockito和Dagger,最近接到安卓的客户断,最后一个是今年我在整的CI的应用。我们可能滴滴工程师一样用的GKS(音)我们用的GTLPCI(音)。 我们在讲测试的时候我们在讲什么,我们希望产出开发出来的时候是希望一个结果,希望做回归测试减少测试人员的开销,就是让他失业,第三希望把复杂无趣的工作做成自动化,做一个流水线的工作希望写一个代码把这个工作解决掉,释放自己的双手。这是非常爽的事情,讲测试的时候刚刚说的颗粒度,大概有三个颗粒度,第一个单元测试,第二集成测试,第三个UI测试,在这里给了它一个金字塔模型,大概是这样,也就是说集成被DESUI测试,单元测试是DES集成测试,比如说单元测试针对于程序模块,软件的最小设计单位进行测试式检验的操作,就是java的方法,方法有输出和输入,只要输出1和2,只要输出3,等于这个方法是正确的逻辑,1和2输入4这个方法逻辑肯定是错误的,这里检查的输入与输出,单元测试是一切测试的基础,只有通过单元测试才有条件说集成测试或者UI测试,之前写测试的时候我自己有一个坏毛病,可能当时想如果测试的覆盖度不能去达到百分之百,那我们做测试有意义,后来想明白这个问题,这个是有意义,现在做的UI测试覆盖度不是百分之百,当时给我们的产品给了一个目标,立了一个目标,我说自动化掉50%的东西已经非常欣慰,就是说我们公司没有测试人员,只有产品人员去做测试,所以说能减少50%的工作量这个事情已经很让我自豪。 看一下刚刚说的典型的例子,Int add,returnA+B,希望的结果是3,这是非常经典单元测试一个例子,我们做单元测试能使我们做组建化之前尽量保证原子性的正确,所以单元测试就是要保证所有的函数可测试的函数,输入和输出必须没有问题,这里注意有的函数可以测试,有的函数不可以测试,看一下集成测试,这里也叫主张测试联合测试,其实概念非常简单,把一堆的单元测试组在一块,它形成一个模块,只要保证模块的输出和输入是正确就可以,比如说有一些方法没有输出,因为可能改的类成员变量的值,这个成员变量经过一系列的修改达到一个期望值就好了,比如说像这个样子,有三个job,1和2改了什么,所以这个时候并不知道,它可能在也五原子当中一个事情,Gob1和2完成以后并不知道结果是否正确,所以经历job3就去拿下他一个结果,判断一下看到的结果是不宁唯是我们希望的结果,在单元但测试基础下做好基础测试。 再看一下最最重要的UI测试,当时对它的理解,UI测试到底爱测一些什么东西,这个问题其实是非常深刻,我当时知道UI测试的概念,然后并不知道我能找这个工具来做一些什么,然后我进入问题非常多的思考,我当时很早的时候比如说UI市给我的第一印象,可能检查一下界面元素是不是在我们

文档评论(0)

159****3685 + 关注
实名认证
文档贡献者

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

1亿VIP精品文档

相关文档