吓死我了

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

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

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

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

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

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

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

笑一笑 十年少

get macaca and uirecorder tools， thx

笑一笑 十年少

标题党

Sweetest

本人开源的项目：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LZ 你吓到我了

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

有必要吗？既然敢写，就已经实现了。

其实不是我实现了，而是 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 关系不大。

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

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

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

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

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

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

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

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

这是与你们 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 自动化测试、接口自动化测试的一些怪象。

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

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

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

这是事实。

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

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

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

我们也主要做接口测试

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

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

竟说废话 拉到吧

忍不住想问几个问题：

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

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

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

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

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

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

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

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

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

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

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

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

你这是在回避我的问题。

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

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

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

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

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

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

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

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

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

UI Recorder 要比Selenium IDE更加强大!

UI Recorder 非常简单易用.

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

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

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

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

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

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

不全是针对小项目，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 遍历能带来不一样的效果。

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

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

嗯，跳进坑里面了。

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

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

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

感谢大神前来参与。
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 实现。

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

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

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

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

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

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

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

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

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

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

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

这个数据怎么来的啊？

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

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

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

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

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

eTest 可以参考一下：https://alltheblue.github.io/docs/#/

亲测，官网链接里的 chrome 插件下载 404，这是多久没人维护了

一直有人维护哦，链接修改了哦