在游戏开发中，兼容性测试是确保游戏在各种硬件、操作系统和平台上正常运行的关键环节。兼容性测试不仅能够保证游戏在不同设备上的表现一致，还可以提高用户体验和扩大游戏的受众范围。本文将介绍兼容性测试的概念，探讨游戏常见的兼容性问题，并分享兼容性测试的具体流程，帮助开发者更好地理解和实施游戏兼容性测试。
看病就医，如果医生只是知其然而不知其所以然，只是根据病者表象开药，对症而不对根，即使病症好了，却无法保证是因为时间和环境等外部环境变化导致的暂时性的康复还是彻底解决了病症。做兼容性测试亦然，只有测试人员了解了什么是兼容性，才能够更好地分辨什么是兼容性问题，进而大致地定位兼容性问题，甚至能够在问题后续的修复中去判定程序的修复是否具有道理，能否彻底解决该问题等等。所以本章节将从兼容性的概念和应用程序的兼容性原理来简单谈谈何为兼容性。
1
兼容性的概念
2
应用程序的兼容性原理
在计算机之中，兼容性是指硬件之间、软件之间或是软硬件组合系统之间的相互协调工作的程度。兼容的概念比较广，相对于硬件来说，几种不同的部件，如CPU、主板、显示卡、屏幕等，如果在工作时能够相互配合、稳定地工作，就说它们之间的兼容性比较好，反之就是兼容性不好。
从某一软件的角度来理解，从设计之初即存在目标机器上的理想效果，用上文来说，这就相当于是朋友们友好相处的结果，应用程序兼容性就是指应用程序能否在不同的环境或内部系统变化中保持一致的友好相处结果的行为，而这种一致性则是设计人员所希望的理想效果。
应用程序和手机内部环境
内部环境的变化则是兼容性的核心，内部环境的组成则是该软件运行所依赖的硬件和软件。
对于移动游戏来说则是手机设备型号和操作系统，由于市面上手机厂商众多，设备五花八门，而且不同的型号还存在不同的硬件配置，再加上操作系统的多样，单单就android系统来说，安卓API及安卓操作系统的快速发展，以及原始设备制造商在其设备上部署的安卓操作系统的定制版本的存在，设备型号与操作系统的组合导致了应用程序存在大量可能的运行环境，使开发者在应用程序开发过程中面临十分严峻的挑战，所以想要完全发现和解决掉兼容性问题基本是不可能的。
国内2023年Android设备覆盖率
国内2023年Android小版本覆盖率
在讲如何进行游戏兼容性测试之前，我认为了解一些基本的兼容性问题，在测试中也会比较有底，对于之后的测试也会比较有帮助，所以大致列了几类在兼容性测试中所遇到的兼容性问题。
1
手机屏幕适配问题
UI缩进适配问题
一些游戏在UI设计之初即预留固定的UI缩进以盼直接一次性解决这类屏幕的缩进问题。但是这么做会有一些舍弃，就是一些非挖孔屏进游戏也会有一些缩进，整体UI会向中部靠近，如果屏幕较窄的机器，显示起来拥挤感会更加明显，甚至会有UI重叠的问题。在着手解决这类兼容性问题时，为了避免以上弊端，在android端给出了两个解决方案：
一是在玩家进入游戏时，客户端直接获取到设备的安全区，然后直接进行动态适配；
进入游戏获取设备安全区
二是对于一些因为种种原因无法直接获取安全区的设备则提供了配置表，当遇到这类机型可以将设备型号和对应的缩进比例填写进去，从而达到适配目的。这类手机毕竟是少数，就只能在兼容性测试中遇到一台处理一台了。
配表手动设置UI缩进
（2）缩进不正确导致UI异常
左右两侧未遮盖全
缩放后依然异常
2
视觉表现不兼容问题
这部分遇到较多就是关于不同平台对于浮点数、除0、初始赋值等的处理不同，从而导致的界面异常显示。
比如不同的设备平台浮点数精度会有差异，在Tonemap计算中可能出现NaNs值，当时版本的urp插件中stopNaN的后处理又将NaNs处理为黑色导致部分高亮区域的像素变黑，就会出现以下这种蚂蚁线的问题：
比如ZFight问题，部分机型上深度精度低，特效模型与地面重合：
这类问题乍一看都特别像是功能问题，以后在发现此类问题时，可以多留一个“心眼”，去定位下是否为兼容性问题。
3
稳定性相关的不兼容问题
这一类问题主要包括安装、闪退、黑屏、卡死等，都比较底层且原因多变，无法一一概括分析，所以以安装问题和闪退问题作为例子分享下如何定位和区分是兼容还是功能层面的问题吧。
（1）安装问题
如果要定性为兼容性问题的话，需要保证游戏包体能够成功安装到至少一个版本的android（iOS）平台或者手机上，而在另一个版本的android（iOS）平台或者手机上安装失败，则将其视为安装时兼容性问题。
（2）闪退问题
在测试过程中需要注意的是，一般这类问题都是某些程序逻辑与内部环境不兼容从而导致的程序崩溃闪退，但是在测试中也发现一些类似崩溃问题也容易被误认为是兼容问题。比如性能向的问题，游戏在运行过程中持续的高温高耗导致手机系统主动地杀掉进程；某一台手机本身的内存不足引发的游戏闪退等等，这类问题遇到时，最好是能够先通过查阅日志等初步判定区分一下。
解决问题的前提是需要这些兼容性问题能够尽早尽量多地暴露在开发者面前，于是就引入了在游戏开发环节中必不可少的一项专项测试内容，即游戏兼容性测试。但是漫长的研发周期中，面对如此复杂的设备和操作系统，在项目日常测试工作已经较为繁重的情况下，项目又应该在什么时候、使用什么方式去执行游戏的兼容性测试并最大范围地去发现这些兼容性问题呢？
首先需要明确的是兼容性测试涉及到庞大系统，大量手机，是不可能单单依靠某一个人能够完成的，所以一般是交由专门的部门负责测试，包含大量测试人员，每个人的理解也不同，测试习惯和对问题的理解深度也都不一样。作为项目组QA，就需要思考以下两个问题：一、应该怎样去组织和对接这样一场测试，让其能够最大程度满足我们的测试要求，发现尽可能多的问题；二、最后汇总的有限的测试信息和结果如何去高效地定位问题和跟踪解决问题。
接下来将介绍下笔者目前采用的兼容测试工作流程，逐一明确以上问题的解决办法。
1
兼容性测试准备
兼容性测试不是一蹴而就的工作，随着项目的研发，在不同阶段会有不同的兼容性需求。比如在UI频繁迭代后，需要着重关注的是游戏中的UI在不同的异形屏上是否都可以正常适配；在开发引擎更新之后，需要特别注意游戏在不同手机上运行时能否做到与其手机系统软件、硬件相兼容等等。所以每一次兼容性测试前都需要对不同的需求进行搜集并做好提测前的准备工作。为了便于理解，将本节内容总结如下图：
（1）测试目标的确认
在开展测试前必须搞清楚本次测试目标是什么，换言之，本阶段的兼容性测试具体要求是什么？兼容性测试要求一般包括本次着重需要关注的目标问题、出包的目标时间、包体应用的目标范围。
目标问题的明确才可以帮助我们洞察需求从而凝练出本次的兼容性测试用例。目标问题一般是根据项目的近期开发情况决定的，比如在UI频繁迭代后，我们就可以以UI适配作为目标问题编写用例和提测，功能逻辑的覆盖用例适当减少，可以适当减轻对其他兼容性问题的关注程度，这样一来也可以在有限的时间内缩短单台机器的跑测时间，从而屏幕种类和分辨率数量的覆盖量就可以增加。
（2）测试用例的准备
测试用例的准备是和目标问题紧密相关的，同时还需要考虑时间人力成本。
比如此次测试目标问题是游戏的稳定性，用例的制定就需要重点囊括易发生稳定性问题的步骤，比如登录CG、登录时第三方服务获取（用户中心、权限获取等）、视频播放、录像回放，以及性能高占比的功能，比如抽卡动画播放等等。
（3）测试环境的保证
测试环境包括测试包体、测试服务器以及测试账号。
测试包体需要提前确认提测的版本，需要结合测试目标考虑到内外网差异。建议专包专出，想测试第三方服务的兼容，就需要包体囊括所有的第三方服务内容，想测试游戏内普通的功能兼容性，可能简单的内网包体就可以满足需求。
然后根据本次兼容性测试要求，准备对应的测试服务器和测试账号。
在确认好包体和环境后，一定要使用提测的包体和环境完整跑一遍测试用例，保证功能没有问题，防止因为游戏功能自身的原因增加人天耗时。
2
兼容性提测
在正式提测前需要找到对应的兼容性测试团队的接口人，确认下他们的排期，当前是否有足够的人手和时间安排一次测试，项目可以根据他们的排期结合自己的时间动态调整跟进策略，约定好出测试报告的时间。
当确认好测试目标、准备好测试用例以及测试环境后就可以进行正式的提测。
提测后需要开一个测试问题跟进总单，在测试过程中对一些需要跟进解决的问题及时开出子单跟进，这样也是便于项目组各位同事后续直接查看该总单就能对本次兼容测试的情况进行大致了解，以及修复进度实时查看。
建议开出的bug单标题明确问题表现，描述需要贴上具体的测试机型，复现步骤等等，附件部分最好包括必要的图片、视频和log。明确的标题在遇到相同或者类似的兼容性问题可以帮助我们更加方便地找到之前的问题从而进行对比分析，详细的复现步骤可以帮助程序更好的理解问题，还可以防止修复时间与问题发现时间间隔太久，等到去验证时忘记如何复现从而难以判断问题是否的确完全解决掉。
3
兼容性测试过程
这部分主要是讲一下对于不同情况和类型问题的处理方式以及对于一个问题的基础判别。
（1）针对不同情况如何处理
不用记录的问题及时反馈
一些设定问题或者当前版本暂时不需要解决的已知问题可以直接告诉他们不用记录。比如：功能正在迭代中，大多数UI都是临时资源，但是我们提测时包含这个功能，主要目的是测试其稳定性，则需要提前告知兼容性测试团队，避免无效反馈。
紧急棘手问题及时开单
如果遇到严重并且可能难以解决的问题则需要及时开单，比如在测试过程中有闪退崩溃等问题，这种问题解决和定位是比较复杂的，且可能造成测试阻断，需要尽早开单处理。
不清楚的问题暂时记录
如果遇到一些拿不准是否为兼容性的问题并且不紧急的问题也可以先记录下来，保留相关视频、图片等，以便之后筛查是兼容性问题还是功能bug。
（2）针对不同问题判别思路
单一的兼容性测试行为的构成包括：执行人员、执行设备、被执行软件、执行步骤、执行结果。往往都是从结果找原因，排除外界条件和影响，目的是定位被执行软件本身和设备平台导致的不兼容。
回忆一下第一章所说的应用程序的兼容性的概念，应用程序兼容性就是指应用程序能否在不同的环境或内部系统变化中保持一致的行为。游戏的兼容性是开发组在目标机器上研发效果，同一个版本移植到了不同的手机和操作系统之中，出现了与目标机器上不一致的表现，这类问题才能被称作兼容性问题。
兼容性测试过程中需要学会判别、定位是否为兼容性问题，常见的误判有以下几种：
测试的设备本身的原因
排查是否是测试设备本身导致的不兼容表现：比如设备本身的内存不足、设备的配置本身不足以达到能够运行对应软件的条件等。
功能层面问题
一些比较明显功能层面的问题，能够直接进行判别，一般来说功能执行响应、反馈结果这个流程都是属于功能逻辑，逻辑执行过程中存在兼容性问题那最常见的应该是运行崩溃（卡死闪退等等）问题而不是结果异常，如果结果异常一般是功能向的问题而非兼容问题。
测试人员操作和对兼容性问题误判
（3）信息的保存与问题现场的保护
4
兼容性测试完成后
（1）兼容性问题筛查
（2）兼容性问题重要级分类
对于兼容性问题重要级以某次报告的相关问题为例子，主要用以下准则进行判定：
1）本次测试目的：排查稳定性的问题，准备对外测试
2）问题的复现概率
3）问题的严重程度与覆盖机型的数量
如果是稳定性相关的必现问题就可以设置的中级以上，是否设置为高优先级问题则需要考虑覆盖机型数量和是否为阻断问题了。
（3）兼容性问题指派
问题的指派一般需要根据问题的大致分类去判别，较为精准的指派节约了问题流转的时间，提高了问题修复的效率。
对于模型、特效的问题都可以开单找TA或者负责引擎渲染等逻辑的程序；
UI上的适配问题可以开单找具体功能负责的交互；
稳定性问题可以找负责引擎的程序进行初步排查，因为通常涉及底层的问题，需要他们帮助我们去具体定位一下；
一些不确定的客户端问题可以联系一个固定的客户端程序进行分配，先将问题暂时指派给他，然后麻烦其帮忙及时分派下程序跟进。
（4）兼容性问题解决与验收
必须清楚的是，开出BUG单以后并不意味着兼容性测试的结束，这只是开始。如何推进程序进行问题的解决，以及后续的问题验收才是关键。
对于必现问题，程序修复后最好使用问题设备再复现几次确保没有问题后再关单；非必现问题，需要找程序了解原理，以及修复涉及的范围，让其提供复现思路；如果是无法复现的问题，review程序修改内容确认其是否合理，然后再关单，与此同时同步至修改可能涉及的功能层面的QA，让其在平时测试时留意其表现，一旦发现异常，及时反馈。
如果已经确认无法解决的问题，则做好备忘和记录。
（5）兼容性测试完成后
在完成一次完整的兼容性测试后，需要思考的就是如何在下一次测试中能够最大程度的覆盖更多的问题呢？
根据测试结果完善测试用例和兼容性checklist。比如之前切后台经常会遇到卡住问题，就可以将切后台作为一个常驻用例写入自己的兼容性测试用例里面。
平时也可以留意功能层面的需求，不断搜集一些可能存在兼容性问题的点，在下次兼容性测试中覆盖测试到。
04 结语
兼容性测试是贯穿游戏开发和运营整个时间维度的专项测试内容，只要游戏在更新、在输出新的内容，那么就都不能懈怠。同时市面上的机型和操作系统也是随时在更新迭代，兼容性问题没有确定的原因，也没有标准的跟进办法，你永远不知道会在游戏的哪一块地方出现问题，测试团队需要持续跟踪各类兼容性测试条件的变化，及时更新测试环境、测试设备与测试用例，才能更好地保证兼容性测试的有效性与意义。
推荐阅读
都看到这里了，点个赞再走吧~
