1）如果只连一台手机 直接 adb install -r
2）如果连接多台手机 需指定手机 adb -s install -r
3) 查看 device_id 用 adb devices

看看如何嵌入到需求研发交付的生命周期里 作为质量卡点 其次除了服务好 qa 外 提升测试效率外 可以看看如果进行质量度量（客观数据 主观评测）

Monkey 更多是用来测试 App 的稳定性，主要看的是 ANR 和 CRASH 这两个指标，资源类的较少，常看的资源类指标是 CPU、Mem、GPU、FPS、Jank 等有系统 API 可以调用获取

早期快速迭代的产品最好的需求管理反而是脑图形式的测试用例，由于脑图天然的结构化，通过测试人员梳理后的场景做索引与聚合，补充历史需求文档的版本及实际页面截图与代码 CommitID 作为快速迭代的需求管理与资料存档是不错的选择，亲测有效，值得尝试

历史脚本 除非引擎版本已经不支持 所以线程组未做替换仍然使用 Stepping Thread Group 新的脚本默认使用 Concurrency Thread Group

基于 git diff 获取代码变更的方法 然后通过 callgraph 和 trace 获取影响的方法 接口 及 服务 即楼上同学提到的精准测试~

结合自己之前负责的业务特点来准备非功能的质量保障会好些~ 例如负责 App 发版 可以重点放在 App 的稳定性和兼容性上 负责风控策略类 可以放在数据质量及算法模型评测上 负责架构基础设施类 聚焦在性能、稳定性【混沌实验或公章注入】等

1、Stepping Thread Group 使用频率最高 官方自带基础线程组一般仅用来调试压测脚本
2、压力模型选并发还是 QPS 取决于业务场景，例如秒杀 一般选并发类加压模型，而评估系统性能选 QPS 类模型居多 线上服务或接口 根据上下游的调用量来确定 或历史同期或历史峰值 来确定较为合适 一般多给出 20% 的 BUFF
3、涉及到施压机节点的发压能力 建议按照 1 核 2G 2 核 4G 对试压机节点做基准测试 优化 JVM 参数 保证单台最优 压力不够进行横向扩展 发压稳定 & 成本最低为原则
4、基于 Prometheus 做监控的较多，上层用 Grafana 进行数据可视化展示。建议统一用运维侧提供的监控平台
5、压测脚本一般还是自己编写为主，里面的脚本参数化，断言设置及压测数据准备。流量录制更多线上流量回放 作为压测的补充来使用

是的 测试执行所选用的工具/平台 是为了满足前面的测试设计与后面的测试分析的一种技术手段 否则就变成了为了测试而测试 跑出一堆指标数据 无分析无结论

之前写的比较零碎，正在整理中，整理好后会陆续更新到社区~

感谢关注~无学历要求~

感谢支持~

手动点赞 已落地发版回归测试的流程中 结合安卓绿色联盟应用体验 2.0 标准 进行质量管理

欢迎投递简历~~

已提交