从能点通到测得全TPshop项目第二阶段的用例设计与缺陷管理实战环境搭起来了账号能登录商品能加购订单能提交——不少人做完 TPshop 项目的第一阶段之后都会生出一种错觉测试不过如此就是把能点的按钮都点一遍。我第一遍做这个项目的时候也是这么想的三百多条用例写得很爽执行到一半才发现购物车的数量上限我压根没测优惠券和积分同时用的时候金额算错了我也没发现后台把商品下架之后前台购物车里那条记录的状态我更没管。等把这些问题补上用例数量翻了一倍多。这篇内容就是围绕 TPshop 这个练手项目把测试基础里最难自学的几块讲透需求怎么拆、用例怎么设计得既有覆盖度又不冗余、购物车到下单这条链路上容易漏什么、缺陷记录怎么写才不被开发打回、回归验证怎么做才不会白干。适合刚学完测试理论基础、正拿 TPshop 练手的人也适合已经做过一轮但总感觉测试不够扎实的人。我会尽量按当时真实的操作顺序来讲包括我踩过的坑。1. 拿到 TPshop 需求之后先别急着写用例1.1 需求里其实藏着三种信息只读一种必然漏测大多数人看 TPshop 的需求文档是翻页式阅读——从第一页翻到最后一页看到功能就记下来然后开始写用例。这种读法只能抓到业务信息另外两类信息会被完全忽略。我把需求文档读三遍每遍只盯一个维度第一遍看业务。这个模块是给谁用的、解决什么问题、正常走完一遍的路径是什么。比如会员中心-我的订单这个模块业务信息是用户能查看自己的订单列表、能按状态筛选、能查看订单详情、能取消未支付订单。这些信息决定了我要设计哪些正常流程用例。第二遍看数据。这一步是最容易被跳过的。每个输入框背后都有约束用户名长度是 4 到 16 位还是 3 到 20 位、密码是否允许特殊字符、手机号是否强制 11 位、商品数量输入框允许的最小值和最大值是多少。这些约束在需求文档里往往只提一句甚至只在原型图上标注但它直接决定边界值用例怎么取。我会单独拉一张字段约束表出来后面写用例直接照着表走不用反复翻文档。第三遍看异常。需求文档几乎不会写异常但异常才是缺陷的高发区。我会问自己几个固定问题这个操作提交两次会怎样中途断网重试会怎样两个人同时操作同一条数据会怎样操作超时之后状态是什么权限不够的人访问会怎样这三种信息各读一遍比通读十遍都管用。因为读的目的不同注意力分配就不同翻页式阅读会把三者混在一起最后哪个都没读细。1.2 用功能结构图把系统切到两个小时能测完的粒度TPshop 的功能点很多前台有注册登录、商品搜索与筛选、商品详情、购物车、下单结算、支付、会员中心、评论、收藏、优惠券、积分后台有商品管理、订单管理、会员管理、营销管理、权限管理、系统设置。如果直接按模块来分配测试任务会出问题一个订单管理模块可能包含十几个功能点谁接了都是三天的活进度不可控覆盖度也没法评估。我的做法是先把系统画成三层结构一级是模块二级是功能点三级是操作点。划分粒度的标准很简单——一个三级操作点从准备数据到验证结果两个小时内必须能测完。如果超过两个小时说明还应该再拆。比如下单结算这个二级功能点往下拆就是提交订单成功跳转支付页收货地址为空时的处理未选中任何商品时点击结算运费计算不同地区、是否包邮发票信息填写与不填写订单备注填写与超长输入库存不足时提交商品在购物车期间被下架拆到这个粒度每条都能在半小时内执行完分配任务也公平报告进度的时候能精确说这一层 32 个操作点已完成 25 个。1.3 需求说不清楚的地方用疑点清单去换答案TPshop 这种练手项目需求文档通常不会特别严谨一定会有说不清的地方。这时候有两种选择自己猜一个答案或者把问题记录下来去确认。我强烈建议后者原因很实际猜错了代码会按开发的理解走你按自己的理解写用例最后判定预期结果的时候双方都下不来台。而且练手项目里没有真正的产品经理你需要找的是带你做项目的老师或者自己给自己立规矩这个过程本身就是在练需求澄清这个核心能力。我习惯维护一张需求疑点清单格式是这样的编号所属模块疑点描述我的假设影响用例结论Q-01购物车商品数量上限是多少超出后是提示还是自动截断假设上限 99超出给提示CART-015 至 CART-019待确认Q-02下单优惠券与积分能否同时使用假设可同时抵扣顺序待定ORDER-032已确认可同时先券后积分Q-03会员手机号修改后是否需要重新验证假设需要短信验证MEMBER-008待确认这张表有三个作用一是写用例的时候心里有数知道哪几条是待定的二是后面需求变更了能快速定位到受影响的用例三是评审的时候带着清单去开会比空着手说我觉得这里不太清楚专业得多。2. 登录注册模块等价类、边界值、场景法怎么真正落到用例表里2.1 先做输入域分析把字段拆成可控的测试因子登录注册模块看起来简单但它是把等价类、边界值、场景法三种方法都用上的最佳练手对象。我拿到这个模块第一件事不是写用例是先把所有输入字段列出来做输入域分析。以 TPshop 的注册页面为例需要控制的字段大概是这些字段类型长度/格式约束是否必填是否唯一备注用户名文本4-16 位字母数字下划线是是区分大小写待确认密码密码6-20 位区分大小写是否是否允许空格待确认确认密码密码需与密码一致是否手机号文本11 位数字1 开头是是是否真实发送短信邮箱文本含 与域名否是格式校验强度待确认图形验证码文本4 位是否是否区分大小写这张表一拉出来用例设计的范围就明确了。输入域分析的价值在于把我要测登录注册这种模糊的任务变成我要覆盖 6 个字段的 4 类约束条件这种可衡量的任务。2.2 等价类和边界值重点是合并同类项不是凑用例条数很多人学等价类的时候理解成每个字段写一条有效用例加一条无效用例结果用例表写了八十条实际执行起来一半是重复的。等价类的核心思想是合并同类项把处理逻辑相同的输入归为一类从每一类里挑一个代表值来测。同一个字段的有效等价类通常只有一到两个无效等价类按验证规则来划分。拿用户名做例子约束是 4-16 位字母数字下划线那么有效等价类4-16 位合法字符代表值testuser无效等价类 1长度不足 4 位代表值abc无效等价类 2长度超过 16 位代表值17 位字符无效等价类 3包含非法字符代表值test user含空格无效等价类 4为空无效等价类 5已存在的用户名注意长度不足和长度超过虽然都是长度问题但代码里往往是两个不同的判断分支所以要分成两类。而含中文含特殊符号含空格这三种如果代码用的是同一个正则表达式校验那就是一类测一个就够。判断能不能合并看的是代码分支不是看表面差异。边界值的取点是固定套路对 4-16 这个区间取点值类型最小值-13 位无效最小值4 位有效最小值15 位有效最大值-115 位有效最大值16 位有效最大值117 位无效六个点比穷举高效比随便挑两个靠谱。我见过有人只测 4 位和 16 位结果 3 位和 17 位抛出未捕获异常页面直接白屏——这种问题就是边界值没取全。2.3 场景法补流程缺口注册、登录、找回密码的真实路径等价类和边界值管的是单个输入框管不了多个操作串起来的流程。这时候要用场景法。场景法的写法是先把流程拆成基本流、备选流、异常流。以注册后登录为例基本流打开注册页 → 填写合法信息 → 提交 → 注册成功 → 跳转登录页 → 输入正确账号密码 → 登录成功 → 进入个人中心备选流 1注册时手机号已存在 → 提示已注册 → 走找回密码流程备选流 2登录时密码错误 → 提示错误 → 点击忘记密码 → 通过手机号重置 → 用新密码登录成功异常流 1提交注册时网络中断 → 刷新页面 → 检查是否有脏数据产生异常流 2登录连续输错密码 → 是否触发锁定或验证码机制异常流 1 这类用例特别值得写因为练手项目里经常出现提交失败但数据已经写进数据库的问题这种缺陷用单字段用例永远发现不了。2.4 用例表怎么写才可执行、可判定用例写了没人能用通常是因为两个毛病步骤写成了测试登录功能这种没有动作的描述预期结果写成了登录成功这种没法判定的结论。我用的用例表字段是这样的字段说明用例编号模块前缀序号如 LOGIN-007不重复所属模块便于后面按模块统计覆盖率用例标题一句话说明用什么条件验证什么可判定优先级P0 冒烟 / P1 核心 / P2 一般 / P3 边缘前置条件执行前必须满足的数据和环境状态操作步骤编号写每步一个动作包含具体数据预期结果可观察、可对比尽量写明文案或状态关联需求对应需求文档的章节号举个完整的例子用例编号LOGIN-007用例标题密码为 6 位以下时登录失败并提示优先级P1前置条件已存在账号 testuser正确密码为 Abc123456步骤1. 打开登录页2. 用户名输入 testuser3. 密码输入 Abc125 位4. 点击登录预期结果页面停留在登录页密码输入框下方提示密码长度不能少于 6 位不产生登录会话关联需求REQ-LOGIN-03这里的关键是预期结果里写清了提示文案和页面状态。如果只写登录失败执行的人看到页面白屏也会认为是通过。文案可能和实际不一致但先写上执行时发现对不上就记下来这本身就是一条待确认项。提示用例标题密码为 6 位以下时登录失败并提示这种写法读一遍就知道要测什么、怎么算通过。避免登录密码校验测试这类模糊标题这类标题执行时必然要靠猜。