欢迎来到
兼容性测试
定义
编辑
兼容性测试（Compatibility Test ，简称CT）是针对SUT（System Under Testing,被测试系统)的软件质量特性的兼容性进行的测试活动。主要是验证被测试系统是否可与其他软、硬件配合下正确地运作。IOS-IEC 25010中定义的兼容性是指被测试系统同时共享相同的硬件或软件环境时，系统或组件可以与其它产品交换信息、系统或组件，和/或执行其所需的功能的程度。这里面既包含了在与其他产品共享一个共同的环境和资源时，没有任何其他产品的不利影响情况下，产品可以有效地执行其所需功能的程度的共存性；也包含了两个或两个以上的系统、产品或部件可以交换信息，并使用已经交换的信息的程度的互操作性。
实践出处
编辑
兼容性测试主要来自《软件评测师教程》，对应检测依据兼容性来自ISO-IEC25010标准对于兼容性的描述。
为什么
编辑
任何一个软件系统的运行都是需要一些硬件和软件的配合的，那么硬件包含了CPU、硬盘、内存、网卡等等设备，软件包含了操作系统、数据库、中间件等一些基础服务，那么在这么多不同的条件之下，通过兼容性测试保障SUT都能够正确的运行，顺畅的交互，就是兼容性测试的目的。
何时使用
编辑
兼容性测试一般在集成测试阶段以后，正式上线之前完成，也就是说需要完成功能正确性验证之后，就可以进行兼容性测试的测试用例设计，然后进行兼容性测试了。
如何使用
编辑
兼容性测试的测试用例设计比较普遍的方法就是设计兼容测试矩阵。兼容测试矩阵需要先收集兼容因素。兼容因素是指影响SUT运行的硬件或软件环境。收集完成兼容因素后，利用正交试验的测试用例设计方法，每个兼容因素就是正交表的因素，每个兼容因素的个数就是对应的水平数，从而设计正交表后就可以得到兼容性测试矩阵了。
按照兼容性测试矩阵准备测试环境，然后在每个测试环境中运行SUT的主要业务流程的测试用例，来验证测试用例的结果。
假设我们统计的兼容性测试因素设计如下所示：
依据上面的兼容性测试因素，结合正交实验测试用例设计方法，我们选择按照因素水平，我们选择强度为2的正交计算后得到的如下正交实验的结果：
操作系统，分辨率，浏览器，
1,1,1,
1,2,2,
1,3,3,
2,1,2,
2,2,1,
2,3,4,
1,1,3,
2,1,4,
1,1,5,
2,1,6,
1,1,7,
2,1,8,
1,2,3,
2,2,4,
1,2,5,
2,2,6,
1,2,7,
2,2,8,
1,3,1,
2,3,2,
1,3,5,
2,3,6,
1,3,7,
2,3,8,
得出的兼容性测试矩阵如下：
这样我们就可以开始准备环境，然后选择被测试系统的主要业务流程，就可以进行兼容性测试了。
那么设计兼容性矩阵所需要的兼容因素一般如何得到的呢？通过如下的一些举例给出一些收集方案，Web或者APP的兼容因素的收集主要有如下几个方法：
-
客户的需求：任何一个系统，无论是PC端的还是移动端的，要支持的设备的需求都是从最终用户那里来的。那么我们兼容测试因素的一个来源就是需求，这个需要产品经理在和业务方收集需求的时候可以一起收集，但是这也是兼容测试因素的收集条件之一，虽然看似最合理，但是往往却很难拿到一个准确的答复。
-
埋点日志：很多已经上线的系统都有些前端埋点，我们可以从埋点日志中获取所有访问我们服务的终端信息，从而可以整理出一个访问我们系统的终端的类型，我们可以通过它获取我们当前的兼容因素来源之一，如果获取的种类特别多，我们往往会获取95%的终端类型，从而支持我们绝大部分用户，其他的就人齐自然更新设备了，这样就类似我们近似获取了2个西格玛的兼容指标。当然，如果一个系统是一个全新的系统，这一个获取方式就不起作用了。
-
其他服务：如果一个全新的系统，我们完全不知道怎么处理，那么浏览器可以通过https://gs.statcounter.com/ 获取当前占有量，从而来知道我们设计兼容因素。移动端可以通过搜索类似服务来为我们的兼容因素提供一些支持。
其他一些SUT的兼容因素可以模拟如上思路自行构造。
输出物
编辑
* 兼容因素 * 兼容性测试矩阵
参考资料
编辑
-
https://blog.csdn.net/crisschan/article/details/120182762
延伸阅读
编辑
正交表以及正交试验设计测试用例参考：https://blog.csdn.net/crisschan/article/details/127881580
关键词
编辑
兼容因素；兼容性测试矩阵
我们非常重视知识产权，我们在非常努力地寻找最初的出处来源并注明出处。但因为互联网信息浩瀚，难免会有疏漏。如果您觉得有侵犯您的权益，请联系我们。
导出兼容性测试.pdf
导出兼容性测试.docx
导出兼容性测试.pptx分享
