观客云
直播开播提醒是否真的送到观众手里，不能只看后台有没有“订阅”入口。更稳妥的验收方法是用测试账号走完“看到直播信息—主动订阅—等待提醒—点击进入”的完整路径，再确认提醒对应的是正确场次。观客云资料介绍了小程序订阅直播间和开播提醒功能；具体模板、触发时点和当前端内表现，应以实际配置和测试结果为准。
先把提醒流程说清楚
先明确这次测试的直播间、计划开播时间、测试账号和负责核验的人。订阅提醒与群里转发开播通知不是同一件事：观众订阅的是某一直播入口的提醒，运营人员发送的群通知则是另一种触达。两条路径都可以作为服务安排，但要分别记录，免得把群消息被看到误认为订阅提醒已正常送达。
观客云的开播工具说明介绍，观众可以在小程序中订阅直播间，开播前收到提醒并进入观看。上线前先在当前版本确认订阅入口会显示在哪里、用户完成选择后页面有什么反馈，以及后台是否能查看相应状态。资料没有列出所有账号、设备与消息模板的适用条件，所以不要把单个测试账号收到提醒扩大为所有观众都会收到。
用测试账号走完整条路径
选择一个不会影响真实观众的测试场次，使用尚未订阅的测试账号打开直播入口，检查订阅操作是否清楚、是否需要用户主动确认，以及完成后页面是否给出明确状态。随后按实际设置订阅，再核对账号、直播间和预计开播时间，避免测的是旧场次或工作人员自己的管理员页面。
开播前，可以先用测试场次或当前允许的预览方式检查提醒链路。重点记录提醒出现的时间、账号收到提醒的页面、点击后到达的房间，以及房间是否仍处于预期状态。如果产品后台提供发送记录或订阅状态，就将后台记录与测试设备上的实际表现对照；如果没有记录，不要自行推断消息已到达。
区分未订阅、未收到和点不开
这三种情况需要不同处理。未订阅意味着观众没有完成订阅动作，应检查入口说明和页面反馈；已订阅但没有观察到提醒，应记录测试账号、设备、客户端、时间和场次，交由负责配置的人员核查当前订阅设置；收到提醒却不能进入，则需要检查链接目标、直播状态和观看权限。不要仅凭口头反馈把问题归为“消息延迟”。
测试至少保留一条正常路径和一条失败路径，并写清复测方式。若订阅提醒出现异常，可以按业务允许的渠道补充开播通知，同时在记录中注明补充触达；不要把补发通知算成订阅功能通过。涉及真实用户时，尊重用户在页面上的选择，不用测试流程替用户完成订阅。
发布前留下可复查的结果
把直播间名称、测试时间、测试账号标识、订阅状态、提醒到达情况和点击结果整理在一张简短记录里。敏感账号信息只交给需要处理问题的人。最后由不参与配置的同事按照记录重新操作一次，确认说明足以让他人复现。这样发现问题时，团队能判断是订阅入口、场次设置还是进入房间的链路需要调整。
观客云介绍的功能可以作为验收起点，实际消息能力仍应按当前账号配置、微信小程序端和测试记录核实。需要同时覆盖没有订阅的观众时，应另行设计合适的开播告知方式；不要把订阅提醒当成覆盖所有人的群发通知。