如何用 AI 进行软件测试？从直接提问到 Prompt，再到 Skills

最近经常有人问：AI 到底应该怎么用在软件测试工作里？有人让它生成测试用例，有人用它分析需求，也有人开始尝试自动化测试、Agent 和 Skills。

但对刚接触 AI 的测试工程师来说，问题通常更实际：手里已经有一个 AI 工具，第一件事该做什么？

我的建议是从正在负责的测试任务开始，沿着三个阶段慢慢走：先直接和 AI 对话，熟悉它能做什么、哪里容易出错；再把有效的交代方式整理成 Prompt；等流程稳定、重复使用确实有价值时，再考虑沉淀为 Skills。它们的复用程度和流程约束不同，但不代表必须按顺序升级。

这篇先把路线讲清楚；后续各篇会沿用同一个手机号验证码登录案例，逐步展开具体做法。

先从一个熟悉的测试任务开始

假设你要测试手机号验证码登录。AI 并不知道产品的具体规则。如果你只说“帮我测试登录”，它可能列出一些常见场景，但也可能把行业惯例、自己的猜测当成你的业务要求。

为了把例子说具体，本文沿用初稿中的练习规则：验证码有效 5 分钟；同一个手机号每天最多发送 20 次验证码；连续输错 5 次后锁定 15 分钟；新用户首次登录后自动注册。这些只是文章里的教学设定，真实项目要以需求、接口契约和业务方确认结果为准。锁定计时何时开始、失败次数何时清零、计数窗口何时重置等信息没有给出时，也应该继续确认，不能让 AI 自行补齐。

先直接对话，把任务做起来

最简单的开始方式，就是打开手边的 AI 工具，直接告诉它要完成什么。例如：

我现在需要测试一个用户登录功能，支持手机号和验证码登录。请帮我分析这个功能需要测试哪些场景，并生成测试用例。

AI 可能会先给出登录成功、手机号格式错误、验证码错误或过期、验证码重复使用、发送频率限制、多次验证失败等常见场景。这份清单能作为起点，但它还不知道上面那组业务规则，更不知道当前产品的账号状态、接口行为和测试环境。

接下来就补充事实，再让它修改：

补充业务规则：验证码有效期为 5 分钟；同一个手机号每天最多发送 20 次；连续输错 5 次后锁定 15 分钟；新用户首次登录后自动注册。请根据这些规则更新测试场景，并把仍然未知的行为单独列出来，不要自行假设失败次数清零规则或提示文案。

有时还需要第三轮、第四轮：追问验证码边界如何判定、注册失败时是否创建了部分账号、重复提交如何处理，或要求 AI 为每个场景补上前置条件和预期结果。你负责描述任务、补充上下文和验收结果；AI 协助分析与生成内容。

直接对话的优点是门槛低，几乎不需要准备，适合临时分析、探索问题或刚开始熟悉 AI。它的局限也很实际：每次都要重新交代背景，回答格式不一定稳定，业务信息容易漏掉，不同人或不同会话得到的结果也可能差很多。

所以别等着先学完 Prompt 或安装好 Skills 才开始。拿一个真实但经过脱敏的需求试一次，比收藏一堆工具说明更容易知道 AI 能帮什么忙，也更容易发现自己缺少哪些上下文。

把有效的交代方式整理成 Prompt

用过一段时间后，你可能会发现，有时 AI 给出的测试分析很具体，有时却只有“正常、异常、边界”几行通用清单。一个重要原因是输入任务的方式不同。

只说“帮我生成登录功能的测试用例”，模型还得猜测试范围、业务规则和输出要求。换成结构更清楚的 Prompt，就能把这些要求提前交代出来：

你是一名有经验的软件测试工程师。请根据下面的业务需求，完成测试分析和测试用例设计。

先识别需求中的业务规则和约束，再找出歧义、遗漏及待确认问题；然后从正常流程、异常流程、边界条件和安全性等角度分析测试场景。为有明确依据的场景编写可执行用例，包含前置条件、操作步骤和预期结果。需求没有说明的规则不要写成事实，请标记为“待确认”。

业务需求： [在这里粘贴需求和已确认规则]

这段 Prompt 不只是给模型一个“资深测试工程师”的角色，还交代了任务目标、执行步骤、关注范围、输出内容和不能越过的边界。角色设定本身不会告诉模型验证码怎样失效，也补不上缺失的业务规则。复杂任务还可以补充业务背景、接口说明、用户角色、历史缺陷、测试环境和数据限制。

Prompt 不需要越长越好。关键是让 AI 知道要分析什么、哪些资料可以作为依据、什么不能猜，以及结果要如何检查。尤其是手机号登录的例子，验证码过期、限流计数和用户创建时机都可能影响预期结果；如果需求没有说明，就应该把问题留给产品或研发确认，而不是让模型挑一个“看起来合理”的答案。

一套通用 Prompt 也不能原样套到所有产品。电商系统可能需要核对订单、库存和支付状态；金融系统更关注金额、权限和交易安全；SaaS 产品需要考虑租户隔离和角色差异；AI 应用还要定义输出评估、安全边界和未知答案的处理方式。把模板放进真实项目里使用，再根据错误和遗漏迭代，比单纯收藏现成 Prompt 更有价值。

流程稳定后，再考虑 Skills

当 Prompt 越积越多，需求分析、用例设计、自动化准备各有一份，新的问题也会出现：每次要找对模板，一个复杂任务还要手动组织好几轮步骤；团队成员照着做，结果仍可能不一致。

这时可以评估 Skills。简单说，Skill 会把某类任务的操作说明、执行步骤、参考材料和输出要求组织在一起，让支持这种机制的 Agent 工具在合适的任务中调用。它不只是少写几句 Prompt，更重要的是把一套相对稳定的工作方法放在一个可复用的位置。

例如，一个需求分析 Skill 可以要求 AI 先理解业务背景，再提取规则、识别缺口、分析风险、检查可测试性，最后按约定结构输出。测试用例设计 Skill 可以指导它识别测试条件，并结合等价类划分、边界值分析或状态转换等方法生成场景。自动化测试 Skill 则可以提供项目技术栈、已有测试框架、编码约定和执行方式，避免只生成一段和项目脱节的代码。

沿用前面的手机号验证码登录案例：直接对话时，你可能只问“帮我分析一下手机号登录需求”；使用 Prompt 时，你会贴上同一份需求，并补充固定的分析步骤和输出要求；调用 Skill 时，则要确认当前工具能否识别它，再提供需求文档、已确认规则和参考材料，让 Agent 按流程分析。换成订单需求时，方法仍然适用，但业务规则和需要关注的风险要重新提供。几种方式都离不开真实的业务信息。

安装 Skill 不会让 AI 自动理解产品，也不保证结果正确。需求文档、验收标准、现有系统行为、接口或数据模型、历史缺陷和风险仍要按任务提供。Skill 本身也有质量差异：适用范围、执行步骤、输入要求、输出方式和实际验证情况都值得检查。一个设计不合理的 Skill，完全可能不如一份经过验证的 Prompt。

选择时，先找自己熟悉、出现频率高、步骤相对稳定的任务，例如需求分析或测试用例设计。确认当前 Agent 工具是否支持相应 Skill 格式、如何发现或调用它、能访问哪些文件和工具，再小范围试用。不要一开始就安装一大批，先看它是否真的减少重复沟通、降低遗漏或让评审更容易。

如果想找测试领域的 Skills，可以查看我维护的开源项目。它整理了需求分析、测试设计、功能测试、API 测试、自动化测试、性能测试和 AI 应用测试等方向的可复用工作流。具体安装方法以仓库 README 和当前工具说明为准。

同一种方法，在不同工具里也可能表现不同

Prompt 和 Skills 提供的是任务说明与工作流程，最终表现还会受到 Agent 工具和模型影响。不同工具对 Skills 的发现与调用方式、文件读取、外部工具、上下文管理和权限边界可能不同；不同模型在遵循复杂指令、处理长上下文、发现歧义和生成结构化结果方面也可能有差异。模型版本、参数、工具连接和会话里已有的信息都会影响输出。

因此，同一份 Skill 在一个 Agent 里能按步骤读取项目材料，在另一个工具里可能只读取了主说明文件；同一段 Prompt 换一个模型，也可能出现遗漏、冗长或擅自补规则的差别。方法论可以复用，具体配置和效果需要在目标工具、模型和任务上验证。不要把“装上了”或“跑通一次”当成适配完成。

要做比较时，先固定需求、输入资料和评审标准，再记录 Agent 工具、模型及版本、关键设置、Prompt 或 Skill 版本和运行次数。每轮尽量从干净会话开始，保留原始输出和人工修改记录。这样做不是为了证明某个工具最好，而是尽可能弄清楚差异来自使用方式、模型，还是 Agent 的资料读取、上下文管理与权限能力。

可以把比较拆成几种小实验：比较直接对话、Prompt 和 Skills 时，固定模型与需求，只改变使用方式；比较模型时，固定 Agent、输入和任务，只切换模型版本；比较 Agent 时，尽可能使用同一模型和输入，同时记录各工具实际能读取哪些文件、能调用哪些工具，以及 Skill 是否按预期加载。条件无法完全一致时，也要把差异写出来，避免把不同配置下的结果当成公平对照。

三种方式怎么选

对比维度	直接对话	Prompt	Skills
上手成本	低，直接用自然语言提问	中，需要整理和调整提示词	中，还要确认 Agent 工具支持并了解调用方式
工作方式	临时组织任务，通过多轮交流补充	在提示词里预先约定任务、步骤和输出	按复用流程提供操作说明、资料和输出约定
输出稳定性	依赖每次提问和会话上下文	相对可控，仍受输入和模型影响	可形成统一流程，但取决于工具是否正确加载和执行
复用能力	较弱，背景通常要重新说明	较好，可保存并修改模板	较强，适合多人共享，也需要持续维护
常见场景	临时任务、初次尝试和探索	重复出现、步骤相对稳定的任务	高频、多步骤、需要团队复用的任务

这不是能力排名。一个简单问题直接问最省事；写得好的 Prompt 可能比质量一般的 Skill 更可靠；而高频、步骤稳定的任务，Skill 可能更方便团队复用。真正要比较的是当前任务能否以合理成本，持续得到有依据、可检查的结果。

比较输出时也要看它怎样处理未知信息。比如验证码发送次数的统计周期、失败次数何时清零，如果需求没有说明，能够把问题标成“待确认”，通常比自行补出一个看似合理的规则更值得信任。评审标准应在看结果之前先定好，并尽可能隐藏输出来自哪种方式，减少对熟悉工具的偏爱。

比较之后，还可以继续探索什么

三种方式的对比只能回答一个有限的问题：在这份需求、当前模型和当前工具配置下，哪种方式更适合这项任务。它不能直接说明其他业务、模型或团队也会得到相同结果。

后续可以沿着几个方向继续验证。先看任务类型：同一种方式用于需求缺口分析、测试用例设计和自动化代码时，收益与风险是否一样；再看模型和 Agent：固定任务与资料后，更换模型或工具，哪些步骤变得更稳定、哪些问题反而更容易遗漏；最后看业务场景：把方法从手机号登录迁移到订单、金融或 SaaS 需求时，是否需要补充新的风险和约束。每次实验都记录输入、版本、运行次数、评审标准和人工修订成本，不把单次体验写成普遍结论。

用结果质量判断有没有进步

AI 生成了 50 条测试用例，不代表需求覆盖完整；生成的自动化代码能运行，也不代表它验证了正确的业务行为。测试可能没有有效断言，甚至功能已经出错，测试仍然通过。

无论用直接对话、Prompt 还是 Skills，都要检查三件事：输入有没有提供关键业务事实；分析过程有没有把未知项写成确定规则；输出是否有依据、能执行、能验证。重要任务还应保留需求追溯关系、执行记录和评审结论，不能只存一份看起来完整的 AI 输出。

这就是我说的“质量 Loop”：每次使用后，把发现的问题、测试结果和人工调整记下来；依据业务事实修正输入、Prompt、Skill 或工具配置，再重新验证；把确认过的规则和有效做法整理成下一次能带上的上下文。下一次运行又会产生新的证据，继续更新这份上下文。不同业务、Agent 和模型需要不同的调整，没有一套设置能一次定好、永远适用。

给刚开始使用 AI 的测试工程师

不必从复杂的 Agent、多智能体协作或完整测试平台开始。找一份你正在负责、已经脱敏的真实需求，先让 AI 帮你整理业务规则、风险和待确认问题。拿到业务确认后，再让它生成场景和用例。把这次沟通中有效的指令保存下来，后续遇到相似任务时整理成 Prompt；只有当流程反复出现、多人需要复用时，再评估 Skill。

想亲自比较三种方式，可以用同一份手机号登录需求做一次小练习：先直接提问，再用结构化 Prompt，最后调用一个经过检查的 Skill。尽量固定需求材料、模型和关键设置，每次从新会话开始；这样观察到的差异才更可能来自使用方式，而不是前一轮对话留下的内容。若你要比较的正是 Agent 工具或模型，就一次只改变这一项，并记录名称、版本和设置。

评估时，不要只数生成了多少条用例。可以把下面几项记在同一张记录里：

需求问题：有没有发现真实的歧义、遗漏或冲突？
场景覆盖：关键状态、边界和失败路径漏了多少？
假设质量：有没有把未确认的规则写成事实？
人工成本：补充沟通、审查和修改分别花了多少时间？
稳定与复用：多次运行结果是否相近，团队成员能否重复使用？

再结合任务是否常见、流程是否值得维护，决定哪种方式更合适。一次练习不能证明某种工具普遍更好，但能帮助你找到下一步该补充的上下文或检查方法。

这条路线的重点不是追着更复杂的工具跑，而是逐步把有效的测试方法留下来：先用起来，知道怎样给任务和上下文；再把交代方式变得清楚、稳定；最后只在确有复用价值时，把流程沉淀到团队。这也是我关注 AI 原生质量工程（AI Native Quality Engineering）的原因：AI 可以参与越来越多的测试活动，但质量结论仍要建立在可靠依据和可核查证据上。测试工程师仍要定义测试目标、理解业务、识别风险、验证 AI 结果，并把有效经验沉淀下来。

后续文章会把这条路线拆开：先用直接对话完成需求分析与用例生成，再讲测试 Prompt 的结构和迭代，接着介绍 Skills 的选择与使用；之后用同一需求比较三种方式，评审 AI 生成的用例，并继续走到自动化测试与团队方法沉淀。比较篇会先讲实验怎么设计，不会在没有真实运行和评审记录时预设哪种方式胜出。再往后，也可以把同一套评估方法用于不同模型、Agent 和业务任务，逐步积累适合自己团队的证据。这篇先把路线交代清楚，后面的文章再分别展开各个环节。