针对电商 APP 补贴频道的防薅测试用例设计,需围绕 “规则绕过”“参数篡改”“权限越权” 等薅羊毛核心手段展开,重点覆盖 URL 拼接、接口滥用、规则漏洞等场景。以下从具体场景出发,设计结构化的测试用例:
一、URL 拼接 / 参数篡改场景(核心关注用户通过修改 URL 参数使非补贴商品享受补贴)
- 商品 ID 篡改测试
测试目标:验证修改 URL 中 “商品 ID” 参数后,非补贴商品是否会被错误识别为补贴商品。
测试步骤:
① 获取正常补贴商品的购买页 URL(例:https://app.com/subsidy/buy?goodsId=1001&activityId=2001&subsidy=50,其中goodsId=1001为补贴商品)。
② 将goodsId改为非补贴商品 ID(例:goodsId=2002,该商品未加入任何补贴活动),访问修改后的 URL。
③ 检查页面是否显示补贴价、下单时是否扣除补贴金额。
预期结果:非补贴商品 ID 对应的页面不显示补贴信息,下单时按原价结算,后端返回 “商品不参与当前补贴活动” 提示。 - 活动 ID / 补贴标识篡改测试
测试目标:验证修改 “活动 ID”“补贴开关” 等参数后,非活动商品是否强制绑定补贴。
测试步骤:
① 获取非补贴商品的普通购买页 URL(例:https://app.com/goods/buy?goodsId=3003,无补贴相关参数)。
② 手动拼接补贴活动参数(例:&activityId=2001&subsidy=50,activityId=2001为某有效补贴活动),访问该 URL。
③ 检查是否强制显示补贴价,提交订单时补贴是否生效。
预期结果:后端校验商品与活动的绑定关系(如商品是否在活动白名单),若不匹配则忽略拼接的补贴参数,按原价结算。 - 签名 / 加密参数篡改测试
测试目标:验证 URL 中签名参数(如sign)被篡改后,补贴逻辑是否失效(防止通过伪造签名绕过校验)。
测试步骤:
① 获取带签名的补贴商品 URL(例:https://app.com/subsidy/buy?goodsId=1001&activityId=2001&sign=xxx,sign由商品 ID、活动 ID 等参数加密生成)。
② 修改goodsId为非补贴商品 ID,保持sign不变(或伪造sign),访问 URL 并尝试下单。
预期结果:后端校验sign与参数的一致性,发现篡改后拒绝补贴,返回 “参数无效” 提示。
二、接口层校验场景(防止通过 API 调用绕过前端限制) - 下单接口补贴参数校验
测试目标:验证下单接口是否独立校验商品与补贴活动的关联性(不依赖前端页面参数)。
测试步骤:
① 通过抓包获取补贴商品的下单接口(例:POST /api/order/create,请求体包含goodsId=1001&activityId=2001&subsidyAmount=50)。
② 修改请求体中goodsId为非补贴商品 ID(如3003),保持activityId和subsidyAmount不变,发送请求。
预期结果:后端接口查询活动商品白名单,发现goodsId=3003不在范围内,返回 “商品不参与补贴”,补贴金额不生效。 - 跨频道参数复用测试
测试目标:验证从非补贴频道(如普通商品详情页)调用补贴相关接口时,是否被拦截。
测试步骤:
① 在普通商品详情页(非补贴频道),通过抓包获取该页面的商品 ID(如4004)。
② 手动构造补贴频道的下单接口请求,传入goodsId=4004和有效的activityId,模拟从普通频道调用补贴接口。
预期结果:后端校验请求来源(如channel=subsidy标识)与商品的匹配性,非补贴频道的商品调用补贴接口时被拒绝。
三、活动规则绕过场景 - 补贴资格越权测试(如限新用户 / 限地域)
测试目标:验证不符合资格的用户(如老用户、非目标地域用户)是否能通过参数篡改获得补贴。
测试步骤:
① 用老用户账号访问补贴商品 URL,修改 URL 中的 “用户类型” 参数(如&userType=new,实际为老用户)。
② 或修改地域参数(如®ion=shanghai,实际 IP 为北京,而补贴仅限上海),尝试下单。
预期结果:后端通过用户账号信息(而非 URL 参数)校验资格,老用户 / 非目标地域用户无法享受补贴。 - 补贴叠加 / 重复使用测试
测试目标:验证是否能通过 URL 拼接重复使用补贴,或叠加其他优惠。
测试步骤:
① 某补贴活动规则为 “每个用户限用 1 次”,用户使用补贴下单后,修改 URL 中的订单号(如&orderId=xxxx改为新值),尝试再次用同个活动 ID 下单。
② 拼接多个补贴参数(如&subsidy1=50&subsidy2=30),验证是否被重复扣除。
预期结果:后端记录用户的补贴使用次数,重复使用时提示 “已达使用上限”;拒绝多个补贴参数叠加,仅按规则生效一个。
四、边缘场景与异常值测试 - 活动时效性漏洞测试
测试目标:验证活动过期后,历史 URL 是否仍能生效。
测试步骤:
① 记录活动有效期内的补贴商品 URL(如activityId=2001,有效期至 2023-10-31)。
② 活动过期后(如 2023-11-01),访问该 URL 并尝试下单。
预期结果:后端校验活动状态,过期活动的 URL 无法享受补贴,提示 “活动已结束”。 - 异常商品 ID / 活动 ID 测试
测试目标:验证传入无效 ID(如负数、超大值、特殊字符)时,是否会触发补贴逻辑异常。
测试步骤:
① 在 URL 中修改goodsId=-1或activityId=999999999(不存在的活动),访问页面并下单。
② 传入特殊字符(如goodsId=1001' OR '1'='1),验证是否存在 SQL 注入漏洞导致补贴被滥用。
预期结果:后端对 ID 进行合法性校验(格式、范围、存在性),无效 ID 或特殊字符被拦截,不触发补贴。
五、自动化工具 / 批量薅羊毛测试 - 高频请求限流测试
测试目标:验证是否能通过脚本批量调用补贴 URL / 接口,实现批量薅羊毛。
测试步骤:
① 使用脚本模拟同一 IP / 账号,1 分钟内发送 100 次补贴商品下单请求(修改 URL 中的商品 ID 为不同非补贴商品)。
预期结果:触发限流机制,提示 “请求过于频繁”,拒绝后续请求;批量非补贴商品均不享受补贴。 - 机器人行为识别测试
测试目标:验证自动化工具是否会被识别并拦截。
测试步骤:
① 使用无头浏览器(如 Selenium)自动拼接 URL、提交订单,模拟机器人操作。
预期结果:触发验证码、滑块验证等防机器人机制,未通过验证则无法完成下单。
核心测试原则总结
后端强校验:所有补贴逻辑(商品是否参与、用户资格、活动状态)必须在后端独立校验,不依赖前端参数或页面限制。
参数防篡改:通过签名、加密等方式确保 URL / 接口参数不可伪造,篡改后立即失效。
规则闭环:覆盖活动全生命周期(生效前、有效期、过期后)、用户全维度(资格、次数、地域)的校验。
异常防护:对高频请求、异常参数、自动化行为进行拦截,防止批量薅羊毛。
通过以上测试用例,可有效验证补贴频道的防薅机制,避免因 URL 拼接、参数篡改等方式导致的补贴滥用。