该怎么测就怎么测，三端都要测全了，如果有不一致的就提 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 地址

前端用的什么框架？

可能不同业务不一样，我们的产品我看了下我们所有的脚本，排除 Log().log_info('xxxx') 之类的日志脚本，和前面默认初始化的代码行数，整个测试用例里面需要自己编写的脚本确实 20 以内可以搞定，个别复杂的场景另说，一般我们会把重复的场景和常用的方法进行封装，这样能减少脚本代码的编写量，你们可以试试

几年前的版本的 BUG，经过这么几年 release 的好多版本应该修复了的，之前滑动之类的都有问题，多谢反馈

all in 啥，不都还是写个测试脚本。。。

你们有 airtest 在小程序上的成功案例吗？刚搜了下没找到相关成功的网文

多谢，这个框架几年前我们试过，里面有些 api 方法有 BUG，调用不了，所以当时放弃了，你们是有成功的案例吗？有的话能否推荐一下

没有

如果有合适的业务场景能把俩接口串联起来，一般串起来的接口都是一个写库或者改库的接口 + 一个查询的接口，你这俩查询的放一起意义不大，不如分开呢，俩查询的接口最好上游接上创建或者更改数据的接口

如果能导出 charles 的文件格式就完美了，因为我们提交 BUG 都要求附上 charles 抓包文件，现在开发都是使用的 Charles 抓包和调试，如果能解决这个问题就完美了，否则还是需要多安装一个 charles

手机传 PC（QQ，微信，企业微信，钉钉等 IM 软件），PC 截图（截图软件或者 QQ，微信自带的截图功能），手机传手机（QQ，微信等 IM 软件，或者将图片发到有隐私控制的社交 APP 上，比如微博之类，这样另一个手机访问这账户的内容就可以下载图片）