做软件测试这些年最让我头疼的不是复杂的业务链路也不是刁钻的线上故障反而是登录功能这种不起眼的模块。原因很简单登录虽小但它牵扯到的场景实在太多了正常路径、异常路径、安全攻击、兼容适配、锁定策略、验证码机制……真要正儿八经写一遍几十条用例轻轻松松写起来全是重复劳动。最近我尝试用文心一言来做AI测试辅助把登录功能测试用例的生成压缩到了5分钟左右还顺手沉淀了一份可以直接复用的Excel模板。这篇就完整讲讲我的实操过程、提示词设计思路以及AI生成用例之后必须做的人工复核。1. 登录功能为什么值得当作AI生成用例的试验田1.1 一个登录模块拆出来有多少种场景先别急着看AI怎么操作咱们先拆一下登录功能本身。很多人提到登录就觉得是输入账号密码、点登录但真正做测试的时候你会发现一个标准的登录模块至少包含下面这些维度功能测试正常登录、错误密码、空账号、空密码、账号不存在、密码大小写敏感、回车键登录、记住密码功能输入校验手机号/邮箱格式校验、密码长度边界、特殊字符、前后空格处理安全测试暴力破解锁定、验证码有效期、验证码错误次数、SQL注入字符串、密码是否加密传输异常场景网络超时、服务器异常、接口返回超时、session失效兼容性不同浏览器下Chrome、Edge、Safari、Firefox的展现和响应易用性登录按钮置灰逻辑、错误提示是否友好、密码可见切换、Tab键焦点顺序联动场景忘记密码流程、验证码发送次数限制、登录成功后跳转、异地登录提醒、多端登录互踢。这个清单还不是全部如果你遇到的是某个业务系统内部的登录还得叠加该系统的特殊规则比如指定IP段才允许登录、需要二次短信验证、某类账号只能从特定入口进入等等。1.2 我为什么先拿登录模块试水AI测试我手头正好在负责公司内部CRM系统的登录模块改造因为涉及账号体系的统一测试范围从原来的单一账密登录扩展成用户名密码图形验证码企业微信扫码三种登录方式。老实说这三种方式单独看都不复杂但它们会产生大量排列组合。比如图形验证码的错误提示是否影响密码缓存、扫码登录成功后页面跳转参数是否正常、验证码过期后输入正确的账号密码能否继续登录……这类场景要是纯手工罗列非常费时间而且容易漏。所以我把这个模块当作AI测试的试验田。选择它的原因有两个一是登录模块规则相对清晰适合考察AI对逻辑边界的理解能力二是它的重复性高、覆盖面广最能体现AI生成测试用例的效率优势。整个流程走完一遍之后我不仅拿到了几十条可用的用例还把生成Excel模板的标准做法也一起沉淀下来了。2. 让文心一言听懂需求的Prompt设计思路2.1 新手最常见的提问方式为什么会失败直接说结论如果你的问题是帮我生成登录功能的测试用例那得到的回答大概率很泛看着模板化实际没法直接落地。我试过文心一言会给你列一个通用清单包括输入正确的账号密码输入错误密码输入为空这种不能说错但距离真正能用还差很远。问题出在哪在于AI没有上下文。它不知道你的登录方式是账密还是扫码不知道验证码的规则也不知道期望的输出格式。你让它生成测试用例它就只能按训练数据里最常见的登录模型来答这种答案放在任何系统上都是正确的废话。这就好比让同事帮你写测试用例你只说一句测一下登录他除了问你需求文档在哪儿还会问你密码策略、锁定规则、需要输出什么格式。AI也一样Prompt里的信息密度决定了结果的质量。2.2 我用的Prompt模板逐句拆解经过几轮调整我目前固定使用下面这个Prompt模板效果比较稳定。它不是玄学每一句都有对应目的。你是一名资深测试工程师请为CRM系统的登录模块设计测试用例。 系统情况 - Web端登录浏览器使用Chrome/Edge - 登录方式一用户名密码图形验证码 - 登录方式二企业微信扫码登录 - 图形验证码4位数字有效期60秒最多允许输错3次 - 密码策略8-16位必须包含字母和数字 - 账号锁定同一账号连续输错5次密码后锁定30分钟 要求 1. 从功能、输入校验、安全、异常、兼容性、易用性、联动场景7个维度设计用例 2. 每条用例包含用例编号、所属维度、测试标题、前置条件、测试数据、测试步骤、预期结果、优先级 3. 优先级分P0/P1/P2核心主流程标记为P0 4. 用Markdown表格输出拆解一下你是资深测试工程师给AI一个角色定位它后续输出的措辞和思维方向会主动向专业测试靠拢系统情况这五个约束是我从被测系统的需求文档里提炼出来的关键规则直接决定了用例的准确性。你不给它这些规则它就只能猜测7个维度给AI划定思考边界避免它漏掉某一大类场景每条用例包含哪些字段这是在提前为Excel模板做结构化准备省去二次加工的麻烦用Markdown表格输出明确格式能直接复用到Excel里效率最高。2.3 针对不同登录方式的Prompt变形上面是账密验证码扫码的混合场景如果你手头只有单纯的账密登录Prompt可以精简成下面这样你是一名测试工程师请为Web系统登录功能设计测试用例登录方式为手机号密码手机号需校验11位数字格式密码为6-20位任意字符。请从功能、安全、异常三个维度输出用例每个用例包含用例名称、前置条件、测试步骤、预期结果、优先级。变形的核心思路很简单把被测系统的实际规则填进去把不需要的登录方式删掉再指定你想要的输出字段。不要一上来就想面面俱到AI擅长的是基于约束条件的发散而不是替你猜需求。3. 5分钟实操从一句需求到结构化用例的完整过程3.1 需求描述把业务规则讲清楚我们来看一次完整的实操。我实际用来生成CRM登录用例的需求描述就是从需求文档里摘出来的几段话登录页位于CRM系统首页支持用户名密码图形验证码登录支持企业微信扫码登录用户名为企业内部工号6位数字密码为8-16位必须包含字母和数字图形验证码为4位数字点击可刷新有效期60秒同一账号密码连续输错5次账号锁定30分钟企业微信扫码登录需要绑定过企业微信未绑定账号提示先去OA系统绑定。这段描述只有不到100字但它涵盖了账号格式、密码规则、验证码生命周期、锁定策略、扫码绑定限制五个关键信息点足够AI展开生成用例了。3.2 四轮对话把用例逐层补齐第一轮把上面的需求描述套进2.2的Prompt模板稍作修改后发给文心一言。它的输出是一张包含约30条用例的Markdown表格覆盖了功能、输入校验、安全、异常、兼容性、易用性、联动场景7个维度基本骨架已经出来了。第二轮我追加了一句请补充账号被锁定状态下的测试用例包括锁定期间内不断尝试登录、锁定时间结束后自动解锁的场景。因为第一轮虽然提了锁定策略但AI生成的用例往往停留在锁定了要提示这一层不会主动细化到锁定倒计时结束后能否正常登录跨天锁定如何处理这种细节。第三轮我让它补充图形验证码的完整生命周期用例包括刷新、过期、错误3次后是否出现二次验证。验证码是最容易被AI漏掉的部分训练语料里常见的验证码用例就是输入错误验证码提示失败但实际业务里验证码刷新、过期、多次错误后的交互才是重点。第四轮我要求把所有用例整理成CSV格式字段为用例编号、所属维度、测试标题、前置条件、测试数据、测试步骤、预期结果、优先级。这一步是为了直接导入Excel。四轮对话加起来实际耗时大约3分钟其中大部分时间花在阅读和判断AI输出上而不是打字。3.3 从对话结果转Excel模板的两种方法拿到CSV格式的用例后转Excel有两种比较顺手的做法第一种如果用例条数不多直接把CSV文本复制进记事本保存为UTF-8编码的.csv文件再用Excel打开。打开时如果中文乱码就用WPS的数据-导入-从文本功能选UTF-8编码即可。第二种如果你正在用Excel直接把文心一言输出的Markdown表格复制然后粘贴到Excel工作簿中。Excel一般能自动识别竖线分隔的表格结构粘贴后如果没自动分列就用数据-分列分隔符选|。我个人更推荐第一种因为CSV是纯文本结构导入时只需一次性处理而且后续在Python或者任意测试管理平台里都好用。提示如果AI输出的CSV字段里包含逗号或换行记得提醒它对于含逗号的字段用引号包裹否则导入Excel时列会错位。这是个很容易忽略的小坑。4. Excel模板长什么样字段设计与复用方式4.1 模板字段一览每列都有用处很多测试同学喜欢随手建表表头写模块、步骤、结果就完事了等到用例评审时要补优先级写测试报告时要统计执行结果又回头加列非常被动。我在这次实践中把模板字段固定成了下面这些字段名类型说明用例编号文本按模块类型序号生成如CRM-LOGIN-FUN-001所属维度枚举功能/输入校验/安全/异常/兼容性/易用性/联动场景测试标题文本一句话描述测试目的前置条件文本准备数据、账号状态、环境要求测试数据文本具体的输入值或数据预置说明测试步骤文本按1/2/3编号的操作步骤预期结果文本对应每个步骤的期望表现优先级枚举P0/P1/P2是否自动化枚举是/否执行结果枚举未执行/通过/失败/阻塞备注文本需求变更说明或遗留问题这个模板看起来字段多其实每列都能在实际执行阶段派上用场。执行结果列尤其重要因为很多人在用例设计阶段不会考虑执行状态等真跑起来才发现只能另起一张表记录结果。4.2 优先级和用例编号的设计规则优先级我建议分P0、P1、P2三档就够了太多档会在评审时吵起来三档恰好对应核心流程必须测重要但不能阻塞发版边缘场景有时间就测。P0通常只给最核心的几条正常登录成功、登录失败提示正确、账号锁定生效、锁定后无法登录。这几条挂了就是事故没得商量。P1覆盖常见异常和校验类场景P2留给兼容性、易用性、极端边界。用例编号我习惯按系统简称-模块-类型-序号编比如CRM-LOGIN-FUN-001。这样在缺陷管理工具里关联缺陷号时一眼就能看出这条用例属于哪个模块哪个维度不需要再翻Excel。4.3 把AI生成的用例批量粘贴进模板的操作当文心一言输出的是标准字段后粘贴其实很机械。我的做法是在Excel里建好上面那张字段模板冻结第一行打开文心一言输出的CSV文件全选复制粘贴到模板Sheet中此时AI生成的内容只占用了后8列从用例编号到优先级手动补上是否自动化执行结果备注三列首轮全填否未执行空用条件格式把P0用例整行标成浅红色P1标成浅黄色执行结果失败标成深红。这套操作下来大概两分钟一份可评审、可执行、可追踪的登录功能测试用例就齐了。5. 文心一言看不到的盲区复核清单与二次追问技巧5.1 最容易漏掉的高频缺陷账号锁定与验证码生命周期AI生成用例确实快但它不是神。第一轮生成的30条用例里我逐条过了一遍发现有三个高频盲区一是账号锁定场景只写了提示密码错误和账号锁定没有写锁定30分钟期间内即使密码正确也不能登录也没有写30分钟后自动解锁的验证方式。而后者恰恰是最容易出线上问题的点因为开发在实现锁定逻辑时常常只做了一半——忘记加解锁的定时任务。二是验证码的生命周期没有被完整覆盖。AI会生成验证码错误提示但它不会主动想到验证码过期后提交、点击验证码图片刷新、连续输错三次后是否出现新的校验机制比如滑块验证。这三个点都是实际使用中用户最容易遇到的也是客服投诉的重灾区。三是多端登录和登录后跳转的联动场景缺失。AI生成的用例倾向于把登录当成一个封闭页面来处理默认登录成功后直接进入首页。但CRM系统存在从工单详情页跳转登录页登录成功后要回到原工单详情这种需求AI不了解需要人工补充。5.2 用自问自答式追问逼出边界场景针对上述盲区我摸索出了一种非常有效的追问句式把自己当成一个较真的测试新人连续向AI发问。第一轮追问关注锁定账号锁定后如果在30分钟锁定期内不断尝试登录会有什么表现这里应该设计哪些用例 第二轮追问关注验证码图形验证码有效期是多少验证码过期后提交登录后端应该返回什么请围绕验证码的有效期、刷新、错误次数设计完整用例。 第三轮追问关注联动用户从其他页面被踢回登录页登录成功后应该跳转到哪里请补充这类登录后跳转的用例。每一次追问文心一言都会追加输出几条新用例而且质量明显比第一轮高因为它有了对话上下文。这个自问自答的过程其实就是我平时测试思维的外显——先按维度穷举再针对每个维度的边界条件深挖。5.3 人工复核的五项检查清单AI生成的用例无论看起来多专业最终都要过一遍人工复核。我把自己的检查项整理成了清单每次都用它过一遍与被测系统规则是否一致。重点检查密码长度、锁定次数、验证码有效期这些参数是否和需求文档一致AI如果记错了上下文就会写错预期结果是否可验证且唯一。像界面显示正确系统正常处理这类模糊预期必须改成登录成功并跳转至首页错误提示显示密码错误剩余4次机会这种能直接判断的表述是否有重复用例。同一场景有时AI会用不同说法生成两遍保留其中表述更清晰的一条是否有无法执行的高成本用例。比如并发登录1000用户的性能用例如果当前测试环境不具备就单独挪到性能测试组别混在功能用例里是否补充了业务特有逻辑。比如我们CRM系统要求首次登录必须修改初始密码AI不会知道需要人工加上。这一步最费时间但因为AI已经把80%的重复劳动干完了我只需要把精力放在业务规则和边界判断上整体效率还是远高于从零开始写。6. 用AI生成用例的真实效率账5分钟背后的时间都省在哪6.1 手写与AI生成的一组对比数据我不爱讲虚的直接放一组我这次的实测数据。同样是为CRM系统三种登录方式设计测试用例覆盖功能、安全、异常、联动场景最终交付到Excel模板对比项传统手写方式文心一言人工复核用例总量46条58条用例设计耗时约3小时约20分钟Excel模板整理耗时约40分钟约5分钟发现盲区后补用例需要重新走一遍流程追加一轮对话最终可用用例46条53条AI生成的58条里有5条被我删掉或重写原因是预期结果不够精确或场景重复。但保留下的53条里有很多是我一开始没想到的比如验证码过期后提交是否清空已输入的密码扫码登录后原账号密码登录的会话是否失效这类细节。6.2 模板沉淀与团队复用这次实践更大的收获其实是那份Excel模板和Prompt的组合在团队内沉淀了下来。我把Prompt模板放到了团队的Wiki里同事接单新模块时只需要替换系统情况和需求规则就能快速生成该模块的测试用例初稿。Excel模板也同步共享字段统一之后用例评审时大家讨论的都是业务问题而不是表格结构问题。更重要的是这套方法不只适用于登录功能。我把同样的思路迁移到了订单流程、权限管理、导入导出功能上效果都很稳说明AI结构化Prompt标准化模板这三件套的组合是通用的。6.3 AI测试的边界感什么能信什么不能信最后聊聊边界感。AI测试本质上是辅助工具它的价值是把用例设计的起步成本降到最低让我能更快地进入深度思考。它最擅长的是基于已给规则做穷举和发散在功能测试、输入校验、异常登录这些维度表现很好。但它不懂你的业务闭环。首次登录强改密码、审批流程与登录超时时间的联动、运营后台角色权限对登录入口的过滤这些只有深入理解系统的人才能写出来。所以我的建议是把AI当作一个不知疲倦、思维发散的测试新同事把规则和需求讲清楚后让它打草稿但最终拍板的人一定是自己。按照我现在的习惯每次接手一个模块都会先用这套方法把基础用例铺出来然后花同样的时间做评审和复核。实测下来AI生成和人工复核的时间比大概是1:4也就是说AI花5分钟我至少还要花20分钟去人工打磨。但这依然是划算的因为打磨本身就是测试设计的核心工作AI只是帮我把这部分工作的起点抬高了。