企业官网建设流程全解析

先说一个我真实的评审经历。有一次同事提交了一条用例，标题叫“修改密码”，前置条件栏是空的，操作步骤写着“按正常流程修改密码”，预期结果写着“修改成功”。我当时盯着这条用例看了三遍，最后也不知道执行完它能证明什么——是用新密码能登录？旧密码失效？还是修改过程中短信验证码校验过没过？全都不清楚。

这种用例不是个例，在很多团队里，测试用例的数量一直在涨，但质量并没有跟着涨。大家嘴上说测试用例是测试工作的核心资产，实际写起来却像是在应付差事。这篇内容我打算把测试用例编写规范这件事彻底讲透：从一条用例的基本结构，到设计方法怎么选，到用例库怎么组织、怎么复用、怎么评审，再到用例如何为自动化测试铺路，每一层我都会结合自己踩过的坑来讲。

适合谁看？刚入行的测试新人、带团队的测试负责人、以及那些觉得自己用例“写了但好像没什么用”的同学，都能从中找到可以马上落地的建议。

1. 用例没有规范的团队，都在靠“人肉记忆”硬撑

我先抛一个观点：测试用例如果只是写给自己看，那怎么写都无所谓。但用例的绝大部分价值在于“别人能看懂、别人能执行、别人能判断结果”，在于回归、交接、自动化、审计、甚至培训时反复使用。一旦脱离了个人记忆，用例就必须有规范。没有规范的用例库，本质上是一堆只有作者本人能解释的半成品。

我在一些项目里见过特别典型的情况：同一个功能，三个测试工程师各写了一套用例，步骤和预期结果完全对不上；迭代三个月后，用例库里躺着一百多条“看起来还能用”的用例，但没人说得清哪些还在验证当前版本的行为；新人接手项目，看用例库像看天书，只能追着老员工一个个问。

这些问题的根源，不是大家不努力，而是缺少一套统一的编写约定。所以规范的核心目的，就是把用例从“个人笔记”变成“团队资产”。要实现这个转变，首先得从一条用例的内部结构下手。

1.1 先看反例：一条“能跑但没用”的用例长什么样

我们把刚才那条“修改密码”的用例展开来看。假设它是这么写的：

• 用例标题：修改密码
• 前置条件：无
• 操作步骤：进入个人信息页，点击修改密码，输入新密码，点击确认
• 预期结果：修改成功

这条用例能不能执行？能。但执行完能得到什么结论？很难说。因为“修改成功”这个预期结果没有给出可判定的依据，执行的人根本不知道应该观察什么。更关键的是，这里缺了好几个信息：修改密码前需不需要验证旧密码？需不需要短信验证码？新密码有没有复杂度要求？修改之后原登录态会不会失效？这些问题不写清楚，用例执行时全靠执行人临场发挥。

再举一个登录功能的例子。很多用例会这样写：“输入正确的用户名和密码，点击登录，预期结果：登录成功。”这句话看上去没错，但严格来说它无法指导执行。什么叫“正确的用户名”？是任意一个已注册的用户，还是指定测试环境里某个固定用户？“登录成功”的判定是什么——是URL变了、页面出现了用户名、还是接口返回了特定状态码？如果不定义清楚，执行人很可能走到“这环境里没有这个用户”就卡住了。

1.2 用例的原子结构应该怎么写

一条合格的测试用例，至少要包含下面这些字段，缺任何一个都会在实际使用中带来问题：

前置条件是最容易被敷衍的部分，但它恰恰决定了用例能不能复现。我的习惯是，前置条件里必须写清楚“数据从哪来”和“系统处于什么状态”。比如验证登录，前置条件可以这样写：

• 已注册一个状态正常的用户，用户名：test_user_001，密码：Test@123456
• 该用户无锁定、无禁用标记
• 浏览器使用无痕模式，确保没有残留登录态

操作步骤也必须具体到“别人拿着就能执行”的程度。有些同学喜欢写“输入任意合法手机号”，这等于把决策权甩给了执行人。正确做法是写死测试数据，或者明确数据生成规则——“输入一个长度为11、以1开头、未经注册的手机号”。

预期结果的写法，是区分测试工程师水平的关键之一。我建议按三层来描述，至少覆盖一层：

• 界面层：页面跳转到哪个URL、弹窗文案是什么、按钮置灰还是可点
• 接口层：哪个接口被调用，返回code是多少，响应体的关键字段是什么
• 数据层：数据库表里对应记录的值是否变化，缓存是否更新

拿登录来说，完整的预期结果可以是：

• 界面层：3秒内跳转到系统首页，右上角显示用户昵称
• 接口层：调用login接口，返回code=0，token字段非空
• 数据层：用户状态表last_login_time更新为当前时间

这样一条用例，任何人执行完都能明确回答“过还是没过”。而能够稳定回答“过还是没过”，正是用例规范的底层价值。

2. 从需求到场景：用例设计不是枚举，是风险建模

说完了单条用例的写法，再往上一层看：那么多条用例是怎么设计出来的？很多测试新手容易陷入一个误区，就是把所有可能的输入都试一遍，试图用数量堆出质量。这是典型的“用例枚举病”。真正的用例设计，本质上是对需求做风险建模——把需求分成主流程、分支、异常、边界，找出最可能出问题的点，用最小代价覆盖它们。

具体到设计方法，我们常用的无非是等价类、边界值、场景法、判定表、正交实验这几种。关键不是背名词，而是知道每种方法解决什么问题、在什么场景用最划算。

2.1 等价类与边界值：最便宜的方法最先做

等价类划分的核心思路，是把无穷输入集划分成有限类别，同一类别里的不同输入在系统看来是等价的。边界值则是等价类的补充——很多缺陷恰恰发生在输入范围的边缘。

举一个最常见的例子：一个订单金额输入框，业务规则是“金额需在1到10000元之间，保留两位小数”。

用等价类划分，我们可以得到：

• 有效等价类：1 <= 金额 <= 10000，例如 100.50
• 无效等价类一：金额小于1，例如 0.99
• 无效等价类二：金额大于10000，例如 10000.01
• 无效等价类三：非数字输入，例如 abc
• 无效等价类四：小数位数超过两位，例如 100.001

边界值则在有效等价类边缘附近取值：0.99、1.00、1.01、9999.99、10000.00、10000.01。这样一组用例下来，覆盖密度比随机输入要高得多。

我自己的经验是，先在需求评审阶段把等价类和边界值用例草拟出来，通常不到两个小时就能出一版。这个动作能快速暴露需求里那些“约等于”“左右”“大概”之类的模糊描述，比如“金额不超过一万”到底是小于等于一万还是小于一万，当场就能逼产品经理说清楚。

2.2 场景法：把用户当“笨人”来设计

单元化的输入验证只能证明“每个点没问题”，但很多严重缺陷只有在完整业务链路里才会暴露。场景法就是从用户真实使用角度，把多个功能点串成完整的业务流来设计用例。

举个例子，一个电商购买流程，主路径场景可以是：

• 用户登录，搜索商品，加入购物车
• 进入结算页，填写收货地址，选择支付方式
• 提交订单，支付成功，订单状态变为已支付

但光有主路径远远不够。真实用户绝不会按你预设的路走，他们会中途关闭页面、重复点击提交、切换网络、修改地址后又返回。所以场景法还要覆盖分支场景和异常场景：

• 支付中途取消，订单状态是否保持待支付
• 支付成功后网络断掉，前端是否提示“支付结果确认中”
• 重复点击提交订单按钮，是否产生重复订单
• 支付回调延迟，订单状态是否在轮询后自动更新

场景法的核心，是把每个真实用户会走的路径都当作“一张图”，每张图对应一套用例。我在写用例时习惯先画出主路径图（当然不用画工具图，脑图即可），再逐条标注分支和异常。这样既能保证不遗漏，也能在评审时直接对着业务流说明覆盖情况，沟通效率很高。

2.3 组合类方法：条件不独立时，判定表和正交实验才有意义

当输入条件之间存在组合关系时，比如多个开关、多个状态叠加，简单的等价类覆盖是在赌运气，这时候要用判定表或正交实验。

判定表的思路是结构化地列出所有条件的组合以及对应的动作。假设一个优惠券发放规则：用户是新客（A）、订单金额超过100元（B）、使用指定支付方式（C），三个条件都满足时发放满减券。判定表会把A、B、C的8种真假组合全部列出来，逐条核对发券逻辑。这样设计出来的用例，不会因为漏看某个条件组合导致线上优惠券被薅。

正交实验则是多因子多水平时的简化方案。当因子太多，全量组合数量爆炸时，用正交表选出一组有代表性的组合，用较少用例覆盖主要因子效应。这个方法适合兼容性测试、配置矩阵测试这类场景。不过我要提醒一句，正交实验适合“因子间交互影响不大”的场景，如果条件之间牵一发动全身，还是老老实实用判定表。

优先级划分这块，不少团队是凭感觉定的，结果就是所有用例都是P2，回归时全跑一遍又跑不完。我建议按风险和业务价值量化，至少给出下面这套标准：

P0用例一定不要多。如果P0用例超过二三十条，说明你的P0定义有问题——精挑细选出来的核心流程，每条都要能回答“这条挂了，系统还配发版吗”这个问题。

3. 用例库的分层与复用：迭代多了，用例不是越多越好

用例写多了以后，团队会遇到一个比“不会写”更麻烦的问题：用例库越来越庞大，维护成本和执行成本同时上涨，老用例没人敢动，新用例不断堆叠，最后整个用例库变成“食之无味、弃之可惜”的鸡肋。

我见过最夸张的一个项目，经过三年迭代后用例库里有三千多条用例，但一次迭代回归根本跑不完，也没人知道哪些用例已经和现在的需求脱节。要解决这个问题，不能靠某个人的责任心，必须从用例库的组织结构入手。

3.1 用例库的分层结构决定了回归效率

我推荐的做法是把用例分成几个明确的层级，而不是全部放在一个平面上：

• L1 - 冒烟用例：每个迭代的核心主流程，大概10~30条，执行时间控制在半小时以内，用于环境验证和快速反馈。
• L2 - 功能细测用例：覆盖每个功能模块的完整用例集，包含主流程、主要分支、主要异常，用于版本验收。
• L3 - 专项用例：异常、安全、性能、兼容性、边界探索类用例，不随每次回归全量执行，而是按专项计划轮询执行。
• R - 回归基准用例：从L1和L2中挑选出的、验证历史核心能力的用例集合，每个迭代回归时执行。

这个分层的好处是，当发布压力来临时，你可以快速选择“跑哪些用例”而不是“所有用例都跑”。我在多个项目里实践后，回归时间通常能从两三天压缩到半天到一天。

优先级和层级是两个维度的东西，但要保持一致。我习惯用标签来管理，例如给用例打上@smoke、@regression、@p0这样的标记，方便在测试管理工具或代码仓库里直接筛选。用例的编号里也可以体现层级，比如CORE-L1-001、ORDER-L2-023，一眼就能看出用途。

3.2 复杂迭代中的用例维护机制

很多团队的用例维护是被动式的——需求变了、测试发现用例挂了，才想起来改。这种模式在高速迭代的团队里根本扛不住，因为需求变更的速度远快于用例更新的速度，一个月下来用例库就面目全非了。

我的经验是，把用例维护当成迭代的固定环节来管理，而不是“有空再做”的杂活。具体做法有三条：

第一，关联需求，双向追溯。每条用例必须关联需求编号或用户故事，需求变更通知发出后，系统里自动找出所有关联用例，由用例负责人逐一确认是否需要更新。这个动作必须在需求收敛后一周内完成。

第二，定期体检存量用例。每个迭代末尾，用例负责人要过一遍与本次变更相关的旧用例：还能用的保留，语义模糊的重写，覆盖已失效功能的直接废弃。与其维护一百条模糊用例，不如维护三十条精准用例。

第三，结构化数据生成。用例里的测试数据不要散落在步骤里，而要用参数化方式管理。比如登录用例的数据统一放在test_data/login_data.json里，用例步骤只写“使用账号A登录”，具体账号密码由数据文件控制。这样环境变化时，只需要更新数据文件，不需要改几十条用例。

还有一个很容易被忽略的问题：用例执行时“挂掉”了，并不代表产品有Bug，也可能是用例过时了。每次用例执行失败，必须做一个根因归类——是代码缺陷、环境问题、数据污染，还是用例本身过时。这四类原因的处理方式完全不同。如果团队能坚持把这个分类统计做三个月，你就能清楚地看到，用例库到底是变得越来越准确还是越来越失真。

3.3 跨项目复用的边界在哪里

复用是件好事，但“什么都想复用”会走向另一个极端。我见过有人把项目A的完整用例库复制到项目B，只改了系统名称，结果执行时大量用例因为业务规则不同而失败，最后反而没有人信任这份用例了。

跨项目复用真正靠谱的边界，是“能力相同、规则相同”的部分。典型的例子包括：

• 统一的账号体系：登录、注销、密码找回、多端登录互踢
• 通用的权限模型：角色管理、用户授权、越权访问
• 标准化的上传下载能力：文件类型校验、大小限制、并发上传

这些模块在不同项目里规则高度一致，适合抽成“公共用例集”，由平台或公共组统一维护。而业务规则差异大的部分，比如订单状态流转、审批流配置、计费规则，必须由项目各自编写，最多复用用例模板，不能复用具体用例内容。

还需要留意用例的“环境依赖”。公共用例集最好设计成与具体环境解耦，比如测试数据用参数占位，执行时由脚本注入环境变量。否则一旦跨项目、跨环境使用，前置条件里的IP、账号密码全都失效，复用就成了一句空话。

4. 用例评审与入库：质量门禁比“人人都写”更重要

很多团队把用例评审做成流水账：产品经理、开发、测试大家坐在会议室，用例作者照着文档一条条念，念到一半所有人都走神了。评审变成了“过场”，质量门禁就是形同虚设。

我的观点是，用例评审不是流程负担，而是最便宜的Bug发现手段。在用例评审阶段发现需求歧义，修改成本是一个沟通成本；等开发完了再发现，是返工成本；等上线后被用户发现，那就是事故成本。所以用例评审值得认真做，关键是找到正确的切入角度。

4.1 评审的发起时机和人员配置

不是所有用例都需要全员评审。我给团队定的规则是：

• 新增功能用例：需要产品经理、开发、用例作者三方评审，重点澄清需求歧义
• 大版本的回归用例集筛选：测试负责人、资深测试评审，重点保证覆盖无遗漏
• 单点修改的用例更新：用例作者自审 + 测试负责人抽查即可

评审时最好用“基于需求的提问式评审”而不是“逐条念稿式评审”。每个用例过完，评审者要问自己：这条用例的执行结果能证明需求中的哪一条验收标准？如果回答不上来，说明这条用例与需求脱节，要么删掉要么重写。

我建议评审前先让用例作者填写一张简单的自查表，内容包括：预期结果是否可判定，前置条件是否可复现，是否覆盖了主路径、分支、异常三层场景，P0用例是否标记清楚。评审就围绕这张表展开，能把平均时间压缩到原来的一半。

4.2 评审时重点检查的七个问题

这几年我在评审中积累了七条必查项，基本能筛掉八成不合格用例：

1. 前置条件是否可复现：依赖的数据和环境是否明确，别人拿起来就能执行吗？
2. 操作步骤是否只有单一动作：如果一步里有“输入账号、选择城市、点击搜索”三个动作，失败时你无法定位是哪一步出了问题。
3. 预期结果是否包含可观测断言：不要写“页面正常”，要写“出现提示文案X，请求返回code=0，列表展示N条数据”。
4. 是否有逆向用例：除了验证“该做的做了”，是否验证了“不该做的做不了”，比如无权限访问、非法参数、重复提交。
5. 数据是否会被历史数据污染：用例依赖的数据，在重复执行多次后还能不能保持初始状态。
6. 是否清理测试现场：用例执行后是否离开脏数据，比如创建的订单、注册的账号是否需要清理。
7. 是否与已有用例重复：如果新增用例和旧用例验证的是同一个规则，应该合并而不是再开一条。

其中第七点特别值得强调。很多用例库的膨胀，就是不断有人重复添加功能相同的用例，只是换了测试数据或页面文案。评审时要主动去重，能从源头保持用例库的整洁。

4.3 用数据度量用例质量

质量不能只靠感觉，要建立几个可以统计的指标，放在迭代复盘里持续关注：

• 需求覆盖率：已有关联用例的需求数除以需求总数，目标是100%，这代表需求的每一条验收标准都有对应的验证。
• 单功能用例密度：平均每个功能点对应的用例数，我个人认为健康范围是4到8条。太少说明覆盖粗，太多说明碎片化。
• 用例有效执行率：执行通过的用例数除以总执行数。如果长期低于70%，优先反思用例是否过时、环境是否稳定。
• 自动化率：P0和P1用例中已实现自动化的比例，目标根据团队资源定，但P0主干建议不低于80%。

有一次我让团队成员统计这个有效执行率，发现某个模块长期只有50%多，一查才发现在过去两个大版本里，该模块的交互已经被产品重做过两轮，但用例库只更新了20%。这个数据直接把维护积压问题暴露了出来。

5. 用例和自动化测试的咬合：好脚本的前提是“可断言的用例”

现在很多团队都在提自动化测试，从Playwright到Selenium，从UI自动化到接口自动化，工具五花八门。但大家逐渐发现一个尴尬的事实：自动化脚本写了不少，维护成本高、失败频繁，最后沦为一堆“天天飘红”的CI任务。

问题往往不在脚本本身，而在用例源头上。自动化脚本本质上是把用例翻译成代码，如果用例本身没有清晰的步骤和可断言的预期结果，脚本翻译出来也就是一堆软绵绵的检查。所以用例编写规范，直接决定了自动化测试的上限。

5.1 哪些用例适合自动化

不是所有用例都适合自动化，盲目追求100%自动化率是本末倒置。我给团队定的筛选标准很朴素：

• 执行频率高的用例优先自动化，比如每次发版都要跑的P0冒烟用例
• 步骤稳定、不依赖大量人工判断的用例优先自动化，比如接口字段校验、页面跳转
• 依赖复杂数据准备的用例，除非数据能脚本化准备，否则自动化性价比很低

这里特别提醒一个反直觉的现象：自动化跑得越多，用例维护成本越高。所以自动化的正确策略不是“把手工用例全部脚本化”，而是“精选核心用例脚本化，把手工精力留给探索性测试”。每次看到有人花两周把一个基本没人用的模块自动化了，我都替他心疼时间。

5.2 可自动化用例的编写要点

如果一条用例要被自动化，它的写法有一些额外要求。首先是操作步骤里的输入必须确定，不能写“输入任意合法手机号”，要写“输入指定手机号13800138000”，脚本才能落地。

其次，预期结果要划分出“中间态断言”和“终态断言”。比如测试一个表单提交，中间态断言是点击提交后按钮变为loading态且不可再次点击，终态断言是页面跳转后的列表中出现新记录。交互变化是UI自动化最容易漏掉也最容易稳定的断言点，一定不要只写终态结果。

第三，对页面元素的选择要写“稳定标识”。如果用例步骤里写“点击右上角的设置按钮”，脚本怎么写选择器？最佳实践是给关键元素加上>