发版上线的第一原则就是周五不上线不发版，除非线上 BUG 紧急修复，否则不要触碰这个红线，哪怕上线很简单的优化或者文案修改

有实力就考公，这东西很难的，要有取舍，还要有综合实力，如果是学渣就算了

领导看中的多是结果和效果，要是我就偷偷摸摸搞，等有一定效果能拿的出手了再找领导，否则领导不会认可，应为自动化测试接口自动化见效快，UI 的见效慢

知道问题就已经解决一大半了，最大的问题就是不知道问题是什么

裁员了，我看每天我往大厂送的外卖也没见掉单啊

应该多讲讲从学生到社畜的惨痛过程，应该是经历了什么才会有转变要不不会理解什么是社畜

我们就是部署到 Jenkins 上，你是前端的自动化测试还是接口的自动化测试？接口的可以部署到部门的 Jenkins 上，方便同意管理和版本，前端 UI 的话，用本地电脑部署就行，看各自的喜好

iOS 自动化与 Xcode 版本，Mac 电脑的系统版本，手机型号和 IOS 版本都有关系，一旦找到一个稳定的组合不要轻易升级任何版本，否则就会出现跑不起来的情况，尤其是 IOS 版本，应为手机系统升上去就降不回去，基本就完犊子了，本人就在这地方踩过坑，对于 IOS 自动化测试来说非必要不用升级。

开滴滴，送外卖

小程序测试需要考虑载体的版本，高中低档手机上安装的支付版版本是不一样的，就算一样的支付宝，但是内置的小程序控件版本也不一样。最好让开发有在一些关键的功能上增加 log，这样方便定位线上偶现但是又影响用户使用的问题，应为你们的测试机有限，有些问题无法复现，就算开发改了你们复测不了，而且 IOS 和 android 的支付宝小程序要分别测试，会发现不少兼容性的问题。

该怎么测就怎么测，三端都要测全了，如果有不一致的就提 bug，要不功能多了，不一样地方多了，后面会很麻烦，谁对谁错都不好说，前期一定要保证，UI 问题该提就提，类型选 UI，优先级如果是 UI，可以适当降级一下，开发也不会太较真，说明事情原因就行

这是再给用户送福利

1. 多在不同手机上跑跑 monkey 和遍历
2. 开发要做 code review
3. 产品和设计要做验收
4. 测试环境和线上环境要保持一样，比如各种系统，插件，工具的版本

数据一般都有签名校验，不知道逻辑，只改请求参数是调不通接口的

1024 坦克大战，弄了几个坦克积木

自动化测试要考虑好投入产出比，否则不要轻易给领导承诺

这个可能与 appium 和不同手机平台型号系统的兼容有关，多试一些手机，找到最稳定的那款手机进行测试，保留系统并且不要升级系统，有时 appium 升级后会解决部分兼容问题，可以留意 appium 的更新计划，也可以给 appium 上报问题

用低一点的 android 版本手机试试，android 9-11 的手机

试试小中厂的测试管理岗

抓包只是手段，测试需要参考接口文档的吧，有接口文档使用 postman 之类的工具再进行测试，抓包的话已经到前端测试阶段了，接口测试应该是在这之前就应该进行了

python 的有吗？

黑盒模式下涉及金钱的功能，建议还是全部覆盖，毕竟用户的场景是未知的。
如何精简的话，最好和前后端开发碰一下吗，确认下共性的地方，然后精简用例数。

目前行情，中小厂都差不多，老跳也没意义，建议先待着

应该是一个封装好的开源的基于 VUE 的 admin 框架，楼主能否分享一个 github 地址