你好，这里是「AI Test 测试进化论」

大家好，欢迎来到AI Test 测试进化论。

想了很久，我还是决定开这样一个公众号。

不是因为最近 AI 很火，也不是突然想做技术自媒体。

更真实的原因是：

做测试这些年，我越来越想把工作中真正有价值的东西沉淀下来。

踩过的坑、解决过的问题、学会的方法，以及 AI 出现后，我对测试未来的一些思考。

如果这些内容，刚好能帮到正在做测试的你，或者准备要做测试你，希望有一定帮助。

01｜为什么叫「测试进化论」？

做测试这些年，我最大的感受之一就是：

测试这个岗位，从来没有停止过变化。

最早，我们更多关注需求理解、功能验证、测试用例、Bug 提交和回归测试。

后来，接口测试越来越重要，我们开始接触Postman、Charles、Fiddler、JMeter等工具。

再后来，自动化测试逐渐普及，Selenium、Appium、Pytest、接口自动化、持续集成也成为测试工作的一部分。

测试工程师开始写代码，也开始参与测试平台、精准测试、流量回放、质量监控、DevOps 和稳定性建设。

测试工程师做的事情，早就不只是：

“按照测试用例把功能点一遍。”

我们开始参与需求评审、风险分析、测试策略设计、自动化建设、质量数据分析，甚至参与整个研发流程的改进。

而现在，又到了一个新的阶段：

AI 来了。

工具在变，技术在变，研发模式在变，测试方法也在变。

测试工程师这个职业，本身就是一场持续的进化。

这就是：

AI Test 测试进化论

02｜这里不会只讲 AI

名字里有 AI ，很多人可能会问：

这个公众号是不是只讲 AI 测试？

答案：

不是。

AI 会是这里非常重要的一条内容线，但不会是全部。

因为我一直认为：

AI 可以改变测试效率，但无法替代测试基本功。

以登录功能为例，除了正常登录、密码错误、账号不存在，还需要考虑：

• 连续输错密码后是否锁定；
• 验证码是否过期；
• 重复提交如何处理；
• Token 失效后如何处理；
• 多设备登录是否符合预期；
• 权限是否正确；
• 接口重复调用是否安全；
• 并发和异常网络下是否稳定；
• 是否存在安全风险。

真正拉开测试工程师差距的，很多时候并不是会不会使用某个工具，而是：

面对一个业务场景，你能想到多少风险。

这种能力，不会因为 AI 出现而失去价值。

03｜这个公众号会分享什么？

以后这里的内容，主要分为四个方向。

① 测试基础

包括：

• 需求如何分析；
• 测试点如何提炼；
• 测试用例如何设计；
• 等价类、边界值、场景法如何落地；
• 异常场景如何补充；
• 如何减少漏测；
• Bug 如何描述才真正有价值；
• 测试结束标准如何判断。

这些内容可能没有 AI 那么“新”，但决定了测试工程师的基本功。

我不会只讲概念，更希望说明：

什么时候用？为什么用？不这么做会漏掉什么？

② 测试工具

这里会聊抓包、接口、性能、自动化、数据库、日志、Mock 和流量回放等工具。

但重点不会只是安装和操作，而是：

什么时候应该用？它能解决什么问题？项目里如何落地？

例如，使用 Charles 不只是为了抓包，还可以用来：

• 判断前后端问题；
• 修改请求验证异常场景；
• 模拟弱网；
• 定位接口数据问题。

使用 JMeter 也不只是配置线程组，还需要理解：

• QPS 如何分析；
• TP90、TP99 代表什么；
• 压测结果是否正常；
• 发现性能问题后如何定位。

③ 自动化测试

这里会聊：

接口自动化、Web UI 自动化、移动端自动化、Pytest、Selenium、Appium、CI/CD 和测试平台。

但我始终坚持：

不要为了自动化而自动化。

有些项目写了几千条自动化用例，执行时间很长，失败后也没人知道原因，最终上线前仍然依赖人工回归。

所以相比“怎么写脚本”，我更关心：

• 什么值得自动化；
• 什么时候开始自动化；
• 自动化如何维护；
• 失败结果如何分析；
• 如何真正进入研发流程。

④ 测试工程能力

测试做到一定阶段，真正拉开差距的，往往不是多会几个工具，而是：

能不能处理复杂的质量问题。

例如，一个新项目没有成熟流程、没有稳定环境、没有测试数据，需求还在持续变化，但上线时间非常紧。

这时需要考虑的就不只是一条测试用例，而是：

• 测试策略如何制定；
• 最大质量风险在哪里；
• 测试资源如何分配；
• 哪些地方必须重点测试；
• 自动化应该放在哪里；
• 质量如何衡量；
• 上线风险如何判断；
• 线上问题如何复盘。

这些，都是测试真正走向工程化后必须面对的问题。

04｜然后，才是 AI

AI 会是这个公众号接下来非常重要的一条主线。

但我不想只停留在：

“把需求复制给 AI，让它生成测试用例。”

这当然有价值，但远远不够。

我更关心的是：

如果把 AI 真正放进测试流程，它能走多远？

一个需求进入后，AI 能不能：

• 自动理解需求；
• 发现需求歧义；
• 识别业务风险；
• 拆解测试点；
• 设计测试场景；
• 分析接口文档；
• 准备测试数据；
• 执行测试；
• 读取失败日志；
• 判断失败原因；
• 生成测试结论。

如果这些能力能够逐渐串起来，AI 对测试的改变就不只是：

帮测试工程师写几条测试用例。

而是：

真正开始参与测试工作。

05｜我正在尝试做一套测试 Agent

这是未来会重点分享的一条内容线。

我希望把测试过程拆成不同角色。

Requirement Agent｜需求分析 Agent

负责理解需求、识别规则、发现疑点、分析风险。

Test Design Agent｜测试设计 Agent

负责设计测试场景，补充边界条件、异常场景和测试用例。

Execution Analysis Agent｜执行分析 Agent

负责读取执行结果、分析日志、判断失败原因、输出测试结论。

未来还可能继续增加：

接口测试 Agent、UI 测试 Agent、Bug 分析 Agent、测试数据 Agent、质量分析 Agent。

我真正想验证的不是：

“这个 Demo 看起来酷不酷。”

而是：

它放到真实测试工作里，到底能不能用。

哪里有效？哪里不靠谱？哪里必须人工判断？如何提高准确率？如何和现有测试平台结合？如何避免 AI 一本正经地犯错？

这些问题，我都会慢慢记录下来。

06｜AI 很强，但测试基本功不会消失

以后，AI 写测试用例会越来越快，写自动化脚本、分析日志、执行测试也会越来越快。

但如果 AI 给你生成了 100 条测试用例，你怎么判断它们是否真的有价值？

有没有漏掉核心场景？

有没有重复测试？

业务理解是否正确？

优先级是否合理？

是否覆盖了最大的风险？

如果没有足够的测试能力，就很难判断 AI 的输出是否可靠。

所以我更认同一句话：

AI 不一定直接替代测试工程师，但一定会放大测试工程师之间的能力差距。

基础扎实的人，会利用 AI 做得更快、更深。

基础不扎实的人，也可能只是更快地产生大量看起来专业、实际价值有限的内容。

这也是为什么：

「AI Test 测试进化论」不会只讲 AI。

07｜我希望分享的，是“真实能用的东西”

以后写这个公众号，我想坚持三个原则。

第一，尽量来源于真实问题

工作中遇到了什么问题，如何分析，使用了什么方法，踩过什么坑，最后如何解决。

这些内容，通常比单纯介绍一个概念更有价值。

第二，不只分享成功

特别是 AI。

AI 会理解错需求、遗漏场景、产生错误答案；Agent 会执行失败、丢失上下文，工具调用也可能出错。

这些问题同样值得讨论。

第三，把复杂的问题尽量讲简单

不管是测试基础、测试工具、自动化、性能、测试平台，还是 AI，我都希望做到：

看完以后，你真的知道它是什么，以及什么时候能用。

08｜这个公众号适合谁？

如果你刚开始做测试，这里会分享测试基础、测试方法、工具和实践。

如果你已经做了几年测试，这里会聊自动化、测试开发、测试平台和工程效率。

如果你已经是资深测试工程师或测试负责人，这里也会讨论测试策略、质量体系、稳定性和工程实践。

如果你正在研究 AI，我们还可以一起探索：

AI 辅助测试、AI 测试、大模型测试、测试 Agent、AI Testing Workflow。

09｜为什么现在开始写？

做技术的人应该都有过类似经历。

几个月前解决了一个问题，当时觉得肯定不会忘；半年后再次遇到，却只能先问自己：

“这个问题我以前是不是处理过？”

然后开始翻聊天记录、笔记、代码和历史文档。

所以我越来越觉得：

输出，本身也是一种学习。

把一个东西真正写明白，也是重新整理自己认知的过程。

这些年做测试，有经验，也有教训；有些以前认为正确的东西，现在回头看，也需要重新理解。

而 AI 的出现，又让测试进入了一个新的阶段。

所以我想把这些东西慢慢记录下来：

一篇测试技术文章、一个工具、一个 Bug、一次压测、一种测试方法、一套自动化方案、一个 Prompt、一个 Agent，或者某一天对测试产生的新想法。

最后

我不知道「AI Test 测试进化论」最后会写多久。

但至少现在，我还有很多东西想写。

我不希望这里制造焦虑，也不想每天讨论：

“AI 会不会淘汰测试工程师？”