用过 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 不只是一个"点点点"的练习项目，而是一个能系统训练测试思维的平台。真正拉开差距的从来不是你会不会用某个工具，而是你面对一个功能时，脑子里能不能瞬间拉出一张"该测什么、怎么测、哪里最容易出问题"的清单。这张清单，才是这行最值钱的东西。
