企业官网建设流程全解析

电商后台的测试，只要碰到"钱"和"库存"这两样东西，坑就永远不会少。我这次接着上一轮的进度，把TPshop这套开源商城的测试继续往深里做。上一轮基本是把环境跑起来、把前后台页面点了一遍，属于"知道它长什么样"的阶段；这一轮要做的事情完全不一样——要把注册登录、商品搜索、购物车、下单支付、后台订单处理这几条链路真正打通，用系统的测试方法去验证它在各种边界和异常下的表现。如果你正在学软件测试，或者手头刚接手一个电商类项目不知道从哪儿下手，这篇内容应该能给你一套可以直接照着做的路径。我会把用例怎么设计、数据怎么准备、缺陷怎么描述、遇到问题怎么排查都写清楚，尽量做到看完就能用。

1. 二次测试的整体思路与范围界定

做第二轮测试最容易犯的毛病，是拿着第一轮的结果"再点一遍"。我一开始也差点这么干，后来发现这样纯属浪费时间。第一轮的产出是"页面能不能打开、元素能不能点"，第二轮真正要解决的是"业务流程能不能走通、数据在链路里流转是否一致"。这是两个完全不同层次的目标，思路必须先掰正。

1.1 从单点校验转向链路贯通

单点校验关注的是孤立的功能点，比如手机号格式对不对、搜索框能不能输入。链路贯通关注的是"一个用户在系统里完成一次完整交易"这件事。举个具体的：单点测试只会告诉你"加入购物车按钮点击有反应"，链路测试会追问——加购之后库存数字变了吗？结算页的价格和加购时一致吗？提交订单后购物车里的条目清空了吗？取消订单后库存回来了吗？这一连串问题，才是电商系统真正的风险区。

我把这套逻辑总结成一句话：能点的按钮不叫功能，能走完的路才叫功能。TPshop里一个看似简单的下单动作，背后牵扯到商品表、库存表、订单表、订单详情表、购物车表、优惠券表、用户地址表至少六七张表的联动写入。任何一处写入失败或者条件判断写偏，都会产生"钱付了订单没生成"或者"库存扣了两次"这种灾难级问题。第二轮测试的全部价值，就在于提前把这些灾难找出来。

1.2 测试范围与优先级矩阵

项目时间永远是紧张的，不可能所有模块平均用力。我的做法是先画一张范围表，把模块按业务价值和出错代价排优先级。判断标准很简单：涉及金额和库存的排最高，涉及用户身份的排次高，纯展示类的排最低。

这张表的作用不是分类好看，而是决定执行顺序。P0和P1必须测透，P2在时间允许时覆盖主流程即可。很多新手会把大量时间花在"修改昵称""更换头像"这种边角料上，结果核心链路反而没测到，这是很典型的资源错配。

1.3 手工优先，自动化后置的阶段判断

经常有人问第二轮是不是该上自动化了。我的答案通常是：先别急。自动化测试的前提是业务规则稳定、页面结构稳定、用例已经经过手工验证。第二轮的电商系统往往还处在规则理解阶段，比如"优惠券和满减能不能叠加"这种问题，我自己都还没搞清楚，写出来的自动化脚本只会把错误的预期固化下来。

所以我的节奏是：手工先把每条链路的规则摸清楚，把最容易出问题的节点做成稳定的手工回归用例，等这轮测完、业务规则基本冻结之后，再把那些高频重复执行的用例（比如登录、加购、下单主流程）沉淀成自动化脚本。顺序反过来做，返工的成本会高得离谱。

2. 独立测试环境的搭建与数据准备

第二轮的测试环境我会重新搭一遍，而不是直接用第一轮那套。原因有两个：第一，第一轮环境里全是随手造的脏数据，各种奇怪状态混在一起，很难做精准验证；第二，重搭一遍能顺便验证安装文档是否完整，这对团队协作很重要。下面是我这次的完整过程。

2.1 运行环境与依赖梳理

TPshop我这次用的是ThinkPHP 5内核的版本，对运行环境的依赖比较明确。先把需要的东西列清楚，避免装到一半才发现缺东西。

• Web服务器：Apache 2.4 或 Nginx，我更推荐Nginx，配置伪静态简单
• PHP：7.2 到 7.4 之间最稳，太高或太低都可能报兼容错误
• MySQL：5.7 或 8.0，注意字符集要用utf8mb4
• PHP必需扩展：pdo_mysql、mbstring、gd、curl、openssl、fileinfo、zip

这里面最容易漏的是fileinfo和openssl，前者用于文件类型检测，后者在调用外部接口时会用到。缺了它们，页面不一定报错，但某些功能会静默失败，排查起来很折磨人。

2.2 安装配置的关键步骤

安装本身不复杂，但有几个点必须踩准，我按顺序说。

1. 建库时直接指定字符集：CREATE DATABASE tpshop_test DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;这一步如果偷懒用默认字符集，后面存中文商品名会变问号。
2. 导入官方提供的SQL文件，注意导入时也要带上字符集参数，否则表结构里的中文注释会乱码。
3. 改数据库配置。不同版本位置不太一样，一般在application/database.php或者根目录的config/database.php里。把host、库名、用户名、密码、端口改成自己的。
4. 站点根目录一定要指向public目录，这是TP框架的要求。指向项目根目录会出现目录遍历风险，也可能导致入口文件找不到。
5. 配置伪静态规则。Nginx下大致是判断文件不存在就转发给index.php，具体规则项目文档里有，直接复制即可。
6. 浏览器访问站点，按引导完成初始化设置，然后进后台建立管理员账号。

注意：初始化页面一旦完成，如果想重新走一遍流程，必须清空数据库重新导入，不要试图改配置文件里的初始化标志，很容易留下半初始化状态，后面各种诡异问题都从这里来。

2.3 测试数据的设计与造数

数据准备是第二轮的重头戏。我不要"有一些数据"，我要"每个状态都有对应数据"。因为很多缺陷是通过状态对比才发现的——比如你只有一个正常用户，永远测不出"未实名用户下单"的分支。

造数的时候我有个小技巧：用同一个商品去覆盖多个状态，比如一个"库存为1"的商品既能测加购边界，又能测并发下单，还能测售罄展示，物尽其用。数据量不需要大，但状态覆盖必须全，这比堆一百条重复数据有用得多。

3. 核心业务模块的测试用例设计实战

这一节是我这轮投入时间最多的地方。用例设计的质量直接决定测试的覆盖深度，我用了几种经典方法交叉验证，下面按模块展开。

3.1 注册登录：等价类与边界值的组合拳

注册功能看着简单，实际上字段级的校验规则最密集。我用等价类先把输入划成有效和无效两大类，再用边界值去卡临界点。

手机号字段：有效等价类是11位合规号码，无效等价类包括10位、12位、含字母、以非1开头、含空格。边界值取10位、11位、12位三个点，再加一个首位为1和首位为2的对比。

密码字段：假设规则是6到20位。边界值就是5位、6位、20位、21位四个点。另外还要测纯数字、纯字母、数字字母混合、含特殊字符、含空格、含中文这几种类型，很多系统对中文和空格的处理是有漏洞的。

登录要比注册多考虑几个维度：连续输错密码是否锁定、锁定后多久解锁、验证码错误与过期、账号被禁用时的提示文案是否暴露了敏感信息。最后这点很多人忽略——安全上，账号不存在和密码错误最好返回一致的模糊提示，避免被人枚举出有效账号。

3.2 商品搜索与筛选：把组合条件当主角

搜索功能的测试重点不在单个关键词，而在条件组合。单条件测试只能证明"搜索能用"，组合测试才能暴露筛选逻辑的漏洞。

关键词维度要测：存在的词、不存在的词、空串、只有空格、超长字符串、含特殊字符（百分号、下划线、单引号）、英文大小写。尤其单引号要重点测，这是SQL注入的经典探针，虽然现代框架大多做了防护，但验证一下没有坏处。

筛选维度要测：价格区间、品牌、分类、仅看有货，以及这些条件的多选叠加。这里常见的缺陷是条件叠加后结果为空但实际应该有数据，通常是SQL的AND和OR拼接出了问题。排序维度测价格升序降序、销量排序、综合排序是否稳定。

分页是边界值的高发区：第一页、最后一页、超出范围的页码（比如只有3页却请求第99页）、每页显示数量边界。超出页码时应该返回空列表或跳回首页，而不是报500错误，我实测就碰到过TPshop某版本翻页越界直接白屏的情况。

3.3 购物车与库存：最容易被想当然的地方

购物车看着是"加减数量"这么朴素的功能，但库存处理逻辑藏得很深。第一个必须搞清楚的问题是：库存到底在下单时扣，还是在支付成功时扣？两种设计各有利弊，下单扣库存能防止超卖但会占用库存，支付扣库存体验好但容易超卖。你得先读代码或问开发确认，否则用例的预期结果全错。

数量输入要测的边界：0、1、库存量、库存量加1、负数、超大数值、非数字字符、小数。加购数量等于库存时应该成功，超过库存时应该拦截并提示剩余数量。

价格计算要单独成例：单价乘以数量是否等于小计、多商品合计是否正确、数量改动后小计和总计是否实时刷新。金额计算是精度敏感区，浮点数容易出问题，可以用0.1+0.2这类经典值去探一探，看系统返回的是0.3还是0.30000000000000004。

配送费的计算规则通常比较复杂，需要关注是否按照冷链商品处理、是否根据距离计算、是否有免运费门槛。这需要重点确认商品的配送规则，以及系统是否存在最高限价问题。

3.4 下单支付主链路：场景法的主场

这条链路最适合用场景法。我先定义基本流，再逐一扩展备选流。

基本流：登录用户浏览商品→加入购物车→进入结算页→选择收货地址→选择配送方式→选择支付方式→提交订单→支付成功→订单状态变为待发货。

备选流需要覆盖的分支很多，我挑几个关键的：

• 库存不足时提交订单，应拦截并提示
• 未登录状态下点结算，应跳转登录并保留购物车
• 未选收货地址提交，应给出明确提示而不是静默失败
• 支付中途关闭页面，订单状态应停留在待付款，且超时后能自动或手动取消
• 优惠券不可用时，结算页的金额应实时重算
• 同一账号重复提交同一订单，不应生成两笔订单

注意：重复提交是电商缺陷的重灾区，测试时一定要用"快速连点"和"网络慢时重复提交"两种方式各测一次，很多系统只防住了其中一种。

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 常见问题速查表

这张表我贴在测试环境的浏览器收藏夹里，出问题时先扫一眼，能省掉不少瞎试的时间。

6. 这轮测试下来的一些个人体会

做到这里，我对"测试基础"这四个字的理解又深了一层。工具和方法都是死的，真正拉开差距的是对业务的理解深度和对细节的较真程度。同一个购物车，有人测出来"能用"，有人能测出来七八个边界缺陷，差别不在于懂多少测试理论，而在于愿不愿意多问一句"如果这里出问题会怎样"。

还有个很实际的建议：测电商系统一定要自己完整地用一遍，当你自己的钱和收货地址挂上去的时候，你会突然发现很多之前没注意的细节。我这次就是自己下了一单，结果发现支付成功页的金额和订单详情页对不上，这个在纯点按钮的测试里是发现不了的。

下一轮我打算做两件事：一是把已经稳定的主链路用例整理成可复用的用例集，二是挑几条高频回归的链路尝试自动化，先从登录和加购这种最稳定的开始。仓库里的代码和用例都可以直接拿去复现，如果你也在这条路上，按这个顺序走一遍，效率应该不会差。