1. 先把移动应用的特殊性说透用例设计的第一步不是画表格在测试团队里待久了你会发现对测试用例有两种极端看法。一种觉得用例就是写出来应付流程的文档执行时全靠临场发挥另一种觉得用例就是全部写完用例就等于测完了。我踩过不少坑之后得出的结论是用例本身不是文档问题而是策略问题。移动应用测试的场景复杂度远超预期用例是唯一能把风险可视化、把回归可控化的工具。标题里“移动应用测试用例以及如何用于测试”这句话拆开看其实是两件事第一移动应用的用例和普通功能测试用例到底有什么不同第二用例写完之后怎么在真实的研发节奏里把它用起来——包括评审、执行、追踪、复用到自动化。这两件事做不好用例就只是一堆躺在文档库里的死文字。很多刚转移动测试的同学习惯照搬Web端测试的用例模板结果一上线就被打脸。问题在于移动端有几个Web端没有的维度这些维度会直接决定用例的设计思路。1.1 网络环境是移动应用的“隐形杀手”你很难想象一个Web应用会在用户浏览到一半时突然切换网络协议栈但手机可以。用户从Wi-Fi走到楼道里信号自动切到5G从地铁站出来网络从无服务状态恢复到4G在电梯里网速从几十兆掉到几十KB。每一次切换对App来说都等于一次环境突变。我在一个社交App项目里就栽过跟头。当时设计发图文的功能时用例只覆盖了正常网络下点击发送、发送成功、发送失败提示这几种链路。结果用户在实际使用中经常遇到一种情况在电梯里点发送进度条一直转电梯门一开网络恢复消息自动发出去了。这本来是好事但问题在于发送过程中用户以为失败了又点了一次发送结果一条图文被重复发布了两次。移动应用的弱网用例至少要覆盖以下几类网络切换Wi-Fi切5G、5G切Wi-Fi、双卡切换切换瞬间正在进行的操作是否中断弱网状态通过模拟弱网工具比如常用的网络限速工具模拟上行/下行低带宽观察请求超时时间、超时提示、重试机制断网恢复飞行模式开启再关闭、实体SIM卡临时无服务恢复网络后未完成的操作是否自动重试、数据是否丢失请求超时服务端响应延迟超过客户端超时阈值客户端是否有明确的超时反馈用户重试时是否会重复提交这几项是移动应用用例和Web端用例最大差异之一。Web端当然也会断网但用户很少在网页加载到一半时走出Wi-Fi覆盖范围而手机用户几乎每天都在经历这种状态变化。1.2 系统级事件一通电话就能打断整个用例手机是一个“随时可以被外部事件打断”的设备。来电、通知、闹钟、低电量弹窗、锁屏、用户主动切后台、分屏模式这些系统事件是Web测试完全不用考虑的。我之前测试一款音视频通话类应用时专门设计了“通话中被来电打断”的用例用户在语音通话中手机进来一通电话A路通话被挂起接通电话挂断后App的语音通话状态是否正确恢复。这里面涉及的问题非常多——麦克风权限是否被重新申请、通话时长是否重置、通话界面是否回到了正确页面、对方端是否正常挂断、两端状态同步是否一致。漏掉任何一环上线后必然有用户反馈“打完电话接着聊天发现对面听不到我说话了”。类似的中断场景还有视频播放中切前后台回来之后进度是否保留表单填写中锁屏解锁后App是否还在原页面输入内容是否丢失直播观看中接到语音通话直播声音是否停止挂断后是否恢复下载任务进行中低电量自动关机重启后任务状态是否正确这类用例有个共同特点不是App本身的功能逻辑出了问题而是App被系统事件打断了之后恢复逻辑写得不对。所以用例如无特别说明要把中断和恢复当作一个完整场景来设计而不是只测到“按下Home键”就结束。1.3 权限弹窗的交互比功能本身更容易翻车移动应用和权限深度绑定——定位、相机、麦克风、相册、通知、通讯录、日历、健康数据几乎每个功能都需要至少一个权限。权限设计和用例设计的核心冲突点在于用户可能在任何时间、任何状态下改变对权限的态度。新手编写用例时最常犯的错是只测“授权后功能正常”的路径。实际上用户拒绝权限、拒绝后再次触发、拒绝后进入设置页开启、仅在使用期间允许、从不允许到允许、从允许到关闭这些路径加起来才是权限用例的全貌。举一个地图类App的例子。用户首次启动系统弹出定位权限请求用户选了“永不”。此时用例要跑的场景包括首页是否正常加载、当前位置是否显示占位信息、点击“定位”按钮后是否出现引导开权限的提示——注意这里不是直接跳设置页而是先有弹窗说明跳转原因因为直接乱跳设置页会被应用商店审核拒掉。用户从“永不”改为“使用期间允许”后回到App是否能立刻获取定位、是否需要重启进程。这里有个实际经验很多Android机型的定位权限变了之后App进程如果还活着定位回调拿不到最新权限状态需要杀掉进程重启才能生效。这个细节如果用例里不写开发是不会主动处理的。厂商定制系统的存在又让权限问题复杂了一层。标准Android的权限模型在国产ROM上经常被魔改比如后台定位权限默认关闭、应用启动时有自启动拦截、省电策略里有“杀死后台应用”的选项。同一个权限用例在原生系统和定制系统上的表现可能完全不一样移动应用测试用例里必须单独列出一项“厂商ROM适配清单”。1.4 机型、分辨率、系统版本的兼容性不是靠感觉覆盖的兼容性用例最怕的是“拍脑袋选机型”。适配用例的前提是有一份真实的用户机型分布数据。我之前维护的一个项目测试组一直用主力机型和几台热门中低端机测试结果应用商店崩溃率最高的却是两款我们根本没测过的千元机——原因不是屏幕适配问题而是这两个机型的WebView内核版本太低App内嵌H5页面直接白屏。设计兼容性用例时建议参考三个维度的交叉组合系统版本覆盖主要Android版本和iOS版本重点关注系统升级后旧版本兼容屏幕类型常规屏、刘海屏、挖孔屏、折叠屏以及平板等特殊尺寸厂商定制系统重点关注后台管理策略、权限模型、推送行为差异分辨率适配当然要测但现在的App框架大都能自动适配分辨率真正需要人工看的是异形屏区域和底部安全区。折叠屏更是重灾区展开前后的Activity重建、宽高比变化后的布局重排、双屏状态下的变化这些在普通手机上根本复现不了必须单独建用例库。2. 移动应用测试用例设计不要背方法论而是过好三关很多测试培训教材喜欢把等价类、边界值、判定表、场景法、正交试验设计列成八股文仿佛只要背熟了这些方法用例就一定会写得全面。实际工作中我很少说“我现在要用边界值分析法来写用例”而是把设计过程拆成三个环节每个环节对应一类需要回答的问题。2.1 第一关先把用户角色和真实使用场景拆出来用例设计的素材库不是需求文档而是用户角色和场景清单。需求文档只是把功能描述出来但功能被谁用、在什么环境下用、用手碰到什么程度需求文档里往往没有体现。比如一个电商App的下单功能需求文档里写的是“用户选择商品后点击购买进入确认订单页”。但真实使用场景至少可以拆出这些角色新用户没有收货地址第一次下单需要走完整注册流程老用户有默认收货地址直接下单考虑优惠券和满减组合网络不稳定用户在地铁里下单请求超时订单状态显示为“待支付”需要确认到底支付成功没有中断用户下单过程中来了电话挂断后回到App发现页面停留在一个中间状态需要判断是继续下单还是重头再来多设备用户手机上加入购物车平板上结算收货地址需要跨设备同步角色拆完之后每种角色配合当时的网络、权限、系统状态就构成了一张场景矩阵。这比直接写“点击购买按钮验证跳转”要有效得多因为你测的不只是按钮跳转而是角色在完整上下文中能不能完成目标。这里给出一个我在实际项目中经常用的模板用于启动一个模块的用例设计列出这个功能涉及的全部用户角色包括异常角色如被封号用户、未登录用户、游客列出每个角色在这个模块里的核心任务清单列出每个任务可能发生的物理环境网络状态、时间状态、设备状态对每个任务和环境组合写下可能失败的路径这就是用例的种子清单2.2 第二关针对每个逻辑单元用“三件套”提问法把分支补全拆完场景之后每个场景会落到具体的逻辑单元上比如“提交订单”这个单元、或“输入金额”这个单元。我在设计用例时会对每个逻辑单元问三个问题把大多数容易遗漏的分支捋出来。第一个问题边界在哪。涉及数字输入的场景0、负数、最大上限、超过上限一位、带小数、带千分位分隔符、超长字符串这些是等价类和边界值的实际应用。其他场景也有边界列表翻到最后一页、文本输入达到字数上限、图片上传达到数量上限。边界问题不是数学题而是用户在真实操作时最容易触碰到的临界点。第二个问题状态变了会怎样。一个操作发生时前后的系统状态、页面状态、数据状态都有变化。比如直播推流中切换前后台推流是否暂停录音过程中插入耳机音频源是否切换扫码页面在光线变暗时扫码框是否能正常识别。状态变化是移动应用特有深度也是最容易出bug的地方。第三个问题异常路径怎么走。正常路径是用户按设计者的意图操作异常路径是用户绕开设计者的意图操作。模拟支付时切换网络、上传文件时杀掉App、填写表单时点击返回键这些异常路径在用例里的价值往往比正常路径高得多。因为正常路径开发一定测过异常路径开发大概率没测过。这三个问题问完之后分支基本就覆盖得七七八八了。我见过一些测试新人拿着需求文档逐条翻译用例写出的用例全是正常路径原因就是没做这一步补全。2.3 第三关优先级排序不是拍脑袋是基于风险用例数量一多优先级排序就成了关键问题。主流程用例、异常场景用例、边界用例、兼容性用例、性能用例一个模块全部写满可能有上百条但测试时间和资源永远是有限的。我的排序逻辑很简单先问“这个功能挂了会怎样”再问“这个功能用户多久用一次”最后问“这个功能挂了之后有没有自动恢复机制”。核心链路比如登录、支付、交易、消息收发这些挂了会直接影响核心业务优先级P0高频场景比如首页加载、搜索、商品详情用户每次打开App都会触达挂了用户立刻感知优先级P0或P1破坏性场景比如数据覆盖、重复提交、资源耗尽一旦发生会造成严重后果优先级P1低频边界比如深链接跳转、极老版本兼容、极少用的语言包切换优先级P2甚至P3有一次我接手一个已经上线的项目测试资源只够覆盖P0和P1用例。我宁愿把P0用例里的每个分支都跑透执行到可重复验证的程度也不去把P2的一百条用例快速划拉一遍。因为用例的价值不在于数量而在于当你跑完全部P0用例时你对核心质量是有把握的——这种把握感在发版排期会议上非常有用。3. 移动应用测试用例里最容易出问题的四类细节对照你的用例库检查一下我在评审用例和面试测试候选人时发现了很多共性问题。这些问题不涉及高深的方法论全是落地时最容易犯的错。如果你现在打开自己项目的用例库大概率能在里面找到同类问题。3.1 前置条件写成了“已打开App”等于什么都没写移动应用的前置条件里藏着大量对执行结果有决定性影响的因子。举一个真实例子后台被杀Android系统为了省电把App进程清理掉了。用户重新打开App你期望看到的“上次浏览记录保留”可能根本不存在。前置条件里不写“App在后台运行且进程未被系统回收”执行人根本不知道当前App处于哪个状态。账号状态未登录、已登录但token过期、已登录但被踢下线、多设备同时在线这些账号态直接影响用例结果。数据状态本地有没有缓存、服务端有没有测试数据、购买历史是否存在都会改变用例的行为路径。正确的写法是把前置条件细化到“能复现”的程度。我之前在一个用例评审会上看到一条用例的前置条件是“用户已登录”但开发说“你说的已登录是哪种登录是当前进程登录还是之前登录过恢复的会话状态这两条代码路径完全不同”。这句话让我印象很深从那以后我要求团队里所有用例的前置条件必须包含设备状态、账号状态、数据状态三个要素缺一个就打回重写。3.2 步骤粒度忽粗忽细导致用例无法复现步骤粒度的问题是移动测试用例的常见病。有些用例写“输入正确用户名密码登录”但没说输入的用户名是什么、密码是什么、通过什么方式输入有些用例写“点击页面上的按钮”但没说按钮的名称和位置。好的移动应用用例步骤应该是明确操作对象哪个页面、哪个控件、控件标识明确操作内容输入的具体值、点击的按钮名称明确操作方式点击、长按、滑动、双击、旋转比如一条权限引导用例光“点击弹窗上的允许按钮”就不够要写明是首次弹窗还是二次弹窗按钮文案是“始终允许”还是“仅在使用期间”因为这两个选项对应的代码路径完全不一样。3.3 预期结果没有可判定性执行人无法判断对错“页面正常显示”这句话在用例里出现的频率极高但你让两个测试工程师去执行同一条这样的用例他们大概率会得出不同的结论。“正常”到底是什么标准是页面出现了就算正常还是内容加载完整了才算正常可判定的预期结果是用数据说话的。比如“发送后3秒内出现成功提示”“列表底部显示‘加载完成’不再出现加载动画”“点击后2秒内页面跳转目标页标题为‘订单详情’”“存储空间不足时App弹出引导清理的提示不会崩溃”写预期结果时我会追问自己一个问题如果我在这条用例执行后写“通过”或“失败”我的依据是什么依据越具体用例的可执行性越强。3.4 缺少数据依赖和清场恢复步骤移动应用测试里数据污染是经常发生的事情。一条“领取优惠券”的用例执行完之后账号的优惠券状态变了如果不清场后续任何依赖优惠券状态的用例都会受影响。但绝大多数用例库里的用例都没有清场步骤。我的做法是在每条用例里单独加两行测试数据准备比如“使用账号x账号内预置优惠券至少2张有效期未过期”清场动作比如“执行完成后将账号x优惠券状态恢复到未使用或改用新账号避免影响后续用例”数据依赖写清楚之后用例才谈得上独立可执行。否则一条用例的执行结果会受前面几十条用例执行顺序的影响出了问题你根本分不清是功能缺陷还是数据污染导致的。4. 用例真正被“用”起来从评审、执行到回归的完整动作链写完用例只是第一步。在真实研发节奏里用例能不能发挥作用要看它在评审、执行、追踪、回归这些环节里有没有被真正当成工具来用。我见过很多团队把用例写完就归档测试执行时直接点开App凭感觉测完全背离了写用例的初衷。4.1 用例评审不是过文字而是对齐三方认知用例评审是最常被敷衍的程序。很多团队的评审会就是测试读一遍用例开发问一句“这条没问题吧”产品打个哈欠说“差不多了”就散会了。但用例评审真正要解决的问题是在用例描述这个层面把三方认知中的偏差暴露出来。我在评审会上的固定习惯是先问三个问题需求理解是否一致这条用例涉及的流程和产品理解有没有偏差。比如支付用例里支付失败后的退款形式是原路退回还是余额退回产品说“需要确认”开发说“目前没有实现”测试说“我按提示来”——这种细节在评审会上一对齐常常能避免上线后的客诉。边界条件是否遗漏开发在写代码时会处理很多隐藏边界而这些边界往往没有写进需求文档。评审时让开发看一遍用例分支能把他脑内的边界条件挖掘出来补进用例库。维护责任是否明确这个模块以后谁负责改、用例库的owner是谁、需求变更时谁来同步更新用例。没有明确owner的用例库两周之后就会和代码脱节。评审会开得扎实比多写十条用例有用得多。用例评审的价值不在于“检查用例写得对不对”而在于用用例作为媒介让产品、开发、测试三个人对同一个问题的理解达到一致。4.2 冒烟测试把用例库变成准入准出的执行清单冒烟测试的用例选择有规律可循。不是把所有P0用例拿出来跑一遍就叫冒烟而是要按“核心链路本次变更涉及范围”两个维度来选。我所在的团队每一个版本迭代都会维护一张冒烟用例清单大概20到40条用例。这批用例覆盖的是App从启动到完成一次核心业务闭环的链路比如登录已验证账号能够正常登录token过期后能自动换取新token首页首页能加载核心入口能进入网络错误时有兜底提示使用权限的典型功能比如拍照上传、定位、消息推送验证基本功能可用本次版本修改过的核心模块开发提测时会说明影响范围从用例库中勾出相关用例进入冒烟清单每次发版前后先跑冒烟用例冒烟不过就直接打回开发。这个动作看起来简单但能挡住绝大多数低级问题。我之前在一个App release分支上本地验证没问题打包出来后首页直接白屏。冒烟用例第一条“启动App首页正常加载”就跑挂了省去了在整个测试流程后半段才发现这个问题的来回折腾。4.3 执行中的用例追踪用状态字段驱动测试进度用例执行不是“勾对勾”而是在管理风险。我习惯把用例执行状态拆成五类未执行还没跑到通过步骤执行完结果符合预期失败步骤执行有异常结果和预期不符阻塞存在前置条件不满足无法继续执行跳过该用例在本版本不适用但必须有明确理由执行过程中每失败一条用例都要立即和缺陷管理系统关联。直接在缺陷系统里创建缺陷缺陷描述里写明复现步骤、实际结果、预期结果、设备信息、版本号并关联回原用例ID。这样做的意义在于缺陷表象是“功能不正常”而用例ID能告诉开发这是哪个测试逻辑单元出了问题定位效率会高很多。追踪阶段还有一个被低估的动作执行完用例库之后统计一下P0用例的通过率再统计一下所有失败用例对应的模块分布。通过率不是用来给团队打分的而是用来判断质量风险的如果核心模块的P0用例通过率低于100%就不应该提“功能测试完成”因为你还没验证完核心逻辑。4.4 回归测试从用例库中挑回归集不是把全部用例跑一遍迭代多了之后把整个用例库跑一遍的时间和成本都是不可接受的。合理做法是基于变更影响分析来挑选回归集。具体操作步骤可以这样走拿到本版本的代码变更清单包括改动的模块、对应的需求ID从用例库中筛选出这些模块关联的全部用例再筛选出与这些模块有数据交互的关联模块用例比如改了订单状态流转那么所有依赖订单状态显示的页面用例都要回归加上全App的冒烟用例和我们定义的核心链路用例合并去重后就是本次回归用例集这里特别提醒一点回归集里一定要保留一条历史版本中曾出现严重缺陷的用例。如果模块A在上个版本出过一次数据丢失的严重bug这个版本的回归集里就应该永远保留这条用例。这类用例的回归价值很高因为代码改动迭代时最容易被改回去的就是此类遗留问题。5. 迭代一多用例就烂复杂需求下的用例维护、复用和管理用例库最大的敌人不是写不出来而是写完就没人管。产品迭代六个月以后需求改了三轮页面重构了一次用例库里还躺着十年前的老用例。你说它没用吧它和现在的逻辑对不上你说它有用吧跑起来全是预期结果和实际不符。这种情况在每个项目组都会出现难点在于不同项目组的迭代节奏不同需求复杂程度不同用例库怎么维护才不算过度管理又能保证用例随时可用。我实践下来比较有效的方案是把用例库分成三层。5.1 用例库分层常青层、版本层、临时层常青层是全版本通用、不随业务规则变化而失效的用例。比如启动流程、权限基础、界面基础交互、页面跳转逻辑、埋点上报等。这些用例只要产品形态不变就一直保留任何一次迭代的冒烟测试都从这里取用例。常青层用例的数量要控制每条都是精挑细选的稳定用例不能频繁改。版本层是本迭代特有功能的用例。比如本次迭代上线了“基于地理位置的附近的人”功能相关用例全部放在版本层版本结束后这层用例并不删除但状态会标记为“已归档”。归档不意味着作废而是不参与常规回归集只有当相关模块调整时才启用。临时层是一些过渡性用例。比如灰度发布期间的开关验证、线上问题排查时临时设计的复现用例、性能压测时构造的边界场景。临时层里的用例要设置有效期比如30天后自动标记为待清理由用例owner确认是否转正到常青层或版本层。这套三层机制解决的核心问题是职责边界常青层保证每条用例长期维护版本层真正确认功能临时层临时救火不会互相干扰。用例库的维护成本因此大幅下降。5.2 用例命名规范和目录结构让复用成为可能一个用例库如果命名混乱复用时找一条用例的时间比重新写一条还长那用例库就会被弃用。命名不规范这个问题在不同项目组之间协调时会被放大到极致——测试同学从A项目组调到B项目组B项目组的用例他根本找不到。我的用例命名规范长这样模块前缀比如订单、支付、消息业务场景比如“支付超时”、“优惠券核销”具体验证点比如“重复点击提交按钮只创建一个订单”设备或系统标注比如“Android 14”、“iOS17”合起来就是“订单_支付超时_重复点击提交按钮只创建一个订单_iOS17”。这样的命名在执行时可以批量筛选也很方便关联到自动化脚本。你的用例管理工具如果支持标签还可以给用例打上“回归集”、“冒烟集”、“自动化覆盖”等标签执行时按标签筛选比一层层点目录高效得多。5.3 用例与自动化脚本的对应关系手动用例是脚本的蓝图复杂迭代里自动化测试的比例越来越高但如果手动用例库和自动化脚本脱节就会出现两种产物互相对不上的局面。我建议在用例库里增加一个自定义字段专门标记“是否由自动化脚本覆盖”以及“脚本文件位置”。这套对应关系有三个实际用途优先自动化高价值用例常青层里的P0、P1用例逐条评估是否可以自动化。登录用例、权限弹窗用例、页面跳转用例的自动化价值都很高。手动执行只跑自动化无法覆盖的内容自动化脚本跑不了的临时性场景、需要人工判断视觉效果的场景、需要真机特殊动作用的场景这些用例标记为“仅手动”执行时集中处理。切换回归策略时自动生成清单当回归集确定后自动化覆盖的那批用例直接交给脚本去跑人工只跑未覆盖的测试时间的分配一目了然。这里有一个容易踩的坑有些团队把所有手动用例一股脑转自动化结果脚本维护成本超过了手动执行成本。我的经验是移动应用端优先自动化的对象是那些“重复执行多、输入数据固定、界面状态可控”的用例比如登录、注册、基础信息编辑、列表翻页。涉及复杂图片比对、音视频质量判断、真机传感器状态的用例人工执行的性价比更高硬自动化只是自找麻烦。5.4 定期做“用例体检”删掉烂用例不算损失用例库的“腐烂”速度超出很多人的想象。我见过一条核心业务用例的预期结果里还写着旧版UI的文案需求改版三个月了都没人更新。用例里的信息一旦和当前版本脱节这条用例在执行时就会产生误导——执行人按照旧的预期结果判断看完发现不对还要自己猜测是开发改坏了还是用例没更新时间成本极高。每隔一到两个迭代需要专门抽时间做一次用例体检。体检的标准有三条有效性这条用例对应的功能逻辑在当前版本还存在吗预期结果还准确吗唯一性用例库里是否存在覆盖同一逻辑单元的重复用例是否需要合并优先级这条用例在实际回归中暴露过问题吗如果没有优先级是否过高体检后该删的删该合并的合并该降级的降级。有人担心删用例会丢失历史经验我自己的做法是把删除的用例先放到一个“作废归档”区同时标注作废原因。一两周之后确认不需要再彻底清理。这样既保证了库里的用例是新的又不会因为误删丢了历史线索。6. AI在测试用例上的实践生成可以但使用要带脑子现在的测试圈子里AI生成测试用例的话题热度很高。有不少自动化测试工具已经支持输入需求描述直接生成一份完整的测试用例文档。我在实际工作中也尝试了不少AI辅助写用例的方式体验是AI确实能帮忙提效但如果你不带脑子地用它会给你一大堆模板化的、看起来正确但实际没用的用例。6.1 AI生成用例的能力边界哪些场景值得用AI生成用例比较擅长的场景有明确的特点逻辑简单、规则清晰、输入输出可枚举。举几个我实际验证过有效果的场景表单验证输入框的必填、长度限制、格式校验、特殊字符处理AI生成的边界测试用例质量相当高因为这类规则在历史用例库里样本量很大模型很容易学。接口参数校验请求参数为空、参数类型错误、参数超长、枚举值不合法这类接口层用例用AI批量生成效率极高。操作权限不同角色访问不同功能的预期结果按角色和功能模块做笛卡尔积生成用例AI一分钟能生成几百条人手写可能要大半天。已有用例规范化重写我经常把一批格式混乱的旧用例喂给AI让它按照统一模板重写效果很稳定。但这几个场景有个共同前提业务规则要清楚。AI本质上是在做“基于人类历史经验的模式补全”如果业务规则本身模糊AI只能猜。猜的结果就是生成一些看起来合理的步骤但根本不符合当前App的实际交互逻辑。6.2 我实际在用的AI辅助写用例工作流这里分享一套我自己用得比较顺手的流程整体思路是把AI当作“初稿生成器分支补全器”而不是“最终决策器”。第一步先把需求文档或接口文档整理成结构化摘要喂给AI。摘要里必须包含完整的需求背景、用户角色、核心流程、边界条件。如果你直接扔一整份需求文档进去AI的输出会充斥着无关内容干扰你用归纳逻辑梳理用例。第二步让AI基于摘要生成用例初稿。在提示词里明确要求按“前置条件-步骤-预期结果”的格式输出并且要求区分P0、P1、P2优先级。AI生成的用例标题通常会比较长但我们可以优化。第三步逐条复核AI生成的用例。这不是泛泛检查而是对照真实App的页面和交互确认每一步在现在的版本里真的存在。AI很擅长生成用户根本不用的路径比如它可能生成一条“点击分享到微信-选择朋友圈-确认分享”的用例但实际App里这个按钮的位置和文案已经变了AI根本不知道。第四步把通过的用例导入用例库同时让AI补充边界分支。这里有个技巧让AI针对每条核心用例再生成“如果用户在步骤2执行了一半就切后台”或“如果网络在步骤3请求时断开”这类的变体。AI生成中断、异常、恢复这些变体用例的能力很强因为它见过的失败模式样本太多了。6.3 用AI时的几个坑我踩过的都说给你听AI生成用例目前最大的问题是会“一本正经地胡说八道”。AI会根据语言的惯性生成很多步骤但生成的内容是否和当前版本一致完全取决于你喂给它的信息准不准时。我踩过的一个坑是让AI基于旧的接口文档生成支付流程用例但它不知道接口文档里已经没有了“余额支付”这个支付方式结果生成了一堆不存在的选项用例浪费了评审时间。第二个坑是AI生成的用例容易忽略移动端的特有场景。你让它写“登录”的用例它会把用户名密码登录、验证码登录、第三方登录全部列全但不会主动给你补网络切换、前后台切换、权限拒绝这些场景。移动应用测试必须由人来补充这部分AI只能做加法补全做不了减法识别。第三个坑是把AI的生成结果视为事实。在用例管理工具里我要求所有AI生成的用例必须标记“AI草案”状态只有通过人工评审后才能真正参与执行。这个标记看起来麻烦但能有效防止AI生成内容混入正式用例库影响历史统计。有一次我们不慎混入了一批未评审的AI用例新增功能的回归出现了大量“预期结果与当前版本不符”的结论实际都是用例本身过时了白白折腾了一轮排查。6.4 AI是助手不是对手一起工作的方式目前我和AI配合的效率确实是写纯手工用例的两到三倍以下。原因很简单AI负责做枯燥的枚举和格式规范化工作我负责做决策。用例设计的核心是人对业务的理解对用户场景的把握对风险的判断这些是AI短期无法替代的。如果你团队里也有AI测试用例生成的工具接入我建议从一个最小的模块开始试点。选一个业务逻辑稳定、需求文档齐全的模块用上述工作流跑一轮量化对比手工编写和AI辅助编写的用例数量、评审返工率、上线缺陷率拿到真实数据后再决定是否推广。这个试点过程本身就是一次很好的测试方法培训。