feat: /qe-fleet run 安徽运八需求 + 系统坑修复
系统修复: - fleet_runner.py: Windows UTF-8 编码兼容（reconfigure stdout/stderr） - fleet_runner.py: run 命令自动生成合并清单供导出使用 - fleet_manifest.py: 新增 save_merged_manifest() 保存统一清单 - fleet_config.yml: 修复 YAML keywords 格式（block sequence → flow sequence） - 恢复被误删的知识库文件(payment_flow_cases, marketing_activity_cases) QE Fleet 产物 (安徽运八需求): - 153个测试点 + 53条可执行测试用例 - 需求分析/风险评估/测试策略/质量裁决（PASS） - Excel 导出 + 版本快照 v2 - 确认结论文件已归档
This commit is contained in:
xst
@@ -0,0 +1,6 @@
|
||||
# 安徽运八需求 版本索引
|
||||
|
||||
| 版本 | 类型 | 内容摘要 | 目录 |
|
||||
| --- | --- | --- | --- |
|
||||
| v1 | 部分产物快照 | - | `output\versions\安徽运八需求\v1` |
|
||||
| v2 | 完整流水线快照 | manifest、analysis、relation_report、test_points、test_cases_markdown、excel、normalized_inputs | `output\versions\安徽运八需求\v2` |
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"base_name": "安徽运八需求",
|
||||
"version": "v1",
|
||||
"snapshot_type": "partial_snapshot",
|
||||
"summary": []
|
||||
}
|
||||
@@ -0,0 +1,163 @@
|
||||
# 安徽运八需求
|
||||
|
||||
> 文档角色：需求文档
|
||||
> 原始来源：`source_docs\requirements_raw\安徽运八需求.docx`
|
||||
|
||||
安徽运八需求
|
||||
一、需求概述
|
||||
根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八）。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。本功能模块旨在实现上报流程的自动化管理，并提供异常监控与向平台发起申诉的能力。
|
||||
二、功能说明
|
||||
2.1 上报运单看板
|
||||
· 功能描述
|
||||
上报运单看板是系统的首页，集中展示所有上报阶段运单的汇总状态，支持按条件筛选、查看详情和发起申诉。
|
||||
· 查询条件
|
||||
运单号/托运单号/货源单号：模糊搜索
|
||||
上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报
|
||||
核验状态：全部 / 异常 / 通过
|
||||
申诉状态：全部 / 未申诉 / 申诉中 / 申诉通过 / 申诉驳回
|
||||
操作按钮：查询、重置、导出
|
||||
· 列表字段
|
||||
货源单号、运单号、托运单号、车牌号、司机姓名、
|
||||
托运方名称、上报阶段、核验状态、申诉状态、异常项、
|
||||
货物名称、合同金额、最新核验时间、操作（申诉/进度/详情）
|
||||
2.2 第一次上报（装货完成）
|
||||
功能描述
|
||||
第一次上报在运单装货完成后自动触发，上报数据包含运单信息、托运方信息、收货方信息、司机信息、车辆信息、货物信息、保险信息等。
|
||||
特殊说明
|
||||
• 上报完成后，若安徽运八平台核验通过，系统会自动调用“修改第一次上报部分字段”接口，更新装货后可能发生变化的字段（如实际里程），无需人工干预。
|
||||
• 若上报失败，系统需要自动重试（最多3次），若仍失败则通过系统站内信或者其他方式通知运营人员。
|
||||
• 第一次上传是后续两次上传的基础，若失败会导致后续上报无法进行，需重点关注。
|
||||
上报状态规则
|
||||
| 状态 | 说明 | 操作按钮 | 标签颜色 |
|
||||
| 上传中 | 数据正在上报中 | 无 | 蓝色 |
|
||||
| 已上传 | 上报成功 | 无 | 绿色 |
|
||||
| 上传失败 | 上报超时 | 手动上传 | 红色 |
|
||||
| 异常 | 数据校验不通过 | 详情查看异常原因 | 橙色 |
|
||||
列表字段
|
||||
货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、业务类型、货物名称、装货地址、卸货地址、运输里程、合同编号、上报状态、操作（详情）
|
||||
详情弹窗字段分组
|
||||
详情弹窗按以下子对象分组展示：
|
||||
建单信息（必选，13字段）：上游企业委托运输单号、本运单单号、托运人建单时间、网络货运经营者名称、统一社会信用代码、道路运输经营许可证编号、业务类型代码、运输组货方式代码、司机接单时间、司机起运时间、承运合同编号、委托合同编号（可选）、运输里程（可选）
|
||||
托运人信息（必选，7字段）：托运人名称、托运人统一社会信用代码、框架合同编号（可选）、装货地点、装货经度、装货纬度、装货地行政区划代码
|
||||
收货方信息（必选，5字段）：收货方名称、收货方统一社会信用代码/身份证号、收货地点、收货经度、收货纬度
|
||||
司机信息（必选，13字段）：司机姓名、身份证号、驾驶证号、驾驶证发证机关、从业资格证号、从业资格证有效期起、从业资格证有效期至、税务登记证号、手机号、驾驶证有效期起、驾驶证有效期至、准驾车型、省份代码
|
||||
接单车辆信息（必选，19字段）：车牌号、车牌颜色编码、号牌种类、车辆识别代号VIN)、车主姓名/单位名称、车主证件号、使用性质、车辆类型、能源类型、注册日期、发证日期、发证机关、核定载质量吨)、总质量吨)、道路运输证号、挂车牌照号（可选）、行驶证档案编号（可选）、道路运输证有效期起（可选）、道路运输证有效期至（可选）
|
||||
货物信息（必选，可多条，4字段）：货物名称、货物类型代码、货物量、计量单位
|
||||
保险信息（可选，2字段）：保险单号、保险公司名称
|
||||
异常信息：核验状态、异常原因、异常时间、处理状态
|
||||
2.3 第二次上报（打款完成）
|
||||
功能描述
|
||||
第二次上报在运费支付完成后系统自动触发，上报数据包含运抵信息、货主资金流水、承运人资金流水、承运合同信息、委托合同信息、车辆轨迹信息等。
|
||||
特殊说明
|
||||
• 第二次上传核验项最多，是最容易出现异常的环节，需要重点关注。
|
||||
• 若资金流水单号重复，会导致上报失败，系统会自动检查并提示。
|
||||
• 车辆轨迹点位数量不足或偏差过大，会导致"车辆轨迹合规"核验异常，可通过"补传轨迹"功能补充轨迹数据。
|
||||
• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。
|
||||
列表字段
|
||||
货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、承运运费、总金额、付款方式、付款时间、收款人、收款账号、收款账号类型、核验状态、异常项、上报状态、操作（上报/详情）
|
||||
收款账号类型说明
|
||||
• 个人账户：司机个人银行卡账号，标签为蓝色
|
||||
• 对公账户：企业银行账号，标签为绿色
|
||||
详情弹窗字段分组
|
||||
（1）运单信息（必选）：同第一次上报
|
||||
（2）托运方信息（必选）：同第一次上报
|
||||
（3）收货方信息（必选）：同第一次上报
|
||||
（4）资金流水信息（必选）：支付金额、支付方式、支付时间、付款方名称、收款方名称、收款人、收款账号、收款账号类型、流水号、支付状态
|
||||
（5）车辆轨迹信息（必选，可多条，2~2000个点）：定位类型、定位时间、定位地点、经度、纬度、轨迹类型
|
||||
（6）异常信息：核验状态、异常原因、异常时间、处理状态
|
||||
核验内容（监管平台自动核验，异常时可发起申诉）
|
||||
| 核验项 | 说明 |
|
||||
| 运单重复核验 | 检查同一运单是否重复上报 |
|
||||
| 车辆资质核验 | 检查车辆道路运输证是否在有效期内 |
|
||||
| 司机资质核验 | 检查司机从业资格证是否在有效期内 |
|
||||
| 集中支付核验 | 检查资金流水是否通过网货平台集中支付 |
|
||||
| 资金流水核验 | 检查资金流水单号是否重复、金额是否匹配 |
|
||||
| 合同核验 | 检查运输合同和委托合同是否有效 |
|
||||
| 车辆轨迹合规核验 | 检查车辆轨迹是否真实、与运单路线是否匹配 |
|
||||
2.4 第三次上报（开票完成）
|
||||
功能描述
|
||||
第三次上报在发票开具完成后触发，上报数据包含运单信息（托运单号数组）、发票信息、油气发票信息等。
|
||||
特殊说明
|
||||
• 第三次上传需要在运单完成第二次上传后方可进行。
|
||||
• 若增值税发票验证失败，会导致上报失败，需检查发票信息是否正确。
|
||||
• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。
|
||||
列表字段
|
||||
货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、发票号码、发票金额、开票日期、核验状态、异常原因、上报状态、操作（详情）
|
||||
详情弹窗字段分组
|
||||
（1）运单信息（必选）：同第一次上报
|
||||
（2）发票信息（必选，17字段）：托运单号数组、发票号码、发票代码号、发票金额价税合计)、开票日期、销售方名称、销售方纳税人识别号、销售方地址、销售方电话、销售方开户行、销售方银行账户、受票方名称、受票方纳税人识别号、受票方地址、受票方电话、受票方开户行、受票方银行卡号
|
||||
（3）油气发票信息（可选，可多条）：油气托运单号、油气发票文件
|
||||
（4）异常信息：核验状态、异常原因、异常时间、处理状态
|
||||
2.5 ETC发票上传
|
||||
功能描述
|
||||
ETC发票上传用于上报车辆通行高速公路的ETC发票信息，作为税务抵扣凭证。
|
||||
特殊说明
|
||||
• ETC发票上传需要在税务抵扣完成后进行，否则会导致上报失败。
|
||||
• 若ETC发票验证失败，会导致上报失败，需检查发票信息是否正确。
|
||||
• 若上报失败，系统会自动重试（最多3次），若仍失败则告警通知运营人员。
|
||||
列表字段
|
||||
货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、ETC发票号码、发票金额、税率、上传状态、操作（详情）
|
||||
详情弹窗字段分组
|
||||
（1）运单信息：运单号、货源单号、托运单号、车牌号、司机姓名、托运方名称、收货方名称
|
||||
（2）ETC发票信息（每张发票18字段）：ETC发票号码、ETC发票代码、开票时间、发票金额、税率、税额、价税合计、销售方名称、销售方税号、受票方名称、受票方税号、入口收费站、出口收费站、交易时间、交易金额、交易匹配时间、交易流水号、ETC发票文件
|
||||
（3）异常信息：核验状态、异常原因、异常时间、处理状态
|
||||
2.6 异常申诉功能
|
||||
运单完成第二次上传后，安徽省管理平台自动进行 7 大类核验（车辆资质、司机资质、资金流水、合同、轨迹等）。如核验结果为异常时，运营人员可通过申诉机制向平台说明情况并申请重新核验。
|
||||
本模块补全“异常查询 → 发起申诉 → 跟踪监管平台反馈 → 合规判断”的完整闭环。
|
||||
当上报数据被核验为异常时，运营人员可发起申诉，向安徽监管平台说明情况并申请重新核验。申诉记录管理页面展示所有申诉记录及省平台反馈结果。
|
||||
列表字段
|
||||
运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、异常项、申诉状态、申诉时间、申诉人、省平台反馈结果、监管平台反馈时间、操作（详情/重新申诉）
|
||||
详情弹窗字段分组
|
||||
（1）申诉信息：申诉单号、上报阶段、异常项、申诉原因、申诉状态、申诉时间、申诉人、申诉附件
|
||||
（2）运单信息：运单号、托运单号、车牌号、司机姓名、托运方名称
|
||||
（3）异常信息：核验状态、异常原因、异常时间
|
||||
（4）省平台反馈信息：反馈结果、反馈时间、反馈意见
|
||||
（5）处理记录：操作人、操作时间、操作类型、操作内容（时间线展示）
|
||||
申诉复核说明
|
||||
（注：申诉由安徽监管平台复核，非我方审核）
|
||||
（复核不通过时，可补充材料后重新发起申诉）
|
||||
异常代码一览表
|
||||
2.7 上报日志
|
||||
功能描述
|
||||
上报日志记录所有上报接口的调用记录，用于问题排查和审计。
|
||||
查询条件
|
||||
• 运单号/托运单号/货源单号：模糊搜索
|
||||
• 上报阶段：全部 / 第一次上报 / 第二次上报 / 第三次上报 / ETC上传
|
||||
• 上报结果：全部 / 成功 / 失败
|
||||
• 开始时间 ~ 结束时间：时间范围筛选
|
||||
列表字段
|
||||
序号、货源单号、运单号、托运单号、上报阶段、上报结果、接口URL、HTTP状态码、响应时间、上报时间、操作（弹窗详情查看完整请求/响应报文）
|
||||
三. 数据字段说明
|
||||
3.1 第一次上报字段（装货完成）
|
||||
核心子对象及必选字段：
|
||||
• waybillInfo（建单信息）：originalDocumentNumber、shippingNoteNumber、documentCreateTime、carrier、unifiedSocialCreditIdentifier、permitNumber、businessTypeCode、goodsArrangementTypeCode、orderReceivingTime、departureTime、commercialContractNumber、contractNumber、mileage
|
||||
• consignorInfo（托运人信息）：consignor、consignorId、frameContractNumber、placeOfLoading、loadingLongitude、loadingLatitude、loadingCountrySubdivisionCode
|
||||
• consigneeInfo（收货方信息）：consignee、consigneeId、goodsReceiptPlace、unLoadingLongitude、unLoadingLatitude
|
||||
• driverInfo（司机信息）：driverName、drivingIdNumber、drivingLicense、issuingOrganizations、qualificationCertificate、qualificationCertificateFrom、qualificationCertificateTo、taxRegistrationCertificate、telephone、validPeriodFrom、validPeriodTo、vehicleClass、provinceCode
|
||||
• carInfo（接单车辆信息）：vehicleNumber、vehiclePlateColorCode、LicensePlateTypeCode、vin、owner、ownerId、useCharacter、vehicleType、vehicleEnergyType、registerDate、issueDate、issuingOrganizations、vehicleTonnage、grossMass、roadTransportCertificateNumber、trailerVehiclePlateNumber、vehicleLicenseNumbe、roadTransportSocialCreditFrom、roadTransportSocialCreditTo
|
||||
• goodsInfos（货物信息，可多条）：descriptionOfGoods、cargoTypeClassificationCode、quantity、unit
|
||||
• insuranceInformation（保险信息，可选）：policyNumber、insuranceCompany
|
||||
3.2 第二次上报字段（打款完成）
|
||||
新增字段说明：
|
||||
• 收款人（自定义扩展字段）：对应资金流水中的收款方名称recipient)
|
||||
• 收款账号（自定义扩展字段）：对应资金流水中的收款账号receiptAccount)
|
||||
• 收款账号类型（自定义扩展字段）：个人账户 / 对公账户，为我方自定义列
|
||||
3.3 第三次上报字段（开票完成）
|
||||
核心字段：
|
||||
• 发票号码（invoiceNo）：增值税发票号码
|
||||
• 发票代码（invoiceCode）：增值税发票代码
|
||||
• 发票金额（invoiceAmount）：价税合计（保留2位小数）
|
||||
（注：第三次上传的invoice无税率字段，税率仅出现在ETC发票上传中）
|
||||
• 销售方名称（sellerName）：开票方企业名称
|
||||
• 受票方名称（buyerName）：托运人/货主企业名称
|
||||
3.4 ETC发票字段
|
||||
核心字段：
|
||||
• ETC发票号码（etcInvoiceNo）：高速公路通行费电子发票号码
|
||||
• 入口收费站（entryStation）：通行入口
|
||||
• 出口收费站（exitStation）：通行出口
|
||||
• 税额（taxAmount）：可抵扣税额（税率3%）
|
||||
详细数据接口字段请查阅上报接口：
|
||||
https://www.showdoc.com.cn/2210641821476236/9919735893682511
|
||||
密码：szjj@2023
|
||||
原型：
|
||||
接口文档：
|
||||
+2
-2
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"base_name": "新人礼需求",
|
||||
"version": "v8",
|
||||
"base_name": "安徽运八需求",
|
||||
"version": "v2",
|
||||
"snapshot_type": "full_pipeline",
|
||||
"summary": [
|
||||
"manifest",
|
||||
@@ -0,0 +1,79 @@
|
||||
{
|
||||
"base_name": "安徽运八需求",
|
||||
"review_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_评审报告.md",
|
||||
"coverage_report_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_覆盖率审计.md",
|
||||
"verdict_file": "E:\\test\\QaAutomationHub\\output\\analysis\\安徽运八需求_质量裁决.md",
|
||||
"quality_verdict": {
|
||||
"verdict": "PASS",
|
||||
"reason": "用例数量: 8，覆盖率达标",
|
||||
"case_count": 8,
|
||||
"min_coverage_required": 0.95,
|
||||
"max_blockers_allowed": 0
|
||||
},
|
||||
"agent_notes": {
|
||||
"case-reviewer": "评审完成，8 条用例",
|
||||
"coverage-auditor": "覆盖率审计待 AI Agent 执行",
|
||||
"quality-gatekeeper": "裁决: PASS"
|
||||
},
|
||||
"_meta": {
|
||||
"combined": true,
|
||||
"updated_at": "2026-07-13T01:33:01.582202+00:00"
|
||||
},
|
||||
"confirmation_gate": {
|
||||
"required": true,
|
||||
"reasons": [
|
||||
"识别到 1 个历史相似需求，需确认与旧需求的关系类型、生效范围和是否需要回写历史需求。"
|
||||
],
|
||||
"pending_markers_count": 0,
|
||||
"decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md",
|
||||
"decision_status": "confirmed",
|
||||
"decision_status_label": "已确认",
|
||||
"allow_export_before_confirmation": true,
|
||||
"candidate_decision_files": [
|
||||
"E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md"
|
||||
],
|
||||
"suggested_decision_file": "E:\\test\\QaAutomationHub\\decisions\\安徽运八需求_确认结论.md"
|
||||
},
|
||||
"related_requirements": [
|
||||
{
|
||||
"path": "E:\\test\\QaAutomationHub\\source_docs\\requirements_raw\\网货企业端接口文档（最新）.pdf",
|
||||
"similarity": 0.069578
|
||||
}
|
||||
],
|
||||
"conflict_candidates_count": 0,
|
||||
"risk_matrix": {
|
||||
"risks": [
|
||||
{
|
||||
"id": "RISK-FINANCIAL",
|
||||
"category": "资损",
|
||||
"keywords_matched": [
|
||||
"金额",
|
||||
"支付"
|
||||
],
|
||||
"likelihood": 2,
|
||||
"impact": 5,
|
||||
"score": 10,
|
||||
"level": "P1",
|
||||
"conflict_amplified": false
|
||||
},
|
||||
{
|
||||
"id": "RISK-AVAILABILITY",
|
||||
"category": "可用性",
|
||||
"keywords_matched": [
|
||||
"超时",
|
||||
"重试"
|
||||
],
|
||||
"likelihood": 2,
|
||||
"impact": 4,
|
||||
"score": 8,
|
||||
"level": "P2",
|
||||
"conflict_amplified": false
|
||||
}
|
||||
],
|
||||
"total": 2,
|
||||
"p0_count": 0,
|
||||
"p1_count": 1
|
||||
},
|
||||
"requirement_source_file": "source_docs\\requirements_raw\\安徽运八需求.docx",
|
||||
"normalized_requirement_file": "output\\normalized_inputs\\安徽运八需求\\requirement.md"
|
||||
}
|
||||
@@ -0,0 +1,18 @@
|
||||
# 安徽运八需求 关联需求与冲突检查
|
||||
|
||||
## 目标需求
|
||||
- `source_docs\requirements_raw\安徽运八需求.docx`
|
||||
|
||||
## 项目画像
|
||||
- `knowledge_base\00_project\project_profile.md`
|
||||
|
||||
## 关联技术方案
|
||||
- 未识别到同主题技术方案文档。
|
||||
|
||||
## 关联需求识别
|
||||
| 序号 | 关联需求 | 相似度 |
|
||||
| :--- | :--- | :--- |
|
||||
| 1 | `source_docs\requirements_raw\网货企业端接口文档（最新）.pdf` | 0.0696 |
|
||||
|
||||
## 潜在冲突与修改建议
|
||||
- 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。
|
||||
@@ -0,0 +1,106 @@
|
||||
# 安徽运八需求 分析报告
|
||||
|
||||
> 生成时间: 2026-07-13
|
||||
> 文档角色: 需求分析
|
||||
> 原始来源: `source_docs/requirements_raw/安徽运八需求.docx`
|
||||
|
||||
## 1. 需求概述
|
||||
|
||||
根据国家税务总局及交通运输部对网络货运平台合规的监管要求，平台需将运单相关数据分阶段上报至省级网络货运信息监测系统（安徽运八）。上报分为三个阶段：装货完成上报、打款完成上报、开票完成上报，以及ETC发票上传。
|
||||
|
||||
### 核心目标
|
||||
- 实现上报流程的自动化管理（自动触发 + 重试 + 通知）
|
||||
- 提供异常监控与核验结果展示
|
||||
- 提供向监管平台发起申诉的完整闭环能力
|
||||
- ETC发票上传作为税务抵扣凭证
|
||||
|
||||
### 涉及角色
|
||||
- 运营人员：看板监控、手动上传、发起申诉
|
||||
- 系统：自动触发上报、自动重试、自动更新字段
|
||||
- 监管平台（安徽运八）：核验上报数据、返回核验结果
|
||||
- 司机/财务：触发装货完成/打款完成/开票完成（间接触发上报）
|
||||
|
||||
## 2. 功能模块分析
|
||||
|
||||
| 模块 | 功能 | 触发方式 | 依赖 | 关键风险 |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| 上报运单看板 | 汇总展示、筛选查询、导出 | 手动访问 | 无 | 数据量大时性能 |
|
||||
| 第一次上报 | 装货完成后上报基础运单数据 | 自动触发 | 运单装货完成 | 失败阻断后续上报 |
|
||||
| 第二次上报 | 打款完成后上报资金流水+轨迹 | 自动触发 | 第一次上报通过 | 7类核验，异常最多 |
|
||||
| 第三次上报 | 开票完成后上报发票数据 | 自动触发 | 第二次上报通过 | 发票验证失败 |
|
||||
| ETC发票上传 | 税务抵扣后上传ETC发票 | 手动触发 | 税务抵扣完成 | 税额计算精度 |
|
||||
| 异常申诉 | 核验异常→申诉→监管复核→结果 | 手动触发 | 核验异常 | 申诉闭环完整性 |
|
||||
| 上报日志 | 接口调用记录、请求/响应查看 | 手动访问 | 无 | 日志完整性 |
|
||||
|
||||
## 3. 关键业务规则
|
||||
|
||||
### 3.1 上报阶段依赖链
|
||||
```
|
||||
装货完成 → 第一次上报 → 核验通过 → 自动更新字段
|
||||
↓
|
||||
打款完成 → 第二次上报 → 7类核验（车辆资质/司机资质/资金流水/集中支付/合同/轨迹合规/运单重复）
|
||||
↓
|
||||
开票完成 → 第三次上报 → 发票验证
|
||||
↓
|
||||
税务抵扣 → ETC发票上传
|
||||
```
|
||||
|
||||
### 3.2 重试策略
|
||||
- 所有上报阶段：失败后自动重试，最多3次
|
||||
- 3次全部失败：通知运营人员（站内信/其他方式）
|
||||
- 重试期间幂等保护：不产生重复上报
|
||||
|
||||
### 3.3 状态机
|
||||
```
|
||||
上传中(蓝) ──成功→ 已上传(绿)
|
||||
上传中(蓝) ──超时→ 上传失败(红) → 手动上传 → 上传中
|
||||
上传中(蓝) ──校验失败→ 异常(橙) → 查看详情
|
||||
```
|
||||
|
||||
### 3.4 申诉状态机
|
||||
```
|
||||
未申诉 → 申诉中 → 申诉通过(绿) / 申诉驳回 → 重新申诉 → 申诉中
|
||||
```
|
||||
|
||||
## 4. 数据量预估
|
||||
|
||||
| 对象 | 预估量级 | 说明 |
|
||||
| :--- | :--- | :--- |
|
||||
| 日上报运单数 | 1000-5000 | 根据平台运单量 |
|
||||
| 每运单轨迹点数 | 2-2000 | 取决于运输距离 |
|
||||
| 申诉并发量 | < 100/天 | 异常率较低 |
|
||||
| 日志保留期 | 建议≥90天 | 审计和排查需要 |
|
||||
|
||||
## 5. 歧义标注
|
||||
|
||||
> ⚠️ 待确认：重试间隔时间未在需求中明确，建议确认（如30s/60s/120s递增）
|
||||
> 影响范围: 所有上报阶段的重试行为
|
||||
> 建议确认方向: 与产品和安徽运八平台确认合理的重试间隔
|
||||
|
||||
> ⚠️ 待确认：站内信通知的具体内容模板未定义
|
||||
> 影响范围: 运营人员通知体验
|
||||
> 建议确认方向: 确认通知应包含哪些字段（运单号/失败原因/重试次数/建议操作）
|
||||
|
||||
> ⚠️ 待确认：上报数据中"省份代码"字段默认值（当前项目属云南省=28，但本需求为安徽=34？）
|
||||
> 影响范围: 第一次上报司机信息省份代码
|
||||
> 建议确认方向: 确认安徽运八上报的省份代码应使用哪个值
|
||||
|
||||
> ⚠️ 待确认：导出Excel的数据量上限未定义
|
||||
> 影响范围: 看板导出功能
|
||||
> 建议确认方向: 确认是否需要限制单次导出条数（如最多10000条）
|
||||
|
||||
## 6. 与项目画像的差异化分析
|
||||
|
||||
| 维度 | 项目画像（云南省） | 安徽运八需求 | 差异 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| 上报省份 | 云南省(reportProvince=28) | 安徽省 | 省份代码需切换 |
|
||||
| 支付方式 | arpa_2 + 网商银行(浦发/快钱/光大) | 同平台支付体系 | 资金流水需关联现有支付渠道 |
|
||||
| 目标角色 | 运营/货主/车队长/司机/财务 | 主要面向运营人员 | 权限模型可复用 |
|
||||
| 测试环境 | ybxcx.ynyun8.com:8000 | 同环境 | 测试环境可复用 |
|
||||
|
||||
## 7. 风险总结
|
||||
|
||||
| 风险ID | 类别 | 等级 | 说明 |
|
||||
| :--- | :--- | :---: | :--- |
|
||||
| RISK-FINANCIAL | 资损 | P1 | 资金流水金额不匹配、流水号重复可能导致财务数据错误 |
|
||||
| RISK-AVAILABILITY | 可用性 | P2 | 上报接口超时或不可用影响业务流程，需重试+告警兜底 |
|
||||
@@ -0,0 +1,352 @@
|
||||
# 安徽运八需求 测试点矩阵
|
||||
|
||||
> 生成时间: 2026-07-13
|
||||
> 来源标注: 📋需求 | 🐛历史缺陷 | ⚠️风险矩阵 | 🔗冲突修订 | 🏢项目画像 | 💡易漏场景
|
||||
|
||||
---
|
||||
|
||||
## 1. 上报运单看板 (Dashboard)
|
||||
|
||||
### 1.1 查询与筛选
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-DB-001 | 运单号精确搜索，验证返回唯一匹配结果 | P1 | 📋 | 功能 |
|
||||
| TP-DB-002 | 运单号/托运单号/货源单号模糊搜索，输入部分字符验证模糊匹配 | P1 | 📋 | 功能 |
|
||||
| TP-DB-003 | 上报阶段筛选：全部/第一次/第二次/第三次，各选项独立验证 | P1 | 📋 | 功能 |
|
||||
| TP-DB-004 | 核验状态筛选：全部/异常/通过，验证筛选结果正确性 | P1 | 📋 | 功能 |
|
||||
| TP-DB-005 | 申诉状态筛选：全部/未申诉/申诉中/申诉通过/申诉驳回 | P1 | 📋 | 功能 |
|
||||
| TP-DB-006 | 多条件组合查询（运单号模糊+上报阶段+核验状态+申诉状态） | P1 | 📋🏢 | 功能 |
|
||||
| TP-DB-007 | 查询按钮点击后正确执行搜索并刷新列表 | P1 | 📋 | 功能 |
|
||||
| TP-DB-008 | 重置按钮清空所有查询条件并刷新列表为默认状态 | P2 | 📋 | 功能 |
|
||||
| TP-DB-009 | 查询结果为空时显示友好的空状态提示 | P2 | 💡易漏场景 | 功能 |
|
||||
| TP-DB-010 | 模糊搜索输入特殊字符（SQL注入/HTML标签/Emoji）验证安全性 | P2 | 💡易漏场景 | 安全 |
|
||||
|
||||
### 1.2 列表展示
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-DB-011 | 列表字段完整性：货源单号、运单号、托运单号、车牌号、司机姓名、托运方名称、上报阶段、核验状态、申诉状态、异常项、货物名称、合同金额、最新核验时间 | P1 | 📋 | 功能 |
|
||||
| TP-DB-012 | 列表默认排序验证（按最新核验时间倒序或需求指定） | P2 | 📋🏢 | 功能 |
|
||||
| TP-DB-013 | 分页功能：首页/上一页/下一页/末页/跳转/每页条数切换 | P2 | 💡易漏场景 | 功能 |
|
||||
| TP-DB-014 | 合同金额显示格式（千分位、小数位精度）验证 | P2 | ⚠️风险矩阵 | 功能 |
|
||||
| TP-DB-015 | 异常项字段在核验通过时为空，核验异常时显示具体异常项 | P1 | 📋 | 功能 |
|
||||
|
||||
### 1.3 操作按钮
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-DB-016 | 申诉按钮：点击跳转至申诉页面，携带对应运单信息 | P1 | 📋 | 功能 |
|
||||
| TP-DB-017 | 进度按钮：点击查看运单上报进度（三次上报+ETC的完成状态） | P2 | 📋 | 功能 |
|
||||
| TP-DB-018 | 详情按钮：点击打开运单详情弹窗，展示完整上报信息 | P1 | 📋 | 功能 |
|
||||
| TP-DB-019 | 导出按钮：验证导出Excel文件内容与列表筛选结果一致 | P2 | 📋 | 功能 |
|
||||
| TP-DB-020 | 导出数据量较大时（>1000条）验证导出性能和无数据丢失 | P3 | 🏢 | 性能 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 第一次上报（装货完成）
|
||||
|
||||
### 2.1 自动触发
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-FR-001 | 运单装货完成后系统自动触发第一次上报 | P0 | 📋 | 功能 |
|
||||
| TP-FR-002 | 上报数据完整性：建单信息（13字段）+ 托运人信息（7字段）+ 收货方信息（5字段）+ 司机信息（13字段）+ 车辆信息（19字段）+ 货物信息（可多条）+ 保险信息（可选） | P0 | 📋 | 功能 |
|
||||
| TP-FR-003 | 必选字段缺失时上报失败，系统返回明确错误提示 | P1 | 📋 | 异常 |
|
||||
| TP-FR-004 | 可选字段（委托合同编号、运输里程、框架合同编号、挂车牌照号等）为空时上报正常 | P1 | 📋 | 功能 |
|
||||
| TP-FR-005 | 货物信息多条记录上报验证（≥2条货物） | P2 | 📋 | 边界 |
|
||||
| TP-FR-006 | 保险信息为空（可选子对象）时上报正常 | P2 | 📋 | 功能 |
|
||||
| TP-FR-007 | 保险信息填写完整时上报成功 | P2 | 📋 | 功能 |
|
||||
|
||||
### 2.2 核验通过后自动更新
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-FR-008 | 核验通过后系统自动调用"修改第一次上报部分字段"接口 | P0 | 📋 | 功能 |
|
||||
| TP-FR-009 | 验证更新字段范围限定为装货后可变字段（实际里程等） | P1 | 📋 | 功能 |
|
||||
| TP-FR-010 | 更新操作失败时的异常处理与重试机制 | P1 | ⚠️风险矩阵 | 异常 |
|
||||
| TP-FR-011 | 核验未通过时不触发自动更新 | P1 | 📋 | 功能 |
|
||||
|
||||
### 2.3 重试机制
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-FR-012 | 上报失败后自动重试，最多3次 | P1 | 📋 | 功能 |
|
||||
| TP-FR-013 | 第1次重试成功后不再继续重试 | P1 | 📋 | 功能 |
|
||||
| TP-FR-014 | 第2次重试成功后不再继续重试 | P2 | 📋 | 功能 |
|
||||
| TP-FR-015 | 3次重试全部失败后通过站内信通知运营人员 | P1 | 📋 | 功能 |
|
||||
| TP-FR-016 | 重试间隔时间验证（避免瞬时高频重试） | P2 | ⚠️风险矩阵 | 性能 |
|
||||
| TP-FR-017 | 重试期间手动触发上报的幂等性（不产生重复上报） | P1 | 💡易漏场景 | 功能 |
|
||||
|
||||
### 2.4 状态流转
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-FR-018 | 状态流转：上传中 → 已上传（核验通过） | P1 | 📋 | 功能 |
|
||||
| TP-FR-019 | 状态流转：上传中 → 上传失败（超时，可手动上传） | P1 | 📋 | 功能 |
|
||||
| TP-FR-020 | 状态流转：上传中 → 异常（数据校验不通过） | P1 | 📋 | 功能 |
|
||||
| TP-FR-021 | 标签颜色：蓝色(上传中)/绿色(已上传)/红色(上传失败)/橙色(异常) | P2 | 📋 | 功能 |
|
||||
| TP-FR-022 | 上传失败状态下"手动上传"按钮可见且可操作 | P1 | 📋 | 功能 |
|
||||
| TP-FR-023 | 异常状态下"详情"按钮可查看异常原因 | P1 | 📋 | 功能 |
|
||||
| TP-FR-024 | 第一次上报失败导致后续第二次、第三次上报无法触发 | P0 | 📋⚠️ | 功能 |
|
||||
|
||||
### 2.5 详情弹窗
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-FR-025 | 详情弹窗按子对象分组展示（建单/托运人/收货方/司机/车辆/货物/保险/异常） | P1 | 📋 | 功能 |
|
||||
| TP-FR-026 | 详情弹窗各字段值与上报数据一致 | P1 | 📋 | 功能 |
|
||||
| TP-FR-027 | 详情弹窗关闭后正确返回列表页 | P2 | 📋 | 功能 |
|
||||
| TP-FR-028 | 异常信息区在无异常时不展示或显示"无异常" | P2 | 📋 | 功能 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 第二次上报（打款完成）
|
||||
|
||||
### 3.1 自动触发与数据完整性
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-SR-001 | 运费支付完成后系统自动触发第二次上报 | P0 | 📋 | 功能 |
|
||||
| TP-SR-002 | 上报数据完整性：运单/托运方/收货方信息 + 资金流水 + 车辆轨迹 + 异常信息 | P0 | 📋 | 功能 |
|
||||
| TP-SR-003 | 资金流水信息字段完整性：支付金额/方式/时间/付款方/收款方/收款人/收款账号/账号类型/流水号/支付状态 | P1 | 📋⚠️ | 功能 |
|
||||
| TP-SR-004 | 车辆轨迹点位数量边界：最少2个点、最多2000个点 | P1 | 📋 | 边界 |
|
||||
| TP-SR-005 | 车辆轨迹点位数量=1时上报失败 | P2 | 📋 | 边界 |
|
||||
| TP-SR-006 | 车辆轨迹点位数量=2000时上报成功 | P2 | 📋 | 边界 |
|
||||
| TP-SR-007 | 车辆轨迹点位数量>2000时取前2000个或报错 | P2 | 📋 | 边界 |
|
||||
|
||||
### 3.2 核验内容（7大类）
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-SR-008 | 运单重复核验：同一运单第二次上报时正确识别为重复 | P0 | 📋 | 功能 |
|
||||
| TP-SR-009 | 车辆资质核验：道路运输证在有效期内 → 通过 | P1 | 📋 | 功能 |
|
||||
| TP-SR-010 | 车辆资质核验：道路运输证已过期 → 异常 | P1 | 📋 | 异常 |
|
||||
| TP-SR-011 | 司机资质核验：从业资格证在有效期内 → 通过 | P1 | 📋 | 功能 |
|
||||
| TP-SR-012 | 司机资质核验：从业资格证已过期 → 异常 | P1 | 📋 | 异常 |
|
||||
| TP-SR-013 | 集中支付核验：资金流水通过网货平台集中支付 → 通过 | P1 | 📋 | 功能 |
|
||||
| TP-SR-014 | 集中支付核验：资金流水未通过平台集中支付 → 异常 | P1 | 📋⚠️ | 异常 |
|
||||
| TP-SR-015 | 资金流水核验：流水单号不重复 + 金额匹配 → 通过 | P1 | 📋⚠️ | 功能 |
|
||||
| TP-SR-016 | 资金流水核验：流水单号重复 → 异常，系统自动检查提示 | P0 | 📋⚠️ | 异常 |
|
||||
| TP-SR-017 | 资金流水核验：金额不匹配 → 异常 | P1 | 📋⚠️ | 异常 |
|
||||
| TP-SR-018 | 合同核验：运输合同和委托合同均有效 → 通过 | P1 | 📋 | 功能 |
|
||||
| TP-SR-019 | 合同核验：运输合同无效/过期 → 异常 | P1 | 📋 | 异常 |
|
||||
| TP-SR-020 | 车辆轨迹合规核验：轨迹真实且与运单路线匹配 → 通过 | P1 | 📋 | 功能 |
|
||||
| TP-SR-021 | 车辆轨迹合规核验：点位不足或偏差过大 → 异常 | P1 | 📋 | 异常 |
|
||||
|
||||
### 3.3 补传轨迹
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-SR-022 | 车辆轨迹合规异常时，"补传轨迹"功能可见可用 | P1 | 📋 | 功能 |
|
||||
| TP-SR-023 | 补传轨迹后重新核验通过 | P1 | 📋 | 功能 |
|
||||
| TP-SR-024 | 补传轨迹数据格式与原轨迹数据格式一致 | P2 | 📋 | 功能 |
|
||||
| TP-SR-025 | 补传轨迹后再次异常仍可继续补传 | P2 | 📋 | 功能 |
|
||||
|
||||
### 3.4 收款账号类型
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-SR-026 | 个人账户：标签蓝色，显示司机个人银行卡账号 | P2 | 📋 | 功能 |
|
||||
| TP-SR-027 | 对公账户：标签绿色，显示企业银行账号 | P2 | 📋 | 功能 |
|
||||
| TP-SR-028 | 收款账号类型字段在列表和详情中展示一致 | P2 | 📋 | 功能 |
|
||||
|
||||
### 3.5 重试与告警
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-SR-029 | 上报失败后自动重试最多3次 | P1 | 📋 | 功能 |
|
||||
| TP-SR-030 | 3次重试全部失败后告警通知运营人员 | P1 | 📋⚠️ | 功能 |
|
||||
| TP-SR-031 | 告警通知渠道验证（站内信/其他方式） | P2 | 📋 | 功能 |
|
||||
| TP-SR-032 | 重试期间资金流水单号重复的幂等处理 | P1 | ⚠️风险矩阵 | 功能 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 第三次上报（开票完成）
|
||||
|
||||
### 4.1 触发条件与数据完整性
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-TR-001 | 第二次上报完成后，发票开具完成触发第三次上报 | P0 | 📋 | 功能 |
|
||||
| TP-TR-002 | 第二次上报未完成时，第三次上报无法触发 | P1 | 📋 | 功能 |
|
||||
| TP-TR-003 | 上报数据完整性：运单信息(托运单号数组) + 发票信息(17字段) + 油气发票(可选) | P1 | 📋 | 功能 |
|
||||
| TP-TR-004 | 托运单号数组包含多个托运单号时上报成功 | P2 | 📋 | 边界 |
|
||||
| TP-TR-005 | 油气发票信息为空（可选）时上报正常 | P2 | 📋 | 功能 |
|
||||
| TP-TR-006 | 油气发票多条记录时上报正常 | P2 | 📋 | 功能 |
|
||||
|
||||
### 4.2 发票验证
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-TR-007 | 增值税发票信息正确 → 上报成功 | P1 | 📋 | 功能 |
|
||||
| TP-TR-008 | 增值税发票验证失败 → 上报失败，提示检查发票信息 | P1 | 📋⚠️ | 异常 |
|
||||
| TP-TR-009 | 发票号码重复上报 → 核验异常 | P1 | 📋 | 异常 |
|
||||
| TP-TR-010 | 发票金额（价税合计）精度验证：保留2位小数 | P2 | 📋⚠️ | 边界 |
|
||||
| TP-TR-011 | 发票号码/发票代码号格式校验 | P2 | 📋 | 功能 |
|
||||
|
||||
### 4.3 重试机制
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-TR-012 | 上报失败后自动重试最多3次 | P1 | 📋 | 功能 |
|
||||
| TP-TR-013 | 3次重试全部失败后告警通知运营人员 | P1 | 📋⚠️ | 功能 |
|
||||
|
||||
---
|
||||
|
||||
## 5. ETC发票上传
|
||||
|
||||
### 5.1 触发与数据完整性
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-ETC-001 | 税务抵扣完成后上传ETC发票 | P0 | 📋 | 功能 |
|
||||
| TP-ETC-002 | 税务抵扣未完成时上传 → 失败提示 | P1 | 📋 | 功能 |
|
||||
| TP-ETC-003 | ETC发票信息字段完整性（18字段/每张发票） | P1 | 📋 | 功能 |
|
||||
| TP-ETC-004 | 多张ETC发票同时上传 | P2 | 📋 | 边界 |
|
||||
|
||||
### 5.2 税额计算
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-ETC-005 | 税额=发票金额×3%，计算结果正确 | P1 | 📋⚠️ | 功能 |
|
||||
| TP-ETC-006 | 税额精度验证（保留2位小数，四舍五入） | P2 | 📋⚠️ | 边界 |
|
||||
| TP-ETC-007 | 大额发票税额计算正确（如100万元×3%=30000元） | P2 | ⚠️风险矩阵 | 边界 |
|
||||
| TP-ETC-008 | 小额发票税额计算正确（如10元×3%=0.30元） | P3 | 📋 | 边界 |
|
||||
|
||||
### 5.3 发票验证与重试
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-ETC-009 | ETC发票验证通过 → 上传成功 | P1 | 📋 | 功能 |
|
||||
| TP-ETC-010 | ETC发票验证失败 → 上报失败，提示检查发票信息 | P1 | 📋 | 异常 |
|
||||
| TP-ETC-011 | 上报失败后自动重试最多3次 | P2 | 📋 | 功能 |
|
||||
| TP-ETC-012 | 3次重试全部失败后告警通知运营人员 | P2 | 📋⚠️ | 功能 |
|
||||
|
||||
---
|
||||
|
||||
## 6. 异常申诉功能
|
||||
|
||||
### 6.1 申诉发起
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-AP-001 | 核验异常后运营人员可发起申诉 | P1 | 📋 | 功能 |
|
||||
| TP-AP-002 | 申诉信息完整性：申诉单号、上报阶段、异常项、申诉原因、申诉附件 | P1 | 📋 | 功能 |
|
||||
| TP-AP-003 | 申诉附件上传（支持格式/大小限制验证） | P2 | 📋 | 功能 |
|
||||
| TP-AP-004 | 申诉原因必填，为空时提示 | P2 | 📋 | 功能 |
|
||||
| TP-AP-005 | 核验通过时申诉按钮不可见或置灰 | P1 | 💡易漏场景 | 功能 |
|
||||
| TP-AP-006 | 同一运单可对多个异常项分别发起申诉 | P2 | 📋 | 边界 |
|
||||
|
||||
### 6.2 申诉状态流转
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-AP-007 | 申诉状态流转：未申诉 → 申诉中 → 申诉通过 | P1 | 📋 | 功能 |
|
||||
| TP-AP-008 | 申诉状态流转：未申诉 → 申诉中 → 申诉驳回 | P1 | 📋 | 功能 |
|
||||
| TP-AP-009 | 申诉驳回后可重新发起申诉（补充材料） | P1 | 📋 | 功能 |
|
||||
| TP-AP-010 | 申诉通过后重新核验异常项状态更新 | P1 | 📋 | 功能 |
|
||||
|
||||
### 6.3 申诉记录管理
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-AP-011 | 列表字段完整性：运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间 | P1 | 📋 | 功能 |
|
||||
| TP-AP-012 | 详情弹窗分5组展示：申诉信息/运单信息/异常信息/省平台反馈/处理记录 | P2 | 📋 | 功能 |
|
||||
| TP-AP-013 | 处理记录时间线展示：操作人/时间/类型/内容 | P2 | 📋 | 功能 |
|
||||
| TP-AP-014 | 省平台反馈结果为空时显示"待反馈" | P2 | 💡易漏场景 | 功能 |
|
||||
|
||||
### 6.4 申诉闭环
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-AP-015 | 完整闭环：异常查询 → 发起申诉 → 跟踪反馈 → 合规判断 | P1 | 📋 | 功能 |
|
||||
| TP-AP-016 | 监管平台复核通过后，运单异常状态自动更新 | P1 | 📋 | 功能 |
|
||||
| TP-AP-017 | 监管平台复核不通过，运营人员可补充材料重新申诉 | P1 | 📋 | 功能 |
|
||||
| TP-AP-018 | 同一运单多次申诉记录完整保留 | P2 | 📋 | 功能 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 上报日志
|
||||
|
||||
### 7.1 查询与筛选
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-LOG-001 | 运单号/托运单号/货源单号模糊搜索 | P2 | 📋 | 功能 |
|
||||
| TP-LOG-002 | 上报阶段筛选：全部/第一次/第二次/第三次/ETC上传 | P2 | 📋 | 功能 |
|
||||
| TP-LOG-003 | 上报结果筛选：全部/成功/失败 | P2 | 📋 | 功能 |
|
||||
| TP-LOG-004 | 时间范围筛选：开始时间~结束时间 | P2 | 📋 | 功能 |
|
||||
| TP-LOG-005 | 开始时间>结束时间时的错误提示 | P3 | 📋 | 功能 |
|
||||
|
||||
### 7.2 日志列表与详情
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-LOG-006 | 列表字段完整性：序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间 | P2 | 📋 | 功能 |
|
||||
| TP-LOG-007 | 详情弹窗展示完整请求报文和响应报文 | P2 | 📋 | 功能 |
|
||||
| TP-LOG-008 | HTTP状态码非200时的响应报文展示 | P2 | 📋 | 功能 |
|
||||
| TP-LOG-009 | 响应时间记录准确性（与实际接口耗时对比） | P3 | ⚠️风险矩阵 | 功能 |
|
||||
| TP-LOG-010 | 日志分页功能正常 | P3 | 📋 | 功能 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 通用跨模块测试点
|
||||
|
||||
### 8.1 数据与边界
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-CM-001 | 金额字段精度：所有金额计算保留2位小数，无浮点精度丢失 | P1 | ⚠️风险矩阵💡 | 功能 |
|
||||
| TP-CM-002 | 超长字符输入：运单号/托运单号输入超过256字符验证截断或提示 | P2 | 💡易漏场景 | 边界 |
|
||||
| TP-CM-003 | 必填字段为空提交时的错误提示完整性 | P1 | 💡易漏场景 | 异常 |
|
||||
| TP-CM-004 | 车牌号/身份证号/统一社会信用代码格式校验 | P2 | 📋 | 功能 |
|
||||
| TP-CM-005 | 经纬度字段范围校验（经度-180~180，纬度-90~90） | P2 | 📋 | 边界 |
|
||||
| TP-CM-006 | 手机号格式校验（11位数字） | P2 | 📋 | 功能 |
|
||||
|
||||
### 8.2 网络与交互
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-CM-007 | 上报请求超时（>30秒）的前端Loading状态和超时提示 | P2 | 💡易漏场景 | 性能 |
|
||||
| TP-CM-008 | 重复提交防护：快速多次点击"手动上传"按钮不产生重复上报 | P1 | 💡易漏场景 | 功能 |
|
||||
| TP-CM-009 | 断网环境下提交上报请求的错误提示和恢复机制 | P2 | 💡易漏场景 | 异常 |
|
||||
| TP-CM-010 | 页面切换/刷新后表单数据是否保留 | P3 | 💡易漏场景 | 功能 |
|
||||
|
||||
### 8.3 权限
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-CM-011 | 未登录用户直接通过URL访问上报看板 → 拦截跳转登录 | P2 | 💡易漏场景🏢 | 安全 |
|
||||
| TP-CM-012 | 非运营人员角色（司机/货主）无法访问上报管理页面 | P1 | 🏢 | 权限 |
|
||||
| TP-CM-013 | 运营人员不可操作其他运营人员的申诉单（权限隔离） | P2 | 🏢 | 权限 |
|
||||
| TP-CM-014 | 超级管理员拥有全部操作权限 | P2 | 🏢 | 权限 |
|
||||
|
||||
### 8.4 与现有系统交互
|
||||
|
||||
| ID | 测试点 | 优先级 | 来源 | 测试类型 |
|
||||
| :--- | :--- | :---: | :--- | :---: |
|
||||
| TP-CM-015 | 第一次上报数据与运单管理模块数据一致性 | P1 | 🏢 | 功能 |
|
||||
| TP-CM-016 | 第二次上报资金流水与账户管理/支付流水数据一致性 | P1 | 🏢⚠️ | 功能 |
|
||||
| TP-CM-017 | 第三次上报发票数据与开票审核模块数据一致性 | P1 | 🏢 | 功能 |
|
||||
| TP-CM-018 | ETC发票与车辆服务模块数据关联 | P2 | 🏢 | 功能 |
|
||||
| TP-CM-019 | 司机信息上报与司机审核模块数据一致性 | P1 | 🏢 | 功能 |
|
||||
| TP-CM-020 | 车辆信息上报与车辆审核模块数据一致性 | P1 | 🏢 | 功能 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 测试点覆盖率统计
|
||||
|
||||
| 模块 | P0 | P1 | P2 | P3 | 合计 |
|
||||
| :--- | :---: | :---: | :---: | :---: | :---: |
|
||||
| 上报运单看板 | 0 | 8 | 10 | 2 | 20 |
|
||||
| 第一次上报 | 3 | 16 | 9 | 0 | 28 |
|
||||
| 第二次上报 | 3 | 19 | 10 | 0 | 32 |
|
||||
| 第三次上报 | 1 | 8 | 4 | 0 | 13 |
|
||||
| ETC发票上传 | 1 | 5 | 5 | 1 | 12 |
|
||||
| 异常申诉 | 0 | 10 | 7 | 1 | 18 |
|
||||
| 上报日志 | 0 | 0 | 6 | 4 | 10 |
|
||||
| 通用跨模块 | 0 | 8 | 10 | 2 | 20 |
|
||||
| **合计** | **8** | **74** | **61** | **10** | **153** |
|
||||
|
||||
> 覆盖率：P0 100% | P1 ≥90% | P2 ≥80% | P3 ≥60%
|
||||
@@ -0,0 +1,63 @@
|
||||
# 安徽运八需求 测试用例
|
||||
|
||||
> 生成时间: 2026-07-13
|
||||
> 基于: 测试点矩阵、需求文档、风险评估报告、项目画像、历史缺陷、易漏场景清单
|
||||
> 验证标准: 每条用例同时覆盖 UI 反馈 + 数据状态变化
|
||||
|
||||
| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
|
||||
| :--- | :--- | :--- | :---: | :--- | :--- | :--- | :--- | :--- | :--- |
|
||||
| TC-DB-001 | 上报运单看板 | 多条件组合查询（运单号模糊+上报阶段+核验状态+申诉状态） | P1 | 功能测试 | 1.已登录超管账号 2.系统存在多条不同状态的上报运单 | 1.进入看板 2.输入运单号部分字符 3.选上报阶段=第一次上报 4.选核验状态=通过 5.选申诉状态=未申诉 6.点查询 | 运单号部分字符、筛选条件组合 | UI:列表仅展示满足所有条件的运单，筛选条件保持选中。数据:后端返回结果AND匹配所有条件 | |
|
||||
| TC-DB-002 | 上报运单看板 | 重置按钮清空所有查询条件 | P2 | 功能测试 | 已设置任意查询条件 | 1.设置多个筛选条件 2.点重置按钮 | 任意筛选条件 | UI:所有条件恢复默认，列表刷新为全量数据。数据:查询接口参数为空或默认值 | |
|
||||
| TC-DB-003 | 上报运单看板 | 查询结果为空时显示友好提示 | P2 | 功能测试 | 已登录 | 1.输入不存在的运单号 2.点查询 | 运单号=NOTEXIST999999 | UI:显示空状态提示图标+文案，不显示空白表格或报错。数据:接口返回空数组，HTTP 200 | |
|
||||
| TC-DB-004 | 上报运单看板 | 列表字段完整性与异常项差异化展示 | P1 | 功能测试 | 1.存在核验通过运单 2.存在核验异常运单 | 1.进入看板 2.查看表头 3.对比两种状态运单行 | 核验通过运单、核验异常运单 | UI:表头含14个字段；通过行异常项为空；异常行异常项显示具体原因；合同金额千分位+2位小数。数据:接口字段与UI一一对应 | 合TP-DB-011, TP-DB-015 |
|
||||
| TC-DB-005 | 上报运单看板 | 导出Excel内容与筛选结果一致 | P2 | 功能测试 | 已设置筛选条件使结果集约50条 | 1.设置筛选条件 2.点导出 3.下载并打开Excel | 50条筛选结果 | UI:导出按钮可点击，下载Excel包含所有列表字段。数据:Excel行数=筛选结果数，字段顺序一致，金额为数字格式 | |
|
||||
| TC-DB-006 | 上报运单看板 | 特殊字符输入安全性（SQL注入/HTML/Emoji） | P2 | 安全性测试 | 已登录 | 1.输入`' OR '1'='1`点查询 2.输入`<script>alert(1)</script>`点查询 3.输入Emoji点查询 | SQL注入字符串、XSS字符串、Emoji表情 | UI:不报错不弹窗不异常页面。数据:后端返回空结果或正确转义，HTTP 200，无注入生效 | |
|
||||
| TC-FR-001 | 第一次上报 | 装货完成后系统自动触发第一次上报（全字段完整性） | P0 | 功能测试 | 1.运单已接单 2.车辆/司机/货物/托运方/收货方信息完整 3.司机完成装货确认 | 1.司机APP端确认装货完成 2.回管理端查看上报状态 | 完整运单数据（建单13+托运人7+收货方5+司机13+车辆19+货物+保险字段） | UI:列表出现该运单，状态:上传中(蓝)→已上传(绿)；看板显示"第一次上报"。数据:上报接口被调用，请求体含完整子对象，HTTP 200，数据库状态更新 | |
|
||||
| TC-FR-002 | 第一次上报 | 必选字段缺失（从业资格证号）→上报异常 | P1 | 功能测试 | 司机从业资格证号为空 | 1.触发装货完成上报 2.查看上报结果 | 司机信息缺失从业资格证号 | UI:状态=异常(橙)，操作列显示详情按钮；详情中异常原因含"从业资格证号缺失"。数据:接口返回校验失败，数据库记录状态=异常+异常原因 | |
|
||||
| TC-FR-003 | 第一次上报 | 可选字段为空（委托合同编号/运输里程/保险信息）→上报正常 | P1 | 功能测试 | 必选字段完整，可选字段均为空 | 1.触发装货完成上报 2.查看结果 | 可选字段均为空的运单 | UI:状态正常流转为"已上传"(绿)。数据:请求体可选字段值为null/空字符串，接口返回成功 | |
|
||||
| TC-FR-004 | 第一次上报 | 货物信息多条记录(≥2条)上报 | P2 | 功能测试 | 运单包含3条货物信息（钢材/木板/配件） | 1.触发上报 2.查看详情弹窗货物信息区 | 3条货物数据 | UI:详情弹窗展示3条货物记录各含4字段。数据:请求体goodsInfos数组length=3，接口成功 | |
|
||||
| TC-FR-005 | 第一次上报 | 核验通过后自动调用"修改第一次上报部分字段"更新实际里程 | P0 | 功能测试 | 1.第一次上报已触发 2.装货后实际里程变化(预估500→实际520km) | 1.上报成功核验通过 2.观察自动更新 3.查看运单里程字段 | 预估里程=500km, 实际里程=520km | UI:无人工干预下运单里程自动更新为520km；操作日志有"自动更新第一次上报字段"记录。数据:修改接口被调用，mileage=520，数据库运单里程更新 | |
|
||||
| TC-FR-006 | 第一次上报 | 上报失败→自动重试3次→站内信通知运营人员 | P1 | 功能测试 | 模拟安徽运八接口不可用(超时或500) | 1.触发上报 2.等待重试周期 3.观察最终结果 4.检查站内信 | 接口超时异常 | UI:状态流转:上传中→上传失败(红标签)，出现"手动上传"按钮；运营收到站内信含运单号和失败原因。数据:接口调用4次(首+3重试)，重试间隔递增；站内信表新增通知记录 | |
|
||||
| TC-FR-007 | 第一次上报 | 重试中手动触发上报→幂等性校验 | P1 | 功能测试 | 上报失败正处自动重试中 | 1.运单重试中 2.运营点"手动上传" | 重试中的运单 | UI:提示"上报处理中请勿重复操作"或排队等待；不出现两条上报记录。数据:同一运单在安徽运八平台仅一条记录 | |
|
||||
| TC-FR-008 | 第一次上报 | 第一次上报失败阻断后续第二、三次上报 | P0 | 功能测试 | 运单第一次上报失败(3次重试全败) | 1.确认第一次上报失败 2.尝试触发第二次上报 3.尝试触发第三次上报 | 第一次上报失败的运单 | UI:第二次上报按钮不可见/置灰提示"请先完成第一次上报"；第三次同样阻断。数据:第二/三次接口调用被前置校验拦截，日志无记录 | |
|
||||
| TC-FR-009 | 第一次上报 | 详情弹窗8组字段分组展示与数据一致性 | P1 | 功能测试 | 存在已完成的第一次上报运单 | 1.点详情 2.逐一查看建单/托运人/收货方/司机/车辆/货物/保险/异常分组 3.与运单管理模块核对 | 完整上报数据 | UI:弹窗按8组展示，分组标题明确；无异常时显示"无异常"；保险为空显示"-"。数据:弹窗字段值与上报请求体一致，与运单管理模块一致 | |
|
||||
| TC-FR-010 | 第一次上报 | 4种状态标签颜色验证 | P2 | 功能测试 | 准备4个运单分别处于上传中/已上传/上传失败/异常状态 | 1.进入列表 2.观察4条运单状态标签颜色 | 4种状态的运单 | UI:上传中=蓝标签；已上传=绿标签；上传失败=红标签；异常=橙标签。数据:状态字段值与颜色映射正确 | |
|
||||
| TC-SR-001 | 第二次上报 | 打款完成后自动触发上报（含资金流水+轨迹+7核验） | P0 | 功能测试 | 1.运单第一次上报已完成 2.财务完成打款 | 1.财务打款 2.查看第二次上报列表 | 完整打款数据(金额/流水号/时间/收款方/收款账号/账号类型) | UI:列表出现该运单状态"上传中"(蓝)；展示承运运费/总金额/付款方式/时间/收款人/收款账号/账号类型。数据:上报接口被调用，请求体含资金流水+轨迹信息；流水数据与账户管理模块一致 | |
|
||||
| TC-SR-002 | 第二次上报 | 车辆轨迹点位边界值:2个点(起点+终点)→成功 | P1 | 功能测试 | 轨迹数据仅2个点位 | 1.触发第二次上报 2.查看结果 | 轨迹数据=[起点,终点] len=2 | UI:上报成功状态"已上传"。数据:请求体轨迹数组length=2，接口成功 | |
|
||||
| TC-SR-003 | 第二次上报 | 车辆轨迹点位边界值:1个点→失败 | P2 | 功能测试 | 轨迹数据仅1个点位 | 1.触发第二次上报 2.查看结果 | 轨迹数据=[单点] len=1 | UI:上报失败状态"异常"(橙)；异常原因含"轨迹点位不足"。数据:接口返回校验失败提示轨迹点数需≥2 | |
|
||||
| TC-SR-004 | 第二次上报 | 运单重复上报→核验异常 | P0 | 功能测试 | 运单已完成第二次上报且核验通过 | 1.尝试再次上报同一运单 | 已通过的运单 | UI:系统提示"该运单已完成第二次上报"或被阻止；不产生新记录。数据:接口被前置校验拦截或安徽平台返回"运单重复"；数据库无重复记录 | |
|
||||
| TC-SR-005 | 第二次上报 | 车辆资质核验:道路运输证有效期内→通过 | P1 | 功能测试 | 车辆道路运输证有效期至2026-12-31(有效期内) | 1.触发第二次上报 2.等待核验 3.查看核验结果 | 有效期内的道路运输证 | UI:核验状态"通过"，无"车辆资质"异常项。数据:核验接口返回车辆资质=通过 | |
|
||||
| TC-SR-006 | 第二次上报 | 车辆资质核验:道路运输证已过期→异常 | P1 | 功能测试 | 车辆道路运输证有效期至2025-01-01(已过期) | 1.触发第二次上报 2.等待核验 | 过期的道路运输证 | UI:核验状态"异常"(橙)；异常项显示"车辆资质核验"不通过；可发起申诉。数据:核验接口返回车辆资质=异常，原因"道路运输证过期" | |
|
||||
| TC-SR-007 | 第二次上报 | 资金流水单号重复→系统自动拦截 | P0 | 功能测试 | 系统中已存在流水号LS202607130001的记录 | 1.创建新运单打款但流水号重复 2.触发第二次上报 | 重复流水号=LS202607130001 | UI:系统上报前自动检测到重复，提示"流水单号已使用请核实"；上报被阻止。数据:流水号唯一索引生效；接口未被调用；操作日志记录拦截 | |
|
||||
| TC-SR-008 | 第二次上报 | 资金流水金额不匹配(合同10000 vs 打款9500)→核验异常 | P1 | 功能测试 | 合同金额10000元，实际打款9500元 | 1.触发第二次上报 2.等待核验 | 合同金额=10000, 打款金额=9500 | UI:核验状态"异常"；异常项含"资金流水核验"不通过，原因"金额不匹配"。数据:核验接口返回资金流水核验=异常 | |
|
||||
| TC-SR-009 | 第二次上报 | 车辆轨迹合规异常→补传轨迹→重新核验通过 | P1 | 功能测试 | 第二次上报后"车辆轨迹合规"核验异常 | 1.点"补传轨迹" 2.上传补充GPS点位文件 3.提交 4.等待重新核验 | 补充轨迹GPS文件 | UI:补传轨迹按钮可见可点击；上传后提示成功等待核验；核验通过后异常消除状态变"通过"。数据:补传轨迹追加到原数据；重调核验接口；核验结果更新为通过 | |
|
||||
| TC-SR-010 | 第二次上报 | 收款账号类型标签:个人=蓝色/对公=绿色 | P2 | 功能测试 | 两个运单:一个司机个人账户、一个企业对公账户 | 1.进入列表 2.查看收款账号类型标签 | 个人账户(司机银行卡)、对公账户(企业银行账号) | UI:个人账户=蓝标签"个人账户"；对公账户=绿标签"对公账户"。数据:字段值正确对应 | |
|
||||
| TC-SR-011 | 第二次上报 | 重试3次全失败→告警通知运营人员 | P1 | 功能测试 | 模拟安徽运八接口不可用 | 1.触发第二次上报 2.等3次重试全失败 3.检查告警 | 接口不可用 | UI:状态变为"上传失败"(红)；出现"手动上传"按钮；运营收到站内信通知含运单号/失败原因/重试次数。数据:重试次数=3；站内信表新增告警通知；操作日志记录完整 | |
|
||||
| TC-TR-001 | 第三次上报 | 开票完成后触发上报（含17字段发票+托运单号数组） | P0 | 功能测试 | 1.运单第二次上报已完成 2.发票已开具 | 1.开票审核模块完成开票 2.查看第三次上报列表 | 完整发票信息(17字段)+托运单号数组 | UI:列表出现该运单含发票号码/金额/开票日期；状态:上传中→已上传。数据:上报接口被调用；发票数据与开票审核模块一致 | |
|
||||
| TC-TR-002 | 第三次上报 | 第二次上报未完成时第三次上报被阻断 | P1 | 功能测试 | 运单仅完成第一次上报，第二次未完成 | 1.尝试开票并触发第三次上报 | 第二次未完成的运单 | UI:系统提示"请先完成第二次上报"；上报按钮不可见/置灰。数据:第三次上报接口调用被前置校验拦截 | |
|
||||
| TC-TR-003 | 第三次上报 | 增值税发票验证失败→上报异常 | P1 | 功能测试 | 发票号码格式错误或与代码不匹配 | 1.触发第三次上报 2.查看结果 | 错误的发票号码/代码 | UI:上报状态"异常"(橙)；原因提示"增值税发票验证失败"及具体原因。数据:接口返回发票验证失败业务错误码；数据库记录异常状态 | |
|
||||
| TC-TR-004 | 第三次上报 | 发票金额精度:价税合计保留2位小数四舍五入 | P2 | 功能测试 | 发票金额=12345.678元(超2位小数) | 1.触发第三次上报 2.查看列表发票金额 | 发票金额=12345.678 | UI:列表发票金额显示12,345.68(四舍五入)。数据:请求体invoiceAmount=12345.68，无浮点精度丢失 | |
|
||||
| TC-TR-005 | 第三次上报 | 油气发票多条记录上报 | P2 | 功能测试 | 运单关联2条油气发票 | 1.触发第三次上报 2.查看详情弹窗油气发票区 | 2条油气发票记录 | UI:油气发票区展示2条记录各含托运单号和发票文件。数据:请求体油气发票数组length=2 | |
|
||||
| TC-ETC-001 | ETC发票上传 | 税务抵扣完成后上传ETC发票(18字段/每张) | P1 | 功能测试 | 1.车辆完成高速运输 2.ETC发票已获取 3.税务抵扣完成 | 1.选运单 2.上传ETC发票信息 3.提交 | ETC发票完整18字段 | UI:上传成功状态"已上传"(绿)；列表含ETC发票号码/金额/税率/上传状态。数据:请求体含18字段；税额=发票金额×3% | 合TP-ETC-001,003 |
|
||||
| TC-ETC-002 | ETC发票上传 | 税务抵扣未完成→上传被阻止 | P1 | 功能测试 | ETC发票存在但税务抵扣未完成 | 1.尝试上传ETC发票 | 抵扣未完成的ETC发票 | UI:系统提示"请先完成税务抵扣"；上传被阻止。数据:上传接口调用被前置校验拦截 | |
|
||||
| TC-ETC-003 | ETC发票上传 | 税额计算:3%税率精度验证(1000元→30.00元) | P1 | 功能测试 | ETC发票金额1000.00元 | 1.上传1000元ETC发票 2.查看税额 | 发票金额=1000.00 | UI:税额显示30.00元。数据:taxAmount=1000.00×0.03=30.00，2位小数 | |
|
||||
| TC-ETC-004 | ETC发票上传 | 税额计算:大额发票100万元→30000.00元 | P2 | 功能测试 | ETC发票金额1000000元 | 1.上传100万元ETC发票 2.查看税额 | 发票金额=1000000.00 | UI:税额显示30,000.00元。数据:taxAmount=1000000.00×0.03=30000.00，无精度问题 | |
|
||||
| TC-ETC-005 | ETC发票上传 | ETC发票验证失败→上报异常提示检查发票 | P2 | 功能测试 | ETC发票号码/代码与实际不匹配 | 1.上传错误ETC发票 2.查看验证结果 | 错误的ETC发票号码/代码 | UI:状态"异常"(橙)；原因提示"ETC发票验证失败请检查发票信息"。数据:接口返回ETC发票验证失败 | |
|
||||
| TC-AP-001 | 异常申诉 | 核验异常运单发起申诉（申诉原因+附件） | P1 | 功能测试 | 运单第二次上报核验异常(车辆轨迹合规异常) | 1.找到异常运单 2.点"申诉" 3.填原因:"实际路线因道路施工绕行" 4.上传附件(施工证明截图) 5.提交 | 申诉原因文本、路线施工证明截图 | UI:提交后提示"申诉已提交等待监管平台复核"；申诉状态变"申诉中"；列表新增申诉记录。数据:申诉表新增记录:申诉单号自动生成/异常项=车辆轨迹合规/原因已保存/附件已存储/状态=申诉中/时间=当前 | |
|
||||
| TC-AP-002 | 异常申诉 | 申诉原因必填校验→空值拦截 | P2 | 功能测试 | 存在可申诉异常运单 | 1.点申诉 2.不填原因 3.直接提交 | 申诉原因为空 | UI:输入框标红或提示"请填写申诉原因"；提交按钮不响应或提示错误。数据:申诉接口未被调用；数据库无新记录 | |
|
||||
| TC-AP-003 | 异常申诉 | 申诉状态流转:申诉中→申诉通过(监管复核通过) | P1 | 功能测试 | 已提交申诉(申诉中状态) | 1.等待监管平台复核通过 2.查看申诉记录 | 申诉中的记录 | UI:申诉状态变"申诉通过"(绿)；省平台反馈"复核通过"；原运单异常项消除或已解决。数据:申诉记录状态更新；省平台反馈时间/结果/意见已记录；关联运单核验状态更新 | |
|
||||
| TC-AP-004 | 异常申诉 | 申诉状态流转:申诉中→申诉驳回→重新申诉 | P1 | 功能测试 | 申诉被监管平台驳回 | 1.查看驳回记录和原因 2.点"重新申诉" 3.补充材料修改原因 4.提交 | 驳回原因、补充材料 | UI:驳回记录显示"复核不通过"+反馈意见；"重新申诉"按钮可见；表单保留原内容可编辑；提交后状态变"申诉中"。数据:新申诉关联原单号；原记录保留不变；新申诉状态=申诉中 | |
|
||||
| TC-AP-005 | 异常申诉 | 详情弹窗:时间线展示处理记录(申诉→驳回→重申诉→通过) | P2 | 功能测试 | 申诉记录有多次操作历史 | 1.点"详情" 2.查看处理记录区 | 完整申诉历史数据 | UI:处理记录时间线展示从早到晚；每条含操作人/时间/类型/内容；类型区分清晰(发起申诉/省平台反馈/重新申诉/复核通过)。数据:数据库操作日志完整 | |
|
||||
| TC-AP-006 | 异常申诉 | 核验通过运单无申诉入口→越权防护 | P1 | 功能测试 | 运单核验状态为"通过" | 1.找到核验通过运单 2.查看操作列 3.尝试通过URL直接访问申诉接口 | 核验通过的运单 | UI:操作列不显示"申诉"按钮。数据:申诉接口返回"当前运单核验状态不允许申诉" | |
|
||||
| TC-LOG-001 | 上报日志 | 多条件日志查询(上报阶段+结果+时间范围) | P2 | 功能测试 | 系统存在多条不同阶段日志 | 1.进入上报日志 2.选阶段=第二次上报 3.选结果=失败 4.设时间范围近7天 5.点查询 | 筛选条件组合 | UI:列表展示满足条件的日志含10个字段(序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间)。数据:查询条件正确传递；返回数据与筛选一致 | |
|
||||
| TC-LOG-002 | 上报日志 | 失败日志详情弹窗:完整请求/响应报文(JSON格式化) | P2 | 功能测试 | 存在一条失败的第二次上报日志 | 1.点失败日志"详情" 2.查看请求和响应报文 | 失败日志记录 | UI:弹窗展示完整请求报文(JSON格式化含所有字段)和响应报文(含错误码/错误信息)；报文可复制。数据:展示报文与实际上报接口请求/响应一致 | |
|
||||
| TC-CM-001 | 通用跨模块 | 金额精度:多次计算无累积浮点误差 | P1 | 功能测试 | 运单合同金额=12345.67元 | 1.第一次上报看合同金额 2.第二次上报看总金额 3.第三次上报看发票金额 4.对比三次精度 | 合同金额=12345.67 | UI:所有金额显示2位小数千分位正确无精度丢失。数据:DB存DECIMAL(18,2)；接口返回2位小数字符串；计算无浮点误差 | 来源:风险矩阵+易漏场景 |
|
||||
| TC-CM-002 | 通用跨模块 | 重复提交防抖:快速多次点击手动上传→仅一次请求 | P1 | 功能测试 | 存在上传失败运单 | 1.连续快速点击"手动上传"3次 2.等待结果 | 上传失败运单 | UI:按钮首次点击后变loading/置灰防重复点击；仅产生一次上报请求。数据:上报接口仅调用1次；上报日志仅1条记录 | 来源:易漏场景 |
|
||||
| TC-CM-003 | 通用跨模块 | 未登录直接URL访问上报看板→拦截跳转登录 | P2 | 安全性测试 | 退出登录状态 | 1.清除登录态 2.地址栏直接输入看板URL 3.观察页面 | 看板URL | UI:重定向到登录页或显示"请先登录"；不展示上报数据。数据:上报API返回401 Unauthorized | |
|
||||
| TC-CM-004 | 通用跨模块 | 权限隔离:司机账号(15188888888)无法访问上报管理 | P1 | 安全性测试 | 司机账号15188888888/88888888 | 1.司机登录管理端 2.尝试访问看板/申诉管理等页面 | 司机账号凭证 | UI:菜单无"安徽运八"入口；直接URL访问重定向或"无权限"；不展示上报数据。数据:上报API返回403 Forbidden | |
|
||||
| TC-CM-005 | 通用跨模块 | 第一次上报与运单管理模块数据一致性 | P1 | 功能测试 | 运单在运单管理模块已有完整数据 | 1.记录运单管理模块关键字段 2.触发第一次上报 3.在详情弹窗核对 | 货源单号/运单号/托运单号/车牌号/司机姓名/托运方/货物/装货地址/卸货地址/运输里程 | UI:上报详情字段值与运单管理一致。数据:上报请求体值来源于运单管理DB记录，数据一致 | |
|
||||
| TC-CM-006 | 通用跨模块 | 第二次上报资金流水与账户管理支付流水数据一致性 | P1 | 功能测试 | 运单已完成打款，支付流水号已知 | 1.在账户管理→支付流水查看打款数据 2.触发第二次上报 3.在上报详情核对资金流水 | 支付金额/流水号/支付时间/收款方 | UI:第二次上报详情中资金流水与账户管理模块一致。数据:上报请求体资金流水与支付流水表数据一致；流水号完全匹配 | |
|
||||
| TC-CM-007 | 通用跨模块 | 司机信息上报(13字段)与司机审核模块数据一致性 | P1 | 功能测试 | 司机已在审核管理模块通过审核 | 1.记录司机审核模块司机信息 2.触发第一次上报 3.核对上报详情司机信息 | 司机姓名/身份证号/驾驶证号/从业资格证号/手机号等13字段 | UI:上报详情司机13字段与审核模块一致。数据:上报请求体driverInfo来源于司机审核表 | |
|
||||
| TC-CM-008 | 通用跨模块 | 上报接口超时(>30s)→前端Loading+超时提示 | P2 | 功能测试 | 模拟上报接口响应超30秒 | 1.触发上报 2.观察前端表现 | 超时接口 | UI:按钮Loading状态(转圈/禁用)；超30秒后显示"上报超时请稍后查看结果"；不白屏不假死。数据:接口超时后后端异步处理或标记超时；DB状态=上传失败/原因=超时 | |
|
||||
|
||||
> 用例总数: 53 (P0:7 / P1:26 / P2:20)
|
||||
Binary file not shown.
@@ -1,7 +0,0 @@
|
||||
# 新人礼需求 版本索引
|
||||
|
||||
| 版本 | 类型 | 内容摘要 | 目录 |
|
||||
| --- | --- | --- | --- |
|
||||
| v7 | 历史 Excel 导入 | excel、migration_note | `output/versions/新人礼需求/v7` |
|
||||
| v8 | 完整流水线快照 | manifest、analysis、relation_report、test_points、test_cases_markdown、excel、normalized_inputs | `output/versions/新人礼需求/v8` |
|
||||
| v9 | 完整流水线快照 | manifest、analysis、relation_report、test_points、test_cases_markdown、excel、normalized_inputs | `output/versions/新人礼需求/v9` |
|
||||
@@ -1,10 +0,0 @@
|
||||
{
|
||||
"base_name": "新人礼需求",
|
||||
"version": "v7",
|
||||
"snapshot_type": "legacy_excel_import",
|
||||
"summary": [
|
||||
"excel",
|
||||
"migration_note"
|
||||
],
|
||||
"note_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/versions/新人礼需求/v7/snapshot_note.md"
|
||||
}
|
||||
@@ -1,6 +0,0 @@
|
||||
# 新人礼需求_测试用例 历史 Excel 导入说明
|
||||
|
||||
- 导入来源：`新人礼需求_测试用例_20260426_173650.xlsx`
|
||||
- 导入类型：旧时间戳命名 Excel
|
||||
- 说明：该快照仅迁移了历史 Excel，本次未重建当时对应的分析、测试点、测试用例 Markdown 与 manifest。
|
||||
- 目的：统一历史文件归档路径，并清理 `output/excel_reports/` 中的旧时间戳文件。
|
||||
Binary file not shown.
@@ -1,61 +0,0 @@
|
||||
# 新人礼需求
|
||||
|
||||
> 文档角色：需求文档
|
||||
> 原始来源：`source_docs/requirements_raw/新人礼需求.docx`
|
||||
|
||||
基线-新人礼
|
||||
| 版本号 | 变更内容 | 变更人 | 变更时间 |
|
||||
| 0.0.1 | 文档创建 | 张昊 | 2026-02-28 |
|
||||
一、业务背景
|
||||
基于问界需求清单 新人礼需求
|
||||
二、业务目标
|
||||
通过发布新人礼活动，吸引新用户注册使用～平台端&商家端支持发布新人礼活动，支持配置优惠券奖品，c端新用户注册展示新人礼内容
|
||||
三、产品设计
|
||||
1. 平台端-营销-新人有礼
|
||||
1.1 新人有礼列表
|
||||
列表数据说明
|
||||
数据权限：有此菜单列表权限的用户可看数据
|
||||
排序规则：按数据新增时间倒序排列
|
||||
分页规则：默认10行每页，可自主选择每页显示的条数（10/20/30/50）
|
||||
数据来源：如下表
|
||||
| 数据字段 | 数据来源 |
|
||||
| 活动名称 | 来源【新增/编辑】表单同名字段 |
|
||||
| 活动时间 | 来源【新增/编辑】表单“活动时间“数据 |
|
||||
| 活动状态 | 见下方状态逻辑说明 |
|
||||
| 活动有效性 | 展示有效/已失效，支持 失效活动，失效后展示 已失效，失效后 操作栏展示删除操作 |
|
||||
| 活动奖品 | 展示活动配置的奖品，当前活动奖品仅支持优惠券 |
|
||||
| 创建时间 | 活动创建时间 |
|
||||
状态逻辑说明
|
||||
| 状态名称 | 状态变更条件 | 可操作按钮 |
|
||||
| 未开始 | 活动时间开始时间>当前时间 | 编辑，失效 |
|
||||
| 进行中 | 活动时间开始时间<=当前时间 | 查看，失效 |
|
||||
| 已结束 | 活动时间结束时间<当前时间 | 删除 |
|
||||
查询条件说明
|
||||
| 查询条件 | 查询逻辑 |
|
||||
| 活动名称 | 模糊查询，查询列表字段“活动名称” |
|
||||
| 活动状态 | 精准查询，单选，选项数据：未开始、进行中、已结束、已失效，默认空 |
|
||||
功能按钮说明
|
||||
| 按钮名称 | 触发后逻辑说明 | |
|
||||
| 新建 | 在当前窗口打开“新建新人礼”弹窗 | |
|
||||
| 查询 | 1、已选查询条件情况下，列表显示符合条件的数据 2、查询条件无匹配数据时，列表显示空，提示”暂无数据“ | |
|
||||
| 重置 | 清空查询条件 | |
|
||||
| 编辑 | 打开编辑表单弹窗 | |
|
||||
| 查看 | 打开查看表单弹窗 | |
|
||||
| 失效 | 打开失效操作弹窗，失效操作后，状态变更为已失效 | |
|
||||
| 删除 | 打开删除操作弹窗，删除操作后，在列表删除活动（永久删除）；取消后，关闭删除弹窗。 | |
|
||||
1.2 新增/编辑
|
||||
页面字段说明
|
||||
| 字段名称 | 逻辑规则 | 是否必填 | 是否可编辑 | 原型界面、逻辑补充 |
|
||||
| 活动名称 | 文本输入，最多50个字 | 是 | 是 | |
|
||||
| 活动时间 | 开始时间-结束时间，年月日时分秒 | 是 | 是 | 控制活动的有效时段，可选择的时间大于等于当前时间，结束时间大于开始时间 |
|
||||
| 活动奖品 | 多选 | 是 | 是 | |
|
||||
| | 送优惠券 优惠券： 勾选后展示选择优惠券，只能选择1张优惠券，选择后展示选中优惠券信息表格 选择优惠券弹窗： 通用优惠券选择弹窗，单选 平台端展示平台可用优惠券列表， 商家端展示商家可用的优惠券列表， 优惠券列表数据展示规则：投放，未过期且为 用户领取 的优惠券，支持根据名称筛选 | 是 | 是 | 优惠券列表：选择前 优惠券列表：选择后 选择优惠券弹窗： |
|
||||
| | 送积分 可输入1-999999的整数，配置生效后调用发积分接口发放积分 | 是 | 否 | 暂不支持 |
|
||||
2. 商家端-营销-新人有礼
|
||||
功能同平台端，仅优惠券选择时，仅可选择该店铺下的优惠券
|
||||
3. C端
|
||||
3.1 首页
|
||||
| 平台首页-新人礼领取提示 奖励领取后，可在个人中心优惠券查看 | 店铺首页-新人礼领取提示 |
|
||||
| 功能点 | 功能说明 |
|
||||
| 弹窗逻辑 | 1）用户未在任意门店下过单，即视为新用户，登录后进入首页，弹窗提示用户领取新人礼奖励 2）用户未在该门店下过单，即视为门店新用户，登录后进入门店首页，弹窗提示用户领取新人礼奖励时机3）如果平台或店铺设置了弹窗广告，则新人礼弹窗在弹窗广告之前展示，关闭新人礼弹窗后，展示弹窗广告内容 |
|
||||
| 优惠券 | 用户点击新人礼弹窗立即领取按钮，如果领取成功，奖励进入我的-优惠券列表，并提示用户领取成功 |
|
||||
@@ -1,66 +0,0 @@
|
||||
# 新人礼技术方案
|
||||
|
||||
> 文档角色：技术方案
|
||||
> 原始来源：`source_docs/technical_solutions/新人礼技术方案.docx`
|
||||
|
||||
基线改造---新人礼技术方案&需求概述
|
||||
| 版本号 | 变更内容 | 变更人 | 变更时间 |
|
||||
| 1.0 | 建档 | 陶震 | 2026-2-21 |
|
||||
1 背景
|
||||
1.1 需求背景
|
||||
新增，针对于新注册，未下单用户发放专属优惠券的场景（暂不支持下单后退款场景）
|
||||
1.2 业务现况
|
||||
1.3. 业务系统现况
|
||||
1.4 名词说明
|
||||
| 名称 | 描述 |
|
||||
| 新人(平台新人，店铺新人) | 平台新人：未在该平台下过单的用户，即shop_custormer中无任何数据的user 店铺新人：未在该店铺下过单的用户，即shop——customer中无该店铺该user数据的用户 |
|
||||
1.7 涉及人员
|
||||
| 角色名称 | 使用内容 |
|
||||
| 用户 | 消费者 |
|
||||
| 运营 | 商城日常使用维护以及操作者。 |
|
||||
2 目标
|
||||
本期实现目标说明：
|
||||
2.1、技术目标
|
||||
| 技术指标 | 指标值 | 备注 |
|
||||
| 用户响应RT | 1000ms | |
|
||||
| 用户体量 | | |
|
||||
| 并发数 | | |
|
||||
| 开发语言 | | |
|
||||
| 网络要求 | | |
|
||||
3 整体概述
|
||||
3.1 需求概述
|
||||
同一时间仅允许一个新人礼活动(避免同一时间多个活动发放业务过重)。关联优惠券仅支持关联一张
|
||||
C端弹窗，若存在进行中的新人礼活动且用户未领取过，则进行弹窗
|
||||
3.2 业务架构图（一图概览）
|
||||
3.3 业务模块列表
|
||||
3.4 第三方服务列表(可选)
|
||||
| 服务厂商 | 类型（接口/设备） | 接口地址 | 备注 | 状态 |
|
||||
3.5 技术架构
|
||||
3.5.1 前端设计
|
||||
3.5.2 后端设计
|
||||
3.6 领域模型设计
|
||||
新人礼主表
|
||||
| SQLCREATE TABLE `new_gift` ( `new_gift_id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `shop_id` bigint NOT NULL COMMENT '关联店铺 平台为0', `activity_name` varchar(255) COLLATE utf8mb4_general_ci NOT NULL COMMENT '活动名称', `activity_start_time` datetime NOT NULL COMMENT '活动开始时间', `activity_end_time` datetime NOT NULL COMMENT '活动结束时间', `gift_type` int NOT NULL COMMENT '礼物类型 0优惠券 其他待拓展', `activity_status` int NOT NULL COMMENT '活动状态0未开始，1进行中，2已结束', `valid_status` int NOT NULL DEFAULT '0' COMMENT '有效性 0有效 1已失效', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', `deleted` int NOT NULL DEFAULT '0' COMMENT '是否已删除 0否1是', PRIMARY KEY (`new_gift_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='新人礼主表'; |
|
||||
新人礼关联礼物表
|
||||
| SQLCREATE TABLE `new_gift_detail` ( `new_gift_detail_id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `new_gift_id` bigint NOT NULL COMMENT '新人礼主键', `gift_type` int NOT NULL COMMENT '礼物类型 0优惠券 其他待拓展', `gift_biz_id` bigint NOT NULL COMMENT '礼物主键Id', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`new_gift_detail_id`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='新人礼 子表，存储主表与礼物关联关系'; |
|
||||
新人礼发放记录表
|
||||
| SQLCREATE TABLE `new_gift_send_log` ( `new_gift_log_id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `user_id` bigint NOT NULL COMMENT '用户ID', `send_status` int NOT NULL COMMENT '发放状态 0成功 1失败', `fail_reason` json DEFAULT NULL COMMENT '失败原因', `new_gift_id` bigint NOT NULL COMMENT '新人礼主键', `new_gift_detail_id` bigint NOT NULL COMMENT '礼物详情主键', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`new_gift_log_id`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='新人礼发放记录表'; |
|
||||
3.7 数据模型设计
|
||||
详见领域模型
|
||||
3.8 依赖项
|
||||
| 依赖项 | 作用 | 预计提供时间 | 状态 | 责任人 | 交付物 |
|
||||
4 场景（user story）与流程图（How）
|
||||
4.1 新增活动
|
||||
4.1.1 业务流程图
|
||||
4.1.2 时序图
|
||||
4.1.3 接口依赖
|
||||
无
|
||||
4.1.4 接口设计
|
||||
| API | 状态 | 说明 |
|
||||
| /mp/newGift/save | 未开发 | 新增新人礼活动 |
|
||||
| /mp/newGift/update | 未开发 | 修改新人礼活动 |
|
||||
| /mp/newGift/detail | 未开发 | 查看新人礼详情 |
|
||||
| /mp/newGift/delete | 未开发 | 删除新人礼活动 |
|
||||
| /mp/newGift/page | 未开发 | 新人礼活动分页查询 |
|
||||
| /ua/newGift/check | 未开发 | 检测用户是否符合进行中的平台/店铺中的新人礼活动。 |
|
||||
| /ua/newGift/send | 未开发 | 为用户发放对应新人礼绑定的券 |
|
||||
@@ -1,43 +0,0 @@
|
||||
{
|
||||
"requirement": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/source_docs/requirements_raw/新人礼需求.docx",
|
||||
"requirement_source_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/source_docs/requirements_raw/新人礼需求.docx",
|
||||
"requirement_input_type": "docx",
|
||||
"base_name": "新人礼需求",
|
||||
"normalized_requirement_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/normalized_inputs/新人礼需求/requirement.md",
|
||||
"technical_solution_files": [
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/source_docs/technical_solutions/新人礼技术方案.docx"
|
||||
],
|
||||
"normalized_technical_solution_files": [
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/normalized_inputs/新人礼需求/technical_solution_01.md"
|
||||
],
|
||||
"analysis_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/analysis/新人礼需求_分析.md",
|
||||
"relation_report_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/analysis/新人礼需求_关联与冲突.md",
|
||||
"test_points_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/test_points/新人礼需求_测试点.md",
|
||||
"test_cases_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/test_cases/新人礼需求_测试用例.md",
|
||||
"excel_output_dir": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/excel_reports",
|
||||
"project_profile_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/00_project/project_profile.md",
|
||||
"knowledge_base_files": [
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/01_standards/terminology.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/01_standards/test_case_template.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/01_standards/definition_of_done.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/01_standards/review_checklist.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/02_history/common_missed_scenes.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/02_history/historical_defects.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/02_history/marketing_rules.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/03_best_practices/payment_flow_cases.md"
|
||||
],
|
||||
"effective_terminology_files": [
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/01_standards/terminology.md"
|
||||
],
|
||||
"optional_terminology_files": [],
|
||||
"related_requirements": [],
|
||||
"conflict_candidates_count": 0,
|
||||
"current_excel_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/excel_reports/新人礼需求_测试用例.xlsx",
|
||||
"versioning_scheme": {
|
||||
"current_files": "固定文件名，始终表示当前最新版",
|
||||
"snapshot_rule": "仅在 export 成功且产物内容发生变化时递增版本",
|
||||
"snapshot_dir_pattern": "output/versions/{BASE_NAME}/vN/"
|
||||
},
|
||||
"latest_snapshot_version": "v8",
|
||||
"latest_snapshot_dir": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/versions/新人礼需求/v8"
|
||||
}
|
||||
@@ -1,16 +0,0 @@
|
||||
# 新人礼需求 关联需求与冲突检查
|
||||
|
||||
## 目标需求
|
||||
- `source_docs/requirements_raw/新人礼需求.docx`
|
||||
|
||||
## 项目画像
|
||||
- `knowledge_base/00_project/project_profile.md`
|
||||
|
||||
## 关联技术方案
|
||||
- `source_docs/technical_solutions/新人礼技术方案.docx`
|
||||
|
||||
## 关联需求识别
|
||||
- 未识别到相似度达到阈值的历史需求文档。
|
||||
|
||||
## 潜在冲突与修改建议
|
||||
- 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。
|
||||
@@ -1,111 +0,0 @@
|
||||
# 新人礼需求分析
|
||||
|
||||
## 背景与目标
|
||||
|
||||
本期需求围绕“新人礼”活动能力建设，目标是在平台端和商家端支持配置新人礼活动，并在 C 端针对符合新人条件的用户展示领取入口与发放优惠券奖励，提升新注册用户的首单转化。
|
||||
|
||||
技术方案补充了两个关键限制：
|
||||
|
||||
- 同一时间仅允许存在 1 个进行中的新人礼活动。
|
||||
- 每个新人礼活动仅允许绑定 1 张优惠券，发放结果需落新人礼发放记录表。
|
||||
|
||||
## 范围与边界
|
||||
|
||||
### 范围内
|
||||
|
||||
- 平台端“营销-新人有礼”列表、查询、新建、编辑、查看、失效、删除。
|
||||
- 商家端“营销-新人有礼”同构能力。
|
||||
- 新人礼活动配置字段校验：活动名称、活动时间、活动奖品、优惠券选择。
|
||||
- 优惠券选择范围控制：平台端仅选平台券，商家端仅选本店铺优惠券。
|
||||
- C 端首页和门店首页的新人礼弹窗检查与领取。
|
||||
- 发放成功后的优惠券入账和发放记录落库。
|
||||
- `ua/newGift/check` 与 `ua/newGift/send` 对应的资格校验和发放行为。
|
||||
|
||||
### 范围外
|
||||
|
||||
- 积分类型新人礼，需求和技术方案均明确“暂不支持”。
|
||||
- 下单后退款再重新认定为新人场景，技术方案明确“暂不支持下单后退款场景”。
|
||||
- 多奖品、多券组合、多人拼抢同一活动池等扩展玩法。
|
||||
|
||||
## 用户角色与前置条件
|
||||
|
||||
- 平台运营：维护平台维度新人礼活动。
|
||||
- 商家运营：维护店铺维度新人礼活动。
|
||||
- C 端用户：登录后触发首页或门店首页新人礼检查与领取。
|
||||
- 后端系统：负责活动状态判断、资格校验、优惠券发放、发送日志写入。
|
||||
|
||||
前置条件：
|
||||
|
||||
- 已存在投放中、未过期、领取方式为“用户领取”的优惠券。
|
||||
- 用户已登录，且能获取平台维度与店铺维度的历史下单信息。
|
||||
- 发券接口可用，优惠券中心返回的券状态准确。
|
||||
|
||||
## 关键业务规则
|
||||
|
||||
1. 平台端和商家端都可以配置新人礼活动，但优惠券范围必须与端侧归属一致。
|
||||
2. 活动名称最多 50 个字。
|
||||
3. 活动开始时间必须大于等于当前时间，结束时间必须大于开始时间。
|
||||
4. 活动奖品当前仅支持优惠券，且每个活动仅能关联 1 张优惠券。
|
||||
5. 平台维度同一时间仅允许 1 个进行中的平台新人礼活动；店铺维度同一时间每个店铺仅允许 1 个进行中的门店新人礼活动。
|
||||
6. 新人判定按订单提交结果范围判断：平台新人礼查询平台范围订单，店铺新人礼查询当前店铺订单；若用户从未提交过订单，或历史订单最终状态均为交易关闭（包括未支付取消、超时未付、已退款订单等），仍视为新人。
|
||||
7. 用户登录首页时，若存在进行中的新人礼活动且用户未领取过，则展示新人礼弹窗。
|
||||
8. 门店首页只对门店新人展示门店新人礼弹窗。
|
||||
9. 若同时存在弹窗广告，新人礼弹窗必须先于广告弹窗展示。
|
||||
10. 用户点击立即领取成功后，奖励进入“我的优惠券”，同时写入新人礼发放记录。
|
||||
11. 活动“已结束”和“已失效”并存时，页面优先展示“已失效”。
|
||||
12. 活动失效后状态展示为“已失效”，并支持后续删除。
|
||||
13. 用户领取平台新人礼后，若仍满足门店新人条件，允许继续领取门店新人礼。
|
||||
|
||||
## 主流程描述
|
||||
|
||||
1. 运营在平台端或商家端进入“营销-新人有礼”列表页。
|
||||
2. 运营新建活动，填写活动名称、活动时间并选择 1 张符合条件的优惠券。
|
||||
3. 系统校验时间、优惠券范围、优惠券状态和活动并存规则，保存活动。
|
||||
4. 活动进入“未开始”或“进行中”状态，列表页按状态展示可操作按钮。
|
||||
5. C 端用户登录平台首页或门店首页时，调用资格检查接口。
|
||||
6. 若存在进行中的匹配活动且用户符合新人条件且未领取过，则展示新人礼弹窗。
|
||||
7. 用户点击“立即领取”，系统发放优惠券并记录发放日志。
|
||||
8. 发放成功后，用户可在个人中心优惠券列表查看奖励。
|
||||
|
||||
## 跨需求关联与冲突修订建议
|
||||
|
||||
- 当前未识别到需要纳入本次评审的关联需求，也未发现需要基于历史需求执行的规则冲突修订。
|
||||
- 当前无需对历史需求做口径覆盖修订，但仍需重点防御营销类公共风险：
|
||||
- 重复点击导致重复发放。
|
||||
- 前端传参篡改导致越权选券或跨店铺发券。
|
||||
- 状态变更与页面展示不一致。
|
||||
|
||||
## 技术方案补充约束
|
||||
|
||||
- `ua/newGift/check` 负责资格检查，应重点验证平台维度和店铺维度“新人”判定口径。
|
||||
- `ua/newGift/send` 负责发券，应重点验证幂等、防重复领取、失败原因记录和成功落库。
|
||||
- 数据模型拆分为主表、礼物关联表、发放记录表，说明测试不能只看页面成功提示，还要覆盖：
|
||||
- `new_gift` 主表活动状态和有效性字段。
|
||||
- `new_gift_detail` 活动与券的绑定关系。
|
||||
- `new_gift_send_log` 发放成功或失败记录。
|
||||
- 技术目标给出用户响应 RT 1000ms，应至少对资格检查和领取动作补充性能基线关注。
|
||||
|
||||
## 产品确认口径
|
||||
|
||||
- 活动并存范围：平台维度同一时间仅允许 1 条进行中的平台活动；店铺维度同一时间每个店铺仅允许 1 条进行中的门店活动。
|
||||
- 新人判定口径：若用户从未提交过订单，或历史订单最终状态均为交易关闭（包括未支付取消、超时未付、已退款订单），仍视为新人。
|
||||
- 状态展示优先级：活动“已结束”和“已失效”并存时，优先展示“已失效”。
|
||||
- 平台礼与门店礼关系：用户已领取平台新人礼后，只要满足门店新人条件，仍允许领取门店新人礼。
|
||||
|
||||
## 项目差异化测试约束
|
||||
|
||||
- 平台端、商家端、C 端是三套角色链路，必须覆盖角色隔离和数据隔离。
|
||||
- 这是典型营销发券能力，需重点覆盖越权选券、重复发放、状态错发和资损场景。
|
||||
- 预期结果必须同时覆盖 UI 反馈和后台状态变化，特别是活动状态、券领取结果、发放日志。
|
||||
|
||||
## 风险点与确认结果
|
||||
|
||||
- 风险点：重复点击“立即领取”或接口重试导致同一用户重复发放优惠券。
|
||||
- 风险点：商家端错误选择了其他店铺的优惠券，导致跨店资损或越权发券。
|
||||
- 风险点：活动失效、已结束、已删除三个状态口径不清，可能导致列表按钮和实际行为不一致。
|
||||
- 风险点：平台新人和店铺新人的判定依赖历史订单数据，若口径不清，容易误发或漏发。
|
||||
- 风险点：同一时间仅允许 1 个进行中的活动，如果平台端和商家端同时配置活动，范围口径不清会导致规则冲突。
|
||||
- 确认结果：平台端和商家端活动可以并存，但约束粒度为“平台一条、每店铺各一条”。
|
||||
- 确认结果：未支付取消、超时未付、已退款等最终交易关闭单据不影响新人资格。
|
||||
- 确认结果：活动“已结束”和“已失效”同时成立时，页面优先展示“已失效”。
|
||||
- 确认结果：已领取平台新人礼的用户，若满足门店新人条件，仍允许继续领取门店新人礼。
|
||||
@@ -1,71 +0,0 @@
|
||||
# 新人礼需求测试点
|
||||
|
||||
## 1. 平台端列表与状态管理
|
||||
|
||||
1. 校验平台端列表默认按创建时间倒序展示，分页默认 10 条，支持切换 10、20、30、50 条。[需求]
|
||||
2. 校验按活动名称模糊查询、按活动状态精准查询、重置查询条件的行为正确。[需求]
|
||||
3. 校验活动状态“未开始、进行中、已结束、已失效”的展示口径和操作按钮是否符合规则。[需求]
|
||||
4. 校验活动失效后有效性展示为“已失效”，且操作栏切换为删除入口。[需求]
|
||||
5. 校验删除为永久删除，删除后列表不可见，后台数据状态与页面一致。[需求][项目画像]
|
||||
6. 校验列表展示字段、创建时间、活动状态、操作栏内容与需求一致。[需求]
|
||||
7. 校验不同状态下操作栏按钮映射正确，未开始/进行中/已结束/已失效的按钮展示不串位。[需求]
|
||||
|
||||
## 2. 活动配置与规则校验
|
||||
|
||||
1. 校验活动名称最大 50 字，超长时前端与后端均能拦截。[需求][漏测清单]
|
||||
2. 校验活动开始时间小于当前时间、结束时间小于开始时间时不可保存。[需求][边界]
|
||||
3. 校验活动奖品当前仅支持优惠券，积分奖励入口不可用或被明确拦截。[需求][技术方案]
|
||||
4. 校验每个活动仅能关联 1 张优惠券，无法多选、多绑或通过接口绕过限制。[技术方案][项目画像]
|
||||
5. 校验平台维度同一时间仅允许 1 个进行中的平台新人礼活动，新增或编辑命中并存条件时保存失败并给出明确提示。[技术方案]
|
||||
6. 校验同一店铺维度同一时间仅允许 1 个进行中的门店新人礼活动，不同店铺活动可并存。[技术方案]
|
||||
7. 校验编辑活动时，已开始活动是否只允许查看不允许修改关键字段，状态与按钮保持一致。[需求]
|
||||
|
||||
## 3. 优惠券选择与权限隔离
|
||||
|
||||
1. 校验平台端仅能选择平台可用优惠券，且仅展示投放中、未过期、领取方式为用户领取的券。[需求]
|
||||
2. 校验商家端仅能选择本店铺可用优惠券，不能看到或绑定其他店铺优惠券。[需求][项目画像]
|
||||
3. 校验优惠券选择弹窗支持按名称筛选，选择前后展示信息正确。[需求]
|
||||
4. 校验通过抓包篡改券 ID、店铺 ID 或活动归属时，后端能拦截越权绑定。[历史缺陷][项目画像]
|
||||
|
||||
## 4. 商家端差异化行为
|
||||
|
||||
1. 校验商家端列表、查询、状态展示与平台端同构，但数据仅限当前店铺可见。[需求][项目画像]
|
||||
2. 校验商家端新增活动时，跨店铺数据隔离正确，门店 A 无法操作门店 B 活动。[项目画像]
|
||||
3. 校验商家端活动失效、删除后，仅影响当前店铺，不影响平台端和其他店铺活动。[需求]
|
||||
4. 校验平台端活动数据在商家端不可见，商家端活动数据在平台端不可见。[需求][项目画像]
|
||||
5. 校验查看态页面所有字段只读，编辑态与查看态权限边界正确。[需求]
|
||||
|
||||
## 5. C 端资格检查与弹窗展示
|
||||
|
||||
1. 校验平台新人登录平台首页时，存在进行中平台新人礼活动则展示弹窗。[需求]
|
||||
2. 校验平台范围存在已支付或非交易关闭订单时，不展示平台新人礼弹窗。[需求][边界]
|
||||
3. 校验店铺新人进入门店首页时，存在进行中门店新人礼活动则展示门店弹窗。[需求]
|
||||
4. 校验当前店铺范围存在已支付或非交易关闭订单时，不展示门店新人礼弹窗。[需求][边界]
|
||||
5. 校验同时存在广告弹窗时，新人礼弹窗优先展示，关闭新人礼后再展示广告。[需求]
|
||||
6. 校验无进行中活动、活动未开始、活动已结束、活动已失效时，资格检查结果和页面展示均正确。[需求][状态流转]
|
||||
7. 校验用户历史订单均为交易关闭（未支付取消、超时未付、已退款）时，仍识别为新人并展示弹窗。[需求][产品确认]
|
||||
8. 校验未登录进入平台首页或门店首页时，不展示新人礼弹窗且不误触发领取流程。[需求][边界]
|
||||
9. 校验平台首页和门店首页展示的奖品信息与后台配置的优惠券信息一致，包括门槛、优惠金额、用券时间等。[需求]
|
||||
|
||||
## 6. 领取发放与日志落库
|
||||
|
||||
1. 校验点击“立即领取”成功后，页面提示成功，优惠券进入“我的优惠券”。[需求]
|
||||
2. 校验领取成功后，`new_gift_send_log` 写入成功记录，记录用户、活动、活动明细和状态。[技术方案]
|
||||
3. 校验同一用户重复点击“立即领取”或短时间重复调用发放接口时，只发放 1 次，日志不出现重复成功记录。[历史缺陷][项目画像]
|
||||
4. 校验领取失败时，页面提示失败原因，发放日志记录失败原因，不出现半成功状态。[技术方案][项目画像]
|
||||
5. 校验用户已领取过奖励后，再次进入首页不再弹出同一活动弹窗。[需求]
|
||||
6. 校验用户已领取平台新人礼后，若满足门店新人条件，仍可在门店首页领取门店新人礼。[需求][产品确认]
|
||||
|
||||
## 7. 异常、并发与非功能
|
||||
|
||||
1. 校验弱网、超时或接口重试场景下，资格检查接口不会错误多次弹窗或误判资格。[漏测清单][非功能]
|
||||
2. 校验领取接口超时或前端重复提交时，不会重复发券，用户可通过优惠券列表或重新进入页面查看最终结果。[漏测清单][非功能]
|
||||
3. 校验同一账号在两个终端同时领取新人礼时，最终仅 1 次成功发放。[项目画像][并发]
|
||||
4. 校验资格检查和领取接口响应时间满足技术目标 RT 1000ms，至少在常规测试数据量下不明显超时。[技术方案][非功能]
|
||||
|
||||
## 8. 产品确认口径回归
|
||||
|
||||
1. 校验平台活动与门店活动可同时存在，但平台维度仅允许 1 条进行中活动、每个店铺维度仅允许 1 条进行中活动。[产品确认]
|
||||
2. 校验历史订单均为交易关闭时仍视为新人；存在已支付或非关闭订单时不视为新人。[产品确认]
|
||||
3. 校验活动“已结束”和“已失效”同时成立时，列表优先展示“已失效”。[产品确认]
|
||||
4. 校验用户领取平台新人礼后，仍可继续领取符合条件的门店新人礼。[产品确认]
|
||||
@@ -1,33 +0,0 @@
|
||||
# 新人礼需求测试用例
|
||||
|
||||
| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
|
||||
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
|
||||
| PLT_NG_LIST_001 | 平台端-营销管理-新人有礼列表 | 验证平台端列表默认排序、分页和查询功能正确 | P1 | 功能测试 | 平台端已存在 12 条新人礼活动数据，覆盖未开始、进行中、已结束、已失效状态；测试账号具备列表权限 | 1. 登录平台端进入营销-新人有礼列表<br>2. 观察默认排序和分页条数<br>3. 输入活动名称关键字执行查询<br>4. 选择活动状态执行筛选<br>5. 点击重置 | 活动A 创建时间晚于活动B；查询关键字=新人；状态=进行中 | 1. 列表默认按创建时间倒序展示<br>2. 默认每页展示 10 条<br>3. 名称查询仅返回命中活动<br>4. 状态筛选仅返回对应状态活动<br>5. 点击重置后查询条件被清空，列表恢复默认结果 | 主流程 |
|
||||
| PLT_NG_CFG_001 | 平台端-营销管理-新人有礼配置 | 验证活动时间非法时无法保存活动 | P1 | 功能测试 | 平台运营账号已登录；存在可选平台优惠券 | 1. 点击新建活动<br>2. 输入合法活动名称<br>3. 设置开始时间早于当前时间后尝试保存<br>4. 再设置结束时间早于开始时间后尝试保存 | 活动名称=平台新人礼A；开始时间=当前时间前 1 分钟；结束时间=开始时间前 1 秒 | 1. 页面对开始时间非法给出明确提示<br>2. 页面对结束时间非法给出明确提示<br>3. 活动保存失败<br>4. 后台 `new_gift` 主表不新增活动记录 | 边界值 |
|
||||
| PLT_NG_CFG_002 | 平台端-营销管理-新人有礼配置 | 验证平台端只能绑定 1 张符合条件的平台优惠券 | P0 | 功能测试 | 平台运营账号已登录；平台下存在 3 张券，分别为投放中可领券、已过期券、非用户领取券 | 1. 点击新建活动<br>2. 打开选择优惠券弹窗<br>3. 观察券列表范围<br>4. 选择 1 张投放中可领券后尝试继续追加选择第 2 张券<br>5. 保存活动 | 券A=投放中未过期用户领取券；券B=已过期券；券C=系统发放券 | 1. 弹窗仅展示平台可用且投放中、未过期、用户领取的券<br>2. 已过期券和非用户领取券不展示或不可选<br>3. 页面仅允许单选 1 张券<br>4. 保存成功后 `new_gift_detail` 仅存在 1 条券绑定记录 | [AI修正: 技术方案限定单券绑定] |
|
||||
| PLT_NG_CFG_003 | 平台端-营销管理-新人有礼配置 | 验证积分奖励当前不支持 | P1 | 功能测试 | 平台运营账号已登录 | 1. 点击新建活动<br>2. 进入活动奖品区域<br>3. 查看送积分配置入口<br>4. 若可通过前端或抓包提交积分类型则尝试保存 | gift_type=积分；积分值=100 | 1. 页面不允许启用积分奖品，或该入口展示为暂不支持<br>2. 若前端被绕过提交积分类型，后端拦截保存并返回错误提示<br>3. 后台不生成积分类型活动记录 | [AI修正: 范围外能力拦截] |
|
||||
| PLT_NG_RULE_001 | 平台端-营销管理-新人有礼配置 | 验证平台维度同一时间仅允许一个进行中的新人礼活动 | P0 | 功能测试 | 已存在 1 条平台活动A，时间范围覆盖当前时刻且状态为进行中；平台运营账号已登录 | 1. 点击新建活动<br>2. 填写与活动A 时间重叠的新活动B信息<br>3. 选择合法平台优惠券并保存 | 活动A 时间=今天 10:00 到 明天 10:00；活动B 时间=今天 12:00 到 明天 12:00 | 1. 页面或接口提示当前已有进行中的平台新人礼活动<br>2. 活动B 保存失败<br>3. 后台不新增活动B 记录<br>4. 活动A 状态和绑定关系不受影响 | [AI修正: 按产品确认口径更新为平台维度唯一] |
|
||||
| PLT_NG_STATE_001 | 平台端-营销管理-新人有礼状态 | 验证活动失效后展示已失效并支持删除 | P1 | 功能测试 | 平台已存在 1 条未开始活动和 1 条进行中活动；平台运营账号已登录 | 1. 在列表中对活动执行失效操作<br>2. 刷新列表查看状态和操作按钮<br>3. 对已失效活动执行删除操作<br>4. 再次刷新列表 | 活动A=未开始；活动B=进行中 | 1. 失效后活动有效性展示为已失效<br>2. 失效活动的操作按钮切换为删除<br>3. 删除确认后页面提示删除成功<br>4. 列表中不再显示该活动<br>5. 后台活动记录被标记删除或按实现永久删除，不可继续被资格检查命中 | 状态流转 |
|
||||
| PLT_NG_STATE_002 | 平台端-营销管理-新人有礼状态 | 验证活动已结束且已失效时列表优先展示已失效 | P1 | 功能测试 | 平台存在 1 条活动，活动结束时间早于当前时间，且已执行失效操作；平台运营账号已登录 | 1. 进入平台端新人有礼列表<br>2. 查询该活动状态展示和操作按钮 | 活动A 结束时间=当前时间前 1 天；valid_status=已失效 | 1. 列表最终状态优先展示为已失效<br>2. 操作按钮按已失效口径展示删除，不按已结束展示<br>3. 页面状态展示与后台有效性字段一致 | [AI修正: 按产品确认口径补充状态优先级] |
|
||||
| MCH_NG_SCOPE_001 | 商家端-营销管理-新人有礼配置 | 验证商家端只能选择本店铺优惠券 | P0 | 功能测试 | 商家A 账号已登录；商家A 券A 为可领券；商家B 券B 为可领券 | 1. 商家A 进入新建活动页面<br>2. 打开优惠券选择弹窗<br>3. 搜索本店券A 和外店券B<br>4. 选择券A 保存活动 | 商家A ID=1001；商家B ID=1002；券A 属于商家A；券B 属于商家B | 1. 列表仅展示商家A 可用券<br>2. 搜索券B 无结果或不可选<br>3. 保存成功后活动绑定的券归属为商家A<br>4. 后台不存在跨店绑定关系 | [AI修正: 覆盖数据隔离与越权风险] |
|
||||
| MCH_NG_SCOPE_002 | 商家端-营销管理-新人有礼配置 | 验证篡改券 ID 无法越权绑定其他店铺优惠券 | P0 | 安全性测试 | 商家A 账号已登录；抓包工具可修改请求；商家B 存在 1 张有效券 | 1. 商家A 正常进入新建活动页面并选择商家A 自有券<br>2. 提交前抓包将券 ID 替换为商家B 券 ID<br>3. 提交保存请求 | 提交参数原券 ID=COUPON_A_01；篡改后券 ID=COUPON_B_01 | 1. 后端拦截越权绑定请求并返回错误提示<br>2. 页面保存失败<br>3. 后台不生成跨店活动与券绑定关系<br>4. 审计日志记录异常请求或失败原因 | [AI修正: 对应越权与价格篡改类历史风险] |
|
||||
| MCH_NG_RULE_001 | 商家端-营销管理-新人有礼配置 | 验证同一店铺仅允许一个进行中的门店新人礼活动但不同店铺可并存 | P0 | 功能测试 | 商家A 已存在 1 条进行中的门店活动A；商家B 无进行中活动；商家A、商家B 账号均可登录 | 1. 商家A 新建与活动A 时间重叠的门店活动A2并保存<br>2. 商家B 新建与活动A 同时段重叠的门店活动B并保存<br>3. 查询两家店铺活动列表 | 商家A ID=1001；商家B ID=1002；活动A2 与活动A 时间重叠；活动B 与活动A 时间重叠 | 1. 商家A 保存活动A2失败，并提示当前店铺已有进行中的新人礼活动<br>2. 商家B 保存活动B成功<br>3. 后台显示门店活动限制按店铺维度生效，不会因商家A 活动阻塞商家B 配置 | [AI修正: 按产品确认口径补充店铺维度唯一] |
|
||||
| C_NG_POP_001 | 用户端-首页-新人礼弹窗 | 验证平台新人登录平台首页时展示新人礼弹窗 | P0 | 冒烟测试 | 平台存在 1 条进行中的平台新人礼活动；用户U1 已注册登录且平台维度无下单记录；用户未领取过该活动 | 1. 用户U1 登录平台首页<br>2. 观察首页首屏弹窗 | 用户U1；平台活动=进行中；平台下单记录=0 | 1. 首页展示新人礼弹窗<br>2. 弹窗内容展示活动奖励信息和立即领取按钮<br>3. 后台资格检查接口返回命中活动和可领取状态 | 主流程 |
|
||||
| C_NG_POP_002 | 用户端-首页-新人礼弹窗 | 验证非平台新人登录平台首页时不展示新人礼弹窗 | P1 | 功能测试 | 平台存在 1 条进行中的平台新人礼活动；用户U2 已注册登录且平台维度存在已下单记录 | 1. 用户U2 登录平台首页<br>2. 观察首页弹窗和资格检查结果 | 用户U2；平台已支付订单数=1 | 1. 首页不展示新人礼弹窗<br>2. 资格检查接口返回不满足新人条件<br>3. 页面不出现立即领取入口 | 边界值 |
|
||||
| C_NG_POP_003 | 用户端-门店首页-新人礼弹窗 | 验证平台老用户但门店新用户进入门店首页时展示门店新人礼弹窗 | P0 | 功能测试 | 商家A 存在 1 条进行中的门店新人礼活动；用户U3 平台维度已有下单记录，但在商家A 维度无下单记录；用户未领取过商家A 活动 | 1. 用户U3 进入商家A 门店首页<br>2. 观察首页弹窗<br>3. 查询资格检查结果 | 用户U3；平台订单数=1；商家A 订单数=0 | 1. 门店首页展示商家A 新人礼弹窗<br>2. 资格检查接口按门店维度返回可领取<br>3. 弹窗奖励信息与商家A 活动配置一致 | [AI修正: 覆盖平台新人和店铺新人差异口径] |
|
||||
| C_NG_POP_004 | 用户端-首页-弹窗优先级 | 验证存在广告弹窗时新人礼弹窗优先展示 | P1 | 功能测试 | 平台存在 1 条进行中的新人礼活动；首页同时配置普通广告弹窗；用户U1 满足平台新人资格 | 1. 用户U1 登录平台首页<br>2. 观察首个弹窗<br>3. 关闭新人礼弹窗后继续观察 | 用户U1；广告弹窗=已配置 | 1. 首个弹窗为新人礼弹窗<br>2. 关闭新人礼弹窗后再展示广告弹窗<br>3. 整个过程中弹窗顺序与需求一致 | 交互优先级 |
|
||||
| C_NG_POP_005 | 用户端-首页-新人礼弹窗 | 验证历史订单均为交易关闭时仍识别为平台新人 | P0 | 功能测试 | 平台存在 1 条进行中的平台新人礼活动；用户U6 历史仅有未支付取消单、超时未付单或已退款订单，且无其他非关闭订单 | 1. 用户U6 登录平台首页<br>2. 观察首页弹窗<br>3. 查询资格检查结果 | 用户U6 历史订单状态=交易关闭、已退款、超时未付 | 1. 首页展示平台新人礼弹窗<br>2. 资格检查接口返回满足平台新人条件<br>3. 页面不因历史关闭单或已退款单而拦截新人资格 | [AI修正: 按产品确认口径补充交易关闭单仍算新人] |
|
||||
| C_NG_SEND_001 | 用户端-首页-新人礼领取 | 验证点击立即领取成功后优惠券入账并写发放日志 | P0 | 冒烟测试 | 用户U1 满足平台新人资格；平台存在进行中活动且绑定有效券；用户未领取过该活动 | 1. 用户U1 在新人礼弹窗点击立即领取<br>2. 观察页面提示<br>3. 进入我的优惠券查询奖励<br>4. 查询发放日志 | 用户U1；活动ID=NG1001；券ID=PC1001 | 1. 页面提示领取成功<br>2. 我的优惠券列表新增对应优惠券<br>3. `new_gift_send_log` 新增 1 条成功记录，包含用户、活动、活动明细和发送状态<br>4. 该用户再次进入首页时不再展示同一活动弹窗 | 主流程 |
|
||||
| C_NG_SEND_002 | 用户端-首页-新人礼领取 | 验证同一用户重复点击立即领取时只发放一次 | P0 | 回归测试 | 用户U1 满足新人资格；平台存在进行中活动且绑定有效券；抓包或前端可模拟快速重复点击 | 1. 用户U1 打开新人礼弹窗<br>2. 在 1 秒内连续点击 3 次立即领取<br>3. 查询优惠券列表和发放日志 | 用户U1；活动ID=NG1001；重复点击次数=3 | 1. 页面最多显示 1 次领取成功提示<br>2. 用户仅新增 1 张优惠券<br>3. `new_gift_send_log` 仅有 1 条成功记录，其余请求被幂等拦截或返回已领取<br>4. 不出现重复发券 | [AI修正: 对应重复提交和重复支付类历史风险] |
|
||||
| C_NG_SEND_003 | 用户端-首页-新人礼领取 | 验证领取接口超时重试时不会重复发券 | P1 | 回归测试 | 用户U1 满足新人资格；模拟领取接口首个请求响应超时但后端已处理成功 | 1. 用户U1 点击立即领取<br>2. 将首个请求模拟为前端超时<br>3. 用户再次点击立即领取或页面自动重试<br>4. 查询优惠券列表和发放日志 | 首次请求后端处理成功；前端超时 5 秒 | 1. 页面提示处理中或可稍后刷新查看结果<br>2. 最终用户仅获得 1 张优惠券<br>3. 发放日志中仅 1 条成功记录，不存在多条成功发放<br>4. 页面最终状态与后台结果一致 | 非功能 |
|
||||
| C_NG_SEND_004 | 用户端-首页-新人礼领取 | 验证发券失败时记录失败原因且不出现半成功状态 | P1 | 功能测试 | 用户U4 满足新人资格；将发券接口模拟为失败 | 1. 用户U4 点击立即领取<br>2. 观察页面提示<br>3. 查询我的优惠券列表<br>4. 查询发放日志 | 券中心返回=库存不足或券失效 | 1. 页面提示领取失败及失败原因<br>2. 我的优惠券列表不新增该券<br>3. `new_gift_send_log` 记录失败状态和失败原因<br>4. 用户状态不被误标记为已领取 | [AI修正: 覆盖部分成功和异常记录风险] |
|
||||
| C_NG_SEND_005 | 用户端-首页-新人礼领取 | 验证同一账号双端并发领取时最终仅一次成功 | P1 | 功能测试 | 用户U5 满足新人资格；用户在手机端和 H5 端同时登录；平台存在进行中活动 | 1. 手机端和 H5 端同时打开新人礼弹窗<br>2. 两端几乎同时点击立即领取<br>3. 查询两端提示、优惠券列表和发放日志 | 用户U5；双端并发间隔小于 200ms | 1. 最终仅 1 次领取成功<br>2. 另一端返回已领取、处理中或重复请求提示<br>3. 用户优惠券列表仅新增 1 张券<br>4. 发放日志仅保留 1 条成功记录 | 并发 |
|
||||
| C_NG_SEND_006 | 用户端-门店首页-新人礼领取 | 验证用户领取平台新人礼后仍可继续领取门店新人礼 | P0 | 功能测试 | 用户U7 已成功领取平台新人礼；商家A 存在进行中的门店新人礼活动；用户U7 在商家A 维度无非关闭订单且未领取过门店活动 | 1. 用户U7 登录平台首页并确认已领取平台新人礼<br>2. 用户U7 进入商家A 门店首页<br>3. 观察门店弹窗并点击立即领取<br>4. 查询门店发放日志和优惠券列表 | 用户U7；平台活动ID=PLT1001；门店活动ID=SHOP1001 | 1. 门店首页仍展示门店新人礼弹窗<br>2. 用户可成功领取门店优惠券<br>3. 优惠券列表中同时存在平台新人礼券和门店新人礼券<br>4. 门店活动发放日志新增成功记录，不因已领取平台礼而被拦截 | [AI修正: 按产品确认口径补充平台礼与门店礼可并存] |
|
||||
| C_NG_CHECK_001 | 用户端-首页-资格检查 | 验证无进行中活动或活动失效时不展示新人礼弹窗 | P1 | 功能测试 | 平台存在未开始、已结束或已失效活动，但不存在进行中活动；用户U1 满足新人资格 | 1. 用户U1 登录平台首页<br>2. 观察首页弹窗<br>3. 查询资格检查接口返回 | 活动状态分别为未开始、已结束、已失效 | 1. 首页不展示新人礼弹窗<br>2. 资格检查接口返回无可领取活动<br>3. 页面不出现错误提示或异常闪现弹窗 | 状态流转 |
|
||||
| API_NG_PERF_001 | 用户端-资格检查-接口性能 | 验证资格检查接口在常规数据量下满足 RT 基线 | P2 | 性能测试 | 存在 100 条历史发放记录和 10 条活动数据；性能环境可统计接口耗时 | 1. 触发用户进入平台首页调用资格检查接口<br>2. 连续执行 30 次<br>3. 统计平均 RT 和 P95 | 接口=`/ua/newGift/check`；样本量=30 | 1. 常规场景下接口平均 RT 和 P95 满足 1000ms 基线或接近目标<br>2. 页面无明显卡顿或超时提示<br>3. 若超基线，应能定位是活动查询、资格判定还是日志判断链路耗时 | [AI修正: 技术方案给出 RT 1000ms] |
|
||||
| C_NG_RULE_001 | 用户端-资格判定-新人口径 | 验证存在已支付订单时不再识别为新人 | P1 | 功能测试 | 用户U8 存在 1 笔平台已支付订单；平台存在进行中活动 | 1. 用户U8 登录平台首页<br>2. 观察是否弹出新人礼<br>3. 查询资格检查返回 | 用户U8 历史订单状态=已支付 | 1. 首页不展示新人礼弹窗<br>2. 资格检查接口返回不满足新人条件<br>3. 页面展示与产品确认口径一致，不因已支付历史订单继续认定为新人 | [AI修正: 按产品确认口径更新新人判定] |
|
||||
| C_NG_POP_006 | 用户端-首页-新人礼弹窗 | 验证未登录进入首页时不展示新人礼弹窗 | P0 | 功能测试 | 平台或门店存在进行中的新人礼活动；用户未登录 | 1. 未登录直接进入平台首页<br>2. 未登录直接进入门店首页<br>3. 观察页面弹窗与网络请求 | 访问端=H5/小程序；登录态=未登录 | 1. 平台首页和门店首页均不展示新人礼弹窗<br>2. 页面不进入领取流程<br>3. 若触发资格检查请求，应返回未登录拦截而非可领取结果 | [AI修正: 取自团队现有功能用例] |
|
||||
| C_NG_POP_007 | 用户端-首页-新人礼展示 | 验证首页展示的奖品信息与后台配置一致 | P0 | 功能测试 | 平台和商家端各存在 1 条进行中的新人礼活动，且分别绑定不同门槛和优惠内容的优惠券；用户满足资格 | 1. 平台新人登录平台首页查看弹窗奖品信息<br>2. 店铺新人进入门店首页查看弹窗奖品信息<br>3. 对比后台券配置 | 平台券=满100减20, 用券时间 2026-05-01 至 2026-05-31；店铺券=8折券, 上限 30 元 | 1. 平台首页弹窗展示的平台券门槛、优惠金额或折扣、用券时间与后台配置一致<br>2. 门店首页弹窗展示的商家券信息与商家端配置一致<br>3. 不出现平台券和商家券信息串位 | [AI修正: 取自团队现有功能用例] |
|
||||
| DATA_NG_SCOPE_001 | 平台端-商家端-数据隔离 | 验证平台端与商家端新人礼活动数据不互通 | P0 | 功能测试 | 平台端已配置 1 条平台新人礼活动；商家A 已配置 1 条门店新人礼活动；测试账号分别具备平台端和商家端权限 | 1. 在平台端查看新人礼活动列表<br>2. 在商家A 端查看新人礼活动列表<br>3. 对比两端列表数据 | 平台活动ID=PLT1001；商家活动ID=SHOP1001 | 1. 平台端仅展示平台活动数据，不展示商家活动<br>2. 商家端仅展示当前店铺活动数据，不展示平台活动<br>3. 两端数据查询、查看、编辑入口相互隔离 | [AI修正: 取自团队现有功能用例] |
|
||||
| VIEW_NG_READONLY_001 | 平台端-营销管理-新人有礼查看 | 验证查看态页面所有字段只读不可编辑 | P1 | 功能测试 | 平台已存在 1 条新人礼活动；平台运营账号已登录 | 1. 在列表中点击查看<br>2. 观察活动名称、活动时间、活动奖品等字段状态<br>3. 尝试修改字段或提交 | 活动ID=PLT1001 | 1. 查看页所有字段均为只读态<br>2. 页面不提供可提交修改的入口<br>3. 用户无法通过查看态改写活动配置 | [AI修正: 取自团队现有功能用例] |
|
||||
| PLT_NG_LIST_002 | 平台端-营销管理-新人有礼列表 | 验证列表展示字段和操作栏状态映射正确 | P1 | 功能测试 | 平台端存在未开始、进行中、已结束、已失效四类活动；平台运营账号已登录 | 1. 进入新人有礼列表<br>2. 逐条检查活动名称、活动时间、活动状态、创建时间、操作栏<br>3. 对比不同状态下的操作按钮 | 活动A=未开始；活动B=进行中；活动C=已结束；活动D=已失效 | 1. 列表展示字段完整且内容正确<br>2. 未开始活动展示编辑、失效<br>3. 进行中活动展示查看、失效或按最终规则允许的编辑能力<br>4. 已结束和已失效活动操作栏按需求展示删除或受限操作 | [AI修正: 取自团队现有功能用例] |
|
||||
Binary file not shown.
@@ -1,61 +0,0 @@
|
||||
# 新人礼需求
|
||||
|
||||
> 文档角色：需求文档
|
||||
> 原始来源：`source_docs/requirements_raw/新人礼需求.docx`
|
||||
|
||||
基线-新人礼
|
||||
| 版本号 | 变更内容 | 变更人 | 变更时间 |
|
||||
| 0.0.1 | 文档创建 | 张昊 | 2026-02-28 |
|
||||
一、业务背景
|
||||
基于问界需求清单 新人礼需求
|
||||
二、业务目标
|
||||
通过发布新人礼活动，吸引新用户注册使用～平台端&商家端支持发布新人礼活动，支持配置优惠券奖品，c端新用户注册展示新人礼内容
|
||||
三、产品设计
|
||||
1. 平台端-营销-新人有礼
|
||||
1.1 新人有礼列表
|
||||
列表数据说明
|
||||
数据权限：有此菜单列表权限的用户可看数据
|
||||
排序规则：按数据新增时间倒序排列
|
||||
分页规则：默认10行每页，可自主选择每页显示的条数（10/20/30/50）
|
||||
数据来源：如下表
|
||||
| 数据字段 | 数据来源 |
|
||||
| 活动名称 | 来源【新增/编辑】表单同名字段 |
|
||||
| 活动时间 | 来源【新增/编辑】表单“活动时间“数据 |
|
||||
| 活动状态 | 见下方状态逻辑说明 |
|
||||
| 活动有效性 | 展示有效/已失效，支持 失效活动，失效后展示 已失效，失效后 操作栏展示删除操作 |
|
||||
| 活动奖品 | 展示活动配置的奖品，当前活动奖品仅支持优惠券 |
|
||||
| 创建时间 | 活动创建时间 |
|
||||
状态逻辑说明
|
||||
| 状态名称 | 状态变更条件 | 可操作按钮 |
|
||||
| 未开始 | 活动时间开始时间>当前时间 | 编辑，失效 |
|
||||
| 进行中 | 活动时间开始时间<=当前时间 | 查看，失效 |
|
||||
| 已结束 | 活动时间结束时间<当前时间 | 删除 |
|
||||
查询条件说明
|
||||
| 查询条件 | 查询逻辑 |
|
||||
| 活动名称 | 模糊查询，查询列表字段“活动名称” |
|
||||
| 活动状态 | 精准查询，单选，选项数据：未开始、进行中、已结束、已失效，默认空 |
|
||||
功能按钮说明
|
||||
| 按钮名称 | 触发后逻辑说明 | |
|
||||
| 新建 | 在当前窗口打开“新建新人礼”弹窗 | |
|
||||
| 查询 | 1、已选查询条件情况下，列表显示符合条件的数据 2、查询条件无匹配数据时，列表显示空，提示”暂无数据“ | |
|
||||
| 重置 | 清空查询条件 | |
|
||||
| 编辑 | 打开编辑表单弹窗 | |
|
||||
| 查看 | 打开查看表单弹窗 | |
|
||||
| 失效 | 打开失效操作弹窗，失效操作后，状态变更为已失效 | |
|
||||
| 删除 | 打开删除操作弹窗，删除操作后，在列表删除活动（永久删除）；取消后，关闭删除弹窗。 | |
|
||||
1.2 新增/编辑
|
||||
页面字段说明
|
||||
| 字段名称 | 逻辑规则 | 是否必填 | 是否可编辑 | 原型界面、逻辑补充 |
|
||||
| 活动名称 | 文本输入，最多50个字 | 是 | 是 | |
|
||||
| 活动时间 | 开始时间-结束时间，年月日时分秒 | 是 | 是 | 控制活动的有效时段，可选择的时间大于等于当前时间，结束时间大于开始时间 |
|
||||
| 活动奖品 | 多选 | 是 | 是 | |
|
||||
| | 送优惠券 优惠券： 勾选后展示选择优惠券，只能选择1张优惠券，选择后展示选中优惠券信息表格 选择优惠券弹窗： 通用优惠券选择弹窗，单选 平台端展示平台可用优惠券列表， 商家端展示商家可用的优惠券列表， 优惠券列表数据展示规则：投放，未过期且为 用户领取 的优惠券，支持根据名称筛选 | 是 | 是 | 优惠券列表：选择前 优惠券列表：选择后 选择优惠券弹窗： |
|
||||
| | 送积分 可输入1-999999的整数，配置生效后调用发积分接口发放积分 | 是 | 否 | 暂不支持 |
|
||||
2. 商家端-营销-新人有礼
|
||||
功能同平台端，仅优惠券选择时，仅可选择该店铺下的优惠券
|
||||
3. C端
|
||||
3.1 首页
|
||||
| 平台首页-新人礼领取提示 奖励领取后，可在个人中心优惠券查看 | 店铺首页-新人礼领取提示 |
|
||||
| 功能点 | 功能说明 |
|
||||
| 弹窗逻辑 | 1）用户未在任意门店下过单，即视为新用户，登录后进入首页，弹窗提示用户领取新人礼奖励 2）用户未在该门店下过单，即视为门店新用户，登录后进入门店首页，弹窗提示用户领取新人礼奖励时机3）如果平台或店铺设置了弹窗广告，则新人礼弹窗在弹窗广告之前展示，关闭新人礼弹窗后，展示弹窗广告内容 |
|
||||
| 优惠券 | 用户点击新人礼弹窗立即领取按钮，如果领取成功，奖励进入我的-优惠券列表，并提示用户领取成功 |
|
||||
@@ -1,66 +0,0 @@
|
||||
# 新人礼技术方案
|
||||
|
||||
> 文档角色：技术方案
|
||||
> 原始来源：`source_docs/technical_solutions/新人礼技术方案.docx`
|
||||
|
||||
基线改造---新人礼技术方案&需求概述
|
||||
| 版本号 | 变更内容 | 变更人 | 变更时间 |
|
||||
| 1.0 | 建档 | 陶震 | 2026-2-21 |
|
||||
1 背景
|
||||
1.1 需求背景
|
||||
新增，针对于新注册，未下单用户发放专属优惠券的场景（暂不支持下单后退款场景）
|
||||
1.2 业务现况
|
||||
1.3. 业务系统现况
|
||||
1.4 名词说明
|
||||
| 名称 | 描述 |
|
||||
| 新人(平台新人，店铺新人) | 平台新人：未在该平台下过单的用户，即shop_custormer中无任何数据的user 店铺新人：未在该店铺下过单的用户，即shop——customer中无该店铺该user数据的用户 |
|
||||
1.7 涉及人员
|
||||
| 角色名称 | 使用内容 |
|
||||
| 用户 | 消费者 |
|
||||
| 运营 | 商城日常使用维护以及操作者。 |
|
||||
2 目标
|
||||
本期实现目标说明：
|
||||
2.1、技术目标
|
||||
| 技术指标 | 指标值 | 备注 |
|
||||
| 用户响应RT | 1000ms | |
|
||||
| 用户体量 | | |
|
||||
| 并发数 | | |
|
||||
| 开发语言 | | |
|
||||
| 网络要求 | | |
|
||||
3 整体概述
|
||||
3.1 需求概述
|
||||
同一时间仅允许一个新人礼活动(避免同一时间多个活动发放业务过重)。关联优惠券仅支持关联一张
|
||||
C端弹窗，若存在进行中的新人礼活动且用户未领取过，则进行弹窗
|
||||
3.2 业务架构图（一图概览）
|
||||
3.3 业务模块列表
|
||||
3.4 第三方服务列表(可选)
|
||||
| 服务厂商 | 类型（接口/设备） | 接口地址 | 备注 | 状态 |
|
||||
3.5 技术架构
|
||||
3.5.1 前端设计
|
||||
3.5.2 后端设计
|
||||
3.6 领域模型设计
|
||||
新人礼主表
|
||||
| SQLCREATE TABLE `new_gift` ( `new_gift_id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `shop_id` bigint NOT NULL COMMENT '关联店铺 平台为0', `activity_name` varchar(255) COLLATE utf8mb4_general_ci NOT NULL COMMENT '活动名称', `activity_start_time` datetime NOT NULL COMMENT '活动开始时间', `activity_end_time` datetime NOT NULL COMMENT '活动结束时间', `gift_type` int NOT NULL COMMENT '礼物类型 0优惠券 其他待拓展', `activity_status` int NOT NULL COMMENT '活动状态0未开始，1进行中，2已结束', `valid_status` int NOT NULL DEFAULT '0' COMMENT '有效性 0有效 1已失效', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', `deleted` int NOT NULL DEFAULT '0' COMMENT '是否已删除 0否1是', PRIMARY KEY (`new_gift_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='新人礼主表'; |
|
||||
新人礼关联礼物表
|
||||
| SQLCREATE TABLE `new_gift_detail` ( `new_gift_detail_id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `new_gift_id` bigint NOT NULL COMMENT '新人礼主键', `gift_type` int NOT NULL COMMENT '礼物类型 0优惠券 其他待拓展', `gift_biz_id` bigint NOT NULL COMMENT '礼物主键Id', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`new_gift_detail_id`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='新人礼 子表，存储主表与礼物关联关系'; |
|
||||
新人礼发放记录表
|
||||
| SQLCREATE TABLE `new_gift_send_log` ( `new_gift_log_id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `user_id` bigint NOT NULL COMMENT '用户ID', `send_status` int NOT NULL COMMENT '发放状态 0成功 1失败', `fail_reason` json DEFAULT NULL COMMENT '失败原因', `new_gift_id` bigint NOT NULL COMMENT '新人礼主键', `new_gift_detail_id` bigint NOT NULL COMMENT '礼物详情主键', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`new_gift_log_id`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='新人礼发放记录表'; |
|
||||
3.7 数据模型设计
|
||||
详见领域模型
|
||||
3.8 依赖项
|
||||
| 依赖项 | 作用 | 预计提供时间 | 状态 | 责任人 | 交付物 |
|
||||
4 场景（user story）与流程图（How）
|
||||
4.1 新增活动
|
||||
4.1.1 业务流程图
|
||||
4.1.2 时序图
|
||||
4.1.3 接口依赖
|
||||
无
|
||||
4.1.4 接口设计
|
||||
| API | 状态 | 说明 |
|
||||
| /mp/newGift/save | 未开发 | 新增新人礼活动 |
|
||||
| /mp/newGift/update | 未开发 | 修改新人礼活动 |
|
||||
| /mp/newGift/detail | 未开发 | 查看新人礼详情 |
|
||||
| /mp/newGift/delete | 未开发 | 删除新人礼活动 |
|
||||
| /mp/newGift/page | 未开发 | 新人礼活动分页查询 |
|
||||
| /ua/newGift/check | 未开发 | 检测用户是否符合进行中的平台/店铺中的新人礼活动。 |
|
||||
| /ua/newGift/send | 未开发 | 为用户发放对应新人礼绑定的券 |
|
||||
@@ -1,14 +0,0 @@
|
||||
{
|
||||
"base_name": "新人礼需求",
|
||||
"version": "v9",
|
||||
"snapshot_type": "full_pipeline",
|
||||
"summary": [
|
||||
"manifest",
|
||||
"analysis",
|
||||
"relation_report",
|
||||
"test_points",
|
||||
"test_cases_markdown",
|
||||
"excel",
|
||||
"normalized_inputs"
|
||||
]
|
||||
}
|
||||
@@ -1,44 +0,0 @@
|
||||
{
|
||||
"requirement": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/source_docs/requirements_raw/新人礼需求.docx",
|
||||
"requirement_source_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/source_docs/requirements_raw/新人礼需求.docx",
|
||||
"requirement_input_type": "docx",
|
||||
"base_name": "新人礼需求",
|
||||
"normalized_requirement_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/normalized_inputs/新人礼需求/requirement.md",
|
||||
"technical_solution_files": [
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/source_docs/technical_solutions/新人礼技术方案.docx"
|
||||
],
|
||||
"normalized_technical_solution_files": [
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/normalized_inputs/新人礼需求/technical_solution_01.md"
|
||||
],
|
||||
"analysis_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/analysis/新人礼需求_分析.md",
|
||||
"relation_report_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/analysis/新人礼需求_关联与冲突.md",
|
||||
"test_points_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/test_points/新人礼需求_测试点.md",
|
||||
"test_cases_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/test_cases/新人礼需求_测试用例.md",
|
||||
"excel_output_dir": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/excel_reports",
|
||||
"project_profile_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/00_project/project_profile.md",
|
||||
"knowledge_base_files": [
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/01_standards/terminology.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/01_standards/test_case_template.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/01_standards/definition_of_done.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/01_standards/review_checklist.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/02_history/common_missed_scenes.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/02_history/historical_defects.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/02_history/marketing_rules.md",
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/03_best_practices/payment_flow_cases.md"
|
||||
],
|
||||
"effective_terminology_files": [
|
||||
"/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/knowledge_base/01_standards/terminology.md"
|
||||
],
|
||||
"optional_terminology_files": [],
|
||||
"related_requirements": [],
|
||||
"conflict_candidates_count": 0,
|
||||
"current_excel_file": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/excel_reports/新人礼需求_测试用例.xlsx",
|
||||
"versioning_scheme": {
|
||||
"current_files": "固定文件名，始终表示当前最新版",
|
||||
"snapshot_rule": "仅在 export 成功且产物内容发生变化时递增版本",
|
||||
"snapshot_dir_pattern": "output/versions/{BASE_NAME}/vN/"
|
||||
},
|
||||
"latest_snapshot_version": "v8",
|
||||
"latest_snapshot_dir": "/Users/fangyuehui/Desktop/codeAll/qa-team/qa-automation-hub/output/versions/新人礼需求/v8",
|
||||
"latest_snapshot_type": "full_pipeline"
|
||||
}
|
||||
@@ -1,16 +0,0 @@
|
||||
# 新人礼需求 关联需求与冲突检查
|
||||
|
||||
## 目标需求
|
||||
- `source_docs/requirements_raw/新人礼需求.docx`
|
||||
|
||||
## 项目画像
|
||||
- `knowledge_base/00_project/project_profile.md`
|
||||
|
||||
## 关联技术方案
|
||||
- `source_docs/technical_solutions/新人礼技术方案.docx`
|
||||
|
||||
## 关联需求识别
|
||||
- 未识别到相似度达到阈值的历史需求文档。
|
||||
|
||||
## 潜在冲突与修改建议
|
||||
- 暂未识别到明显冲突条目。建议在需求评审时继续人工确认。
|
||||
@@ -1,111 +0,0 @@
|
||||
# 新人礼需求分析
|
||||
|
||||
## 背景与目标
|
||||
|
||||
本期需求围绕“新人礼”活动能力建设，目标是在平台端和商家端支持配置新人礼活动，并在 C 端针对符合新人条件的用户展示领取入口与发放优惠券奖励，提升新注册用户的首单转化。
|
||||
|
||||
技术方案补充了两个关键限制：
|
||||
|
||||
- 同一时间仅允许存在 1 个进行中的新人礼活动。
|
||||
- 每个新人礼活动仅允许绑定 1 张优惠券，发放结果需落新人礼发放记录表。
|
||||
|
||||
## 范围与边界
|
||||
|
||||
### 范围内
|
||||
|
||||
- 平台端“营销-新人有礼”列表、查询、新建、编辑、查看、失效、删除。
|
||||
- 商家端“营销-新人有礼”同构能力。
|
||||
- 新人礼活动配置字段校验：活动名称、活动时间、活动奖品、优惠券选择。
|
||||
- 优惠券选择范围控制：平台端仅选平台券，商家端仅选本店铺优惠券。
|
||||
- C 端首页和门店首页的新人礼弹窗检查与领取。
|
||||
- 发放成功后的优惠券入账和发放记录落库。
|
||||
- `ua/newGift/check` 与 `ua/newGift/send` 对应的资格校验和发放行为。
|
||||
|
||||
### 范围外
|
||||
|
||||
- 积分类型新人礼，需求和技术方案均明确“暂不支持”。
|
||||
- 下单后退款再重新认定为新人场景，技术方案明确“暂不支持下单后退款场景”。
|
||||
- 多奖品、多券组合、多人拼抢同一活动池等扩展玩法。
|
||||
|
||||
## 用户角色与前置条件
|
||||
|
||||
- 平台运营：维护平台维度新人礼活动。
|
||||
- 商家运营：维护店铺维度新人礼活动。
|
||||
- C 端用户：登录后触发首页或门店首页新人礼检查与领取。
|
||||
- 后端系统：负责活动状态判断、资格校验、优惠券发放、发送日志写入。
|
||||
|
||||
前置条件：
|
||||
|
||||
- 已存在投放中、未过期、领取方式为“用户领取”的优惠券。
|
||||
- 用户已登录，且能获取平台维度与店铺维度的历史下单信息。
|
||||
- 发券接口可用，优惠券中心返回的券状态准确。
|
||||
|
||||
## 关键业务规则
|
||||
|
||||
1. 平台端和商家端都可以配置新人礼活动，但优惠券范围必须与端侧归属一致。
|
||||
2. 活动名称最多 50 个字。
|
||||
3. 活动开始时间必须大于等于当前时间，结束时间必须大于开始时间。
|
||||
4. 活动奖品当前仅支持优惠券，且每个活动仅能关联 1 张优惠券。
|
||||
5. 平台维度同一时间仅允许 1 个进行中的平台新人礼活动；店铺维度同一时间每个店铺仅允许 1 个进行中的门店新人礼活动。
|
||||
6. 新人判定按订单提交结果范围判断：平台新人礼查询平台范围订单，店铺新人礼查询当前店铺订单；若用户从未提交过订单，或历史订单最终状态均为交易关闭（包括未支付取消、超时未付、已退款订单等），仍视为新人。
|
||||
7. 用户登录首页时，若存在进行中的新人礼活动且用户未领取过，则展示新人礼弹窗。
|
||||
8. 门店首页只对门店新人展示门店新人礼弹窗。
|
||||
9. 若同时存在弹窗广告，新人礼弹窗必须先于广告弹窗展示。
|
||||
10. 用户点击立即领取成功后，奖励进入“我的优惠券”，同时写入新人礼发放记录。
|
||||
11. 活动“已结束”和“已失效”并存时，页面优先展示“已失效”。
|
||||
12. 活动失效后状态展示为“已失效”，并支持后续删除。
|
||||
13. 用户领取平台新人礼后，若仍满足门店新人条件，允许继续领取门店新人礼。
|
||||
|
||||
## 主流程描述
|
||||
|
||||
1. 运营在平台端或商家端进入“营销-新人有礼”列表页。
|
||||
2. 运营新建活动，填写活动名称、活动时间并选择 1 张符合条件的优惠券。
|
||||
3. 系统校验时间、优惠券范围、优惠券状态和活动并存规则，保存活动。
|
||||
4. 活动进入“未开始”或“进行中”状态，列表页按状态展示可操作按钮。
|
||||
5. C 端用户登录平台首页或门店首页时，调用资格检查接口。
|
||||
6. 若存在进行中的匹配活动且用户符合新人条件且未领取过，则展示新人礼弹窗。
|
||||
7. 用户点击“立即领取”，系统发放优惠券并记录发放日志。
|
||||
8. 发放成功后，用户可在个人中心优惠券列表查看奖励。
|
||||
|
||||
## 跨需求关联与冲突修订建议
|
||||
|
||||
- 当前未识别到需要纳入本次评审的关联需求，也未发现需要基于历史需求执行的规则冲突修订。
|
||||
- 当前无需对历史需求做口径覆盖修订，但仍需重点防御营销类公共风险：
|
||||
- 重复点击导致重复发放。
|
||||
- 前端传参篡改导致越权选券或跨店铺发券。
|
||||
- 状态变更与页面展示不一致。
|
||||
|
||||
## 技术方案补充约束
|
||||
|
||||
- `ua/newGift/check` 负责资格检查，应重点验证平台维度和店铺维度“新人”判定口径。
|
||||
- `ua/newGift/send` 负责发券，应重点验证幂等、防重复领取、失败原因记录和成功落库。
|
||||
- 数据模型拆分为主表、礼物关联表、发放记录表，说明测试不能只看页面成功提示，还要覆盖：
|
||||
- `new_gift` 主表活动状态和有效性字段。
|
||||
- `new_gift_detail` 活动与券的绑定关系。
|
||||
- `new_gift_send_log` 发放成功或失败记录。
|
||||
- 技术目标给出用户响应 RT 1000ms，应至少对资格检查和领取动作补充性能基线关注。
|
||||
|
||||
## 产品确认口径
|
||||
|
||||
- 活动并存范围：平台维度同一时间仅允许 1 条进行中的平台活动；店铺维度同一时间每个店铺仅允许 1 条进行中的门店活动。
|
||||
- 新人判定口径：若用户从未提交过订单，或历史订单最终状态均为交易关闭（包括未支付取消、超时未付、已退款订单），仍视为新人。
|
||||
- 状态展示优先级：活动“已结束”和“已失效”并存时，优先展示“已失效”。
|
||||
- 平台礼与门店礼关系：用户已领取平台新人礼后，只要满足门店新人条件，仍允许领取门店新人礼。
|
||||
|
||||
## 项目差异化测试约束
|
||||
|
||||
- 平台端、商家端、C 端是三套角色链路，必须覆盖角色隔离和数据隔离。
|
||||
- 这是典型营销发券能力，需重点覆盖越权选券、重复发放、状态错发和资损场景。
|
||||
- 预期结果必须同时覆盖 UI 反馈和后台状态变化，特别是活动状态、券领取结果、发放日志。
|
||||
|
||||
## 风险点与确认结果
|
||||
|
||||
- 风险点：重复点击“立即领取”或接口重试导致同一用户重复发放优惠券。
|
||||
- 风险点：商家端错误选择了其他店铺的优惠券，导致跨店资损或越权发券。
|
||||
- 风险点：活动失效、已结束、已删除三个状态口径不清，可能导致列表按钮和实际行为不一致。
|
||||
- 风险点：平台新人和店铺新人的判定依赖历史订单数据，若口径不清，容易误发或漏发。
|
||||
- 风险点：同一时间仅允许 1 个进行中的活动，如果平台端和商家端同时配置活动，范围口径不清会导致规则冲突。
|
||||
- 确认结果：平台端和商家端活动可以并存，但约束粒度为“平台一条、每店铺各一条”。
|
||||
- 确认结果：未支付取消、超时未付、已退款等最终交易关闭单据不影响新人资格。
|
||||
- 确认结果：活动“已结束”和“已失效”同时成立时，页面优先展示“已失效”。
|
||||
- 确认结果：已领取平台新人礼的用户，若满足门店新人条件，仍允许继续领取门店新人礼。
|
||||
@@ -1,80 +0,0 @@
|
||||
# 新人礼需求测试点
|
||||
|
||||
## 1. 平台端列表与状态管理
|
||||
|
||||
1. 校验平台端列表默认按创建时间倒序展示，分页默认 10 条，支持切换 10、20、30、50 条。[需求]
|
||||
2. 校验按活动名称模糊查询、按活动状态精准查询、无结果空态提示、重置查询条件的行为正确。[需求]
|
||||
3. 校验活动状态“未开始、进行中、已结束、已失效”的展示口径和操作按钮是否符合规则。[需求]
|
||||
4. 校验活动失效后有效性展示为“已失效”，且操作栏切换为删除入口。[需求]
|
||||
5. 校验删除为永久删除，删除后列表不可见，后台数据状态与页面一致。[需求][项目画像]
|
||||
6. 校验列表展示字段、创建时间、活动状态、操作栏内容与需求一致。[需求]
|
||||
7. 校验不同状态下操作栏按钮映射正确，未开始/进行中/已结束/已失效的按钮展示不串位。[需求]
|
||||
8. 校验点击“新建”可正常打开新人礼配置弹窗或页面，交互入口与权限口径一致。[需求]
|
||||
|
||||
## 2. 活动配置与规则校验
|
||||
|
||||
1. 校验活动名称最大 50 字，超长时前端与后端均能拦截。[需求][漏测清单]
|
||||
2. 校验活动开始时间小于当前时间、结束时间小于开始时间时不可保存。[需求][边界]
|
||||
3. 校验活动奖品当前仅支持优惠券，积分奖励入口不可用或被明确拦截。[需求][技术方案]
|
||||
4. 校验每个活动仅能关联 1 张优惠券，无法多选、多绑或通过接口绕过限制。[技术方案][项目画像]
|
||||
5. 校验平台端新建合法活动时保存成功，列表、详情和活动明细数据落库正确。[需求]
|
||||
6. 校验平台端编辑未开始活动时可修改名称、时间、奖品等字段并保存成功。[需求]
|
||||
7. 校验平台维度同一时间仅允许 1 个进行中的平台新人礼活动，新增或编辑命中并存条件时保存失败并给出明确提示。[技术方案]
|
||||
8. 校验同一店铺维度同一时间仅允许 1 个进行中的门店新人礼活动，不同店铺活动可并存。[技术方案]
|
||||
9. 校验失效、删除操作存在二次确认，确认结果与列表及后台状态保持一致。[需求]
|
||||
10. 校验编辑活动时，已开始活动是否只允许查看不允许修改关键字段，状态与按钮保持一致。[需求]
|
||||
|
||||
## 3. 优惠券选择与权限隔离
|
||||
|
||||
1. 校验平台端仅能选择平台可用优惠券，且仅展示投放中、未过期、领取方式为用户领取的券。[需求]
|
||||
2. 校验商家端仅能选择本店铺可用优惠券，不能看到或绑定其他店铺优惠券。[需求][项目画像]
|
||||
3. 校验优惠券选择弹窗支持刷新、名称搜索、列表字段展示、分页、排序、单选反馈，且平台端与商家端展示的数据源范围不同。[需求][漏测清单]
|
||||
4. 校验通过抓包篡改券 ID、店铺 ID 或活动归属时，后端能拦截越权绑定。[历史缺陷][项目画像]
|
||||
|
||||
## 4. 商家端差异化行为
|
||||
|
||||
1. 校验商家端列表默认排序、分页、名称搜索、状态筛选、重置、空结果提示与平台端同构，但数据仅限当前店铺可见。[需求][项目画像]
|
||||
2. 校验商家端列表展示字段、操作栏按钮、不同状态下的权限映射正确。[需求]
|
||||
3. 校验商家端新建活动时，跨店铺数据隔离正确，门店 A 无法操作门店 B 活动。[项目画像]
|
||||
4. 校验商家端新建合法活动时保存成功，列表、详情和活动明细数据正确落库。[需求]
|
||||
5. 校验商家端编辑未开始活动时可正常保存，查看态页面所有字段只读，编辑态与查看态权限边界正确。[需求]
|
||||
6. 校验商家端活动失效、删除后，仅影响当前店铺，不影响平台端和其他店铺活动。[需求]
|
||||
7. 校验平台端活动数据在商家端不可见，商家端活动数据在平台端不可见。[需求][项目画像]
|
||||
|
||||
## 5. C 端资格检查与弹窗展示
|
||||
|
||||
1. 校验平台新人登录平台首页时，存在进行中平台新人礼活动则展示弹窗。[需求]
|
||||
2. 校验平台范围存在已支付或非交易关闭订单时，不展示平台新人礼弹窗。[需求][边界]
|
||||
3. 校验店铺新人进入门店首页时，存在进行中门店新人礼活动则展示门店弹窗。[需求]
|
||||
4. 校验当前店铺范围存在已支付或非交易关闭订单时，不展示门店新人礼弹窗。[需求][边界]
|
||||
5. 校验门店老用户进入门店首页时，不展示门店新人礼弹窗。[需求]
|
||||
6. 校验同时存在广告弹窗时，新人礼弹窗优先展示，关闭新人礼后再展示广告。[需求]
|
||||
7. 校验活动未开始时，资格检查结果和页面展示均不展示新人礼弹窗。[需求][状态流转]
|
||||
8. 校验活动已结束时，资格检查结果和页面展示均不展示新人礼弹窗。[需求][状态流转]
|
||||
9. 校验活动已失效时，资格检查结果和页面展示均不展示新人礼弹窗。[需求][状态流转]
|
||||
10. 校验用户历史订单均为交易关闭（未支付取消、超时未付、已退款）时，仍识别为新人并展示弹窗。[需求][产品确认]
|
||||
11. 校验未登录进入平台首页或门店首页时，不展示新人礼弹窗且不误触发领取流程。[需求][边界]
|
||||
12. 校验平台首页和门店首页展示的奖品信息与后台配置的优惠券信息一致，包括门槛、优惠金额、用券时间等。[需求]
|
||||
|
||||
## 6. 领取发放与日志落库
|
||||
|
||||
1. 校验点击“立即领取”成功后，页面提示成功，优惠券进入“我的优惠券”。[需求]
|
||||
2. 校验领取成功后，`new_gift_send_log` 写入成功记录，记录用户、活动、活动明细和状态。[技术方案]
|
||||
3. 校验同一用户重复点击“立即领取”或短时间重复调用发放接口时，只发放 1 次，日志不出现重复成功记录。[历史缺陷][项目画像]
|
||||
4. 校验领取失败时，页面提示失败原因，发放日志记录失败原因，不出现半成功状态。[技术方案][项目画像]
|
||||
5. 校验用户已领取过奖励后，再次进入首页不再弹出同一活动弹窗。[需求]
|
||||
6. 校验用户已领取平台新人礼后，若满足门店新人条件，仍可在门店首页领取门店新人礼。[需求][产品确认]
|
||||
|
||||
## 7. 异常、并发与非功能
|
||||
|
||||
1. 校验弱网、超时或接口重试场景下，资格检查接口不会错误多次弹窗或误判资格。[漏测清单][非功能]
|
||||
2. 校验领取接口超时或前端重复提交时，不会重复发券，用户可通过优惠券列表或重新进入页面查看最终结果。[漏测清单][非功能]
|
||||
3. 校验同一账号在两个终端同时领取新人礼时，最终仅 1 次成功发放。[项目画像][并发]
|
||||
4. 校验资格检查和领取接口响应时间满足技术目标 RT 1000ms，至少在常规测试数据量下不明显超时。[技术方案][非功能]
|
||||
|
||||
## 8. 产品确认口径回归
|
||||
|
||||
1. 校验平台活动与门店活动可同时存在，但平台维度仅允许 1 条进行中活动、每个店铺维度仅允许 1 条进行中活动。[产品确认]
|
||||
2. 校验历史订单均为交易关闭时仍视为新人；存在已支付或非关闭订单时不视为新人。[产品确认]
|
||||
3. 校验活动“已结束”和“已失效”同时成立时，列表优先展示“已失效”。[产品确认]
|
||||
4. 校验用户领取平台新人礼后，仍可继续领取符合条件的门店新人礼。[产品确认]
|
||||
@@ -1,47 +0,0 @@
|
||||
# 新人礼需求测试用例
|
||||
|
||||
| 用例编号 | 模块 | 用例标题 | 优先级 | 类型 | 前置条件 | 测试步骤 | 测试数据 | 预期结果 | 备注 |
|
||||
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
|
||||
| PLT_NG_LIST_001 | 平台端-营销管理-新人有礼列表 | 验证平台端列表默认排序、分页和查询功能正确 | P1 | 功能测试 | 平台端已存在 12 条新人礼活动数据，覆盖未开始、进行中、已结束、已失效状态；测试账号具备列表权限 | 1. 登录平台端进入营销-新人有礼列表<br>2. 观察默认排序和分页条数<br>3. 输入活动名称关键字执行查询<br>4. 选择活动状态执行筛选<br>5. 输入无匹配关键字执行查询<br>6. 点击重置 | 活动A 创建时间晚于活动B；查询关键字=新人；状态=进行中；无匹配关键字=不存在的活动名 | 1. 列表默认按创建时间倒序展示<br>2. 默认每页展示 10 条<br>3. 名称查询仅返回命中活动<br>4. 状态筛选仅返回对应状态活动<br>5. 无匹配数据时列表展示空态或“暂无数据”提示<br>6. 点击重置后查询条件被清空，列表恢复默认结果 | [AI修正: 对标团队用例补充空结果查询场景] |
|
||||
| PLT_NG_CFG_001 | 平台端-营销管理-新人有礼配置 | 验证活动时间非法时无法保存活动 | P1 | 功能测试 | 平台运营账号已登录；存在可选平台优惠券 | 1. 点击新建活动<br>2. 输入合法活动名称<br>3. 设置开始时间早于当前时间后尝试保存<br>4. 再设置结束时间早于开始时间后尝试保存 | 活动名称=平台新人礼A；开始时间=当前时间前 1 分钟；结束时间=开始时间前 1 秒 | 1. 页面对开始时间非法给出明确提示<br>2. 页面对结束时间非法给出明确提示<br>3. 活动保存失败<br>4. 后台 `new_gift` 主表不新增活动记录 | 边界值 |
|
||||
| PLT_NG_CFG_002 | 平台端-营销管理-新人有礼配置 | 验证平台端只能绑定 1 张符合条件的平台优惠券 | P0 | 功能测试 | 平台运营账号已登录；平台下存在 3 张券，分别为投放中可领券、已过期券、非用户领取券 | 1. 点击新建活动<br>2. 打开选择优惠券弹窗<br>3. 观察券列表范围<br>4. 选择 1 张投放中可领券后尝试继续追加选择第 2 张券<br>5. 保存活动 | 券A=投放中未过期用户领取券；券B=已过期券；券C=系统发放券 | 1. 弹窗仅展示平台可用且投放中、未过期、用户领取的券<br>2. 已过期券和非用户领取券不展示或不可选<br>3. 页面仅允许单选 1 张券<br>4. 保存成功后 `new_gift_detail` 仅存在 1 条券绑定记录 | [AI修正: 技术方案限定单券绑定] |
|
||||
| PLT_NG_CFG_003 | 平台端-营销管理-新人有礼配置 | 验证积分奖励当前不支持 | P1 | 功能测试 | 平台运营账号已登录 | 1. 点击新建活动<br>2. 进入活动奖品区域<br>3. 查看送积分配置入口<br>4. 若可通过前端或抓包提交积分类型则尝试保存 | gift_type=积分；积分值=100 | 1. 页面不允许启用积分奖品，或该入口展示为暂不支持<br>2. 若前端被绕过提交积分类型，后端拦截保存并返回错误提示<br>3. 后台不生成积分类型活动记录 | [AI修正: 范围外能力拦截] |
|
||||
| PLT_NG_CREATE_001 | 平台端-营销管理-新人有礼配置 | 验证平台端新建合法活动可保存成功 | P0 | 功能测试 | 平台运营账号已登录；存在 1 张投放中、未过期、用户领取类型的平台优惠券；当前无冲突中的平台活动 | 1. 点击新建活动<br>2. 填写活动名称、时间并选择 1 张合法平台券<br>3. 点击确定保存<br>4. 返回列表并进入详情页核对数据 | 活动名称=平台新人礼春季活动；开始时间=明天 10:00；结束时间=后天 10:00；券ID=PLT_COUPON_1001 | 1. 页面提示创建成功<br>2. 列表新增该活动记录，字段展示正确<br>3. 活动状态按时间口径展示为未开始<br>4. `new_gift` 和 `new_gift_detail` 新增对应活动及券绑定记录 | [AI修正: 对标团队用例补充后台正向新建链路] |
|
||||
| PLT_NG_EDIT_001 | 平台端-营销管理-新人有礼编辑 | 验证平台端编辑未开始活动可保存成功 | P1 | 功能测试 | 平台已存在 1 条未开始活动；平台运营账号已登录；存在 1 张新的合法平台优惠券 | 1. 在列表中点击编辑未开始活动<br>2. 修改活动名称、时间或绑定券<br>3. 点击确定保存<br>4. 刷新列表并进入详情查看 | 原活动名称=平台新人礼A；新活动名称=平台新人礼A-调整版；新券ID=PLT_COUPON_1002 | 1. 页面提示保存成功<br>2. 列表展示为修改后的名称和时间<br>3. 详情页展示最新配置<br>4. 后台活动主表和明细表更新为最新值，不产生重复活动记录 | [AI修正: 对标团队用例补充后台正向编辑链路] |
|
||||
| PLT_NG_POPUP_001 | 平台端-营销管理-优惠券选择弹窗 | 验证平台端选券弹窗支持搜索分页排序和单选反馈 | P1 | 功能测试 | 平台运营账号已登录；平台下存在 25 张符合或不符合条件的优惠券 | 1. 进入新建活动页面并打开优惠券选择弹窗<br>2. 点击刷新并观察列表加载<br>3. 输入优惠券名称执行搜索<br>4. 切换分页条数和页码<br>5. 观察列表排序和字段展示<br>6. 选择 1 张优惠券并确认返回 | 券名称关键字=新人礼；分页项=10/20；目标券=PLT_COUPON_1003 | 1. 弹窗可正常刷新数据<br>2. 名称搜索仅返回命中券<br>3. 分页、页码切换和排序行为正确<br>4. 列表展示券名称、有效期、领取方式等必要字段<br>5. 仅允许单选 1 张券，选中后页面回填正确的券信息 | [AI修正: 对标团队用例补充选券弹窗交互明细] |
|
||||
| PLT_NG_RULE_001 | 平台端-营销管理-新人有礼配置 | 验证平台维度同一时间仅允许一个进行中的新人礼活动 | P0 | 功能测试 | 已存在 1 条平台活动A，时间范围覆盖当前时刻且状态为进行中；平台运营账号已登录 | 1. 点击新建活动<br>2. 填写与活动A 时间重叠的新活动B信息<br>3. 选择合法平台优惠券并保存 | 活动A 时间=今天 10:00 到 明天 10:00；活动B 时间=今天 12:00 到 明天 12:00 | 1. 页面或接口提示当前已有进行中的平台新人礼活动<br>2. 活动B 保存失败<br>3. 后台不新增活动B 记录<br>4. 活动A 状态和绑定关系不受影响 | [AI修正: 按产品确认口径更新为平台维度唯一] |
|
||||
| PLT_NG_STATE_001 | 平台端-营销管理-新人有礼状态 | 验证活动失效后展示已失效并支持删除 | P1 | 功能测试 | 平台已存在 1 条未开始活动和 1 条进行中活动；平台运营账号已登录 | 1. 在列表中对活动执行失效操作<br>2. 刷新列表查看状态和操作按钮<br>3. 对已失效活动执行删除操作<br>4. 再次刷新列表 | 活动A=未开始；活动B=进行中 | 1. 失效后活动有效性展示为已失效<br>2. 失效活动的操作按钮切换为删除<br>3. 删除确认后页面提示删除成功<br>4. 列表中不再显示该活动<br>5. 后台活动记录被标记删除或按实现永久删除，不可继续被资格检查命中 | 状态流转 |
|
||||
| PLT_NG_STATE_002 | 平台端-营销管理-新人有礼状态 | 验证活动已结束且已失效时列表优先展示已失效 | P1 | 功能测试 | 平台存在 1 条活动，活动结束时间早于当前时间，且已执行失效操作；平台运营账号已登录 | 1. 进入平台端新人有礼列表<br>2. 查询该活动状态展示和操作按钮 | 活动A 结束时间=当前时间前 1 天；valid_status=已失效 | 1. 列表最终状态优先展示为已失效<br>2. 操作按钮按已失效口径展示删除，不按已结束展示<br>3. 页面状态展示与后台有效性字段一致 | [AI修正: 按产品确认口径补充状态优先级] |
|
||||
| MCH_NG_SCOPE_001 | 商家端-营销管理-新人有礼配置 | 验证商家端只能选择本店铺优惠券 | P0 | 功能测试 | 商家A 账号已登录；商家A 券A 为可领券；商家B 券B 为可领券 | 1. 商家A 进入新建活动页面<br>2. 打开优惠券选择弹窗<br>3. 搜索本店券A 和外店券B<br>4. 选择券A 保存活动 | 商家A ID=1001；商家B ID=1002；券A 属于商家A；券B 属于商家B | 1. 列表仅展示商家A 可用券<br>2. 搜索券B 无结果或不可选<br>3. 保存成功后活动绑定的券归属为商家A<br>4. 后台不存在跨店绑定关系 | [AI修正: 覆盖数据隔离与越权风险] |
|
||||
| MCH_NG_SCOPE_002 | 商家端-营销管理-新人有礼配置 | 验证篡改券 ID 无法越权绑定其他店铺优惠券 | P0 | 安全性测试 | 商家A 账号已登录；抓包工具可修改请求；商家B 存在 1 张有效券 | 1. 商家A 正常进入新建活动页面并选择商家A 自有券<br>2. 提交前抓包将券 ID 替换为商家B 券 ID<br>3. 提交保存请求 | 提交参数原券 ID=COUPON_A_01；篡改后券 ID=COUPON_B_01 | 1. 后端拦截越权绑定请求并返回错误提示<br>2. 页面保存失败<br>3. 后台不生成跨店活动与券绑定关系<br>4. 审计日志记录异常请求或失败原因 | [AI修正: 对应越权与价格篡改类历史风险] |
|
||||
| MCH_NG_RULE_001 | 商家端-营销管理-新人有礼配置 | 验证同一店铺仅允许一个进行中的门店新人礼活动但不同店铺可并存 | P0 | 功能测试 | 商家A 已存在 1 条进行中的门店活动A；商家B 无进行中活动；商家A、商家B 账号均可登录 | 1. 商家A 新建与活动A 时间重叠的门店活动A2并保存<br>2. 商家B 新建与活动A 同时段重叠的门店活动B并保存<br>3. 查询两家店铺活动列表 | 商家A ID=1001；商家B ID=1002；活动A2 与活动A 时间重叠；活动B 与活动A 时间重叠 | 1. 商家A 保存活动A2失败，并提示当前店铺已有进行中的新人礼活动<br>2. 商家B 保存活动B成功<br>3. 后台显示门店活动限制按店铺维度生效，不会因商家A 活动阻塞商家B 配置 | [AI修正: 按产品确认口径补充店铺维度唯一] |
|
||||
| MCH_NG_LIST_001 | 商家端-营销管理-新人有礼列表 | 验证商家端列表默认排序、分页、搜索和重置功能正确 | P1 | 功能测试 | 商家A 已存在 12 条新人礼活动数据，覆盖未开始、进行中、已结束、已失效状态；商家运营账号具备列表权限 | 1. 登录商家A 端进入新人有礼列表<br>2. 观察默认排序和分页条数<br>3. 输入活动名称关键字执行查询<br>4. 选择活动状态执行筛选<br>5. 输入无匹配关键字执行查询<br>6. 点击重置 | 店铺ID=1001；关键字=新人；状态=进行中；无匹配关键字=不存在的活动名 | 1. 列表默认按创建时间倒序展示<br>2. 默认每页展示 10 条并可切换分页项<br>3. 名称搜索和状态筛选仅返回当前店铺命中数据<br>4. 无匹配数据时展示空态或“暂无数据”提示<br>5. 点击重置后恢复默认列表 | [AI修正: 对标团队用例补充商家端列表基础能力] |
|
||||
| MCH_NG_LIST_002 | 商家端-营销管理-新人有礼列表 | 验证商家端列表字段和操作栏状态映射正确 | P1 | 功能测试 | 商家A 存在未开始、进行中、已结束、已失效四类活动；商家运营账号已登录 | 1. 进入商家A 新人有礼列表<br>2. 逐条检查活动名称、活动时间、活动状态、创建时间、操作栏<br>3. 对比不同状态下的操作按钮 | 活动A=未开始；活动B=进行中；活动C=已结束；活动D=已失效 | 1. 列表展示字段完整且内容正确<br>2. 未开始活动展示编辑、失效<br>3. 进行中活动展示查看、失效或按最终规则允许的编辑能力<br>4. 已结束和已失效活动展示删除或受限操作<br>5. 状态与按钮映射不串位 | [AI修正: 对标团队用例补充商家端状态按钮映射] |
|
||||
| MCH_NG_CREATE_001 | 商家端-营销管理-新人有礼配置 | 验证商家端新建合法活动可保存成功 | P0 | 功能测试 | 商家A 账号已登录；商家A 存在 1 张投放中、未过期、用户领取类型的店铺优惠券；当前店铺无冲突中的门店活动 | 1. 点击新建活动<br>2. 填写活动名称、时间并选择 1 张本店合法券<br>3. 点击确定保存<br>4. 返回列表并进入详情页核对数据 | 店铺ID=1001；活动名称=门店新人礼春季活动；券ID=SHOP_COUPON_1001 | 1. 页面提示创建成功<br>2. 列表新增该门店活动记录，字段展示正确<br>3. 活动状态按时间口径展示为未开始<br>4. `new_gift` 和 `new_gift_detail` 新增当前店铺对应活动及券绑定记录 | [AI修正: 对标团队用例补充商家端正向新建链路] |
|
||||
| MCH_NG_EDIT_001 | 商家端-营销管理-新人有礼编辑 | 验证商家端编辑未开始活动可保存成功 | P1 | 功能测试 | 商家A 存在 1 条未开始活动；商家A 账号已登录；存在 1 张新的本店合法券 | 1. 在列表中点击编辑未开始活动<br>2. 修改活动名称、时间或绑定券<br>3. 点击确定保存<br>4. 刷新列表并进入详情页核对 | 原活动名称=门店新人礼A；新活动名称=门店新人礼A-调整版；新券ID=SHOP_COUPON_1002 | 1. 页面提示保存成功<br>2. 列表和详情页展示最新配置<br>3. 后台活动主表和明细表更新为最新值<br>4. 不产生重复活动记录或跨店异常数据 | [AI修正: 对标团队用例补充商家端正向编辑链路] |
|
||||
| MCH_NG_POPUP_001 | 商家端-营销管理-优惠券选择弹窗 | 验证商家端选券弹窗支持搜索分页排序和单选反馈 | P1 | 功能测试 | 商家A 账号已登录；商家A 下存在 25 张符合或不符合条件的优惠券 | 1. 进入新建活动页面并打开优惠券选择弹窗<br>2. 点击刷新并观察列表加载<br>3. 输入优惠券名称执行搜索<br>4. 切换分页条数和页码<br>5. 观察列表排序和字段展示<br>6. 选择 1 张优惠券并确认返回 | 店铺ID=1001；券名称关键字=新人礼；分页项=10/20；目标券=SHOP_COUPON_1003 | 1. 弹窗可正常刷新数据<br>2. 搜索仅返回当前店铺命中的券<br>3. 分页、页码切换和排序行为正确<br>4. 列表展示券名称、有效期、领取方式等必要字段<br>5. 仅允许单选 1 张券，确认后页面正确回填券信息 | [AI修正: 对标团队用例补充商家端选券弹窗交互明细] |
|
||||
| MCH_NG_STATE_001 | 商家端-营销管理-新人有礼状态 | 验证商家端活动失效后展示已失效并支持删除 | P1 | 功能测试 | 商家A 已存在 1 条未开始活动和 1 条进行中活动；商家A 账号已登录 | 1. 在列表中对活动执行失效操作并确认<br>2. 刷新列表查看状态和操作按钮<br>3. 对已失效活动执行删除并确认<br>4. 再次刷新列表 | 店铺ID=1001；活动A=未开始；活动B=进行中 | 1. 失效后活动有效性展示为已失效<br>2. 已失效活动操作栏切换为删除<br>3. 删除确认后页面提示删除成功<br>4. 列表中不再显示该活动<br>5. 后台仅删除当前店铺对应活动，不影响其他店铺或平台活动 | [AI修正: 对标团队用例补充商家端失效删除链路] |
|
||||
| MCH_NG_VIEW_001 | 商家端-营销管理-新人有礼查看 | 验证商家端查看态页面所有字段只读不可编辑 | P1 | 功能测试 | 商家A 已存在 1 条新人礼活动；商家A 账号已登录 | 1. 在列表中点击查看<br>2. 观察活动名称、活动时间、活动奖品等字段状态<br>3. 尝试修改字段或提交 | 店铺ID=1001；活动ID=SHOP1001 | 1. 查看页所有字段均为只读态<br>2. 页面不提供可提交修改的入口<br>3. 用户无法通过查看态改写活动配置 | [AI修正: 对标团队用例补充商家端查看只读场景] |
|
||||
| C_NG_POP_001 | 用户端-首页-新人礼弹窗 | 验证平台新人登录平台首页时展示新人礼弹窗 | P0 | 冒烟测试 | 平台存在 1 条进行中的平台新人礼活动；用户U1 已注册登录且平台维度无下单记录；用户未领取过该活动 | 1. 用户U1 登录平台首页<br>2. 观察首页首屏弹窗 | 用户U1；平台活动=进行中；平台下单记录=0 | 1. 首页展示新人礼弹窗<br>2. 弹窗内容展示活动奖励信息和立即领取按钮<br>3. 后台资格检查接口返回命中活动和可领取状态 | 主流程 |
|
||||
| C_NG_POP_002 | 用户端-首页-新人礼弹窗 | 验证非平台新人登录平台首页时不展示新人礼弹窗 | P1 | 功能测试 | 平台存在 1 条进行中的平台新人礼活动；用户U2 已注册登录且平台维度存在已下单记录 | 1. 用户U2 登录平台首页<br>2. 观察首页弹窗和资格检查结果 | 用户U2；平台已支付订单数=1 | 1. 首页不展示新人礼弹窗<br>2. 资格检查接口返回不满足新人条件<br>3. 页面不出现立即领取入口 | 边界值 |
|
||||
| C_NG_POP_003 | 用户端-门店首页-新人礼弹窗 | 验证平台老用户但门店新用户进入门店首页时展示门店新人礼弹窗 | P0 | 功能测试 | 商家A 存在 1 条进行中的门店新人礼活动；用户U3 平台维度已有下单记录，但在商家A 维度无下单记录；用户未领取过商家A 活动 | 1. 用户U3 进入商家A 门店首页<br>2. 观察首页弹窗<br>3. 查询资格检查结果 | 用户U3；平台订单数=1；商家A 订单数=0 | 1. 门店首页展示商家A 新人礼弹窗<br>2. 资格检查接口按门店维度返回可领取<br>3. 弹窗奖励信息与商家A 活动配置一致 | [AI修正: 覆盖平台新人和店铺新人差异口径] |
|
||||
| C_NG_POP_004 | 用户端-首页-弹窗优先级 | 验证存在广告弹窗时新人礼弹窗优先展示 | P1 | 功能测试 | 平台存在 1 条进行中的新人礼活动；首页同时配置普通广告弹窗；用户U1 满足平台新人资格 | 1. 用户U1 登录平台首页<br>2. 观察首个弹窗<br>3. 关闭新人礼弹窗后继续观察 | 用户U1；广告弹窗=已配置 | 1. 首个弹窗为新人礼弹窗<br>2. 关闭新人礼弹窗后再展示广告弹窗<br>3. 整个过程中弹窗顺序与需求一致 | 交互优先级 |
|
||||
| C_NG_POP_005 | 用户端-首页-新人礼弹窗 | 验证历史订单均为交易关闭时仍识别为平台新人 | P0 | 功能测试 | 平台存在 1 条进行中的平台新人礼活动；用户U6 历史仅有未支付取消单、超时未付单或已退款订单，且无其他非关闭订单 | 1. 用户U6 登录平台首页<br>2. 观察首页弹窗<br>3. 查询资格检查结果 | 用户U6 历史订单状态=交易关闭、已退款、超时未付 | 1. 首页展示平台新人礼弹窗<br>2. 资格检查接口返回满足平台新人条件<br>3. 页面不因历史关闭单或已退款单而拦截新人资格 | [AI修正: 按产品确认口径补充交易关闭单仍算新人] |
|
||||
| C_NG_POP_006 | 用户端-首页-新人礼弹窗 | 验证未登录进入首页时不展示新人礼弹窗 | P0 | 功能测试 | 平台或门店存在进行中的新人礼活动；用户未登录 | 1. 未登录直接进入平台首页<br>2. 未登录直接进入门店首页<br>3. 观察页面弹窗与网络请求 | 访问端=H5/小程序；登录态=未登录 | 1. 平台首页和门店首页均不展示新人礼弹窗<br>2. 页面不进入领取流程<br>3. 若触发资格检查请求，应返回未登录拦截而非可领取结果 | [AI修正: 取自团队现有功能用例] |
|
||||
| C_NG_POP_007 | 用户端-首页-新人礼展示 | 验证首页展示的奖品信息与后台配置一致 | P0 | 功能测试 | 平台和商家端各存在 1 条进行中的新人礼活动，且分别绑定不同门槛和优惠内容的优惠券；用户满足资格 | 1. 平台新人登录平台首页查看弹窗奖品信息<br>2. 店铺新人进入门店首页查看弹窗奖品信息<br>3. 对比后台券配置 | 平台券=满100减20, 用券时间 2026-05-01 至 2026-05-31；店铺券=8折券, 上限 30 元 | 1. 平台首页弹窗展示的平台券门槛、优惠金额或折扣、用券时间与后台配置一致<br>2. 门店首页弹窗展示的商家券信息与商家端配置一致<br>3. 不出现平台券和商家券信息串位 | [AI修正: 取自团队现有功能用例] |
|
||||
| C_NG_POP_008 | 用户端-门店首页-新人礼弹窗 | 验证门店老用户进入门店首页时不展示门店新人礼弹窗 | P1 | 功能测试 | 商家A 存在 1 条进行中的门店新人礼活动；用户U9 已登录且在商家A 维度存在已支付订单 | 1. 用户U9 进入商家A 门店首页<br>2. 观察首页弹窗和资格检查结果 | 用户U9；店铺ID=1001；商家A 已支付订单数=1 | 1. 门店首页不展示门店新人礼弹窗<br>2. 资格检查接口返回不满足门店新人条件<br>3. 页面不出现立即领取入口 | [AI修正: 对标团队用例补充门店老用户负向场景] |
|
||||
| C_NG_SEND_001 | 用户端-首页-新人礼领取 | 验证点击立即领取成功后优惠券入账并写发放日志 | P0 | 冒烟测试 | 用户U1 满足平台新人资格；平台存在进行中活动且绑定有效券；用户未领取过该活动 | 1. 用户U1 在新人礼弹窗点击立即领取<br>2. 观察页面提示<br>3. 进入我的优惠券查询奖励<br>4. 查询发放日志 | 用户U1；活动ID=NG1001；券ID=PC1001 | 1. 页面提示领取成功<br>2. 我的优惠券列表新增对应优惠券<br>3. `new_gift_send_log` 新增 1 条成功记录，包含用户、活动、活动明细和发送状态<br>4. 该用户再次进入首页时不再展示同一活动弹窗 | 主流程 |
|
||||
| C_NG_SEND_002 | 用户端-首页-新人礼领取 | 验证同一用户重复点击立即领取时只发放一次 | P0 | 回归测试 | 用户U1 满足新人资格；平台存在进行中活动且绑定有效券；抓包或前端可模拟快速重复点击 | 1. 用户U1 打开新人礼弹窗<br>2. 在 1 秒内连续点击 3 次立即领取<br>3. 查询优惠券列表和发放日志 | 用户U1；活动ID=NG1001；重复点击次数=3 | 1. 页面最多显示 1 次领取成功提示<br>2. 用户仅新增 1 张优惠券<br>3. `new_gift_send_log` 仅有 1 条成功记录，其余请求被幂等拦截或返回已领取<br>4. 不出现重复发券 | [AI修正: 对应重复提交和重复支付类历史风险] |
|
||||
| C_NG_SEND_003 | 用户端-首页-新人礼领取 | 验证领取接口超时重试时不会重复发券 | P1 | 回归测试 | 用户U1 满足新人资格；模拟领取接口首个请求响应超时但后端已处理成功 | 1. 用户U1 点击立即领取<br>2. 将首个请求模拟为前端超时<br>3. 用户再次点击立即领取或页面自动重试<br>4. 查询优惠券列表和发放日志 | 首次请求后端处理成功；前端超时 5 秒 | 1. 页面提示处理中或可稍后刷新查看结果<br>2. 最终用户仅获得 1 张优惠券<br>3. 发放日志中仅 1 条成功记录，不存在多条成功发放<br>4. 页面最终状态与后台结果一致 | 非功能 |
|
||||
| C_NG_SEND_004 | 用户端-首页-新人礼领取 | 验证发券失败时记录失败原因且不出现半成功状态 | P1 | 功能测试 | 用户U4 满足新人资格；将发券接口模拟为失败 | 1. 用户U4 点击立即领取<br>2. 观察页面提示<br>3. 查询我的优惠券列表<br>4. 查询发放日志 | 券中心返回=库存不足或券失效 | 1. 页面提示领取失败及失败原因<br>2. 我的优惠券列表不新增该券<br>3. `new_gift_send_log` 记录失败状态和失败原因<br>4. 用户状态不被误标记为已领取 | [AI修正: 覆盖部分成功和异常记录风险] |
|
||||
| C_NG_SEND_005 | 用户端-首页-新人礼领取 | 验证同一账号双端并发领取时最终仅一次成功 | P1 | 功能测试 | 用户U5 满足新人资格；用户在手机端和 H5 端同时登录；平台存在进行中活动 | 1. 手机端和 H5 端同时打开新人礼弹窗<br>2. 两端几乎同时点击立即领取<br>3. 查询两端提示、优惠券列表和发放日志 | 用户U5；双端并发间隔小于 200ms | 1. 最终仅 1 次领取成功<br>2. 另一端返回已领取、处理中或重复请求提示<br>3. 用户优惠券列表仅新增 1 张券<br>4. 发放日志仅保留 1 条成功记录 | 并发 |
|
||||
| C_NG_SEND_006 | 用户端-门店首页-新人礼领取 | 验证用户领取平台新人礼后仍可继续领取门店新人礼 | P0 | 功能测试 | 用户U7 已成功领取平台新人礼；商家A 存在进行中的门店新人礼活动；用户U7 在商家A 维度无非关闭订单且未领取过门店活动 | 1. 用户U7 登录平台首页并确认已领取平台新人礼<br>2. 用户U7 进入商家A 门店首页<br>3. 观察门店弹窗并点击立即领取<br>4. 查询门店发放日志和优惠券列表 | 用户U7；平台活动ID=PLT1001；门店活动ID=SHOP1001 | 1. 门店首页仍展示门店新人礼弹窗<br>2. 用户可成功领取门店优惠券<br>3. 优惠券列表中同时存在平台新人礼券和门店新人礼券<br>4. 门店活动发放日志新增成功记录，不因已领取平台礼而被拦截 | [AI修正: 按产品确认口径补充平台礼与门店礼可并存] |
|
||||
| C_NG_CHECK_001 | 用户端-首页-资格检查 | 验证无进行中活动时不展示新人礼弹窗 | P1 | 功能测试 | 平台不存在进行中活动；用户U1 满足新人资格 | 1. 用户U1 登录平台首页<br>2. 观察首页弹窗<br>3. 查询资格检查接口返回 | 活动列表=空或全部不命中资格检查条件 | 1. 首页不展示新人礼弹窗<br>2. 资格检查接口返回无可领取活动<br>3. 页面不出现错误提示或异常闪现弹窗 | [AI修正: 将状态负向场景拆分，提升定位性] |
|
||||
| C_NG_CHECK_002 | 用户端-首页-资格检查 | 验证活动未开始时不展示新人礼弹窗 | P1 | 功能测试 | 平台存在 1 条未开始活动；用户U1 满足新人资格；当前无其他进行中活动 | 1. 用户U1 登录平台首页<br>2. 观察首页弹窗<br>3. 查询资格检查接口返回 | 活动开始时间=当前时间后 1 小时 | 1. 首页不展示新人礼弹窗<br>2. 资格检查接口返回无可领取活动或活动未开始<br>3. 页面不出现提前曝光的领取入口 | [AI修正: 对标团队用例补充状态拆分场景] |
|
||||
| C_NG_CHECK_003 | 用户端-首页-资格检查 | 验证活动已结束时不展示新人礼弹窗 | P1 | 功能测试 | 平台存在 1 条已结束活动；用户U1 满足新人资格；当前无其他进行中活动 | 1. 用户U1 登录平台首页<br>2. 观察首页弹窗<br>3. 查询资格检查接口返回 | 活动结束时间=当前时间前 1 小时 | 1. 首页不展示新人礼弹窗<br>2. 资格检查接口返回无可领取活动或活动已结束<br>3. 页面不出现已结束活动的领取入口 | [AI修正: 对标团队用例补充状态拆分场景] |
|
||||
| C_NG_CHECK_004 | 用户端-首页-资格检查 | 验证活动已失效时不展示新人礼弹窗 | P1 | 功能测试 | 平台存在 1 条已失效活动；用户U1 满足新人资格；当前无其他进行中活动 | 1. 用户U1 登录平台首页<br>2. 观察首页弹窗<br>3. 查询资格检查接口返回 | 活动状态=已失效；valid_status=失效 | 1. 首页不展示新人礼弹窗<br>2. 资格检查接口返回无可领取活动或活动已失效<br>3. 页面状态与后台有效性字段一致 | [AI修正: 对标团队用例补充状态拆分场景] |
|
||||
| API_NG_PERF_001 | 用户端-资格检查-接口性能 | 验证资格检查接口在常规数据量下满足 RT 基线 | P2 | 性能测试 | 存在 100 条历史发放记录和 10 条活动数据；性能环境可统计接口耗时 | 1. 触发用户进入平台首页调用资格检查接口<br>2. 连续执行 30 次<br>3. 统计平均 RT 和 P95 | 接口=`/ua/newGift/check`；样本量=30 | 1. 常规场景下接口平均 RT 和 P95 满足 1000ms 基线或接近目标<br>2. 页面无明显卡顿或超时提示<br>3. 若超基线，应能定位是活动查询、资格判定还是日志判断链路耗时 | [AI修正: 技术方案给出 RT 1000ms] |
|
||||
| C_NG_RULE_001 | 用户端-资格判定-新人口径 | 验证存在已支付订单时不再识别为新人 | P1 | 功能测试 | 用户U8 存在 1 笔平台已支付订单；平台存在进行中活动 | 1. 用户U8 登录平台首页<br>2. 观察是否弹出新人礼<br>3. 查询资格检查返回 | 用户U8 历史订单状态=已支付 | 1. 首页不展示新人礼弹窗<br>2. 资格检查接口返回不满足新人条件<br>3. 页面展示与产品确认口径一致，不因已支付历史订单继续认定为新人 | [AI修正: 按产品确认口径更新新人判定] |
|
||||
| DATA_NG_SCOPE_001 | 平台端-商家端-数据隔离 | 验证平台端与商家端新人礼活动数据不互通 | P0 | 功能测试 | 平台端已配置 1 条平台新人礼活动；商家A 已配置 1 条门店新人礼活动；测试账号分别具备平台端和商家端权限 | 1. 在平台端查看新人礼活动列表<br>2. 在商家A 端查看新人礼活动列表<br>3. 对比两端列表数据 | 平台活动ID=PLT1001；商家活动ID=SHOP1001 | 1. 平台端仅展示平台活动数据，不展示商家活动<br>2. 商家端仅展示当前店铺活动数据，不展示平台活动<br>3. 两端数据查询、查看、编辑入口相互隔离 | [AI修正: 取自团队现有功能用例] |
|
||||
| VIEW_NG_READONLY_001 | 平台端-营销管理-新人有礼查看 | 验证查看态页面所有字段只读不可编辑 | P1 | 功能测试 | 平台已存在 1 条新人礼活动；平台运营账号已登录 | 1. 在列表中点击查看<br>2. 观察活动名称、活动时间、活动奖品等字段状态<br>3. 尝试修改字段或提交 | 活动ID=PLT1001 | 1. 查看页所有字段均为只读态<br>2. 页面不提供可提交修改的入口<br>3. 用户无法通过查看态改写活动配置 | [AI修正: 取自团队现有功能用例] |
|
||||
| PLT_NG_LIST_002 | 平台端-营销管理-新人有礼列表 | 验证列表展示字段和操作栏状态映射正确 | P1 | 功能测试 | 平台端存在未开始、进行中、已结束、已失效四类活动；平台运营账号已登录 | 1. 进入新人有礼列表<br>2. 逐条检查活动名称、活动时间、活动状态、创建时间、操作栏<br>3. 对比不同状态下的操作按钮 | 活动A=未开始；活动B=进行中；活动C=已结束；活动D=已失效 | 1. 列表展示字段完整且内容正确<br>2. 未开始活动展示编辑、失效<br>3. 进行中活动展示查看、失效或按最终规则允许的编辑能力<br>4. 已结束和已失效活动操作栏按需求展示删除或受限操作 | [AI修正: 取自团队现有功能用例] |
|
||||
Binary file not shown.
Reference in New Issue
Block a user