CN111813693B - 一种软件兼容性检测方法、智能终端及存储介质 - Google Patents

Abstract

本发明公开了一种软件兼容性检测方法、智能终端及存储介质，所述方法包括：获取待检测的原始软件，并对所述原始软件进行埋点的预处理，生成测试软件；控制所述测试软件运行预先生成的常规测试用例，并生成各个所述常规测试用例对应的运行日志；根据所述运行日志中是否存在目标API，对所述常规测试用例进行筛选和加工，生成兼容性测试用例；根据所述兼容性测试用例，对所述测试软件进行兼容性检测。本发明能够有效提高软件的兼容性检测效率。

Description

一种软件兼容性检测方法、智能终端及存储介质

技术领域

本发明涉及计算机信息技术领域，尤其涉及一种软件兼容性检测方法、智能终端及存储介质。

背景技术

安卓系统是基于Linux内核研发的移动操作系统，由于它的开源性，大量的厂商在原生的安卓系统基础上开发不同的定制版本，以吸引客户。而开发定制版本会修改底层的系统，因此导致市面上安卓系统碎片化严重。市面上有来自1200多个制造商的24000多种不同设备。此外，随着安卓系统的更新换代，市场上常见运行的应用程序编程接口(Application Programming Interface，API)版本有很多种，而且不同的软件调用的API数量巨大，统计发现仅仅是API版本28的软件开发工具包(Software Development Kit，SDK)的源代码中就有220000多个方法，而开发人员在开发一款新软件时，为测试该软件是否在客户的终端正常运行，必须事先在各个不同的版本的系统和终端上进行检测，并验证是否能够正常调用API和工作正常。

为解决这一技术问题，研究人员推出了许多用于静态分析软件兼容性的软件，例如FicFinder和CiD，但由于静态分析的局限性，在检测过程中会出现许多错误报警。因此又有人提出了一种动态检测方案，称之为自动化兼容性测试，通过开发的软件在不同设备和不同版本的应用程序编程接口(Application Programming Interface，API)重复执行测试，也就是重放，以识别不一致的地方，从而实现对该软件兼容性的测试。但是由于前文所述的设备型号、API版本数量和需要测试的API调用点的数量非常庞大，因此目前的动态检测方案的实用性较差，在真正检测时会消耗大量的人力、时间和金钱。

发明内容

本发明的主要目的在于提供一种软件兼容性检测方法、智能终端及存储介质，旨在解决现有技术中安卓软件兼容性检测时检测效率低问题。

为实现上述目的，本发明提供一种软件兼容性检测方法，所述软件兼容性检测方法包括如下步骤：

获取待检测的原始软件，并对所述原始软件进行埋点的预处理，生成测试软件；

控制所述测试软件运行预先生成的常规测试用例，并生成各个所述常规测试用例对应的运行日志；

根据所述运行日志中是否存在目标API，对所述常规测试用例进行筛选和加工，生成兼容性测试用例；

根据所述兼容性测试用例，对所述测试软件进行兼容性检测。

可选地，所述的软件兼容性检测方法，其中，所述获取待检测的原始软件，并对所述原始软件进行预处理，生成测试软件，具体包括：

获取待检测的原始软件；

对所述原始软件中的目标API进行插桩，生成中间软件；

对所述中间软件进行签名，生成测试软件。

可选地，所述的软件兼容性检测方法，其中，所述根据所述运行日志中是否存在目标API，对所述常规测试用例进行筛选和加工，生成兼容性测试用例，具体包括：

根据所述运行日志中是否存在目标API，将包含所述目标API的运行日志对应的常规测试用例作为候选测试用例；

将所述候选测试用例剪切，生成中间测试用例；

将所述中间测试用例添加用于获取屏幕界面的记录序列，生成包含所述目标API的兼容性测试用例。

可选地，所述的软件兼容性检测方法，其中，所述根据所述兼容性测试用例，对所述测试软件进行兼容性检测，具体包括：

控制所述测试软件在预先设定的测试设备池中运行所述兼容性测试用例；

基于所述记录序列，获取同一所述兼容性测试用例在所述测试设备池中的不同设备运行时的目标屏幕界面；

根据所述目标屏幕界面，确定所述测试软件对应的兼容性信息。

可选地，所述的软件兼容性检测方法，其中，所述兼容性信息包括所述原始软件是否存在兼容性问题及引发所述兼容性问题的原因，所述根据所述目标屏幕界面，确定所述测试软件对应的兼容性信息，具体包括：

根据所述目标屏幕界面，判断所述目标屏幕界面是否存在崩溃或闪退；

若所述目标屏幕界面存在崩溃或闪退，则确定所述原始软件存在兼容性问题，且存在崩溃或闪退的目标屏幕界面所对应的目标API为引发兼容性问题的原因；

若所述目标屏幕界面不存在崩溃或闪退，则根据所述目标屏幕界面之间的差异，确定所述原始软件对应的兼容性信息。

可选地，所述的软件兼容性检测方法，其中，所述若所述目标屏幕界面不存在崩溃或闪退，则根据所述目标屏幕界面之间的差异，确定所述原始软件对应的兼容性信息，具体包括：

计算各个所述目标屏幕界面之间的相似度值；

根据所述相似度值，判断所述目标屏幕界面中是否存在满足预设的差异判断规则的差异屏幕界面；

若是，则确定所述原始软件存在兼容性问题，且所述差异屏幕界面所对应的目标API为引发兼容性问题的原因。

可选地，所述的软件兼容性检测方法，其中，所述目标API包括第一目标API和与第二目标API，所述兼容性测试用例包括第一兼容性测试用例和第二兼容性测试用例，其中，所述第一目标API为与厂商定制有关的API，所述第二目标API为与安卓系统演化有关的API，所述第一兼容性测试用例对应的目标API为第一目标API，所述第二兼容性测试用例对应的目标API为第二目标API。

可选地，所述的软件兼容性检测方法，其中，所述基于所述记录序列，获取同一所述兼容性测试用例在所述测试设备池中的不同设备运行时的目标屏幕界面，具体包括：

当所述兼容性测试用例为所述第一兼容性测试用例时，基于所述记录序列，获取同一所述第一兼容性测试用例在所述测试设备池中的第一设备池中运行时的第一目标界面，其中，所述第一设备池包含多种厂商定制的设备；

当所述兼容性测试用例为所述第二兼容性测试用例时，基于所述记录序列，获取同一所述第二兼容性测试用例在所述测试设备池中的第二设备池中运行时的第二目标界面，其中，所述第二设备池包含多种版本API的设备。

此外，为实现上述目的，本发明还提供一种智能终端，其中，所述智能终端包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的软件兼容性检测程序，所述软件兼容性检测程序被所述处理器执行时实现如上所述的软件兼容性检测方法的步骤。

此外，为实现上述目的，本发明还提供一种存储介质，其中，所述存储介质存储有软件兼容性检测程序，所述软件兼容性检测程序被处理器执行时实现如上所述的软件兼容性检测方法的步骤。

本发明将API中与厂商定制和安卓平台演化有关的API作为目标API。对待检测的原始软件预处理，生成可记录运行日志的测试软件，然后控制测试软件运行常规测试用例，生成运行日志。由于测试软件在运行常规测试用例时，会触发或调用不同API，因此可根据运行日志中是否存在目标API，对常规测试用例进行筛选和加工，生成数量更少的兼容性测试用例，从而减少后续测试软件进行兼容性检测的耗时，提高检测效率。

此外，本发明在对常规测试用例进行筛选和加工中，采用了修剪和添加纪录序列的方式。修剪是将常规测试用例中触发目标API之后的序列删除，从而缩短了兼容性测试用例的长度，提高了检测效率，添加纪录序列是用于获取触发目标API后的屏幕界面，本发明根据屏幕界面进行两步检测，第一步检测是否崩溃或闪退，若存在崩溃，则确定原始软件存在兼容性问题，若不存在崩溃或闪退，进一步检测屏幕界面之间是否存在差异，若存在差异，则确定原始软件存在兼容性问题，因此检测方法快速便捷且直观，可提高检测效率。最后本发明还将目标API分为与厂商定制有关的第一目标API和与安卓平台演化有关的第二目标API，并控制测试软件对应不同的目标API在不同的测试设备池中运行，从而减少测试软件运行兼容性测试用例的次数，缩短检测时间。

附图说明

图1是本发明软件兼容性检测方法提供的较佳实施例的流程图；

图2是本发明软件兼容性检测方法的较佳实施例中整个方法执行流程的示意图；

图3是本发明软件兼容性检测方法的较佳实施例中步骤S100的流程图；

图4是本发明软件兼容性检测方法的较佳实施例中步骤S300的流程图；

图5是本发明软件兼容性检测方法的较佳实施例中步骤S400的流程图；

图6是安卓系统的构架示意图；

图7是本发明软件兼容性检测方法的较佳实施例中步骤S420的流程图；

图8是本发明软件兼容性检测方法的较佳实施例中整个方法的简略流程图；

图9是本发明软件兼容性检测方法的较佳实施例中步骤S430的流程图；

图10是本发明软件兼容性检测方法的较佳实施例中对测试软件进行兼容性检测的示意图；

图11是本发明软件兼容性检测方法的较佳实施例中步骤S433的流程图；

图12为本发明智能终端的较佳实施例的运行环境示意图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明较佳实施例所述的软件兼容性检测方法，如图1和图2所示，所述软件兼容性检测方法包括以下步骤：

步骤S100、获取待检测的原始软件，并对所述原始软件进行埋点的预处理，生成测试软件。

在本实施例中，执行所述兼容性检测方法的主体为安装于电脑上的兼容性检测程序实现，通过用户导入或主动读取的方式，所述兼容性检测程序获取所述原始软件。

正常情况下，所述原始软件并不包含对软件执行过程中可能触发或调用的API进行记录，本方案为记录所述原始软件调用或触发API的过程中，对原始软件插入用于记录调用或触发API情况的操作序列，生成可用于进行兼容性检测的测试软件。插入用于记录调用或触发API的方式可以采用埋点技术，埋点可记录软件运行过程中各个API的触发情况、应用软件的使用数据等等。

进一步地，参阅图3，步骤S100包括：

步骤S110、获取待检测的原始软件。

步骤S120、对所述原始软件中的目标API进行插桩，生成中间软件。

具体地，所述目标API为当软件运行时，更容易导致兼容性问题的API。本实施例中，埋点是通过插桩技术实现，插桩是指在目标程序代码中的某些位置插入或修改部分代码，从而在目标程序运行过程中获取某些程序状态并加以分析。本方案先采用代码分析工具Soot对所述原始软件中所述目标API的位置之前插入记录所述目标API触发或调用情况的操作序列，生成所述测试软件，该语句能够在所述测试软件运行过程中，监测所述目标API的触发或调用，若存在触发或调用，则将所述目标API的事件写入软件日志中。

步骤S130、对所述中间软件进行签名，生成测试软件。

具体地，签名是指在应用程序的特定字段写入特定的标记信息，表示该软件已经通过了签署者的审核，签署者对该软件的安全性负责。现今为保障软件的真实性和安全性，在系统上运行的软件都需要进行签名验证。由于所述兼容性检测程序对所述原始软件进行了修改，因此对修改之后的中间软件需要进行签名，以使其在后续能够正常运行。

步骤S200、控制所述测试软件运行预先生成的常规测试用例，并生成各个所述常规测试用例对应的运行日志。

具体地，所述常规用例是指常规的软件兼容性检测时采用的用例，可包括安装测试用例，配置测试用例，卸载测试用例等等。本实施例中采用的常规测试用例的生成是基于测试用例生成软件Appium，Appium软件是一个开源软件，允许用同样的API对多平台写测试。除Appium外，还可采用其他的测试软件书写和生成所述常规测试用例，本方案并不仅限于该软件。

所述兼容性检测程序控制所述测试软件在选定的设备上运行所述常规测试用例。选定的设备可以是原生的安卓系统，设备中的API的版本号也可根据用户的喜好或需求自由选定。由于所述测试软件为插桩后的软件，因此当所述测试软件运行所述常规测试用例时，实时记录运行过程中所述常规测试用例的运行状况，生成包含调用所述目标API的运行日志。

步骤S300，根据所述运行日志中是否存在目标API，对所述常规测试用例进行筛选和加工，生成兼容性测试用例。

具体地，先根据所述运行日志中是否包含目标API，对所述常规测试用例进行筛选，剔除不包含所述目标API的常规测试用例，留下包含所述目标API的常规测试用例，并将其作为候选测试用例。然后对所述候选测试用例进行剪切，仅保留所述候选测试用例中起始至触发的这一段操作序列，得到中间测试用例。最后，在所述中间测试用例之后加上获取屏幕界面的记录序列，生成兼容性测试用例。通过剪切，能够减少后续所述测试软件执行兼容性测试用例的时间，从而提高效率。而另一方面，由于兼容性问题的直观反映是通过屏幕界面的显示实现的，因此在所述中间测试用例之后增加记录序列，可便于后续对是否存在兼容性问题进行快速便捷的分析。

进一步地，参阅图4，步骤S300包括：

步骤S310、根据所述运行日志中是否存在目标API，将包含所述目标API的运行日志对应的常规测试用例作为候选测试用例。

具体地，若在运行所述常规测试用例中的常规测试用例A时，生成的日志文件包含所述目标API，则认为所述常规测试用例A为所述候选测试用例，可用于后续生成本方案的兼容性测试用例。若常规测试用例B对应的日志文件中不包含所述目标API，则将所述常规测试用例B删除或弃之不用。

步骤S320、将所述候选测试用例剪切，生成中间测试用例。

具体地，所述测试软件的每一个执行都是被具体的操作指令所控制，在软件系统中，所述操作指令为一个操作序列。由于真正调用目标API的仅仅是操作序列的一部分，执行还需要安卓系统中的其他层进行协助，而兼容性检测并不需要完整地执行完一个操作，因此，后续用于兼容性检测时，测试用例可缺失其他层协助的部分。本方案采用剪切的方式，仅保留操作序列中第一个操作到触发所述目标AP操作的子序列，剪切后的候选测试用例即为所述中间测试用例。

步骤S330、将所述中间测试用例添加用于获取屏幕界面的记录序列，生成包含所述目标API的兼容性测试用例。

具体地，所述中间测试用例仅仅包含操作起始到触发所述目标API的过程，但是并未包含可确定是否兼容性正常的功能。在本方案中，在所述中间测试用例之后，添加获取不同设备上的用户界面(User Interface，UI)界面的序列，从而当所述测试软件触发所述目标API时，可获取当前UI界面。获取UI界面的方式可包括截图，界面中图像的分布，显示等等，在此不做限定。

步骤S400，根据所述兼容性测试用例，对所述测试软件进行兼容性检测。

具体地，预先设定包含多种不同厂商终端的系统设备以及不同版本API设备的测试设备池。生成所述兼容性测试用例后，控制所述测试软件在所述测试设备池中运行所述兼容性测试用例。基于所述兼容性测试用例的记录序列，获取同一兼容性测试用例在不同设备对应的屏幕界面。然后通过对屏幕界面进行分析，从而确定所述原始软件是否存在兼容性问题，以及引发兼容性问题的原因。例如某一兼容性测试用例A在设备A上运行时获取的屏幕界面为系统的初始屏幕界面，即可确定所述测试软件在运行兼容性测试用例A时出现闪退或崩溃，因此可确定所述原始软件存在兼容性问题，且所述兼容性问题由兼容性测试用例A所引起。后续所述兼容性检测软件可在屏幕上显示测试结果，如“无兼容性问题”。

进一步地，参阅图5，步骤S400包括：

步骤S410、控制所述测试软件在预先设定的测试设备池中运行所述兼容性测试用例。

具体地，所述兼容性检测程序中包含有预先设定好的设备池，所述测试设备池是多种不同虚拟设备的集合，例如A厂商某终端的系统，可直接在所述兼容性检测程序中虚拟运行，从而得到可运行所述测试软件的A厂商的设备。除了不同厂商的设备外，所述测试设备池中还可包含不同版本API的设备，例如B设备中包含的API是15年更新和未更新的API。获得所述兼容性测试用例后，控制所述测试软件在所述测试设备池中各个设备运行所述兼容性测试用例。

步骤S420、基于所述记录序列，获取同一所述兼容性测试用例在所述测试设备池中的不同设备运行时的目标屏幕界面。

具体地，由于上述对所述候选测试用例进行加工的过程中，添加了用于获取屏幕界面的记录序列，因此在所述测试软件运行所述兼容性测试用例的时候，当触发或调用了所述目标API的时候，可获取当前设备的屏幕界面。因此最后可获得不同设备的多个屏幕界面，同一设备对应的屏幕界面又包括不同的兼容性测试用例所对应的屏幕界面。

步骤S430、根据所述目标屏幕界面，确定所述测试软件对应的兼容性信息。

具体地，由于不同的兼容性测试用例所对应的目标API不完全相同，因此为确定所述测试软件所存在的兼容性问题，需要对同一兼容性测试用例在不同设备上获取的屏幕界面进行比较分析，从而可确定所述测试软件的兼容性信息，所述兼容性信息可包括所述测试软件是否存在兼容性问题，以及该兼容性问题是由哪一设备或哪一目标API引起等。

进一步地，所述目标API包括第一目标API和与第二目标API，所述兼容性测试用例包括第一兼容性测试用例和第二兼容性测试用例，其中，所述第一目标API为与厂商定制有关的API，所述第二目标API为与安卓系统演化有关的API，所述第一兼容性测试用例对应的目标API为第一目标API，所述第二兼容性测试用例对应的目标API为第二目标API。

具体地，在软件运行过程中，容易导致兼容性问题的主要原因有两个，一个是厂商在原生的安卓系统上定制的系统修改底层的API，另一个是安卓系统本身在不断更新过程中导致的API功能等存在差异。因此将所述目标API分为两类，一类称为第一目标API，是指与厂商定制有关的API，另一类称为第二目标API，是指与安卓系统更新演化相关的API。参阅图6，安卓系统的架构从上到下分为应用程序层、API框架层、Native C/C++库以及安卓运行层、硬件抽象层和Linux内核层组成。大部分厂商对原生系统的修改是通过驱动所在的文件夹的改变实现的，而驱动所在的文件夹一般在Linux内核层，当所述测试软件运行时，可能触发被改变的文件夹，从而导致运行异常，从而引发兼容性问题。由于这些问题是通过调用API框架层的API触发Linux内核层，因此把可触发到经常被改变位置的驱动所在的文件夹的这部分API作为所述第一目标API。

安卓平台每隔一段时间都会进行版本的更新，包括删除旧的API，添加新的API。若所述原始软件需要旧版本的API才能运行时，其在安装新版本API的终端上运行可能会导致兼容性问题，甚至可能出现崩溃的现象。因此将在安卓平台更迭过程中被删除或新增的API作为第二目标API。

进一步地，参阅图7和图8，步骤S420还包括：

步骤S421、当所述兼容性测试用例为所述第一兼容性测试用例时，基于所述记录序列，获取同一所述第一兼容性测试用例在所述测试设备池中的第一设备池中运行时的第一目标界面，其中，所述第一设备池包含多种厂商定制的设备。

具体地，所述兼容性检测程序中预先设定有两种测试设备池，一种是包含不同供应商的设备的第一设备池，另一种是包含不同版本的API的第二设备池。当所述兼容性测试用例生成后，若所述兼容性测试用例为第一兼容性测试用例，则说明其中包含的目标API为所述第一目标API，即触发的是底层可能被修改的驱动文件夹的API，因此在包含多种厂商设备的第一设备池中运行。在所述测试软件运行时，基于所述获取屏幕界面的序列，获取各个所述版本设备对应的第一屏幕界面。

步骤S422、当所述兼容性测试用例为所述第二兼容性测试用例时，基于所述记录序列，获取同一所述第二兼容性测试用例在所述测试设备池中的第二设备池中运行时的第二目标界面，其中，所述第二设备池包含多种版本API的设备。

具体地，若所述兼容性测试用例为第二兼容性测试用例，则说明其中包含的目标API为所述第二目标API，即触发的是安卓系统演变中的更新迭代的API，因此在包含多种版本API的第二设备池中运行。在所述测试软件运行时，基于所述获取屏幕界面的序列，获取各个所述版本设备对应的第二屏幕界面。

进一步地，参阅图9和图10，所述兼容性信息包括所述原始软件是否存在兼容性问题及引发所述兼容性问题的原因，步骤S430包括：

步骤S431、根据所述目标屏幕界面，判断所述目标屏幕界面是否存在崩溃或闪退。

具体地，崩溃或闪退是软件运行过程中严重的兼容性问题导致的现象，因此当运行所述兼容性测试用例时出现闪退或崩溃现象，则可直接判定所述测试软件存在兼容性问题。

步骤S432、若所述目标屏幕界面存在崩溃或闪退，则确定所述原始软件存在兼容性问题，且存在崩溃或闪退的目标屏幕界面所对应的目标API为引发兼容性问题的原因。

具体地，若所述目标屏幕界面存在崩溃或闪退，则确定所述测试软件存在兼容性问题，且根据所述目标界面所对应的兼容性测试用例，可确定所述测试软件对应的具体的兼容性信息。例如所述目标屏幕界面存在崩溃，其对应兼容性测试用例A，而兼容性测试用例A所包含的目标API为远程过程调用中的某一API，则该API为引起所述测试软件出现兼容性问题的API。

步骤S433、若所述目标屏幕界面不存在崩溃或闪退，则根据所述目标屏幕界面之间的差异，确定所述原始软件对应的兼容性信息。

进一步地，参阅图11，步骤S433包括：

步骤S4331、计算各个所述目标屏幕界面之间的相似度值。

具体地，若否，则对所述兼容性测试用例对应的屏幕界面进行统计分析，本实施例中，所述记录序列所获取的屏幕界面为图片形式的屏幕界面，然后计算所述目标屏幕界面之间的相似度值。由于目前的厂商定制的系统在外观上都存在差异，因此一对一地进行完全匹配，错误率过高，因此可对其进行相似度值的比较，采用的算法包括差异值哈希算法、颜色直方图等。以直方图为例，直方图能够描述一副图像中的颜色的全局分布，首先根据各个图像的像素数据，生成各自的直方图数据，然后运用巴氏洗漱算法，计算图像之间彼此的相似度值。

步骤S4332、根据所述相似度值，判断所述目标屏幕界面中是否存在满足预设的差异判断规则的差异屏幕界面。

具体地，所述差异判断规则可为设定一个相似度阈值，如90％。在一个测试过程中，存在三个目标屏幕界面，分别为目标屏幕界面A，目标屏幕界面B和目标屏幕界面C，目标屏幕界面A与目标屏幕界面B的相似度值为92％，目标屏幕界面B与目标屏幕界面C的相似度值为50％，目标屏幕界面C与目标屏幕界面A之间的相似度值为60％，则目标屏幕界面C与其他目标屏幕界面之间的相似度值低于相似度阈值，因此目标屏幕界面C为差异屏幕界面。此外差异判断规则还可采用聚类的方式，将所述相似度值接近的目标屏幕界面进行聚类，如共有目标屏幕界面10个，其中8个目标屏幕界面属于一类，而另外2个目标屏幕界面属于另一类，则将另外2个目标屏幕界面作为差异屏幕界面。

步骤S4333、若是，则确定所述原始软件存在兼容性问题，且所述差异屏幕界面所对应的目标API为引发兼容性问题的原因。

具体地，若存在差异屏幕界面，则确定所述原始软件存在兼容性问题，而所述差异屏幕界面对应的目标API即为引发所述原始软件兼容性问题的原因。

进一步地，如图12所示，基于上述软件兼容性检测方法，本发明还相应提供了一种智能终端，所述智能终端包括处理器10、存储器20及显示器30。图12仅示出了智能终端的部分组件，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。

所述存储器20在一些实施例中可以是所述智能终端的内部存储单元，例如智能终端的硬盘或内存。所述存储器20在另一些实施例中也可以是所述智能终端的外部存储设备，例如所述智能终端上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器20还可以既包括所述智能终端的内部存储单元也包括外部存储设备。所述存储器20用于存储安装于所述智能终端的应用软件及各类数据，例如所述安装智能终端的程序代码等。所述存储器20还可以用于暂时地存储已经输出或者将要输出的数据。在一实施例中，存储器20上存储有软件兼容性检测程序40，该软件兼容性检测程序40可被处理器10所执行，从而实现本申请中软件兼容性检测方法。

所述处理器10在一些实施例中可以是一中央处理器(Central Processing Unit,CPU)，微处理器或其他数据处理芯片，用于运行所述存储器20中存储的程序代码或处理数据，例如执行所述软件兼容性检测方法等。

所述显示器30在一些实施例中可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。所述显示器30用于显示在所述智能终端的信息以及用于显示可视化的用户界面。所述智能终端的部件10-30通过系统总线相互通信。

在一实施例中，当处理器10执行所述存储器20中软件兼容性检测程序40时实现以下步骤：

获取待检测的原始软件，并对所述原始软件进行埋点的预处理，生成测试软件；

控制所述测试软件运行预先生成的常规测试用例，并生成各个所述常规测试用例对应的运行日志；

根据所述运行日志中是否存在目标API，对所述常规测试用例进行筛选和加工，生成兼容性测试用例；

根据所述兼容性测试用例，对所述测试软件进行兼容性检测。

其中，所述获取待检测的原始软件，并对所述原始软件进行预处理，生成测试软件，具体包括：

获取待检测的原始软件；

对所述原始软件中的目标API进行插桩，生成中间软件；

对所述中间软件进行签名，生成测试软件。

其中，所述根据所述运行日志中是否存在目标API，对所述常规测试用例进行筛选和加工，生成兼容性测试用例，具体包括：

根据所述运行日志中是否存在目标API，将包含所述目标API的运行日志对应的常规测试用例作为候选测试用例；

将所述候选测试用例剪切，生成中间测试用例；

将所述中间测试用例添加用于获取屏幕界面的记录序列，生成包含所述目标API的兼容性测试用例。

其中，所述根据所述兼容性测试用例，对所述测试软件进行兼容性检测，具体包括：

控制所述测试软件在预先设定的测试设备池中运行所述兼容性测试用例；

基于所述记录序列，获取同一所述兼容性测试用例在所述测试设备池中的不同设备运行时的目标屏幕界面；

根据所述目标屏幕界面，确定所述测试软件对应的兼容性信息。

其中，所述兼容性信息包括所述原始软件是否存在兼容性问题及引发所述兼容性问题的原因，所述根据所述目标屏幕界面，确定所述测试软件对应的兼容性信息，具体包括：

根据所述目标屏幕界面，判断所述目标屏幕界面是否存在崩溃或闪退；

若所述目标屏幕界面存在崩溃或闪退，则确定所述原始软件存在兼容性问题，且存在崩溃或闪退的目标屏幕界面所对应的目标API为引发兼容性问题的原因；

若所述目标屏幕界面不存在崩溃或闪退，则根据所述目标屏幕界面之间的差异，确定所述原始软件对应的兼容性信息。

其中，所述若所述目标屏幕界面不存在崩溃或闪退，则根据所述目标屏幕界面之间的差异，确定所述原始软件对应的兼容性信息，具体包括：

计算各个所述目标屏幕界面之间的相似度值；

根据所述相似度值，判断所述目标屏幕界面中是否存在满足预设的差异判断规则的差异屏幕界面；

若是，则确定所述原始软件存在兼容性问题，且所述差异屏幕界面所对应的目标API为引发兼容性问题的原因。

其中，所述目标API包括第一目标API和与第二目标API，所述兼容性测试用例包括第一兼容性测试用例和第二兼容性测试用例，其中，所述第一目标API为与厂商定制有关的API，所述第二目标API为与安卓系统演化有关的API，所述第一兼容性测试用例对应的目标API为第一目标API，所述第二兼容性测试用例对应的目标API为第二目标API。

其中，所述基于所述记录序列，获取同一所述兼容性测试用例在所述测试设备池中的不同设备运行时的目标屏幕界面，具体包括：

当所述兼容性测试用例为所述第一兼容性测试用例时，基于所述记录序列，获取同一所述第一兼容性测试用例在所述测试设备池中的第一设备池中运行时的第一目标界面，其中，所述第一设备池包含多种厂商定制的设备；

当所述兼容性测试用例为所述第二兼容性测试用例时，基于所述记录序列，获取同一所述第二兼容性测试用例在所述测试设备池中的第二设备池中运行时的第二目标界面，其中，所述第二设备池包含多种版本API的设备。

本发明还提供一种存储介质，其中，所述存储介质存储有软件兼容性检测程序，所述软件兼容性检测程序被处理器执行时实现如上所述的软件兼容性检测方法的步骤。

当然，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关硬件(如处理器，控制器等)来完成，所述的程序可存储于一计算机可读取的存储介质中，所述程序在执行时可包括如上述各方法实施例的流程。其中所述的存储介质可为存储器、磁碟、光盘等。

应当理解的是，本发明的应用不限于上述的举例，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，所有这些改进和变换都应属于本发明所附权利要求的保护范围。

Claims (7)

1.一种软件兼容性检测方法，其特征在于，所述软件兼容性检测方法包括：

获取待检测的原始软件，并对所述原始软件进行埋点的预处理，生成测试软件；

所述获取待检测的原始软件，并对所述原始软件进行埋点的预处理，生成测试软件，具体包括：

对所述原始软件中的目标API进行插桩，生成中间软件；

对所述中间软件进行签名，生成测试软件；

控制所述测试软件运行预先生成的常规测试用例，并生成各个所述常规测试用例对应的运行日志；

根据所述运行日志中是否存在目标API，对所述常规测试用例进行筛选和加工，生成兼容性测试用例；

所述根据所述运行日志中是否存在目标API，对所述常规测试用例进行筛选和加工，生成兼容性测试用例，具体包括：

根据所述运行日志中是否存在目标API，将包含所述目标API的运行日志对应的常规测试用例作为候选测试用例；

将所述候选测试用例剪切，生成中间测试用例；

将所述中间测试用例添加用于获取屏幕界面的记录序列，生成包含所述目标API的兼容性测试用例；

根据所述兼容性测试用例，对所述测试软件进行兼容性检测

所述根据所述兼容性测试用例，对所述测试软件进行兼容性检测，具体包括：

控制所述测试软件在预先设定的测试设备池中运行所述兼容性测试用例；

基于所述记录序列，获取同一所述兼容性测试用例在所述测试设备池中的不同设备运行时的目标屏幕界面；

根据所述目标屏幕界面，确定所述测试软件对应的兼容性信息；

所述兼容性信息包括所述原始软件是否存在兼容性问题及引发所述兼容性问题的原因。

2.根据权利要求1所述的软件兼容性检测方法，所述根据所述目标屏幕界面，确定所述测试软件对应的兼容性信息，具体包括：

根据所述目标屏幕界面，判断所述目标屏幕界面是否存在崩溃或闪退；

若所述目标屏幕界面存在崩溃或闪退，则确定所述原始软件存在兼容性问题，且存在崩溃或闪退的目标屏幕界面所对应的目标API为引发兼容性问题的原因；

若所述目标屏幕界面不存在崩溃或闪退，则根据所述目标屏幕界面之间的差异，确定所述原始软件对应的兼容性信息。

3.根据权利要求2所述的软件兼容性检测方法，其特征在于，所述若所述目标屏幕界面不存在崩溃或闪退，则根据所述目标屏幕界面之间的差异，确定所述原始软件对应的兼容性信息，具体包括：

计算各个所述目标屏幕界面之间的相似度值；

根据所述相似度值，判断所述目标屏幕界面中是否存在满足预设的差异判断规则的差异屏幕界面；

若是，则确定所述原始软件存在兼容性问题，且所述差异屏幕界面所对应的目标API为引发兼容性问题的原因。

4.根据权利要求1-3任意一项所述的软件兼容性检测方法，其特征在于，所述目标API包括第一目标API和第二目标API，所述兼容性测试用例包括第一兼容性测试用例和第二兼容性测试用例，其中，所述第一目标API为与厂商定制有关的API，所述第二目标API为与安卓系统演化有关的API，所述第一兼容性测试用例对应的目标API为第一目标API，所述第二兼容性测试用例对应的目标API为第二目标API。

5.根据权利要求4所述的软件兼容性检测方法，其特征在于，所述基于所述记录序列，获取同一所述兼容性测试用例在所述测试设备池中的不同设备运行时的目标屏幕界面，具体包括：

当所述兼容性测试用例为所述第一兼容性测试用例时，基于所述记录序列，获取同一所述第一兼容性测试用例在所述测试设备池中的第一设备池中运行时的第一目标界面，其中，所述第一设备池包含多种厂商定制的设备；

当所述兼容性测试用例为所述第二兼容性测试用例时，基于所述记录序列，获取同一所述第二兼容性测试用例在所述测试设备池中的第二设备池中运行时的第二目标界面，其中，所述第二设备池包含多种版本API的设备。

6.一种智能终端，其特征在于，所述智能终端包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的软件兼容性检测程序，所述软件兼容性检测程序被所述处理器执行时实现如权利要求1-5任一项所述的软件兼容性检测方法的步骤。

7.一种存储介质，其特征在于，所述存储介质存储有软件兼容性检测程序，所述软件兼容性检测程序被处理器执行时实现如权利要求1-5任一项所述的软件兼容性检测方法的步骤。

Images