防重复提交的Token机制需求测试点
根据防重复提交的Token机制需求，从功能、边界、异常、性能和安全五个维度设计测试点，确保覆盖核心场景和潜在风险。以下是详细的测试方案：
一、基础功能测试
-
Token生成与传递
-
验证前端每次提交订单是否生成唯一随机字符串（长度、字符类型是否符合要求）
-
检查前端是否将Token正确附加到请求头/请求体中
-
后端是否成功接收Token并返回200响应
-
-
Redis存储验证
-
提交订单后，检查Redis是否以
order:token:{token}为Key存储数据（Value可为订单ID或时间戳） -
验证Redis的TTL（生存时间）是否与配置的Token失效时间一致
-
-
重复提交拦截
-
相同Token在失效期内二次提交订单，检查：
-
后端是否返回明确错误码（如HTTP 409 Conflict）
-
错误信息是否提示"重复提交"
-
订单是否未被创建（数据库无新记录）
-
-
更换不同Token提交相同订单内容，验证是否成功
-
-
Token自动失效
-
等待Token过期后，用原Token重新提交订单：
-
检查Redis中该Key是否自动删除
-
验证订单是否提交成功
-
-
二、边界条件测试
-
时效性边界
-
Token失效时间临界点测试（如配置60秒失效）：
-
第59秒提交 → 触发重复提交拦截
-
第61秒提交 → 成功创建新订单
-
-
-
高并发重复提交
-
使用同一Token在10ms内发起100次并发请求：
-
仅允许第一个请求成功，其余99次均被拦截
-
检查Redis中Token未被意外删除或覆盖
-
-
-
Token容量测试
-
批量生成10万+ Token存入Redis：
-
验证Redis内存占用是否正常
-
检查Token写入/读取性能是否达标（如P99延迟<50ms）
-
-
三、异常场景测试
-
异常Token处理
-
前端传递空Token/非法字符Token（如SQL注入语句）：
-
后端是否返回400错误并提示"无效Token"
-
检查是否未操作Redis和数据库
-
-
-
Redis服务异常
-
模拟Redis宕机或网络中断：
-
验证订单提交是否降级处理（如记录日志并放行）
-
检查监控告警是否触发
-
-
-
重复提交绕过
-
在Token失效前手动删除Redis中的Key：
-
尝试用原Token提交 → 应成功创建订单（需记录审计日志）
-
-
篡改Token重放请求 → 后端应拒绝并告警
-
四、性能与安全测试
-
Token生成安全性
-
用工具检测Token随机性（如Entropy值>7.9）
-
尝试预测下一个Token（如用时间戳+随机数模式） → 应无法预测
-
-
压力测试
-
模拟每秒1万次订单提交：
-
验证Token写入Redis成功率100%
-
检查Redis CPU/内存无瓶颈
-
重复提交拦截响应时间<100ms
-
-
-
防重放攻击
-
捕获合法请求后重放1000次：
-
仅第一次成功，后续请求全部被拦截
-
Redis中Token的TTL未因重放被重置
-
-
五、配置与兼容性测试
-
动态配置验证
-
修改Token失效时间（如60s → 120s）：
-
热更新后新提交订单是否立即生效新TTL
-
-
关闭防重功能开关 → 相同Token可重复提交
-
-
多端兼容
-
不同客户端（Web/APP/H5）生成的Token格式是否统一
-
混合使用各端Token提交 → 防重逻辑应一致
-
六、测试工具建议
| 测试类型 | 推荐工具 | 验证指标 |
|---|---|---|
| 功能测试 | Postman + RedisInsight | 状态码、Redis数据一致性 |
| 并发测试 | JMeter / k6 | 拦截率、订单创建成功率 |
| 安全性测试 | Burp Suite | Token不可预测性 |
| 异常注入 | ChaosMesh | Redis宕机时服务降级能力 |
关键检查点总结
最终输出：测试报告需包含Redis操作日志、并发测试截图、Token失效时间验证视频，重点标注防重失效和安全绕过风险项。