先从机构实际使用的设备列测试范围
跨平台兼容性不必先比较开发框架或设备市场份额，先把门店每天真正使用的终端列出来。清单可以包含前台电脑、咨询人员手机、门店平板，以及机构允许使用的系统版本和浏览器。每个终端标明岗位、使用地点、网络条件和常用任务。测试范围来自机构的真实设备，而不是供应方演示时准备的几台样机；无法覆盖的老设备或特殊环境，应明确记录为尚未验证。
先让不同岗位使用测试账号登录，确认账号切换、退出、密码找回和权限是否符合机构安排。再选择常见工作任务：查找一条虚构预约、录入联系事项、更新改期状态、查看待办并交接给下一岗位。每个任务分别在电脑、手机和平板上完成，核对字段是否完整、按钮是否容易误触、保存后再次打开内容是否一致。不能只看首页能否打开；真正的兼容性要看关键操作能否完成并留下可追溯结果。
把高频表单和附件单独跑一遍
表单测试时，记录必填项、较长备注、不同长度的姓名和特殊字符，看看输入、保存、搜索和再次编辑是否正常。涉及日期和时段的字段，要核实显示格式、时区或日期跨天时的含义是否容易看错；不要因页面显示不同就直接认为数据错误，先用同一测试记录在不同设备间核对实际值。若业务需要查看图片或附件，只用虚构素材验证上传、预览和权限，不要为了兼容性测试上传真实顾客影像或诊疗资料。
屏幕大小、软键盘弹出、横竖屏切换和网络状态都可能改变员工完成任务的方式。让实际使用者按日常姿势操作一次，记录页面是否遮挡关键字段、返回后是否丢失输入、重复点击是否生成多条记录、上传中断后能否识别当前状态。问题描述应包括设备型号、系统版本、网络、操作步骤、预期结果和实际结果，避免只写“手机不好用”。
异常状态是验收的一部分
安排一次短时断网或网络切换演练，观察正在填写的内容如何提示，重新联网后记录是否需要人工核对。测试人员不要连续重复提交，先确认后台是否已经生成记录，再决定是否重试，避免把网络延迟误当成提交失败。若机构有临时手工登记流程，写清由谁保管、恢复后由谁补录、如何避免重复预约；不要假定软件支持离线工作，除非当前版本已实际验证。
还应测试账号过期、岗位权限变化和系统更新后的关键任务。某个功能在测试版本通过，不等于生产配置或更新后的版本也相同。每次修改设备范围、版本或网络设置，都应重新跑与业务相关的核心用例，保存日期、版本、测试人和结果。若手机端能查看但不能修改、或平板端表单布局不同，也应明确这是否符合机构工作安排，而不是把所有设备体验要求笼统写成“完全一致”。
建立可复查的兼容性验收记录
可以用一张表按“设备—岗位—任务—结果—问题—复测”整理证据。对核心流程设定通过条件，例如每个指定岗位能在约定终端完成查询和更新、改期信息在接手岗位可见、离开页面后记录仍可找回、异常时员工知道下一步。把通过项、待修复项、暂不支持项分开；供应方口头说支持但未实际验证的，继续标记待验，不记为通过。
修复后由原问题设备和另一台常用设备各复测一次，确认改动没有影响其他任务。问题仍存在时留存测试编号和可复现步骤，约定责任人和复查日期；涉及机构内部网络或设备设置的问题，也要分清由谁排查。跨平台验收不是追求所有界面像素完全一致，而是确认员工在已约定的设备环境中能稳定、清楚地完成实际工作，且关键记录不会因终端差异而丢失或误读。
最终的测试结论应注明覆盖了哪些设备、岗位、网络和版本，也要说明没有测试的范围。这样门店扩设备、换系统或更新版本时，管理者可以复用同一组任务做回归核对，不必重新依赖一次演示来判断能否使用。
问题要按原因分派，避免反复转述
测试发现异常后，先把问题分成账号权限、页面显示、数据保存、网络连接和设备配置几类，再由相应负责人跟进。员工提交问题时附上测试账号、终端型号、系统版本、发生时间、操作步骤和脱敏截图；涉及顾客信息的截图先遮掉姓名、电话及影像。管理者登记受影响岗位和业务任务，供应方反馈修复版本后，由原岗位按同一用例复测，并在记录中写明结果。这样可以区分偶发网络波动、设备设置差异和软件缺陷，也能避免同一问题在群聊里多次描述却无人确认关闭。
