★ FEATURED ARTICLE 1. 拿到需求文档后先别急着写用例需求认知的三个层次有一次评测会开发把需求讲完我随手翻翻手里那版用例——二十多条“验证XX功能正常”每条长得都像孪生兄弟。坐在旁边的新人小声问这些用例到底是怎么从需求里“变”出来的这一问把我问住了因为我确实很少复盘“变”的过程。后来在这个行业里泡得久了才看明白真正拉开测试工程师差距的不是用例数量不是执行速度而是对测试需求和测试模型的认知深度。先说个扎心的事实大多数测试需求分析停在了“把需求文档翻译成用例”这一步。文档里写得清楚的用例覆盖到了文档里没写的用例里就没有。可软件测试真正值钱的地方恰恰就是把那些没人明说、但系统必须正确响应的东西挖出来。这就是认知三层次的第一层——对象认知。你得先搞清楚被测系统是谁、它处在什么环境里、谁在用、用它干什么。第二层是目的认知你不仅要懂系统能做什么还要懂系统为什么这么做背后有什么业务约束。第三层是边界认知系统在什么条件下成立、在什么条件下会瓦解这里往往藏着最容易漏掉的缺陷。我见过不少人在这三层上栽跟头。某次一个电商项目需求文档写得很完整登录、下单、支付全都有结果上线后出了个事故凌晨两点用户用积分加现金混合支付订单状态一直卡在“支付中”。为什么因为需求分析时只看到了“支付成功”和“支付失败”两种结果压根没想过第三方支付渠道超时这种中间态。这就是对象认知和边界认知没有做透的典型例子——大家都以为自己在测支付其实只测了支付最光鲜的那条路。所以我现在拿到需求文档第一件事不是打开用例模板而是先做一张“需求认知脑图”左边写用户中间写流程右边写约束底下写异常。这张图画完我对“要测什么”才敢说有谱。2. 需求拆解的实操心法把一句话变成一张可执行的测试纲领2.1 业务规则从哪来三个容易被忽略的来源很多测试工程师拆需求只会盯需求规格说明书但真实的业务规则往往有三个来源只盯一个注定会漏。第一是需求文档本身。这个不用多说但要警惕的是文档里的“逻辑暗坑”。比如一句“会员享受折扣”听起来很简单可“会员”的定义是什么注册就算还是得累计消费满多少折扣和优惠券能不能叠加叠加时先算哪个“以价高为准”还是“以时间先后为准”同样一句话不同的人能读出三套规则。第二是历史缺陷库和线上问题记录。这是最容易被忽略但回报率最高的来源。我习惯在接手新模块时先去翻一遍这个模块过去的缺陷单看看哪些地方崩过、哪些逻辑被改过。某次我做支付模块翻了历史记录才发现退款金额大于原订单金额这种情况系统逻辑上有漏洞但需求文档里从没提过。这类“用血换来的规则”需求文档永远写不进去。第三是业务方的口头补充和用户反馈。需求评审会上业务方随口讲的一句“其实只有VIP用户才能走这个流程”往往就是决定性的逻辑分支。这个信息不进文档你不在评审会挖出来后面测到天荒地老也测不对。2.2 用“需求条目表”把隐性需求显式化很多人写用例时总觉得“没思路”其实就是需求颗粒度太粗。我习惯的第二步是把拆出来的业务规则填到一张需求条目表里一列写编号一列写规则的原始描述一列写我理解的逻辑一列写验证方式一列写风险备注。举个例子还是那个会员折扣需求。原始描述是“会员享受95折”。规则1会员身份认定——注册时间超过30天且完成过至少1笔有效订单才算会员。规则2折扣适用范围——全场通用但特价商品和秒杀商品不参与。规则3折扣叠加逻辑——会员95折可与其他平台券叠加叠加时先算会员折扣再算券。规则4折扣计算精度——按单品优惠后价格向下取整到分再累加订单总额。规则5异常场景——打折后金额低于1分钱按1分钱处理。同一句话拆出五条规则每条对应一组测试用例这事才算做到位。这张表就是你的“测试纲领”后面所有模型和用例都围着它转。2.3 不写进文档的隐式需求约束、权限、性能、兼容还差一处不能漏就是隐式需求。这类需求不会有人专门写给你看但你漏了后果一样严重。我归纳成四类约束类比如接口超时时间、并发上限、单次上传大小限制这些参数一般写在技术方案里测试前必须和技术确认清楚。权限类哪些角色能看到哪些数据、能操作哪些按钮。很多系统前台按钮不显示但接口不拦截测试如果不专门设计越权用例上线就是事故。性能类需求文档里写“支持1000人在线”但1000人是平均在线还是峰值并发响应时间要求多少这些往往要到压测阶段才被提出来最好在需求分析时就确认。兼容类浏览器、操作系统、屏幕分辨率、网络类型到底哪些组合是官方支持矩阵我见过太多团队默认“全兼容”结果测到后面根本测不完只能砍范围。把显式规则和隐式需求都列全需求认知这一关才算真正闯过去。3. 测试模型的选型与组合等价类、边界值、决策表、状态转换、场景法各管哪一段需求拆完下一步是建模。很多人听到“测试模型”四个字就觉得是高大上的数学公式其实没那么玄。测试模型就是用一种结构化的方式把测试数据、测试条件和测试行为组织起来让你能低成本地把所有该测的东西都考虑到。3.1 五类常用测试模型的适用场景对比我先把最常用的五类模型放进一张表后面再逐个展开模型核心思路适合的需求类型典型产出等价类划分把海量输入数据按“同等测试效果”分组输入框、参数校验、数据格式有效/无效等价类表边界值分析重点盯临界点附近的数据数值范围、长度限制、时间窗口边界值用例集决策表列出所有条件组合与对应动作多条件多动作的业务规则条件-动作决策表状态转换描述状态迁移路径与触发事件流程性、状态机类需求状态转换图和状态表场景法从用户视角串联完整业务流程端到端业务流程、主路径备选路径场景树3.2 等价类和边界值一对最容易被误用的小伙伴等价类划分的逻辑很好懂如果输入“北京”“上海”“广州”对系统来说都是“符合格式的城市名”并且处理方式一样那这三个数据就算同一个等价类选一个代表测就够。但实际工作中我见过两个常见误区。第一个误区是只划分有效等价类不划分无效等价类。比如手机号输入框有效等价类是11位数字无效等价类必须包括10位数字、12位数字、含字母、纯符号、为空。无效等价类才是缺陷扎堆的重灾区很多人测完有效数据就交差结果数据库里混进一堆脏数据。第二个误区是把等价类和边界值割裂开。其实边界值是等价类的延伸专门盯着每个等价类的“边缘”看。一个范围是1到100的输入框光测1和100根本不够必须测0、1、2、99、100、101六个点分别对应下边界外、下边界、下边界内、上边界内、上边界、上边界外。你说0和101看起来和1、100差别不大程序员的判断条件写错一个等于号差别就大了。我有一次测一个抽奖活动规则写得清清楚楚“每人每天限抽3次”开发也说自己加了判断结果我测第4次抽奖还能成功。后来一查判断条件写成了“3”第4次才拦第3次之后那一下没拦住。这种bug只有边界值分析才能抓出来。3.3 决策表多条件组合下不会再“漏组合”当需求里有三个以上条件互相影响时等价类和边界值就不够用了。这时候我会启用决策表。决策表的做法是把所有条件的真假组合都列出来再填上每个组合下系统该做什么动作。三、四个条件的组合数量就是2的几次方比如3个条件有8种组合4个条件有16种手工凑很容易漏表格一列一比对逻辑空洞立刻显形。真实案例用过一次就上瘾。某个审批系统的需求描述是“金额大于5000需部门主管审批金额大于50000还需财务总监审批如果属于紧急采购可先执行后补审批。”光看这句话你能快速摸清几种处理路径我列了张决策表条件包括金额档位、是否紧急、审批链是否完整一共列出来六种组合其中有一种组合是“紧急采购但金额超过50000”——按需求应该先执行后补审批但开发实现时漏了这个分支直接走了拒绝流程。这种分支逻辑用决策表推一遍就能发现纯靠写用例靠脑袋空想要漏到猴年马月。3.4 状态转换模型流程性需求的最佳拍档带状态流转的系统比如工单系统、订单系统、审批流用状态转换模型来设计测试用例效果远好于一条条列用例。做法分三步第一步把所有状态列出来比如待支付、支付中、已支付、已取消、已退款第二步列出能触发状态变化的“事件”比如支付成功回调、支付超时、用户取消订单第三步画一张状态转换表把每个状态下发生每个事件后跳转到哪个状态填进去——这个动作本身就能暴露出很多逻辑漏洞。什么漏洞比如“已取消”状态下如果用户又发来支付成功回调系统该去哪正确做法是转“已取消”并触发退款但如果状态表里这个格子是空的说明开发根本没处理这种情况。这种用例你不建模就永远想不起来要测。状态转换模型还有个额外优点它能帮你生成回归用例因为状态迁移路径一旦变化影响范围一眼就能圈出来。3.5 场景法把分散用例串成用户旅程单个用例测的是“点”场景法测的是“线”和“面”。我一般把场景法放在最后用等前面的模块级用例都设计完了再打开脑洞从用户视角把交互串起来。以一次网上购物为例场景树可以画成主场景登录 - 搜索 - 加购 - 结算 - 支付 - 收到确认备选场景1结算时发现收货地址不完整提示补齐后再支付备选场景2支付途中网络中断恢复后继续支付备选场景3支付成功后取消订单走退款流程备选场景4库存不足导致订单拆分部分发货异常场景支付结果未知系统处于“处理中”需要靠对账任务补偿场景法最大的价值在于暴露数据流在不同模块间传递时的一致性这种问题单测覆盖面再全也发现不了。4. 从需求到模型的完整推导一个登录与结算模块的真实建模演练理论讲完我拿一个虚构的某电商App的“登录结算”模块来完整演示一遍推导过程。这份需求你可能看着眼熟因为我故意把现实中好几个项目的常见细节缝在了一起。需求原始描述是这样的用户使用手机号加验证码登录登录后可领取新人立减券结算时系统自动计算优惠优惠后的金额不低于1分钱才能支付。4.1 第一步需求拆解得到测试纲领这句话我拆出了下面这些规则条目编号规则描述补充理解风险备注R1手机号格式需合法11位1开头第二位3-9格式判断是否严格R2验证码有效期5分钟超时验证码不可用过期后提示是否明确R3验证码错误5次锁定锁定5分钟滑动验证码是否介入R4新人立减券仅限首单按手机号判定换设备登录能否绕过R5立减券金额取整规则四舍五入保留两位与原有优惠优先级R6优惠后金额不足1分钱不可支付系统自动拦截拦截提示是否明确这张表就是后面所有测试模型的“输入源”。4.2 第二步逐条建模等价类和边界值建模面向手机号输入框我划了这些等价类有效等价类11位且第二位为3-9的数字串无效等价类10位数字、12位数字、11位但第二位为1或2、含字母、全符号、空值边界值第二位为2和3的边界、第二位为9和10的边界、总长度10/11/12位边界面向验证码输入框边界值是“第5次错误”这个点因为在第5次提交错误验证码时系统是否锁定锁定后是否提示剩余时间测试用例必须覆盖“刚好第5次”和“第6次尝试时被拒绝”。决策表建模结算优惠逻辑可以列一张决策表。条件项包括是否为新人首单是否有立减券是否命中其他平台券优惠后金额是否小于0.01元。我列出关键组合新人首单有立减券有平台券优惠后金额0.01系统动作是是是是拦截支付提示“订单金额异常”是是是否正常支付立减券先算是是否是拦截支付提示券金额超限是否是否正常支付只享平台券否是是否立减券不生效平台券生效这五条是排除了大量重复组合后留下的关键路径。第五行特别值得注意——新人立减券判定为“非首单”时不生效但很多开发会在这种情况下把优惠券悄悄吃掉用户感知不到这里必须专门设计用例。状态转换建模登录验证码模块的状态我画成待发送、已发送未验证、已验证通过、已锁定。触发事件是发送验证码、提交验证码、验证码错误、错误达到5次、锁定时间结束。其中有一个格子特别容易出问题——“已锁定”状态下再发验证码系统是直接拒绝还是允许重新发送从业务角度看锁定的目的是防刷重新发送就绕过了锁定限制这属于必须拒绝的场景。这种用例不靠状态表根本想不起来写。场景法建模场景1主流程输入正确手机号 - 获取验证码 - 输入正确验证码 - 登录成功 - 领取新人立减券 - 下单结算 - 自动抵扣 - 支付成功。场景2验证码超时 - 重新获取 - 登录成功。场景3连续输错4次 - 第5次输错 - 系统锁定 - 等待解锁后重新获取验证码 - 登录成功。场景4结算时立减券抵扣后金额小于1分钱 - 系统拦截 - 用户更换支付方式仍拦截 - 客服介入调整。异常场景验证码短信发送接口超时 - 用户点击发送无响应 - 提示重试 - 重试成功后继续流程。场景4这类用例非常考验需求认知因为需求文档里只写了“优惠后金额不低于1分钱才能支付”但真实用户遇到这种场景会怎么操作换支付方式、换账号、反复进入结算页这一串动作都是要从用户视角补出来的。4.3 第三步把模型转成用例矩阵我习惯最后汇总成一张覆盖矩阵横轴是需求条目编号纵轴是设计出来的用例每个用例对应打钩。这么做的目的是查漏任何一个需求条目下没有任何用例挂钩它就是漏测点任何一条用例挂不上任何需求条目它就是冗余用例。有一次我靠这张矩阵删掉了整个模块百分之十五的冗余用例回归工作量降了一截这算是建模带来的附加收益。5. 模型落地时最容易踩的三个坑和我的处置习惯5.1 过度建模模型是服务用例的不是反过来我见过有人把状态转换图画了七八张决策表列了四十多行最后用例却没写几条。这属于典型的“为建模而建模”模型的产出脱离了实际的测试目标。我的判断标准很简单模型值不值看它能不能导出比凭感觉写case更多的有效用例。如果一个等价类划分导致每条用例之间没有任何行为差异那这个等价类就是废话如果一张决策表导出的组合一半是业务上不可能发生的那这张表就该裁剪。建模是为了让测试设计更高效不是为了让文档看起来更厚。5.2 需求变更后模型没跟着变这是最现实的问题。需求在迭代过程中反复调整但大部分人的习惯是“改一条用例算一条”根本不动原始模型。结果两周后需求改了三次模型还是最初那版后面新增的用例挂在空中覆盖关系彻底断裂。我现在的做法是需求变更时先改模型再改用例。比如折扣规则从“全场95折”变成“全场95折但生鲜品类不参与”我不急着去翻用例先把决策表里的条件项改掉再根据新模型重新推一遍用例矩阵该加的和该删的自动浮出来。这套流程看着多花了时间实际反而省时因为你不必花几小时改几十条用例后再发现逻辑本身就是错的。5.3 模型覆盖率自检每个月都推倒重来一遍模型也是会“过期”的特别是一个模块上线跑了大半年之后。沉淀下来的用例越来越多但新来的测试很难从上千条用例里看出这个模块到底被测到了什么程度。我每隔一段时间会做一次“模型逆向还原”——把现有用例反向归拢回等价类、决策表、状态图看看哪些地方用例扎堆哪些分支场景完全没覆盖。这个动作执行过一次你就知道大量“历史回归用例”其实在测同一个等价类而真正没被覆盖的边界和状态迁移反而被埋在了角落。逆向还原出来的模型和当初设计的模型对照差异部分就是最值得补用例的地方。5.4 两个实战小动作最后分享两个我自己一直在用的小动作。第一个是半小时模型评审每个迭代提测前找个会议室把决策表和状态转换表投影出来叫上开发、产品一起过一遍重点看有没有“条件组合被漏掉”和“状态迁移路径缺失”。这个会基本每次都能挑出问题成本只有半小时比缺陷上线后再返修节省太多。第二个是回归增量分析凡是涉及流程改造的需求上线后我除了跑全量回归还会专门把“受影响的旧状态”和“新增的状态”之间的迁移路径翻出来重测一遍。流程类需求最容易出的回归缺陷就是新旧状态之间的桥接没做好——旧逻辑以为没有新状态新逻辑以为旧状态不存在两边一交叉就出鬼故事。这行干得越久我越觉得“认识测试需求”和“设计测试模型”这两件事某种程度上比执行本身更重要。用例跑得再多也没有在一个正确模型指导下跑十条来得有价值。我自己的亲身体会是最好在项目刚启动时就逼着自己把需求拆成规则、把规则变成模型、把模型变成覆盖矩阵——这个过程越早做后面返工越少。
阅读完成 · 觉得有帮助？
