基于应用程序的加壳工具测试方法、存储介质及电子设备与流程

1.本公开涉及通信技术领域，特别涉及一种基于应用程序的加壳工具测试方法、存储介质及电子设备。


背景技术：

2.对着智能手机的普及，各类应用程序也在不断开发，以丰富用户对智能手机的实际体验，应用程序开发者将打包好的应用程序上传到应用商店中供用户下载安装，但同时也会有竞争厂商或者不法分子对打包的安装程序进行破解，导致程序员所编写的源代码泄露，不利于应用程序的使用安全。
3.在相关技术中，可以通过加壳工具对应用程序进行保护，加壳工具通常具有如下功能：函数虚拟化、dex加密、反调试、反注入、文件校验、签名校验、资源加密等，还可以包括内存校验、unity引擎保护、metadata加密和metadata名称混淆等功能。在通过加壳工具对应用程序进行加壳处理之后，该应用程序还应当正确实现其自身原有功能，若加壳后的应用程序无法正常运行或者在使用过程中出现程序崩溃情况，则有可能是在加壳过程中出现问题；与此同时，智能终端的型号和系统版本的多样性，也可能导致加壳后的应用程序无法正常运行。
4.因此，需要对加壳后的应用程序来进行测试以反映加壳工具可能存在的问题，现有技术中在进行测试时主要基于人工实现，通过在不同设备中分别安装加壳后的应用程序，通过程序的执行情况来判断加壳后的应用程序的稳定性和适配性，进而反映加壳工具的加壳效果。但是基于人工实现的测试需要消耗大量人力和物力资源，同时使测试的时间成本增加，并且基于程序执行截图作为反应程序问题的依据时，开发人员无法直观知悉具体由加壳工具的哪个功能导致了问题的产生，进而也影响了加壳工具的调试和修改的效率。


技术实现要素：

5.本公开实施例的目的在于提供一种基于应用程序的加壳工具测试方法、存储介质及电子设备，用以解决现有技术中加壳工具测试周期长、测试效率低的问题。
6.本公开的实施例采用如下技术方案：一种基于应用程序的加壳工具测试方法，包括：在预设路径存储的所有加壳后的样本程序中获取预定数量的样本程序作为第一批次程序；将所述第一批次程序中的每个所述样本程序分别安装在预定数量的测试设备中；启动所有所述测试设备中的所述样本程序，并对每个所述样本程序进行限定时间压测；获取每个所述样本程序在所述限定时间压测后形成的崩溃日志；根据所述崩溃日志，确定所述加壳工具的测试结果。
7.在一些实时例中，所述第一批次程序中的所述样本程序之间具有相同或不同的加壳方式；所述第一批次程序中的所述样本程序与所有样本程序中除去所述第一批次程序以外的其他批次的样本程序之间具有不同的加壳方式。
8.在一些实时例中，每个所述测试设备至少有一个设备参数的值与其他测试设备的设备参数的值不同；其中，所述设备参数至少包括以下任意一种：设备id、设备型号、操作系统、操作系统版本号。
9.在一些实时例中，所述启动所有所述测试设备中的所述样本程序，包括：获取所述样本程序的包名和活动名；根据所述包名和所述活动名启动所述样本程序。
10.在一些实时例中，在预设路径存储的所有加壳后的样本程序中获取预定数量的样本程序作为第一批次程序之前，还包括：基于第一配置文件对应用程序进行加壳处理以形成样本程序；其中，每个所述应用程序均对应有一个所述第一配置文件，所述第一配置文件中至少包括用于表征当前加壳方式的选项内容，以使所述加壳工具根据所述选项内容实现对所述应用程序的加壳处理。
11.在一些实时例中，所述在预设路径存储的所有加壳后的样本程序中获取预定数量的样本程序作为第一批次程序，包括：在所述加壳工具对应的第二配置文件中确定第一预设节点的值是否为第一预设值；其中，所述第一预设节点用于表征所述加壳工具是否对所述样本程序进行签名；在所述第一预设节点的值为第一预设值的情况下，将所述第二配置文件中第二预设节点的值作为所述预设路径；其中，所述第二预设节点用于表征签名后的样本程序所在的存储位置；在所述第一预设节点的值为第二预设值的情况下，控制所述加壳工具重新对所述样本程序进行签名，并将所述签名后的样本程序存储至所述预设路径。
12.在一些实时例中，所述根据所述崩溃日志，确定所述加壳工具的测试结果，包括：在所述崩溃日志为空的情况下，确定所述加壳工具的测试通过；在所述崩溃日志不为空的情况下，确定所述崩溃日志中记录的错误码，并在所述崩溃日志对应的所述样本程序的第一配置文件中确定所述错误码对应的选项内容。
13.在一些实时例中，在所述根据所述崩溃日志，确定所述加壳工具的测试结果之后，还包括：将不为空的所述崩溃日志对应的所述样本程序名称与所述错误码对应的选项内容进行关联保存。
14.本公开的实施例还提供了一种存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现上述的基于应用程序的加壳工具测试方法的步骤。
15.本公开的实施例还提供了一种电子设备，至少包括存储器、处理器，所述存储器上存储有计算机程序，其特征在于，所述处理器在执行所述存储器上的计算机程序时实现上述的基于应用程序的加壳工具测试方法的步骤。
16.本公开实施例的有益效果在于：通过自动化方式实现加壳后的样本程序的获取、安装、运行测试等步骤，并通过样本程序的崩溃日志内容反映样本程序的执行情况，进而反映加壳工具的测试结果，极大地缩短了加壳工具测试过程的测试周期，提升了测试效率，并且可以直观展示加壳工具的问题所在，更有利于测试人员进行加壳工具的调试和修改，有助于验证加壳工具的各个功能的兼容性效果。
附图说明
17.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提
下，还可以根据这些附图获得其他的附图。
18.图1为本公开第一实施例中基于应用程序的加壳工具测试方法的流程图；
19.图2为本公开第三实施例中电子设备的结构示意图。
具体实施方式
20.此处参考附图描述本公开的各种方案以及特征。
21.应理解的是，可以对此处申请的实施例做出各种修改。因此，上述说明书不应该视为限制，而仅是作为实施例的范例。本领域的技术人员将想到在本公开的范围和精神内的其他修改。
22.包含在说明书中并构成说明书的一部分的附图示出了本公开的实施例，并且与上面给出的对本公开的大致描述以及下面给出的对实施例的详细描述一起用于解释本公开的原理。
23.通过下面参照附图对给定为非限制性实例的实施例的优选形式的描述，本公开的这些和其它特性将会变得显而易见。
24.还应当理解，尽管已经参照一些具体实例对本公开进行了描述，但本领域技术人员能够确定地实现本公开的很多其它等效形式，它们具有如权利要求的特征并因此都位于借此所限定的保护范围内。
25.当结合附图时，鉴于以下详细说明，本公开的上述和其他方面、特征和优势将变得更为显而易见。
26.此后参照附图描述本公开的具体实施例；然而，应当理解，所申请的实施例仅仅是本公开的实例，其可采用多种方式实施。熟知和/或重复的功能和结构并未详细描述以避免不必要或多余的细节使得本公开模糊不清。因此，本文所申请的具体的结构性和功能性细节并非意在限定，而是仅仅作为权利要求的基础和代表性基础用于教导本领域技术人员以实质上任意合适的详细结构多样地使用本公开。
27.本说明书可使用词组“在一种实施例中”、“在另一个实施例中”、“在又一实施例中”或“在其他实施例中”，其均可指代根据本公开的相同或不同实施例中的一个或多个。
28.对着智能手机的普及，各类应用程序也在不断开发，以丰富用户对智能手机的实际体验，应用程序开发者将打包好的应用程序上传到应用商店中供用户下载安装，但同时也会有竞争厂商或者不法分子对打包的安装程序进行破解，导致程序员所编写的源代码泄露，不利于应用程序的使用安全。
29.在相关技术中，可以通过加壳工具对应用程序进行保护，加壳工具通常具有如下功能：函数虚拟化、dex加密、反调试、反注入、文件校验、签名校验、资源加密等，还可以包括内存校验、unity引擎保护、metadata加密和metadata名称混淆等功能。在通过加壳工具对应用程序进行加壳处理之后，该应用程序还应当正确实现其自身原有功能，若加壳后的应用程序无法正常运行或者在使用过程中出现程序崩溃情况，则有可能是在加壳过程中出现问题；与此同时，智能终端的型号和系统版本的多样性，也可能导致加壳后的应用程序无法正常运行。
30.因此，需要对加壳后的应用程序来进行测试以反映加壳工具可能存在的问题，现有技术中在进行测试时主要基于人工实现，通过在不同设备中分别安装加壳后的应用程
序，通过程序的执行情况来判断加壳后的应用程序的稳定性和适配性，进而反映加壳工具的加壳效果。但是基于人工实现的测试需要消耗大量人力和物力资源，同时使测试的时间成本增加，并且基于程序执行截图作为反应程序问题的依据时，开发人员无法直观知悉具体由加壳工具的哪个功能导致了问题的产生，进而也影响了加壳工具的调试和修改的效率。
31.为了解决上述问题，本公开的第一实施例提供了一种基于应用程序的加壳工具测试方法，其主要根据加壳后的应用程序在不同测试设备内的运行情况反应加壳工具的各种加壳功能的稳定性和适应性，并且通过程序自动执行加壳后样本程序的获取、安装、运行测试等流程，无需人工进行重复操作，极大地提升了测试的效率。具体地，图1示出了测试方法的流程图，其主要包括步骤s10至s50：
32.s10，在预设路径存储的所有加壳后的样本程序中获取预定数量的样本程序作为第一批次程序。
33.s20，将第一批次程序中的每个样本程序分别安装在预定数量的测试设备中。
34.样本程序可以选用经过程序开发商测试后，可以在不同的智能设备型号以及不同操作系统中均可以稳定运行的应用程序，其可以是以动态化打包方式(android app bundlem，aab)形成的应用程序，也可以是通过其他打包方式形成的应用程序，本实施例不进行限制。而加壳工具支持对android abb和android unity abb程序的保护，其中针对android abb所能实现的功能包括函数虚拟化、应用程序代码文件(例如.dex文件)加密、反调试、反注入、文件校验、签名校验、资源加密等，而针对android unity abb程序所能实现的功能包括内存校验、unity引擎保护、metadata加密和metadata名称混淆等，在加壳工具测试过程中，需要使用大量的测试设备和大量的应用程序来验证加壳工具每个功能的兼容性。
35.在进行测试之前，可以针对应用程序进行基于不同功能的加壳，以得到多个加壳后的应用程序作为样本程序。具体地，测试人员可以对第一配置文件内容进行调整，加壳工具则根据第一配置文件内的具体内容对应用程序进行相应方式的加壳，其中，第一配置文件中至少包括用于表征当前加壳方式的选项内容，测试人员可根据测试需求对相应功能对应的选项内容进行调整，以指示加壳工具是否进行对应功能的实现。需要注意的是，为了实现加壳工具自动进行加壳，需要保证第一配置文件与需要进行加壳的应用程序放置在同一个路径中，随后通过加壳工具的指令控制加壳工具实现加壳操作，对于经过加壳处理后返回的样本程序，其应当被放置在预先指定的预设路径中，便于在进行安装测试时可直接获取到样本程序的安装包，实现测试的自动化。
36.在本实施例中，首先在基于不同的加壳方式进行加壳处理后的多个样本程序中获取预定数量的样本程序作为第一批次程序，用以进行当前的测试流程。具体地，第一批次程序中样本程序的获取可以是随机进行的，预定数量的值则可根据当前所具有的测试设备的数量进行确定，以保证第一批次程序中的每个样本程序都可以被安装在一个测试设备中进行稳定性测试。测试设备多个智能终端，在选用时应当保证每个所述测试设备至少有一个设备参数的值与其他测试设备的设备参数的值不同，其中设备参数至少包括以下任意一种：设备id、设备型号、操作系统、操作系统版本号，还可以包括设备品牌等其他设备参数。另外，每次进行测试的测试设备数量可根据实际情况进行设置，只要通过数据线将测试设
备与电脑等控制设备进行连接，并允许电脑进行测试设备控制即可。
37.在一些实施例中，可以限定第一批次程序中所包含的样本程序之间具有相同或不同的加壳方式，而第一批次程序中所包含的样本程序与所有样本程序中除去所述第一批次程序以外的其他批次的样本程序之间则限定其具有不同的加壳方式，以便于在不同批次的测试中，可以实现多种加壳方式的稳定性的分别测试，避免进行单一的加壳方式的测试。在实际实现时，第一批次程序中样本程序的选择可以是随机的，并且针对一个样本程序会被安装到哪一个测试设备中也可以是随机的，尽量保证样本程序以及测试设备对应关系的多样性，此时经过测试后所获得的测试结果可以具有更好的准确性和可信任性。
38.在一些实施例中，获取第一批次样本时，首先在加壳工具对应的第二配置文件中确定第一预设节点的值是否为第一预设值；其中，第一预设节点用于表征加壳工具是否对样本程序进行签名，第一预设值可以为表征加壳工具完成对样本程序进行签名的具体值，而只有在加壳工具对样本程序完成签名后才可以认定加壳工具对程序实现了成功加壳。进一步地，在第一预设节点的值为第一预设值的情况下，将第二配置文件中第二预设节点的值作为预设路径；其中，第二预设节点用于表征签名后样本程序所在的存储位置，其通常为一个文件的路径，在测试开始时在预设路径中即可获取相应的样本程序安装包。若第一预设节点的值为第二预设值的情况下，则控制加壳工具对样本程序重新进行签名，并控制加壳程序将签名后的样本程序存储至预设路径；其中，第二预设值用于表征样本程序签名失败的具体值，并且在签名失败的情况下，需要进行重新签名，而对于重新签名的样本程序所存储的位置，其可以为测试人员指定的任意一个目录的路径，只要能保证在测试时能从中获取到样本程序的安装包即可。在实际实现时，第一预设节点可以为《enable_sign》节点，第一预设值可以设定为1，第二预设值可以为0，第二预设节点可以为《apks_path》节点，该节点的值可以为一个预先设定的目录的路径。
39.s30，启动所有测试设备中的样本程序，并对每个样本程序进行限定时间压测。
40.样本程序在测试设备中安装完毕后，可控制测试设备获取样本程序的包名(package name)和活动名(activity name)，并根据各个测试设备中程序的package name和activity name，基于一定的顺序通过控制指令依次将测试设备中的样本程序启动，并对每个当前正在运行的样本程序进行限定时间压测。
41.具体地，限定时间压测可以基于adb工具中的monkey指令实现，其主要通过monkey程序，模拟用户触摸屏幕、滑动、按键等操作对样本程序进行测试，其具体限定的测试时间和测试强度可以根据需求进行调整，本实施例不进行限制，但是应当保证每个样本程序所进行的显示压力测试的测试时间和强度是相同的，以尽量保证其他变量对测试结果的影响。在一些实施例中，在进行限定时间压测之前，还可以通过控制指令清除当前测试设备内的缓存日志，以进一步保证测试环境的统一。
42.s40，获取每个样本程序在限定时间压测后形成的崩溃日志。
43.s50，根据崩溃日志，确定加壳工具的测试结果。
44.在限定时间压测过程中，若程序出现崩溃等情况，在其对应的崩溃日志中则会记录表征样本程序出现的崩溃类型的错误码，还可以同时记录具体是哪种操作导致了崩溃的产生，若在限定时间压测结束后，当前程序对应的崩溃记录为空，则说明程序在限定时间压测过程中并未出现崩溃情况，可判定加壳后的程序可以正常运行，进而判定加壳工具针对
当前样本程序所进行的加壳方式在当前测试设备中运行时具有良好的稳定性。
45.若崩溃日志的内容不为空，则根据崩溃日志中记录的错误码，在样本程序对应的第一配置文件中确定错误码对应的选项内容，以得到具体是加壳工具中的哪个功能导致了崩溃的产生。应当了解的是，错误码与选项内容之间的对应关系是预先设置的，根据错误码对应的选项内容即可确定加壳工具中具体哪个功能在实现时导致了崩溃的发生，进而可以供测试人员进行有针对性对加壳工具进行调试和修改。
46.另外，还可以将崩溃日志不为空的样本程序对应的程序名称、崩溃日志中记录的错误码以及错误码对应的选项内容等进行关联保存，另外还可以进一步保存相应测试设备的设备参数以供参考。
47.在实际实现时，对于第一批次程序所包含的样本程序在限定时间压测结束后，通过控制指令将样本程序从测试设备中进行卸载，然后从所有样本程序中再次选择预定数量的样本程序作为新的第一批次程序，重复进行上述的测试流程，直至所有样本程序均测试完毕。
48.本实施例通过自动化方式实现加壳后的样本程序的获取、安装、运行测试等步骤，并通过样本程序的崩溃日志内容反映样本程序的执行情况，进而反映加壳工具的测试结果，极大地缩短了加壳工具测试过程的测试周期，提升了测试效率，并且可以直观展示加壳工具的问题所在，更有利于测试人员进行加壳工具的调试和修改，有助于验证加壳工具的各个功能的兼容性效果。
49.本公开第二实施例提供了一种存储介质，该存储介质可安装于计算机等控制设备中，计算机通过数据线与多个测试设备连接，并且可以实现对加壳工具和测试设备的控制，其具体为计算机可读介质，存储有计算机程序，该计算机程序被处理器执行时实现本公开任意实施例提供的方法，包括如下步骤s31至s35：
50.s31，在预设路径存储的所有加壳后的样本程序中获取预定数量的样本程序作为第一批次程序；
51.s32，将第一批次程序中的每个样本程序分别安装在预定数量的测试设备中；
52.s33，启动所有测试设备中的样本程序，并对每个样本程序进行限定时间压测；
53.s34，获取每个样本程序在限定时间压测后形成的崩溃日志；
54.s35，根据崩溃日志，确定加壳工具的测试结果。
55.具体地，第一批次程序中的样本程序之间具有相同或不同的加壳方式；第一批次程序中的样本程序与所有样本程序中除去第一批次程序以外的其他批次的样本程序之间具有不同的加壳方式。
56.具体地，每个测试设备至少有一个设备参数的值与其他测试设备的设备参数的值不同；其中，设备参数至少包括以下任意一种：设备id、设备型号、操作系统、操作系统版本号。
57.计算机程序被处理器执行启动所有测试设备中的样本程序时，具体被处理器执行如下步骤：获取样本程序的包名和活动名；根据包名和活动名启动样本程序。
58.计算机程序被处理器执行在预设路径存储的所有加壳后的样本程序中获取预定数量的样本程序作为第一批次程序之前，还被处理器执行如下步骤：基于第一配置文件对应用程序进行加壳处理以形成样本程序；其中，每个应用程序均对应有一个第一配置文件，
第一配置文件中至少包括用于表征当前加壳方式的选项内容，以使加壳工具根据选项内容实现对应用程序的加壳处理。
59.计算机程序被处理器执行在预设路径存储的所有加壳后的样本程序中获取预定数量的样本程序作为第一批次程序时，具体被处理器执行如下步骤：在加壳工具对应的第二配置文件中确定第一预设节点的值是否为第一预设值；其中，第一预设节点用于表征加壳工具是否对样本程序进行签名；在第一预设节点的值为第一预设值的情况下，将第二配置文件中第二预设节点的值作为预设路径；其中，第二预设节点用于表征签名后的样本程序所在的存储位置；在第一预设节点的值为第二预设值的情况下，控制加壳工具重新对样本程序进行签名，并将签名后的样本程序存储至预设路径。
60.计算机程序被处理器执行根据崩溃日志，确定加壳工具的测试结果时，具体被处理器执行如下步骤：在崩溃日志为空的情况下，确定加壳工具的测试通过；在崩溃日志不为空的情况下，确定崩溃日志中记录的错误码，并在崩溃日志对应的样本程序的第一配置文件中确定错误码对应的选项内容。
61.计算机程序被处理器执行根据崩溃日志，确定加壳工具的测试结果之后，还被处理器执行如下步骤：将不为空的崩溃日志对应的样本程序名称与错误码对应的选项内容进行关联保存。
62.本实施例通过自动化方式实现加壳后的样本程序的获取、安装、运行测试等步骤，并通过样本程序的崩溃日志内容反映样本程序的执行情况，进而反映加壳工具的测试结果，极大地缩短了加壳工具测试过程的测试周期，提升了测试效率，并且可以直观展示加壳工具的问题所在，更有利于测试人员进行加壳工具的调试和修改，有助于验证加壳工具的各个功能的兼容性效果。
63.本公开的第三实施例提供了一种电子设备，该电子设备可以是计算机等控制设备，其可以通过数据线与多个测试设备连接，并且可以实现对加壳工具和测试设备的控制，其结构示意图如图2所示，至少包括存储器100和处理器200，存储器100上存储有计算机程序，处理器200在执行存储器100上的计算机程序时实现本公开任意实施例提供的方法。示例性的，电子设备计算机程序步骤如下s41至s45：
64.s41，在预设路径存储的所有加壳后的样本程序中获取预定数量的样本程序作为第一批次程序；
65.s42，将第一批次程序中的每个样本程序分别安装在预定数量的测试设备中；
66.s43，启动所有测试设备中的样本程序，并对每个样本程序进行限定时间压测；
67.s44，获取每个样本程序在限定时间压测后形成的崩溃日志；
68.s45，根据崩溃日志，确定加壳工具的测试结果。
69.具体地，第一批次程序中的样本程序之间具有相同或不同的加壳方式；第一批次程序中的样本程序与所有样本程序中除去第一批次程序以外的其他批次的样本程序之间具有不同的加壳方式。
70.具体地，每个测试设备至少有一个设备参数的值与其他测试设备的设备参数的值不同；其中，设备参数至少包括以下任意一种：设备id、设备型号、操作系统、操作系统版本号。
71.处理器在执行存储器上存储的启动所有测试设备中的样本程序时，具体执行如下
计算机程序：获取样本程序的包名和活动名；根据包名和活动名启动样本程序。
72.处理器在执行存储器上存储的在预设路径存储的所有加壳后的样本程序中获取预定数量的样本程序作为第一批次程序之前，还执行如下计算机程序：基于第一配置文件对应用程序进行加壳处理以形成样本程序；其中，每个应用程序均对应有一个第一配置文件，第一配置文件中至少包括用于表征当前加壳方式的选项内容，以使加壳工具根据选项内容实现对应用程序的加壳处理。
73.处理器在执行存储器上存储的在预设路径存储的所有加壳后的样本程序中获取预定数量的样本程序作为第一批次程序时，具体执行如下计算机程序：在加壳工具对应的第二配置文件中确定第一预设节点的值是否为第一预设值；其中，第一预设节点用于表征加壳工具是否对样本程序进行签名；在第一预设节点的值为第一预设值的情况下，将第二配置文件中第二预设节点的值作为预设路径；其中，第二预设节点用于表征签名后的样本程序所在的存储位置；在第一预设节点的值为第二预设值的情况下，控制加壳工具重新对样本程序进行签名，并将签名后的样本程序存储至预设路径。
74.处理器在执行存储器上存储的根据崩溃日志，确定加壳工具的测试结果时，具体执行如下计算机程序：在崩溃日志为空的情况下，确定加壳工具的测试通过；在崩溃日志不为空的情况下，确定崩溃日志中记录的错误码，并在崩溃日志对应的样本程序的第一配置文件中确定错误码对应的选项内容。
75.处理器在执行存储器上存储的根据崩溃日志，确定加壳工具的测试结果之后，还执行如下计算机程序：将不为空的崩溃日志对应的样本程序名称与错误码对应的选项内容进行关联保存。
76.本实施例通过自动化方式实现加壳后的样本程序的获取、安装、运行测试等步骤，并通过样本程序的崩溃日志内容反映样本程序的执行情况，进而反映加壳工具的测试结果，极大地缩短了加壳工具测试过程的测试周期，提升了测试效率，并且可以直观展示加壳工具的问题所在，更有利于测试人员进行加壳工具的调试和修改，有助于验证加壳工具的各个功能的兼容性效果。
77.以上对本公开多个实施例进行了详细说明，但本公开不限于这些具体的实施例，本领域技术人员在本公开构思的基础上，能够做出多种变型和修改实施例，这些变型和修改都应落入本公开所要求保护的范围之内。