软件上线前为什么必须做全维度兼容性测试？正规第三方机构怎么做？

系统内部测过了，功能都没问题，上线前还要专门做兼容性测试吗？

要，而且这件事越早做越省钱。原因很简单，内部测试通常只在“我们自己那台电脑”上跑，但用户用什么设备、什么浏览器、什么系统版本，从来没人能提前猜准。

兼容性测试

一、为什么“全维度”不是凑字数

兼容性在国标里其实是个挺窄的概念，主要讲三件事：共存性（跟别的软件装在一起、抢同一份资源时会不会打架）、互操作性（跟别的系统交换数据、调接口能不能通）、依从性（你宣称支持的环境和标准，是不是真支持）。但落到实际项目里，它拆出来的维度比很多人想的要多。

1.浏览器与内核：Chrome、Edge、Firefox、Safari，以及不同内核（Blink/Gecko/WebKit）对布局、日期控件、文件上传的处理差异。政企项目还得额外考虑老版本浏览器。

2.操作系统：Windows 各版本、macOS、Linux，服务器端还有中间件、数据库、JDK 的版本组合。

3.移动端：机型、分辨率、刘海屏、Android 厂商定制 ROM（权限管理、后台机制、推送各不相同）、iOS 版本。

4.网络环境：弱网、断网重连、跨运营商，很多“偶发报错”都是这儿来的。

5.第三方依赖：支付 SDK、地图、单点登录、Office/WPS 的导入导出格式。

6.共存场景：和客户现有系统部署在同一台服务器上会不会互相拖垮。

全维度不等于穷举所有组合，那不现实，也没必要。合理的做法是按用户真实分布做优先级矩阵：P0 核心流程覆盖主流环境，旧版本和边缘机型按需抽样。这点在评审会上说清楚，比堆一百页截图更有说服力。

二、不上线前做的代价是什么

兼容性问题有个特点：不影响功能逻辑，只影响一部分人。所以开发自测很难发现，测试同学用自己电脑也复现不了。但它爆发的时间点往往特别要命：上线第一天，某个领导用 Safari 打不开报表；或者验收演示现场，IE 上整个页面错位。

更麻烦的是修复成本。同样是布局问题，设计阶段改 CSS 是半小时，上线后改可能牵一发动全身，还要重新走发布窗口。移动端更惨，涉及原生代码或 SDK 版本的，发版周期直接按周算。

另外说一句实在的：现在不少项目的招标文件和入网规范里，已经把“提供第三方兼容性/适配测试结论”写成了门槛项。信创项目尤其明显，CPU、操作系统、数据库、中间件的适配清单要一条条对。这时候再补，时间根本不够。

三、正规第三方机构做兼容性测试，看这几条就够了

1. 依据标准是不是写清楚了。

国内主流的测试依据是 GB/T 25000.51-2016《系统与软件工程 系统与软件质量要求和评价（SQuaRE）第51部分：就绪可用软件产品的质量要求和测试细则》，兼容性那一章就是照着共存性、互操作性、依从性三个子特性来设计的。质量模型层面参考 GB/T 25000.10-2016，测试文档规范看 GB/T 38634.3-2020。行业项目还会有自己的行标，比如金融、医疗、政务各有要求，得提前问清楚用哪一把尺子。

GB/T 25000.51-2016

顺带提醒一句：标准版本和资质能力目录是会调整的（这几年 CMA 能力项目库就有变动），签合同前让机构把“依据哪个标准、盖什么章”写进委托单，别口头约定。

2. 资质看CNAS，但要问清章覆盖的范围。

有资质不等于资质覆盖了你要测的那一类。报告上盖的章对应哪些标准、哪些检测对象，是可以查的。投标或验收用的报告，这一步省不得。

3. 环境矩阵有没有作为附件列出来。

这是最容易糊弄的地方。一份靠谱的兼容性报告，应该明确写出测了哪些浏览器版本、哪些机型、哪些 OS，以及每个环境下的用例执行结果和缺陷记录。只写一句“经验证兼容主流浏览器”的，基本等于没测。反过来，如果你自己心里有数，比如甲方明确要求必须支持某几款终端，提前告诉我们，我们把它写进矩阵，别等报告出了才发现漏了关键项。

4. 过程留不留痕。

采样、执行、截图、缺陷、复测，每一步都要可追溯。评审专家翻报告，最爱看的就是缺陷列表和环境记录的对应关系。模板套出来的东西，一眼就能看出来。

5. 周期和复测怎么算。

纯兼容性专项，环境清单确定后一般几个工作日能出；如果同时要测功能、性能，尽量一次进场合并做完，省一轮排期。测出不兼容的地方要不要回归、收不收费，报价阶段就问清楚。

如果你手上已经有招标文件的技术要求、或者甲方给的适配清单，最好提前找我们定制需求，别等到上线前一周才找我们，兼容性问题是最好提前暴露的一类，早两周发现，开发改起来不疼；晚两周，就是赶着上线硬扛风险。

标签：上线测试、兼容性测试