https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502我们的上一篇推文《AI赋能兼容性测试的探索之路--平台篇》介绍了手游兼容性测试的背景和基本流程。仔细分析整个兼容测试流程，我们总结了以下3个兼容性测试流程中的难点：
1、目前市场上手机多种多样，不同厂商品牌也有各种不同配置的机型，要在这些设备上快速运行兼容性测试是一个难题。
2、游戏应用为了吸引用户，会设置各种各样的玩法，不同的玩法有不同的场景，场景与场景之间的跳转关系复杂，如何遍历到这些场景从而发现兼容性问题也是一个难点。
3、由于兼容性问题种类复杂繁多，不同种类问题的表现形式都不相同，而且不同游戏之间的风格差异也很大，因此很难找到一个通用的模型来对不同的异常情况进行判断。
为了解决这三个难题，网易伏羲与网易雷火测试中心一同研发了一个用于检测UI异常的智能兼容性测试框架：
整个兼容性测试框架包括三个部分：云真机平台、游戏场景遍历模块和异常图像识别模块。第一块是云真机平台，这块功能主要是对手机集群进行统一管理，具体的实现思路在平台搭建篇已经详细介绍过，感兴趣的读者可以去上一篇推送或在文章末端推荐文章处翻阅。第二块是场景遍历模块，它主要负责UI提取、控件选取和智能脚本生成。第三块是图像异常检测模块，它能监控手游运行过程中手机界面的屏幕截图，找出其中的异常界面并分析其中的异常区域。
01 场景遍历
游戏测试本质上是检测软件代码在硬件上执行的结果与预期是否一致，因此想要在不同设备上检测手游的兼容性，就需要尽量让所有的代码都被执行到。目前手游中常用的遍历工具是Monkey工具，之所以叫Monkey，是因为它就像一个啥也不懂的猴子在屏幕上进行像素级别的随机点击。
Monkey工具的优点是他不需要任何的先验知识就能进行场景遍历，但是由于目前手机分辨率都是在百万以上，像素数量巨大，直接在像素级别进行随机点击有很大概率点击到一些非控件区域，这就造成了大量的无效点击，导致测试效率低下。
此外，Monkey工具也可能会点到一些系统内置按键，比如home键、wifi开关等，这样会让移动设备处于断网状态或者应用后台，导致整个测试流程被中断。
1. UI识别
基于Poco SDK的UI检测流程
基于上述原因，我们在场景遍历模块中开发了UI识别模块。首先我们会让游戏项目方在包体内打入Poco SDK，借助Poco工具，我们就可以获取到游戏界面的布局树信息，树内的每一个节点都与界面上的控件一一对应。在得到场景的布局树后，首先我们会根据控件的类别初步筛选出一些可交互的控件，比如Button, Toggle, Tab等，而类似Layout, Framework布局类的组件会被过滤丢弃。经过一层粗筛后，一般来说我们得到的控件总数是远远多于界面上可交互控件数量的，这是由于软件弹出一个新界面时，老界面并不会被直接销毁，而是会被隐藏到新界面的下层，因此我们根据Unity控件层级关系进行进一步筛选，最后只留下顶层的UI，下图中右下角的蓝色框即为筛选结果。
基于计算机视觉的目标识别方法
借助Poco SDK提取界面的UI信息有一个缺陷就是需要产品方接入Poco SDK，有一定的接入成本，为了方便游戏项目组能够快速接入到我们的兼容性测试服务，我们目前正在尝试使用计算机视觉领域的目标检测算法直接识别游戏图像中的UI组件，具体方法是收集大量游戏场景截图，在截图上标注UI位置，然后借助这些数据训练目标检测模型（Faster RCNN/Yolo/SSD等），在测试阶段只需直接将界面截图输入到目标检测模型中，即可定位到可交互区域并识别出对应的控件类别。
由于UI数据集收集耗时耗力，且不同游戏风格差异巨大，所以目前目标检测算法的准确率和召回率都不是很高，有些关键控件无法被识别到，比如下图中右上角的返回按钮，这样会导致遍历算法在这个界面时永远无法返回上层界面，对测试效率造成一定的影响，因此基于图像的目标检测方法只是作为一个备选方案，并未正式启用，在后续计划中我们会继续优化图像检测算法，增加服务的通用性。
2. 控件交互算法
随机点击
在得到界面上UI控件的位置后，下一步就是如何选择UI组件进行交互，也就是在哪个区域进行点击操作，一开始我们选择了比较粗暴的方式：在控件级别进行随机选择，也就是说不同控件在任何时间下都是以同等的概率被选择到。
但是这样一来我们会发现两个问题：
1、某些未被激活的控件可能会被点击到，比如下图显示的三个按钮功能都未开放，如果一直在点击这三个按钮，就会在当前界面停留过久，从而降低测试的效率。
2、随机点击算法在两个UI较少且可以互相跳转的界面之间可能会不断地循环，也会对测试过程产生一定的影响。
强化学习点击策略
为了让整个遍历过程能覆盖更多的场景，我们引入了强化学习的算法，也就是会综合历史的点击情况来确定下一次点击的具体位置，它根据控件的历史访问次数来选择交互目标：具体的计算过程如下：
UI组件Ai 被选择的概率是Pi，目前已访问的次数记为Ci ，所有组件选择概率初始化值为:
当某一UI组件被访问后，该组件访问次数Ci=Ci +1，并且其概率更新为：
根据公式不难看出，当前界面下历史点击次数少的控件会在下一次点击中以更高的概率被访问到，反之，历史点击次数多的控件会以更小的概率被选择到，这样就能让整个过程尽可能多地探索到新的界面，也可以避免界面间的无限循环。
此外，由于目前游戏应用有日版本周版本月版本，不同版本需要进行的测试方法不尽相同，像日版本这种更新快，但是改动较小的版本，我们可能只需要执行冒烟测试，就是只要验证一些基础场景的正确性，而针对周版本月版本，这些改动较大的版本，我们就需要执行回归测试，也就是需要对整个手游的功能进行深度的测试。
针对这两种情况，我们提供了两种场景遍历模式：一种是快速场景遍历，也就是只覆盖一些基础界面，不深入去到与主界面跳转关系过于复杂的界面，比如下面这个场景：
因为这个场景有很多的开关按钮，这些开关的排列组合情况非常多，如果不快速跳出这个界面，就容易在这个界面停留过久，如果只是对日版本包进行测试，则会大大延长测试时间，另一种是深度场景遍历模式，与快速场景遍历模式相反，这种模式会仔细去探索界面下的各个子界面，这种测试模式运行时间较长但是能对整个包体进行充分测试，针对周版本或者月版本的包体，我们可以采用深度场景遍历模式来进行回归测试。来看一下我们场景遍历算法在产品上的执行demo：
图中蓝框是当前场景中所有被识别出来的UI控件，红框是UCB算法选定的UI控件，绿色点是点击位置，可以看出点击效率还是不错的，同时，有些无效控件会在后续的学习过程中慢慢被过滤掉。
3. 构建场景结构图
在进行场景遍历的同时，我们会记录下整个遍历过程，也就是记录下场景之间的跳转关系，根据这个跳转关系，可以构建出场景与场景之间的结构图。由于在测试过程中有些场景可能会出现多次（比如可能会多次返回到主界面），为了避免结构图的冗余，我们会先对场景进行去重，这里用到的算法是特征匹配算法，也就是提取图像的sift特征，如果两幅图像的sift特征相似度过高，则可以认为它们是一个场景。
利用游戏场景结构图，我们可以定义一些具体的任务，借助搜索的思想，即可生成指定任务的测试脚本，下面这张流程图即为测试脚本的生成流程：
02 异常检测
相较非游戏应用而言，3d渲染在游戏运行过程中会被频繁触发，这就导致了游戏应用的UI异常问题会比非游戏应用更为复杂，且表示形式并不固定，经过统计分析，UI异常在整个兼容性测试问题中的占比约为40%。
1. UI异常类别
花屏：这类问题主要是因为游戏在渲染场景的时候，相机的参数（相机开关或者clearflags）被设置为不恰当的值所导致的，
局部高光：这类问题产生的原因是gpu的计算精度不够，计算结果溢出所导致的
黑边：主要是软件没有适配一些特殊的手机分辨率所导致的
材质丢失：这是因为是游戏的资源文件格式存储异常或者读取过程出现了异常
异形屏遮挡：这类问题是因为异形屏的刘海/挖孔/圆角区域与UI控件发生了重叠，导致这些控件无法被点击到，从而对游戏功能产生影响。
这些UI显示异常不同于其他兼容性测试问题，一般不会体现在手机运行log中，也就是说即使出现了UI异常问题，软件并不会报错，而是需要有一定测试经验的人才能判断，因此我们借助AI技术来检测游戏运行时出现的UI异常问题，也就是训练一个神经网络分类器用于判断界面显示是否正常。
2. 数据增强
要训练一个神经网络往往需要大量的样本数据，包括正常和异常的样本，正常的图像样本十分容易收集，而由于历史积累的异常样本数量不足，而且大多数异常样本都是通过外置相机拍摄，这些图片会包含标注框和一些额外的信息（比如人的手），有的还会有摩尔纹且清晰度低，此外还有部分数据是动图，大部分难以直接用来训练神经网络。
因此有必要借助数据增强的方法来产生一些异常样本，我们用了两种方法：
第一种是分析bug report得到异常图像出现的根本原因，然后在包体内插入bug code从而生成异常样本。
我们用了三种bug注入方式，第一种是修改相机的缓存标志位，比如下图中的第一张图片这张图，我们直接修改相机的clearflag数值，就得到了帧叠加的异常图像，第二个是关闭某些相机，这样就会让场景中出现一些异常色块，第三个是添加不恰当的后处理特效，比如最下方这张图，通过添加后处理特效，就会造成屏幕上出现雪花斑点。
第二种是直接对图像数据进行修改从而生成额外的异常样本，比如我们图像的编码方式，这样会让图像帧数据出错，从而生成异常数据，也可以手动给图像添加色块以及噪声从而生成异常图像。
3. 训练异常检测模型
借助上述数据增强的方法，我们就可以在场景遍历过程中生成大量的异常样本，把这些异常图像与正常样本一同输入到一个神经网络中进行训练，就可以得到我们想要的异常检测模型，我们用到的网络就是一个传统的cnn分类器，类似这里的二分类器，神经网络的输入是我们的游戏截图，输出就是图片的标签，标签0代表图像正常，标签1代表图像异常。
在测试阶段，模块接收游戏运行过程中的手机截图，然后将图片输入到异常检测模型中，让模型判断界面显示是否正常，如果模型检测到某一界面出现了异常（花屏、高光、黑边等），就会将该界面记录下来，并对图像的异常区域进行分析并展现在报告中，比如下图显示了黑边问题和具体的黑边区域。
4. 异形屏遮挡检测流程
针对花屏高光这些异常问题我们可以直接将手机截图输入到异常检测模型中进行判断，而异形屏遮挡这类因物理遮挡所产生的问题无法通过手机截图来进行判断，也就是说直接对手机进行截图是无法看到异形屏刘海区域的，因此我们收集了现有异形屏手机的刘海/圆角/挖孔区域，然后在手机截图上人工添加异形屏区域，通过计算UI组件与异形屏区域之间的重叠面积来判断是否有异形屏遮挡异常问题。这个方法的关键点在于如何获取不同手机的异形屏区域，我们设计了如下方案：
首先我们将手机放到一个比较黑暗的环境下，打开一张纯白的照片，利用外置相机拍摄一张手机的全身照，然后借助计算机视觉的算法来定位手机，并获取手机的最小外接矩形框，接着将这个矩形框通过物理变换转换成一个横平竖直的矩形，做这一步的原因是我们在拍摄过程中无法保证手机是水平放置的，而且拍照时相机的抖动也可能会对手机屏幕的成像位置有所偏差。之后我们会对屏幕区域进行二值化，得到手机屏幕的01掩码，最后再让我们的测试人员在屏幕掩码上标注出刘海/挖空/圆角区域，得到该手机的异形屏数据并存放到数据库中。
在测试过程中，我们首先进行UI控件识别，方法与场景遍历模块中提到的识别方法（利用Poco SDK获取界面UItree再进行控件筛选）是一样的，接着会将手机掩码覆盖到截图上，然后判断UI控件的位置与刘海/挖空/圆角区域是否有重叠，如果重叠面积较大则可以认为当前场景有异形屏遮挡的问题。
03 实际效果&后续计划
在实际运行过程中，我们的方案检测出了黑边、材质丢失等多种兼容性问题。
虽然目前智能测试服务已在线上稳定运行且能应对大多数兼容性问题，但是目前我们的框架还不支持一些文字相关异常：比如乱码，文字重叠遮挡等，在后续的工作中我们会对这一块进行完善。此外，我们的服务对mmorpg这种游戏类型的支持并不完善，这是因为在mmo进行场景遍历的方法是需要操作角色进行移动、战斗才可以完成的，如何寻路到指定地点，战斗过程中采用何种战斗策略都是一个难题，在后续的工作中我们会对这些问题进行完善。
除了丰富整个服务的支持类型，我们在后续的工作中还将致力于提升整个流程的通用性。由于目前场景遍历模块需要借助poco sdk，对包体会有一定入侵性，因此我们会引入更多的图像算法，直接利用图像数据来检测UI组件的位置，从而提供无入侵的接入方式。同时，我们会提供简易的接入工具和调试工具，方便一些新游戏的接入。
行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群： 759968159，里面有各种测试开发资料和技术可以一起交流哦。
最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
1893
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
