导航菜单

 

一、先摊开地图，别一上来就冲自动化

很多人学Codex，第一反应是「帮我写个自动化脚本」。

坦率地说，这一步跳得太快了。

你更应该先搞清楚三件事：环境能不能稳定运行；模型、权限、工作区是否正常连接；项目上下文是否足够——它能不能看到你的接口文档、用例、页面和仓库约定。

再往后，才是MCP和Skill这些扩展能力。

这套教程的目录本身就是一条合理的学习曲线：前面是安装与布局，中间是计划模式和目标模式，再往后才是MCP、插件和Skill。

测试人员可以把它理解成一条流水线——先能对话，再能执行，最后才是能重复执行。

我的建议很朴实：第一周别贪多。把安装、权限、聊天引导、上下文压缩跑通，比硬上一条半成品的UI自动化更有价值。
 

二、计划模式 vs 目标模式，测试排期就这两招

计划模式更像是编写测试方案。先让Codex把范围、风险、步骤、依赖摊开，由你来决策。适合需求评审后的用例设计、回归范围裁剪、自动化可行性评估等场景。

目标模式则更像执行冲刺。你给一个明确的终点，比如「把登录链路的接口断言补齐并跑通」，它就朝着终点推进。适合缺陷复现脚本、冒烟脚本、数据校验小工具等任务。

在测试项目中，我常用的节奏是：周一用计划模式拆解本周的质量风险，周三以后用目标模式把可自动化的节点逐一打穿。

刚开始可能会有些笨拙，花费的时间比手动操作还长。这很正常。等到项目的约定沉淀进规则文件后，它才会越跑越顺畅。
 

三、MCP才是主菜，把它当成测试工具总线

如果你只把Codex当聊天框使用，那就太亏了。

MCP可以简单理解为：给大模型插上各种测试工具的标准接口。配置好以后，它不再只是建议你怎么测，而是能直接操作你的工具链。

接口测试方向：接入Postman MCP。集合中的请求、环境变量、断言可以转化为可调用的动作。适合接口冒烟、参数矩阵补全、异常码巡检等场景。传统的接口测试参数化与断言逻辑几乎可以原样迁移，只是执行者从人变成了Agent。

UI测试方向：接入Playwright MCP，或叠加playwright-cli Skill。适合主流程回归、冒烟、兼容性抽检。不需要从零手写定位器，但必须能够审核脚本。PO分层、稳定选择器、等待策略这些基本功一点都不能丢。

数据测试方向：接入数据库MCP。接口测试完成后查库验证，是很多团队的日常操作。把只读查询交给Agent，可以显著缩短手工核对时间。权限务必收紧，生产环境数据库切勿接入。

需求测试方向：接入蓝湖MCP。评审前拉取原型结构，对照文案、状态、异常分支，比单纯看PRD更容易发现遗漏。测试左移终于不再只是一句口号。

桌面测试方向：Computer Use。适用于客户端、本地工具、不方便走Web自动化的场景。适合探索和复现，不适合一开始就作为核心回归引擎使用——它是侦察兵，不是正规军。

Notion与Chrome插件这条线，更适合把用例库、缺陷单、浏览器操作串联成轻量自动化。测试工作流本来就应该是文档、工具、执行三者融合在一起。
 

四、嵌入真实项目，按这五步走

第一步，建立测试工作区约定。目录结构先明确，例如 tests/api、tests/e2e、testdata、reports。再编写一份给Agent看的规则文档，说明命名规范、断言风格、禁止提交的敏感信息、失败时需要保留的证据。agents规则和memories记忆，本质上都是为了降低它每次重新猜测的成本。

第二步，先接通一条MCP，只打通一条主链路。不要五条一起上。接口团队优先打通Postman，前端团队优先打通Playwright。一条链路从能调用到能稳定输出报告，比十条半成品强得多。

第三步，用Skill把重复话术固化下来。Skill基础、手写Skill、自定义Skill，对测试人员来说几乎是彩蛋般的存在。你可以把「生成接口用例」「从原型抽取检查点」「把失败日志整理成缺陷描述」等内容做成Skill。以后不是每次都重新教，而是直接唤醒对应技能。

最小可用结构，心里有这个骨架就够了：

my-qa-skill/

SKILL.md # 触发词、目标、步骤、输出格式

references/ # 断言规范、字段字典、禁测清单

scripts/ # 可选，本地辅助脚本

SKILL.md 里写清楚三件事就很有价值：什么时候触发、做完长什么样、失败时怎么停止。

第四步，权限分级管理。能自动执行的放行，涉及数据变更、外发、删除文件的操作必须人工确认。测试环境可以适当放宽，预发和生产环境必须严格守住。

第五步，把结果接回现有流程。报告进入CI流水线，失败截图关联缺陷单，用例变更同步回用例库。Codex的目标不是替换你们的用例平台和流水线，而是填补写脚本、查数据、对原型、整理失败信息这些最耗时的环节。
 

五、盯可控，不盯酷

两种极端情况。一种完全不信，认为AI脚本不能进仓库。一种全信，生成完直接合入主干。两种都挺危险。

更稳健的姿态是：把它当作一个速度很快、但需要严格门禁的初级测试开发人员。

断言必须你自己能理解。选择器策略必须由你审核。数据清理必须可回滚。密钥不能进对话、不能进Skill正文。每次自动执行都要有完整的日志和产物。

传统的测试能力一项都没有过时。接口测试、自动化、性能、安全、兼容性等，只是执行层多了一个Agent。衡量指标还是那些：成功率、失败归因、回归下降率、稳定性。变化的是，你从亲手执行变成了设计规则并验收结果。

第三方Skill可以先使用现成的版本，但在引入项目之前需要先做沙箱验收，检查是否存在越权、是否会乱改文件、输出是否稳定。飞书相关的Skill适合串联评审纪要和任务，同样只授予最小权限。
 

六、一周速通日历

第1天：安装与布局，把一个测试仓库加入工作区。

第2天：权限和模型设置，跑通一次只读任务。

第3天：MCP通识，先接入一条Postman或Playwright。

第4天：用计划模式产出一份回归裁剪方案。

第5天：用目标模式落地一条冒烟脚本。

第6天：写一个小Skill，专门生成缺陷描述或用例大纲。

第7天：复盘总结，把踩坑经验写入规则和记忆，删掉华而不实的配置。

一周下来，你不一定成为Codex高手。但你会拥有更重要的东西——一条属于你们项目的、可重复的测试提效闭环。

大时代啊，朋友们。工具会变，门禁思维不会过时。