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

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

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

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

业余

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

职场内

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

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

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

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

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

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

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

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

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

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

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

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

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

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