这样拆分，就算是部门 leader，也肯定会优先自己组内的工作。这种模式，有问题，甩锅项目经理，叫他去协调。

虽然在组织架构上还是一个，但是实际上根本不会 care 另外组的测试，在人力协助，问题沟通上更加如此，基本上都是各自有各自的规范

这个的关键就是你们部门 leader 怎么做跨组的沟通协调了，比如一起早会、周会啥的保持跨组沟通和信息同步。每个组自己的组长肯定首先关注自己组的利益，而这些跨组共同利益必须由部门领导来重点关注指挥。

在我们这，用户量很大，服务端和 app 端的灰度是必须的流程。
服务端灰度一般发现的问题较少，大部分测试都能 hold 住，但是也有极少数的情况发生，所以灰度也是必须的。
客户端的灰度，是实打实的能发现很多 crash 的问题，一般都需要二灰，很多情况，比如空指针，特殊数据引起的异常，在测试这边很难 100% 的覆盖。

测试应该统筹分配，统一管理，否则光是测试之间的扯皮就很耗时耗力

唉，某度某部门刚这么拆的，各有优劣吧，我理解就是瞎折腾，谁有话语权谁喜欢哪样就搞成哪样。

流程规范应该按照公司统一的吧，这种我理解就是虚线管理，我了解到的大多公司现在都是这种方式，至于个业务之间的协调配合建议项目经理协调，我司目前是这样操作的，所以不会出现不配合的情况，质量按各自业务划分就好了啊

我们每次发版都要通宵，开发通宵改 bug，测试通宵回归

哈哈是的，目前我们灰度只支持 2 家线上我们自己的公司，灰度也是在自己公司搞；一般灰度没问题了，线上就是切一下全量，基本能一遍过

我解释下，全量测试是晚上 10 点后接入，灰度是任意时间都可以。测试环境回归测试后，灰度到线上测试，发现线上环境导致的问题可以修复。这样全量发布时，由于已经灰度测试过，所以可以避免环境问题导致的 bug 修复验证时间，缩短全量发布时间，争取全量线上回归测试一遍过

我感觉应该是说，薪资还行，但是要加班，深夜加班还要通宵，不知道有没有解决这个凌晨灰度发版问题吧，避免加班。如果无法避免，可能就不去了~

你应该在公司待遇方面进行考虑吧...，既然接受了给出的待遇，那就不会对这个问题有忧虑。如果对方给出的待遇没能达到你能接受这样情况的话，那就再考虑其他 offer

多关注招聘网站的需求，按照招聘要求去学习不失为一个好的学习方式。

只会脚本怕是不行，要会写自动化框架

在招聘网站上找

OK，这个 Offer 没去了

没看懂

建议就是别去跳火坑……

一般这种年终特别晚发 的 别去

很正常啊，我就不信最后 A 的绩效能比 B 差，如果你遇到了，那么申请换部门或者申请裁掉领导吧
当然，如果这 50 个版本全部是在乱搞或者救火，根本没有任何业务价值，那就没办法了

很多业务测试，身上挂的 KPI 是，例如每年 P0 P1 线上 bug 不能超过几个。 那一个 A 同学全年繁忙，上了 50 个版本，做了很多，一个 B 同学一年很闲上了 5 个版本。 最后 A 同学背到线上的 bug 数可能远高于 B 。

做多错多，分情况，常见两种：
1.一直在掘新，新的业务知识，新的测试工具，手段，流程等等，没有成功经验的参照，试错应该是唯一的办法了，这种情况下减少错误，就是把必要的试错成本放在本地或者灰度
2.不整理，反思并且寻求已有，重复犯的错误的解决方法，老驴拉磨，做多错多。这种的换下这波人，让他们做犯错少的部分流程，把解决已有的错误，建立反馈机制，制定预防的流程写到工作内容里，做好向上管理。

测试为啥会做多错多