一方面首先是：关于测试时间评估这块最好能有个标准搞出来大家可以参考，不然很容易变成一个人说了算（比如测试负责人），其实风险挺大的。

1. 按照用例的数量和执行难度评估：100 个用例跟 10 个用例的执行时长自然不一样，一个用例要查缓存查数据库查日志跟一个用例只看响应的执行时长也不一样，所以需要做明确的区分。
2. 明确测试时间有效评估的前提：测试肯定不是一帆风顺的，所以要明确说清楚，评估出来的时间是指正常顺利测试的时间，如果别人非要你给一个准确时间，就不要把因提测质量不佳、功能不可测等承诺进去，这块说清楚就好。再给到 修 bug 的一些 buffer 时间，基本 ok。

如果这里说的是手机系统通知栏里的那种推送（不是 App 自定义的站内推送），这些推送必然要经过手机厂商的服务器（华米 OV、Apple 都要），这似乎意味着无法从本地真机上 mock 出来的。

在我司，推送中台将推送服务封装了一个简单的 Web 平台供大家手工测试使用或者自动化调用，要做成自动化那就是去调用这个推送中台的 Api。如果楼主的公司不存在这种推送中台，那就需要自行去和推送服务端的研发沟通，能否开一个内部测试接口给你调用。

假设推送可以了，那接下来就是看手机是否能接受到推送，推送是一定有折损率的，它不会 100% 成功，同时也会存在时延，所以整体上失败率非常高。这个步骤可使用常规的移动端自动化框架去做校验，或者从 App 日志上去做校验也可以，看测试目标自行选择不同方式。

最后备注，推送测试有安全风险，比如一不小心给线上用户批量推送了一个测试消息，那就是一个测试事故了。

精彩的回答：公开可参考的制度 -> 落实制度的组织 -> 来源于组织的标准 -> 从标准中转化的技术能力和技术运营 -> 承载能力和运营事项的平台

这个命题定得太大了，既然公司规模不是很大，就没必要追求面面俱到，要先看做这个事情的目的是什么，再来确定要做出什么结果。
如果只是想保证不出现安全维度的质量问题，我觉得最快的方式就是直接找乙方安全公司做全面的渗透测试。如果不想出这块费用，也可以拿市面上开源的现成工具扫一扫找问题解决。可以去 OWASP 上看看有没有你需要的安全标准（甚至是 Top 10 安全问题也可以当成是你们的安全标准），再找一些网上的安全编码规范给到研发，结合一些信息安全意识的条理和培训，我觉得就差不多了。

是的，老哥很有经验，这个是我们在做的一个事情，不过感觉这个事情在不久后就会遇到瓶颈。核心问题可能会转化为：

1. 宿主 App 视角：我怎么把合到我身上来的 SDK 的质量把关兜底好，有无比较通用的测试方案
2. SDK 视角：如何解决 SDK 发版多宿主测试的效率问题，如何有利用有限的人力来支撑不停增加的待测宿主

表达一下我的观点：
1、理论上，确实这么做是正确的，但是 SDK 团队有质量保障上的局限性和客观困难 —— 一方面 SDK 自身质量好，不等于集成在复杂的宿主上呈现出来的质量一定好；另一方面 SDK 客观不一定有测试团队，SDK 研发自己测试在宿主业务视角看来局限很大。
2、这么说理论上合理，但是当宿主集成的 SDK 越来越多，SDK 寄宿的宿主也越来越多，双方都无法顾得来。
3、在实际场景下可能更多的是这样：App 和 SDK 是一同升级的，经常是 SDK 的研发给 App 提接入代码，需要 SDK 的研发熟悉 App 的业务和技术框架，这个就很硬性要求了（尤其是平台型的 App，上面会集成很多集团的其他业务，如 淘宝）

其实有一个死结很难解（或者解不了，只能去缓和）：SDK 变更升级，宿主和 SDK 都有质量风险，在复杂的合作中，各自的边界划分好没问题，但是暂时找不到合适的手段将测试成本降低，以及提升效率。

同意，我们的思路有一部分就是打算提供一些标准给 SDK 方，告诉他们在什么环节应该要具备什么能力完成很么事情，会包含 imath60 所提及的这些内容~
不过标准归标准，当 SDK 越来越多，不同 SDK 的团队配置都不一样，就不能一概这样要求（也不实际，因为执行不下去），所以在宿主上还是有挺大的痛点解决不了（质量 与 效率）。

确实是这么个理，但是在质量视角，该兜底的还是得有自动手段去兜底，总不能一直归因到人的质量意识层面，因为这个很难去把控和改变。所以也挺没办法的，只能穷极各种不一定高效的手段去做质量守门员

老哥目前测试方式是怎样的，不妨交流交流，真的是好难找到对口的同学

5 楼说得挺好，我补充一下我的看法。

工作前两三年应该是迅速生长的时光，迷茫周期不宜超过两个月，如果有那代表问题已经出现了，那就这问题应该怎么调整呢？需要先弄明白两个问题：

1. 你自己想要在职场中成为一个什么样的人？
2. 成为你心目中理想的人，你现在还缺什么？

好，即使第 2 个问题你想不明白，至少第 1 个问题你还是能很快给出答案的吧。那承接第 1 个问题其实也是很确定的做法，你需要找到对应的 RoadMap（发展地图，技能地图）来参考。

上面已经明确了你接下来要做什么（计划），你可以从下面几个方面去发展：

1. 工作中是否有符合你计划的内容，如果有，那尝试直接在工作中实践成长 —— 日复一日的用例设计、执行，这些重复工作中真的没有可以提效的部分吗？如果有，那怎么用技术、流程去提效；如果没有，那尝试着找上级反馈自己的想法，可以尝试发起一些类似的小专项，找人和自己一起做（或者找人带着自己做）；如果也不可行，就看第 2 点。
2. 工作中找不到直接能切合计划的内容让自己发展，那就业余时间，靠自驱靠卷了，这里没必要多说，self discipline

其实这个问题转化一下，就是我们在简历和面试应该如何合理加料。

我的感觉是：

1. 在实际工作中，要主动去拓展上下游让自己摸得到更多东西，这样自合作伙伴做过的事情，自己如果了解得比较清楚，可以在面试里一并说出来（不建议说成是自己的东西，但也可以不提及是别人做的事情，就当成给面试官完整地呈现出来整个事情，除非被确切问到）。
2. 一些自己完全没参与过的东西，但是通过各种形式学习沉淀下来（比如公司内部分享和培训），也可以当成是自己对某种事情开展的想法 or 思路，但要明确说自己还没实践过，免得误会。

至于背调，职场里做个好人，不要和别人撕破脸皮，不要留下黑历史，其实没什么特别难度，让大家对自己有个正常的评价。

我作为面试官，如果看到有人简历里写 “精通功能测试用例设计”，不会觉得有啥特别的甚至有点想笑。
一来用例设计是测试的基本功吧，二来但凡你写了精通我问个问题你答不出来或者回答得一般般就可以当场寄了。

吸引技术同学最好的作用就是技术公关，这一次 B 站很成功，看得上头

一般下面几种做法。

SDK 本身的接口测试

先给定义：

• 接口：SDK 的一个 API
• 功能：SDK 的一个或者多个 API 组合在一起成为有实际意义的功能

SDK 接口测试，一般就是基于 SDK 接口去写调用代码测试，本质上就是写接口自动化，也经常会基于 SDK 实现一个可视化的宿主 Demo（这个 Demo 就调用 SDK 各种功能接口），后面点一下 Demo 的按钮就能在背后跑接口自动化。

SDK 服务端接口测试

SDK 可能也会有服务端交互，如 RTC SDK（推流、连麦），这时可以针对和 SDK 涉及的服务端做接口测试，不过这个范畴更多是服务端的测试，和 SDK 关系没那么大。

SDK 宿主上的黑盒测试

这个没什么好说的，就是谁集成使用了你的 SDK，你就去谁上面搞测试。

上面提到的是具体测试实施的手段，而说到测试范畴，其实还是我们常说的那些维度，不外乎

• 功能测试、异常测试、性能测试、兼容测试、安全测试 而具体要做哪些测试，要基于 SDK 本身的业务属性去评估，不一定都要做。

自己注册一个 qq ？

如果这个音视频 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，招进来冗余的人裁掉，存量的人把控好他们的工作方向和工作量

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