自动化工具 UI 自动化技能可能被 UI 录制替代

qianxing for 点点点 · September 21, 2018 · Last by 克克克劳德 replied at March 16, 2020 · 13447 hits

背景

  1. 本文关于UI自动化观点是根据macaca+uirecorder(两年前已实现)的思路而来,对于用例生成规则、特殊页面处理规则都有研究与实现。
  2. 本文观点来自过去几个月查看社区关于自动化的帖子而来,抱着介绍当前自动化的现状而来,批判当下测试领域UI自动化测试、接口自动化测试的一些怪象。
  3. 鉴于本文观点引起争议,限定本文提及的UI自动化不涉及APP端电量测试、弱网测试、稳定性测试、兼容性测试,将APP端电量测试、弱网测试、稳定性测试、兼容性测试等归入APP专项测试。
  4. 文中观点比较尖锐,如引起个人不适,请在本文后提交批评意见。

一、UI自动化测试

使用macaca+uirecorde简化UI自动化工作。

1. macaca

macaca官网
github官方仓库

2. uirecorder

uirecorder官网
github官方仓库

3. 框架优点

不多说,减少大量人力,即便BAT公司所开发的APP,1~5人可以使用macaca+uirecorder可搞定公司所有APP的UI自动化测试、WEB端UI自动化测试。平常1~2人维护便可。

4. 前景

云测平台,UI自动化集成到云测平台。不多说。

5. 影响

对不起,UI自动化不能算作技能了,招聘过程中不会招聘目前仅仅用selenium写脚本的UI自动化工程师了。但是会有招聘优化录制脚本的工程师岗位、UI自动化平台开发人员。

6. 展望

UI自动化录制、自动遍历是近期小目标,人工智能+自动化遍历是UI自动化终极目标

7. 仅以WEB端举例说明(用例均使用UI录制脚本或者优化录制代码实现的)

实例一、判断testerhome精华帖,效果如下:

(1). 第1次运行25个页面

(2). 第2次运行70个页面(mochawesome报告)

实例二、检查腾讯财经频道页面加载时间(默认超时时间为30s)

21分钟生成200个页面的用例,未添加其他断言。

二、接口自动化

翻了一些简历,发现一些所谓的接口自动化就是使用python或者Java编写了一段代码,去执行Excel或者数据库里面储存的测试用例。

1. 著名自动化框架(欢迎补充)

(1) Python
pytest、unittest、nose
(2) Java
Junit、testNG
(3) node.js
mocha、jest、jasmine、qunit
(4) c++
googletest

2. 如何高效的进行接口自动化

编写测试自动化代码(不仅仅是脚本),与开发代码集成。

3. 编写接口自动化测试代码的好处

(1) 持续集成
与开发代码一起进行持续集成,测试过程中代码可以与开发代码一起编译,可以及时发现开发提交代码问题。
(2) 开发同学也可使用测试代码
接口自动化代码不仅仅被测试使用,也可被开发使用。
(3) 促进测试、开发之间相互学习
目前IT行业也有许多测试无法胜任的事情,部分项目开发编写的代码多数测试已无法全部理解,测试仅仅进行功能测试、接口测试已无法保证质量。
随着行业的发展,IT行业最终将仅会剩下很少的测试工程师岗位,测试工作(无论是单元测试工作、接口测试工作、UI自动化测试工作)大多数将是开发工程师完成的,现阶段的测试工程师、开发工程师相互学习,可以更快的到达这一步。
(4) 便于统计分析代码质量
什么单元测试代码覆盖率、接口测试代码覆盖率,都是通过现有工具可统计的。
(5) 接口自动化用例维护
根据代码特征、代码文件可以将自动化测试脚本元数据提取出来,存储到数据库中,没有现阶段手动维护接口测试数据的问题。

4. 前景

只有软件开发工程师,测试工作是软件开发工程师的一部分工作。
现阶段不会写单元测试的开发工程师会被淘汰。

5. 影响

花了几个月,写了一套牛X的接口测试框架,厉害了。但是对不起,建议你使用开源的测试框架,不要浪费时间、资源在自以为牛X的测试框架上。

此外,测试框架真的是你写的吗?最多算作你封装了一个或者几个测试框架而已。

大牛们请绕路,测试框架还是需要大牛们开发的,而不是几个拿着一个封装了几百行、几千行代码的人开发的。

三、性能自动化(仅指接口性能)

使用nGrinder、jmeter搭建性能测试自动化平台,鉴于本人暂未做过该部分工作,不做介绍。

四、测试工程师进阶之路

既然未来比较残酷,那就为未来做好准备吧。

1. 懂代码到写代码

(1) 测试工程师阅读开发代码还存在困难?
醒醒吧,找领导申请开发代码仓库的权限吧。
(2) 领导不批怎么办?
github中比你公司开发编写的代码还要优秀的代码多如牛毛。

2. 懂代码到懂业务

(1) 不仅仅是懂代码,也需懂业务
不多说,懂业务才能给公司带来营收(盈利)。
(2) 懂业务,淘汰不合理需求
不多说

3. 深入了解系统原理、测试框架原理

纯走技术路线,python、Java等开源的测试框架,也可去贡献自己的力量,甚至创造全新的测试框架、自动化测试工具。

4. 懂代码到懂质量

单元测试、自动化测试是保障软件质量的手段,软件质量保障不仅仅限于代码层面,流程控制也占据十分重要的地位。

此外软件质量评估、评估开发人效需要收集大量质量数据,通过整合各个组织内部的质量数据,提供管理者决策数据。

四、备注与版权申明

本文为原作者在segmentfaulttesterhome知乎同步发文,转载请注明原文作者。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 86 条回复 时间 点赞

吓死我了 😃

看了ui的框架,给年轻小白用比较好些,复杂的需求还是自己造轮子吧。开发项目适用的框架才是最优选。淘汰99%的ui自动化有点夸张,看标题以为是划时代的AI自动化测试要来了。。。

1988年世界末日
2012年世界末日
2020年世界末日

点击率、回复率、超自然力、超前力

4Floor has been deleted

对不起,httpclient+sikuli也可以解决99%的问题,怎么测试是根据业务来的,你说的99%可能是你的业务形态对应的测试而已

另外,别老UI自动化UI自动化的了,你说的是通过GUI实施的自动化测试,并非UI自动化测试,UI自动化测试到现在为止还没有什么突出高效的方案呢吧

现阶段测试圈乱象丛生,也可以说是百家争鸣吧,多数都是理论大于实践,你这么说也没什么错误,毕竟正确的话都是废话,希望有创新大于airtest的新东西不断的涌现出来,毕竟只有一个airtest过于狭隘了。另外我也觉得会ui与接口自动化毛用没有,门槛太低,毫无安全感,已在深入研究开发技能,本着学习python的态度造了几个轮子,现以转入学习app开发技能。

现在市面的工具还不如自己写框架呢,和开发代码持续集成,依靠代码特征、代码文件可以将自动化测试脚本元数据提取出来,存储到数据库中,没有现阶段手动维护接口测试数据,基本没有可执行性,框架也没有可推广性。而且接口测试稳定的原因,基本上接口报错只因代码迭代,维护版本的代码迭代数据我想是相对轻松的把。

9Floor has been deleted

笑一笑 十年少

get macaca and uirecorder tools, thx

笑一笑 十年少

14Floor has been deleted

Sweetest

本人开源的项目:

  1. Sweetest:自动化测试解决方案,支持 Web 测试, Http 测试,DB 测试,Android 测试,以及小程序测试
  2. Doo:接口文档及 Mock 服务

在 TesterHome 的开源软件里有,你可以了解一下~

槽神 回复

大神,你们弄的macaca+uirecorder,跨平台都能支持,也挺好用,关键是如何保证框架的稳定性、跨平台兼容性。

uirecorder只是其中的一种录制实现方案,但是你们可以做得更强大。

yca 回复

圈子太杂,通过uirecoeder进行ui自动化录制没有任何技术难度(安装过程可能会出错,但是对于一个精通Java、python、node.js的人都能解决,debug一下的问题)。

yca 回复

本来想写目前整个自动化现状,但是太晚了,还没有考虑性能测试自动化。

letme 回复

主要是提取case名字,主要还是编写测试代码。
对于如何提取用例特征数据,普通测试人员无需关注,这个可以交给测试框架处理。

qianxing 回复

早年间用过qtp玩儿录制,坑的要死,从此对所有录制的东西一律持有抵触态度,个人观点。airtest是个例外,正是因为录制没有技术难度才让人坐立不安,危机感一直都有…

Bach 回复

只说目前能做的事情,至于怎么安装使用macaca、uirecorder不copy教程了。

wtnhz 回复

是的,标准的标题党。
本文只是对于那些还在学selenium的同行说明一下当前技术的现状(已经实现的、别人家已实现的),想想还在使用selenium编写所谓的自动化意义何在?

24Floor has been deleted

随着各种开源框架的发展,自动化测试的入门门槛确实是在降低。
但是“99%的 UI 自动化技能转瞬即可淘汰” 这标题也太危言耸听了吧。 怎么定义 99% ? 怎么定义“转瞬” ?

其实自动化测试也就是一个如何使用工具的问题, 工具发展越来越先进和智能,但不代表工具就能完全替代工具使用者啊, 应该是继续使用先进的工具来做更深层次、更高目标的事情。

举个例子,现在的摄影技术越来越先进,各种器材黑科技层出不穷,随便一台智能手机的摄像头就能吊打几年前的卡片机。但也没见 99% 的摄影师都被淘汰了啊,相反先进便捷的相机为摄影行业提供了更多的可能。

tonglei 回复

非常优秀,可以更进一步。
可以将抽象程度提升一下,并扩展支持的协议。

tonglei 回复

此外,互联网使用Java开发了大量应用,许多应用都是Java开发的,rpc调用可以考虑一下。

😂 LZ你吓到我了

29Floor has been deleted
30Floor has been deleted

读了几篇文章、了解几个框架,以为这就是全世界了!

ltyd5788 回复

有必要吗?既然敢写,就已经实现了。

其实不是我实现了,而是uirecorder实现了,但是可以在uirecorder上进行更好的开发。

楼主可以了解一下to b企业中动辄数百甚至数千的UI自动化的case体量下, 你这套理论还管用不管用。 UI自动化的难点从来都不在工具上。而是代码设计能力,在to b企业中,面对复杂的业务逻辑,海量的测试用例,大量的异步调用和异构系统中。 如何能使用代码把业务逻辑组织起来,稳定,高效,简洁的运行下去才是难点。 并且to b企业中产品维护多个版本。我以前的公司同时维护50个版本。 50个UI自动化的daily run,并且还要对一些重要环境进行UI自动化的巡检。 试问构建这个级别的UI自动化测试,谁敢用录制回放。 都是自己哭哈哈的写代码,一个case的不稳定都会带来巨大的人力成本。海量的case下, 如果代码设计的不好,一个需求变动对测试来说都是灾难级的影响。 大量的异步调用和异构系统。需要写代码轮询数据库,中间件,各种集群来判断任务执行状态和结果。所以楼主有机会去大的to b企业做做看,就会有不同的收获的

没有数据,全是感性言论。
我们是做技术的,不是唱戏的。

孙高飞 回复

额,UI是什么?不就是将数据展现出来给用户。
先看看react的UI公式后再看你的需求:

React设计理念中UI是用一个公式表达的,既然UI只与数据有关,UI自动化组织用例的过程也是组织测试数据的过程。
看你怎么组织数据,与UI自动化有成千上万的case关系不大。

magicyang 回复

macaca的核心开发大神在#5,可以咨询他uirecorder的功能是否如此强大,我做的事情也就是读完他们macaca、uirecorder的代码,做的改呗改呗的事情。

我不清楚阿里内部是否有功能更完善、更稳定的macaca、uirecorder代码,但是使用上述功能可以做到成本接近0的UI自动化。

至于如何优化uirecorder的录制脚本、如何优化uirecorder是各个公司的事情,当然也可依赖官方更新代码。

qianxing 回复

算了不跟你犟了,你先去大型to b企业里见见像样的UI自动化是怎么做的吧。去看看ibm,微软这些公司怎么搞的。 就是我在一家叫ariba的这种小型的to b企业里, UI自动化也不是你这么做的。等你理解了自动化是怎么回事以后再聊吧

孙高飞 回复

此外,不要把问题复杂化,UI自动化只与数据有关,与系统是否是同构系统、异构系统关系不大。

孙高飞 回复

1、录制不是终点,就看你如何使用这种思想、方法减少UI自动化成本。
2、不考虑成本,招聘几个、甚至十几个UI自动化工程师搞,定制化需求都能满足。
但是并不能说录制方案无法保证定制化需求,问题在于如何管理驱动UI的数据,同时录制的脚本也是代码,既然传统的UI自动化可以使用代码处理定制型需求,录制方案就不能编写一下定制化代码吗?
3、文中已经提到需要优化UI自动化脚本(代码)。

qianxing 回复

嗯嗯。你觉得对就行。 我们谁也说服不了谁。就此打住吧。 各自做自己觉得正确的事就好了

孙高飞 回复

换台手机ui自动化就跑不起来了。😏

0x88 回复

这是与你们app开发使用的技术有关,所以存在优化脚本需求。
此外,也可考虑对原数据进行处理,进一步优化录制脚本。

同鞋,你好认真哦。我只是看到你写的东西好搞笑想逗一下,举个例子,你给我扯到app开发技术。我想举个例子是比如华为手机不定时的弹出升级系统啦,你告诉我这个app开发技术有啥关系。另外请问你做过功能测试吗?写过多少条测试用例呀,怎么在快速版本迭代中维护测试用例?然后你再从ui自动化测试的角度去实现你的用例,再进而维护。你写过多少条ui测试用例?每个版本迭代你试一下维护ui自动化用例就好了,另外版本迭代周期是两周,然后你就会发现痛点,另外提醒一下,case有可能要废弃,也可能复用。你不要站在你的角度考虑问题,你试下站在你所说的5个人去维护所有的ui自动化测试用例中,这5个人之一。如果是我,给我再多的钱也绝对不愿意当这5个人中的之一,当然,可能我是要被淘汰的那一批人之一。

很不喜欢类似于这样的言论

言论真的有点狂,做技术就好好沉淀,别来鄙视流;其次这话就跟有些人说服务端不就增删改查一样的赶脚

飞狐 回复

关注点

  1. 身边暂无Android手机,Android应用实现与WEB端实现的原理一样,只是技术细节有一些细微差别。
  2. 工作中接触iOS测试较少,没有研究透,但是借助WebDriverAgent完全也可实现。
  3. 不鄙视任何人,只是透露目前UI自动化技术发展超出目前多数UI自动化的测试人员的认知。
  4. 本文提到的macaca+uirecorder可以实现高效、低成本的UI自动化,并不是本文第一次提及,请看uirecorder的介绍。uirecorder最近两年没有怎么维护,但是要知道那已是两年前的东西了。
  5. 当然也可使用airtest等实现,限于时间,对airtest进行录制研究不多,感兴趣的人可以去研究。
  6. 针对ycwdaaaa反馈的在企业内部用不起来,个人不赞同。
    目前研究确认:对于特殊页面可以使用某种规则引擎编写定制化测试代码;
  7. 回复0x88的疑问:
    华为手机弹窗问题、vivo手机需要登录vivo帐号等问题,属于移动APP UI自动化测试过程中的特殊情况,可以考虑运行自动化测试用例的手机上运行一个或多个特殊APP便可解决问题;
    根据目前应用UI录制技术过程中遇到的问题,UI录制方案毫无疑问与APP开发技术相关(移动端APP使用A手机录制的脚本在B手机上无法运行是常见问题,可以通过UI录制框架解决问题,也可通过优化UI录制后的脚本来解决该类问题)
  8. 通过UI=render(data)公式可以得出结论:UI自动化过程中UI展示的数据、UI交互的方式与数据存在直接关系。
    通过mock展现UI的接口数据完全可以实现与后台业务流程无关的UI自动化。对于那些前后端耦合程度较高的应用(主要指在后台动态生成包括数据的html文档的应用),本质上可以将那些html页面看作接口,通过mock也可实现。

仅以WEB端举例说明(用例均使用UI录制脚本或者优化录制代码实现的)

一、判断testerhome精华帖,效果如下:

  1. 第1次运行25个页面

  2. 第2次运行70个页面(mochawesome报告)

二、UI录制2B业务遇到的问题如何解决?

2B业务过程中可能遇到大量表单应用,UI录制过程中遇到问题较大的是新增表单。但是UI录制过程中可以通过提交新增表单的POST/GET请求的数据,进行测试。
对于特殊页面可以使用某种规则引擎编写定制化测试代码,规则引擎本文不做说明。

文字 回复

不仅仅于此,最主要是批判当下测试领域UI自动化测试、接口自动化测试的一些怪象。

48Floor has been deleted

问题来自社区,我们同事都是大牛。

  1. 已界定范围:判断testerhome精华帖
  2. 截图仅仅是一个最基础的helloworld示例,用例失败是因为增加的断言导致的(文章不是精华帖导致的),截图中没有收集报告数据;
  3. UI自动化代码已存在,要做浏览器兼容性测试仅仅是换一个终端而已:可以通过图像对比对比不同浏览器的截图来实现,当然喽可以截图让测试人工辅助测试。

之前也用uirecorder录着玩,改脚本好烦,还不如直接手写,遂放弃之

linpengcheng 回复

这是事实。

1、手机端录制比写代码快吧?移动端录制的脚本已经比大多数做UI自动化工程师效率高很多。
2、正因为uirecorder录制脚本效率慢,且录制的代码在不能在所有设备上运行,进而存在优化脚本的需求。
3、uirecorder已是两年前的技术,借助uirecorder的代码可以玩出更新、更高效的录制方案。

qianxing 回复

录制再修改 和 边写边调试 其实花的时间差不多 我感觉。工具千千万 自己觉得好用就行。其实录制回放的工具很多 uirecorder只是其中一个。

macaca和uirecorder 一出来我就用了,还给组内做了分享,不过,大家貌似都只有听的兴趣。针对楼主的发言,其实我有几个很现实的问题,也是我的领导们会问的问题,我想问一下楼主的情况,请问:楼主目前在做的UI自动化有哪些?目前的case量级多少?不管是录制还是修改还是编码,完成case需要多久时间?维护又要多久?收益如何?版本两周一个迭代的化,如何有效开展UI自动化?这些问题,也是我目前遇到的问题,搞了三套UI自动化(包含uirecorder),最后使用的还是编码的那种,用着方便顺手,这不是重点,重点是做了一年多收效甚微,最后经过和老大讨论,就暂停了,专心做接口的自动化,收益高嘛,那么楼主的情况呢,纯讨论,不喷任何人

tester 回复

我们也主要做接口测试

tester 回复

本人目前工作过程中UI自动化做得很少,主要做接口测试。
关于case数量、录制与编码时长的问题回复如下:

  1. 录制与编码通过优化后,可以在一天时间内完成一个APP所有一级入口、二级入口、三级入口的覆盖;
  2. 录制过程中存在特殊页面(主要是填写表单页面),这块可以结合规则引擎特殊处理(如果新增表单页面不变,可录制一次多次使用);
  3. case数量与App的复杂度有关,但是录制过程中也考虑了App主要功能;

竟说废话 拉到吧

qianxing 回复

忍不住想问几个问题:

  1. 题主既然很少做UI 自动化,是从什么方面得到 99% 、 95% 这样的数据呢(实际项目统计? 问卷调查? 实际测评对比?)? 还是只是来个吸人眼球的标题?
  2. 一天时间内完成一个APP 的所有一级、二级、三级入口的覆盖: 请问这个 APP 的体量有多大? 页面入口总共有多少? 一共有多少个用例? 录制回放成功率多高? 后续执行稳定性如何? 和完全手动编写的脚本或者用例,这几方面的对比又如何?
  3. 一个项目做UI 自动化, 框架搭建和维护(用例管理、失败重试、报告生成、数据存储维护等)和脚本用例的设计、编写/录制、更新维护、失败用例分析和bug确认, 这些工作分别占多少的比例? 这里面分别有多少是属于你所说的 UI 自动化技能,其中又有哪 99% 是会被淘汰的, 哪 1% 是不被淘汰的?

如果有实践,请拿出数据来说服和警醒广大无法理解的人,谢谢!

Jerry li 回复

1、99%表示目前许多人搞的UI自动化已无效率意义、属于浪费时间、浪费测试资源的事情;
2、玩过QQ音乐、美团、京东这样的APP,录制回放成功率与自己优化录制脚本、自己UI自动化的经验有关;
3、用例管理用代码管理没毛病(如果要将数据存库的话,文中已说过可以自动生成用例存库)
4、失败重试本身mocha框架支持,macaca用例用mocha驱动的;
5、uirecorder本身生成了测试报告,报告为html格式存储没什么问题;
6、用例更新维护直接修改录制的脚本(开发的代码可以更新,为何测试的代码不能更新?),但不仅限于此,看用的人自己;

Jerry li 回复

不一一回复,你提到的问题都不是问题。

有认识uirecorder作者的可以拉进来讨论一下uirecorder最新情况

从上到下把文章和楼主的和大家的观点看了遍。99%的问题,不用多说,给我的感觉是2012世界末日来了。uirecorder录制问题,前面有同学说过类似的问题,例如华为系统升级或者其他app的广告也好,会造成你的case不稳定,你后面解释说可以专门的针对类似情况去做脚本调整,OK这个思路是没问题的,不过可以提醒一下楼主,想的万分简单,做着千难万难,很多突发情况你是没有办法去预测的,录制脚本只是一种借鉴的手段,如果高效的让自己的脚本快速执行起来才是最终的目的,这个需要考虑到后续业务需求的变化,脚本可维护性,诚然录制脚本可以减少大量时间,只不过你只是针对你自己企业内部的业务需求,业务量的大小决定你脚本成长的方向。需求小,当然是简洁一点,需求量大的时候是否需要考虑到别的问题了。最后说句题外话,假如99%的人用UI自动化技能,几年内大家遇到复杂的业务逻辑,大量测试case,并且完美的解决这些问题,而你这1%的人用uirecorder录制脚本,只是修改了几年代码,我只能说抱歉,你这1%可能会被淘汰掉(个人观点,不代表大众)。

Whsnd 回复

1、无论华为手机、还是其他手机,系统层面的问题都是可以解决,最简单的解决方法将录制的脚本执行每一步前加一个前置检查,复杂问题可以考虑增加一个监控的app处理该问题。这是所有UI自动化都会遇到的问题,文中已说明需要优化脚本。

2、app中的广告也可通过优化录制脚本来处理;

3、吸收就业主力军的是中小微企业。
如果老板知道可以用一个录制工具搞定的事情,老板为何需要几个人去搞所谓的UI自动化?
欢迎各位在中小微企业的朋友尽早掌握录制思想。

4、录制也可以搞定BAT、美团、京东、今日头条目前投产的APP UI自动化。
uirecorder是阿里巴巴的牛人开发的。

5、录制技术不会止步不前。

发现设为最佳了不能继续讨论,欢迎大家继续吐槽。

qianxing 回复

你这是在回避我的问题。

1、99%表示目前许多人搞的UI自动化已无效率意义、属于浪费时间、浪费测试资源的事情;

-- 我就问你 99% 的数据是怎么来的, 数据如果是真的,就请严禁列出; 数据是自己瞎编的,就早点承认。

2、玩过QQ音乐、美团、京东这样的APP,录制回放成功率与自己优化录制脚本、自己UI自动化的经验有关;

-- 玩过代表实际项目经验吗? 录制回放成功率和经验有关, 手动写脚本同样和经验有关,有什么冲突?

其他的 3-6点, 都不是你说的这套东西创新出来的,而是现在大部分框架都有的功能。 你所指的淘汰 99% 技能,其实只有一个录制和手动写脚本的区别。

如果你认为录制就代表 UI 自动化的 99% , 那就没什么好讨论的了。

有啥好争论的啊,闲的蛋疼。

Jerry li 回复

不与你争论,请看uirecorder介绍:

UI Recorder 是一款零成本UI自动化录制工具,类似于Selenium IDE.

UI Recorder 要比Selenium IDE更加强大!

UI Recorder 非常简单易用.

至于是99%,仅表示UI自动化大量的工作(甚至中小微企业100%的工作)都会被UI录制取代(当然不仅仅限于录制,UI遍历也是一种方法,UI录制与UI遍历中间仅一个方法的差异)。

孙高飞 回复

兄弟我支持你的看法,我们就是大体量用例动辄成千上万的,感觉LZ说录制能替代自动化代码的,只是针对几十上百条案例的小小项目吧~~

qianxing 回复

你这楼的说法,我可以理解成你只是对Web自动化比较理解,而对移动端都是‘暂无Android手机’,‘接触iOS测试较少’。那你是怎么得出‘目前UI自动化技术发展超出目前多数UI自动化的测试人员的认知’?我想请问几个问题,你身边有多少专职自动化的同事?我觉得你最大的问题是,理解这个行业是与时俱进的,却否认从事这个行业的人也是与时俱进的。

qianxing 回复

"文中已说明需要优化脚本",你这说这话不等于白说吗? 出了问题你不优化留着干什么,对吗?而且我最后说的那个意思不是说录制技术怎么样,我的意思就是设计师设计好房子,你上手砌墙就行。

qianxing 回复

建议lz接着改标题名字吧,把转瞬去掉留个可能

Whsnd 回复

好的,后续再分享录制脚本如何快速优化

water 回复

不全是针对小项目,UI录制与UI遍历无本质区别。

  1. 喜欢折腾的同学可以拿着UI录制去学习UI录制背后的知识,以便更好的为UI自动化后续发展做好准备。老板们喜欢看得见的东东。
  2. 拿着UI录制的代码,自己动手写UI遍历的工具。
  3. UI遍历主要是采集数据,然后使用图像识别+规则引擎,实现极少人力参与的兼容性测试;
  4. UI遍历过程中产生的数据(截图、APP端性能、电量、内存、日志等数据),进行质量评估。

我就问一句:QTP是怎么被selenium rc和watiN他们赶下神坛的呢?只是因为license费用?
如果录制之后改一改就能搞定,这江湖可能还是Mercury的江湖,可能HP都插不上手去接了……

孙高飞 回复

其实应该建议楼主换工作,你写再多楼主也听不进去的。当工作中碰壁了就会体会到你所说的问题。我在以前团队也搞过自动化录制,包括遍历测试,深受其害。写出来的东西真的还不如手写脚本来得快,尤其在项目快速迭代过程中,等你分析出录制用例或者遍历工具哪里出问题,项目组的人都已经用人肉测完了。最终的结论就是录制工具和遍历工具不靠谱。老老实实写脚本用例。其中华为手机提示升级这个问题就是我当时做这些破玩意的时候遇到的,还有其他各种无法预料奇葩的问题。他还没遇到开发在某些ui留了个后台控制的界面开关这种奇葩功能,而且运营的同鞋特别喜欢随性的去开启或者关闭。只能说楼主too young too simple。当然可能ai遍历能带来不一样的效果。

0x88 回复

UI录制并不是使用屏幕坐标定位的。

qianxing 回复

这跟跟坐标没关系…你只是已经跳进录制坑里,拉都拉不回来。做技术要讲究取舍,录制脚本这技术可以作为简单的ui冒泡测试。级别不一样的技术得考量的级别也不一样,因为你现有的工作环境限制了你的思维,看事物的角度局限了。

0x88 回复

嗯,跳进坑里面了。

  1. 目前已有许多人盲目的跳进UI自动化的坑里面了,简历中做过自动化,但是做过的UI自动化case不及uirecorder录制的几个case高效;
  2. UI自动化投入产出比是目前许多中小微企业面临的一个问题,大公司可以招聘一帮专门的UI自动化的人,但是中小微企业可能测试团队就几个人,uirecorder是为这些人服务的。当然比不上专门UI自动化团队的人,也没有必要比。
  3. 我的工作环境确实限制了我的思维,因为我不专职做UI自动化。
  4. UI自动化对于培训机构来说可以忽悠住没有做过UI自动化、视野狭窄的人,让人花数千、数万RMB去培训,培训完编写的UI自动化脚本还不如uirecorder录制出来的脚本。
qianxing 回复

我重新看了一下,有点理解你意思了,只能说楼主语文不好。我来翻译一下你的意思。
我们这群懂一点点ui自动化测试的渣渣们,天天拿着这点屁技术招摇撞骗,会写几行就上天了吗?现有的企业简单的做个录制脚本工具就把我们替代掉了,测试还有很长条路要走,比如如何高效执行接口测试,单元测试,如何做好性能测试,如何做好质量这事,我们要跟开发一起好好学习,天天向上。还有还有,那个谁谁谁,现有这么优秀的框架和工具,这么好,还非得要自己写一个破框架有没有点创新,懂不懂什么叫站在巨人肩膀。哎,测试这项工作不会减少,但是我们这群渣渣再不进步就会被淘汰啦。
另外,楼主想吐槽这些事不要拿一些99%,1-5个人这种没有可比性的数据来说呀,这种做法肯定会被挑战。测试的实质是质量,质量本身可以很高,可能要求5个9的质量,也可以是一个9的质量,你不能拿1个9的质量标准做法去衡量一个5个9的质量标准项目。

0x88 回复

淡定点吧,这帖子热度有点高了,多说无益,伤神

槽神 回复

感谢大神前来参与。
QTP不仅仅是因为license问题而被取代,个人分析的原因如下(并不全面):

  1. 因为录制工具仅能完成录制工具本身的事情,而代码可以搞定几乎一切问题;
  2. QTP本身不是开源软件;
  3. 移动端测试框架与QTP没有什么关系;

而uirecorder弥补了QTP的短板,具备下述特点:

  1. 录制的脚本是node.js代码,可以任意扩展;
  2. uirecorder是开源的,任何人都可以拿过去进行修改,以满足自己的需求;
  3. uirecorder是macaca测试方案的一个简单应用,本身融入了macaca生态体系,具备移动端、web跨平台解决问题能力。macaca本身还具备多语言支持,uirecorder是其中的一种用实现,并非仅仅只能用node.js实现,还可使用Java、python实现。
qianxing 回复

我是弱鸡,不是大神😂 感觉你答非所问,uirecoder和macaca是QTP衰落之后好几年才出现的,没有任何联系,谈不上谁弥补谁的问题

QTP是最卓越的测试工具之一,除了只能工作在windows上、体量臃肿之外,其他方面,目前没有任何其他开源工具追得上,就是RF这么优秀的框架和selenium这样的工具,也不难看出朝着他靠近的心思和迹象,个人理解,可能不太对,比如:

  • RF的description-based case、keyword-driven设计等
  • selenium rc转向webdriver最关键的就是JS驱动操作变成利用JNI调用浏览器消息接口来驱动,这跟QTP的设计几乎一样了
  • ……

其实无论任何工具多牛逼,但这并不妨碍他衰落,因为每个时代总有无能的人,用不好QTP就说QTP不好用,不稳定,不好扩展,贵(一边破解一边喊贵),过几年,还是这波人,用selenium、sahi也没有取得超过QTP的成就,又开始推崇新的东西,虽然说工匠的技巧永远追不上科技的进步,但是在每个科技发展层次上,都应该本着匠人的精神把东西先吃透再去逐新才是

怎么感觉是一篇广告洗脑文……有种进了传销组织的感觉(我们的产品最好~我们的产品万能的~我们的产品一出其他的都是垃圾没用啦~)😀

槽神 用 Selenium IDE 录制脚本 中提及了此贴 11 Oct 14:46
qianxing UI 自动化技能可能被 UI 录制替代 中提及了此贴 18 Oct 11:33

看标题以为是多niubility的东西,是AI自动遍历什么的,结果通篇下来还是老东西。
UI录制很早就有了,看下来uirecorder也没有比其他录制工具更进步的地方,无非操作->生成可运行脚本,也就多了个报告。

UI录制之前为什么没有广泛运用,因为它看起来很简单,但实际上维护很麻烦,上面孙高飞同学已经都说的很明白了。
很多同学最后弃用录制而选用代码,因为Page Object设计模式是UI自动化的精髓所在。
一个页面可能有20个用例,如果录制要点点点二十次生成二十个脚本,但是代码将其封装成一个页面对象,只需要写一个脚本,用例调用页面对象,更改输入输出就好了。
这些优势在脚本为几十个的情况下看不出来,而上百上千甚至上万就知道差距了。

而且关键是如果这时候前端改了个页面元素,那么通过录制的20个脚本都会失效,需要重新点点点再录制。
最后,选用UI录制的同学会发现,还不如点点点来的快,他们放弃录制自动化而选择手工测试。而代码写的,只需要改动一个页面对象的相关代码就好。

你也可以争辩说,第一次录制,后面修改代码,那跟直接写代码有什么区别?一个页面对象顶多也就几十行,录制20个用例的时间已经够写好几个了啊。

qianxing #88 · July 20, 2019 作者
iced_me 回复

没有必要与不了解内幕的人争论。

selenium+sikuli+关键字驱动+自动生成测试报告+数据库,做成测试平台和工具。大体的功能已经实现!部分小的地方还需要改进。大家都是在摸索着前进,做个大概的框架,不停地改进。也没什么好批判的,我刚开始也是做了这么一个UI +接口的测试平台觉得可以了,后来在测试开发大会上见证了各种新的东西,才认识到自己的不足!!更坚信了要不断的学习完善自己的工具


这个数据怎么来的啊?

没有任何技术含量的文章,真的是测试这一行参差不齐,楼主思维逻辑不严谨,没有半点实际数据支撑,满嘴跑火车

瓜牛 回复

你没有做过怎么知道其他人与你一样呢?

废话半天,实际上就是要不要上PO模型
不上PO模型当然录制最方便咯,这就是废话

大牛,能否讲讲 ios ui 自动化

看了评论放心了,这贴也就是忽悠新人不懂的,或者说只是会一点点自动化或者写简单的自动化代码就觉得自动化多简单的了

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up