不排除楼主要搞竞品评测自动化

风水宝地，搭车招聘：[深圳/北京/社招] 字节跳动 - 移动专项测试

建议提供现场信息，机型、系统、app 版本、wda 日志

1 分钟真男人

左右移思路上是做盘点枚举。

从版本生命周期或者研发流程出发：

需求提出与评审->技术设计&评审->测试设计&评审->代码合入&测试->灰度上线->全量上线

从这里面逐个环节去看，质量和效能层面分别能做什么……就不会再说【每次 build 就触发自动化测试】而且还自我感觉说到本质了

你一下子给好几个难度不低的问题，不知道要回答你哪一个……

在互联网公司，看不同的团队定位和业务发展阶段，感觉跟业务领域没有很强的关系：

• 业务线移动端：不做 or 很少做（部分沉库代码有做）。业务迭代快，变动范围复杂，需求压力大，单测要大量做不现实也不合理，人力成本黑洞
• 移动端中台 SDK：一般都会做。因为要接入到多个业务宿主上，出问题概率高，业务也会要求中台做好质量管控，单测是很好切入点
• 服务端：建议做。服务端频繁发布上线，不容易受移动端版本发布时间节点限制，集成测试不如移动端直观，单测是十分好的质量底线

分业务体量而言，业务不同的发展阶段，本身在产品质量上的目标是不一样的。

• 业务起步阶段，就是要快，要争取时间窗口，产品质量不可能是业务的核心。整个产品根本就不复杂，对测试的要求也很明确 —— 发现 Bug，线下抓一个 Bug 线上就少一个问题。本质上问题处于有限阶段，问题是可以被修复完的。
• 业务发展阶段，业务长期方向明确，大家持续为业务添砖加瓦使得业务已经呈现一定复杂度，线上问题反馈在研发内部已经开始难以消化，产品质量开始成为大家的关注点。随着研发团队膨胀质量甚至出现回退，很容易就发现 50 人的团队使用 5 人的合作方式已经不可靠了，由于流程紊乱和信息不对齐，非常多低级 Bug 在研发早期被引入，这时测试的产出除了单纯抓 Bug 外，引入了更高的要求 —— 规范出更好的研发测试流程，在不同阶段定要求定标准，最终把控产品线上质量风险；Bug 是解不完的也测不全的，那如何兜底线上质量问题、如何高效吞吐需求、如何低成本跟进线上反馈，也就出现了效能建设的要求。
• 业务成熟阶段，业务整体形态已经稳定，业务增长出现瓶颈，产品研发都在探索以求进一步突破用户体量。一般到了这个阶段，研发内部甚至都有人力空余下来，去做横向通用的技术建设（大公司就搞中台），本质目标是希望从成熟业务中孵化出通用能力，让下一个新兴产品做得更好更快更低成本。这种情况下，测试和研发可能是竞对又合作的关系，因为大家都在关注技术和质量，大家都可以做类似的建设。测试的产出要求就更加多，点点点的测试就很明显外包化了 —— 通用的质量效能建设，要求产出可支持横向拓展的平台服务、工具流程、质量标准，抽象来说，就是需要成熟业务的测试团队去产出 “可复制的质量”，从而让每一个产品都能享受到比较好的质量建设。

以上其实并不全面，在细节上千丝万缕，不同的团队配置，不同的业务体量，不同的公司基建都会有不一样的要求。

• 必备：

  • 实现宿主 demo，包装 SDK 进去单个功能做测试（人肉）
  • SDK 层面函数级别的单测
  • SDK 层面暴露测试接口，针对宿主 demo 做 UI 自动化更深入的测试
  • SDK 请求的服务端接口，对这些接口做自动化

• 其他：

  • SDK 接入使用规范（防止接入方用预料外的奇怪姿势使用）

• 高级：

  • 静态检测能力（比如楼主提到的库依赖冲突，宿主和 SDK 依赖了同一个库的不同版本存在冲突，需要 case by case）
  • SDK 性能：宿主资源占用、极端场景
  • 对被请求服务端的关注度

本帖长期有效昂！！！感兴趣的同学快来看看

公司开发人员参与度不高（可能认为就是形式会议）

大概率是参与各方不理解用例评审的价值，这里影响因素很多，一方面是参与方意识和理解不到位导致对这个会议不重视，另一方面是主持人主持得不好让大家犯困了。个人感觉很重要的点，这个会议不能开太久，最好控制在半小时内，一小时已经有点难顶了……
在技巧上，可以把这次会议当成与研发的交流会，在会上问研发对本次测试最关注的点在哪里，他们希望测什么以及为什么这么想，再反过来去补充用例或调整优先级，让各方参与进来的一些小技巧。（产品一般好像没什么必要参加，至少我参与过的评审都没有产品）

测试用例过多，评审时间长效率低（是否可以筛选出部分用例进行评审）

这个是要筛选的，用例评审不是流水账，重点是体现测试思路，其次才是曝光测试执行过程。一些很常规的、共识性质的测试用例就没必要啰嗦，比如核心路径和普通异常测试等。也不用啰嗦你每一步是怎么操作（除非真的很复杂有信息量在里面），大家也不是傻的，自行看一下就能理解。
至于如何才叫重点测试用例，就要看需求来说了。

无法感知到评审用例给整个团队带来什么（收效甚微）

这个很难用数据来衡量，一般是看大家对用例评审的口碑和满意度，如果大家真的觉得不行，那言语上都会抱怨这个东西，如果大家觉得听了很有意义，对研发来说补充到没考虑的场景提高程序健壮性，对测试来说提升了影响力并通过评审找到了 “测试的感觉”，那就应该让它继续开展下去。

在专门的测试团队中做测试

我理解这种是测试同学属于一个质量保障大部门独立运行，测试同学以资源小组的形式打散到不同业务中去支持业务发展，与业务线的产品研发不在一个大部门中。

• 优点：人多力量大，这种架构下质量大部门下会孵化出单独的中台质量技术团队，去探索先进测试技术，会做质量平台和工具来提效，这时候测试同学有更多机会往技术深入的方向发展，测试的方法论和目标一般会好，工作更加讲求效能逻辑、效能、计划。另外，不同业务线中的同学，有机会互相交流探讨不同业务形态下的测试工作差异。
• 缺点：并不是每个人都可以去干最有含金量的事情，看清现实吧……其实还是要看所支持的产品线，如果产品线资源很紧张迭代非常快，其实测试同学也没精力去搞啥技术，只能从大部门中把测试拿过来业务上落地。不过这并不妨碍个人从大环境中学习成长。

在开发团队中做测试

我理解这种是测试同学跟业务绑定，和产品研发同属于一个团队。

• 优点：研发测试沟通协作或许会更好（只是或许，不一定比第一种就好），有更多机会深入到业务中做建设，跟研发交流。
• 缺点：缺少测试技术标杆，一般这种团队下成长起来的测试同学对测试体系的理解不深，更多是带着研发视角来看待问题。而且由于缺少大部门高纬度的工作方针指导，也没了大部门的撑腰，测试同学很可能沦为产品研发的下游角色，只负责最低端的测试工作，发展上限低。

总结：我更偏向于第一种，因为第一种才真正代表着质量保障团队在发展壮大，测试同学才可以跟着大部门水涨船高，对于大多数人来说单打独斗是非常难做出彩的，长期来看少了对应指导也会让职业中后期产生认知和视野上的劣势。

1. IP 和域名瞎猜是落地保存但是有过期时长或过期策略，好细节真的给干不会了
2. 问题 2 已经看不懂了，不知是否问题表述上有出入【让服务器再次向 DNS 请求后再与被请求域名服务器建立 TCP 链接？】
3. 同 2
4. 每次请求前都清一次本地 DNS 缓存？（至于清理的方法，得靠搜索引擎了 ）

4 楼回答得很棒，我做个精简版：

1. 异步请求发起时 —— 响应方立即的接口反馈是否符合预期，比如最基本的异步消息入队是否成功
2. 异步请求发起后 —— 验证中间态数据，着手点一般有：流量染色（服务调用链）、中间日志、数据库数据
3. 异步请求结束后 —— 最终数据状态一致性，如请求结束各方是否工作完毕并正常

细节纠偏，radis -> redis

其实还好啦，代码文件拉下来就 2000 来行，一大堆注释和增加可读性的空行，实际代码感觉不足 1000 行，拿两个小时出来专心点看一看，把过于细节的部分省掉只看核心，就是纸老虎了

招招招，只要是素质好的全都要，HC 很足呢~

尝试以相对狭隘的视角去理解题主的问题，限制在小的范畴去回答。

1. 理解业务形态，针对性做建设
   不同业务形态对应不同的质量风险或测试难点，如图文资讯、视频直播、电商购物必然意味着不同的前后端问题类型，深挖所负责的业务全链路，每个环节上研发做了哪些技术工作，再来看这个技术工作是否合理，做体系化（“体系” 这两个字难度真的很大）的建设和查漏补缺

2. 不标准不规范的地方会引入混乱和沟通成本，找出并解决
   比较好下手的就是研发流程，狭义上我们说需求提交、UI 设计、技术评审、测试评审、技术开发、研发自测、测试执行、灰度上线、全量上线、线上监控等等的环节，从人工执行的环节下手，做好各种标准规范去约束混乱的自发行为；再拓展一下，可以细化到每个环节的具体，比如编码实现环节，施加质量层面的编码规范（数据信息的安全隐私、组件使用的姿势等等）

3. 研发效能提升
   其实质量或测试本质上就是研发效能的一部分，拓展一下其实可以把研发效能也纳进来。是否有更好的工具平台来提升研发测试体验，如全链路日志检索平台、接口自动化平台、用例管理平台…… 这些平台数不尽说不完，还是要看研发测试的痛点。另外一些就是测试提效或测试深度，如接口抓包 mock 平台、UI 自动化框架、monkey 工具……

针对社招同学的话，基本都需要 3 年到 5 年以上的工作经验（如果年限不足也没关系，我们看实际能力灵活看）。
校招同学当然就没有年限要求了，有实习经验最好~

求大佬帮忙吸引一下人才

就是 4 楼的意思。因为审核导致我没法及时回复，但是我又想回复别人，难道用户还要用笔记本记一下我几个小时后再上来论坛给别人回复消息吗

2

我们没有广州岗位哦，业务测试的兄弟团队有广州岗位，不知道你是否感兴趣

同意一楼的观点。
测试开发发展路线有比较多，有的是业务研发出身，后续转到质量中台做测开，再慢慢带团队；有的是纯测开出身，做质量效能工具平台慢慢成为大的质量中台；有的是业务测试出身，对业务测试常见痛点有所了解后逐步向测开转型定点做工具平台解决质效问题（个人觉得这一种是最适合多数人的路线）；

你既然都没有经济压力了，何不放飞一把，怕个啥，大不了多啃几个月的家底。趁着早期职业激情比较充沛，赶紧找下家吧，不然就是温水煮青蛙了