如果这个音视频 sdk 有没有专门的质量团队，如果有，那就对他们提要求。毕竟坑了你们这么多次，这些数据拿出来找那个团队的负责人一看，怎么说也还是有道理的；如果没有，那就真的只能自己搞了，这种东西就是要做自动化，UI 自动化只挑最重点最核心的基本功能去做，限制成本；重点在接口自动化上多做一些事情，成本相对更低，用例也更稳定可靠。

关于 “模拟双方的场景”，我理解就是有多账号互动的过程，一般来说这类自动化要做一个中间模块来进行多方管理，作用是分别给多个账号下发指令让他们按顺序去做一些事情，实际上相当于一个调度模块。

我打算歪个楼给一些方法，楼主可以按需自取，回答和帖子不相关，也是我自己的面试官经历总结。

看起来楼主要面试的是社招同学，看面试的目的是什么：

1. 希望找一个跟公司岗位要求非常匹配的人进来就要马上干活？
2. 希望找一个差不多的人进来给一点时间去适应调整？ 两个不同的出发点，面试关注点不一样，问题也就随之变化。

社招面试的本质：

1. 候选人通过了简历筛选，那代表面试官对这份简历是相对认可的，那面试就是一个求证简历内容真假的过程
2. 一个双向选择的过程，面试官和候选人互相面试，互相感受是否适合对方

一些其他建议：

1. 候选人是业务侧出身，更多可能是先从业务实践应用，从解决业务问题的角度切入，慢慢深入到原理
2. 候选人是技术侧出身，更多可能是先从技术方案和实现原理切入，慢慢延伸到业务的实际应用场景和能解决的业务问题 留意避免反过来问，如，候选人业务出身可能更擅长实践落地，但面试过程却着重深挖技术；或者相反，候选人技术出身却不问技术上来问业务实践落地，这样可能本末倒置，定位不符，双方的面试体验都不佳。面试尽量去挖候选人的亮点，而不是找候选人的缺点（当然也需要识别出缺点，但识别缺点它不是面试的第一重点）。

我在 19 年时还真的测过一次保活，当时也是我第一次（唯一一次）接触这个东西，搞了两周多，大概分享一下。

1. 保活的功能测试：需要理解业务实现的保活策略，包括策略下发、策略更替、策略生效等，有能力的话需要走读代码理解实现细节更有助于抓 bug；黑盒测试局限性会大一些，主要从日志、信息数据上报、进程是否调起等方面去判断。这里面可以拓展一些异常测试，比如下发错误的策略配置、app 新安装未授予系统权限、系统低电量等都可能会有影响，具体要看业务实现。
2. 保活的兼容性测试：保活的方式有很多，细分到不同厂商的不同 Android 版本，业务锁实现的保活策略都可能存在不一致的地方，因为 “保活” 本质上就是和厂商的系统策略在对抗，而厂商的策略会一直迭代，所以兼容测试会是一个很大块的工作。
3. 保活的性能测试：其实都说不上是性能测试，当时做得很浅，就是不断去杀进程，让保活反复生效（甚至是生效了一般又被杀掉），某种程度上给予其功能正常生效的压力。
4. 保活的安全测试：这块当时没做事情，现在回想起来，在数据上报，配置落盘存储等方面可能需要额外关注一些数据安全加密等是否存在问题。
5. 其他联动测试：看业务实现了，比如和推送下发是否有联动等。

一些注意的地方：

1. 留意 Java 弱引用对象的销毁是否会成为策略 bug，当时踩过这个坑，线下测试偶现保活策略生效不合预期无法稳定给研发复现，后来保活功能上线，研发在线上观察定位到问题。
2. 策略生效需要多次观察，保活结果也要观察多一阵时间，需要很细节地抠策略生效间隔和实际拉活的间隔是否符合预期，有若干秒的差异可能就是 bug。
3. 多发挥想象力去从各个角度艹保活功能，多想想用户的使用环境。

其他要求：

1. 具备基本的 adb 命令使用能力，不会的命令要知道怎么茶
2. 具备基本的 shell 脚本编写能力，把整套的操作封装成 shell 挂机跑

如果我是面试官，我内心预期可能会是这样：

1. 了解级：了解压测的一些基本概念，理解其目标和应用场景，但是不知道怎么用工具，没有实践过。（属于看过一些文章和资料，但是没有实践过的）
2. 入门级：知道工具的基本使用，有一些实践经验，但是只负责执行层面的事情，基本不参与测试方案的制定，对整体压测背景、目标、结果等均不太清楚。（属于和主力一起合作干活，但是主责打辅助的同学）
3. 主力级：清楚理解压测背景、目标，能根据目标拆分设计出具体的压测方案，并利用工具将方案执行落地，给出压测结果并跟进研发的后续优化，做各类验收。（属于对整个压测前后细节清清楚楚的绝对干活主力）
4. Owner 级（甚至 Leader 级）：从主力里慢慢成长出来，会有不同的方向，技术路线可能是成为压测整个系统的某方面担当，围绕公司基建去演化压测系统，帮业务实现更低成本的压测，甚至做成 ToB 化；业务路线可能是围绕业务设计一套可持续有效果的压测方案，做到常态化压测和专项压测的支持，不断迭代优化业务的性能和容量，帮业务在容量成本、可靠性等方面做到优化。

如果社区有人分享 SDK、芯片，或者除了常规功能、性能之外的其他方向（如兼容、稳定性、容量、监控报警等），我会马上飞奔过去拜读点赞……

在实际工作中，大家会不会遇到这么一类人：经常搞跨团队沟通推进，表达啰嗦冗余，一个观点反复陈述，一个事情说好久整得好像很复杂一样，实际上精炼几句话就能传达出意思，而且在沟通上非常强势，反复要求你当场给承诺和排期。

这种人需要更特别的沟通技巧来应付。

1. 为什么要做 UI 自动化
2. UI 自动化预期要解决哪些问题
3. 选择什么技术来实现 UI 自动化框架，为什么这样选择
4. UI 自动化用例编写的策略是什么，过程遇到什么难题以及怎么解决
5. UI 自动化在公司内部的落地场景是哪些，分别有什么收益
6. 如果你是部门内部的 UI 自动化布道者，你以什么方式来组织大家开展 UI 自动化，过程中如何做质量运营
7. UI 自动化以后的规划是怎么样的，打算怎么做下去

以上【UI 自动化】可以随便替换成【API 自动化】

图二能通过.给出提示，是因为你的 wk 变量是直接由库函数返回的，ide 可以精确知道 wk 变量的类型，所以能给出它包含的各种方法。
图一之所以不能.出来，是因为 sheet 变量是 wb 字典变量的某一个值，ide 不知道你这个 wb['login'] 到底是个啥玩意儿，它可能是一个字符串，可能是一个 int，无从猜测，取决于你的实际数据（也就是 wb['login'] 是啥只有你自己知道），所以无法提供任何方法名称。

这个并不奇怪，公司走到最后肯定都是往这种模式发展，换自己来当老板，肯定不希望自己花钱招了人进来但是不干事情。以前不这么搞，大概率是没这个必要，比如可能营收情况好，就粗放员工各自发挥。后面营收开始疲软了，自然就收敛 HC，招进来冗余的人裁掉，存量的人把控好他们的工作方向和工作量

十分合理并且赞同，任何测试相关的资产都不要绑定到个人名下，测试账号如果是共用的那就用公司名义去搞一个。难道等会测微信支付，还要测试人员提供自己手机绑定的微信号去测么，离大谱