还是积分制比较好。
之前建议过，但是没采用。
虽然积分制也有各种各样的缺点，但是毕竟是被很多网站实践过的东西，好处还是很多的。

破坏性建议很难得到别人的认同。

老板说的有道理。

你的担心不是多余的。
我是极其不推荐去外包的，外包当然不是死路，但是最起码是一条岔路，有些人岔的没那么歪，有些人一岔就岔出这个行业了。
而且，从你组织的语言里也能看出来，你的顾虑是很深的，自己也很不愿意走外包，只是因为现在一直没工作压力变大了，这才考虑外包这条路。
这样的话，更加不建议你去外包了。

是污点。
楼上的很多同学都说了成长的问题，但是有时候 HR 根本就不看你的成长，看到你是外包就 Pass 掉简历了。
或许你的成长跟的上，但是在跳出外包的过程中依然难免备受冷眼。
再说另一面。
感觉你是因为找了一个多月的工作，都是外包给你发 offer，想着先入职，生活上不会有那么大的压力。
这其实是一种退缩的表现。
我只能告诉你，生活中每一次因为选择美好而做的坚持，最后都会在未来帮助到你。

标题很对立啊。

为什么我看到最后两张图，又想到了阶层固化。
最近老想到这个词，心累。

我此前也企图去报非全日制的，但是发现自己根本就没时间也没动力去做这件事。看了几天高数，做了一些三角函数和极限求值的题之后就昏昏欲睡，早上也很难起来背英语。
后来再一搜，发现深圳周边，只有中山大学有非全的招生，并且课程开设都是走正常的时间上课，据说是因为指导老师是兼做非全的，所以没有周末集中授课，并且往年录取分比全日制的还高，要 360 分，因为调剂的学生太多了，很多分数高但是学校差的学生都被更好的学校刷掉了（是的，本科差，研究生考试分数高也非常有可能被刷掉，反过来，本科好，分数稍微低点也很可能被录取），然后退而求其次来中山大学。
还有一些其他小原因吧，最后纠结了一年多，选择了放弃。
在我个人看来，你先别管行业认可度，你得想想你自己的认可度。有了这个非全研究生，你是不是更看得起自己了？比此前的专升本学历是不是好看多了？我相信这些回答应该都是肯定的，我此前无数次问过自己这些问题，都是肯定的。
其次，你得想一下，自己究竟可不可以做到每天在工作之后还要花六个小时去看书，坚持一年，甚至坚持两三年。是的，别以为自己一年就能考上，先不说你能不能考到好的分数，就算你考到了好的分数，就像上面说的，你在本科里已经是最差的了，专升本，很多全日制的本科，分数非常高，但是一到面试就被刷了（别问，问就是阶层固化！）。那些面试老师更喜欢同样是 985，同样是 211，同样是专业一流的学校出来的学生，这很残酷，但是这也很现实。
如果两件事你都能接受，那你快去做吧。
对了，你说函授的啊？函授的当我没说。

受这篇帖子的启发，我也对公司的 WEEX 项目代码做了覆盖率统计。
现在已经大体完成了。
这里补充一个踩过的坑，可能 RN 没有，WEEX 有。
Express 框架在调试的时候，会报一个错

Access to fetch at 'http://10.96.2.20:8889/coverage/client' from origin 'http://10.96.4.42:8092' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

具体错误的意思大家可以自行搜索一下。
补上修复后的代码。

var express = require('express'),
    im = require('istanbul-middleware'),
    isCoverageEnabled = true,
    app = express(),
    port = 8889;
var cors = require('cors')

app.use(cors())
// add the coverage handler
console.log('Coverage reporting at /coverage');
app.use('/coverage', im.createHandler({ verbose: true, resetOnGet: true }));

console.log('Starting server at: http://localhost:' + port);
app.listen(port);

最后提的三点，其实都是建立在有人可用的情况下，但是如果无人可用呢？相信你也经历过招聘需求紧急的时候，招了一个只适合当前最紧迫任务的人，但是当这段紧迫的任务完成后，发现这个员工的成长性不太行，一直想办法安排难度更高的任务给他锻炼，但是他一直完成的非常差，甚至存在隐瞒事实的情况，导致迟迟不敢放手让他去做，怎么办？

如果你要严格按照 pre_response 里的内容验证的话，看起来并没有什么比较好的办法解决这个问题，但是如果你放宽一点条件，比如每次测试有四五个 key 值不一致/缺失/新增的时候忽略掉这个错误，然后将返回值作为新的 pre_response 更新，或许可以解决你的问题？另外，92 就说自己是大龄阿姨，我也有感到被冒犯。

我是一个开发。
工作了好几年，佩服的测试也就 2 个人。
有时候 ，去面试的时候 也会和测试聊聊，会下意识的问 APPIUM 底层代码逻辑，修改网络通信达成分发执行的时候，没有几个测试能给出满意的方式。再加上日常观察，测试就是点点点或者复制市面上成熟的自动化框架即可，在日常工作中 ，没法找到我们团队的和 整个研发中非常严重的问题，有时候和测试聊天，问问他们下班时间有了解现有市场上新的测试方案和测试框架时，他们直接说：下班后就回家了。
不晓得是测试不愿意说 ，还是测试已经没有了自己的思想，不愿意追上最新的趋势，不能从最底层保证系统的稳定。 那测试到底有毛用呢？
于是鄙视链形成了。

启动 adb 服务的时候指定不同的端口，理论上应该可以解决这个问题。
或者按楼上说的，你把这几个软件里的 adb 都替换成同一个，不过有时候会有兼容性的问题。

就是一个是开发，一个是测试。
自动化测试想转型成测试开发，个人认为最好的办法是将你的自动化脚本写好，写成体系。然后在写好的过程中，处理各类 BUG，加深对代码的理解。顺其自然就能过渡到测开了。

每次都全跑，但是测试报告里需要特别标明，受改动影响导致的失败用例数，以及扣除这部分的用例后的真实通过率。然后安排人员在一周（时间根据自身需要来确定）内将用例修改好，保证下次测试前，成功率恢复到正常水平。

需要先把接口测试做好，保证接口返回的内容没有问题的情况下，将接口获取的数据和页面展示的数据对一个对比。这中间的工作量比较大，楼主如果想做需要做好心理准备。

楼主的观点蛮高屋建瓴的，上来就是学习了开发技术也无法做那个推动者，话事人。但其实我学习开发技术没那么高的追求，我只是想可以更加平等的和开发对话，让开发知道我不是好忽悠的，这个点其实就已经非常重要了，不是吗？

HR 也是背了绩效的，绝大部分你觉得他不好的地方，也是屁股决定脑袋而已。
所以没必要对另一个在人海里浮沉的人给予暗戳戳的恶评。

headless 模式执行，可以搭配一个截图操作，方便回溯问题。
你这样的描述 8 分靠猜，没办法分析出具体问题。

嗯，思想上不能投降很有道理。在无可奈何的时候，做出的选择才更能体现这个团队的所思所想。
之前面对这些问题更多的是无奈，现在是该去思考一下，怎么样选择才能对团队长期发展带来正收益了。
受益颇多，点赞支持一下。

说的挺好的，但是感觉更适合大公司，不着急招人，有足够的时间去淘候选人。中小公司一个是简历质量和候选人质量相对较低；一个是公司要招人的时候都还挺急的，没时间等那个合适的人。

因为你跑了两遍，所以有两个结果。
你把最底下的 runner 代码注释掉或者执行方式改为普通的 python 脚本执行方式，就只会输出一遍了。

还真是随性而为。

adb 点击是有一定的优点的，不过大部分时候都被它的缺点掩盖了，如果能将 appium 和 adb 的优点结合起来，可以做成一个非常不错的测试工具，或许不能独当一面，但是可以作为 appium 的插件，即插即用也很不错。