用过 TPshop 练手的人大概都有这种体会第一次照着教程把功能点一遍觉得这不挺简单的吗等真正让你写用例、提缺陷、追着开发复现问题的时候才发现电商这条业务链里藏着太多想当然的坑。这篇接着上一篇继续聊 TPshop 项目重点放在那些真正需要动脑子的测试点上——商品、购物车、订单、权限、支付状态流转还有测试基础练习里最容易被忽略的边界和数据校验。你要是刚学完测试理论、正找一个完整项目练手或者工作一两年想补一补业务测试的思路下面这些内容基本可以拿着直接对照操作。我会把每一步为什么这么做讲清楚而不是只丢给你一个结论。1. TPshop项目到底在测什么先把范围和思路理清1.1 电商系统为什么是测试基础的试炼场选 TPshop 做练习不是因为它多复杂而是因为它全。一个完整的电商系统天然包含了注册登录、商品浏览、购物车、下单、支付、发货、售后这一整条链路几乎把测试基础阶段要学的东西都覆盖了输入框校验、下拉框、列表分页、数据联动、状态流转、权限控制。你不需要额外造场景业务自己就把场景给你摆好了。更关键的是电商的每个环节都不是孤立的。改一个价格会影响下单金额改一个库存会影响能不能加购物车改一个订单状态会影响能不能申请退款。这种牵一发动全身的特性正好是训练测试思维最好的材料。很多新人写用例只会盯着单个页面点一到联调场景就漏TPshop 恰好能把这种短板暴露出来逼着你去想数据是怎么在模块之间流动的。所以我在练这个项目的时候第一件事不是急着点功能而是先画一张业务流程图把用户从进来到下单完成这条主线走一遍。心里有了这条线后面写用例、定优先级、判断影响范围都会顺很多。这个习惯我强烈建议大家养成比背多少条理论都管用。1.2 需求梳理与测试范围边界的确定拿到 TPshop 之后很多人的第一反应是功能这么多我一个个测到什么时候。这时候就要做范围划分。我的做法是先分三大块前台用户端、后台管理端、以及两端之间的数据交互。前台是普通用户能看到的关注的是体验和流程顺不顺后台是运营用的关注的是数据能不能正确增删改查、权限有没有漏洞交互部分则是最容易出问题也最容易被忽略的。范围划出来之后再排优先级。核心链路——注册登录、搜索商品、加购物车、下单、支付——优先级最高必须先测透商品管理、订单管理这类后台功能次之像积分、优惠券、评论这些附加模块可以往后放。这么排的理由很实际万一你时间有限核心链路崩了用户根本用不了其他功能再完美也没意义。边界这块特别提醒一句测试范围不是所有功能都点一遍而是所有会影响核心业务的功能都验证到位。我曾经见过有人把后台每一个设置项都点了一遍结果下单金额算错了都没发现这就是典型的本末倒置。范围划定的本质是取舍取舍的依据就是业务影响面这一点想通了测试效率会明显不一样。1.3 测试优先级与时间分配思路优先级排完之后时间怎么分也很讲究。我一般的分配是核心链路占五成后台关键功能占三成其余零散功能占两成。为什么核心链路要占这么多因为它是用户真正会走的路径缺陷密度也最高。TPshop 的下单流程涉及库存、价格、运费、优惠、支付状态好几个变量任何一个环节出问题都是生产级事故值得多花时间。后台功能我给三成是因为它虽然用户看不到但直接决定前台数据对不对。比如后台改了个商品价格前台没同步那用户看到的就是错的。这种后端配置影响前端展示的测试点是电商测试里非常典型的一类必须专门留时间去覆盖。剩下的两成留给探索性测试。什么叫探索性测试就是没有固定用例拿着系统边点边想专挑那些感觉会出问题的地方试试。比如连续快速点击下单按钮、在结算页停留很久再提交、把浏览器缩放调到很小看布局会不会乱。这类测试往往能挖出用例覆盖不到的缺陷是常规测试的重要补充。时间不用多但不能没有。2. 核心业务链的测试细节从商品一路走到订单2.1 商品模块藏在字段里的校验点商品模块看着最枯燥其实校验点最多。后台新增商品时要填商品名称、价格、库存、规格、图片、详情描述每一个字段背后都有一堆边界要测。拿价格来说正常情况填个正数是没问题的但你得想能不能填 0能不能填负数能不能填小数、小数点后几位能不能填超大数值能不能填字母或者特殊符号这些就是典型的等价类和边界值思路在实战里的应用。名称字段除了长度边界还要考虑重复名称能不能提交、名称里带特殊字符会不会导致前台展示乱码或者页面错位。我之前练的时候就遇到过商品名里带单引号前台详情页直接报数据库错误的例子这就是典型的输入没有做过滤导致的。测试的意义之一就是提前把这些没做防御的地方找出来。规格和库存的联动也要重点看。比如一个商品有红色、蓝色两个规格各自库存不同那么用户选红色和蓝色时前台显示的库存必须对应上。如果后台改了规格库存前台没刷新就会误导用户下单后才发现无货。这种跨模块的数据一致性光靠单页面点击是测不出来的必须前后台对照着看。我的习惯是把后台配置和前台展示做一张对照表逐项核对效率高还不容易漏。2.2 购物车与库存数量、价格、并发的三重要命处购物车是用户下单前的必经环节也是问题高发区。先说数量加购时能不能填 0能不能填负数能不能超过库存能不能填小数这些都是基础校验。再往上数量改了之后小计金额有没有跟着变、多件商品的总价有没有重新算这些属于计算逻辑必须逐条核对。价格这块更微妙。商品可能在加购之后被后台改价或者参加了促销活动那购物车里显示的是原价还是活动价结算时以哪个为准这类时效性问题在真实电商里非常常见也是测试时特别容易漏的。我练 TPshop 的时候就专门造过这种场景加购 → 后台改价 → 回前台刷新结算看金额到底按哪个走。库存并发是个进阶点。理论上同一件最后一件库存如果两个人同时下单应该有一个人失败。单机练习环境很难真正模拟并发但你可以用工具的并发功能或者多开浏览器近似验证一下至少观察下单后库存扣减对不对、超卖有没有拦截。这个点在实际工作里往往是重点提前在练习项目里接触面试或上岗时不至于一脸茫然。2.3 订单与支付状态机最容易出缺陷的地方如果说电商测试有一个重灾区那一定是订单状态。一个订单从生成到完成要经过待付款、已付款、待发货、已发货、已完成、已取消、退款中、已退款等好几个状态每个状态之间能不能合法流转是测试的核心。比如未付款的订单能不能直接发货已发货的能不能取消退款中的能不能又去支付这些都要挨个验证。状态流转最容易出的问题是非法跳转和重复操作。非法跳转比如订单已经取消了还能点支付重复操作比如快速点两次付款按钮生成了两笔支付记录。我在练这个模块时专门盯着按钮的可用状态看——什么状态下哪个按钮该亮、哪个该灰这是一条很实用的检查线索因为按钮状态往往直接反映了业务规则有没有被正确实现。支付环节还要注意金额和订单的绑定关系。支付金额必须和订单应付金额一致不能出现付了 A 订单的钱却更新了 B 订单状态的情况。这类问题通常需要结合后台订单列表和支付记录一起核对光看前台是看不出来的。所以我一直强调测订单千万别只看前台后台的数据才是真相。2.4 会员与权限角色越权是重点排查对象权限测试在后台管理端尤其重要。TPshop 后台一般会有超级管理员、普通管理员、不同角色对应不同菜单和操作权限。测试时要验证的是不同角色登录后能看到的菜单是不是只有自己权限范围内的能不能通过直接输入 URL 的方式访问到没权限的页面这就是典型的水平越权和垂直越权检查。我遇到过一种很典型的情况前端菜单把没权限的入口藏起来了看起来很安全但直接在地址栏敲对应路径页面居然能打开甚至能提交数据。这就是只做了前端隐藏、没做后端校验的经典漏洞。测试的价值就在这里——不要相信界面上看到的要主动去试那些理论上不该让你进的入口。会员相关的还有个人信息修改、密码修改、收货地址管理这些。密码修改要验证旧密码校验、新密码规则、两次输入一致性收货地址要验证必填项、手机号格式、默认地址切换。这些点单个看都很基础但合在一起就是一条完整的用户数据链路测透了你对数据在系统里怎么流动的理解会上一个台阶。3. 测试用例设计实操把方法真正落到用例上3.1 等价类与边界值以注册和下单为例等价类和边界值是测试基础里最先学的两个方法但很多人学完不知道怎么用。拿 TPshop 的注册功能举例用户名要求 6 到 20 位那有效等价类就是 6 到 20 位之间的正常字符无效等价类包括小于 6 位、大于 20 位、含特殊符号、纯空格等。边界值则取 5、6、20、21 这几个点。这么一拆一个输入框就能产出七八条用例逻辑还特别清晰。下单时的数量输入同理。假设库存是 10那有效区间是 1 到 10边界值取 0、1、10、11。0 和 11 是无效的1 和 10 是有效的边界。别小看这几个数字真实的缺陷经常就藏在边界上——比如填 10 能下单填 11 系统没拦住或者填 0 直接崩溃。我想强调的是这两种方法不是用来凑用例数量的而是帮你系统地覆盖可能性。你按等价类分完再按边界值补基本就不会出现某个区间完全没测的情况。练习的时候可以刻意这么做几遍形成肌肉记忆以后拿到任何输入框都不会慌。3.2 场景法把一条完整购买链路串起来单个输入框的用例是点业务场景用例是线。场景法的核心是把用户完成一件事的完整路径走一遍同时考虑正常路径和异常分支。以用户购买一件商品为例正常路径是登录 → 搜索商品 → 进入详情 → 加入购物车 → 结算 → 提交订单 → 支付 → 支付成功。异常分支则是每个环节都可能出错的地方。比如搜索不到商品怎么办加购时库存不足怎么办结算时地址为空怎么办提交订单后不支付、取消订单会怎样支付中途关闭页面会怎样把这些分支列出来一条主流程能延伸出十几条场景用例。这种设计方法最大的好处是贴近真实用户行为测出来的缺陷往往也是用户真正会遇到的。我的经验是写场景用例时用前提—操作—预期三段式来组织写完之后自己顺着读一遍看逻辑通不通。如果读起来都别扭那多半是哪里没想清楚。场景法练熟了你会发现它的价值远不止写用例更能帮你建立一个用户视角这是做测试非常重要的一种思维方式。3.3 用例编写规范与优先级标注用例写得好不好直接影响执行效率和沟通成本。一条规范的用例至少要包含用例编号、所属模块、用例标题、前置条件、操作步骤、预期结果、优先级、执行结果。其中前置条件最容易被省略但它特别重要——比如购物车中已有一件库存充足的商品就是一个前置条件不写清楚别人执行时就会卡在第一步。优先级标注也是个容易被忽视的点。我一般按 P0 到 P3 来分P0 是核心链路必须通过才能继续往下测P1 是重要功能影响主流程但不致命P2 是次要功能P3 是体验类问题。分好优先级之后时间不够就先跑 P0、P1保证核心功能不掉链子。这个习惯在实际项目里能救命。下面给一张用例要素的对照表方便大家对照检查自己的用例是不是写全了要素说明常见误区用例编号唯一标识便于引用编号重复或随意编前置条件执行前的系统状态漏写导致无法执行操作步骤具体到每一个动作步骤太笼统别人看不懂预期结果明确、可判断写正常显示这种模糊描述优先级P0 到 P3全部标 P0失去意义3.4 测试数据准备与环境搭建要点数据准备这块很多新手会忽略结果测着测着发现没数据可测。TPshop 测试至少需要几类数据一个可用的普通用户账号、一批有库存的商品、几个不同状态的订单、以及后台的管理员账号。这些数据最好在开测前就统一准备好而不是边测边造。环境方面练习环境建议用本地部署数据库单独一个库方便你随时改数据、重置状态。我习惯在测之前先备份一次数据库测的过程中如果数据被改乱了直接恢复省得重新造。这个做法在真实项目里同样适用尤其是涉及支付、库存这种敏感数据的时候。还有一个小技巧把常用的测试数据整理成一张清单记录账号、密码、商品 ID、订单号这些信息放在手边。需要的时候直接查不用每次翻来翻去。别小看这点效率测试工作琐碎能省一点是一点。4. 测试执行与缺陷管理从点到面地推进4.1 执行顺序与冒烟、回归的节奏测试执行不是想到哪测到哪得有节奏。一般先跑冒烟测试——就是挑最核心的几条用例快速过一遍确认系统基本能用。如果冒烟都过不了说明这版质量太差直接打回让开发自测别浪费时间做详细测试。这个判断很重要能帮你把精力花在刀刃上。冒烟通过后按模块顺序执行详细用例优先跑 P0、P1。每跑完一个模块做一次小范围的回归——因为修缺陷可能引入新问题尤其是改动公共代码的时候。我以前就吃过亏改了一个金额计算的方法结果影响了好几个页面当时没回归上线才发现教训很深刻。回归测试要讲究方法不是每次都把所有用例跑一遍那样太耗时间。我的做法是根据改动的影响范围圈定要回归的模块和用例再补一点相邻模块的抽查。这样既保证覆盖又不至于无限膨胀。这个影响范围分析的能力是测试工程师进阶的关键。4.2 缺陷定位从前端现象追到数据库提缺陷最忌讳的就是我点了一下就报错了你们自己看。高质量的缺陷单应该包含清晰的现象描述、可复现的步骤、预期和实际结果、可能的原因分析。而且如果你能初步定位到是哪一层的问题价值会大大提升。举个例子下单金额不对。你可以先在前台看金额计算然后在浏览器开发者工具里看结算接口返回的数据再去数据库查订单表的金额字段一层层往下追。很多时候追到最后会发现是后端计算逻辑的问题或者根本就是测试数据本身有问题。这个追查的过程本身就是对系统理解加深的过程。学会看接口和查数据库是测试基础阶段非常划算的一项投入。不用会写代码只要能看懂接口返回的 JSON、会几条简单的查询语句就够了。下面这几条查询在排查订单问题时我经常用到-- 查某个订单的当前状态和金额 SELECT order_id, order_status, pay_status, total_amount FROM tp_order WHERE order_id 12345; -- 查某商品的库存情况 SELECT goods_id, goods_name, store_count FROM tp_goods WHERE goods_id 100; -- 查某个用户的地址列表 SELECT address_id, consignee, mobile, is_default FROM tp_user_address WHERE user_id 1001;有了这几条很多看起来玄学的问题一下子就能定位。不用一开始就精通 SQL能把这几条用熟排查效率就有质的提升。4.3 缺陷单怎么写才不会被开发打回缺陷单被打回通常有几个原因复现步骤不清楚、环境信息缺失、现象描述太模糊、或者根本没法复现。要避免这些我总结了几个要点。第一标题要精准比如购物车商品数量改为 0 后仍能提交订单而不是购物车有问题。第二步骤要能照着一步步走通让别人能稳定复现。第三附上截图、接口返回、日志这些证据远比一句报错了有说服力。还有一个容易被忽视的点缺陷的严重程度和优先级要标对。严重程度指的是问题本身有多严重比如崩溃、数据错误 vs 界面错位优先级指的是要多久修比如影响主流程 vs 可以缓一缓。这两个不是一个概念标对了开发才好安排。我见过有人把界面文案写错标成致命结果开发一看就笑了反而影响沟通信任。最后一点批评问题而不是批评人。缺陷单是客观描述不要写你怎么又犯这种错。就事论事把现象和证据摆清楚剩下的交给开发判断。合作顺畅了修复效率自然就高了。5. 常见问题与排查技巧速查5.1 高频问题速查表练 TPshop 的过程中有些问题是高频出现的我整理成一张表遇到了可以直接对照排查现象可能原因排查方向下单金额与实际不符优惠、运费、活动价格叠加逻辑核对后台配置与前端计算加购后库存未同步缓存或数据未刷新刷新页面、查数据库库存支付后订单状态没变支付回调未正确更新查支付记录与订单表状态后台改价前台没变缓存未清或数据未同步清缓存后重新验证无权限页面能直接打开只做了前端隐藏后端未校验手动输入 URL 验证重复提交生成多笔订单未做防重复提交快速连点或并发提交验证这张表不是让死记而是给你一个思考的起点。看到类似现象先往这几个方向想往往能少走弯路。5.2 排查思路与独家避坑经验最后分享几个我在实际练习里踩出来的经验都是文档里不会写的。第一遇到问题先别急着提缺陷先确认是不是自己环境或者数据的问题。我曾经提过一个下单失败的缺陷开发查了半天最后发现是我自己改数据库把库存改成了负数。这种乌龙提多了影响你在团队里的可信度。所以提之前先按正常流程复现一遍确认操作没错、数据正常。第二善用浏览器的开发者工具。很多前端现象看一眼 Network 面板就清楚了——接口是 200 还是 500、返回的数据长什么样、请求参数对不对。不用会前端会看这些就够查大部分问题了。这是性价比极高的一项技能。第三测边界和异常比测正常流程更有价值。正常流程开发自己也会点真正容易漏的是极端情况和异常分支。多花点时间在边界值、空值、超长输入、并发操作上往往能挖出别人挖不到的缺陷。第四随时记录。测试过程琐碎想到的测试点、发现的现象、关键的数据随手记下来。一是防止遗漏二是复盘的时候有据可查。我到现在还保持着开测先建一个记录文档的习惯收益很大。第五别怕重复。TPshop 这类练习项目功能就那么多但每次重新过一遍关注点可以不一样第一次看流程第二次看数据第三次看异常。同一个功能测三遍出来的理解深度完全不一样。测试这件事量变到质变靠的就是这种反复打磨。把这些点和前面的方法结合起来用你会发现 TPshop 不只是一个点点点的练习项目而是一个能系统训练测试思维的平台。真正拉开差距的从来不是你会不会用某个工具而是你面对一个功能时脑子里能不能瞬间拉出一张该测什么、怎么测、哪里最容易出问题的清单。这张清单才是这行最值钱的东西。 
长河君 · 2026/9/29 1:10:22 · 阅读 1.2k TPshop电商测试实战：用例设计、订单状态与缺陷定位
用过 TPshop 练手的人大概都有这种体会第一次照着教程把功能点一遍觉得这不挺简单的吗等真正让你写用例、提缺陷、追着开发复现问题的时候才发现电商这条业务链里藏着太多想当然的坑。这篇接着上一篇继续聊 TPshop 项目重点放在那些真正需要动脑子的测试点上——商品、购物车、订单、权限、支付状态流转还有测试基础练习里最容易被忽略的边界和数据校验。你要是刚学完测试理论、正找一个完整项目练手或者工作一两年想补一补业务测试的思路下面这些内容基本可以拿着直接对照操作。我会把每一步为什么这么做讲清楚而不是只丢给你一个结论。1. TPshop项目到底在测什么先把范围和思路理清1.1 电商系统为什么是测试基础的试炼场选 TPshop 做练习不是因为它多复杂而是因为它全。一个完整的电商系统天然包含了注册登录、商品浏览、购物车、下单、支付、发货、售后这一整条链路几乎把测试基础阶段要学的东西都覆盖了输入框校验、下拉框、列表分页、数据联动、状态流转、权限控制。你不需要额外造场景业务自己就把场景给你摆好了。更关键的是电商的每个环节都不是孤立的。改一个价格会影响下单金额改一个库存会影响能不能加购物车改一个订单状态会影响能不能申请退款。这种牵一发动全身的特性正好是训练测试思维最好的材料。很多新人写用例只会盯着单个页面点一到联调场景就漏TPshop 恰好能把这种短板暴露出来逼着你去想数据是怎么在模块之间流动的。所以我在练这个项目的时候第一件事不是急着点功能而是先画一张业务流程图把用户从进来到下单完成这条主线走一遍。心里有了这条线后面写用例、定优先级、判断影响范围都会顺很多。这个习惯我强烈建议大家养成比背多少条理论都管用。1.2 需求梳理与测试范围边界的确定拿到 TPshop 之后很多人的第一反应是功能这么多我一个个测到什么时候。这时候就要做范围划分。我的做法是先分三大块前台用户端、后台管理端、以及两端之间的数据交互。前台是普通用户能看到的关注的是体验和流程顺不顺后台是运营用的关注的是数据能不能正确增删改查、权限有没有漏洞交互部分则是最容易出问题也最容易被忽略的。范围划出来之后再排优先级。核心链路——注册登录、搜索商品、加购物车、下单、支付——优先级最高必须先测透商品管理、订单管理这类后台功能次之像积分、优惠券、评论这些附加模块可以往后放。这么排的理由很实际万一你时间有限核心链路崩了用户根本用不了其他功能再完美也没意义。边界这块特别提醒一句测试范围不是所有功能都点一遍而是所有会影响核心业务的功能都验证到位。我曾经见过有人把后台每一个设置项都点了一遍结果下单金额算错了都没发现这就是典型的本末倒置。范围划定的本质是取舍取舍的依据就是业务影响面这一点想通了测试效率会明显不一样。1.3 测试优先级与时间分配思路优先级排完之后时间怎么分也很讲究。我一般的分配是核心链路占五成后台关键功能占三成其余零散功能占两成。为什么核心链路要占这么多因为它是用户真正会走的路径缺陷密度也最高。TPshop 的下单流程涉及库存、价格、运费、优惠、支付状态好几个变量任何一个环节出问题都是生产级事故值得多花时间。后台功能我给三成是因为它虽然用户看不到但直接决定前台数据对不对。比如后台改了个商品价格前台没同步那用户看到的就是错的。这种后端配置影响前端展示的测试点是电商测试里非常典型的一类必须专门留时间去覆盖。剩下的两成留给探索性测试。什么叫探索性测试就是没有固定用例拿着系统边点边想专挑那些感觉会出问题的地方试试。比如连续快速点击下单按钮、在结算页停留很久再提交、把浏览器缩放调到很小看布局会不会乱。这类测试往往能挖出用例覆盖不到的缺陷是常规测试的重要补充。时间不用多但不能没有。2. 核心业务链的测试细节从商品一路走到订单2.1 商品模块藏在字段里的校验点商品模块看着最枯燥其实校验点最多。后台新增商品时要填商品名称、价格、库存、规格、图片、详情描述每一个字段背后都有一堆边界要测。拿价格来说正常情况填个正数是没问题的但你得想能不能填 0能不能填负数能不能填小数、小数点后几位能不能填超大数值能不能填字母或者特殊符号这些就是典型的等价类和边界值思路在实战里的应用。名称字段除了长度边界还要考虑重复名称能不能提交、名称里带特殊字符会不会导致前台展示乱码或者页面错位。我之前练的时候就遇到过商品名里带单引号前台详情页直接报数据库错误的例子这就是典型的输入没有做过滤导致的。测试的意义之一就是提前把这些没做防御的地方找出来。规格和库存的联动也要重点看。比如一个商品有红色、蓝色两个规格各自库存不同那么用户选红色和蓝色时前台显示的库存必须对应上。如果后台改了规格库存前台没刷新就会误导用户下单后才发现无货。这种跨模块的数据一致性光靠单页面点击是测不出来的必须前后台对照着看。我的习惯是把后台配置和前台展示做一张对照表逐项核对效率高还不容易漏。2.2 购物车与库存数量、价格、并发的三重要命处购物车是用户下单前的必经环节也是问题高发区。先说数量加购时能不能填 0能不能填负数能不能超过库存能不能填小数这些都是基础校验。再往上数量改了之后小计金额有没有跟着变、多件商品的总价有没有重新算这些属于计算逻辑必须逐条核对。价格这块更微妙。商品可能在加购之后被后台改价或者参加了促销活动那购物车里显示的是原价还是活动价结算时以哪个为准这类时效性问题在真实电商里非常常见也是测试时特别容易漏的。我练 TPshop 的时候就专门造过这种场景加购 → 后台改价 → 回前台刷新结算看金额到底按哪个走。库存并发是个进阶点。理论上同一件最后一件库存如果两个人同时下单应该有一个人失败。单机练习环境很难真正模拟并发但你可以用工具的并发功能或者多开浏览器近似验证一下至少观察下单后库存扣减对不对、超卖有没有拦截。这个点在实际工作里往往是重点提前在练习项目里接触面试或上岗时不至于一脸茫然。2.3 订单与支付状态机最容易出缺陷的地方如果说电商测试有一个重灾区那一定是订单状态。一个订单从生成到完成要经过待付款、已付款、待发货、已发货、已完成、已取消、退款中、已退款等好几个状态每个状态之间能不能合法流转是测试的核心。比如未付款的订单能不能直接发货已发货的能不能取消退款中的能不能又去支付这些都要挨个验证。状态流转最容易出的问题是非法跳转和重复操作。非法跳转比如订单已经取消了还能点支付重复操作比如快速点两次付款按钮生成了两笔支付记录。我在练这个模块时专门盯着按钮的可用状态看——什么状态下哪个按钮该亮、哪个该灰这是一条很实用的检查线索因为按钮状态往往直接反映了业务规则有没有被正确实现。支付环节还要注意金额和订单的绑定关系。支付金额必须和订单应付金额一致不能出现付了 A 订单的钱却更新了 B 订单状态的情况。这类问题通常需要结合后台订单列表和支付记录一起核对光看前台是看不出来的。所以我一直强调测订单千万别只看前台后台的数据才是真相。2.4 会员与权限角色越权是重点排查对象权限测试在后台管理端尤其重要。TPshop 后台一般会有超级管理员、普通管理员、不同角色对应不同菜单和操作权限。测试时要验证的是不同角色登录后能看到的菜单是不是只有自己权限范围内的能不能通过直接输入 URL 的方式访问到没权限的页面这就是典型的水平越权和垂直越权检查。我遇到过一种很典型的情况前端菜单把没权限的入口藏起来了看起来很安全但直接在地址栏敲对应路径页面居然能打开甚至能提交数据。这就是只做了前端隐藏、没做后端校验的经典漏洞。测试的价值就在这里——不要相信界面上看到的要主动去试那些理论上不该让你进的入口。会员相关的还有个人信息修改、密码修改、收货地址管理这些。密码修改要验证旧密码校验、新密码规则、两次输入一致性收货地址要验证必填项、手机号格式、默认地址切换。这些点单个看都很基础但合在一起就是一条完整的用户数据链路测透了你对数据在系统里怎么流动的理解会上一个台阶。3. 测试用例设计实操把方法真正落到用例上3.1 等价类与边界值以注册和下单为例等价类和边界值是测试基础里最先学的两个方法但很多人学完不知道怎么用。拿 TPshop 的注册功能举例用户名要求 6 到 20 位那有效等价类就是 6 到 20 位之间的正常字符无效等价类包括小于 6 位、大于 20 位、含特殊符号、纯空格等。边界值则取 5、6、20、21 这几个点。这么一拆一个输入框就能产出七八条用例逻辑还特别清晰。下单时的数量输入同理。假设库存是 10那有效区间是 1 到 10边界值取 0、1、10、11。0 和 11 是无效的1 和 10 是有效的边界。别小看这几个数字真实的缺陷经常就藏在边界上——比如填 10 能下单填 11 系统没拦住或者填 0 直接崩溃。我想强调的是这两种方法不是用来凑用例数量的而是帮你系统地覆盖可能性。你按等价类分完再按边界值补基本就不会出现某个区间完全没测的情况。练习的时候可以刻意这么做几遍形成肌肉记忆以后拿到任何输入框都不会慌。3.2 场景法把一条完整购买链路串起来单个输入框的用例是点业务场景用例是线。场景法的核心是把用户完成一件事的完整路径走一遍同时考虑正常路径和异常分支。以用户购买一件商品为例正常路径是登录 → 搜索商品 → 进入详情 → 加入购物车 → 结算 → 提交订单 → 支付 → 支付成功。异常分支则是每个环节都可能出错的地方。比如搜索不到商品怎么办加购时库存不足怎么办结算时地址为空怎么办提交订单后不支付、取消订单会怎样支付中途关闭页面会怎样把这些分支列出来一条主流程能延伸出十几条场景用例。这种设计方法最大的好处是贴近真实用户行为测出来的缺陷往往也是用户真正会遇到的。我的经验是写场景用例时用前提—操作—预期三段式来组织写完之后自己顺着读一遍看逻辑通不通。如果读起来都别扭那多半是哪里没想清楚。场景法练熟了你会发现它的价值远不止写用例更能帮你建立一个用户视角这是做测试非常重要的一种思维方式。3.3 用例编写规范与优先级标注用例写得好不好直接影响执行效率和沟通成本。一条规范的用例至少要包含用例编号、所属模块、用例标题、前置条件、操作步骤、预期结果、优先级、执行结果。其中前置条件最容易被省略但它特别重要——比如购物车中已有一件库存充足的商品就是一个前置条件不写清楚别人执行时就会卡在第一步。优先级标注也是个容易被忽视的点。我一般按 P0 到 P3 来分P0 是核心链路必须通过才能继续往下测P1 是重要功能影响主流程但不致命P2 是次要功能P3 是体验类问题。分好优先级之后时间不够就先跑 P0、P1保证核心功能不掉链子。这个习惯在实际项目里能救命。下面给一张用例要素的对照表方便大家对照检查自己的用例是不是写全了要素说明常见误区用例编号唯一标识便于引用编号重复或随意编前置条件执行前的系统状态漏写导致无法执行操作步骤具体到每一个动作步骤太笼统别人看不懂预期结果明确、可判断写正常显示这种模糊描述优先级P0 到 P3全部标 P0失去意义3.4 测试数据准备与环境搭建要点数据准备这块很多新手会忽略结果测着测着发现没数据可测。TPshop 测试至少需要几类数据一个可用的普通用户账号、一批有库存的商品、几个不同状态的订单、以及后台的管理员账号。这些数据最好在开测前就统一准备好而不是边测边造。环境方面练习环境建议用本地部署数据库单独一个库方便你随时改数据、重置状态。我习惯在测之前先备份一次数据库测的过程中如果数据被改乱了直接恢复省得重新造。这个做法在真实项目里同样适用尤其是涉及支付、库存这种敏感数据的时候。还有一个小技巧把常用的测试数据整理成一张清单记录账号、密码、商品 ID、订单号这些信息放在手边。需要的时候直接查不用每次翻来翻去。别小看这点效率测试工作琐碎能省一点是一点。4. 测试执行与缺陷管理从点到面地推进4.1 执行顺序与冒烟、回归的节奏测试执行不是想到哪测到哪得有节奏。一般先跑冒烟测试——就是挑最核心的几条用例快速过一遍确认系统基本能用。如果冒烟都过不了说明这版质量太差直接打回让开发自测别浪费时间做详细测试。这个判断很重要能帮你把精力花在刀刃上。冒烟通过后按模块顺序执行详细用例优先跑 P0、P1。每跑完一个模块做一次小范围的回归——因为修缺陷可能引入新问题尤其是改动公共代码的时候。我以前就吃过亏改了一个金额计算的方法结果影响了好几个页面当时没回归上线才发现教训很深刻。回归测试要讲究方法不是每次都把所有用例跑一遍那样太耗时间。我的做法是根据改动的影响范围圈定要回归的模块和用例再补一点相邻模块的抽查。这样既保证覆盖又不至于无限膨胀。这个影响范围分析的能力是测试工程师进阶的关键。4.2 缺陷定位从前端现象追到数据库提缺陷最忌讳的就是我点了一下就报错了你们自己看。高质量的缺陷单应该包含清晰的现象描述、可复现的步骤、预期和实际结果、可能的原因分析。而且如果你能初步定位到是哪一层的问题价值会大大提升。举个例子下单金额不对。你可以先在前台看金额计算然后在浏览器开发者工具里看结算接口返回的数据再去数据库查订单表的金额字段一层层往下追。很多时候追到最后会发现是后端计算逻辑的问题或者根本就是测试数据本身有问题。这个追查的过程本身就是对系统理解加深的过程。学会看接口和查数据库是测试基础阶段非常划算的一项投入。不用会写代码只要能看懂接口返回的 JSON、会几条简单的查询语句就够了。下面这几条查询在排查订单问题时我经常用到-- 查某个订单的当前状态和金额 SELECT order_id, order_status, pay_status, total_amount FROM tp_order WHERE order_id 12345; -- 查某商品的库存情况 SELECT goods_id, goods_name, store_count FROM tp_goods WHERE goods_id 100; -- 查某个用户的地址列表 SELECT address_id, consignee, mobile, is_default FROM tp_user_address WHERE user_id 1001;有了这几条很多看起来玄学的问题一下子就能定位。不用一开始就精通 SQL能把这几条用熟排查效率就有质的提升。4.3 缺陷单怎么写才不会被开发打回缺陷单被打回通常有几个原因复现步骤不清楚、环境信息缺失、现象描述太模糊、或者根本没法复现。要避免这些我总结了几个要点。第一标题要精准比如购物车商品数量改为 0 后仍能提交订单而不是购物车有问题。第二步骤要能照着一步步走通让别人能稳定复现。第三附上截图、接口返回、日志这些证据远比一句报错了有说服力。还有一个容易被忽视的点缺陷的严重程度和优先级要标对。严重程度指的是问题本身有多严重比如崩溃、数据错误 vs 界面错位优先级指的是要多久修比如影响主流程 vs 可以缓一缓。这两个不是一个概念标对了开发才好安排。我见过有人把界面文案写错标成致命结果开发一看就笑了反而影响沟通信任。最后一点批评问题而不是批评人。缺陷单是客观描述不要写你怎么又犯这种错。就事论事把现象和证据摆清楚剩下的交给开发判断。合作顺畅了修复效率自然就高了。5. 常见问题与排查技巧速查5.1 高频问题速查表练 TPshop 的过程中有些问题是高频出现的我整理成一张表遇到了可以直接对照排查现象可能原因排查方向下单金额与实际不符优惠、运费、活动价格叠加逻辑核对后台配置与前端计算加购后库存未同步缓存或数据未刷新刷新页面、查数据库库存支付后订单状态没变支付回调未正确更新查支付记录与订单表状态后台改价前台没变缓存未清或数据未同步清缓存后重新验证无权限页面能直接打开只做了前端隐藏后端未校验手动输入 URL 验证重复提交生成多笔订单未做防重复提交快速连点或并发提交验证这张表不是让死记而是给你一个思考的起点。看到类似现象先往这几个方向想往往能少走弯路。5.2 排查思路与独家避坑经验最后分享几个我在实际练习里踩出来的经验都是文档里不会写的。第一遇到问题先别急着提缺陷先确认是不是自己环境或者数据的问题。我曾经提过一个下单失败的缺陷开发查了半天最后发现是我自己改数据库把库存改成了负数。这种乌龙提多了影响你在团队里的可信度。所以提之前先按正常流程复现一遍确认操作没错、数据正常。第二善用浏览器的开发者工具。很多前端现象看一眼 Network 面板就清楚了——接口是 200 还是 500、返回的数据长什么样、请求参数对不对。不用会前端会看这些就够查大部分问题了。这是性价比极高的一项技能。第三测边界和异常比测正常流程更有价值。正常流程开发自己也会点真正容易漏的是极端情况和异常分支。多花点时间在边界值、空值、超长输入、并发操作上往往能挖出别人挖不到的缺陷。第四随时记录。测试过程琐碎想到的测试点、发现的现象、关键的数据随手记下来。一是防止遗漏二是复盘的时候有据可查。我到现在还保持着开测先建一个记录文档的习惯收益很大。第五别怕重复。TPshop 这类练习项目功能就那么多但每次重新过一遍关注点可以不一样第一次看流程第二次看数据第三次看异常。同一个功能测三遍出来的理解深度完全不一样。测试这件事量变到质变靠的就是这种反复打磨。把这些点和前面的方法结合起来用你会发现 TPshop 不只是一个点点点的练习项目而是一个能系统训练测试思维的平台。真正拉开差距的从来不是你会不会用某个工具而是你面对一个功能时脑子里能不能瞬间拉出一张该测什么、怎么测、哪里最容易出问题的清单。这张清单才是这行最值钱的东西。