企业官网建设流程全解析

入行做测试的头两年，我一度以为写测试用例就是把需求文档里的“正常流程”翻译成操作步骤，再补几条异常场景，凑够数量就算交差。直到有次评审会上，开发指着一条用例问我：“这条和那条，本质上是同一件事吧？”我才意识到，用例不是填表格，写不清楚用例的人，往往不是不会写，而是没想清楚自己要测什么。这篇东西不聊理论教材里那些大词，就聊聊我这些年写功能用例、接口用例、游戏用例时踩过的坑，以及一套我自己验证过比较好用的拆解思路。如果你也经常觉得“用例写了不少，上线还是漏测”，那这篇应该能帮你找到症结。

1. 用例写得对不对，先看它究竟给谁用

先说一个我观察很久的现象：很多团队把用例当成“测试执行脚本”来写，写完往用例管理平台一传，测试执行时对着步骤一步步点，点完勾选通过，到了下个版本用例就长眠在系统里没有人再打开。如果用例只是“今天执行完就扔”的临时清单，那它当然可以随便写。但问题在于，真正有价值的用例，要同时服务四种角色，而这四种角色对用例的诉求完全不一样。

1.1 用例的四种角色，决定了你不该只写操作步骤

第一是验收契约。用例是对需求的一种“可执行化复述”，开发可以用它来自测，产品可以用它来验收，测试用它来判定“做完了没有”。第二是回归基线。迭代三个月后要改一个老功能，你靠什么评估改动影响范围？靠的是历史用例能覆盖住哪些老逻辑。第三是排期依据。用例条数和复杂度可以直接换算成工作量，管理层需要靠这个判断版本节奏。第四是知识库。新人接手一个模块，最快的上手方式不是翻需求文档，而是看这个模块的用例。

想清楚这四种角色，你就明白为什么用例不能只写“点击按钮，出现弹窗”这种话。因为这种用例只能给“今天执行的这个测试员”看，三个月后的自己、新来的同事、开发的联调自测，全部没法用。我现在的习惯是在每条用例里都写清楚“前置条件”和“预期结果”，这两个字段不是为了格式完整，而是为了让用例脱离“写的人”也能成立。前置条件交代测试启动状态，预期结果交代判定标准，只有这两个都明确，用例才有契约属性。

1.2 可读性是最容易被低估的用例质量属性

你回忆一下，是不是见过这种用例：“输入手机号，点击获取验证码，输入验证码，点击登录，登录成功。”乍一看没毛病，但细想全是问题——手机号是任意手机号吗？验证码怎么拿到？登录成功后页面跳转到哪？如果登录失败，提示什么？这些字段不写清楚，执行的人要么反复追问，要么就按自己理解的随便测。而所谓“可读性好”，不是文笔好，是信息密度够。开发看完知道自己该实现到什么程度，产品看完知道验收点是什么，另一个测试不用问你也能直接执行。

一个有效的技巧是：把每一步操作拆细到“不需要动脑”的程度。比如“输入已注册手机号138xxxx5678”就比“输入手机号”好；“点击右上角‘下一步’按钮”就比“点击下一步”好。有人觉得这样写太啰嗦，但我的经验是，用例里多写的那句话，往往就是上线后少漏的那个bug。

2. 从需求到用例的拆解：我常用的三层设计路径

很多刚入行的同学拿到需求文档就急着打开Excel填用例，结果填到一半发现需求没想清楚、分支逻辑理不清，删了重写。我的习惯是分三层走，先不碰用例模板，先把需求从“一段描述”变成“一张逻辑图”。

2.1 第一层：需求分析期先问七个问题

拿到需求后先别急着写操作步骤，先逼自己回答下面七个问题，答不上来就先去找产品、开发确认，确认完再动笔：

• 需求的目标用户是谁？是C端普通用户还是B端管理员？
• 入口在哪？用户从哪个页面、通过什么操作能进入这个功能？
• 主流程是什么？用户达成目标的最短路径是哪条？
• 有哪几条分支流？比如已登录、未登录、无权限、重复提交？
• 异常场景有哪些？网络超时、服务端报错、输入非法值、数据为空，分别怎么表现？
• 数据有什么约束？必填、格式、长度、唯一性、取值范围，依据在哪里？
• 验收标准是什么？产品口里说的“成功”到底是一个页面、一个提示，还是一串数据库变更？

我见过太多用例漏测，根本原因不是设计方法不行，而是需求阶段就没把分支和异常聊透。比如一个“修改昵称”的功能，用例如果只写了“修改成功后展示新昵称”，就漏掉了“昵称含敏感词”“昵称重复”“昵称为空”“昵称带emoji”“昵称纯空格”这一大片。这七个问题过一遍，至少能把大的坑先圈出来。

2.2 第二层：站在用户视角梳理场景流

需求分析完，我会做一张简单的场景清单，把用户可能走的路径全列出来。这里强烈建议别一上来就套“等价类”“边界值”这些方法，先按正常人会怎么操作，把路径走一遍。以“下单支付”为例：

• 主流程：选商品 → 加入购物车 → 确认订单 → 提交订单 → 支付 → 支付成功 → 订单列表出现新订单
• 分支流：购物车为空直接结算？商品库存不足？下单后取消支付？
• 异常流：支付超时、支付中杀掉App、支付成功后回调延迟、余额不足、微信/支付宝取消授权

把路径列完，你对需求的理解基本就立体了。之后再开始写用例，每个分支、异常都能变成一条或多条用例，数量自然就上来了，而且不会乱。

这套思路同样是接口测试和游戏测试的底子。接口测试的场景流来自接口文档里的调用链和异常码定义，游戏测试的场景流来自玩法规则和状态机设定。底层逻辑一致：先梳理“所有可能发生的情况”，再为每个情况设计验证路径。

2.3 第三层：设计方法不是越多越好，关键是匹配场景

教科书上常提的等价类、边界值、判定表、场景法、错误推测法，我实际用下来的体会是：不同方法对应不同场景，别混着用。

等价类和边界值通常一起用，适合所有有输入域的场景。比如注册功能“密码长度为8~20位”，有效等价类是8位到20位的任意密码，无效等价类是少于8位、多于20位，边界值是8、20、7、21、空。这四个边界值一定得测，实践中很常见的bug就是边界判断写成了>而不是>=。判定表适合条件组合多且结果受组合影响的场景，比如登录模块里“记住密码”和“自动登录”两个开关，组合起来就有四种状态，用判定表能把遗漏组合的概率降到最低。场景法适合流程式业务，比如下单、审批、退款这类多步骤流程，重点覆盖每条路径的完整链路而不是单个步骤。错误推测法靠经验，不是结构化方法，但往往能命中真正的坑，比如“快速连续点击提交按钮”“断网后点提交”“手机时间调快一天再操作”这类反常规但线上真实存在的操作。

我的建议是：每个模块挑主用的1~2种设计方法就够了，剩下的靠经验补。设计方法的价值是帮你想全，不是逼你把所有方法都在一个模块里用一遍。

3. 功能、接口、游戏三类场景的用例写法差异

很多测试同学会跨业务线干活，今天测Web后台，明天测App接口，后天可能去测一把游戏活动玩法。三个领域的用例框架差不多，但关注点差异很大，混着写容易写飞。

3.1 功能测试用例：默认站在用户视角，别替用户做决定

功能用例是大多数人接触最多的类型，核心原则是“像用户那样操作”，但要比用户更“刁钻”。用户只走正常路，测试要把正常、分支、异常、容错、兼容全部走一遍。我给新人培训时常用一个骨架：正常流覆盖主流程，分支流覆盖功能内部可选项，异常流覆盖输入、状态、权限、数据四种异常，容错覆盖弱网、中断、恢复场景，兼容覆盖不同机型、系统、浏览器。

举个例子，一个“忘记密码”功能，正常流是“输入手机号 → 获取验证码 → 重设密码 → 新密码登录成功”。分支流是“验证码过期”“验证码多次错误”“新密码与旧密码相同”。异常流是“手机号未注册”“验证码输入错误”“两次新密码不一致”。容错是“获取验证码时断网”“提交新密码时杀进程”。兼容是“iOS和Android两端文案展示是否一致”。写完这套，这个功能才算是测明白了。

这里有个容易犯的毛病，就是替用户做决定。比如你先登录了再进忘记密码页，和用户直接点击“忘记密码”的实际场景完全不同，前置条件一写错，后面全白测。所以功能用例的第一步永远是确认前置条件，这条比步骤本身还重要。

3.2 接口测试用例：关注契约、鉴权、异常和幂等

接口用例和功能用例最大的区别是：功能用例关心用户的体感，接口用例关心系统的契约。接口用例的核心字段是请求方法、URL、请求头、请求体、预期响应和数据库预期变化。实际工作中我按六个维度拆接口用例：

• 参数校验：必填项缺失、类型错误、长度超限、枚举值非法、JSON格式错误
• 鉴权与权限：未带token、token过期、token伪造、普通用户调管理员接口
• 业务逻辑：正常请求返回正确结果、条件组合导致不同结果
• 异常与容错：下游服务超时、数据库连接失败、依赖接口返回异常
• 幂等性：重复提交相同请求，比如支付回调重复推送，系统不能产生两笔订单
• 并发：同一资源同时修改、库存扣减超卖、多人同时抢同一张券

举一个典型的接口用例示例：

这里最容易被忽略的是数据库预期变化。很多同学写完接口响应断言就以为结束了，结果漏了“字段值是否真的写入”“状态位是否更新正确”这类问题，这些都是线上事故的高发点。所以我的接口用例表里始终保留“DB预期”这一列，比如“订单表新增1条记录，状态为UNPAID；库存表扣减2”。

3.3 游戏测试用例：数值、状态机、随机性和体验缺一不可

游戏测试用例可能是三个类型里最难写的，因为业务系统通常讲“逻辑正确”就够了，游戏还得讲“体验正确”。以新手引导任务为例，功能用例会写“点击任务按钮，领取奖励，奖励到账”。游戏用例就得拆得更细：

• 状态与阶段：引导任务处于未开始、进行中、已完成、已领奖四个状态时，按钮表现分别是什么
• 数值验证：奖励的货币类型、数量公式是否正确；体力是+10还是+5，加完有没有刷新UI
• 异常操作：引导过程中强杀进程、断网重连、多个任务同时完成、领奖瞬间背包已满
• 随机性：掉落概率、抽卡结果是否受保底规则约束，需要大量重复次数验证或通过后台配置重现
• 性能与表现：同屏大量特效时是否卡顿、资源加载是否导致白屏

游戏里有个特性是“状态机”，比如角色的“待机/走路/跑步/攻击/死亡”状态切换，任意状态下被怪物攻击、被眩晕、被击退，都可能出现状态错乱。写用例时我会专门列一张状态转换表，把“当前状态 + 触发事件 → 预期状态”一条条列出来，比如“攻击状态下被眩晕，应迅速切换至眩晕状态而不是继续播放攻击动画”。这个思路应用在业务系统上也很值钱，订单的“待支付/已支付/已发货/已完成/已取消”状态转换就是同一个道理。

4. 测试用例模板与用例管理：让用例能复用、能追踪

写用例不难，难的是让用例“活”起来，能复用、能追踪、能积累。这方面我有几个相对固定的实践。

4.1 一套我长期在用的模板字段

模板不是越多越好，每个多余字段都会增加维护成本。我长期在用的核心字段就十个，但每个字段都有明确用途：

模板看着简单，但很多团队执行时会倒在不统一上。建议在团队内做一次模板统一，字段定下来就固定，不要一期加一个字段，否则历史用例会越来越乱，到最后根本没法复用。

4.2 用例命名的一个标准动作：模块_功能_场景_编号

“用例标题”怎么写，直接决定检索效率。我用的格式是“模块_功能_场景_编号”，比如：

• 登录_未注册账号_输入未注册手机号提示“账号不存在”
• 订单_下单_未勾选协议时点击提交_按钮置灰不可点
• 背包_领取奖励_背包已满时领取_奖励通过邮件补发

这样一个团队里无论谁搜索关键词都能快速定位，而且标题本身就能当执行结果来描述。不推荐写“登录测试1”“登录测试2”这种标题，毫无检索价值。标题写好了，用例平台里的搜索、筛选、统计才有意义。

4.3 优先级怎么定才不会被开发怼

优先级定错，回归时会被开发追着问“这条也P0吗？”。我的标准很简单：

• P0：主流程冒烟，每次发版必须全部通过，不通过直接挡版本
• P1：核心功能分支，比如支付、鉴权、推送等，回归时必须执行
• P2：非核心且影响面不大的功能，有时间就回归
• P3：体验优化类，比如文案、颜色、动效，排期空时执行

判断优先级的一个重要参考是“故障影响半径”。支付失败的半径远大于按钮颜色不对，后者即使线上有问题也有临时办法，前者一出问题就是资损。定优先级时问自己一句：这个问题线上发生，用户能绕过吗？能绕过的往低了定，绕不过的必须P0。

4.4 用例的维护节奏：需求变更、缺陷回流、定期清理

用例不是写完就一劳永逸。我按三个节奏维护用例：

第一，需求变更时同步改用例。每次需求变更评审时，测试要做的事不是只测新功能，而是回看旧用例里哪些描述已经不成立，立即更新。第二，线上缺陷回流。每次线上出现bug，第一时间问自己“为什么用例没拦住”，然后把这条bug变成一条新用例补进用例集。第三，定期清理。每个大版本结束后，检查用例有没有重复、过时、被合并的，果断删。我的经验是：一个模块的用例长期不清理，会有20%~30%的死用例，执行时浪费时间，统计覆盖率时还虚高。

5. AI辅助编写测试用例的实操经验与翻车避坑

最近AI生成测试用例这个话题很热，我也用了一段时间，说点大实话：AI确实能提效，但完全指望它替你思考，会翻车翻得很惨。它的定位是“有经验的实习生”，不是“领域专家”。

5.1 AI真正能帮你省的是哪几步

我实测下来，AI在三个场景很能打：

• 接口用例初稿生成。你把接口文档粘给它，让它列出参数校验、鉴权、异常、幂等的用例，它生成的覆盖度很完整，尤其是参数校验和边界值这块，几乎能帮你省掉一半时间。
• 组合场景的穷举。比如条件组合、状态转换、权限矩阵，你告诉它有哪些条件和状态，它能快速生成成百上千条组合，虽然会有重复和废话，但作为查漏补缺很有价值。
• 回归用例的快速“翻译”。你给它一份历史用例，让它更新标题格式、补齐前置条件、拆分过长的步骤，这种机械性工作它做得很稳。

我用AI最多的是接口用例。打开接口文档，把请求参数和响应字段丢过去，再给它一句“按参数校验、鉴权、业务逻辑、异常、幂等、并发六个维度生成用例，输出Markdown表格，包含用例标题、请求方法、路径、请求体、预期结果”，它能在几十秒内给你一张相当能看的表，我再花二十分钟剔除无效项、补充业务规则，比纯手写省半小时以上。

5.2 怎么写提问词才能拿到像样的用例

AI生成用例的质量，很大程度上取决于提问词。我给一个自己调出来的结构化模板：

请作为资深测试工程师，根据以下需求生成测试用例。 需求描述：{把需求文档核心逻辑粘进来，区分正常流程、分支流程、异常约束} 被测对象：{Web端/App端/后端接口/游戏模块} 用例粒度：{按场景拆分，每条用例不超过6个步骤} 输出格式：Markdown表格，字段含用例标题、前置条件、测试步骤、测试数据、预期结果、优先级 设计要求：先从用户视角梳理场景流，再补充输入域边界值、异常场景，最后覆盖并发和重复操作

这个模板的关键是“需求描述”要写得足够具体。你把一句话需求丢给它，它只能给你一句话用例。你把参数范围、状态流转、异常码都填进去，它才能生成能直接执行的用例。

5.3 AI生成用例后的三道质检关卡

AI生成的用例，直接拿去执行是不行的，我每条都会过三道关：

第一关，需求一致性。AI不懂业务上下文，它经常会把“普通用户A不能看B的订单”这种权限限制写成“所有用户都能查看订单”，或者把产品明文规定的“VIP等级3以上才可参与活动”漏掉。这一步的核心是把需求文档里每条硬性规定，一条条跟AI生成的用例对一遍。

第二关，可执行性。AI生成步骤时经常写“输入正确的手机号”这种正确但无法执行的句子，你需要把“正确的手机号”具体成“已注册的138xxxx5678”。这一步的验收标准是：一个没参与过这个项目的同事，能不能照着步骤跑完。如果不能，就要补细节。

第三关，预期结果可判定。AI写的预期结果经常是“页面显示正常”“数据正确”，这等于没写。“页面显示登录成功并跳转首页，首页显示用户名”才可判定。这一关是提升用例执行效率的关键。

5.4 哪些用例别指望AI

我的经验是，强业务规则耦合、强随机性、强体验判断这三类用例，AI很难写好。强业务规则比如“跨境外币支付时，不同货币类型享受不同汇率优惠”，AI没有业务背景，生成的规则很容易错。强随机性比如游戏里的掉落概率、抽卡保底，AI可以生成步骤，但没法判断概率设计是否符合预期。强体验判断比如“新手引导的弹窗出现时机是否合适，按钮位置是否顺手”，AI生成的用例往往只能覆盖“能点”，覆盖不了“好不好点”。

一句话总结我目前的工作方式：AI负责把覆盖率做大，我负责把精准度做高。AI生成初稿，我删减、补业务规则、定优先级，最后人工评审。这个组合拳下来，用例编写效率至少能提升40%，但前提是你自己得先懂怎么设计用例，否则你连AI的“病句”都看不出来。

6. 用例评审与持续维护：让用例从个人笔记变成团队资产

用例写到第六七个版本时，最难的不是写，而是让整个团队愿意用、持续用。这里分享几个落地层面的实操。

6.1 评审时别逐条念，讲场景和风险

很多团队用例评审变成“一条条念Excel”，念到一半大家走神，最后评审走过场。我的做法是：只挑P0和P1用例讲，而且按场景来讲，不按单条讲。比如“下单流程我覆盖了正常提交、库存不足、重复提交、支付超时四种场景，其中支付超时我是这么设计的……开发你看看这个场景下服务端状态是预期那样吗？”这样评审的信息密度高，开发也能快速判断逻辑是否遗漏，比念50条用例有效得多。

评审时还一定要拉上产品和开发。产品能确认验收标准对不对，开发能指出哪些场景在技术实现上根本不成立。比如你写“断网后点击下单按钮”，开发可能告诉你“断网状态前端根本不发请求，这个用例只能说明按钮置灰逻辑”，这样就能把用例从“永远不会执行的理想用例”改成“真实会发生的用例”。

6.2 线上缺陷的用例回流：我自己的一个固定仪式

我每遇到一个线上漏测的问题，都会做一个“缺陷回填”动作：把缺陷转成一条回归用例，标记为P1，关联到对应模块。这个动作看起来简单，坚持一年之后你的用例集就是一个“踩坑博物馆”，每一个线上问题的教训都被固化下来了。

我有一次负责的模块上线后，用户反馈某个返利金额算错了。排查发现是一个金额四舍五入的边界问题，当时所有功能用例都覆盖了正常金额和边界金额，但没有覆盖“金额为0.005元”这种三位小数的场景。后来我把这条补成用例：返利计算_金额为0.005元_预期按四舍五入规则展示0.01元。下次这个模块再发版，这条用例就会一直帮我看住这个坑。

6.3 用例数量健康度：不是越多越好

最后说一个反直觉的观点：用例不是越多越好。我见过一个项目，一个模块写了600条用例，但执行率只有一半，因为用例太多、重复的太多，执行的人根本跑不完，最后挑着装样子执行，覆盖率其实很低。我的建议是：模块用例数量应以覆盖风险为前提，而不是以覆盖条数为目标。定期删减重复用例，合并同一场景下不同输入但预期结果一致的用例，控制P0和P1用例在总用例数的30%以内，保证高优先级用例“小而精”。

在团队里，可以建立一个简单的用例健康度看板：各模块用例总数、P0/P1占比、最近一次版本执行率、缺陷回流新增用例数。有了这四个数，用例资产好不好，一眼就能看出来，而不是靠感觉拍脑袋。

做测试这些年，我最大的感受是：测试用例真正考验的不是“写”，而是“想”。想得够清楚，写出来只是时间问题；想不清楚，再华丽的用例模板也是空中楼阁。如果你正准备重构团队的用例体系，我建议从“先想清楚谁在看、为什么看”开始，然后再优化模板和命名。至于AI，用它做你的快手和检查员，但永远别让它替你做那个最终拍板的人。