是携程开源的 我拉你进群邀请下？

宿主 APP 视角：做好 SDK 升级的版本频率控制。SDK 越多，升级后的风险越大，一般核心 SDK 的重点版本升级分散到不同的宿主 APP 版本迭代中，小流量 APP 先升级看效果，核心 APP 后升级保稳定
SDK 视角：矩阵宿主 APP，优先针对核心宿主 APP 及组件化框架的 DEMO 做人工适配，然后将这部分的工作以自动化脚本的形式落地下来，交给云测平台做多机型多 APP 的自动化回归，再人工审核结果及校验

是的 平台侧【负责宿主 App】QA，组件侧【负责 SDK】QA 及业务侧【负责各业务方向内容】QA 的协同。是个值得讨论与持续跟踪的议题。在流程规范、技术应用、组织人员不同维度的协同。最终形成一套标准作业化体系及通用能力标准。

到目前为止十年的职场生涯都在和 SDK 打交道，从 SDK 开发到 SDK 接入【即楼主说的宿主 APP，有本公司的也有第三方公司的】再到现在的 SDK 质量保障及公司平台 APP 的质量保障。总结下来有几点比较实用的方法供参考
1、宿主 APP 以组件化的方式构建，可以按需构建 DEMO【即主 APP 及包含 1 个待测 SDK】供 SDK 的 QA 进行测试，包括人工功能及非功能【兼容、稳定、性能】
2、约定接入标准，及包体积增量、对兼容、稳定、性能的影响，需 SDK 方给出测试报告，及版本基线比较。在接入后由宿主包侧给出自己 QA 的功能测试及非功能测试报告【double check 尽可能保证 SDK 的接入质量】
3、针对 ANR、CRASH 等问题，接入数据埋点统计，收集问题并做缺陷归类与分析。我们现在也有引入精准测试及覆盖率统计，来确定变更及影响范围，及测试后的覆盖情况，来辅助接入及发版决策。同步在推进开发侧完成相关 SDK 的代码单侧，基于代码调用的频次与风险等级来决定单测代码的编写优先级
上述：是在实践过程中一些比较好用且有效的方法，供参考。

在 Android11 及 iOS14 及之后系统 WIFI 连接稳定性较好 之前的手机不推荐 所以实际生产中 还是以优先连接为主 保证设备连接稳定性优先

拥有选择的权力，不是盲目的裸辞，也不是为了所谓的薪资忍气吞声。1-3 年打基础。3-5 年将某个细分领域的能力纵向深挖。在 5-8 年的时候成为细分领域专家的同时开始横向拓展并锻炼实践自己的管理能力。在 8-10 年，成为一号位或者二号位【根据自身情况选择】。本科毕业 10 年 32 左右 硕士毕业 35 左右。既有能力又有态度。为下个十年奠定基础。

视觉测试 如果想开箱即用的话 建议看看 美团开源的 vision-ui 项目 后期可参考原理自己实现模型 收集样本数据 训练并调参

纯靠 JMeter 的话 还是建议一主带四从 如果并发或 QPS 要求大于上限后 可以考虑更换 Gatling 引擎 自己引入分布式任务调度做水平扩展 支撑更大并发/QPS 的压测场景需求

业内一股清流 当可以直面问题 将事故原委 处理流程分享出来 可以更好的防微杜渐 也可以为业内做个标杆 点赞~

一般作为技术面试官 我主要会就候选人简历上的业务和技术项目进行由浅入深的提问 来看候选人的思考 掌握 深入 总结及横向拓展能力 然后结合他面试岗位的特点问些问题 看他的匹配度及兴趣度等

从压测的背景 指标评估 链路分析 到压测计划 时间 周期 前置准备 并 压测脚本 数据 模型等 执行完成后的人工复查 压测结论 问题的定位 调优 及整体复盘

app 保活的测试 是否可以通过添加心跳埋点日志 上报后对日志分析实现

看下是不是 workspace 和 src root
设置缺失导致找不到

选择一个方向深入下去做吧 性能也好 稳定性也好 从流程标准化到工具平台建设到问题定位分析调优 每个都懂一点 反而没有竞争力

在功能模块中做原子能力的验证，在业务场景中做串联的验证。彼此不矛盾。

学无止境 不要给自己设限 35 岁 是工程师的黄金时代开始

1）先算好 roi 自动化脚本的编写和维护成本 与人工覆盖的差值 高于的话 再考虑 2）看楼主的选型是在做 web 的自动化 那么对多浏览器多版本的支持也需要考虑过进来 3）对线上问题进行分析归类 看看大部分问题是在接口层还是 ui 层发现的。如果是业务逻辑为主，那么优先落地 api 自动化会比 ui 自动化的价值更高

不光要做得好，更要会汇报。既有客观数据，又有主观判断。

基于业务建模 脚本分层 po 做封装 数据驱动 都是一些常用的易扩展易维护的方法

核心业务核心线 每次晋升都不要错过 内部没机会就去外部 一步快步步快 超越同龄人 赶超前人

质量变化 - 原因 - 可执行优化 这三步对应的质量数据收集、问题归类&分析、调优&落地。既要将流程跑起来，又要将过程中的数据采集存储建立版本基线以便后续的归类分析。前期建议从线上事故和缺陷逃逸两个指标开始抓，生产问题因可转化为资损最为重视，抓典型利于突出价值，从这个点开始突破，效果会更好~

控制变量在相同网络环境中 播放自己和竞品 app 视频 观察卡顿情况 或 介入弱网控制网速及丢包 来查看视频播放卡顿情况

本人观点：需要。测开交付的工具平台服务于测试与开发同学，最终是要用于支撑业务，保证质量，提升效率。所以对业务的理解与测试的设计都需要。否则开发出的工具平台不接地气，无法达到目标。

适配业务的一套完整的质量保证体系所需的工具平台，不建议自己闭门造轮子，早期基于开源工具快速构建并落地，然后开始有针对性的开发相关插件和源码二次开发增强能力。当这套工具平台的用户使用量和使用时长已成为必选项且无法支撑业务的需要，再开始考虑重新的架构设计与升级

接口测试的协议类型（http rpc 还是其他）根据每种协议的特点自己写 client server demo 了解交互的原理并确认测试点 燃油选择合适的测试工具 或者自己写脚本