TG咨询应用能够下载、安装并打开，不等于交付完成。车载互联伴侣应用的远程交付验收用例，应验证用户能否从手机端走完关键流程，以及车辆、应用和网络异常时能否给出清楚反馈。下面六项测试可由远程验收人员按步骤执行；具体功能以待交付应用实际提供的能力为准。
先统一测试条件与判定口径
准备一台支持该应用的车辆、一部已安装应用的手机、可用的移动网络，以及一个按交付流程创建或授权的测试账号。记录应用版本、手机系统版本、车辆标识的脱敏信息和测试时间。每项用例都保存操作步骤、页面结果和时间点；涉及车辆操作时，车辆应停在安全位置，避免行驶中测试。
通过标准不应只是“没有报错”：预期结果要出现，异常时也要说明原因或下一步操作。若功能受车型、账号权限或网络条件限制，先把限制写进验收范围，不要把未提供的能力判为失败。
六项不能省略的验收用例
1. 安装后首次启动与账号登录
- 通过交付指定的应用分发渠道安装应用，记录版本号。
- 首次打开，按要求完成登录、条款确认及必要权限设置，再关闭并重新启动。
- 核对应用是否保持登录状态、关键页面能否加载，权限拒绝时是否说明受影响的功能。
验收关注安装包能否正常启动和进入服务流程，而非仅看图标是否出现。若登录依赖验证码，记录是否收到、是否能完成验证，不记录或传播验证码本身。
2. 车辆绑定与身份对应
- 按应用指引输入或扫描车辆识别信息，并完成要求的车主验证或授权。
- 退出后重新登录，检查绑定关系是否保留，车辆名称或识别信息是否对应目标车辆。
- 用无权限账号尝试访问该车辆，确认系统会拒绝或引导申请授权。
这项测试能发现“登录成功但绑错车”以及授权边界不清的问题。验收材料中的车辆信息应脱敏，避免暴露完整识别码。
3. 车辆状态同步与数据时效
在车辆停放、熄火等适用条件下，打开状态页，记录应用显示的门锁、续航或其他实际提供的状态及更新时间。等待一段合理时间后刷新，再与车辆端可核对的信息比较。不同车型与连接方式的更新速度可能不同，因此应依据产品说明或约定时限判断；若暂时无法取得新数据，页面应区分“数据未更新”和“状态正常”。
4. 远程指令的确认与结果反馈
只测试交付范围内且适合静止车辆的指令，例如应用确实支持时的远程空调启动。先确认车辆停放、账号有权限，再发出一次指令，检查是否有受理反馈、执行结果和失败原因。随后在网络受限条件下重复一次，确认应用不会把超时误报为成功。不要在道路行驶中发指令，也不要将门锁等安全相关操作用于无人看护的演示。
5. 通知与手机权限变化
如果应用提供充电、状态变化或指令结果通知，先在手机系统设置中允许通知，再触发一项可验证的事件，检查通知内容、到达顺序和点击后的页面。随后关闭通知权限，确认应用能提示用户前往系统设置开启，而不是把通知缺失误判成车辆故障。不同手机系统的后台限制会影响送达时机，验收记录应注明系统版本和权限状态。
6. 弱网、断网与恢复后的连续性
- 打开应用并确认页面可用，然后暂时关闭手机移动数据或进入信号较弱的环境。
- 尝试刷新状态或提交一项非安全关键操作，观察是否提示网络不可用、等待或超时。
- 恢复网络后重新进入页面，确认数据能否更新，失败操作是否被明确标记，避免重复提交造成歧义。
此项适合检验蜂窝网络中断后的恢复体验。不要把缓存中的旧状态当成实时数据；页面应提供更新时间或其他足以识别数据新旧的提示。
验收记录怎么写，才便于远程交付
每项记录至少包含：用例编号、前置条件、操作步骤、预期结果、实际结果、截图或录屏、版本与时间、结论及缺陷编号。测试账号和车辆信息使用脱敏标识。若问题可复现，补充发生网络状况、手机权限和车辆状态，不要只写“功能异常”。
上述车载互联伴侣应用的远程交付验收用例，将验证范围从“安装成功”延伸到绑定、数据、指令和故障恢复。按六项逐条执行并留存证据，才能判断交付是否真正可用，也能明确哪些差异来自产品能力、账号权限或现场条件。
常见问题
没有真实车辆，能否完成验收？
可先做安装、登录、权限和页面检查；涉及绑定、状态同步与车辆指令的项目应标注未验证，不能据此宣布全项通过。
远程指令超时，是否直接判定失败？
先看应用是否准确提示超时、车辆是否收到指令及网络是否恢复。若结果无法确认，应记录为结果不确定并按安全流程核实，不应重复盲目操作。
截图里需要保留哪些信息？
保留页面状态、操作时间和版本等排查线索；账号、手机号、车辆识别信息及验证码应遮盖或删除。