1. 为什么测试用例是整个测试工作的“核心重点”1.1 测试用例到底是什么测试用例说白了就是针对某个功能点、某个业务规则或者某个异常场景提前设计好的一整套“输入什么数据、怎么操作、预期看到什么结果”的执行说明。它不只是一张表也不只是几个字段的堆砌而是一份把“需求语言”翻译成“可验证步骤”的标准化文档。我在刚开始接触测试那会儿也以为测试用例就是照着需求文档把功能点罗列一遍写成“输入用户名密码点击登录登录成功”这样就算完事。后来被现实教育过几次才明白真正合格的测试用例是要让任何一个没参与过这个项目的人拿着它都能一步步执行下去并且能明确判断每一步的结果是对还是错。换句话说测试用例是测试执行的地图是测试人员之间、测试人员和开发人员之间沟通的通用语言。很多人把测试用例当成“给测试人员自己看的东西”这就大错特错了。一份写得好的测试用例项目经理能拿它评估进度开发人员能拿它理解边界规则新来的同事能拿它快速上手业务甚至产品经理能拿它反向检查需求有没有漏洞。它是一个项目的活文档而不是一个交差用的表格。1.2 测试用例解决什么问题测试用例要解决的核心问题本质上就三个测什么、怎么测、怎么算通过。先说说“测什么”。需求文档里写“用户可以在搜索框输入关键词进行搜索支持模糊查询”这句话看上去很清楚但你细想就会发现有一堆问题关键词最长能输多少个字支持哪些字符空搜索怎么处理特殊字符要不要过滤搜索结果是分页还是滚动加载没有结果的时候展示什么这些问题如果不在测试用例设计阶段想清楚等到执行的时候再一个个去问开发效率就太低了。再说“怎么测”。同样的一个搜索功能可以输入中文、英文、数字、混合字符、超长字符、纯空格、特殊符号、脚本代码可以有正常搜索、无结果搜索、快速连续搜索、弱网环境下搜索。到底要测哪些每一个操作步骤的先后顺序是什么测试用例就是把这些“怎么测”的路径固定下来让测试执行有章可循。最后是“怎么算通过”。预期结果不是“搜索成功”这四个字就完了而是要写清楚页面跳转到搜索结果页、列表展示与关键词相关的数据、结果总数大于0、排序符合规则。只有预期结果写得足够具体用例才有判断价值不然执行的人全靠猜那和没写用例有什么区别。1.3 衡量一份用例好坏的标准判断一份测试用例写得好不好我一般看四个维度。第一是覆盖率。需求里涉及的功能点、规则点、异常点有没有被覆盖到而不是只测了开心路径。第二是可执行性。用例拿到手不看需求文档、不问开发能不能直接照着操作步骤里有没有出现“输入正确的用户名”这种含糊表述第三是有效性。用例是不是真的能发现缺陷如果一套用例跑完连一个bug都没暴露出来而且不是因为系统质量好大概率就是用例设计得太浅了。第四是维护成本。用例是不是结构清晰、分类合理需求变更之后能不能快速定位需要修改的用例而不是在一堆杂乱无章的表格里大海捞针。我见过很多团队用例写了一大堆数量看着很壮观但真正执行的时候发现一半用例已经过期了另一半因为描述太模糊两三个人执行出了三种不同结果。这种用例不仅没有价值还会消耗团队信心。所以用不用例是态度问题用例写得好不好就是专业能力问题了。2. 测试用例的落地流程与设计过程2.1 需求分析测试用例的起点我见过的绝大部分低质量用例根源都在同一个地方需求没吃透就急着动手写。需求分析是测试用例设计真正的起点这一步做得越扎实后面写用例就越顺。拿搜索功能举例需求文档里可能只有一句“用户可以在搜索框输入关键词进行搜索支持模糊查询”。如果直接照着这句话写用例写出来的东西大概率就是“输入关键词点击搜索显示结果”这种空架子。正确的做法是从多个维度把这句话拆开。功能维度要看搜索入口、搜索触发方式、结果展示形式、分页逻辑、排序规则、无结果提示、搜索历史这些子功能分别是什么规则。规则维度要确认关键词长度限制、是否区分大小写、是否支持模糊匹配、是否过滤特殊字符。异常维度要覆盖输入为空、输入特殊字符、输入超长内容、网络中断、接口超时这些情况。数据维度要考虑搜索历史要不要持久化存储、搜索词要不要记录。兼容维度还要考虑不同浏览器、不同操作系统、不同分辨率下页面的展示和交互是否一致。我建议在需求分析阶段就做一个需求拆解清单把每个维度的问题列出来逐个确认。不确定的地方宁可多问几次也不要自己拍脑袋决定。我在实际工作中吃过一次亏有个搜索需求开发说搜索框限制了最大长度但需求文档里根本没写具体数字我以为没限制结果漏测了超长输入的场景上线后用户从别处复制了一段超长文本进去页面直接错乱。从那之后凡是需求里没写清楚的规则我一定会在写用例之前找产品和开发当面确认并在用例里标注“规则来源于某某确认记录”这样以后追溯也有依据。2.2 业务规则与边界条件提取业务规则本质上就是系统对“什么能做、什么不能做、做到什么程度”的约束。测试用例的核心任务之一就是把需求文档里自然语言描述的规则翻译成可验证的边界点和分支路径。举个例子需求里写“关键词长度限制为1到50个字符支持数字、字母、中文不支持特殊字符”。这句话看上去清晰但真正提取测试点时至少能拆出以下几条长度边界上1个字符是最小值50个字符是最大值0个字符是空输入51个字符是超长输入这四类数据全部要测。内容类型上纯中文、纯英文、纯数字、中英文数字混合每一种都是一个独立的测试点因为系统对它们的处理逻辑可能完全不同。特殊字符上标点符号、空格、emoji、HTML标签、单双引号这些都要分开测尤其是空格和引号很多系统的过滤逻辑在这两类字符上容易出问题。附加规则上全角半角是否一样处理、大小写是否敏感、输入内容前后的空格是保留还是去除这些细节往往藏在代码里需求文档不一定会写清楚。提取规则的时候有一个技巧每一条需求文字都逐词过一遍把“只能”“不能”“必须”“至少”“最多”“支持”“不支持”这些关键词圈出来每一个关键词背后都对应一组测试点。像“最多50个字符”意味着要测50和51“支持模糊查询”意味着要测部分匹配“不支持特殊字符”意味着要测特殊字符被拦截、被替换还是直接报错。把这些规则点整理成一张清单再逐个映射到对应的测试用例上覆盖率自然就上来了。2.3 测试数据设计正反用例的数据准备很多人写用例的时候测试数据是随手填的比如“输入abc”“输入123”看起来有数据实际上完全没有设计过。测试数据本身就是一项需要认真对待的设计工作它的质量直接决定用例能不能真正测到点子上。还是搜索功能。有效类的数据至少要覆盖中文关键词如“手机”、英文关键词如“phone”、数字关键词如“12345”、混合关键词如“iPhone 15 pro”、带空格的短语如“测试工程师”这几种类型目的是验证正常输入场景下系统行为是否正确。无效类的数据要有空输入、51个字符的超长输入、纯空格输入、特殊字符如“#$%”、脚本注入尝试如“ ”目的是验证异常输入场景下系统是否有正确的拦截和提示。这里特别说明一下测试数据设计有两个常见的坑。第一个坑是“一个数据想测多种场景”比如拿“手机”这个词既测正常搜索又测模糊匹配又测大小写不敏感结果一旦用例失败很难判断到底是哪个环节出了问题。正确的做法是一条用例聚焦一个测试目标数据要为目标服务。第二个坑是“以为选一个代表就够了”比如有效等价类里已经测了中文“手机”就认为不需要再测英文和数字了但系统对中英文的搜索处理逻辑可能完全不同比如分词策略、字符编码、匹配规则所以一定要按类型分别覆盖。我个人的习惯是在每条用例的“测试数据”字段里把具体值写死比如“用户名admin密码Abc123456”而不是写“输入正确账号”。这样既方便自己执行也方便别人接手还能在用例自动化的时候直接把参数提取出来。2.4 用例评审与基线冻结用例设计初稿完成后千万别急着直接拿去执行。用例评审这一关能帮你挡掉大量低级的、常识性的缺陷。评审之前写用例的人必须自己做一轮自查。我给自己定的自查标准是每条用例有没有明确的测试目标操作步骤是否每一步只有一个动作测试数据是否写具体了预期结果是否可检查、不模糊有没有遗漏边界条件优先级划分是否合理自查都过不了关的用例不要去浪费评审会上其他人的时间。自查结束后再找开发、产品和资深测试一起评审不同角色看问题的角度不同开发能看到底层实现上的约束产品能纠正对业务规则的理解偏差资深测试能指出设计方法上的不足。评审通过之后用例就要进入基线冻结状态。基线通俗理解就是把这一版用例作为后续测试执行的基准谁都不能随意修改。需求变更的时候走正式的变更流程重新评估受影响的功能范围更新对应的用例再次评审重新冻结。我见过有些团队没有“基线”这个概念谁想起来就改一下用例结果版本还没发用例已经改得面目全非回溯的时候完全对不上。冻结基线不是为了限制修改而是为了让修改有据可查、有流程可依。3. 测试用例的结构与编写规范3.1 标准用例字段解析一份规范的测试用例字段设计是很有讲究的。我用过很多模板无论是Excel表格、TestRail还是其他的用例管理平台核心字段基本就这几个用例ID、用例名称、优先级、前置条件、测试数据、操作步骤、预期结果。先讲用例ID。它的作用是给每条用例一个唯一标识方便引用和追溯格式通常采用“模块缩写-编号”比如登录模块就是LOGIN-001搜索模块就是SEARCH-001。建议在模块内部连续编号不要跳号这样统计用例数量和定位用例都比较方便。用例名称讲究一句话说清楚“测什么”。建议格式是“验证业务描述关注点”比如“验证搜索框最大长度限制”“验证未登录状态下加入购物车跳转登录页”。切忌写“搜索功能测试”“登录测试”这种把范围写得很大的名称因为一条用例只负责测一个点名称太大执行时根本对不上。前置条件强调的是“进入测试状态前必须具备的预设状态”比如“已打开搜索页网络正常”“测试账号admin已存在且密码有效”。这里要特别注意前置条件写的是客观存在的状态不是操作步骤。有些新人会写成“先打开浏览器输入网址”这不是前置条件而是步骤。测试数据就是执行这条用例需要的输入值务必写具体写死。“正确的用户名”这种写法等于没写要写“用户名admin密码Abc123456”。操作步骤要编号每步一个动作而且动作要具体。预期结果要对应步骤编号写得具体可检查。3.2 步骤描述与预期结果操作步骤和预期结果是整个用例的灵魂也是最容易写废的地方。操作步骤的编写有几个硬性要求。第一每一步只做一个动作不要把多个操作挤在一起比如“输入用户名和密码”就要拆成“输入用户名”“输入密码”两步这样一旦失败才能快速定位到具体动作。第二步骤中的操作对象和操作数据要具体“点击搜索按钮”比“点击按钮”好“输入‘手机’”比“输入关键词”好。第三步骤顺序要符合实际用户操作路径不要跳步。第四每一步对应的系统反馈如果值得验证就应该在预期结果中体现。预期结果最容易出现的问题是“模糊”。我见过最多的写法是“登录成功”“搜索成功”“页面正常”“提示正确”这些话等于什么都没说。什么是登录成功是跳转到首页是右上角出现用户名还是弹窗提示不同人理解完全不一样。正确的写法要追求可检查性比如“登录成功页面跳转到系统首页首页右上角显示当前登录用户‘admin’”。这样的预期结果任何一个执行者看到之后都能明确判断是否符合预期。这里分享一个我把关预期结果的小技巧写完用例之后拿一张纸盖住预期结果栏只看操作步骤在心里默默把步骤走一遍看看自己能不能确定每一步之后系统应该呈现什么状态。如果发现模棱两可、拿不准那就说明预期结果写得不够具体需要补充。这一步虽然费时但对提升用例质量非常有效。3.3 用例优先级划分方法优先级的作用是明确执行顺序让有限的测试精力花在最值得测的地方。一般分三级P0、P1、P2。P0是核心流程冒烟级用例一旦不通过版本就不能发布。比如登录、注册、支付、主流程下单这些核心链路只要有一个环节挂了用户就完全用不了产品这种用例是发布前的第一道闸门。P1是主要功能特性用户高频使用的功能比如搜索、筛选、排序、详情页展示这类功能出问题会严重影响体验但通常不会完全阻塞发版。P2是次要功能或异常场景比如边界值、特殊字符、无网络、权限不足这类用例它们很重要但优先级靠后时间不足时可以放到下一轮再执行。划分优先级的时候我一般考虑四个因素用户使用频率越常用的功能优先级越高功能影响范围影响面越大的优先级越高故障发生概率越容易出错的地方优先级越高故障造成的损失越严重优先级越高。实际操作中我还会加一条经验P0用例数量一般不超过总用例的15%如果P0太多说明对“核心”的定义出了问题什么都重要就等于什么都不重要。还有一个技巧是把P0用例单独抽出来组成一份冒烟测试集每次发版前先快速执行一遍十几分钟就能确认核心功能是否正常能省掉后面大量的返工时间。这个习惯我在多个项目里验证过效果非常好。4. 测试用例的核心设计方法4.1 等价类划分等价类划分是测试设计里的基础方法之一它的核心思想很简单把输入域划分成若干个互不相交的子集从每个子集中挑选一个有代表性的数据作为测试用例如果这个数据通过了就认为这个子集里的其他数据也大概率没问题。判断一个人是不是成年人“小于18岁”和“大于等于18岁”就是两个等价类各自选一个代表测一遍就够了不需要把1岁、2岁、3岁全都测了。应用到搜索框上有效等价类可以分成中文、英文、数字、混合字符这几类无效等价类可以分成空值、超长、纯空格、特殊符号、脚本注入这几类。每一类选一个代表数据即可。但这里有一个很容易踩的坑不是所有情况下等价类里的数据都可以随便挑一个就完事。比如“英文关键词”这一类你选了“phone”通过不代表“IPHONE”这种大写形式也一定能通过因为系统可能做了大小写不敏感处理也可能没有。所以等价类划分的时候如果有潜在的规则差异就要把子类再拆细一点比如“小写英文”“大写英文”“首字母大写英文”。等价类划分的精髓不是“省用例”而是“科学地省用例”。4.2 边界值分析边界值分析的出发点是大量错误往往发生在输入或输出范围的边界上而不是发生在范围内部。还是搜索框的例子需求规定关键词长度是1到50个字符那最容易出错的地方在哪里是正好50个字符、第51个字符、以及正好1个字符这个地方。这种规律在现实生活里也很常见比如考试60分及格59分和60分之间就是天壤之别。边界值分析的具体做法是找三个关键点上点正好在边界上的点比如50离点离边界最近的那个点比如49和51内点边界范围内的任意一个点比如25。实际操作中上点必测离点必测内点可以选测。像“最长50字符”这条规则就至少需要三条用例输入49个字符验证正常通过输入50个字符验证正常通过输入51个字符验证被拦截并给出提示。边界值分析几乎总是和等价类划分结合使用。正确的顺序是先用等价类划分出有效和无效大类再在边界值附近补充用例。比如先确定“有效长度1到50”是一个有效等价类“超过50”是一个无效等价类然后再对“1、50、51”这些边界值单独设计用例。两者的关系不是互斥的而是互补的。4.3 场景法等价类和边界值擅长处理单点输入但业务流程复杂的功能比如电商下单、账号找回、审批流光靠单点用例是覆盖不了的这时候就要用场景法。场景法的核心是从用户实际使用的角度出发把一条业务流程串起来测试。一个完整的业务流程里有基本流和备选流。基本流是用户最常走的、一切正常的那条路径比如用户登录、搜索商品、加入购物车、提交订单、支付成功。备选流是在基本流的每个环节上可能出现的异常分支比如登录失败会提示错误用户可以找回密码重新登录后继续购买。场景法的实施步骤我是这样做的第一步把需求中描述的正常流程梳理成基本流。第二步逐个分析基本流中每个环节可能出现的异常或分支写成备选流。第三步把基本流和备选流组合成完整的测试场景每个场景对应一组用例。比如登录环节就有“账号密码正确登录成功”“密码错误提示重新输入”“账号不存在提示注册”“忘记密码走找回流程”这几个分支每个分支都要设计独立的用例。场景法最大的价值在于它逼着你从用户的完整操作路径去想问题而不是站在功能点的局部去看。很多单点看都没问题、串起来就出bug的缺陷只有用场景法才能被发现。4.4 判定表与正交实验简述当功能有多个输入条件而且不同条件的组合会产生不同输出时等价类和边界值就不太够用了这时候可以引入判定表法和正交实验法。判定表由条件桩、条件项、动作桩、动作项四部分组成。条件桩列出所有参加判断的输入条件条件项列出每个条件的取值组合动作桩列出所有可能的输出动作动作项则是每个条件组合对应的输出结果。比如优惠券系统是否登录、是否领券、金额是否满足门槛、商品是否在可用范围内这四个条件的不同组合会带来不同的输出用判定表可以把所有组合和对应的处理逻辑一次性理清楚。正交实验法适用的场景是条件很多把所有组合全测一遍成本太高。正交表的设计思路是选取有代表性的组合进行测试用较少的用例覆盖大部分组合情况。这种方法在参数组合类测试中非常实用但初学阶段建议先从等价类、边界值、场景法这几个基础方法练起判定表和正交法前期了解原理后续需要时再深入研究。设计方法没有优劣之分只有适不适合能用最合适的方法解决当前问题才是关键。5. 测试用例的维护与常见问题5.1 用例维护的节奏测试用例不是写完之后就一劳永逸的它是一份需要持续维护的活文档。我建议的维护节奏有三个固定节点。第一个节点是版本迭代时。每次新需求进来功能有了变化对应的用例就必须同步更新——新增的功能要补用例修改的功能要改用例删除的功能要移除用例。第二个节点是定期抽查。我习惯每两个迭代周期或者每个月随机抽取一部分用例去核对确认它们和当前版本的功能仍保持一致防止用例悄悄“过期”。第三个节点是线上缺陷反哺。线上出了问题复盘的时候一定要回到用例层面检查这个缺陷为什么没有在测试阶段发现是漏设计了用例还是用例执行了但预期结果没覆盖到找出原因后把缺失的用例补进去防止同样的漏测再次发生。维护用例最忌讳的态度就是“能用就行”。我见过有些团队用例库越来越大动辄上万条但真正有效的可能只有六成剩下的要么过期要么重复要么写得压根没法执行。这样的用例库不仅是资产还是负债因为它会让人失去对测试的信任。5.2 常见问题与对策整理一下我工作中常见到的用例问题基本可以归为四类。第一类是粒度过粗或过细。粒度过粗的表现是一条用例试图覆盖所有场景比如“验证搜索功能的正常和异常情况”这种用例完全没有可执行性。粒度过细的表现是为一个简单功能写了几十条几乎重复的用例比如同一个输入框把每种标点符号都单独列一条。对策是把握一条原则一条用例对应一个明确的测试目标。粗的要拆细的要合并。第二类是冗余。用例库里有大量重复用例可能是因为不同人设计过同一个模块也可能是因为版本迭代时旧用例没清理。对策是给用例按模块做好归档定期做“查重”同模块的用例放在一个目录下设计新用例前先查一遍有没有已存在的相同覆盖点。第三类是用例过期。系统功能已经改造了用例还停留在旧版本。这种情况通常发生在项目紧、迭代快的团队里。对策是前文说的三个维护节点一定要坚持尤其是线上缺陷反哺这一个动作是对抗过期的利器。第四类是最隐蔽的——用例和缺陷没有关联。用例测出了一个问题问题被修复了但反查用例发现根本没有一条用例覆盖了这个场景那这个问题下次大概率还会再犯。对策是把缺陷和用例做双向关联每个缺陷都要能追溯到它是由哪条用例发现的如果是由未覆盖的路径发现的那就说明用例有遗漏需要补。5.3 测试用例与缺陷管理联动测试用例和缺陷管理的关系比很多人想象中更紧密。一份高质量用例库天然就是缺陷管理的依据。我推荐的做法是缺陷报告里增加一个“关联用例”字段填写发现这个缺陷时执行的是哪条用例。这样一来缺陷被修复之后回归测试的范围就非常明确了把这条用例以及它所在的业务场景周边的用例一起跑一遍就能验证修复是否有效、是否引入了新问题。相比“凭感觉从头回归一遍”“用例驱动回归”的效率要高得多覆盖率也更可把控。反过来缺陷记录也是用例质量的反馈数据。如果某条用例反复报出缺陷说明这块功能不稳定需要提醒开发重点关注如果某个模块长期一条缺陷都报不出来就要警惕是不是用例本身有问题覆盖不到真正的风险点。我曾经维护过一个老模块用例有一千多条但连续三个迭代一条缺陷都没报我一查才发现大部分用例用的测试数据都是那一套老账号、老商品根本走不到新逻辑的分支上。把测试数据更新之后缺陷很快就暴露出来了。用例和数据都是活的要随着系统的变化一起演进。结尾测试用例写了这么多年我最大的体会是它从来不是一锤子买卖写完了往文档库一丢就完事。那些真正有好处的团队都是把用例当作项目活文档来养的需求变了它跟着变线上出问题了它反哺补漏新人来了它是最好的业务教材。我个人的习惯是每做完一个迭代都会专门留出一点时间回头翻翻用例库删几条过期的、补几条漏掉的、改几条写得含糊的。这个动作看起来不起眼但坚持几个版本之后回归效率的提升会非常明显。如果你刚开始接触测试不用急着把所有的设计方法都学完先把等价类、边界值、场景法这三样用熟把用例字段写得规范、预期结果写得具体就已经能超越很大一部分从业者了。更重要的是养成一种习惯——每写一条用例之前多问自己一句用户真的会这么操作吗如果不会我为什么要测它多想几次用例的水平自然就上去了。
