增量覆盖率

把常用的 ui 自动化 adb 命令化，然后就可以用 adb 做自动化了

那叫接口测试，不是 ui

面试造航母实际拧螺丝，没听过么？

root 会创建，访问目录失败?kidding...
同鞋啊，linux 基础啊。
之所以不用 root 账号是因为 web 应用的安全问题。

同鞋，这个所有手机都要设置的呀。

应该是考察 ascii 编码吧。作为一个测试，你是否还会考虑字符是否为空，特殊字符，空格，字符长度等情况吧。编程能力和测试能力一起考察了。

这很正常，谁叫咱们年轻时不好好读书。平常心就好啦，每天进步一点点，等机会来了你才能把握好。

技术其实没你想象的高端，中级还是初级只是个 title 重要的是努力干活，不懂就问。我觉得你的组长也会看在眼里的，一般管理者都只看结果，而你需要发动身边的人帮助你，一个人的能力是有上限的，寻求帮助也是种工作能力。

没懂你的意思，你说的是 stf 的开发代码怎么部署么？跟 ci 有啥关系?如果是代码调试你得做好单机开发能力，stf 那边是推荐使用 ubt 作为开发电脑系统，所以他们本地就能调试。我们当时是搞了好几台 ubt 的电脑作为开发环境。

diy 一个大功率的充电模块，给每个 hub 充电。

wifi 是可以的，但是我们为了避免上网和 adb 通讯间的冲突不考虑使用 wifi。而且手机数量上去了，占用 wifi 的带宽会影响到通讯质量。

谁轻轻召唤我。

寿险真牛 B

并不是，logcat 都可以打开，只是参数不同导致 adbkit 出 bug。

越级说，没技术没能力的 leader 直接干掉。

面试造航母实际拧螺丝。

问什么快速排序，根本记不住。每次面试前看看而已，要问就问哪种排序算法比较快嘛。

外观很酷炫

这个观点同意，测试覆盖率性价比最高是在 70% 左右，再多了其实差别不大，然后需要更多 code review 去发现问题。

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

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

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

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

基础最重要。