别做测试了，听行业老人的

大厂的经验分享下，我们之前做过屏蔽字和图片的上传审核，屏蔽字上，公司平台搭了个 ai 框架，先拦截屏蔽字，再做语义分析。但是我们项目实际接入测试时，还是发现了些问题，比如一些 tw 的 td 人的名字，是无法完全覆盖的；比如一些分词算法，“黑夜总会来临”，夜总会会被分词屏蔽，他们的 ai 判定机制还需要进一步训练。我们图片完全是人工审核。另外抖音应该用了 ai+ 人，我实际使用时发现过 ai 没有过滤掉的图片

设计测试方案的核心思路是无视客户端，服务器的限制，都当作可以随时获取的资源，想出大致想要的效果，再和程序对方案。我们项目的战斗编辑器也是这种思路，在编辑器中可以修改和配置战场内人物和怪物的所有属性和配置项，用编辑器来测试战斗系统

我面试时，面试官聊过这种思路，不知道是不是你们公司

看项目参与度，以游戏行业为例，有的公司测试只有一个文档，有的公司测试参与需求讨论和需求会
看公司的体量，在大厂流程完善，有相关积累，新人可以少走弯路
看个人，测试同学只有深入理解业务，有编码能力，理解实现方式和原理，测试才会更完善

两个工作思考方式不同，测试写好测试用例，研发写完代码，自己过一遍测试用例，改完再交给测试，可以缩短工期

拆分类型设计测试方式，做专项测试，如攀爬，是 n 个山体，组合到一起，形成游戏中各种样式的山。
把所有山体放到一个场景里，让测试同学做每个面的从下往上攀爬遍历测试
基本不用自动化，开发期变化大，情况多，投入回报不成比例
我们已经在做的专项：单人战斗，多人战斗，弱网，断线重连，大世界同步，战斗和大世界各个技能间进出同步，攀爬，等等等