确实是一个痛点，想象一下一旦你的手机丢失，你能不能想起你的银行卡挂失电话，你的支付宝挂失方式，你的各种邮箱密码重置。。。不法分子可能比你下手的速度快得多。

不错不错，python 脚本，我喜欢。但是感觉楼主还没说完，毕竟光录制成脚本还不够，如何断言如何处理 log 文件这些都还没说

别不服 保洁阿姨管……你们那的卫生

人工智能太牛，一直想把 Siri 培养成女盆友，无奈她就是不从。。。哎

感觉很好吃呀，表示从来没吃过这么好的午宴（乡下土包子大雾脸）

感谢分享。用 Uiautomatorviewer 获取静态的 native 控件是不错的，但是动态的 UI 下（比如说播放音乐时，屏幕上有进度条之类的动态元素），或导致 Uiautomatorviewer.dump 失败，获取不到元素，怎么处理呢？

#4 楼 @ycwdaaaa 人艰不拆，人艰不拆

#2 楼 @ycwdaaaa 看下限就行了

主要是还是算人力和对计划突变的应变能力——反正我是跪了，怕得罪人，当不好管理

现在很多 app 页面上都有动态元素，这会导致 uiautomator.dump 失败，有什么办法解决这个问题吗？

一般感谢开头的，都是地图炮。。。

#20 楼 @ycwdaaaa 嗯，这个方法是挺好的，只不过我们的关键字驱动框架改起来很麻烦，一条一条的，从脚本设计之初就要考虑到要不要保留数据，牵一发动全身很痛苦

#18 楼 @ycwdaaaa 他又要保证回归测试的正确性，又要测试稳定性，二者兼顾。几千条 case，要都分割独立化的话要执行很久

#16 楼 @ycwdaaaa 我尝试用你的理论去和老大讨论，被反驳的重点也是执行效率问题，太费时间了。我们做 UI 自动化，每条测试用例结束后数据都恢复初始化，无形中也会降低给予设备的 “压力”。这一点不知道你是如何考虑的，可能业务不同，出发点也不同吧。总之会谈不欢而散，谁也说服不了谁，继续深陷在维护用例的泥潭里

此一时彼一时。。。在这个充满变化的时代，保持学习的态度很重要。我是小吊丝一枚，我没有话语权，我只想在腥风血雨的江湖中有小小的一片天地。

写得好，赞~然而我们做 UI 自动化测试，业务不太一样，写着写着很容易 “变味”，变成了脚本迁就软件质量的情况，而且这个泥潭越陷越深，每次版本迭代都要花很大力气去 review 脚本实现 ‘pass’，有种本末倒置的感觉，然而关键字驱动的框架并不能很好的改善这个情况

KPI
Scrum

#7 楼 @edwardxer 感觉这东西还是太大了，要是能做成别针/扣子那样便携会好很多

还不支持 IOS？

哎 这要是在帝都削尖了脑袋都要去啊

#47 楼 @nicoc 梦想是要有的，万一实现了呢？世上本没有路，走的人多了，也就成了路。测试本来不值这个价儿，喊得人多了，也就成了价。

#12 楼 @seveniruby 这样的 hr 也是毒瘤啊

就喜欢看楼主的长文，不管看不看得懂，为楼主的分享精神点赞

这帖子要能匿名的话反响会更热烈