定制软件合同怎样约定浏览器、手机型号和验收环境？

“兼容所有设备”既无法验证，也会把上线后的任何显示差异都变成责任争议。更可执行的约定是：依据真实用户和业务风险列出支持矩阵，分别说明哪些环境完整支持、哪些只保证核心任务、哪些尚未验证、哪些明确排除；每一项再绑定可复现的设备、系统、浏览器或 App 版本、屏幕与输入方式、网络、外设、账号和测试数据。验收看关键任务是否在约定环境中完成，而不是要求所有设备像素完全相同。

兼容矩阵只回答“在哪些环境中验证”。项目仍需另行定义每条业务流程的结果、严重程度和通过门槛，可结合软件项目验收标准怎么定？与为什么试运行不能只找一个超级用户？一起评审。

“所有设备”不是一个可测试的范围

同一个 Web 系统可能运行在 Chrome、Edge、Safari、Firefox、企业内置浏览器和 App WebView 中；同一款手机还会受到系统版本、字体大小、横竖屏、权限、网络和厂商改动影响。原生 App、小程序、扫码枪、打印机、相机、蓝牙与企业安全策略又会增加新的组合。

因此，“兼容所有浏览器和手机”至少缺少六项边界：

1. 谁在使用： 顾客、门店员工、现场工程师、审核人员还是管理员；
2. 要完成什么： 浏览信息、下单付款、拍照上传、扫码、离线记录、批量导出还是设备控制；
3. 运行在哪里： Web、微信小程序、iOS、Android、企业内置浏览器或桌面客户端；
4. 具体版本与形态： 操作系统、浏览器/App 版本、屏幕尺寸、横竖屏与输入方式；
5. 外部条件： 网络、相机、定位、蓝牙、打印机、扫码枪、企业代理与单点登录；
6. 通过标准： 核心任务、数据结果、性能、可访问性和失败恢复怎样才算合格。

ISO/IEC 25010:2023 的公开摘要把产品质量模型用于需求定义、测试目标、质量控制和验收标准，但它不会替具体项目选择手机型号或浏览器。标准能帮助双方确认“兼容性属于需要定义和评价的质量属性”；实际支持范围仍要由用户、业务和运行环境决定。

先从业务覆盖率倒推设备清单

采购负责人不需要先背浏览器版本，而要先回答三类问题。

1. 哪些人和任务一旦失败就不能营业

支付、核销、接单、现场签到、上传维修证据、审批、退款和设备控制通常比营销页动画风险更高。先列关键角色和端到端任务，再找这些角色真实使用的设备；不要因为办公室电脑上能打开，就默认门店手机、仓库平板和客户旧机也已覆盖。

2. 现有用户实际使用什么

已有产品可从合规的访问统计、设备台账、客服问题和门店抽样获得浏览器、系统、屏幕与机型分布。新产品没有历史数据时，应从目标客群、企业采购标准、现场外设和原型测试形成假设，并在试点后校正。低占比不一定可以直接排除：负责付款、值班或关键审批的少量用户，业务风险可能很高。

MDN 的跨浏览器测试策略建议按目标受众的重要浏览器和设备确定测试范围，而不是尝试穷举全部组合；它还提醒，统计里没有某类用户，也可能是因为产品此前在该环境中不可用。这一方法适用于 Web 项目的覆盖决策，但不能替代企业自己的用户证据。

3. 哪些能力会改变兼容成本

普通查询与表单主要受布局、输入、上传和浏览器能力影响；拍照、定位、蓝牙、NFC、离线、后台任务、视频或专用外设会显著增加实机验证。若某项高风险能力只有少数设备真正需要，首期可收窄到明确型号或设备等级，不必让全部用户共同承担无限兼容成本。

用四级支持策略替代一句空承诺

建议把每个环境放进四级之一，并把级别写进需求、报价、测试计划和验收附件。

级别	承诺	适用情形	验收方式
完整支持	关键任务、主要交互、性能与可访问性达到约定标准	主流用户和高风险流程	自动化回归 + 代表性实机 + 业务场景验收
核心可用	核心信息和业务结果可完成，次要布局或增强效果可降级	老旧但仍有业务价值的环境	验证关键流程和降级说明，不要求视觉完全一致
尽力兼容/未验证	不主动阻断，但未纳入持续回归和正式承诺	低占比、未知或临时环境	记录已知结果；发现需求后另行评估
不支持	已知无法安全、稳定或经济地运行	过旧系统、私有浏览器、越狱/Root 或缺少必要硬件	给出升级、替代入口或人工兜底，不作为缺陷验收

MDN 的跨浏览器测试介绍明确指出，网站不必在所有设备上呈现完全相同的体验，但应与委托方约定可工作的浏览器和设备范围。对于 Web 新特性，MDN Baseline可以帮助了解主流浏览器是否普遍支持，却不覆盖旧设备、WebView、辅助技术、性能、安全或可用性测试。因此，“用了 Baseline 特性”不能直接等于“已满足合同兼容要求”。

支持矩阵必须写到能复现

一行“支持 Android 和 iOS”仍然太宽。每个代表环境至少应记录：

字段	示例写法	为什么需要
用户与任务	门店员工完成接单、扫码核销和退款申请	防止只测首页打开
产品与发布物	Android App 正式候选版、生产同版本后端	固定被验收对象
系统与版本	约定的 Android 主版本范围，另测当时最新公开版本	避免“Android”无限扩张
设备等级	代表性低/中档手机、门店指定平板、关键扫码设备	覆盖性能和硬件差异
屏幕与输入	小屏、横竖屏、系统大字体、键盘/鼠标/触控	发现布局和操作问题
浏览器或容器	Chrome、Edge、Safari、企业 WebView 的明确版本策略	区分不同运行内核与更新方式
网络与权限	正常网、弱网、断网恢复；相机/定位拒绝后再授权	验证失败和恢复路径
外设与组织策略	打印机、扫码枪、VPN、代理、SSO、移动设备管理	还原企业现场条件
数据与账号	脱敏代表数据、真实角色权限、第三方沙箱	保证结果可复核且受控
通过标准	结果正确、无阻断、可恢复，性能阈值另行约定	把“看起来正常”变成证据

版本范围可以采用“指定最低版本 + 当前稳定版本 + 目标用户中仍有实质占比的代表版本”，也可以按企业统一设备清单维护。没有一种固定的“最近两个版本”适合所有项目；自动更新的消费浏览器、受管控的企业电脑和多年不换的工业平板需要不同策略。

实机、模拟器和自动化各证明一部分

自动化适合持续发现登录、表单、支付回调、权限和关键流程被改坏；模拟器适合快速覆盖系统版本、分辨率和窗口变化；实机才能更可靠地暴露相机、蓝牙、性能、厂商系统、键盘、通知和弱网问题。三者不能相互完全替代。

Google 的 Android 核心应用质量指南建议用模拟设备覆盖常见形态，同时用少量代表性真实硬件验证目标用户的关键组合，并测试最新公开 Android 版本。该指南针对 Android 应用，不直接规定 Web、iOS 或小程序的验收范围；它支持的通用方法是“代表性组合 + 最新平台 + 实机关键路径”，而不是收集市场上每一款手机。

每个环境至少应跑三组场景：

1. 正常闭环： 从业务起点到订单、工单、审批或核销结果；
2. 边界与中断： 大字体、小屏、旋转、锁屏、来电、切后台、重复点击、弱网和断线重连；
3. 权限与异常： 拒绝相机/定位、令牌过期、外设断开、上传失败和第三方接口超时。

验收记录保留版本、设备、账号角色、步骤、预期与实际、截图或日志、严重程度和复测结果。只写“真机测试通过”无法在争议时复现。

可访问性不是兼容清单里的附加备注

如果用户可能使用键盘、屏幕阅读器、放大、语音输入或系统大字体，应把相应组合纳入完整支持或核心可用环境，而不是等到上线后再说“特殊设备不兼容”。WCAG 2.2提供可感知、可操作、可理解和稳健等成功准则，但 W3C 并不替项目指定要支持多少辅助技术组合。

因此，项目仍需记录实际使用的浏览器、操作系统、辅助技术和版本，并用代表性任务验收。通过自动扫描也不等于真实用户可以完成付款、预约、上传或审批。

合同要区分缺陷、变更和持续维护

兼容争议通常不是因为没有测试，而是没有提前约定事件属于哪一类。

事件	建议归类	处理原则
约定完整支持环境中，关键任务无法完成	缺陷	按严重程度修复并在同环境复测
核心可用环境中只有非关键动画或像素差异	已知降级	不阻断验收，前提是合同已写明
客户新增未列入矩阵的老旧机型或专用外设	范围变更	先评估可行性、成本、周期和风险
验收后平台升级导致行为改变	维护事件	按维护范围、响应等级和更新窗口处理
原先完整支持的环境被供应商停止安全更新	生命周期变更	提前通知，给迁移期、替代方案和退役日期
企业代理、浏览器插件或移动设备策略改变功能	环境变化	双方复现并确认责任界面，不直接归咎于页面

不要把“验收时支持”写成永久免费适配。合同应说明支持矩阵何时复核，例如重大系统或浏览器升级、平台规则变化、新机型/外设上线或用户结构显著变化；同时约定监控、问题分级、复现材料、修复窗口和退役通知。具体法律责任仍应由双方结合合同和适用法律审阅，本文提供的是可验证的项目边界，不是法律意见。

一个可直接评审的验收附件结构

采购方可以要求开发团队交付以下六项：

1. 用户—任务—环境矩阵，以及选择和排除每项环境的证据；
2. 完整支持、核心可用、未验证和不支持的定义；
3. 浏览器、系统、App/小程序、设备和外设版本策略；
4. 正常、弱网、中断、权限拒绝与恢复场景；
5. 自动化、模拟器、实机和辅助技术的测试分工及证据格式；
6. 上线后的监控、平台升级复测、兼容问题响应和环境退役流程。

滚水科技可以在定制 App、小程序和业务系统立项时，把真实用户设备、关键流程、外设和企业网络条件整理成支持矩阵，并把相同矩阵贯穿报价、开发、试运行、验收和维护。这样做不是降低质量，而是把预算优先投入会影响真实业务的组合，同时给未覆盖环境清楚、可执行的处理路径。

参考来源

• ISO：ISO/IEC 25010:2023 产品质量模型，用于需求、测试目标、质量控制和验收标准的质量模型；标准发布于 2023 年 11 月，访问于 2026-10-12。
• GOV.UK：Technology Code of Practice，用户需要、可访问性、开放标准、集成适配与生命周期原则；页面更新于 2025-07-07，访问于 2026-10-12。其政府采购适用范围不直接构成中国企业合同要求。
• MDN：Strategies for carrying out testing、Introduction to cross-browser testing与Baseline compatibility，目标受众驱动的浏览器矩阵、分级支持和 Baseline 边界；访问于 2026-10-12。
• Android Developers：Core app quality guidelines，模拟器、代表性真实设备、最新平台与核心流程测试；访问于 2026-10-12。
• W3C：Web Content Accessibility Guidelines 2.2，Web 可访问性成功准则及辅助技术支持边界；访问于 2026-10-12。