★ FEATURED ARTICLE 登录功能大概是测试圈里最看不起、又最写不完的功能。你说简单吧账号密码输对点一下登录就完事了但真要让一个同学把用例写到能过评审往往要憋一整天——正常流程、异常流程、密码错误、账号锁定、验证码过期、多次失败、异地登录、弱密码、SQL注入、XSS攻击……列到后面自己都想吐。我前阵子接了一个登录模块优化的需求当天下午就要用例评审实在不想从空白Excel开始敲就试着用文心一言跑了一遍结果5分钟拿到一份60多条用例的初稿再审一遍补上业务规则半小时内直接交出去。这篇文章就把这套AI测试实操方法完整拆给你提示词怎么设计、AI生成结果怎么审、Excel模板怎么落地以及那些我踩过之后才知道的坑。不管你用的是文心一言还是其他大模型思路都是通用的。适合正在做功能测试的同学也适合想用AI给团队提效的测试负责人。1. 为什么写登录用例这种小事也要用AI1.1 你真的了解登录用例要覆盖多少维度吗很多人对登录用例的认知停留在输入账号密码点登录但真正上线过的项目都知道一个登录框背后牵扯的测试维度远超想象。功能层面要覆盖正常登录、密码错误、账号不存在、账号锁定、验证码失效、记住密码、退出登录、Session过期安全层面要覆盖暴力破解、SQL注入、XSS脚本、密码传输加密、验证码绕过兼容层面要覆盖不同浏览器、不同操作系统、不同分辨率性能层面要考虑并发登录、接口响应时间。再加上现在的系统普遍支持扫码登录、短信验证码登录、第三方OAuth登录登录这个小功能真正展开写一百条用例一点都不夸张。我在实际项目里见过太多以为写完了上线就出事故的情况。比如验证码逻辑没覆盖、多次失败锁定策略没验证、找回密码后旧Session没有失效这些问题一旦漏到生产环境轻则被安全团队通报重则影响用户账号安全。所以登录用例不是不需要写全而是太容易靠个人经验漏写。AI在这里最大的价值就是像一个读过几百个登录模块用例的助手帮你把通用维度先铺满剩下的才是你基于项目实际情况去调整的部分。1.2 AI写用例的本质检索与组织而不是创造我刚开始尝试AI写用例的时候也犯过一个理解错误——以为AI能完全替代测试工程师的思考把需求丢进去就能产出可直接执行的交付物。用了几次之后才想明白AI在写用例这件事上干的活本质上是检索与组织不是创造。它做的是把你给出的功能需求映射到一个庞大的、经过训练的测试用例知识库上然后按照你要求的格式把相关内容组织出来。这跟搜索引擎有点像只不过它是用自然语言跟你对话输出的是结构化的可用文本。这意味着两件事第一你给的信息越具体AI输出越可用——你只写测试登录它就只能给你一堆教科书式的通用用例你写清楚系统有哪些登录方式、锁定规则、验证码策略它就能按你的业务规则生成有针对性的用例。第二AI没有你是否漏了需求的判断力——需求文档里没提的东西它不会帮你强行补上它只会按你喂的料去铺。想明白这一点之后我不再把AI当独立测试设计师而是当初稿生成器灵感补充器。人工负责业务规则梳理和最终验收AI负责把那些大家都会测、但又特别耗时的基础场景快速铺出来。这种分工方式让我实际写用例的时间压缩了至少一半而且漏测率反而降了因为AI铺底的覆盖面比单靠个人记忆更稳定。1.3 为什么选文心一言而不是其他工具市面上的大模型产品很多我之所以在实操里用文心一言来演示不是因为别的模型不行而是它在做中文测试用例生成这件事上有几个让我觉得顺手的点。第一是中文理解稳定。测试用例里经常出现请输入11位手机号密码由8-20位字母和数字组成这类描述文心一言对中文语境的解析能力比较扎实生成出来的用例描述基本不需要大改。第二是低门槛注册就能用不需要考虑网络、部署这些问题对绝大多数测试同学来说是最快能上手体验AI提效的路径。第三是支持多轮对话修改。我先让它生成一版然后继续追问把移动端的场景补上优先级重新调一下把用例编号改成LOGIN_CN这种格式它都能基于上文继续优化而不是每次重新生成。当然如果你团队已经在用其他大模型的API或者公司要求数据不能出内网那用私有化部署的模型也是可以的。核心思路是一样的区别只在工具本身。这篇文章里的提示词模板、审查方法、Excel模板都可以直接平移到任何大模型产品上使用。2. 5分钟搞定提示词怎么设计才能让AI输出可用用例2.1 一个能开箱即用的登录用例提示词模板直接来干货。这个模板是我在实际项目里反复调整过好几版之后定下来的把它复制到文心一言对话框里把被测功能需求部分替换成你自己系统的真实规则回车就能得到一份可以直接进入人工审查的用例初稿。你是一位有10年经验的资深测试工程师擅长Web端和App端功能测试。 现在需要为【登录模块】编写一份完整的测试用例集被测系统的登录功能需求如下 1. 用户使用已注册的邮箱/手机号和密码登录。 2. 登录成功后跳转到首页右上角显示用户名。 3. 密码错误时提示用户名或密码错误连续5次错误锁定账号30分钟。 4. 支持记住密码勾选后下次自动填充。 5. 支持短信验证码登录验证码有效期5分钟60秒后可重新发送。 6. 未注册的账号登录时提示账号不存在请先注册。 请基于以上需求编写一份覆盖完整的登录功能测试用例集并满足以下要求 1. 覆盖正常流程、异常流程、边界值、安全、兼容性、易用性几个维度。 2. 输出格式为Markdown表格字段包含用例编号、用例名称、前置条件、测试步骤、测试数据、预期结果、优先级、用例类型。 3. 用例编号使用LOGIN_CN、LOGIN_EX、LOGIN_SEC等前缀。 4. 对高风险、高优先级用例用高标注。 5. 如果需求描述不足以覆盖某个场景请基于通用登录系统的常见做法做合理补充并在该用例备注栏说明AI补充。这个模板看起来不复杂但我见过很多人写提示词只写一句帮我写登录功能的测试用例然后抱怨AI输出太水。区别就在于后面那一大段关于角色、需求、输出格式、编号规则、兜底策略的约束才是让AI从教科书模式切换到可交付模式的关键。2.2 为什么提示词要这样写五个要素逐个拆先看角色定义。我给AI设定了一个有10年经验的资深测试工程师的角色。这个设置不是玄学而是因为大模型在训练时见过海量不同身份视角的表达给它一个明确的角色相当于帮它锁定输出的语气、深度和关注点。你让它以资深测试工程师身份写用例它输出时会更关注边界、异常、安全维度你让它以产品经理身份写它可能会更关注用户场景和流程合理性。这个差异化在使用中是非常明显的。功能需求要素是整个提示词的核心。我建议把需求逐条编号列出来而不是用一大段文字描述。编号的好处有三点第一AI更容易逐条对齐不会漏掉某一条第二你后续追问第3条那种场景再多补几个用例时AI能准确知道你指的是哪一条第三强制你自己先把需求梳理清楚——这一步的价值后面还会提到。覆盖维度和输出字段两个要素解决的是格式问题。我见过太多AI生成结果没有编号、没有优先级、预期结果写得含糊其辞直接导致后期还要人工返工。你在一开始就把字段名定死把维度点齐AI输出就能直接进入表格流程省掉大量整理时间。最后说兜底策略。这一条是我自己加的也是我觉得最实用的一条。AI在处理信息不完整的需求时有一种默认倾向是会停下来反问请提供更多信息。但如果真让它反问你就得一轮一轮对话5分钟根本搞不定。所以我在提示词里明确告诉它信息不足时基于通用做法做合理补充并在备注栏说明AI补充。这样它既能给出完整输出又保留了标记让你后面审查时能快速识别哪些内容是需要特别核对的。3. 实操演示文心一言生成登录用例的全过程拆解3.1 现场操作从提出需求到拿到60条用例把上面那段提示词复制进文心一言的输入框点击发送之后你会看到它开始逐字生成Markdown表格。整个过程大概在30秒到1分钟之间取决于当前服务的繁忙程度。生成完之后我找到了页面上复制Markdown的按钮直接把结果粘到了本地一个.md文件里然后通过Excel的数据-从文本/CSV导入功能快速把Markdown表格转成了真正的Excel表。这一步很多人不知道实际上比手动复制粘贴每一个单元格要快非常多。第一版生成出来的用例大约有60条我数了一下覆盖了账号密码登录、验证码登录、记住密码、密码找回、锁定与解锁、Session会话、兼容性、安全性等八大类。从覆盖面上看AI做得确实比多数新人更全面比如它自动补了密码使用弱口令时系统是否拦截锁定时间到期后能否正常登录清除浏览器缓存后记住密码是否失效这类我个人都未必第一时间想到的场景。但这个初稿也不是完美无缺。仔细看你会发现部分预期结果写得比较笼统比如有一句系统应正确校验验证码这种描述放到Excel里是没法直接执行的必须改写成系统应在验证码错误时提示验证码错误并清空验证码输入框。还有一部分AI补充的测试数据是编造的比如用户名为A123456的账号实际测试环境里根本没有这个账号需要替换成真实数据。这些就需要进入下一步人工审查去处理。3.2 人工审查把80分的AI初稿改成95分拿到AI初稿之后我一般会做一轮15分钟左右的人工审查分三步走。第一步是逐条对照核心业务规则。我会把需求文档里的每一条关键规则拿出来跟AI生成的用例逐一比对。比对的目的是找出AI理解偏差的地方比如需求里写的是密码错误5次锁定账号但AI生成了密码错误5次后账号永久锁定虽然只是两个字的差异测试结果会完全不同。这一步必须要人工来做因为AI并不知道你系统的真实行为到底是什么。第二步是把测试数据从AI编造的换成真实可用的。这一步容易被忽视但直接影响用例能否被执行。我会把用户名:test001、密码:Test12345这类占位数据替换成测试环境里真实存在的账号并且把账号类型标注清楚比如已注册普通用户已锁定用户未注册手机号。很多测试同学在写用例时也会忽略这一点结果执行的时候才发现账号不存在又得临时找人创建效率非常低。第三步是重新排优先级。AI给出的优先级判断往往偏通用它会把所有安全相关用例都标成高但实际项目中登录接口的防暴力破解可能比注册流程的边界值更紧急这个轻重缓急只有了解当前迭代重点和线上风险的人才判断得了。我会把当前版本重点改造的功能相关用例全部提升优先级把AI默认高但实际影响面小的用例降为中或低保证回归测试时先跑最关键的部分。这一轮审查做完AI初稿基本就从看起来全变成了真正能执行。我自己算过一笔账同样一份登录用例以前从空白Excel开始写加上整理格式怎么也要3个小时现在这套流程AI生成5分钟人工审查15分钟总计不到半个小时而且覆盖面更全、格式更规范。4. 把AI结果落到Excel模板字段、下拉、高亮一次配齐4.1 测试用例Excel模板的字段设计AI生成的是Markdown表格要落到团队协作用的Excel里字段还需要再扩展一下。我自己的模板里会放这些列字段名填写说明示例用例编号模块前缀_类型_三位序号LOGIN_CN_001所属模块被测功能模块登录用例名称一句话描述验证点正确账号密码登录成功前置条件用例执行前需要满足的状态账号test已注册且未被锁定测试步骤数字编号列出操作步骤1.进入登录页 2.输入账号 3.点击登录测试数据步骤中使用的输入值邮箱:testexample.com 密码:Test12345预期结果可断言的系统表现登录成功跳转首页右上角显示用户名优先级高/中/低控制执行顺序高用例类型功能/UI/安全/性能/兼容性功能执行结果未执行/通过/失败/阻塞通过执行人实际执行用例的人张三备注补充说明或关联缺陷ID关联BUG-1024字段设计有几个细节值得注意。首先是预期结果这列我在模板里明确要求填写可断言的描述也就是能明确判断成功还是失败而不是系统应正确处理这种废话。其次是所属模块和用例编号要分开因为后续做用例统计和筛选时按模块分组看用例分布是非常高频的需求。最后是执行结果状态建议和团队的测试管理系统保持一致不要自己发明一套名词否则后续统计口径对不上。4.2 几个能提升填表效率的Excel小技巧模板字段定好了再说几个我实际用下来觉得特别好用的Excel功能能让这套模板从表格变成半自动化工件。第一个是数据验证下拉菜单。选中优先级列整列点击数据验证允许条件选序列来源填高,中,低确定。这样填表时直接点下拉选择不用每次手敲。同理用例类型列来源填功能,UI,安全,性能,兼容性,异常执行结果列来源填未执行,通过,失败,阻塞。这个操作一分钟就能完成但能让全组的人填表口径保持统一不会出现高优先级高混着写的情况。第二个是条件格式高亮。点击开始-条件格式-新建规则选择使用公式确定要设置格式的单元格公式填$J2失败然后设置一个浅红色填充。这里的$J2假设执行结果在J列如果你的模板列顺序不同需要按实际列号改。设置完之后失败的行会自动标红整个测试周期的通过情况一眼就能扫出来。我再加了一个规则$J2阻塞标黄色失败和阻塞在视觉上直接分开。第三个是冻结首行加自动筛选。视图-冻结窗格-冻结首行然后CtrlShiftL开启自动筛选。做完整理的时候我会按优先级筛选出所有高优先级用例再按用例类型筛出安全维度单独拉出来做一轮专项确认非常方便。第四个是关于用例编号的一个小技巧。如果用例数量一多手动改编号很容易出错。可以在用例编号列使用公式CONCAT(LOGIN_CN_,TEXT(ROW()-1,000))这样往下填充的时候编号会自动生成。第一行表头占了一行所以ROW()要减1。当前面的行被删除时编号也会自动更新不会再出现断号的情况。需要批量导入禅道或其他管理系统时直接把这一列复制成值再导出即可。5. 翻车现场汇总AI生成用例最常见的6个坑5.1 六大高频翻车场景与排查方案我自己前前后后用AI写了十几个模块的测试用例踩过的坑不少。这里整理一个速查表按现象-根因-解决方案的方式列出来你对照着就能避坑。现象根因解决方案生成的用例太泛泛像教科书模板提示词没有提供具体业务规则把需求逐条编号写进提示词越具体越好漏了短信验证码/图形验证码场景AI不知道你的登录包含验证码在功能需求描述里单独列出包含验证码登录测试数据是编造的AI没有真实环境数据人工替换为真实账号并标注账号类型预期结果描述含糊无法执行提示词没要求可断言追加预期结果必须可判断成功或失败业务规则理解错误规则本身复杂且描述不清抽取核心规则用必须强调单独成段多轮对话后忘掉之前的约束上下文被后续内容干扰重要约束在每次追加问题时重复发送一遍展开说几个我印象最深的。测试数据是编造的这个坑第一次用AI生成用例时最容易踩。AI生成的测试数据看起来有模有样比如用户名:zhangsan、密码:Abc123456但等你真正执行的时候才发现测试环境里根本没有这个账号还得去找开发创建数据白白浪费半天。现在我收到AI输出后会第一时间扫一遍测试数据列凡是编造的数据全部替换成测试环境真实存在的账号或者统一写成预置账号:test_01然后单独在旁边标注。预期结果含糊也是个高频问题。AI初稿里经常出现系统应正确反馈或者页面表现正常这类描述这种用例发到测试执行人手里根本没法判断到底算通过还是失败。我试过在提示词里直接加一句预期结果必须是可以明确判断成功或失败的客观描述禁止使用正确正常等模糊词汇加了这句话之后输出质量明显提升了一个档次。多轮对话后忘掉约束是我在让AI补用例时遇到的。我先让它生成了一版然后让它再补充移动端场景的用例结果它补充的用例里用例编号格式、优先级标注方式全都变了跟第一版完全对不上。后来我每次追加需求都会把用例编号格式仍然使用LOGIN_CN这种前缀这类关键约束重新发一遍问题就解决了。5.2 AI生成内容进入评审前的检查清单结合这些翻车经验我总结了一份AI生成用例评审前检查清单每次用AI生成完用例后我都会过一遍保证交到评审会上的内容经得起问。第一项逐条比对核心业务规则。这块强调的是需求里明确的规则用例里必须有对应覆盖比如连续5次错误锁定账号30分钟这条必须能看到对应的成功路径和失败路径用例甚至锁定时长边界值也算上。第二项检查AI补充标记的用例是否合理。我在提示词里要求AI把自己补充的内容打上标记拿到结果后我会重点看这些标记。如果内容是通用的业界实践比如登录接口应使用HTTPS传输我就保留如果明显不符合我们系统的设计比如支持指纹登录而我们根本没做指纹登录我会直接删掉或改写。第三项确认测试数据和预期结果都可执行。这一点前面提过但值得再强调因为评审会上被问最多的就是这条用例怎么执行预期结果是什么标准。把这两列打磨清楚用例评审通过率会高很多。第四项检查编号和格式是否统一。批量生成的用例编号前缀、优先级大小写、用例类型用词都要保持全表一致否则后面做统计和追溯时非常痛苦。6. 登录只是一个开始AI测试还能怎么玩6.1 从用例生成到自动化脚本AI测试的进阶玩法登录用例的AI生成其实只是AI测试这件事很小的一块。我尝试下来觉得下面几个方向同样值得测试团队关注。第一个是AI辅助生成自动化测试脚本。既然Excel里已经有了步骤明确的测试用例那能不能让AI把这些自然语言步骤直接翻译成自动化脚本我试验过把一条1.进入登录页 2.输入用户名 3.输入密码 4.点击登录 5.验证跳转首页的用例丢给AI让它生成一段Selenium脚本它能给出一个八九不离十的版本你只需要把元素定位符改成自己项目里的真实选择器。对于刚上手自动化测试的团队这个能力能显著降低写脚本的启动成本。现在很多AI自动化测试工具也在做录制自然语言操作生成脚本的路子方向基本一致。第二个是AI辅助缺陷分析。测试执行过程中失败用例会留下一堆日志和截图。我把日志关键信息和界面截图描述喂给AI让它基于经验给出失败可能的原因它往往能指出一些我忽略的线索比如接口返回500之前有一个超时重试的日志怀疑是服务端连接池配置问题这类推测。虽然它不能替代真正的开发排查但能帮我缩小定位范围节省不少时间。第三个是AI变异测试。这个方向偏研究一些核心思路是让AI对被测代码做小改动生成一堆变异体然后跑一遍现有测试集看测试用例能不能把这些变异体测出来。如果某个变异体没被测试用例杀死说明测试集存在漏洞。这个玩法评估的是你的测试用例本身的质量跟AI生成用例配合起来能比较科学地衡量测试覆盖率到底够不够。第四个是AI在安全测试领域的应用比如辅助渗透测试和漏洞探测。AI可以根据你描述的系统类型和接口信息生成探测用的输入样例、构造异常请求、甚至给出攻击链路建议。它在这个领域的定位是辅助而不是全自动因为安全测试的误报率本来就高最终判断还是需要专业的测试人员来做。6.2 测试工程师和AI协作的边界在哪里说到最后我特别想说一说我对AI会取代测试工程师吗这个问题的看法。我自己用了大半年AI辅助测试最直观的感受是AI改变的不是要不要做测试而是怎么做测试。那些重复的、规则清晰的、依赖知识面铺底的测试工作AI确实能干得又快又多。比如登录用例生成、基础回归用例整理、通用格式的格式化输出这些都是AI的优势区间。但真正涉及复杂业务流程的链路设计、需要结合用户场景做主观体验判断、需要在多个需求之间权衡测试优先级、需要跟开发产品沟通确认需求意图的事情AI目前还远远替代不了人。它没有对业务的理解没有对用户痛点的感知更没有这个功能上线出问题影响有多大的风险判断力。所以我的建议是测试工程师不妨把AI当成一个永远精力充沛、知识面很广但不懂业务的小助手。你负责告诉它业务规则和重点它负责快速铺底和查漏补缺你来做最终的决策和收口。这种协作方式下你花在基础工作上的时间会大大减少省下来的精力正好可以投入到更高价值的业务测试设计和质量策略上。对个人发展来说这反而是个提升空间更大的机会窗口。我个人现在的工作习惯是接到任何测试任务第一步不是打开Excel而是先花5到10分钟把业务规则梳理成一条条可验证的描述然后丢给AI生成初稿。这个过程本身就会倒逼我把需求想清楚——如果我自己都说不清规则AI生出来的东西一定没法用。所以别把AI当成偷懒神器把它当成一面强制你想清楚需求的镜子效果会好得多。
阅读完成 · 觉得有帮助？
