一、项目简介

对电商Web系统开展质量验证，覆盖功能测试、接口与抓包测试、自动化测试、性能测试 被测模块：用户登录注册、首页商品、商品搜索详情、购物车、订单结算、个人中心、权限越权校验。

测试目标：

1. 功能测试保障业务流程可用，挖掘业务功能缺陷；
2. UI自动化实现核心场景回归，减少重复手工回归工作量；
3. 使用Fiddler抓包，分析接口请求响应，发现参数校验、权限越权类后端漏洞；
4. 使用Postman 独立构造接口请求，脱离前端页面直接验证后端接口逻辑；
5. 性能压测验证系统并发承压能力，提前识别性能瓶颈。

测试环境：内网测试服务器、MySQL8.0，Chrome / Edge浏览器，Fiddler代理抓包。

二、功能测试

测试范围

登录注册、商品浏览搜索、购物车增删改查、订单提交取消、未登录越权访问拦截。

• 总用例：112条  通过：104  失败：8 通过率：92.86%

缺陷分级统计：

缺陷等级	数量	已修复	待修复
严重	1	1	0
一般	5	4	1
轻微	2	2	0

结果说明：阻断上线的严重bug全部修复回归通过。遗留1个一般缺陷：购物车输入超大数字提示文案不友好，不影响主业务，下个迭代优化。 核心交易链路：登录→浏览商品→加购→下单，完整跑通。

三、接口抓包测试

本次使用Fiddler作为抓包代理工具，拦截浏览器和服务端之间HTTP/HTTPS请求，对比单纯浏览器F12，Fiddler可以修改请求参数、重放请求、篡改请求报文，做越权和参数篡改测试。

使用 Postman、手工构造请求对个人设置以及下单等核心功能接口进行接口测试。

重点被测接口：登录、商品列表、商品详情、购物车新增/修改、订单提交接口。

Fiddler 测试操作要点

1. 配置Fiddler解密HTTPS，开启代理，浏览器走Fiddler代理；
2. 抓取正常业务操作的请求，查看请求方式、请求头、Cookie、请求入参、响应状态码、返回JSON报文；
3. 使用Replay(Reissue)重放接口；使用Composer构造自定义请求，篡改参数；
4. 修改请求参数：传入空值、负数、超长字符串、非法字符，提交给后端，校验接口防护逻辑；
5. 越权测试：复制登录后的Cookie，修改接口里用户ID、购物车ID、订单ID，尝试访问其他用户的数据；
6. 对比接口返回数据和前端页面展示数据，校验前后端数据一致性。

Postman 接口测试操作要点

1. 新建接口集合，按模块分组：登录、商品、购物车、订单、个人设置；
2. 配置环境变量，保存测试环境域名、token，接口之间实现参数传递；
3. 录入接口请求方式、请求头、JSON 请求体，发送请求；
4. 在 Tests 脚本编写断言：校验响应状态码、返回字段、业务数据正确性；
5. 构造异常参数：空参数、超长文本、非法 ID，发送请求，校验后端异常处理逻辑；
6. 批量运行集合，批量执行接口用例，统计接口通过情况。

抓包 & 接口发现问题：

1. 修改购物车数量接口，通过 Fiddler 篡改参数传入负数，后端没有参数校验，数据库写入负数库存；开发已修复，增加参数范围校验。
2. 未登录状态，Fiddler 构造请求直接调用订单查询接口，服务端没有返回权限拦截，直接返回空数据，权限校验逻辑不完善；已优化增加鉴权拦截。
3. 登录接口密码明文传输（测试环境），生产环境建议做密码加密处理。
4. Postman 测试个人资料修改接口，传入超长昵称，后端未做长度限制，数据库存储超长字符串，已增加字段长度校验。

小结：页面上看不到的后端漏洞，Fiddler 篡改请求很容易复现；搭配 Postman 独立构造接口请求，脱离前端页面直接验证后端接口逻辑，抓包 + 接口请求是手工测试非常重要的补充，重点验证后端防护，不能只相信前端页面校验。

四、自动化测试 

测试用例

自动化测试/MallUIAutoTest/电商测试用例.xlsx · 五四/JavaEE - 码云 - 开源中国

实现思路

封装公共工具类Utils.java：

• 创建EdgeDriver驱动、设置隐式等待；
• 获取系统时间，按日期创建文件夹，存储截图；
• 封装截图方法，每条用例执行完毕自动截图留存现场。
• 写个方法专门清空Vue受控输入框，替代原生clear()
• 写个方法安全判断元素是否存在，不会抛出TimeoutException
• 写个退出浏览器方法

用例覆盖：登录正常/异常、首页、商品列表搜索、商品详情、购物车操作、订单提交、未登录越权访问。

• 自动化用例总数：18条
• 执行结果：Pass:18 

编写自动化脚本遇到的问题：

 1.ElementClickInterceptedException

• 现象：点击元素被拦截
• 根因：操作后弹出提示框，页面灰色遮罩层不会自动消失，遮挡后续元素
• 解决思路：弹窗关闭后，JS清理灰罩，再执行下一条用例；

2. 提示框断言：实际文本为空 Actual = ""

• 代码问题：直接driver.findElement()无显式等待，弹窗动态渲染，代码执行过快，DOM 刚生成但文字未加载完成；且误用assertNotNull（空字符串对象不为 null，断言会误通过）
• 修复：使用visibilityOfElementLocated等待弹窗可见；用assertEquals比对文本；获取文本加.trim()；

3.页面点击后新开标签页，元素定位一直失败

先后尝试 4 种定位 / 等待方案都无效，判断大概率是：没有切换到新窗口句柄，代码还停留在原始页面，导致找不到新页面元素。

已做调试动作

1. 想要打印当前页面 URL，用来确认当前 driver 所在页面；
2. 需要窗口切换代码，处理点击后弹出的新标签页；
3. 问题根源猜想：点击打开新标签，driver 上下文没有切换，依旧在旧页面，所以元素找不到、超时。

关键代码需求

1. 获取并打印driver.getCurrentUrl()调试；
2. 获取所有窗口句柄，切换到新打开的标签页。

后续排查方向

1. 切换窗口后立刻打印 URL，验证是否成功切到新页面；
2. 切换完成后再执行元素等待与定位；
3. 区分：新标签页（window 句柄切换） vs 页面内 iframe（iframe 切换，二者代码不一样）

  4.原有执行方式缺陷

问题：

        1.使用main方法串行调用所有测试方法，缺少用例隔离，无法单独执行单条测试用例，失败排查困难。

        2.迁移 TestNG 框架后，单用例新建销毁浏览器，资源释放的后置清理逻辑设计不当，浏览器进程残留，占用系统资源。

解决方案：采用 TestNG 管理测试用例

        1.抛弃 main 方法串行执行，使用@Test注解管理每条自动化用例，支持单独执行单条用例，方便调试。

        2.通过@BeforeTest全局只初始化一次浏览器（实现浏览器复用），通过@AfterMethod做单条用例后置清理（复原），@AfterTest统一收尾，合理调用 quit () 关闭浏览器，避免浏览器后台残留进程。

5.断言机制不完善

问题：

1. 原始代码仅通过findElement查找元素，未使用 TestNG 断言。代码不抛出异常就默认用例通过，无法主动校验页面业务结果，测试结果标记不规范。
2. JVM 原生assert问题：JVM 默认参数‑da会关闭 assert 断言，断言直接失效。

解决方法：

• 使用 TestNG 提供：Assert.assertTrue()、Assert.assertFalse()、Assert.assertNotNull()

TestNG 断言不受 JVM -da参数影响，运行失败会标记用例失败，打印自定义错误信息。

6.CSS 选择器过长问题

问题：

1. 超长后代 css 可读性极差、页面布局微小改动直接全部失效；

解决方案：

1. 优先使用 id，例如#user-offcanvas；
2. 使用局部 class代替完整层级，如.header-top、.login-title、.em.logout>a；
3. 只保留业务相关 class，抛弃多余布局容器层级；

7.getText()拿输入框 value 错误

问题：

1. input 标签getText()拿不到输入框文本

解决方法：

     1.使用getAttribute("value")

8.测试用例边界争议

问题：

1. 用例 2（登录后退出）与用例 6（校验退出按钮）操作均为点击退出按钮，容易混淆，直接合并会丢失原有测试目标，不能简单合并。

解决方案：

      1.区分用例的测试目的：用例 2 重点验证完整登录 + 退出业务流程；用例 6 重点验证退出按钮功能，不直接合并，按需选择复用公共操作方法，保留独立的业务校验点。

实战感悟：自动化不是写完就一劳永逸，页面改动就要维护脚本；自动化主要用来做版本回归，不能完全替代手工测试。

五、性能测试 

压测核心接口：登录、商品列表、商品详情、添加购物车、提交订单。 加压策略：阶梯线程组，分别模拟50/100/200虚拟用户，持续压测5分钟。

验收指标：平均响应时间≤500ms，95%响应时间≤800ms，错误率＜1%，服务器CPU＜80%

接口	并发用户	平均响应时间	95%响应时间	错误率	TPS	CPU占用
用户登录	200	326ms	541ms	0.2%	312	72%
商品列表查询	200	412ms	675ms	0.3%	268	76%
商品详情查询	200	374ms	610ms	0.1%	291	74%
购物车添加商品	200	463ms	742ms	0.6%	224	78%
订单提交	100	582ms	864ms	0.8%	136	83%

压测结论

1. 查询类接口200并发全部达标；
2. 订单提交接口存在性能拐点：200并发CPU超过85%，响应时间明显上涨，数据库写入压力大；系统100并发以内满足业务指标。

优化建议：订单提交引入消息队列削峰，增加数据库索引，缓解数据库写入压力。

六、遗留风险

1. 测试时间有限，部分极端边界场景覆盖不全，存在细节体验风险；
2. 高并发下单场景存在性能瓶颈，大促流量突增可能响应变慢，上线需要重点监控；
3. 当前仅使用Fiddler+Postman手工接口测试，暂未开发接口自动化脚本。

七、测试总结与上线评估

核心业务功能全部通过，严重缺陷全部修复，版本可以上线。

上线后重点关注：订单链路CPU指标、线上报错日志、用户交易反馈。

后续迭代优化计划：

1. 维护自动化脚本，补充显式等待，扩充用例；
2. 优化订单接口性能，增加消息队列；
3. 修复遗留UI文案缺陷；
4. 将Fiddler与 Postman验证过的核心接口，补充接口自动化脚本。