Tidyvo v1.0.6 通知系统测试验收#
本页供产品在线逐项验收，共 26 项，与 PRD 第 4 章的 26 条验收标准一一对应。
测试状态和反馈保存在当前浏览器；更换设备或清理浏览器数据后不会自动同步。
测试前准备#
| 类别 | 必须准备 |
|---|---|
| 测试包 | 当前待验收的 v1.0.6 包，能查看版本号和构建号；代码或配置变更后必须换新包重测 |
| 设备 | 至少 1 台 Android 13+ 真机；通知权限可反复开关，可查看系统通知栏、App 前后台和强行停止状态 |
| 用户来源 | 自然量、推广、无法归类三种可复位测试状态；每次切换后都能从客户端日志确认当前判定结果 |
| 中台 / FCM | 可切换 OFF / ORGANIC_ONLY / PAID_ONLY，可向统一 Topic 发 data-only 空消息，可创建一条 FCM 后台定时可见测试通知 |
| 测试数据 | 可控照片、视频、截图、联系人、Private Space 文件、Smart Clean 结果、清理记录和其他 App 通知；每组数据需记录预期数量和容量 |
| 可观测证据 | 每次候选检查至少能追溯：入口、三态、来源、调度时间、场景 ID、模板 ID、合格/跳过原因、展示结果、当日次数、上次展示时间、点击路由和广告结果 |
| 时间边界 | 15 分钟、60 秒、跨日和 24 小时场景可用测试时钟/可控数据快速验证，但必须再用真实系统时间至少抽验 1 次；不能只改界面显示时间 |
统一执行与判定规则#
- 每条用例开始前记录：包版本、设备 / Android 版本、当地时间、通知权限、用户来源、中台三态和预置数据。
- 每条用例至少保留：操作截图 / 录屏、关键日志、实际通知截图（若应展示）、目标页截图（若涉及点击）。
- “未展示”类用例必须同时用日志证明候选确实进入且被指定规则拦截，不能只看通知栏没有通知就判通过。
- 任一子场景不满足通过标准，整条用例选“不通过”；因缺包、缺账号、缺中台权限或缺日志无法判定时选“阻塞”，不得选“通过”。
一、通知控制与频控#
| 编号 | 测试项 | 怎么测 | 通过标准 |
|---|---|---|---|
| A01 | 只有一套通知方案 | 前置：取当前待验收 APK / AAB 及中台当前通知配置截图或导出。 步骤：1、全局搜索客户端通知策略、分组和比例字段；2、检查中台通知配置页和下发请求；3、用自然量与推广设备各触发 3 次合格候选，记录命中的策略标识。 证据：代码/包检查结果、中台截图、6 次候选日志。 |
1、客户端只有一条 Tidyvo 通知调度主链；2、中台无 A/B 分组、策略比例、实验桶或备用策略；3、所有设备日志都进入同一策略标识。任一处可按比例切换两套通知规则即不通过。 |
| A02 | 没有竞品额外频控 | 前置：取客户端可识别配置 schema、中台可编辑字段及一次真实下发响应。 步骤：1、逐项列出实际频控字段及默认值；2、向测试响应额外加入 upper_limit=99、continuous_ntf_num=12、ntf_cooling_time=2、repetitions=3、max_visible_ntf=5 等参考字段；3、观察解析日志和实际展示。证据：schema/配置页、下发原文、客户端解析日志。 |
1、可执行控制只有三态、2 分钟轮询、POLLING / STATE 的单 ID 5 次/日和 15 分钟间隔、EVENT 单 ID 60 秒间隔；2、参考字段不出现在可编辑中台且客户端忽略；3、额外字段不改变候选、展示或冷却。任一参考字段生效即不通过。 |
| A03 | 2 分钟轮询、单轮最多 1 条 | 前置：通知权限开启，三态与来源匹配，同时准备至少 3 个合格周期/状态 ID，清空当日计数和通知栏。 步骤：1、记录调度器启动时间 T0；2、连续观察 3 轮调度，每轮记录候选数、选中 ID 和通知栏新增数；3、再把所有场景改为不合格后观察 1 轮。证据：4 轮带时间戳日志、通知栏录屏。 |
1、配置与日志中默认轮询值为 120 秒；2、在 App 进程可正常执行的条件下，不得在上一轮后未满 120 秒又执行新轮询（系统延迟可晚于 120 秒）；3、每轮新增可见通知为 0 或 1 条，绝不得≥2 条；4、无合格候选时日志明确记录“本轮无展示”。 |
| A04 | 周期 ID 与事件 ID 频控分开 | 前置：选 2 个周期/状态 ID（例如 12、10）和 2 个事件 ID（例如 14、15），所有条件持续合格并清空计数。 步骤：1、使 ID 12 成功展示，15 分钟内再进入该 ID，15 分钟后重试；2、在 ID 12 冷却期内触发 ID 10；3、使 ID 14 成功展示，60 秒内、满 60 秒后分别再触发；4、在 ID 14 冷却期内触发 ID 15；5、分别把 ID 12 与 ID 10 展示到第 5 次后再触发。 证据：每次触发时间、ID、展示/拦截原因、计数前后值。 |
1、同一 POLLING / STATE ID 成功展示后未满 15 分钟被拦截，满 15 分钟可再展示；2、不同周期/状态 ID 互不占用间隔和次数；3、同一 EVENT ID 未满 60 秒被拦截，满 60 秒可再展示；4、不同事件 ID 互不占用间隔；5、事件 ID 没有 5 次/日上限，周期/状态 ID 第 6 次必须被日上限拦截。 |
| A05 | 跨日清零、未展示不计数 | 前置：选 1 个持续合格的周期/状态 ID，准备可控测试时钟，设备时区和当地日期已记录。 步骤：1、使该 ID 在同一当地日期成功展示 5 次，第 6 次触发；2、把时间跨过当地 00:00后再触发；3、分别制造通知权限关闭、三态不匹配、数据失效三种被拦截候选，对比计数和上次展示时间。证据：跨日前后当地日期 key、计数、上次展示时间及拦截原因。 |
1、同日第 6 次被拦截；2、当地时间进入新自然日后该 ID 计数从 0 开始，其他 ID 各自独立；3、三种未真正展示情况均不增加当日次数，不写入/刷新上次成功展示时间；4、不得按 UTC 00:00 错误清零。 |
| A06 | 并发入口只调度一次 | 前置：至少 2 个候选 ID 合格，通知栏清空，准备任意两个可并发触发的恢复入口（例如 Service + Job）。 步骤：1、在同一秒内触发两个恢复入口；2、重复 5 轮，每轮前清空测试状态；3、记录入口调用次数、合并标识、候选检查次数和通知新增数。 证据：5 轮完整时序日志和通知栏录屏。 |
1、每轮两个入口都可被记录，但只生成 1 次候选检查；2、每轮最多新增 1 条可见通知；3、单 ID 次数最多只增加 1；4、不得因两入口各自启动调度而绕过 2 分钟轮询或频控。 |
| A07 | 竞品参考字段不进入执行 | 前置：准备 PRD 3.3.2 竞品 B 原始参数表、客户端配置模型、中台字段列表和执行日志。 步骤：1、对 ntf_switch / upper_limit / interval_time / ntf_m_on_* / continuous_ntf_num / ntf_cooling_time / start_time / end_time / repetitions / max_visible_ntf / os16_max_visible_ntf 逐项检查；2、确认每项在中台是否可配、在客户端是否可解析、在运行时是否参与判断；3、保留逐项对照结果。 |
1、上述字段只出现在历史/竞品参考文档；2、不出现在 Tidyvo 可执行配置模型、中台可编辑项或运行时判断中；3、找到任一字段会改变展示次数、间隔、时段或通知栏数量即不通过。 |
二、场景 ID 与模板#
| 编号 | 测试项 | 怎么测 | 通过标准 |
|---|---|---|---|
| A08 | 13 个周期 ID 与 4 个事件 ID | 前置：按 PRD 3.5.3 为每个 ID 准备“合格”与“不合格”数据各 1 组。 步骤：1、按 12→10→13→1→2→9→3→11→5→6→7→8→18 依次只放行 1 个周期 ID；2、对 ID 14—17 各触发 1 次对应本地事件，再用错误事件尝试触发；3、对每个事件分别制造三态、权限或数据拦截，之后等待 2 轮调度。证据：17 个 ID 的触发、候选和展示/跳过日志矩阵。 |
1、13 个周期 ID 顺序与 PRD 完全一致；2、ID 14—17 只响应各自对应本地事件，不进入 13 项周期循环；3、事件被拦截后日志标记当次结束，不存候选队列，后续轮询不补发该事件。 |
| A09 | 多场景与并发事件 | 前置：同时使 3 个连续周期/状态 ID 合格；准备 2 个可在同一秒回调的事件 ID。 步骤：1、记录游标后启动一轮调度，连续观察 3 轮；2、同时触发两事件并重复 5 次；3、并发结束后再独立触发之前未获锁的事件。 证据：游标、处理锁、候选和通知时序日志。 |
1、周期每轮只选顺序中第一个合格 ID，展示后游标移到下一 ID；2、其余合格 ID 只能在后续新轮询重新判断；3、每组并发事件只有第一个取得锁并执行候选，其余立即结束、不保存/排队/补发；4、后续独立新事件仍可正常候选。 |
| A10 | 周期场景使用真实数据 | 前置：为 ID 1、5、9、13 分别准备边界数据。 步骤：1、ID 1 分别用 0、1、2 个指定 Home 模块真实非 0 结果；2、ID 5 分别用 0、1 个 Private Space 有效文件；3、ID 9 分别用 0 B 与 >0 B 真实可清理量；4、ID 13 分别用无清理记录、有成功记录的数据；5、候选前删除文件或撤回权限后重试。 |
1、ID 1 只在有效扫描 24 小时内且至少 2 个指定模块真实非 0 时合格；2、ID 5 只在至少 1 个有效 Private Space 文件时合格；3、ID 9 只在真实可清理量 >0 时整组合格；4、ID 13 必须有成功清理记录，不得用安装时长代替；5、文件、权限或记录失效后跳过且不计数。 |
| A11 | 每场景 1—8 套模板 | 前置：取最终包内置模板数据和中台配置页/schema。 步骤：1、按场景 ID 导出模板 ID 列表并去重计数；2、检查是否有重复模板 ID 或第 9 套；3、尝试在中台新增、删除或修改模板。 证据：“场景 ID→模板 ID→数量”清单与中台截图。 |
1、每个场景数量为 1—8，无 0 套和≥9 套；2、模板 ID 在同一版本内唯一；3、中台没有运行时模板编辑能力，修改模板必须随 App 新版本。 |
| A12 | 整套随机、不跨模板混用 | 前置：选择至少含 2 套合格模板的场景，准备每套的主文案、CTA、路由、收起/展开 UI 和视觉元素映射表。 步骤：1、在规则允许的测试时钟下独立触发 20 次；2、每次记录模板 ID 并核对六类绑定元素；3、检查是否存在权重、轮播游标或“上次已选不再选”状态。 |
1、20 次每次都只产生 1 个模板 ID，且全部可见与路由元素都属于该 ID；2、无跨模板拼接；3、随机范围只包含当时合格模板；4、不因本次样本分布不均判失败，但实现中不得存在权重或顺序轮播逻辑。 |
| A13 | 收起与展开通知 UI | 前置：至少抽取 3 个不同场景、每场景 2 套模板；系统通知栏支持收起/展开。 步骤：1、逐条截取 320×80 收起态和展开态；2、核对主文案、CTA、视觉主题和模板 ID；3、分别重新生成通知，一次点主体、一次点 CTA；4、程序统计全部英文 CTA 可见字符（空格计入）。 |
1、同一模板收起/展开的主文案、CTA、主题和路由一致；2、收起为小 CTA，展开为同文案的大 CTA；3、主体和 CTA 均经同一广告链路进同一目标页；4、全部英文 CTA ≤10 个可见字符；5、收起主文案无截断、重叠或越界。 |
| A14 | 当前 UI 只显示英文主文案和 CTA | 前置：取最终包的全部内置普通通知模板，设备分别切换英文、中文及其他 1 种系统语言。 步骤：1、对全部模板做静态字段检查；2、每种系统语言至少展示 3 条普通通知；3、检查收起/展开态和 Android 降级样式；4、检查中台是否存在 12 语言模板配置。 |
1、产品可见区域只有 1 条英文主文案 + 1 个英文 CTA；2、没有独立标题+正文形成第二条可见文案；3、非英文系统语言下也不展示中文或其他本地化通知 UI；4、中台无 12 语言通知模板配置。 |
| A15 | 状态模板与动态变量 | 前置：准备可控的扫描/清理时间、其他 App 通知数、大文件字节数和系统低存储状态。 步骤：1、分别设置 23:59、24:00、47:59、48:00 小时边界；2、设置通知数 0、1、2；3、设置大文件 30 MB 以下、等于 30 MB、高于 30 MB；4、切换 Android 低存储开/关；5、删除或损坏变量来源。 |
1、达到 PRD 对应阈值时才进候选；2、天数按完整 24 小时向下取整；3、英文严格使用 1 Day / N Days、1 Notification / N Notifications；4、30 MB 和低存储判断与真实字节/系统状态一致；5、变量缺失时该动态模板不入池，通知不出现 {...} 或虚假数字。 |
三、中台三态与 FCM Topic#
| 编号 | 测试项 | 怎么测 | 通过标准 |
|---|---|---|---|
| A16 | 中台只有三态控制 | 前置：使用有通知配置查看/编辑权限的中台账号，准备配置接口响应或发布记录。 步骤：1、查看通知配置列表、新建/编辑页和权限菜单；2、展开三态字段的全部选项；3、检查接口 schema 和一次发布记录；4、搜索场景、文案、模板、频控、路由及“全量”类配置。 证据：配置页录屏、schema/响应脱敏截图。 |
1、可编辑业务字段只有 notification_audience_mode；2、枚举值只有 OFF / ORGANIC_ONLY / PAID_ONLY，不存在 ALL / ON / ENABLED 或“全量开启”；3、中台无场景、文案、模板、频控、路由配置页或隐藏字段；4、发布后客户端读到的值与中台一致。 |
| A17 | 三态受众正确 | 前置：自然量、推广、无法归类 3 种设备/测试状态，各自至少 1 个合格通知候选，通知权限开启。 步骤：1、分别设置 OFF、ORGANIC_ONLY、PAID_ONLY；2、每种状态下让 3 类设备各进入 1 次周期调度和 1 次事件候选，共 18 个子场景；3、记录中台值、本机来源、放行/拦截和展示结果。 |
1、OFF：3 类设备的周期与事件候选全部被拦截；2、ORGANIC_ONLY：仅自然量放行；3、PAID_ONLY：仅推广放行；4、无法归类在三种状态下均不下放；5、被拦截候选不计数、不刷新间隔。 |
| A18 | 统一 Topic 与 Token 边界 | 前置：3 类来源设备均从全新安装或清除应用数据开始，可抓取脱敏客户端网络请求和业务中台请求日志。 步骤：1、3 类设备完成首次启动并记录 Topic 订阅结果；2、切换来源后重启，检查是否退订/改订其他 Topic；3、查看全部业务中台请求体、账户绑定和数据库字段；4、检查实际空消息 payload。 证据：Topic 订阅日志、脱敏请求清单、payload 截图。 |
1、所有客户端始终只订阅同一个唤醒 Topic，来源切换不改 Topic；2、无自然量/推广专用 Topic；3、业务中台请求、账户和数据库均无 FCM Token 上传、绑定、保存或查询；4、空消息不含 title/body、通知 ID、模板 ID、路由或用户数据。 |
| A19 | Topic 空消息先判断受众 | 前置：三类来源设备均订阅统一 Topic，通知栏已清空；准备 OFF、匹配、不匹配三类组合。步骤：1、每类组合各发送 1 条 data-only 空消息；2、记录 FCM 收到时间、当前三态、本机来源、受众判断、是否进入恢复/调度；3、观察通知栏和广告日志。 |
1、每条空消息本身均不产生系统可见通知且不触发广告；2、日志顺序为“收到消息→读取三态→读取本机来源→判断”；3、仅三态与来源匹配时进入恢复和本地调度；4、OFF、不匹配及无法归类均在受众判断后结束。 |
四、后台恢复边界#
| 编号 | 测试项 | 怎么测 | 通过标准 |
|---|---|---|---|
| A20 | 多路后台恢复共用入口 | 前置：进程可运行，三态匹配，至少 2 个场景合格，清空调度和频控状态。 步骤：1、分别单独触发前台 Service、快速 Job、18 分钟 WorkManager、24 分钟持久 Job、8 小时 Alarm、开机广播、升级广播；2、每次记录入口名、统一恢复方法和调度器实例标识；3、选任意 3 个入口在同一秒并发触发；4、在同一 ID 冷却期内重复上述操作。 |
1、7 个入口都只进入同一恢复函数/调度器，不在入口内直接创建可见通知；2、单独触发可恢复调度能力；3、并发触发只合并成 1 次候选检查；4、任一入口都不能绕过 120 秒轮询、单 ID 15 分钟间隔或 5 次/日上限。 |
| A21 | Force Stop 不承诺拉活 | 前置：App 已完成 Topic 订阅和后台任务注册，记录强停前日志。 步骤：1、从系统设置点击“强行停止”，不再打开 App；2、发送 Topic 空消息，并分别等待原定 Job / Work / Alarm 时点；3、记录进程、日志和通知栏结果；4、用户手动重新打开 App，检查初始化和后续调度。 |
1、强停后若未唤醒，测试结果记“未唤醒”，不得写成 FCM / Job / Alarm 拉活成功；2、产品文案、日志名称和验收报告均不得出现“保证拉活/强停后必达”；3、手动重开后能恢复三态、Topic 和统一调度器初始化，不补发强停期间的过期事件。 |
五、通知点击、广告与分类#
| 编号 | 测试项 | 怎么测 | 通过标准 |
|---|---|---|---|
| A22 | 广告后正确路由与数据边界 | 前置：选择至少 3 个不同目标路由的可见通知，可控广告为正常关闭、加载失败、展示失败、无填充，并能制造无效路由。 步骤：1、对每个目标路由分别执行广告正常和一种异常；2、再用无效/不可达路由点击 1 次；3、抓取广告请求和通知埋点的脱敏字段名；4、记录点击、广告结果、最终页面时间序。 |
1、广告正常关闭、加载失败、展示失败和无填充后都只进入该通知原定目标页 1 次；2、无效路由只回退 Home，不崩溃、不白屏、不循环跳转；3、请求/埋点只可含 PRD 允许的分类、ID、模板 ID、时间、广告结果和来源类型；4、不含媒体名称/URI、联系人、其他 App 通知正文、FCM Token 或 Topic 成员明细。 |
| A23 | 只有四类可见通知 | 前置：分别准备普通、常驻、通知清理、FCM 定时通知的真实展示条件，同时发 1 条 Topic 空消息。 步骤：1、逐类触发并记录通知栏样式、产品内名称、channel/category 和埋点分类；2、检查客户端枚举与中台配置；3、搜索 ad_ntf；4、确认 Topic 空消息的通知栏结果。 |
1、产品可见分类恰好为普通通知、常驻通知、通知清理通知、FCM 定时通知四类；2、无第 5 类可见通知；3、ad_ntf 不得作为产品枚举、频控分类或对用户名称；4、Topic 空消息不在通知栏出现。 |
| A24 | 四类通知只触发一次广告 | 前置：四类可见通知均可点击，广告测试环境可切换“正常关闭/加载失败/展示失败/无填充”。 步骤：1、执行 4 类通知 × 4 种广告结果，共 16 个子场景；2、每次从全新通知开始，只点击 1 次；3、记录点击事件数、广告请求数、展示尝试数、广告结果和目标页打开数。 |
1、16 个子场景每次都只产生 1 条通知点击事件和 1 次统一广告链路；2、不得因通知主体与 CTA 同时绑定而双重请求广告；3、4 种广告结果都最终只打开正确目标页 1 次；4、广告异常不阻塞路由，不二次重试广告。 |
| A25 | Topic 空消息与 FCM 定时通知分开 | 前置：设备订阅统一 Topic；在 FCM 后台建立一条带唯一标题、正文、发送时间和目标页的可见测试通知。 步骤：1、先发 Topic data-only 空消息，观察通知栏和广告日志；2、再等待 FCM 定时可见通知到点；3、核对标题、正文、实际到达时间和路由；4、点击定时通知并记录广告与目标页。 |
1、Topic 空消息不生成可见通知、不触发广告、不使用后台 title/body/route；2、FCM 定时通知按后台配置形成可见通知，标题、正文和目标页一致；3、发送时间按 FCM 实际投递能力记录到达偏差，不将网络/系统延迟误判为本地轮询；4、点击定时通知时只走 1 次统一广告链路。 |
| A26 | 竞品技术标识不变成产品规则 | 前置：取客户端通知分类枚举、本地记录字段、埋点字典、频控配置和产品 UI 名称。 步骤：1、全局搜索 normal_ntf / res_ntf / filter_ntf / ad_ntf；2、逐个确认它们出现的文件、字段和运行时用途；3、触发普通、常驻、通知清理通知，记录产品分类和频控结果。 |
1、normal_ntf / res_ntf / filter_ntf 只可作为竞品对照说明或内部兼容映射，对应产品分类仍是普通/常驻/通知清理；2、不得因技术标识新增产品可见分类、独立日上限、间隔或通知栏数量限制；3、ad_ntf 不得成为 Tidyvo 产品分类；4、日志/埋点若为内部技术兼容保留标识，必须能明确映射回四类产品分类且不改变执行规则。 |
建议验收顺序#
先完成 A16—A19（三态与 Topic），再完成 A03—A06（调度与频控），随后完成 A08—A15（场景和模板），最后完成 A20—A26（后台恢复、广告和路由）。需要日志或中台证据但当前无法查看的项目，状态请选择“阻塞”，不要直接选择“通过”。