吸引技术同学最好的作用就是技术公关，这一次 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，招进来冗余的人裁掉，存量的人把控好他们的工作方向和工作量

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

业余

如果自己的目标导向性很强，那就走目标驱动的方式，给自己一直定短期小目标，比如每个目标是学习 xxx，然后将它拆成几个子课题逐个突破。
如果自己的目标导向性一般，那就先上网找找 roadmap（别人整理好的学习路线图），然后从上面按顺序学习，或者挑自己感兴趣的去学习。
学习主要是将节奏，稳定的输入输出，剩下交给时间。

职场内

谦虚请教，多主动和 leader 一对一沟通，不停询问其对自己的看法和建议，不停做调整；学习如何去把一件事情做好，如何从 60 分做到 80 分再做到 90 分；学习怎么和别人友善顺畅地沟通，学习怎么抑制在沟通时不好的情绪表现等等

如果直接要答案，没办法给你，可以尝试给点思路。

【系统环境多多少少都会存在一些细微的差异性，导致部署的过程中，活着在试用的过程中零零碎碎的问题就显得很多】

我假设这里楼主已经把问题范围圈出来了，接下来要做的是，把这个很粗的定义细化。

• 正向思路：服务器环境差异究竟有哪些影响因素？如硬件规格、系统版本、程序版本、程序配置等，需要楼主去盘点……
• 逆向思路：在实际 ToB 的过程中，客户遇到的实际问题排查下来是什么原因，补充到你梳理的影响因素里面。

当你把影响质量的点都搞清楚后，就能去决策应该先优化什么，优化了之后预期有什么效果，这样就有了目标。另一方面，你需要在这里面找出一些可量化的点来评价你做事做到多少分，举个例子，假设运行环境中依赖程序版本会影响你系统的运行，那你要有个类似这样的指标 —— 系统可以正常兼容哪些程序版本，没兼容的是哪些。

比较常规的如一楼所说，测试先划定一个，再找研发评估对齐。
引入其他依据的话，可以是基于代码调用链上下游各 N 层来评估测试范围，这个评估步骤可以是人来做，也可以做成自动化。

希望楼主不要觉得我说话难听，忠言逆耳，其实楼主有些浮躁。
接这个例子说，用例数量 10 条和 100 条有本质区别，100 条和 1000 条区别更大，有很多问题是在一定体量之下才会出现（不然淘宝双十一天天卷架构卷压测是为了啥）。
举个例子，当你用例膨胀到几百条，你会出现很多维护成本问题（用例不稳定性，修改效率低）和很多统计度量问题（哪些用例失败率高，哪些用例经常发现 bug），就会让你在用例分级、运行策略、框架升级等各方面做更工作……这也仅仅是部分问题，越往后做，就要和各种奇怪的问题斗智斗勇，这时才是最锻炼人的，而不是写几百行代码就算是 ok 了。

一开始看还懵了一下，按照面向接口压测的思路，一般不会把用户在浏览器上请求的模式拎出来说，而是直接按照业务链路的思维去梳理。后来看完之后就理解了，本质上工具的核心卖点是 UI 操作化与录制，录制功能做到和多用户用浏览器一样的访问模式，对用户的要求更低（甚至不用具备链路业务梳理的能力）。

不过这样做压力测试会有局限性的：

1. 没有办法把后端链路拆分开来进行压测，除非后端很简单，不然压测粒度太粗也就不好定位问题；
2. 不是所有系统都会有前端页面，就没法录制了（不过工具本身应用定位就不是在这个场景，可以理解）
3. 个人感觉会有一些问题无法触达，因为不是所有流量都是由前端的用户访问直接产生的，有时候在链路内部会流量放大的机制（如内部的失败重试），极端场景下需要额外考虑

9 楼的逻辑有点问题，外包要是薪资高，那为什么还会分化出 “外包” 这种角色，“外包” 之所以产生，最大原因应该是企业希望降低人力成本吧？这些成本泛指培养成本、福利成本、违约成本……

回到正题，从楼主的描述中，薪资和工作内容都不太让人满意，现在又把离职摆出来了台面，大概率是要走的了，还是只能边做边找。不过大环境很一般，还是尽量放低薪资预期，看长远一些，优先考虑找一个能让自己在未来有竞争力的岗位吧。

回家随便找工作然后考公务员，看着更像是一个放弃治疗的选项，除非考虑成熟了，不然还是晋升，否则这 3 年工作经验基本浪费。

最近倒是面试了不少 “毕业” 的同学，确实日子不好过。
另外，欢迎对移动专项测试感兴趣的同学加入我们，有平台开发、移动端测开、性能&体验评测等岗位：https://testerhome.com/topics/32296

应该要明确一下，你表达的 “接口断言” 和 “数据库断言” 在这个上下文里具体是指什么？

我自己理解，帖主问的问题是：性能测试过程中每个请求是否需要看落库结果，来确保性能测试的逻辑正确性。

我的理解是：

1. 性能测试可以做结果断言，但不需要在测试过程中做，而是在性能测试结束后统一做断言。举个例子，电商抢购性能测试，最后通过日志和数据等对账完成断言，判断没有不符预期的情况，没必要在发生抢购的过程你还要浪费性能去做额外的事情。
2. 性能测试断言结果其实是次要的，因为性能和功能相对独立，很多时候只要功能测试是正常的，性能理论上就不出现逻辑问题（不过极端场景下，尤其是系统有复杂的上下游依赖，这个时候确实会出现功能不正确的表现）。所以一般来说功能测试通过了，性能测试基本都不关注 “结果是否正确”，因为功能测试已经给了结论。不过甲方爸爸要求给，那还是得给……

也是可以的，这算是具体测试下手的几个维度，但还是不太够，面试的时候问你这种问题，其实就想了解你的质量保障体系是否完备，所以从线下到线上到得回答一遍。

嘿嘿嘿

智能纸制笔记本，不过 7 号发起兑换到现在还处于审核中