1. 测试用例设计从读需求到批量出场景1.1 我为什么先把AI用在用例设计上做软件测试这些年最耗时、最磨人的环节不是执行而是设计用例。尤其是接到那种改动范围大、涉及多个模块的需求PRD随手一甩就是几十页把业务流啃明白、把异常路径想全往往要花掉一天甚至更久。等到评审会上产品问一句这个状态如果同时被两个用户触发会怎样你发现自己还是漏了场景那种感觉是真难受。后来我开始把ChatGPT引入到用例设计这一步思路很简单让AI先把正常流程这条主线快速铺出来我再集中精力去补业务规则和边界异常。实测下来第一版用例的产出时间从原来的半天压缩到一个小时左右而且AI给出的基础场景覆盖质量并不差。这不是说AI替代了测试分析而是它替你把体力活干掉了你只需要做更有价值的判断和校验。我在实际工作中喜欢用一种比较固定的提示词结构这里直接给出来你们可以按自己的项目改一改你是一名资深测试工程师。下面是一段脱敏后的需求描述[粘贴需求内容]。请使用场景分析法从正常流程、备选流程、异常流程三个角度输出一份测试用例清单。每条用例包含用例编号、前置条件、操作步骤、预期结果、优先级。先不要写自动化脚本只关注测试设计。这里有个关键点喂给AI的需求一定要做脱敏处理涉及到真实账号、手机号、业务密钥的信息要么替换成测试桩数据要么删掉。我见过有同事直接把生产环境的业务截图丢进去后面被安全组约谈这点务必注意。AI给出的第一版用例通常能覆盖正常流程的70%到80%但业务规则复杂的模块比如金额计算、状态机切换、权限组合它往往会想当然。我的做法是把接口文档里对应的字段约束、状态流转图转成文字描述一起贴给AI再让它重新生成。加了约束条件之后准确性会明显上一个大台阶。1.2 用等价类边界值错误推测组合拳补全场景光让AI出基础用例还不够真正拉开测试质量差距的地方在于那些正常人不容易想到的边界和异常场景。这块恰恰是ChatGPT比较擅长的地方因为它被训练的数据里包含了大量软件缺陷案例和测试设计方法你只要用对方法去引导它就行。我常用的第二个提示词是请针对上面这套测试用例分别使用等价类划分、边界值分析和错误推测法进行补充。重点考虑空字符串、null值、超长字符、特殊符号、并发操作、重复提交、权限不足、接口超时、第三方依赖返回异常等场景。输出格式与上面保持一致并标注每条用例是基于哪种方法设计的。这个步骤跑完之后你会发现自己原来漏掉了很多看起来理所当然不会发生的场景。比如一个金额输入框你可能会测0、负数和超大值但AI会提醒你补充小数位超过两位金额为科学计数法前后端精度不一致这些更贴近真实故障的用例。这些都是我在实际工作中踩过的坑现在靠着这个习惯提前堵住了不少线上隐患。不过我得泼一盆冷水AI补出来的用例并不是都能用偶尔会有一两条属于理论上存在、现实里根本不会走到的空想场景。所以它生成的用例最终一定要有人工评审环节。我的做法是让AI先产出我再和组里的同事过一遍确定有价值的才进用例库而不是无脑全收。用例设计的价值在于好钢用在刀刃上别让自己变成AI的copy机器。1.3 评审与回归场景里的AI配合测试用例评审会历来是个容易冷场的环节尤其是那种几十条用例铺在表格里大家对着屏幕一页页翻效率很低。我的经验是在评审前让ChatGPT先当一次虚拟评审专家。提示词可以这样写下面是我针对某模块设计的测试用例清单[粘贴用例]。请从测试设计完整性、需求可追溯性、用例冗余度三个角度进行评审。指出可能遗漏的高风险场景标出重复或无效的用例并给出修改建议。AI给出的意见不一定都专业但至少能让评审会有一个讨论的起点。很多时候它会指出这组用例里没有覆盖到用户取消操作后的数据回滚这种提醒就能帮我们提前发现问题。还有一个很实用的场景是回归测试。每次上线前我习惯把本次改动涉及的功能点和影响范围整理成一段文字让AI结合原有用例库生成一份针对性回归清单。这里要注意不要让AI凭空生成回归清单它不了解你项目的上下文生成出来的东西往往泛泛而谈。正确的做法是把之前用例库的关键路径、本次改动的代码影响模块由开发提供一起丢给它再让它筛选和组合这样产出才有真正的参考价值。2. 自动化测试脚本让AI当你的结对编程搭子2.1 快速生成Selenium脚本骨架我踩过的老语法坑如果你做Web端测试大概率用过或想过用Selenium。要说ChatGPT在自动化测试上最省时间的点就是写脚本骨架。以前我们写一个页面对象类从定位器到操作封装手写一套得半小时现在用AI几分钟就能拉出来。但这里有个大坑我必须重点提醒ChatGPT训练数据里有大量Selenium老版本的代码它很容易生成find_element_by_id这种旧API。你要是环境装的是Selenium 4以上的版本跑起来直接报错然后你还要花时间查错修改反而更浪费时间。我自己就因为这个一度觉得AI生成的代码根本没法用。后来我调整了策略在给AI提问之前先把当前项目的依赖版本信息告诉它。提示词开头直接加一句我的环境是Python 3.11 Selenium 4.15 Chrome 120请使用当前主流API生成脚本不要使用find_element_by_xxx这类已废弃的方法。有了这个前置约束AI生成的脚本几乎可以零修改直接跑通基础流程。这个小小的改动直接把脚本生成的可用率从五成拉到了八成以上。类似的思路也适用于其他技术栈Appium、Playwright、Requests都一样先讲清楚版本再让它干活。2.2 读懂AI生成的代码用重构消化黑盒生产AI写代码的能力确实不错但它有个特点它不知道你的项目规范也不知道你组里约定俗成的命名方式所以直接生成的代码经常是能跑但很乱。比如一个登录测试脚本它可能把等待逻辑写在每一步操作里搞得整个脚本冗长还难以维护。我见过不少测试新手拿到AI代码就往仓库里传结果别人review的时候一头雾水。我的习惯是把AI当成初稿工具而不是最终交付工具。脚本生成之后我至少要做三件事第一把硬编码的测试数据提取成配置文件或数据驱动文件第二把公共操作封装成Page Object或者方法第三加上必要的异常处理和日志输出。这三步做完代码才算真正属于你的项目。这里分享一个我常用的重构提示词下面这段Selenium脚本是我生成的初稿[粘贴脚本]。请按照Page Object模式帮我重构将元素定位、页面操作、断言分离。保持功能不变代码风格要求简洁添加必要的异常捕获和日志记录。重构完的代码质量通常比我自己手写还要规整因为AI在模式识别方面很稳。当然最后一定要自己跑一遍用例确认功能没被改坏。用AI不代表可以做甩手掌柜你依然是代码质量的第一责任人。2.3 定位器失效、框架迁移这两件事AI能帮大忙UI自动化里最折磨人的就是定位器失效。今天还是idlogin_btn明天前端重构就变成了classbtn-primary login-button脚本直接红灯一片。以前遇到这种情况我得打开开发者工具一阵乱翻才能找到合适的替代定位器现在这个活儿可以让AI分担。我的做法是把报错信息、页面的HTML片段从开发者工具里复制一起贴给AI然后问它页面定位器失效了这是报错信息[报错内容]这是相关的HTML结构[粘贴HTML片段]。请帮我给出5种可替代的定位策略优先使用稳定的属性避免使用会随页面渲染变化的index。AI给出的方案里基于>
