120 lines
4.5 KiB
Markdown
120 lines
4.5 KiB
Markdown
# CP关系本地真实链路测试用例
|
||
|
||
本文只记录本地真实链路验证用例。业务动作优先走 gateway HTTP、room/wallet/user/notice 服务和 RocketMQ；SQL 只用于准备本地测试数据和核对最终事实。
|
||
|
||
## 环境前置
|
||
|
||
- Docker 本地服务：MySQL、Redis、RocketMQ、gateway-service、room-service、wallet-service、user-service、notice-service。
|
||
- `user-service` 必须启用 `cp_relationship_worker`，并消费 `hyapp_room_outbox`。
|
||
- `notice-service` 必须消费 `hyapp_user_outbox`，并把 CP 申请/同意/拒绝/关系创建事件投递到腾讯云 IM。
|
||
- 本地测试账号 A、B、C 需要是同一个 `app_code=lalu` 下的完整资料用户。
|
||
- 本地 CP 礼物需要是 `gift_type_code=cp`，并在礼物配置中写入 `cp_relation_type`。
|
||
- 送礼前 A 和 B 必须都在同一个房间的 room-service presence 内。
|
||
|
||
## T01 CP礼物创建申请
|
||
|
||
步骤：
|
||
|
||
1. 准备 A、B 用户和 A 的 COIN 余额。
|
||
2. 准备 CP 礼物 `local_cp_gift_cp`，`cp_relation_type=cp`。
|
||
3. A 创建房间，A 和 B 都调用进房接口。
|
||
4. A 通过 gateway 给 B 送 CP 礼物。
|
||
|
||
验证：
|
||
|
||
- `hyapp_room.room_outbox` 有 `RoomGiftSent`，payload 中 `cp_relation_type=cp`、`gift_icon_url` 非空。
|
||
- RocketMQ `hyapp_room_outbox` 被 user-service CP consumer 消费。
|
||
- `hyapp_user.user_cp_applications` 有 A 到 B 的 pending 申请，`expires_at_ms` 为当前时间加服务端默认 24 小时。
|
||
- `hyapp_user.user_cp_gift_event_consumption` 有该 room event 的消费记录。
|
||
- `hyapp_user.user_outbox` 有 `UserCPApplicationCreated`。
|
||
- 腾讯云 IM 有 A 发给 B 的 C2C 申请消息，`Desc=cp_application_created`，payload 含 `application_id`、`relation_type=cp`、`expires_at_ms`。
|
||
- 腾讯云 IM 有发到房间群的申请消息，`Desc=cp_application_created`，payload 含 `recipient_user_id=B`、`room_id`。
|
||
|
||
## T02 B同意申请建立关系
|
||
|
||
步骤：
|
||
|
||
1. 使用 T01 产生的 `application_id`。
|
||
2. B 调用 gateway 同意申请接口。
|
||
|
||
验证：
|
||
|
||
- `user_cp_applications.status=accepted`。
|
||
- `user_cp_relationships` 新增 active 关系，A/B 无序 pair 只有一条 active 关系。
|
||
- 同一对用户其他 pending 申请被置为 `blocked`。
|
||
- `user_outbox` 有 `UserCPApplicationAccepted` 和 `UserCPRelationshipCreated`。
|
||
- 腾讯云 IM 向 A 发送 B 发出的同意结果 C2C 消息，`Desc=cp_application_accepted`。
|
||
- 腾讯云 IM 向房间群发送同意结果消息，`Desc=cp_application_accepted`，payload 含 `recipient_user_id=A`。
|
||
- 腾讯云 IM 向区域群发送关系创建消息，`Desc=cp_relationship_created`，payload 含 A/B 头像昵称短 ID、礼物 icon 和 `room_id`。
|
||
|
||
## T03 已有关系后送礼增加亲密值并升级
|
||
|
||
步骤：
|
||
|
||
1. 使用服务端默认等级规则，确认 1 级阈值为 0。
|
||
2. A 再次给 B 送 CP 礼物。
|
||
|
||
验证：
|
||
|
||
- 不新增 pending 申请。
|
||
- 原关系 `intimacy_value` 增加礼物结算热度值。
|
||
- 原关系 `level_no` 按服务端默认阈值计算。
|
||
- `user_outbox` 有 `UserCPRelationshipIntimacyChanged`。
|
||
|
||
## T04 同一对用户只能同时存在一种关系
|
||
|
||
步骤：
|
||
|
||
1. A 给 B 发送兄弟礼物，生成 brother pending 申请。
|
||
2. A 给 B 发送姐妹礼物，生成 sister pending 申请。
|
||
3. B 接受其中一个申请。
|
||
4. B 再尝试接受另一个申请。
|
||
|
||
验证：
|
||
|
||
- 第一个接受成功后产生 active 关系。
|
||
- 另一个申请不能接受，接口返回冲突提示。
|
||
- A/B active 关系仍只有一种。
|
||
|
||
## T05 同一用户只能同时存在一个关系
|
||
|
||
步骤：
|
||
|
||
1. 使用 T02 建立 A/B active 关系。
|
||
2. C 给 A 发送 CP 礼物，生成 C 到 A 的 pending 申请。
|
||
3. A 尝试同意 C 的申请。
|
||
|
||
验证：
|
||
|
||
- 同意接口返回冲突。
|
||
- A/B active 关系仍保留。
|
||
- C/A 不创建 active 关系。
|
||
|
||
## T06 申请过期
|
||
|
||
步骤：
|
||
|
||
1. 创建一条 pending 申请。
|
||
2. 通过 SQL 把 `expires_at_ms` 调整到当前时间之前。
|
||
3. B 查询申请列表或尝试同意。
|
||
|
||
验证：
|
||
|
||
- 申请状态被固化为 `expired`。
|
||
- 同意接口返回 `CONFLICT`，申请被固化为 `expired`，不建立关系。
|
||
|
||
## T07 拒绝申请
|
||
|
||
步骤：
|
||
|
||
1. 创建一条 pending 申请。
|
||
2. B 调用拒绝接口。
|
||
|
||
验证：
|
||
|
||
- `user_cp_applications.status=rejected`。
|
||
- 不创建 active 关系。
|
||
- `user_outbox` 有 `UserCPApplicationRejected`。
|
||
- 腾讯云 IM 向 A 发送 B 发出的拒绝结果 C2C 消息，`Desc=cp_application_rejected`。
|
||
- 腾讯云 IM 向房间群发送拒绝结果消息，`Desc=cp_application_rejected`，payload 含 `recipient_user_id=A`。
|