1. 测试用例是软件测试的“最小可交付物”它的价值被低估了在软件测试这个行当里我见过太多人把“写用例”当成应付流程的苦差事需求评审结束拉一个Excel模板照着功能列表逐条填“操作步骤、预期结果”填满几十条就算交差。可一旦版本上线线上出问题回头一查出事的那条路径恰恰在用例列表里找不到。这种场景几乎每个测试团队都经历过问题不在执行的人不够细心而在用例设计这一步就没把“测什么、为什么测、怎么测”想清楚。测试用例不是需求文档的复述也不是给领导看的进度表。它是软件测试工程师把需求翻译成“可执行验证方案”后产出的最小交付物。一个用例能独立回答三个问题验证哪个功能点在什么前置条件下操作操作后应该观察到什么结果能够清晰回答这三个问题的用例才具备可执行性反过来如果连“为什么写这条用例”都答不上来那这条用例大概率是在凑数。所以我把用例设计的价值分为三层第一层是覆盖它能告诉我们哪些功能正常、哪些异常、哪些边界被验证过第二层是可追溯每一条用例都能对应回具体的需求和风险别人接手时知道它存在的理由第三层是知识沉淀好的用例集合本身就是团队对产品最完整的行为描述新人看一遍用例比读三遍需求文档更能理解系统。忽视这三层价值用例设计就退化成了填空题软件测试的质量自然无从谈起。1.1 用例是测试计划里唯一能“落地执行”的载体测试计划、测试方案这些文档更多是在回答“怎么组织测试”而用例才是真正落到操作层面的载体。很多测试团队计划写得漂亮风险识别也做了但到了执行阶段全靠测试人员临时发挥这种做法在项目节奏紧张时尤其危险今天这个功能测了明天换了人就不一定测版本迭代一快回归范围全靠记忆漏测几乎是必然。用例能成为“最小可交付物”是因为它满足三个特征一是原子性一条用例只验证一个相对独立的测试点失败之后可以快速定位到具体环节二是有明确预期预期结果不是“功能正常”这种废话而是可观察、可比较的具体表现比如“点击提交后按钮置灰2秒随后跳转到订单列表页并弹出‘提交成功’提示”三是可回归无论今天谁执行、什么时候执行同一套前置条件和步骤应该得到同样可判定的结果。正因为有这三个特征用例才能支撑起软件测试里最核心的“回归”动作也能在自动化测试中成为脚本的脚本。1.2 用例数量不是KPI覆盖风险和需求才是我见过有些团队把“写了多少条用例”当作绩效指标于是出现了一种奇特现象一条登录功能能拆出三四百条用例把用户名长度、密码长度、每次输入字符的排列组合全列一遍数量是凑够了真实风险却可能完全暴露在盲区里。用例设计的第一原则不是“写更多”而是“写对”。什么算“对”我的判断标准是每一条用例背后要么对应一个需求逻辑分支要么对应一个用户真实使用场景要么对应一个已经发生过的线上缺陷。如果三者都不是这条用例再好看也是负债因为它会增加维护成本、拉低执行效率、干扰自动化脚本的稳定性。后面我会详细讲怎么用等价类、边界值、判定表、场景法这些方法把“写对用例”从口号变成可复现的流程。2. 动笔之前需求拆解成测试点的完整路径很多测试新手拿到需求文档第一反应是打开Excel开始写第一条用例。这是最大的误区。用例设计不是从“写”开始的而是从“拆”开始的。需求拆解得越细用例设计就是顺水推舟拆解模糊后面的用例要么冗余要么漏测。我习惯在动手前先做三件事建立“输入—处理—输出”模型梳理业务流程和状态流转最后把需求翻译成一组可验证的测试点。这三件事做完相当于给自己画了一张测试地图后面的所有用例都是地图上的坐标点而不是零散堆砌的功能快照。2.1 用“输入—处理—输出”模型吃透单功能需求任何功能无论界面多复杂底层都可以抽象成一组输入、一段处理逻辑、一个输出结果。页面上的文本框、下拉框、单选按钮、上传文件、接口参数都是输入后端校验、数据库读写、金额计算、状态变更都是处理页面跳转、提示信息、返回报文、落库数据、发送消息都是输出。拿到需求后我会先列一个三列表输入项有哪些每个输入项的类型、长度、取值范围、是否必填是什么对应的处理规则是什么输出结果有哪些可观察的表现比如做一个“用户注册”功能输入项至少包括手机号、验证码、密码、确认密码处理规则包括手机号格式校验、验证码有效期与一致性校验、密码复杂度校验、两次密码一致性校验输出包括注册成功跳转、验证码错误提示、密码规则不满足提示、接口返回错误码等。这张表一列出来测试点基本上就浮出水面了之后写用例只是把每个“处理规则”变成“验证步骤”和“预期结果”。2.2 从业务流程和状态流转里挖隐形需求单功能拆解解决的是“这个功能怎么工作”的问题但很多缺陷恰恰出现在“多个功能怎么串联”和“状态怎么迁移”上。这时候就要画业务流程图和状态转换图。不需要画得多专业能表达清楚路径就够。以订单系统为例一个订单会经历“待支付、已支付、已发货、已签收、已取消、售后中、已完成”等多个状态。单看“取消订单”这个功能测试点可能只有“取消成功”和“取消失败”但放到状态流转里看真正值得测的是待支付状态取消、已支付未发货状态取消、已发货状态取消、已签收状态取消这四种路径的业务规则完全不同是否退款、是否要扣手续费、是否要通知商家都是测试点。如果你只看需求文档里“用户可以取消订单”这一句话这些路径就全部漏掉了。所以我给团队的要求是用例设计前必须输出一版简单的状态流转表哪怕只是Excel里的一列“从状态A到状态B触发动作是什么允许还是禁止”。有了这张表测试点才不会只停留在功能表面。2.3 用“测试点卡片”把需求翻译成可验证的句子测试点是从需求到用例之间的一层“中间产物”它比需求更具体又比用例更简练。我会把每个候选测试点写成一句话“验证xx条件下执行xx操作期望xx结果”。比如“验证手机号为空时点击获取验证码提示‘请输入手机号’且不发送短信”“验证手机号格式为11位且以1开头时点击获取验证码发送成功并出现60秒倒计时”。这样做的好处非常明显一是在设计阶段就能过滤掉一批“伪测试点”比如“验证注册功能正常”这种不可执行的句子根本没法往下写二是方便评审产品、开发和其他测试同事只需要看测试点卡片就能快速指出遗漏或理解偏差不用在几十条用例里逐条找三是后期写用例时一张卡片可以直接展开成一条或多条用例减少重复脑力劳动。我个人的习惯是测试点卡片放在用例表里的一个单独Sheet每条测试点有个编号写用例时在“覆盖测试点”一列引用编号这样用例和需求之间就有了第一层追溯关系。2.4 需求评审不能等用例设计完再做这里我想强调一个反过来的做法与其等到需求评审时才发言不如在写用例之前先做一轮“测试视角的需求预审”。因为用例设计本身就是最残酷的需求审查手段——你会发现需求里大量“未定义”的地方验证码有效期是多少密码最短几位点击取消后订单状态多久更新输入框最多能输多少字符这些问题如果等到写用例时才发现你只能反复找产品确认效率极低。我的做法是在需求评审会上直接带着一张“待澄清问题清单”去清单上的每一项都来自用例设计前的输入拆解。这样既推动了需求完善也让产品和开发提前知道测试会把边界放在哪里后续执行阶段扯皮少很多。这个过程本质上就是软件测试工作前移到需求阶段的价值体现。3. 核心设计方法等价类、边界值、判定表与场景法的组合打法方法不在多在于会用。等价类、边界值、判定表、场景法这四招是软件测试用例设计里最常用的基本功但很多人只是背了名称并不会组合使用。我用一个贯穿始终的例子来说明设计一个“手机号验证码登录”功能的用例。需求背景先交代清楚输入项为手机号、验证码。手机号规则是11位数字、以1开头验证码规则是6位数字、有效期5分钟、错误次数超过5次后账号锁定30分钟。3.1 等价类划分按“处理规则是否一致”分而不是按“正确/错误”分等价类划分的核心思想是如果一组数据被程序用同样的规则处理那么它们属于同一个等价类只需要测其中一条代表数据就够了。初学者最常犯的错是把等价类简单分成“有效等价类”和“无效等价类”但有效无效只是表面处理规则一致才是本质。拿手机号来说按处理规则可以分类别示例数据处理规则合法手机号13812345678进入“获取验证码”流程非1开头23812345678提示“请输入正确的手机号”不发送验证码非11位1381234567提示格式错误不发送验证码含非数字字符1381234567a提示格式错误不发送验证码空值未输入提示“请输入手机号”不发送验证码注意“13812345678”和“13912345678”都属于“合法手机号”这个等价类不需要两条用例都写同样“23812345678”和“28812345678”都属于“非1开头”选一条代表即可。等价类划分的意义在于去重让用例数量“瘦身”把有限的执行时间留给真正不同的处理分支。等价类划分的产出不是用例而是一张“类别-代表数据-预期处理”的对照表后续方法都在这张表上做增量。3.2 边界值只测边界还不够要测“刚刚经过边界”的状态边界值分析是等价类划分最有效的一个补充因为开发写代码时最容易在边界判断上出错比如length 11写成length 11count 0写成count 0这类问题。手机号长度的边界是11位那我要测的不只是11位合法数据还要测10位、12位以及理论上不太可能出现的0位空值。验证码6位数字那边界值是5位、6位、7位另外还要考虑验证码输入框是否接受空格、全角字符等。用户名、密码、金额、数量、日期范围几乎每个带边界条件的输入项都值得这样过一遍。边界值方法有个容易忽略的进阶点除了输入值的边界还要关注“时间边界”和“状态边界”。比如验证码有效期5分钟那就要测第4分钟59秒输入是否成功、第5分钟0秒输入是否失败转账限额每日1万元那就要测单笔刚好1万是否成功、加上当天已发生金额后是否超额。这些边界往往比数值边界更容易漏也更容易在线上出事故。3.3 判定表多条件组合用判定表条件多就做条件合并当业务规则由多个条件组合决定时等价类和边界值就不够用了因为组合数是爆发式增长的。比如“手机号是否正确”和“验证码是否正确”两个条件组合起来就有4种情况如果再加上“验证码是否过期”、“错误次数是否超过5次”、“账号是否锁定”组合数翻倍这时候判定表是最好用的工具。判定表的做法列出所有条件每个条件取“真/假”或“有效/无效”两个取值然后列出所有可能组合一列一种组合最后对照需求逐列填动作。我不建议一上来就做全组合而是在拆完条件后先做“条件合并”把不改变结果的组合合并把互斥条件直接写进约束。以“验证码错误次数超限”为例条件可以简化为条件A验证码是否正确是/否条件B错误次数是否已达5次否/达/未达条件C验证码是否在有效期内是/否把条件组合填入判定表后每一列就是一条规则对应一组预期结果。判定表的优势是逻辑直观评审时产品和开发一眼就能看出“这个组合的业务规则你没定义”从而倒逼补齐需求。实际项目里条件控制在4到6个超过这个数先做条件合并否则判定表会膨胀到不可维护。3.4 场景法以用户动作为主线别被功能列表绑架前面的方法都是围绕“单个输入条件”展开的但用户操作永远是连续动作。场景法也叫流程分析法的核心是把用户从头到尾的一次操作过程当作一个测试场景覆盖“基本流”和“备选流”。接回“手机号验证码登录”的例子基本流是打开登录页 - 输入手机号 - 点击获取验证码 - 输入6位验证码 - 点击登录 - 进入首页。备选流至少有这些验证码错误一次后重新输入错误多次后触发锁定登录页切走又切回后验证码是否仍有效验证码未过期但手机号切换了验证码是否失效。场景法最大的价值是防止“只见树木不见森林”。很多测试人员用等价类和边界值把每个输入框测得很细却忽略了“用户到底是怎么操作的”。我见过一个项目单功能用例全部通过但两个用户同时下单时因为前置库存校验缺失导致超卖这个缺陷恰恰需要场景法把“并发下单”这条备选流列出来才能发现。场景不只包括正常路径还包括中断、重复、回退、并发、超时等异常路径。3.5 四种方法如何组合成一张用例网我的组合策略是先用场景法画出主流程和备选流程确定“有哪些场景要测”再对场景中的每个输入项做等价类划分去掉冗余接着对关键输入项补边界值覆盖最容易出错的临界点最后对多条件规则用判定表确保业务规则组合不漏。四层过滤下来同一功能的用例数量不会爆炸但每个风险点基本都有对应用例。以登录功能为例最终的用例网是首先有5条主流程场景用例覆盖不同业务路径其次有手机号和验证码各自的等价类代表数据然后补手机号长度边界、验证码长度边界、验证码有效期边界最后对“错误次数锁定状态有效期”组合用判定表生成规则用例。这样一套下来常规功能30到50条用例就足够扎实而不是动辄上百条有效无效交替的流水账。4. 让用例可执行、可度量字段模板、优先级与覆盖率追踪方法把“测什么”想清楚了接下来就是“怎么写”才能让人看得懂、跑得动。很多团队的用例表只有“步骤”和“预期”两列看上去简单实际执行时问题一大堆前置条件没人写测试数据没人准备预期结果含糊到任何结果都能算通过。这样的用例执行质量完全依赖个人水平根本无法度量和复盘。我建议用例表至少包含以下字段按团队需要裁剪字段说明示例用例编号唯一标识建议按模块类型序号编码LOGIN-FUNC-001所属模块功能模块名称登录注册用例标题一句话说明验证点手机号格式错误时点击获取验证码提示错误优先级P0到P3P1前置条件执行前必须满足的状态和数据已进入登录页未输入任何短信测试数据具体输入值或数据准备方法手机号23812345678操作步骤从用户视角描述动作明确1.输入手机号 2.点击获取验证码预期结果可观察、可判定的结果提示“请输入正确的手机号”不发送短信实际结果执行时填写与预期一致结论通过/失败/阻塞通过覆盖需求编号对应的需求项或测试点编号REQ-101这里最容易被忽略的是“前置条件”和“测试数据”。前置条件不写清楚执行者拿到用例不知道要不要先造数据测试数据不写具体执行者随便填一个手机号很可能落在别的等价类里测的压根不是这条用例想验证的场景。用例是给团队执行的不是给自己看的所以一切歧义都要在设计阶段消掉。4.1 优先级怎么定先保核心业务流程再拼覆盖率优先级不是按功能模块的重要性拍脑袋定的我的划分逻辑是P0是核心链路和资金安全相关的用例失败会直接阻断版本发布P1是主要功能的主流程和重要分支失败会影响用户体验但可以带风险发布P2是一般功能的常规场景和中等优先级分支P3是边缘场景、界面细节、兼容性等可延后修复的问题。优先级同时决定了回归范围版本发布前P0和P1必须全回归P2至少跑一轮冒烟P3放到稳定迭代窗口处理。这样即使时间紧张测试团队也能用有限资源守住最重要的风险。覆盖率度量的第一步就是统计各级别用例的执行通过率而不是只看总条数。4.2 覆盖率不是看代码行数而是看需求分支有没有对应用例“覆盖率”这个词在软件测试里很常见但很多人把它理解成“代码覆盖率”。我并不反对看代码覆盖率但对测试用例设计来说更实用的是需求覆盖率。做法是前面提到的“需求编号/测试点编号”映射表每个需求项是否至少有一条用例覆盖每个状态流转是否至少有一条用例覆盖代码覆盖率可以作为补充当你发现某段新增代码没有任何用例关联时大概率存在测试盲区。我常用的覆盖率估算方法简单粗暴需求拆出来的测试点总数是多少已经有对应用例的测试点是多少相除就是需求覆盖率。统计出来如果低于80%我不会急着补用例而是先问“剩下20%的测试点是没条件测还是压根没设计出来”。没条件测可以标注阻塞没设计出来就得回到第二章节的方法重新拆解。4.3 评审用例时最该问的不是“写得对不对”而是“漏了什么”用例评审是设计质量的最后一道关口但很多评审会开成了“念用例大会”效率极低。我复盘过几十场评审最有效的问题清单是这几个这条用例的预期结果产品能接受吗有没有歧义这个场景在真实用户操作里可能出现吗概率大小无所谓但至少要见过。刚才讨论的条件组合判定表里有没有对应列新增需求和旧功能之间的联动有没有回归场景覆盖测试数据是否确实可用是否存在执行时才发现没有入口造数据的情况评审不需要逐条念Excel而是带着这几类问题有的放矢地过一遍测试点和关键用例。我和团队的习惯是评审前发一份“重点风险用例清单”只聊有争议、有遗漏可能的地方普通用例留到会后自行确认会议效率翻倍。5. 用例的“可维护性”是自动化时代的及格线如果你做过几年软件测试一定有这样的痛苦用例写了一堆版本一迭代三分之一用例直接失效维护成本比新写用例还高。尤其在引入UI自动化测试之后用例的可维护性问题会被放大十倍元素定位变了要改脚本业务流程调整了要重构步骤测试数据变了要重新设计前置。所以用例在出生那一刻就要为自动化做好准备。5.1 把测试数据和操作步骤分离让用例更抗业务变动最常见的问题是把“测试数据”直接写死在“操作步骤”里。看起来省事但需求一旦调整比如手机号长度从11位变成13位你得在几十条用例里逐条改步骤漏一处就是隐患。正确做法是用例的“测试数据”字段单独维护操作步骤里用参数名代替具体值比如“输入{手机号}”然后在测试数据字段里定义“手机号13812345678”。更进一步可以把测试数据抽成独立的数据表每条用例引用一个数据编号。这样业务规则变化时多数情况下只需要改数据不动步骤自动化脚本同理参数化后的用例脚本即使页面文案变了也常常可以做到零修改。5.2 前置条件的搭建要可复制不要依赖“上次跑过所以现在还在”执行用例最怕环境状态不可控。比如一条“取消订单退款”的用例前置条件是“已有一笔支付成功的订单”如果每次执行都要手动去下单再支付效率极低而且很可能下单流程脏数据堆积导致后续用例互相影响。我会要求团队把前置条件写成“可重复搭建”的状态要么通过接口预置要么通过造数工具要么在用例自动化里用前置步骤创建数据。原则就一个每一个用例执行前系统状态必须是“确定的、可重建的”。不满足这个原则的用例严格来说不可执行因为换个人、换个时间跑结果可能完全不同。在执行记录里增加“前置准备耗时”这个指标会很直观地暴露出哪些用例的预置成本过高值得投入精力做数据工厂。5.3 用例之间尽量独立混合依赖是回归执行最大的坑我说“尽量”独立是因为真实业务里完全独立很难比如“先下单才能发货”。但至少要遵守一个底线用例A的执行结果不能决定用例B是否还能跑。换句话说不要在用例B的“前置条件”里写“用例A已经执行成功并留下某状态”而应该写“存在某状态且可通过xx方式预置”。否则回归时用例A失败用例B连带失败失败原因被掩盖测试团队会花大量时间做“区分是我搞坏了还是本来就是坏的”这种无价值分析。自动化测试里这个问题尤其严重。脚本之间如果有隐式依赖异常发生时排查链路会非常痛苦。我见过一个团队的自动化用例是按顺序跑的某一天中间一条挂了后面十几条全部失败最后发现是前面那条的脏数据污染了全局状态。把用例之间的依赖切开回归的稳定性才能上来。5.4 自动化改造从用例字段规范开始很多人以为自动化测试是脚本工程师的事用例设计者只需要“到时候把手工用例交给开发”。但真正顺利的自动化改造恰恰是从用例设计的规范化开始的。如果一条手工用例的操作步骤是“输入正确的手机号”自动化脚本并不知道“正确的手机号”是什么如果预期结果是“页面正常跳转”脚本也不知道要怎么断言。自动化脚本最擅长的是匹配明确的输入值和可量化的预期所以用例在设计时就要把模糊词汇消灭掉“验证码错误时会提示用户”要改成“输入6位错误数字后点击登录登录按钮下方显示红色提示‘验证码错误’停留3秒后自动消失”。把每个预期都拆成“状态变化文案/数值时间条件”是让手工用例平滑转向自动化的关键。这不是说所有内容都要自动化而是说哪怕只是自动跑冒烟用例你也需要这些语义清晰的步骤和断言点。6. 从评审到回归用例执行后的迭代闭环用例设计不是一次性工作。每次版本执行完、每个bug产生后用例库都应该有所反应否则下一次迭代还会漏掉同样的风险。很多团队用例库越来越难用根本原因就是从没有闭环维护过。6.1 每条线上缺陷都应该反哺一条新用例我在项目里立过一条规矩线上缺陷和开发自测漏掉的问题无论修没修完第一件事就是补一条用例到回归用例库并在用例备注里关联缺陷编号。原因很简单缺陷是已经发生的风险是最有说服力的测试点如果不沉淀成用例你无法证明它修复了也无法保证下次不会重现。补用例不是简单地把bug报告复制一遍而要抽象成“触发条件操作路径预期结果”。举例线上有个bug是“用户连续点击两次提交按钮生成了两笔订单”补的用例应该是“提交请求发出后立即再次点击提交按钮系统应阻止第二次提交并提示处理中”而不是“点击提交按钮后用户只有一笔订单”。这样补出来的用例验证的是根因路径而不只是表面现象。6.2 回归不是全量重跑而是按“变更影响面”动态规划回归范围的选择是测试执行里最需要经验的一环。全量回归在大型系统里成本不可接受完全不回归又风险巨大。我的做法是三层叠加第一层本次变更直接涉及的模块全部相关用例必跑第二层与变更模块有数据交互、状态流转、接口调用的关联模块跑核心流程用例第三层关键历史缺陷回归挑那些曾经线上出过、代码改动容易影响的用例。这个范围不应该是执行时才拍脑袋定而应该在用例设计阶段就把“影响模块”和“关联需求”字段维护好。变更来了测试负责人对着需求变更单直接在用例库里筛出受影响用例集合再叠加历史缺陷用例回归范围自然就出来了。整个过程不超过半小时但比凭记忆“觉得应该测一下”靠谱得多。6.3 定期清理“僵尸用例”保持用例库的健康度所谓僵尸用例是指那些长期不执行、执行了也没什么人关心结果、已经和新版本逻辑对不上的用例。它们躺在用例库里不产生价值只会让“总用例数”虚高让覆盖率统计失真也让新人接手时不知所措。我建议每个迭代末尾做一次轻量清理先标记90天以上没有更新也没有执行的用例逐条确认是删除、更新还是保留对每个迭代都有变更的模块优先检查关联用例是否需要同步调整对自动化脚本里的用例跑一轮全量后把失败且已确认废弃的用例移出基线不要让它们继续占用回归时间。用例库不是档案馆不需要把所有历史痕迹都留着有用的才值得留下。7. 我在一线写用例时踩过的坑和自检清单最后聊点“文档里不会写”的东西。我在软件测试这条路上踩过不少坑最深的三个值得每个用例设计者引以为戒。第一个坑是“过度设计”。刚学会等价类和边界值时觉得每写一条用例都很专业结果登录功能写了200条自己执行都嫌烦后来被开发吐槽“你们测试就是测些没人会用的场景”。后来我明白了用例设计要服务风险不是服务方法本身。方法只是工具一个输入项到底需要多少条用例取决于它的业务重要性和出错概率而不是理论上的排列组合。第二个坑是“用例设计完就抛到脑后”。用例不是写出来给评审会拍照用的它是执行和回归的基准。我见过太多团队用例库严重滞后于实际功能执行根本不受用例管控最后用例成了摆设。要让用例发挥价值必须有闭环执行要按用例跑、缺陷要反哺用例、需求变更要同步用例。这是流程问题不是写作技巧问题。第三个坑是“忽略数据和环境的设计”。很多用例写得逻辑通顺但执行时发现没有对应的测试账号、没有可用的测试商户、没有造数接口只能临时绕过测出来的结果根本不代表真实路径。数据设计在用例设计里占的权重不比功能逻辑低。一个成熟的测试团队一定有一个专门的测试数据策略甚至会有数据工厂来支撑用例执行。下面是我每次写完一轮用例之后都会对照的自检清单分享给你做参考每一条用例是否能回答“为什么测它”对应需求编号、测试点编号是否可追溯。前置条件是否可复制、可重建测试数据是否写清了具体值或获取方式。操作步骤是否消除了“正确的值”“正常情况”这类模糊表述预期结果是否可观察、可比较包括文案、状态、跳转、落库数据等。每个输入项是否都用等价类去重过关键边界是否都补了边界值多条件组合的业务规则是否用判定表核对过有没有未定义的组合主流程和备选流程是否都覆盖了有没有考虑中断、重复、回退、并发、超时。历史缺陷是否已经有一条对应的回归用例用例之间是否存在隐性依赖能不能做到独立执行。自动化改造视角下步骤和预期是否足够结构化能直接翻译成脚本断言软件测试用例的设计说到底是一门“把模糊需求精确成可验证行为”的手艺。方法可以学套路可以练但真正让用例有价值的是你是否愿意在动笔之前多问自己几层为什么。把这些基本功打扎实无论是写手工用例、做自动化回归还是应对软件测试面试里的场景设计题你都会比大多数人更能站得住脚。