电商后台的测试只要碰到钱和库存这两样东西坑就永远不会少。我这次接着上一轮的进度把TPshop这套开源商城的测试继续往深里做。上一轮基本是把环境跑起来、把前后台页面点了一遍属于知道它长什么样的阶段这一轮要做的事情完全不一样——要把注册登录、商品搜索、购物车、下单支付、后台订单处理这几条链路真正打通用系统的测试方法去验证它在各种边界和异常下的表现。如果你正在学软件测试或者手头刚接手一个电商类项目不知道从哪儿下手这篇内容应该能给你一套可以直接照着做的路径。我会把用例怎么设计、数据怎么准备、缺陷怎么描述、遇到问题怎么排查都写清楚尽量做到看完就能用。1. 二次测试的整体思路与范围界定做第二轮测试最容易犯的毛病是拿着第一轮的结果再点一遍。我一开始也差点这么干后来发现这样纯属浪费时间。第一轮的产出是页面能不能打开、元素能不能点第二轮真正要解决的是业务流程能不能走通、数据在链路里流转是否一致。这是两个完全不同层次的目标思路必须先掰正。1.1 从单点校验转向链路贯通单点校验关注的是孤立的功能点比如手机号格式对不对、搜索框能不能输入。链路贯通关注的是一个用户在系统里完成一次完整交易这件事。举个具体的单点测试只会告诉你加入购物车按钮点击有反应链路测试会追问——加购之后库存数字变了吗结算页的价格和加购时一致吗提交订单后购物车里的条目清空了吗取消订单后库存回来了吗这一连串问题才是电商系统真正的风险区。我把这套逻辑总结成一句话能点的按钮不叫功能能走完的路才叫功能。TPshop里一个看似简单的下单动作背后牵扯到商品表、库存表、订单表、订单详情表、购物车表、优惠券表、用户地址表至少六七张表的联动写入。任何一处写入失败或者条件判断写偏都会产生钱付了订单没生成或者库存扣了两次这种灾难级问题。第二轮测试的全部价值就在于提前把这些灾难找出来。1.2 测试范围与优先级矩阵项目时间永远是紧张的不可能所有模块平均用力。我的做法是先画一张范围表把模块按业务价值和出错代价排优先级。判断标准很简单涉及金额和库存的排最高涉及用户身份的排次高纯展示类的排最低。模块业务价值出错代价优先级下单支付链路核心转化极高P0购物车与库存核心转化极高P0优惠券与满减影响成交高P0注册登录身份入口高P1商品搜索与筛选导购体验中P1后台订单管理履约基础高P1前台商品展示浏览体验低P2个人中心信息辅助功能低P2这张表的作用不是分类好看而是决定执行顺序。P0和P1必须测透P2在时间允许时覆盖主流程即可。很多新手会把大量时间花在修改昵称更换头像这种边角料上结果核心链路反而没测到这是很典型的资源错配。1.3 手工优先自动化后置的阶段判断经常有人问第二轮是不是该上自动化了。我的答案通常是先别急。自动化测试的前提是业务规则稳定、页面结构稳定、用例已经经过手工验证。第二轮的电商系统往往还处在规则理解阶段比如优惠券和满减能不能叠加这种问题我自己都还没搞清楚写出来的自动化脚本只会把错误的预期固化下来。所以我的节奏是手工先把每条链路的规则摸清楚把最容易出问题的节点做成稳定的手工回归用例等这轮测完、业务规则基本冻结之后再把那些高频重复执行的用例比如登录、加购、下单主流程沉淀成自动化脚本。顺序反过来做返工的成本会高得离谱。2. 独立测试环境的搭建与数据准备第二轮的测试环境我会重新搭一遍而不是直接用第一轮那套。原因有两个第一第一轮环境里全是随手造的脏数据各种奇怪状态混在一起很难做精准验证第二重搭一遍能顺便验证安装文档是否完整这对团队协作很重要。下面是我这次的完整过程。2.1 运行环境与依赖梳理TPshop我这次用的是ThinkPHP 5内核的版本对运行环境的依赖比较明确。先把需要的东西列清楚避免装到一半才发现缺东西。Web服务器Apache 2.4 或 Nginx我更推荐Nginx配置伪静态简单PHP7.2 到 7.4 之间最稳太高或太低都可能报兼容错误MySQL5.7 或 8.0注意字符集要用utf8mb4PHP必需扩展pdo_mysql、mbstring、gd、curl、openssl、fileinfo、zip这里面最容易漏的是fileinfo和openssl前者用于文件类型检测后者在调用外部接口时会用到。缺了它们页面不一定报错但某些功能会静默失败排查起来很折磨人。2.2 安装配置的关键步骤安装本身不复杂但有几个点必须踩准我按顺序说。建库时直接指定字符集CREATE DATABASE tpshop_test DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;这一步如果偷懒用默认字符集后面存中文商品名会变问号。导入官方提供的SQL文件注意导入时也要带上字符集参数否则表结构里的中文注释会乱码。改数据库配置。不同版本位置不太一样一般在application/database.php或者根目录的config/database.php里。把host、库名、用户名、密码、端口改成自己的。站点根目录一定要指向public目录这是TP框架的要求。指向项目根目录会出现目录遍历风险也可能导致入口文件找不到。配置伪静态规则。Nginx下大致是判断文件不存在就转发给index.php具体规则项目文档里有直接复制即可。浏览器访问站点按引导完成初始化设置然后进后台建立管理员账号。注意初始化页面一旦完成如果想重新走一遍流程必须清空数据库重新导入不要试图改配置文件里的初始化标志很容易留下半初始化状态后面各种诡异问题都从这里来。2.3 测试数据的设计与造数数据准备是第二轮的重头戏。我不要有一些数据我要每个状态都有对应数据。因为很多缺陷是通过状态对比才发现的——比如你只有一个正常用户永远测不出未实名用户下单的分支。数据类型需要准备的种类用途用户账号正常、被禁用、未验证邮箱登录与下单身份校验收货地址默认地址、非默认、多地址结算页地址选择商品上架、下架、零库存、多规格搜索与加购边界优惠券未使用、已使用、已过期、未达门槛优惠计算订单待付款、待发货、已发货、已取消后台流转与库存回滚造数的时候我有个小技巧用同一个商品去覆盖多个状态比如一个库存为1的商品既能测加购边界又能测并发下单还能测售罄展示物尽其用。数据量不需要大但状态覆盖必须全这比堆一百条重复数据有用得多。3. 核心业务模块的测试用例设计实战这一节是我这轮投入时间最多的地方。用例设计的质量直接决定测试的覆盖深度我用了几种经典方法交叉验证下面按模块展开。3.1 注册登录等价类与边界值的组合拳注册功能看着简单实际上字段级的校验规则最密集。我用等价类先把输入划成有效和无效两大类再用边界值去卡临界点。手机号字段有效等价类是11位合规号码无效等价类包括10位、12位、含字母、以非1开头、含空格。边界值取10位、11位、12位三个点再加一个首位为1和首位为2的对比。密码字段假设规则是6到20位。边界值就是5位、6位、20位、21位四个点。另外还要测纯数字、纯字母、数字字母混合、含特殊字符、含空格、含中文这几种类型很多系统对中文和空格的处理是有漏洞的。用例编号测试字段输入预期结果REG-01手机号11位合规号码注册成功REG-02手机号10位数字提示格式错误REG-03手机号11位但以2开头提示格式错误REG-04密码5位提示长度不足REG-05密码6位通过校验REG-06密码密码含空格按规则处理登录要比注册多考虑几个维度连续输错密码是否锁定、锁定后多久解锁、验证码错误与过期、账号被禁用时的提示文案是否暴露了敏感信息。最后这点很多人忽略——安全上账号不存在和密码错误最好返回一致的模糊提示避免被人枚举出有效账号。3.2 商品搜索与筛选把组合条件当主角搜索功能的测试重点不在单个关键词而在条件组合。单条件测试只能证明搜索能用组合测试才能暴露筛选逻辑的漏洞。关键词维度要测存在的词、不存在的词、空串、只有空格、超长字符串、含特殊字符百分号、下划线、单引号、英文大小写。尤其单引号要重点测这是SQL注入的经典探针虽然现代框架大多做了防护但验证一下没有坏处。筛选维度要测价格区间、品牌、分类、仅看有货以及这些条件的多选叠加。这里常见的缺陷是条件叠加后结果为空但实际应该有数据通常是SQL的AND和OR拼接出了问题。排序维度测价格升序降序、销量排序、综合排序是否稳定。分页是边界值的高发区第一页、最后一页、超出范围的页码比如只有3页却请求第99页、每页显示数量边界。超出页码时应该返回空列表或跳回首页而不是报500错误我实测就碰到过TPshop某版本翻页越界直接白屏的情况。3.3 购物车与库存最容易被想当然的地方购物车看着是加减数量这么朴素的功能但库存处理逻辑藏得很深。第一个必须搞清楚的问题是库存到底在下单时扣还是在支付成功时扣两种设计各有利弊下单扣库存能防止超卖但会占用库存支付扣库存体验好但容易超卖。你得先读代码或问开发确认否则用例的预期结果全错。数量输入要测的边界0、1、库存量、库存量加1、负数、超大数值、非数字字符、小数。加购数量等于库存时应该成功超过库存时应该拦截并提示剩余数量。价格计算要单独成例单价乘以数量是否等于小计、多商品合计是否正确、数量改动后小计和总计是否实时刷新。金额计算是精度敏感区浮点数容易出问题可以用0.10.2这类经典值去探一探看系统返回的是0.3还是0.30000000000000004。配送费的计算规则通常比较复杂需要关注是否按照冷链商品处理、是否根据距离计算、是否有免运费门槛。这需要重点确认商品的配送规则以及系统是否存在最高限价问题。3.4 下单支付主链路场景法的主场这条链路最适合用场景法。我先定义基本流再逐一扩展备选流。基本流登录用户浏览商品→加入购物车→进入结算页→选择收货地址→选择配送方式→选择支付方式→提交订单→支付成功→订单状态变为待发货。备选流需要覆盖的分支很多我挑几个关键的库存不足时提交订单应拦截并提示未登录状态下点结算应跳转登录并保留购物车未选收货地址提交应给出明确提示而不是静默失败支付中途关闭页面订单状态应停留在待付款且超时后能自动或手动取消优惠券不可用时结算页的金额应实时重算同一账号重复提交同一订单不应生成两笔订单场景前置条件操作预期正常下单库存充足、地址有效全流程提交并支付订单生成、状态待发货库存不足库存为0提交订单拦截并提示重复提交订单已提交快速再次点击只生成一笔订单支付中断选好支付方式不完成支付订单保持待付款注意重复提交是电商缺陷的重灾区测试时一定要用快速连点和网络慢时重复提交两种方式各测一次很多系统只防住了其中一种。3.5 优惠券与满减判定表的最佳舞台营销规则是条件最多、最容易出逻辑漏洞的地方判定表在这里能发挥最大价值。假设我们用一张券需要同时满足四个条件是否登录、订单金额是否达到门槛、券是否在有效期、券是否未被使用。登录达门槛有效期内未使用预期是是是是可用是否是是不可用是是否是不可用是是是否不可用否是是是提示登录更麻烦的是叠加规则和计算顺序。满减和优惠券谁先算折扣之后还算不算满减门槛这些规则在实际项目里经常连产品经理都说不清我吃过不止一次亏。我的做法是把结算页所有能影响的规则列一张优先级表逐条验证金额而不是只看最终数字对不对。因为只看结果可能多个规则相互抵消看起来是对的实际上顺序全错。4. 测试执行、缺陷管理与回归验证用例设计完只是完成了一半执行过程和缺陷管理同样决定测试质量。这一轮我按冒烟、功能、回归三个阶段推进。4.1 冒烟测试先行避免浪费每拿到一个新构建的版本我不会直接全量执行用例而是先跑一遍冒烟。冒烟用例只覆盖最核心的几条能不能登录、能不能搜索、能不能加购、能不能下单。这几条里有一条挂了说明这个版本是坏的直接打回去让开发重新构建没必要浪费时间去测细节。我做冒烟的时候有个习惯同一组用例固定下来每次都跑一样的。这样版本的稳定性趋势能看出来如果冒烟通过率从100%掉到60%说明最近的改动风险很大后续就要投入更多回归精力。4.2 缺陷单要写成能复现的故事低质量的缺陷单是点了没反应高质量的缺陷单是别人照着就能复现。我写缺陷单固定包含这几块标题、环境版本、前置条件、操作步骤、预期结果、实际结果、附件。标题要一句话讲清楚问题比如零库存商品仍可加入购物车且不提示而不是笼统的购物车有问题。步骤要写到可复现的程度前置数据也要写清楚比如使用账号test01商品A库存为0。截图或录屏尽量附上尤其是那种偶现的问题一次录屏胜过十次文字描述。偶现问题我会在描述里注明复现频率比如10次尝试复现3次这个信息对开发定位问题很关键。4.3 缺陷状态流转与跟踪缺陷不是提完就结束了要盯着它走完整个生命周期。我用的是比较经典的一套状态新建、已确认、已修复、待验证、已关闭另外还有拒绝、延期两个分支。提缺陷之后我会主动关注开发的处理结果。如果被打上拒绝我会去看拒绝理由是否合理——是设计如此还是无法复现。设计如此的话要回到需求去确认很多时候是需求文档本身没写清楚。无法复现的话我要提供更详细的复现路径或者环境信息。这个来回沟通的过程往往比提缺陷本身更能提升测试的严谨性。4.4 回归测试与用例维护每修复一批缺陷就必须做回归。回归不是把修复的那条用例再跑一遍就完事而是要覆盖可能被这次修改影响的周边功能。比如开发改了购物车的价格计算逻辑那不仅要回归购物车还要回归结算页、订单金额、优惠计算因为它们是共用计算方法的。回归过程中我发现用例本身也需要维护。有些用例在第二轮就过时了比如某个按钮的文案改了、某个校验规则放松了对应的预期结果就要更新。我习惯在每轮测试结束后统一梳理一遍用例把失效的删掉、把新发现的边界补充进去这样用例库是活的下一轮直接能复用。5. 常见问题与排查技巧实录这一节全是实打实踩出来的比前面任何一节都值钱。TPshop部署和测试过程中下面这几类问题我至少碰到过一次。5.1 环境类问题排查页面报500错误或白屏先看Web服务器错误日志和PHP错误日志不要凭感觉猜。最常见的原因是PHP扩展没装全、伪静态没配、目录权限不对。TP框架在调试模式关闭时会把错误吞掉所以开发阶段建议把调试开关打开能看到具体报错位置。页面能打开但样式全丢99%是静态资源路径问题。检查站点根目录是否指向了public以及配置里的域名是否带了口号或端口不一致。这种情况不影响功能测试但会影响UI检查最好一开始就解决。数据库连不上先确认MySQL服务是否启动再核对配置文件里的账号密码端口。有个容易被忽略的点是MySQL 8.0的默认认证方式变了老版本的PHP连接可能报错需要在数据库里调整账号的认证插件。5.2 数据类问题排查中文乱码几乎都和字符集有关。检查三处建库字符集、连接字符集、以及PHP端设置的字符集。三处不一致就会乱码缺一处也会。时间对不上服务器时区和PHP时区设置不一致导致订单时间可能差好几个小时。测试时如果发现下单时间和实际时间对不上先查时区再查其他。数据状态不一致这是最烧脑的一类。比如订单状态是已取消但库存没有回滚。这类问题我一般直接查数据库对应的几张表对比它们的数据是否矛盾。电商的很多缺陷本质就是多张表之间不同步顺着这个思路去查往往很快能定位。5.3 业务逻辑理解偏差有一类问题其实不是缺陷是我理解错了规则。比如我一度认为购物车改数量不该影响库存实测发现系统设计就是加购即锁库存。这种情况最好的办法是测试前跟开发或产品把规则对齐把容易产生歧义的规则库存扣减时机、优惠叠加顺序、订单超时时间逐条确认并记录下来形成一份规则清单。有了它用例的预期结果才站得住脚。5.4 常见问题速查表现象可能原因排查方向页面500扩展缺失、权限、伪静态错误日志优先样式丢失根目录指向错误检查public指向中文乱码字符集三处不一致库、连接、PHP端订单库存不同步事务或逻辑缺陷对比相关数据表优惠金额不对计算顺序或精度逐条核对规则翻页报错页码越界未处理边界值用例这张表我贴在测试环境的浏览器收藏夹里出问题时先扫一眼能省掉不少瞎试的时间。6. 这轮测试下来的一些个人体会做到这里我对测试基础这四个字的理解又深了一层。工具和方法都是死的真正拉开差距的是对业务的理解深度和对细节的较真程度。同一个购物车有人测出来能用有人能测出来七八个边界缺陷差别不在于懂多少测试理论而在于愿不愿意多问一句如果这里出问题会怎样。还有个很实际的建议测电商系统一定要自己完整地用一遍当你自己的钱和收货地址挂上去的时候你会突然发现很多之前没注意的细节。我这次就是自己下了一单结果发现支付成功页的金额和订单详情页对不上这个在纯点按钮的测试里是发现不了的。下一轮我打算做两件事一是把已经稳定的主链路用例整理成可复用的用例集二是挑几条高频回归的链路尝试自动化先从登录和加购这种最稳定的开始。仓库里的代码和用例都可以直接拿去复现如果你也在这条路上按这个顺序走一遍效率应该不会差。
TPshop电商系统第二轮测试：链路贯通与核心业务用例设计
电商后台的测试只要碰到钱和库存这两样东西坑就永远不会少。我这次接着上一轮的进度把TPshop这套开源商城的测试继续往深里做。上一轮基本是把环境跑起来、把前后台页面点了一遍属于知道它长什么样的阶段这一轮要做的事情完全不一样——要把注册登录、商品搜索、购物车、下单支付、后台订单处理这几条链路真正打通用系统的测试方法去验证它在各种边界和异常下的表现。如果你正在学软件测试或者手头刚接手一个电商类项目不知道从哪儿下手这篇内容应该能给你一套可以直接照着做的路径。我会把用例怎么设计、数据怎么准备、缺陷怎么描述、遇到问题怎么排查都写清楚尽量做到看完就能用。1. 二次测试的整体思路与范围界定做第二轮测试最容易犯的毛病是拿着第一轮的结果再点一遍。我一开始也差点这么干后来发现这样纯属浪费时间。第一轮的产出是页面能不能打开、元素能不能点第二轮真正要解决的是业务流程能不能走通、数据在链路里流转是否一致。这是两个完全不同层次的目标思路必须先掰正。1.1 从单点校验转向链路贯通单点校验关注的是孤立的功能点比如手机号格式对不对、搜索框能不能输入。链路贯通关注的是一个用户在系统里完成一次完整交易这件事。举个具体的单点测试只会告诉你加入购物车按钮点击有反应链路测试会追问——加购之后库存数字变了吗结算页的价格和加购时一致吗提交订单后购物车里的条目清空了吗取消订单后库存回来了吗这一连串问题才是电商系统真正的风险区。我把这套逻辑总结成一句话能点的按钮不叫功能能走完的路才叫功能。TPshop里一个看似简单的下单动作背后牵扯到商品表、库存表、订单表、订单详情表、购物车表、优惠券表、用户地址表至少六七张表的联动写入。任何一处写入失败或者条件判断写偏都会产生钱付了订单没生成或者库存扣了两次这种灾难级问题。第二轮测试的全部价值就在于提前把这些灾难找出来。1.2 测试范围与优先级矩阵项目时间永远是紧张的不可能所有模块平均用力。我的做法是先画一张范围表把模块按业务价值和出错代价排优先级。判断标准很简单涉及金额和库存的排最高涉及用户身份的排次高纯展示类的排最低。模块业务价值出错代价优先级下单支付链路核心转化极高P0购物车与库存核心转化极高P0优惠券与满减影响成交高P0注册登录身份入口高P1商品搜索与筛选导购体验中P1后台订单管理履约基础高P1前台商品展示浏览体验低P2个人中心信息辅助功能低P2这张表的作用不是分类好看而是决定执行顺序。P0和P1必须测透P2在时间允许时覆盖主流程即可。很多新手会把大量时间花在修改昵称更换头像这种边角料上结果核心链路反而没测到这是很典型的资源错配。1.3 手工优先自动化后置的阶段判断经常有人问第二轮是不是该上自动化了。我的答案通常是先别急。自动化测试的前提是业务规则稳定、页面结构稳定、用例已经经过手工验证。第二轮的电商系统往往还处在规则理解阶段比如优惠券和满减能不能叠加这种问题我自己都还没搞清楚写出来的自动化脚本只会把错误的预期固化下来。所以我的节奏是手工先把每条链路的规则摸清楚把最容易出问题的节点做成稳定的手工回归用例等这轮测完、业务规则基本冻结之后再把那些高频重复执行的用例比如登录、加购、下单主流程沉淀成自动化脚本。顺序反过来做返工的成本会高得离谱。2. 独立测试环境的搭建与数据准备第二轮的测试环境我会重新搭一遍而不是直接用第一轮那套。原因有两个第一第一轮环境里全是随手造的脏数据各种奇怪状态混在一起很难做精准验证第二重搭一遍能顺便验证安装文档是否完整这对团队协作很重要。下面是我这次的完整过程。2.1 运行环境与依赖梳理TPshop我这次用的是ThinkPHP 5内核的版本对运行环境的依赖比较明确。先把需要的东西列清楚避免装到一半才发现缺东西。Web服务器Apache 2.4 或 Nginx我更推荐Nginx配置伪静态简单PHP7.2 到 7.4 之间最稳太高或太低都可能报兼容错误MySQL5.7 或 8.0注意字符集要用utf8mb4PHP必需扩展pdo_mysql、mbstring、gd、curl、openssl、fileinfo、zip这里面最容易漏的是fileinfo和openssl前者用于文件类型检测后者在调用外部接口时会用到。缺了它们页面不一定报错但某些功能会静默失败排查起来很折磨人。2.2 安装配置的关键步骤安装本身不复杂但有几个点必须踩准我按顺序说。建库时直接指定字符集CREATE DATABASE tpshop_test DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;这一步如果偷懒用默认字符集后面存中文商品名会变问号。导入官方提供的SQL文件注意导入时也要带上字符集参数否则表结构里的中文注释会乱码。改数据库配置。不同版本位置不太一样一般在application/database.php或者根目录的config/database.php里。把host、库名、用户名、密码、端口改成自己的。站点根目录一定要指向public目录这是TP框架的要求。指向项目根目录会出现目录遍历风险也可能导致入口文件找不到。配置伪静态规则。Nginx下大致是判断文件不存在就转发给index.php具体规则项目文档里有直接复制即可。浏览器访问站点按引导完成初始化设置然后进后台建立管理员账号。注意初始化页面一旦完成如果想重新走一遍流程必须清空数据库重新导入不要试图改配置文件里的初始化标志很容易留下半初始化状态后面各种诡异问题都从这里来。2.3 测试数据的设计与造数数据准备是第二轮的重头戏。我不要有一些数据我要每个状态都有对应数据。因为很多缺陷是通过状态对比才发现的——比如你只有一个正常用户永远测不出未实名用户下单的分支。数据类型需要准备的种类用途用户账号正常、被禁用、未验证邮箱登录与下单身份校验收货地址默认地址、非默认、多地址结算页地址选择商品上架、下架、零库存、多规格搜索与加购边界优惠券未使用、已使用、已过期、未达门槛优惠计算订单待付款、待发货、已发货、已取消后台流转与库存回滚造数的时候我有个小技巧用同一个商品去覆盖多个状态比如一个库存为1的商品既能测加购边界又能测并发下单还能测售罄展示物尽其用。数据量不需要大但状态覆盖必须全这比堆一百条重复数据有用得多。3. 核心业务模块的测试用例设计实战这一节是我这轮投入时间最多的地方。用例设计的质量直接决定测试的覆盖深度我用了几种经典方法交叉验证下面按模块展开。3.1 注册登录等价类与边界值的组合拳注册功能看着简单实际上字段级的校验规则最密集。我用等价类先把输入划成有效和无效两大类再用边界值去卡临界点。手机号字段有效等价类是11位合规号码无效等价类包括10位、12位、含字母、以非1开头、含空格。边界值取10位、11位、12位三个点再加一个首位为1和首位为2的对比。密码字段假设规则是6到20位。边界值就是5位、6位、20位、21位四个点。另外还要测纯数字、纯字母、数字字母混合、含特殊字符、含空格、含中文这几种类型很多系统对中文和空格的处理是有漏洞的。用例编号测试字段输入预期结果REG-01手机号11位合规号码注册成功REG-02手机号10位数字提示格式错误REG-03手机号11位但以2开头提示格式错误REG-04密码5位提示长度不足REG-05密码6位通过校验REG-06密码密码含空格按规则处理登录要比注册多考虑几个维度连续输错密码是否锁定、锁定后多久解锁、验证码错误与过期、账号被禁用时的提示文案是否暴露了敏感信息。最后这点很多人忽略——安全上账号不存在和密码错误最好返回一致的模糊提示避免被人枚举出有效账号。3.2 商品搜索与筛选把组合条件当主角搜索功能的测试重点不在单个关键词而在条件组合。单条件测试只能证明搜索能用组合测试才能暴露筛选逻辑的漏洞。关键词维度要测存在的词、不存在的词、空串、只有空格、超长字符串、含特殊字符百分号、下划线、单引号、英文大小写。尤其单引号要重点测这是SQL注入的经典探针虽然现代框架大多做了防护但验证一下没有坏处。筛选维度要测价格区间、品牌、分类、仅看有货以及这些条件的多选叠加。这里常见的缺陷是条件叠加后结果为空但实际应该有数据通常是SQL的AND和OR拼接出了问题。排序维度测价格升序降序、销量排序、综合排序是否稳定。分页是边界值的高发区第一页、最后一页、超出范围的页码比如只有3页却请求第99页、每页显示数量边界。超出页码时应该返回空列表或跳回首页而不是报500错误我实测就碰到过TPshop某版本翻页越界直接白屏的情况。3.3 购物车与库存最容易被想当然的地方购物车看着是加减数量这么朴素的功能但库存处理逻辑藏得很深。第一个必须搞清楚的问题是库存到底在下单时扣还是在支付成功时扣两种设计各有利弊下单扣库存能防止超卖但会占用库存支付扣库存体验好但容易超卖。你得先读代码或问开发确认否则用例的预期结果全错。数量输入要测的边界0、1、库存量、库存量加1、负数、超大数值、非数字字符、小数。加购数量等于库存时应该成功超过库存时应该拦截并提示剩余数量。价格计算要单独成例单价乘以数量是否等于小计、多商品合计是否正确、数量改动后小计和总计是否实时刷新。金额计算是精度敏感区浮点数容易出问题可以用0.10.2这类经典值去探一探看系统返回的是0.3还是0.30000000000000004。配送费的计算规则通常比较复杂需要关注是否按照冷链商品处理、是否根据距离计算、是否有免运费门槛。这需要重点确认商品的配送规则以及系统是否存在最高限价问题。3.4 下单支付主链路场景法的主场这条链路最适合用场景法。我先定义基本流再逐一扩展备选流。基本流登录用户浏览商品→加入购物车→进入结算页→选择收货地址→选择配送方式→选择支付方式→提交订单→支付成功→订单状态变为待发货。备选流需要覆盖的分支很多我挑几个关键的库存不足时提交订单应拦截并提示未登录状态下点结算应跳转登录并保留购物车未选收货地址提交应给出明确提示而不是静默失败支付中途关闭页面订单状态应停留在待付款且超时后能自动或手动取消优惠券不可用时结算页的金额应实时重算同一账号重复提交同一订单不应生成两笔订单场景前置条件操作预期正常下单库存充足、地址有效全流程提交并支付订单生成、状态待发货库存不足库存为0提交订单拦截并提示重复提交订单已提交快速再次点击只生成一笔订单支付中断选好支付方式不完成支付订单保持待付款注意重复提交是电商缺陷的重灾区测试时一定要用快速连点和网络慢时重复提交两种方式各测一次很多系统只防住了其中一种。3.5 优惠券与满减判定表的最佳舞台营销规则是条件最多、最容易出逻辑漏洞的地方判定表在这里能发挥最大价值。假设我们用一张券需要同时满足四个条件是否登录、订单金额是否达到门槛、券是否在有效期、券是否未被使用。登录达门槛有效期内未使用预期是是是是可用是否是是不可用是是否是不可用是是是否不可用否是是是提示登录更麻烦的是叠加规则和计算顺序。满减和优惠券谁先算折扣之后还算不算满减门槛这些规则在实际项目里经常连产品经理都说不清我吃过不止一次亏。我的做法是把结算页所有能影响的规则列一张优先级表逐条验证金额而不是只看最终数字对不对。因为只看结果可能多个规则相互抵消看起来是对的实际上顺序全错。4. 测试执行、缺陷管理与回归验证用例设计完只是完成了一半执行过程和缺陷管理同样决定测试质量。这一轮我按冒烟、功能、回归三个阶段推进。4.1 冒烟测试先行避免浪费每拿到一个新构建的版本我不会直接全量执行用例而是先跑一遍冒烟。冒烟用例只覆盖最核心的几条能不能登录、能不能搜索、能不能加购、能不能下单。这几条里有一条挂了说明这个版本是坏的直接打回去让开发重新构建没必要浪费时间去测细节。我做冒烟的时候有个习惯同一组用例固定下来每次都跑一样的。这样版本的稳定性趋势能看出来如果冒烟通过率从100%掉到60%说明最近的改动风险很大后续就要投入更多回归精力。4.2 缺陷单要写成能复现的故事低质量的缺陷单是点了没反应高质量的缺陷单是别人照着就能复现。我写缺陷单固定包含这几块标题、环境版本、前置条件、操作步骤、预期结果、实际结果、附件。标题要一句话讲清楚问题比如零库存商品仍可加入购物车且不提示而不是笼统的购物车有问题。步骤要写到可复现的程度前置数据也要写清楚比如使用账号test01商品A库存为0。截图或录屏尽量附上尤其是那种偶现的问题一次录屏胜过十次文字描述。偶现问题我会在描述里注明复现频率比如10次尝试复现3次这个信息对开发定位问题很关键。4.3 缺陷状态流转与跟踪缺陷不是提完就结束了要盯着它走完整个生命周期。我用的是比较经典的一套状态新建、已确认、已修复、待验证、已关闭另外还有拒绝、延期两个分支。提缺陷之后我会主动关注开发的处理结果。如果被打上拒绝我会去看拒绝理由是否合理——是设计如此还是无法复现。设计如此的话要回到需求去确认很多时候是需求文档本身没写清楚。无法复现的话我要提供更详细的复现路径或者环境信息。这个来回沟通的过程往往比提缺陷本身更能提升测试的严谨性。4.4 回归测试与用例维护每修复一批缺陷就必须做回归。回归不是把修复的那条用例再跑一遍就完事而是要覆盖可能被这次修改影响的周边功能。比如开发改了购物车的价格计算逻辑那不仅要回归购物车还要回归结算页、订单金额、优惠计算因为它们是共用计算方法的。回归过程中我发现用例本身也需要维护。有些用例在第二轮就过时了比如某个按钮的文案改了、某个校验规则放松了对应的预期结果就要更新。我习惯在每轮测试结束后统一梳理一遍用例把失效的删掉、把新发现的边界补充进去这样用例库是活的下一轮直接能复用。5. 常见问题与排查技巧实录这一节全是实打实踩出来的比前面任何一节都值钱。TPshop部署和测试过程中下面这几类问题我至少碰到过一次。5.1 环境类问题排查页面报500错误或白屏先看Web服务器错误日志和PHP错误日志不要凭感觉猜。最常见的原因是PHP扩展没装全、伪静态没配、目录权限不对。TP框架在调试模式关闭时会把错误吞掉所以开发阶段建议把调试开关打开能看到具体报错位置。页面能打开但样式全丢99%是静态资源路径问题。检查站点根目录是否指向了public以及配置里的域名是否带了口号或端口不一致。这种情况不影响功能测试但会影响UI检查最好一开始就解决。数据库连不上先确认MySQL服务是否启动再核对配置文件里的账号密码端口。有个容易被忽略的点是MySQL 8.0的默认认证方式变了老版本的PHP连接可能报错需要在数据库里调整账号的认证插件。5.2 数据类问题排查中文乱码几乎都和字符集有关。检查三处建库字符集、连接字符集、以及PHP端设置的字符集。三处不一致就会乱码缺一处也会。时间对不上服务器时区和PHP时区设置不一致导致订单时间可能差好几个小时。测试时如果发现下单时间和实际时间对不上先查时区再查其他。数据状态不一致这是最烧脑的一类。比如订单状态是已取消但库存没有回滚。这类问题我一般直接查数据库对应的几张表对比它们的数据是否矛盾。电商的很多缺陷本质就是多张表之间不同步顺着这个思路去查往往很快能定位。5.3 业务逻辑理解偏差有一类问题其实不是缺陷是我理解错了规则。比如我一度认为购物车改数量不该影响库存实测发现系统设计就是加购即锁库存。这种情况最好的办法是测试前跟开发或产品把规则对齐把容易产生歧义的规则库存扣减时机、优惠叠加顺序、订单超时时间逐条确认并记录下来形成一份规则清单。有了它用例的预期结果才站得住脚。5.4 常见问题速查表现象可能原因排查方向页面500扩展缺失、权限、伪静态错误日志优先样式丢失根目录指向错误检查public指向中文乱码字符集三处不一致库、连接、PHP端订单库存不同步事务或逻辑缺陷对比相关数据表优惠金额不对计算顺序或精度逐条核对规则翻页报错页码越界未处理边界值用例这张表我贴在测试环境的浏览器收藏夹里出问题时先扫一眼能省掉不少瞎试的时间。6. 这轮测试下来的一些个人体会做到这里我对测试基础这四个字的理解又深了一层。工具和方法都是死的真正拉开差距的是对业务的理解深度和对细节的较真程度。同一个购物车有人测出来能用有人能测出来七八个边界缺陷差别不在于懂多少测试理论而在于愿不愿意多问一句如果这里出问题会怎样。还有个很实际的建议测电商系统一定要自己完整地用一遍当你自己的钱和收货地址挂上去的时候你会突然发现很多之前没注意的细节。我这次就是自己下了一单结果发现支付成功页的金额和订单详情页对不上这个在纯点按钮的测试里是发现不了的。下一轮我打算做两件事一是把已经稳定的主链路用例整理成可复用的用例集二是挑几条高频回归的链路尝试自动化先从登录和加购这种最稳定的开始。仓库里的代码和用例都可以直接拿去复现如果你也在这条路上按这个顺序走一遍效率应该不会差。
