我现在还记得我刚入行的时候，都在说测试知识广度优先。后来工作多年后才醒悟过来自己被骗了，无论做什么都要有一门安身立命的本事，不断深挖里面的技术细节，然后以此为核心竞争力去扩展自己的其他能力。而在互联网这种技术一年小更新，三年大变样的行业里，还要求我们不断的拓展第二门，第三门拿得出手的副业，以防旧技术被淘汰而失去竞争力。

把你代码里的第二行贴出来，让大伙看看是什么命令导致的问题？按照我的经验，你需要在 Linux 下把 Jenkins 的权限改成 root 权限，这样 Jenkins 就能直接执行你的命令了。

水平是相对的，一个人只能判断与他程度相差不多或更差的人的水平，无法判断能力比他高很多的人的具体水平。所以评判这些东西的时候自己心里要有些 B 数，明白自己的定位在哪里。

实测了一下，还是有点问题，Delete 会把工程中存在加载关系的图片也一起删除，导致编包失败。你这边使用正常吗？

管理好自动化的投入和产出的预期。

set 去重，判断 0 的位置

a = [0, 0, 0, 1, 2, 3]
def get_num(a):
    a_set = set(a)
    if len(a) == 1:
        return "", ""
    if 0 not in a_set:
        return "", ""
    a_set_sort = sorted(a_set)
    num_0_index = a_set_sort.index(0)
    if num_0_index == 0:
        return "", a_set_sort[num_0_index+1]
    elif num_0_index + 1 == len(a_set_sort):
        return a_set_sort[num_0_index-1], ""
    else:
        return a_set_sort[num_0_index - 1], a_set_sort[num_0_index + 1]

干掉广告代码

人生有三重境界，看山是山，看山不是山，看山还是山。恭喜，你到了自动化的第二层境界了。

adb uiautomator 可以获取到 android 手机的控件信息，然后和自己提前设置好的控件信息 list 做一个交集。拿交集结果后可以获取到控件坐标然后做相应的操作。
中间还有很多细节，需要去适配，这只是大致的方法。

说的很实在。自动化测试的开展本就是要求贴合业务，脱离了业务的自动化落地困难，效果有限，并且难以得到团队其他部门的承认。

或许有些人从一开始就想着走所谓的知识变现的路呢？他只是成为了自己想成为的人不是吗？

收少了，这个世界可爱的人就这么多，收一个少一个，天花板很快就来了，要增加从每一个可爱的人那里获取的收益，抬高天花板。

本科应届生能拿 12K 的绝对不是大多数，一线城市就是这个价格的结论不知道你从何而来？啥都不懂的敢叫 12K，还有啥都不懂的敢叫 30K 的，问题是你应该不会给这种人 offer，对吧？通常我们把假如我有 XXX 我就能怎么样，当成是一种不负责任的吹嘘或者叫借口，你非常轻松的假定了你有 211 学历就能收获更多的工资，一来夸大了取得成功的某一种因素并忽略了其他可能更重要的因素，二来你也把你对现在低工资的不满归罪于低学历，这其实是非常不可取的。

mark 一下，和我现在做的思路差不多，不过我的整体进度还没有楼主那么快。目前只是把双端的性能数据采集完成，还没有实现图形化以及回溯功能。

人对于自己的焦虑，很多时候都是想的太多，做的太少引起的。

这一点优势可比其他优势好用多了。

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

这种锅都能甩测试头上，只能说你们的流程不完善。文案是产品或者运营负责，UI 就让设计把关，把这些锅分出去不就好了。

需要添加权限，系统管理->In-process Script Approval。里面应该有你报错的 new java.io.File java.lang.String 这两个类。直接点击 approve 之后应该就可以用了。

楼上很多同学说的都有一定的道理，但是相信还是不能很好的解决楼主的疑惑 ---- 既然接口是我手工测试时必须要验证的一个环节，为什么我还要花额外的精力去接口测试。
我就自己的经验试着去回答这个问题。
举两个场景：
1.每个公司都有的上报功能。
这一块如果做了上报接口功能验证，在客户端测试时就只需要验证相应地方是否生效，上报次数是否符合等情况，而不需要每次都去验证接口的内容。而事实是很多公司都已经做了基于 UI 自动化的上报验证测试。
2.某信息流公司要验证 10000 条拉取中是否会包含相应的正确的广告数量。
这个场景是涉及数量上的，有时要验证的不仅 10000 条。因为广告投放的数量和具体投放哪个广告都是有要求的，每个频道每个时间点投什么，投多少都不确定，信息流公司更是要基于用户模型来判断广告的投放。如果都是手工验证，肯定是验证不过来的。

当然，实际过程中肯定有更多场景必须用到接口测试，也有很多公司的 APP，web 等产品并不适合上述情况，说这么多只是想说接口测试的适用空间还是非常多的。

zhangzhao 大神一出手就是精品。
也非常期待大神能一起分享一下这个工具的产出效果如何。

我碰到过一种情况
界面总共有相同 id 的元素 0，1，2，3，操作步骤是要重复点击两次 3，点击第一次 3 的时候正常，第二次的时候要选择 7 才能点击到正确的元素，选择 3 的话会告诉你找不到元素。
所以，我猜测，会不会是被一层看不到的 UI 覆盖了什么的？

自己尝试一下就知道了。

adb 可以赋予手机权限，了解一下