由于第一段话和第二段话的逻辑看起来很奇怪，没有能完全理解，上面已经有人说了，你的问题其实不是测试问题，而是本身服务端实现就存在已知的性能问题，和你做性能测试没有关系，问题在线上已经验证出来了，接下来应该是排查修改。

下面尝试回答你的两个问题。

问题 1：如何在测试环境去模拟这种数据量较大的情况测试

1. 解法一：在测试环境伪造同样负载程度的数据，要关注数据类型分布，数据量比例一致（注意，并不线上 1000w 条数据线下就要 1000w 条数据，线上线下配置往往不对等）等问题；数据伪造的方式，有脚本批量生成、线上导流脱敏生成，一般需要待测试标志方便后续清理，或者影子库的方式去处理。
2. 解法二：如果数据量级不好伪造，那就重新搭另一个测试环境。这个新测试环境的硬件配置要更差，差到在较小测试数据量级时已经出现性能问题，也是另一种思路。

问题 2：测试标准怎么定

我假设你说的是性能测试标准，一般主要关注以下维度：

• 响应时长维度：文字意思
• 响应正确率维度：文字意思
• 机器资源维度：cpu、内存、I/O（可以泛化到缓存和数据库的速度）、网络带宽

思路是，在一定时长范围内，满足 xx% 响应率，能压到多少 QPS，这个 QPS 是否达到预定目标，在压测过程中有没有发现资源问题……具体数值，要从线上历史数据去分析预测，与研发和产品商讨确定。具体可以看看服务端压测怎么做。

好的测开，确实还是得从业务中走出来，对业务痛点有亲身摸爬滚打经历，再慢慢走到中台化服务化

感觉是精力分配转移了，年纪越大越清楚想要什么，精力管理得越来越好，鸡毛蒜皮的事已经不入脑了

不错，很明确自己的学习路径，继续加油，做到学以致用，实践到工作里加深理解（当然不要盲目实践）

• 一方面，小厂由于体量小多数可能还是以业务生存为主，在具体方向深度上大多数时候是打不过大厂的，所以小厂看起来无法满足楼主的需要。
• 另一方面，大厂对于楼主年龄的候选人，应该会有两种方向的要求。要不是能带团队在某个领域方向上发展壮大，做到细分领域的 top（团队带领者），这个方向显著的要求大概是具备较好的视野、规划能力、管理能力；要不就是有非常强的个人能力可以解决大家都解决不了的技术问题（个人贡献者），专一在某技术领域上发展为没有任何人能替代的资深专家。或许楼主可以想一想自己比较适合哪个方向吧，毕竟时间对于楼主来说越来越宝贵，时间花在刀刃上，让自己的能力模型符合大厂的理想，可能会更有利。

至于技术深度方面上，可能得有标杆基线才能去评价深度，比如领域内大家一般都做成啥样，有些什么地方大家可能没做，这样去评估可能目标性更强。
有些时候太钻牛角尖确实不是一件好事，“够用就好” 和 “深挖到最底层” 并不就是一个贬义一个褒义，还是要区分场景去看待。如果在一个快速发展的地方，“够用就好” 是一个理智的行为，强行挖深度会带来负面效果，最直接的表现可能就是自嗨和闭门造车。“深挖到最底层” 要看周围环境是否允许，当然如果是业余深挖是鼓励的，工作上去花时间深挖，就真的要权衡 ROI 了，可能有更多更重要的事情自己装看不见，挑活不想干。有时候老板可能也不好意思挑战，要自己意识到不合适。

我看下来有些疑问（好奇）

1. 作者个人定位是什么？专精的哪个领域范畴？之所以这样问，是看到楼主快 40 了，还有在切换新领域（最近在被老板逼着看编解码的算法，想的是超越 GOOGLE 开源），挑战新方向是好事，但经常在个人的历史经验清零的状态下面对工作，不好发挥出独特的价值，很容易被扣帽子说 “工作年限与能力不匹配”。
2. 作者希望待在一个什么团队，觉得团队对自己的要求是什么，自己希望从团队里获取的是什么，又觉得能给团队带来的是什么？
3. 年纪大经历多，确实不会再愿意做简单的事情，那找到一个合适的长期做下去的岗位的阻碍是什么？是个人原因还是外部原因？频繁跳槽我理解是进来后做的事情跟进来前了解的对不上。

在豆瓣慢慢蹲大佬的新书

本质职责：保产品质量底线，如有余力，再来说提升研发测试效率

1. 常见的标准质量体系是什么
2. 业务形态相关的特型质量问题在哪里
3. 你的数据度量大盘有没有

呈现上，你的能力地图（都已经有些什么能力），你的风险地图（盘点业务潜在的质量问题），早期通过度量大盘驱动业务建设，后期通过能力成熟度模型深化工程能力，这一套套看似官话套话的东西，理解下来，够做好多年。

1. 深度结合公司内部的研发体系，从 流量抓取、发压机部署、测试流量染色、发压策略配置、压测度量 等各个环节做更深度的定制，得到更好的效果。这个是最主要的原因，大厂的基本环境，不是外部系统搬过来就能用的。
2. 方案成熟，目标明确，建设起来晋升涨工资。
3. 带一拨人排坑撸出来后，跳槽下一家公司涨工资，经验还能再复制一遍。

中高阶的知识一般来源有：进阶书本、twitter 等各类外国社交论坛、paper、工作实战、业界了解等……

测试技术相对来说，信息获取渠道更加局限，因为很多深入的测试技术是细分到具体领域的，而不会被人当成测试单独放在一起。

比较可行的方式：工作实战、业界了解、paper。（书本太少、社交论坛很少深入探讨测试或者质量，更多时候可能放到效能工程里头去）

风水宝地，搭车上广告：[深圳/北京/社招] 字节跳动 - 移动专项测试，极速面试

找到了两篇相关文章：

• https://ysw1912.github.io/post/network/how_to_close_tcp_connection_correctly/
• https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable

没想到协议栈底层原来会这样处理数据，send函数只是将数据写到了内核缓冲区，所以send函数的返回值不代表对方已经收到多少数据，挺有意思。

1. 测试单独部署一个环境，在上面随便搞，搞完全量清除下次再用
2. 测试数据添加一个标识，比如 id 或者 name 统统以某种特征开头，测完后手工 sql 删除
3. 参考 3 楼

个人看法，只要不是过度监控，就是有做得必要。
收益：

1. 尽早发现问题，尽早做出响应，争取更多时间，不用多解释
2. 排查定位问题，如某特定类型的 error 日志开始暴涨，很容易知道是谁的变更引入问题

但是在具体实施时要考虑一些因素：

1. 监控触达率，不要搞低效的监控通知机制，比如群里甩个没啥信息量的报警，除非有明确的奖惩机制，否则一般没人管
2. 监控误报率，监控不是做了就完事，是需要持续运营跟进的，不然后面监控准确性越来越低会直接影响正常工作，监控变成了垃圾
3. 监控覆盖率，如果当成是一个正儿八经的事情来做，就需要考虑这个点，否则可以不管

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

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

建议提供现场信息，机型、系统、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 性能：宿主资源占用、极端场景
  • 对被请求服务端的关注度

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

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

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

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

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

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

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