做了这么多年测试我见过太多人写用例时盯着需求文档发呆然后凭感觉刷刷刷列出一堆用例评审会上被追问两句就底虚。测试用例这东西看起来就是“前置条件 操作步骤 预期结果”可为什么不同人写出来的用例质量和数量能差出好几倍核心差异不在手速而在有没有一套能复用的设计思路。这篇文章想分享的东西很明确一套万能思路加六种设计用例的方法。万能思路负责让你面对任何功能时都有章法知道先干什么、后干什么六种方法负责在具体环节把用例设计得又全又精。文中所有方法都会围绕同一个“登录功能”实例展开配图解和可直接抄的用例模板。适合两类人看一是刚入行的测试新人脑子里对用例没有体系二是做了两三年但写用例一直靠感觉的功能测试工程师想把方法论补起来。1. 测试用例设计的万能思路1.1 底层逻辑先回答三个问题很多测试同学拿到需求就急着打开Excel其实这是本末倒置。用例设计的底层逻辑永远是用三个问题驱动的。第一个问题测什么。也就是这个功能模块有哪些输入项、输出项、业务规则、状态流转、外部接口。拿登录功能来说测什么绝不只是“账号密码能不能登进去”还包括验证码是否有效、失败次数和锁定策略、记住我是否生效、日志是否正确记录、是否支持回车提交、密码在传输和存储过程中是否安全等。这些维度不梳理清楚后面写用例就是无源之水。第二个问题怎么测。针对每一个测试点应该选择哪种设计方法。输入项通常用等价类和边界值业务流程用场景法多条件规则用判定表多因子组合用正交试验历史缺陷和经验场景用错误推测法。不是每个测试点都要套所有方法而是根据测试点的特性选最合适的方法这才是“万能”的真正含义。第三个问题测到什么程度算够。也就是覆盖率的判定标准。这里的覆盖率不只是代码覆盖率而是需求点、分支、边界、异常路径、业务规则这几个维度的覆盖。一个业务规则复杂的功能如果只覆盖了主流程和几个常见分支那明显是不够的反之一个简单展示页面非要把像素间距都写成用例那又过度设计。用例不是越多越好也不是越细越好而是要和风险等级、业务影响面匹配。这三个问题想清楚了案例设计才会有一个可靠的骨架。骨架稳定了用哪种方法、怎么填充血肉都是顺理成章的事。1.2 六步建模流程从需求到用例的套路在我自己的实践中会把用例设计固化成六步流程。这个流程几乎适用所有功能测试场景所以管它叫“万能思路”也不夸张。第一步需求拆解。把需求文档里的自然语言转化成可验证的测试点列表。重点抓三样数据规则、业务逻辑、异常处理。数据规则比如用户名长度限制、密码组成要求业务逻辑比如登录成功后跳转、失败后提示异常处理比如网络超时、服务端异常。第二步输入与输出建模。找出所有输入项划分有效和无效等价类标记边界值。同时把每个操作对应的预期输出整理清楚。这一步是等价类和边界值方法的主战场。第三步业务流程建模。画出正常路径和异常路径识别基本流和备选流。一个用户从进入页面到离开页面中间有多少条路可走每一条路上有哪些判断节点。这是场景法的主战场。第四步规则与组合分析。当多个条件之间存在制约关系或不同组合会产生不同结果时用判定表或正交试验来覆盖。登录功能里用户名、密码、验证码、账号状态就是典型的条件组合。第五步经验补漏。结合历史bug、用户习惯、安全风险和易用性问题主动补充那些方法论覆盖不到的场景。比如弱口令、SQL注入、重复提交、复制粘贴等情况。第六步组织成用例。把前五步得到的测试点整理成标准用例补充优先级、前置条件、测试数据、预期结果并做交叉评审。这一步更考验对用例结构的把握。这六步不是线性走完就结束实际项目中经常需要来回迭代。比如在组织用例时发现业务规则理解有歧义就要回头找产品确认再更新前面的建模结果。思路引导方向方法保证精度流程保证不漏这三点合起来就是万能思路的全部秘密。1.3 贯穿全文的实战锚点登录功能需求为让后面的方法拆解不悬空我先把本文反复使用的登录功能需求写下来。这是一个非常常见的B端后台登录需求具备足够的代表性。用户名规则6至16位字符只能包含英文字母和数字必填。密码规则8至20位字符至少包含一个字母和一个数字必填。验证码4位数字5分钟内有效输入错误3次后图片刷新。登录失败策略连续失败5次账号锁定30分钟锁定期间不可登录。记住我勾选后30天内免登录。登录成功跳转首页显示用户昵称。其他支持回车键提交提供忘记密码入口安全要求密码不能是明文存储。有了这个锚点后面讲每一种方法时我都会回到登录功能上做一次演练。这样读者看到的是一个完整闭环而不只是方法概念。2. 六种核心用例设计方法逐一拆解2.1 等价类划分法把输入世界一分为二等价类划分法的核心思想是对无限输入进行无限输入进行分类从每类中取出一个代表性数据进行测试。前提假设是同一类输入对程序的处理是等价的测了其中一个就相当于测了整个类。这个方法最擅长处理输入框、参数、数据范围等场景。具体操作分三步先找出全部输入条件再为每个条件划分有效等价类和无效等价类最后为每个等价类生成一个用例。有效等价类是指符合需求、程序能正确处理的输入无效等价类是指不符合需求、程序应当给出错误提示的输入。用图解来表示输入条件用户名长度 6~16 位 无效类 有效类 无效类 [0~5位] [6~16位] [17位及以上] | | | 提示错误 正常校验 提示错误更常见的是多个无效等价类。比如用户名“只能包含字母和数字”那无效类就至少包括含特殊字符、含中文、含空格、空值、超长、过短等好几类。这里有个非常关键的原则每个无效等价类要单独设计用例不要多个无效类拼在一条用例里。原因是程序往往在遇到第一个非法输入时就报错跳出后面的非法输入根本没机会被执行到。比如用户名填了中文、密码填了不及格式系统在用户名校验时就已经拦截了密码那个无效类实际上没被覆盖。刚开始接触用例设计的人特别容易在这上面翻车。回到登录功能用户名的有效等价类是“6至16位字母数字组合”无效等价类包括小于6位、大于16位、包含特殊字符、包含中文、空值。密码的有效等价类是“8至20位且包含字母和数字”无效类包括小于8位、大于20位、纯字母、纯数字、空值。验证码的有效等价类是“4位数字且未过期”无效类包括非4位、含字母、已过期、空值。等价类划分法最大的优点是能把无限输入简化为有限几类缺点是它只关注输入本身不关注输入之间的关系和业务规则。所以它通常要配合边界值法和其他方法一起用。2.2 边界值分析法bug最爱的边界地带如果说等价类划分是在“圈范围”那边界值分析就是在“抠边界”。大量实践证明程序最容易出错的地方不是范围的中间而是范围的边界附近。一个允许6到16位的字段7位和15位通常没什么事5位和17位最容易出问题。要么前端校验规则写错位数要么后端用的校验逻辑和前端不一致导致边界条件两边各管一段。边界值分析的基本思想很简单取边界上和边界两边的值作为测试数据。对长度6到16的规则来说需要覆盖的最小边界是6和16边界附近的最小值是7和15边界外是5和17。如果再规范一点还需要取一个范围内的正常值比如10用来确认正常情况没有误伤。图解更直观长度限制6~16 位 边界外 |--------有效区间--------| 边界外 5 6 7 ... 15 16 17 无效 有效 有效 有效 有效 无效 min max等价类和边界值经常成对出现。我的习惯是先划分等价类再根据等价类的边界来补充边界用例。注意两件事一是边界值不局限在长度上数值范围、时间范围、金额范围、次数上限都有边界二是除了输入边界输出边界也一样要测比如分页结果第一页和最后一页、金额刚好等于最大值等情况。登录功能里可以测的边界相当多。用户名长度为6位和16位验证码输入3次整连续失败4次后登录成功、连续失败第5次触发锁定锁定时间最后一分钟登录仍然失败、刚过30分钟登录成功。这些都是教科书级别的边界场景。坦白说边界值法是我们测试工作中投入产出比最高的方法之一十个功能bug里面有四五个都藏在边界上。只要需求里出现“大于、小于、最多、最少、不低于、不超过”这类词请条件反射一样列出边界值和边界外值。2.3 场景法从用户真实操作路径出发前面的等价类和边界值都是针对单个输入的但用户在实际使用时面对的是完整的一个业务流程。场景法的核心就是跳出单个输入项的视角转而去模拟用户在真实使用过程中的操作序列。场景法依赖“基本流”和“备选流”的概念。基本流是用户完成一个业务目标的最顺利路径没有异常、没有分支备选流是在某个步骤上出现异常或分支后重新回到基本流的路径。比如登录的基本流是打开登录页、输入账号密码验证码、点击登录、进入首页。备选流可能是密码错误、提示错误、用户重输、再次提交成功也可能是验证码过期、刷新验证码、重新填写。用图解表示登录场景---------------- | 打开登录页面 | ---------------- | v ---------------- | 输入账号/密码 | ---------------- | ------------ | | 正确 错误/验证码错误 | | 进入首页 刷新验证码/重新输入 | | -- 回到输入 --注意实际画图时不必画得这么复杂能用文字把基本流和备选流列清楚就足够指导用例设计了。以登录功能为例可以拆出这些场景场景一所有信息正确登录成功并跳转首页场景二用户名错误系统提示并停留在当前页场景三密码错误提示错误并允许重试场景四验证码错误提示错误并刷新验证码场景五连续输错5次账号被锁定30分钟场景六锁定期间再次登录系统提示锁定中场景七勾选记住我登录成功后30天内重新打开网站无需登录场景八点击忘记密码进入找回密码流程并最终能登录成功。场景法特别适合业务流程清晰、用户操作路径固化的功能模块比如电商下单、审批流、开户流程。它和等价类边界值完全不冲突前面的方法管的是“一个字段值对不对”画面法管的是“用户从头到尾走不走得通”。实际设计用例时先用场景法把大流程串起来再用边界值去填每个输入项的细节效率和覆盖率都会好很多。2.4 判定表法多条件组合的规则器很多功能不是单一条件决定的而是多个条件组合决定动作。比如登录时系统要同时判断用户名是否存在、密码是否正确、验证码是否有效、账号是否被锁定。这四个条件不同组合会产生完全不同的结果。如果光靠场景法一个一个蒙很容易漏掉某个组合。判定表法就是专门解决这类问题的。判定表的结构分成条件桩、条件项、动作桩、动作项四部分。条件桩是列出所有可能影响结果的判断条件每个条件用真/假表示具体取值动作桩是列出可能执行的操作或结果动作项则是每个条件组合执行哪个动作。做判定表的步骤是列出所有条件和状态列出所有可能的动作填出所有条件组合对每个组合勾选对应的动作最后合并相同动作的组合删除不可能出现的组合。登录页的登录校验判定表可以简化成四大条件用户名合法、密码正确、验证码正确、账号未锁定。如果全部为真登录成功如果用户名不合法提示“用户不存在”如果密码错误提示“密码错误”连续失败统计加一验证码错误提示验证码错误连续错三次刷新账号锁定提示锁定剩余时间。理论上四个条件真真假假能组合出16种情况用判定表可以把这16种情况全部列出来再进一步简化合并。实际设计时不需要把16个组合都写成测试用例只需要覆盖动作不同的那些组合。判定表真正的价值就在这里它强迫你穷举然后再有策略地取舍这个过程的顺序不能反。先穷举是防止漏后取舍是防止过度设计。很多同学一上来就凭感觉挑组合结果往往漏掉“用户名正确、密码正确、验证码正确、账号正好被锁定”这种虽然少见但确实需要处理的组合。判定表适合条件少且条件之间有逻辑关系的场景一般三到五个条件最合适。条件超过五个组合数爆炸式增长判定表会变得极其庞大这时候该换成正交试验法。2.5 正交试验法用最少组合覆盖最多因子当功能涉及多个因子、每个因子又有多个取值时全组合测试往往不现实。假设登录方式有密码登录、扫码登录、验证码登录三种同时还要在Web端、App端、小程序端运行还要考虑网络环境2G、4G、WiFi全组合就是3乘3乘3等于27种。这还只是一个不太复杂的场景现实中一个查询功能配上十几个筛选条件全组合数量能吓死人。正交试验法的思路是从全组合中挑选出一部分有代表性的组合进行测试这些组合彼此之间覆盖了各个因子和取值的两两组合。它的数学基础是正交表常见的正交表有L4(2^3)、L8(2^7)、L9(3^4)、L16(4^5)等。L9(3^4)表示最多支持4个因子每个因子有3个取值总共只需要9次试验而全组合是3的4次方等于81次。实际使用时不要求自己推导正交表可以直接查现成的正交表表格。比如一个登录功能要有4个因子终端类型Web、App、小程序、登录方式账号密码、手机验证码、扫码、网络2G、4G、WiFi、账号类型普通用户、VIP、管理员每个因子3个水平套用L9(3^4)后只需要9条用例就能覆盖任意两个因子各个水平之间的两两组合。L9(3^4) 正交表示意 编号 | 因子1 | 因子2 | 因子3 | 因子4 1 | 1 | 1 | 1 | 1 2 | 1 | 2 | 2 | 2 3 | 1 | 3 | 3 | 3 4 | 2 | 1 | 2 | 3 5 | 2 | 2 | 3 | 1 6 | 2 | 3 | 1 | 2 7 | 3 | 1 | 3 | 2 8 | 3 | 2 | 1 | 3 9 | 3 | 3 | 2 | 1正交试验法的前提是因子之间相互独立没有明显的逻辑制约关系。若存在条件互斥比如“忘记密码后要通过验证码重置此时账号锁定状态可以忽略”正交表就无法直接套用需要手工调整或改用判定表。这个方法在兼容性测试、配置验证、多参数接口测试中特别常用。合理使用以后最大的收获是从“测不完”变成了“在你重点覆盖的前提下测完”那种深不见底的焦虑感会明显减少。2.6 错误推测法经验主义的有效补漏错误推测法是最不像方法的方法。它不依赖什么建模套路而是依赖测试人员的经验、直觉和对历史缺陷的积累。说白了就是针对那些“这里很可能出错”的地方主动设计用例。很多刚入行的人觉得这个方法太虚实际上它是资深测试人员和普通测试人员的核心差距之一。比如说登录框有经验的人会主动补上这些用例密码框用星号掩码展示输入前后两端带空格系统是否自动去除用键盘回车能否提交弱密码如123456、admin能否提示修改常见SQL注入写法是否被拦截密码是否允许明文出现在页面源码或请求中多次快速点击登录按钮是否产生重复提交浏览器后退和前进是否导致重复提交表单。这些用例靠等价类边界值根本推不出来因为它们不是从输入规则出发而是从“现实世界会发生什么奇怪操作”“历史bug最容易出现在哪里”“攻击者会怎么试探”出发。我的建议是每个测试团队都要建立一份属于自己的错误推测清单谁在项目里踩到过什么坑就更新进去。时间一长这份清单比任何方法论的威力都大。错误推测法不是用来替代前面五种方法的它们的关系更像是防守型球员。等价类、边界值、场景法、判定表、正交试验解决的是“系统性地覆盖已知可能性”错误推测法解决的是“把未知可能性也堵住一部分”。一套完整的用例良好的组成方式是前面五种方法跑出80%的覆盖错误推测法在剩余20%的边界场景、安全隐患和经验场景里补刀。3. 实战演练一个登录功能的完整用例设计3.1 需求梳理与测试点拆解现在把万能思路完整跑一遍跑的对象就是前面定义的登录功能。第一步先把需求里的测试点拆成可执行的清单。我习惯拆成六类输入校验、交互逻辑、安全策略、状态管理、异常处理、兼容体验。输入校验包括用户名必填、格式、长度密码必填、格式、长度验证码必填、格式、有效期。交互逻辑包括登录按钮点击后的加载态、点击回车是否能提交、错误提示展示位置和自动消失等。安全策略包括密码是否掩码、是否明文传输、连续失败锁定策略、验证码输错3次刷新。状态管理包括记住我是否生效、登录态过期后跳转、账号锁定倒计时。异常处理包括接口超时、服务端500、断网重连。兼容体验包括主流浏览器、不同分辨率、Web端和移动端适配。拆测试点这一步非常关键它是所有后续方法的地基。如果拆得不全后面六种方法用得再熟练也白搭。判断拆全没有我有一个土办法把自己当成一个第一次用这个功能的用户从注册账号开始到登录、退出、忘了密码、被锁定、换设备重新登录从头走一遍流程一边走一边记录每一步会发生什么哪些地方可能出错。这比单纯看需求文档不容易漏。3.2 六种方法如何配合使用测试点拆完之后下一步是把每一类测试点分配到最合适的方法上而不是把所有方法全抛上去。我从实际操作中验证过的分配方案是这样的。输入校验类测试点用等价类加边界值。用户名和密码每一类输入规则都划分有效类和无效类然后在长度边界上补齐数据。验证码在格式和有效期两个维度上做等价类和边界值覆盖。交互逻辑类测试点主要用场景法。把从进入页面到登录成功的整个过程建模成基本流和备选流把回车提交、点击刷新验证码、错误提示消失这些交互放在关键路径的节点上。安全策略类测试点先用判定表把用户名、密码、验证码、锁定状态四个条件组合列出来看看每种组合下系统的动作是否符合预期。锁定策略的具体数值再交给边界值处理比如第4次失败和第5次失败。状态管理类测试点主要靠场景法加错误推测法。记住我、锁定期限、登录态过期这几个状态需要用场景串起来同时补充一些异常状态比如记住我登录后在服务端重置密码原登录态是否立即失效。异常和兼容类测试点核心是错误推测法加少量正交试验。断网、超时、重复点击这些靠经验补充浏览器和终端组合可以用正交试验压缩测试量。看到没有这五种方法不是排排坐每个都要写一遍而是各管一块。对输入框多的页面等价类边界值是主力对流程长的模块场景法是主力对规则复杂的后台配置判定表是主力。这种“看菜下饭”的选择能力才是万能思路里“万能”二字的真正含义。3.3 最终测试用例清单节选标准测试用例字段包括用例编号、所属模块、用例标题、优先级、前置条件、测试步骤、测试数据、预期结果。下面节选几条登录功能的用例展示实际落地效果。用例编号用例标题优先级前置条件测试步骤测试数据预期结果TC-LOGIN-001输入合法用户名密码验证码登录成功P0已注册账号验证码可正常获取1.打开登录页 2.输入用户名密码 3.输入验证码 4.点击登录用户名testuser01密码abc12345验证码1234提示登录成功跳转首页并显示用户昵称TC-LOGIN-002用户名长度小于6位P1无1.打开登录页 2.输入5位用户名 3.输入合法密码和验证码 4.点击登录用户名user5密码abc12345验证码1234用户名输入框下方提示“用户名长度需为6-16位”不提交请求TC-LOGIN-003用户名长度为17位P1无同TC-LOGIN-002用户名user123456789abcd密码abc12345验证码1234同上提示长度不合法TC-LOGIN-004密码为纯数字P1无1.打开登录页 2.输入合法用户名 3.输入纯数字密码 4.输入验证码 5.点击登录用户名testuser01密码12345678验证码1234提示“密码需包含字母和数字”TC-LOGIN-005验证码错误后登录失败P1验证码已加载1.输入合法用户名密码 2.输入错误验证码 3.点击登录用户名testuser01密码abc12345验证码0000提示“验证码错误”停留登录页TC-LOGIN-006连续失败4次后第5次成功P1账号未锁定1.连续4次输错密码 2.第5次输入正确密码第5次使用正确密码第5次登录成功无锁定提示TC-LOGIN-007连续失败5次触发账号锁定P0账号未锁定1.连续5次输错密码每次密码均错误第5次提交后提示“密码错误次数过多账号锁定30分钟”TC-LOGIN-008锁定期间尝试登录P0账号已锁定1.锁定期间打开登录页 2.输入正确用户名密码和验证码正确凭证提示“账号已锁定请30分钟后再试”不能登录TC-LOGIN-009验证码输错3次后刷新P1验证码图片正常显示1.连续输错3次验证码3次验证码均错误第3次提交后验证码图片自动刷新原有验证码失效TC-LOGIN-010勾选记住我登录P1用户已登录过1.勾选记住我 2.登录成功后关闭浏览器 3.30天内重新打开站点正确凭证无需重复登录自动进入首页TC-LOGIN-011密码请求中是否明文传输P0抓包工具就绪1.打开页面 2.输入账号密码和验证码 3.点击登录 4.抓取提交请求用户名testuser01密码abc12345请求中密码字段加密或不可明文识别页面源码不出现明文密码TC-LOGIN-012用户名包含SQL注入字符P1无1.输入“admin or 11”等注入字符 2.输入任意密码和验证码 3.点击登录用户名admin or 11系统无异常不登录成功提示用户不存在或账号错误实际项目中登录功能这种规模的需求完整用例大概在40到60条之间。上面节选的12条只是展示格式和设计思路。重点在于每一条用例都可以追溯到需求或风险点评审被人问“为什么写这条用例”时你能明确说出理由这才是用例设计的健康状态。4. 常见问题与排查技巧实录4.1 用例设计中最常见的五个误区误区一是只喜欢测正常路径。团队里总有测试伙伴拿到需求后一口气写了十几条“输入正确数据、系统正常处理”的用例异常情况一条没有。看不清哪个环节出了问题。正常的流程要测但一个经得起推敲的用例库异常用例通常比正常用例多一倍。程序出问题往往就在“没想到用户会这样操作”的地方。误区二是无效等价类合并成一条用例。前面已经强调过一个无效等价类对应一条用例不合并的理由很实在程序遇到第一个非法输入就会终止后续逻辑。把两个无效类合并第二个无效类根本没有被执行用例等于白写。误区三是不写前置条件和测试数据。有些同学写的用例步骤只有“点击登录、查看结果”看起来精简执行时每一轮都要临时猜数据不同的测试人员还会猜出不同结果。用例是团队资产不是个人备忘录。前置条件、数据、预期结果必须明确甚至可以给关键数据命名比如“已锁定账号LOCKED_USER”方便自动化和回归测试复用。误区四是想把所有方法都用上。我刚带新人那会儿经常看到有人对一个简单按钮硬生生拆出等价类、边界值、判定表、正交试验最后写了几十条例把简单问题复杂化。方法是为目的服务的一条用例能说清楚的事情不要拆成三条。设计到什么粒度要按功能复杂度和风险等级来定一个纯展示页面核心路径加边角异常就足够。误区五是不维护用例。需求一变更最怕听到“旧的先不管了把新功能用例写了”。测试用例和代码一样需要持续维护。需求变了用例不更新不仅有回归遗漏风险还会让团队慢慢失去对用例库的信任最后大家都不看用例测试就变成了凭感觉做事。我现在每个迭代会把用例库维护当成测试任务的一部分变更了哪些功能同步更新哪些用例在迭代验收时严格检查。4.2 用例评审时最容易吵起来的三个问题用例评审是测试质量的一道重要关卡但真正开评审会时大家经常会为三个问题争论不休。第一个问题“这条用例该不该写”。产品觉得某条异常场景根本不可能发生开发觉得某条边界值验证没有意义测试觉得有风险必须覆盖。这种分歧的根源是风险认知不同。我现在的处理方式是先摆出这条用例对应的是哪个需求点或历史缺陷如果都摆不出来说明可疑暂缓如果能摆出来就按风险等级决定去留。以数据和事实说话而不是按职位高低或嗓门大小判断。第二个问题“覆盖率多少才算够”。这是一个没有标准答案的问题硬要验收只能靠代码覆盖率工具但用例覆盖率和代码覆盖率从来不是一回事。我的判断标准很简单核心业务流程必须有场景覆盖所有输入规则必须有等价类和边界值覆盖所有业务规则必须有判定表或场景覆盖历次缺陷回归必须有对应用例。四类覆盖都齐了覆盖率就算达标。这个口径一般在项目启动时就对齐不要等到评审时再吵。第三个问题“用例归谁维护、自动化脚本归谁写”。这个问题看上去是分工问题实际是工程化问题。我经历过最混乱的阶段是测试人员手工维护Excel用例自动化工程师另维护一套脚本用例两边内容不一致执行结果对不上。后来我们统一把用例和自动化脚本关联用例作为唯一入口脚本挂载在用例下需求和用例变更走同一套流程情况才有好转。现在很多团队在推的harness工程化本质上也是解决这个关联问题让用例、数据、脚本、执行结果形成一个闭环。4.3 关于AI辅助生成测试用例的几点看法AI生成测试用例最近热度很高也有不少团队开始尝试通过AI根据PRD生成功能测试用例甚至让AI自动写用例并执行自动测试。作为一个真实项目里跑过AI辅助生成用例的测试人员我聊点实际操作感受。先说结论AI能把用例设计的效率提升30%到50%但还远不能完全替代测试人员的设计判断。拿登录功能举例把上面的需求描述扔给一个训练有素的AI它能够很快输出等价类、边界值、场景法甚至是判定表结构的用例格式规范字段齐全初看完全可以拿去评审。但细看就会发现几个问题一是它会照抄需求需求文档没写清楚的业务规则它不会自行弥补二是它能穷举常见组合但缺乏对业务本质的理解比如登录成功后部门数据权限范围是否正确这类深挖逻辑它就想不到三是它在错误推测法相关场景上比较弱SQL注入、越权、并发重复点击这类安全用例往往需要人再补一道。因此我的实践方法是让AI做“初稿生成器”而不是“终稿输出器”。具体流程是需求文档先喂给AI让它拆解测试点并生成基础用例我基于测试点拆解结果补充业务逻辑和异常场景再把补充后的用例回给AI进行格式化和组合补齐最后由测试负责人评审定稿。这个流程实践下来最舒服的不是AI生成了多少条能用的用例而是它把那些格式规范、必然覆盖的基础输入校验用例写完以后我可以把精力投在更具价值的业务规则分析和错误推测上。另外我注意到AI结合代码review和harness工程化也是一个值得尝试的方向。用例不只在评审时起作用它还可以直接驱动自动化测试框架执行执行失败时自动关联用例和日志形成一个“用例设计、代码审查、测试执行、结果反馈”的闭环工具链。AI生成用例后自动落到这个链路里减少手工搬运整个效率提升就很明显。不过AI生成用例也有一个隐患它会产生“看似穷尽的错觉”。人会因为知道自己漏了什么而心虚AI生成的一大堆用例反倒可能让团队误以为覆盖很完整从而放松了对业务深逻辑的推敲。所以我始终强调一句话AI解决的是效率和规范问题需求和业务的理解、关键场景的判断最终还得靠人来承担责任。把AI当成一个高效的初稿助手把测试工程师的精力聚焦到AI不擅长的那些深度判断上这才是当前阶段最务实的用法。踩过几次坑之后我现在设计用例的习惯已经非常固定了。拿到任何需求先不急着写用例把测试点拆清楚再根据测试点的特性选择两三种主要方法辅助方法做补充最后再花时间把历史缺陷和异常场景过一遍。这样写出来的用例评审时被质疑的底气都足很多。这个习惯我建议你可以在下个项目里试试不用多试两次就会发现写用例这件事真的不靠天赋靠的是思路和方法。
测试用例设计万能思路：六种核心方法助你打造高质量用例
做了这么多年测试我见过太多人写用例时盯着需求文档发呆然后凭感觉刷刷刷列出一堆用例评审会上被追问两句就底虚。测试用例这东西看起来就是“前置条件 操作步骤 预期结果”可为什么不同人写出来的用例质量和数量能差出好几倍核心差异不在手速而在有没有一套能复用的设计思路。这篇文章想分享的东西很明确一套万能思路加六种设计用例的方法。万能思路负责让你面对任何功能时都有章法知道先干什么、后干什么六种方法负责在具体环节把用例设计得又全又精。文中所有方法都会围绕同一个“登录功能”实例展开配图解和可直接抄的用例模板。适合两类人看一是刚入行的测试新人脑子里对用例没有体系二是做了两三年但写用例一直靠感觉的功能测试工程师想把方法论补起来。1. 测试用例设计的万能思路1.1 底层逻辑先回答三个问题很多测试同学拿到需求就急着打开Excel其实这是本末倒置。用例设计的底层逻辑永远是用三个问题驱动的。第一个问题测什么。也就是这个功能模块有哪些输入项、输出项、业务规则、状态流转、外部接口。拿登录功能来说测什么绝不只是“账号密码能不能登进去”还包括验证码是否有效、失败次数和锁定策略、记住我是否生效、日志是否正确记录、是否支持回车提交、密码在传输和存储过程中是否安全等。这些维度不梳理清楚后面写用例就是无源之水。第二个问题怎么测。针对每一个测试点应该选择哪种设计方法。输入项通常用等价类和边界值业务流程用场景法多条件规则用判定表多因子组合用正交试验历史缺陷和经验场景用错误推测法。不是每个测试点都要套所有方法而是根据测试点的特性选最合适的方法这才是“万能”的真正含义。第三个问题测到什么程度算够。也就是覆盖率的判定标准。这里的覆盖率不只是代码覆盖率而是需求点、分支、边界、异常路径、业务规则这几个维度的覆盖。一个业务规则复杂的功能如果只覆盖了主流程和几个常见分支那明显是不够的反之一个简单展示页面非要把像素间距都写成用例那又过度设计。用例不是越多越好也不是越细越好而是要和风险等级、业务影响面匹配。这三个问题想清楚了案例设计才会有一个可靠的骨架。骨架稳定了用哪种方法、怎么填充血肉都是顺理成章的事。1.2 六步建模流程从需求到用例的套路在我自己的实践中会把用例设计固化成六步流程。这个流程几乎适用所有功能测试场景所以管它叫“万能思路”也不夸张。第一步需求拆解。把需求文档里的自然语言转化成可验证的测试点列表。重点抓三样数据规则、业务逻辑、异常处理。数据规则比如用户名长度限制、密码组成要求业务逻辑比如登录成功后跳转、失败后提示异常处理比如网络超时、服务端异常。第二步输入与输出建模。找出所有输入项划分有效和无效等价类标记边界值。同时把每个操作对应的预期输出整理清楚。这一步是等价类和边界值方法的主战场。第三步业务流程建模。画出正常路径和异常路径识别基本流和备选流。一个用户从进入页面到离开页面中间有多少条路可走每一条路上有哪些判断节点。这是场景法的主战场。第四步规则与组合分析。当多个条件之间存在制约关系或不同组合会产生不同结果时用判定表或正交试验来覆盖。登录功能里用户名、密码、验证码、账号状态就是典型的条件组合。第五步经验补漏。结合历史bug、用户习惯、安全风险和易用性问题主动补充那些方法论覆盖不到的场景。比如弱口令、SQL注入、重复提交、复制粘贴等情况。第六步组织成用例。把前五步得到的测试点整理成标准用例补充优先级、前置条件、测试数据、预期结果并做交叉评审。这一步更考验对用例结构的把握。这六步不是线性走完就结束实际项目中经常需要来回迭代。比如在组织用例时发现业务规则理解有歧义就要回头找产品确认再更新前面的建模结果。思路引导方向方法保证精度流程保证不漏这三点合起来就是万能思路的全部秘密。1.3 贯穿全文的实战锚点登录功能需求为让后面的方法拆解不悬空我先把本文反复使用的登录功能需求写下来。这是一个非常常见的B端后台登录需求具备足够的代表性。用户名规则6至16位字符只能包含英文字母和数字必填。密码规则8至20位字符至少包含一个字母和一个数字必填。验证码4位数字5分钟内有效输入错误3次后图片刷新。登录失败策略连续失败5次账号锁定30分钟锁定期间不可登录。记住我勾选后30天内免登录。登录成功跳转首页显示用户昵称。其他支持回车键提交提供忘记密码入口安全要求密码不能是明文存储。有了这个锚点后面讲每一种方法时我都会回到登录功能上做一次演练。这样读者看到的是一个完整闭环而不只是方法概念。2. 六种核心用例设计方法逐一拆解2.1 等价类划分法把输入世界一分为二等价类划分法的核心思想是对无限输入进行无限输入进行分类从每类中取出一个代表性数据进行测试。前提假设是同一类输入对程序的处理是等价的测了其中一个就相当于测了整个类。这个方法最擅长处理输入框、参数、数据范围等场景。具体操作分三步先找出全部输入条件再为每个条件划分有效等价类和无效等价类最后为每个等价类生成一个用例。有效等价类是指符合需求、程序能正确处理的输入无效等价类是指不符合需求、程序应当给出错误提示的输入。用图解来表示输入条件用户名长度 6~16 位 无效类 有效类 无效类 [0~5位] [6~16位] [17位及以上] | | | 提示错误 正常校验 提示错误更常见的是多个无效等价类。比如用户名“只能包含字母和数字”那无效类就至少包括含特殊字符、含中文、含空格、空值、超长、过短等好几类。这里有个非常关键的原则每个无效等价类要单独设计用例不要多个无效类拼在一条用例里。原因是程序往往在遇到第一个非法输入时就报错跳出后面的非法输入根本没机会被执行到。比如用户名填了中文、密码填了不及格式系统在用户名校验时就已经拦截了密码那个无效类实际上没被覆盖。刚开始接触用例设计的人特别容易在这上面翻车。回到登录功能用户名的有效等价类是“6至16位字母数字组合”无效等价类包括小于6位、大于16位、包含特殊字符、包含中文、空值。密码的有效等价类是“8至20位且包含字母和数字”无效类包括小于8位、大于20位、纯字母、纯数字、空值。验证码的有效等价类是“4位数字且未过期”无效类包括非4位、含字母、已过期、空值。等价类划分法最大的优点是能把无限输入简化为有限几类缺点是它只关注输入本身不关注输入之间的关系和业务规则。所以它通常要配合边界值法和其他方法一起用。2.2 边界值分析法bug最爱的边界地带如果说等价类划分是在“圈范围”那边界值分析就是在“抠边界”。大量实践证明程序最容易出错的地方不是范围的中间而是范围的边界附近。一个允许6到16位的字段7位和15位通常没什么事5位和17位最容易出问题。要么前端校验规则写错位数要么后端用的校验逻辑和前端不一致导致边界条件两边各管一段。边界值分析的基本思想很简单取边界上和边界两边的值作为测试数据。对长度6到16的规则来说需要覆盖的最小边界是6和16边界附近的最小值是7和15边界外是5和17。如果再规范一点还需要取一个范围内的正常值比如10用来确认正常情况没有误伤。图解更直观长度限制6~16 位 边界外 |--------有效区间--------| 边界外 5 6 7 ... 15 16 17 无效 有效 有效 有效 有效 无效 min max等价类和边界值经常成对出现。我的习惯是先划分等价类再根据等价类的边界来补充边界用例。注意两件事一是边界值不局限在长度上数值范围、时间范围、金额范围、次数上限都有边界二是除了输入边界输出边界也一样要测比如分页结果第一页和最后一页、金额刚好等于最大值等情况。登录功能里可以测的边界相当多。用户名长度为6位和16位验证码输入3次整连续失败4次后登录成功、连续失败第5次触发锁定锁定时间最后一分钟登录仍然失败、刚过30分钟登录成功。这些都是教科书级别的边界场景。坦白说边界值法是我们测试工作中投入产出比最高的方法之一十个功能bug里面有四五个都藏在边界上。只要需求里出现“大于、小于、最多、最少、不低于、不超过”这类词请条件反射一样列出边界值和边界外值。2.3 场景法从用户真实操作路径出发前面的等价类和边界值都是针对单个输入的但用户在实际使用时面对的是完整的一个业务流程。场景法的核心就是跳出单个输入项的视角转而去模拟用户在真实使用过程中的操作序列。场景法依赖“基本流”和“备选流”的概念。基本流是用户完成一个业务目标的最顺利路径没有异常、没有分支备选流是在某个步骤上出现异常或分支后重新回到基本流的路径。比如登录的基本流是打开登录页、输入账号密码验证码、点击登录、进入首页。备选流可能是密码错误、提示错误、用户重输、再次提交成功也可能是验证码过期、刷新验证码、重新填写。用图解表示登录场景---------------- | 打开登录页面 | ---------------- | v ---------------- | 输入账号/密码 | ---------------- | ------------ | | 正确 错误/验证码错误 | | 进入首页 刷新验证码/重新输入 | | -- 回到输入 --注意实际画图时不必画得这么复杂能用文字把基本流和备选流列清楚就足够指导用例设计了。以登录功能为例可以拆出这些场景场景一所有信息正确登录成功并跳转首页场景二用户名错误系统提示并停留在当前页场景三密码错误提示错误并允许重试场景四验证码错误提示错误并刷新验证码场景五连续输错5次账号被锁定30分钟场景六锁定期间再次登录系统提示锁定中场景七勾选记住我登录成功后30天内重新打开网站无需登录场景八点击忘记密码进入找回密码流程并最终能登录成功。场景法特别适合业务流程清晰、用户操作路径固化的功能模块比如电商下单、审批流、开户流程。它和等价类边界值完全不冲突前面的方法管的是“一个字段值对不对”画面法管的是“用户从头到尾走不走得通”。实际设计用例时先用场景法把大流程串起来再用边界值去填每个输入项的细节效率和覆盖率都会好很多。2.4 判定表法多条件组合的规则器很多功能不是单一条件决定的而是多个条件组合决定动作。比如登录时系统要同时判断用户名是否存在、密码是否正确、验证码是否有效、账号是否被锁定。这四个条件不同组合会产生完全不同的结果。如果光靠场景法一个一个蒙很容易漏掉某个组合。判定表法就是专门解决这类问题的。判定表的结构分成条件桩、条件项、动作桩、动作项四部分。条件桩是列出所有可能影响结果的判断条件每个条件用真/假表示具体取值动作桩是列出可能执行的操作或结果动作项则是每个条件组合执行哪个动作。做判定表的步骤是列出所有条件和状态列出所有可能的动作填出所有条件组合对每个组合勾选对应的动作最后合并相同动作的组合删除不可能出现的组合。登录页的登录校验判定表可以简化成四大条件用户名合法、密码正确、验证码正确、账号未锁定。如果全部为真登录成功如果用户名不合法提示“用户不存在”如果密码错误提示“密码错误”连续失败统计加一验证码错误提示验证码错误连续错三次刷新账号锁定提示锁定剩余时间。理论上四个条件真真假假能组合出16种情况用判定表可以把这16种情况全部列出来再进一步简化合并。实际设计时不需要把16个组合都写成测试用例只需要覆盖动作不同的那些组合。判定表真正的价值就在这里它强迫你穷举然后再有策略地取舍这个过程的顺序不能反。先穷举是防止漏后取舍是防止过度设计。很多同学一上来就凭感觉挑组合结果往往漏掉“用户名正确、密码正确、验证码正确、账号正好被锁定”这种虽然少见但确实需要处理的组合。判定表适合条件少且条件之间有逻辑关系的场景一般三到五个条件最合适。条件超过五个组合数爆炸式增长判定表会变得极其庞大这时候该换成正交试验法。2.5 正交试验法用最少组合覆盖最多因子当功能涉及多个因子、每个因子又有多个取值时全组合测试往往不现实。假设登录方式有密码登录、扫码登录、验证码登录三种同时还要在Web端、App端、小程序端运行还要考虑网络环境2G、4G、WiFi全组合就是3乘3乘3等于27种。这还只是一个不太复杂的场景现实中一个查询功能配上十几个筛选条件全组合数量能吓死人。正交试验法的思路是从全组合中挑选出一部分有代表性的组合进行测试这些组合彼此之间覆盖了各个因子和取值的两两组合。它的数学基础是正交表常见的正交表有L4(2^3)、L8(2^7)、L9(3^4)、L16(4^5)等。L9(3^4)表示最多支持4个因子每个因子有3个取值总共只需要9次试验而全组合是3的4次方等于81次。实际使用时不要求自己推导正交表可以直接查现成的正交表表格。比如一个登录功能要有4个因子终端类型Web、App、小程序、登录方式账号密码、手机验证码、扫码、网络2G、4G、WiFi、账号类型普通用户、VIP、管理员每个因子3个水平套用L9(3^4)后只需要9条用例就能覆盖任意两个因子各个水平之间的两两组合。L9(3^4) 正交表示意 编号 | 因子1 | 因子2 | 因子3 | 因子4 1 | 1 | 1 | 1 | 1 2 | 1 | 2 | 2 | 2 3 | 1 | 3 | 3 | 3 4 | 2 | 1 | 2 | 3 5 | 2 | 2 | 3 | 1 6 | 2 | 3 | 1 | 2 7 | 3 | 1 | 3 | 2 8 | 3 | 2 | 1 | 3 9 | 3 | 3 | 2 | 1正交试验法的前提是因子之间相互独立没有明显的逻辑制约关系。若存在条件互斥比如“忘记密码后要通过验证码重置此时账号锁定状态可以忽略”正交表就无法直接套用需要手工调整或改用判定表。这个方法在兼容性测试、配置验证、多参数接口测试中特别常用。合理使用以后最大的收获是从“测不完”变成了“在你重点覆盖的前提下测完”那种深不见底的焦虑感会明显减少。2.6 错误推测法经验主义的有效补漏错误推测法是最不像方法的方法。它不依赖什么建模套路而是依赖测试人员的经验、直觉和对历史缺陷的积累。说白了就是针对那些“这里很可能出错”的地方主动设计用例。很多刚入行的人觉得这个方法太虚实际上它是资深测试人员和普通测试人员的核心差距之一。比如说登录框有经验的人会主动补上这些用例密码框用星号掩码展示输入前后两端带空格系统是否自动去除用键盘回车能否提交弱密码如123456、admin能否提示修改常见SQL注入写法是否被拦截密码是否允许明文出现在页面源码或请求中多次快速点击登录按钮是否产生重复提交浏览器后退和前进是否导致重复提交表单。这些用例靠等价类边界值根本推不出来因为它们不是从输入规则出发而是从“现实世界会发生什么奇怪操作”“历史bug最容易出现在哪里”“攻击者会怎么试探”出发。我的建议是每个测试团队都要建立一份属于自己的错误推测清单谁在项目里踩到过什么坑就更新进去。时间一长这份清单比任何方法论的威力都大。错误推测法不是用来替代前面五种方法的它们的关系更像是防守型球员。等价类、边界值、场景法、判定表、正交试验解决的是“系统性地覆盖已知可能性”错误推测法解决的是“把未知可能性也堵住一部分”。一套完整的用例良好的组成方式是前面五种方法跑出80%的覆盖错误推测法在剩余20%的边界场景、安全隐患和经验场景里补刀。3. 实战演练一个登录功能的完整用例设计3.1 需求梳理与测试点拆解现在把万能思路完整跑一遍跑的对象就是前面定义的登录功能。第一步先把需求里的测试点拆成可执行的清单。我习惯拆成六类输入校验、交互逻辑、安全策略、状态管理、异常处理、兼容体验。输入校验包括用户名必填、格式、长度密码必填、格式、长度验证码必填、格式、有效期。交互逻辑包括登录按钮点击后的加载态、点击回车是否能提交、错误提示展示位置和自动消失等。安全策略包括密码是否掩码、是否明文传输、连续失败锁定策略、验证码输错3次刷新。状态管理包括记住我是否生效、登录态过期后跳转、账号锁定倒计时。异常处理包括接口超时、服务端500、断网重连。兼容体验包括主流浏览器、不同分辨率、Web端和移动端适配。拆测试点这一步非常关键它是所有后续方法的地基。如果拆得不全后面六种方法用得再熟练也白搭。判断拆全没有我有一个土办法把自己当成一个第一次用这个功能的用户从注册账号开始到登录、退出、忘了密码、被锁定、换设备重新登录从头走一遍流程一边走一边记录每一步会发生什么哪些地方可能出错。这比单纯看需求文档不容易漏。3.2 六种方法如何配合使用测试点拆完之后下一步是把每一类测试点分配到最合适的方法上而不是把所有方法全抛上去。我从实际操作中验证过的分配方案是这样的。输入校验类测试点用等价类加边界值。用户名和密码每一类输入规则都划分有效类和无效类然后在长度边界上补齐数据。验证码在格式和有效期两个维度上做等价类和边界值覆盖。交互逻辑类测试点主要用场景法。把从进入页面到登录成功的整个过程建模成基本流和备选流把回车提交、点击刷新验证码、错误提示消失这些交互放在关键路径的节点上。安全策略类测试点先用判定表把用户名、密码、验证码、锁定状态四个条件组合列出来看看每种组合下系统的动作是否符合预期。锁定策略的具体数值再交给边界值处理比如第4次失败和第5次失败。状态管理类测试点主要靠场景法加错误推测法。记住我、锁定期限、登录态过期这几个状态需要用场景串起来同时补充一些异常状态比如记住我登录后在服务端重置密码原登录态是否立即失效。异常和兼容类测试点核心是错误推测法加少量正交试验。断网、超时、重复点击这些靠经验补充浏览器和终端组合可以用正交试验压缩测试量。看到没有这五种方法不是排排坐每个都要写一遍而是各管一块。对输入框多的页面等价类边界值是主力对流程长的模块场景法是主力对规则复杂的后台配置判定表是主力。这种“看菜下饭”的选择能力才是万能思路里“万能”二字的真正含义。3.3 最终测试用例清单节选标准测试用例字段包括用例编号、所属模块、用例标题、优先级、前置条件、测试步骤、测试数据、预期结果。下面节选几条登录功能的用例展示实际落地效果。用例编号用例标题优先级前置条件测试步骤测试数据预期结果TC-LOGIN-001输入合法用户名密码验证码登录成功P0已注册账号验证码可正常获取1.打开登录页 2.输入用户名密码 3.输入验证码 4.点击登录用户名testuser01密码abc12345验证码1234提示登录成功跳转首页并显示用户昵称TC-LOGIN-002用户名长度小于6位P1无1.打开登录页 2.输入5位用户名 3.输入合法密码和验证码 4.点击登录用户名user5密码abc12345验证码1234用户名输入框下方提示“用户名长度需为6-16位”不提交请求TC-LOGIN-003用户名长度为17位P1无同TC-LOGIN-002用户名user123456789abcd密码abc12345验证码1234同上提示长度不合法TC-LOGIN-004密码为纯数字P1无1.打开登录页 2.输入合法用户名 3.输入纯数字密码 4.输入验证码 5.点击登录用户名testuser01密码12345678验证码1234提示“密码需包含字母和数字”TC-LOGIN-005验证码错误后登录失败P1验证码已加载1.输入合法用户名密码 2.输入错误验证码 3.点击登录用户名testuser01密码abc12345验证码0000提示“验证码错误”停留登录页TC-LOGIN-006连续失败4次后第5次成功P1账号未锁定1.连续4次输错密码 2.第5次输入正确密码第5次使用正确密码第5次登录成功无锁定提示TC-LOGIN-007连续失败5次触发账号锁定P0账号未锁定1.连续5次输错密码每次密码均错误第5次提交后提示“密码错误次数过多账号锁定30分钟”TC-LOGIN-008锁定期间尝试登录P0账号已锁定1.锁定期间打开登录页 2.输入正确用户名密码和验证码正确凭证提示“账号已锁定请30分钟后再试”不能登录TC-LOGIN-009验证码输错3次后刷新P1验证码图片正常显示1.连续输错3次验证码3次验证码均错误第3次提交后验证码图片自动刷新原有验证码失效TC-LOGIN-010勾选记住我登录P1用户已登录过1.勾选记住我 2.登录成功后关闭浏览器 3.30天内重新打开站点正确凭证无需重复登录自动进入首页TC-LOGIN-011密码请求中是否明文传输P0抓包工具就绪1.打开页面 2.输入账号密码和验证码 3.点击登录 4.抓取提交请求用户名testuser01密码abc12345请求中密码字段加密或不可明文识别页面源码不出现明文密码TC-LOGIN-012用户名包含SQL注入字符P1无1.输入“admin or 11”等注入字符 2.输入任意密码和验证码 3.点击登录用户名admin or 11系统无异常不登录成功提示用户不存在或账号错误实际项目中登录功能这种规模的需求完整用例大概在40到60条之间。上面节选的12条只是展示格式和设计思路。重点在于每一条用例都可以追溯到需求或风险点评审被人问“为什么写这条用例”时你能明确说出理由这才是用例设计的健康状态。4. 常见问题与排查技巧实录4.1 用例设计中最常见的五个误区误区一是只喜欢测正常路径。团队里总有测试伙伴拿到需求后一口气写了十几条“输入正确数据、系统正常处理”的用例异常情况一条没有。看不清哪个环节出了问题。正常的流程要测但一个经得起推敲的用例库异常用例通常比正常用例多一倍。程序出问题往往就在“没想到用户会这样操作”的地方。误区二是无效等价类合并成一条用例。前面已经强调过一个无效等价类对应一条用例不合并的理由很实在程序遇到第一个非法输入就会终止后续逻辑。把两个无效类合并第二个无效类根本没有被执行用例等于白写。误区三是不写前置条件和测试数据。有些同学写的用例步骤只有“点击登录、查看结果”看起来精简执行时每一轮都要临时猜数据不同的测试人员还会猜出不同结果。用例是团队资产不是个人备忘录。前置条件、数据、预期结果必须明确甚至可以给关键数据命名比如“已锁定账号LOCKED_USER”方便自动化和回归测试复用。误区四是想把所有方法都用上。我刚带新人那会儿经常看到有人对一个简单按钮硬生生拆出等价类、边界值、判定表、正交试验最后写了几十条例把简单问题复杂化。方法是为目的服务的一条用例能说清楚的事情不要拆成三条。设计到什么粒度要按功能复杂度和风险等级来定一个纯展示页面核心路径加边角异常就足够。误区五是不维护用例。需求一变更最怕听到“旧的先不管了把新功能用例写了”。测试用例和代码一样需要持续维护。需求变了用例不更新不仅有回归遗漏风险还会让团队慢慢失去对用例库的信任最后大家都不看用例测试就变成了凭感觉做事。我现在每个迭代会把用例库维护当成测试任务的一部分变更了哪些功能同步更新哪些用例在迭代验收时严格检查。4.2 用例评审时最容易吵起来的三个问题用例评审是测试质量的一道重要关卡但真正开评审会时大家经常会为三个问题争论不休。第一个问题“这条用例该不该写”。产品觉得某条异常场景根本不可能发生开发觉得某条边界值验证没有意义测试觉得有风险必须覆盖。这种分歧的根源是风险认知不同。我现在的处理方式是先摆出这条用例对应的是哪个需求点或历史缺陷如果都摆不出来说明可疑暂缓如果能摆出来就按风险等级决定去留。以数据和事实说话而不是按职位高低或嗓门大小判断。第二个问题“覆盖率多少才算够”。这是一个没有标准答案的问题硬要验收只能靠代码覆盖率工具但用例覆盖率和代码覆盖率从来不是一回事。我的判断标准很简单核心业务流程必须有场景覆盖所有输入规则必须有等价类和边界值覆盖所有业务规则必须有判定表或场景覆盖历次缺陷回归必须有对应用例。四类覆盖都齐了覆盖率就算达标。这个口径一般在项目启动时就对齐不要等到评审时再吵。第三个问题“用例归谁维护、自动化脚本归谁写”。这个问题看上去是分工问题实际是工程化问题。我经历过最混乱的阶段是测试人员手工维护Excel用例自动化工程师另维护一套脚本用例两边内容不一致执行结果对不上。后来我们统一把用例和自动化脚本关联用例作为唯一入口脚本挂载在用例下需求和用例变更走同一套流程情况才有好转。现在很多团队在推的harness工程化本质上也是解决这个关联问题让用例、数据、脚本、执行结果形成一个闭环。4.3 关于AI辅助生成测试用例的几点看法AI生成测试用例最近热度很高也有不少团队开始尝试通过AI根据PRD生成功能测试用例甚至让AI自动写用例并执行自动测试。作为一个真实项目里跑过AI辅助生成用例的测试人员我聊点实际操作感受。先说结论AI能把用例设计的效率提升30%到50%但还远不能完全替代测试人员的设计判断。拿登录功能举例把上面的需求描述扔给一个训练有素的AI它能够很快输出等价类、边界值、场景法甚至是判定表结构的用例格式规范字段齐全初看完全可以拿去评审。但细看就会发现几个问题一是它会照抄需求需求文档没写清楚的业务规则它不会自行弥补二是它能穷举常见组合但缺乏对业务本质的理解比如登录成功后部门数据权限范围是否正确这类深挖逻辑它就想不到三是它在错误推测法相关场景上比较弱SQL注入、越权、并发重复点击这类安全用例往往需要人再补一道。因此我的实践方法是让AI做“初稿生成器”而不是“终稿输出器”。具体流程是需求文档先喂给AI让它拆解测试点并生成基础用例我基于测试点拆解结果补充业务逻辑和异常场景再把补充后的用例回给AI进行格式化和组合补齐最后由测试负责人评审定稿。这个流程实践下来最舒服的不是AI生成了多少条能用的用例而是它把那些格式规范、必然覆盖的基础输入校验用例写完以后我可以把精力投在更具价值的业务规则分析和错误推测上。另外我注意到AI结合代码review和harness工程化也是一个值得尝试的方向。用例不只在评审时起作用它还可以直接驱动自动化测试框架执行执行失败时自动关联用例和日志形成一个“用例设计、代码审查、测试执行、结果反馈”的闭环工具链。AI生成用例后自动落到这个链路里减少手工搬运整个效率提升就很明显。不过AI生成用例也有一个隐患它会产生“看似穷尽的错觉”。人会因为知道自己漏了什么而心虚AI生成的一大堆用例反倒可能让团队误以为覆盖很完整从而放松了对业务深逻辑的推敲。所以我始终强调一句话AI解决的是效率和规范问题需求和业务的理解、关键场景的判断最终还得靠人来承担责任。把AI当成一个高效的初稿助手把测试工程师的精力聚焦到AI不擅长的那些深度判断上这才是当前阶段最务实的用法。踩过几次坑之后我现在设计用例的习惯已经非常固定了。拿到任何需求先不急着写用例把测试点拆清楚再根据测试点的特性选择两三种主要方法辅助方法做补充最后再花时间把历史缺陷和异常场景过一遍。这样写出来的用例评审时被质疑的底气都足很多。这个习惯我建议你可以在下个项目里试试不用多试两次就会发现写用例这件事真的不靠天赋靠的是思路和方法。
