1、入行测试已经 5 年，目前还是点工，主要是做业务流程测试。随着项目的发展，业务功能越来越多，整个系统也越来越复杂，从最开始由 tomcat 部署的 7、8 个服务，升级到现在的几十个微服务，感觉自己的测试思维跟不上项目发展的脚步了，怎么办？
2、为什么出现这种想法呢？最近由研发自己发现的 bug 数量明显比之前多，测试也能发现 bug，但总感觉发现的不是很深的 bug，这种我们要怎么改进？
3、还有性能测试，除了 OOM 这种很容易复现的问题，其他性能相关的问题很难发现，要怎么改进？
思考，复盘，总结，如此循环
功能测试可以沉淀出各种方法论啊，比如
- 研发测试流程的优化和改进
- 缺陷漏斗的规律，对应挡板的设置
- 高危链路的梳理，研发架构，部署架构的梳理
- 重复工作的提效方式 ....
业务复杂性的价值：在微服务架构下，业务逻辑的理解比技术工具更重要。
缺陷发现的本质：发现深层次 bug 依赖对业务的理解深度，绝非技术手段。
3，性能问题的真相：性能瓶颈也常源于业务场景，而非纯技术问题。
注： 大多数企业根本活不到技术开花结果的那天，在资本收缩周期，企业更需要能守住业务底线的"测试守门员"，而非追逐技术潮流的"测试杂技演员"，其实你改不改进都大差不差，还不如多留意下公司的盈利情况，随时做好自己的容裁条件
以 TesterHome 的评论功能为例，说明发现深层次 Bug 依赖于对业务的深度理解：
产品需求文档：能发表用户评论，能发表情包和图片，敏感词屏蔽
1, 常规能想到的测试点：验证评论能否正常发布、显示、删除，检查字符限制、表情/代码块支持、敏感词等基础功能。
2, 你这边需要深度理解：评论功能在技术社区场景下的特殊规则、用户行为、关联系统（如审核、通知、权限）等。
举个栗子，测评论审核机制时，你需要理解的角度
-
从社区需求上，得知道技术社区的核心是 “高效技术交流”，因此审核太严会卡住讨论（比如发个报错日志都触发敏感词），太松又会有广告党/喷子/恨 G 档
- 你需要在松紧之间找平衡点，既要防止常用的代码符号或者单词被屏蔽导致用户抱怨降低社区活跃度，也要防止用户利用特殊符号/表情替代关键词如【解㊙️决性能问题 +V🤖：xxx】等引发管理员可能被请喝茶的问题。
-
从管理成本上想，如果全靠人工审核，团队根本忙不过来，必须依赖自动过滤 + 人工抽查的平衡。
- 那你就要用真实用户评论（含技术术语、符号变体）测试自动拦截过滤准确性，统计误杀比例。人工抽查的流程有没有可能因覆盖不足而留下隐患。基于成本，需不需要增加 “一键举报” 功能，利用社区力量辅助审核，减少人工压力。
不过一切还得看项目的性质，像社区是非盈利项目，大多数需求的实现肯定以保平安和省事为主，很多功能都不需要想那么深，能用就行
