1.本技术涉及测试技术领域以及其他相关技术领域，具体而言，涉及一种测试脚本的生成方法、装置及电子设备。
背景技术：2.随着信息技术的发展，越来越多的用户会根据自身的需求选择定制化的应用程序或者运行该应用程序的定制设备。其中，开发人员为了快速响应用户定制化的需求，通常会基于应用程序的全部代码提取出多个代码分支，例如，每个代码分支对应应用程序的一个功能。此外，根据用户的定制化需求，定制设备所搭载的平台也会存在多种选择。
3.对于每一个代码分支，进行编译生成安装镜像时，都需要通过设置标记区分，打包出用于不同平台的镜像，供不同平台的设备安装使用。而在对一个代码分支进行修改，或者新增了一个代码分支时，通常需要使用测试脚本对修改的代码分支或者新增的代码分支进行测试，以保证功能的正常使用。
4.但是，现有技术在每个分支所对应的多个平台下都是单独维护测试脚本，从而导致即便是在一个分支的情况下，不同平台之间也会对应生成大量重复的测试脚本，使得测试脚本数量过多，进而造成了维护成本过高的问题。
技术实现要素：5.本技术实施例提供了一种测试脚本的生成方法、装置及电子设备，以至少解决现有技术中不同平台之间所对应的测试脚本数量过多，导致的测试脚本维护成本高的技术问题。
6.根据本技术实施例的一个方面，提供了一种测试脚本的生成方法，包括：从多个代码分支中确定目标分支，其中，代码分支为应用程序所对应的全部代码中的待测试代码，目标分支为多个代码分支中的任意一个代码分支；获取目标分支所对应的多个平台标识，其中，平台标识对应于运行目标分支的平台；根据目标分支与平台标识生成公用脚本以及多个函数库，其中，公用脚本为多个平台测试目标分支时所运行的公共测试脚本，每个函数库对应一个平台标识，函数库中包含多条函数，公用脚本通过调用函数库中的函数控制平台执行测试操作。
7.进一步地，测试脚本的生成方法还包括：检测多个平台中是否存在目标平台，其中，目标平台的测试流程与其他平台的测试流程之间存在差异，其他平台为多个平台中除目标平台之外的平台；在多个平台中存在目标平台的情况下，确定第一测试流程与第二测试流程之间的差异内容，其中，第一测试流程为目标平台的测试流程，第二测试流程为其他平台的测试流程；根据差异内容生成至少一个差异脚本；根据差异脚本生成第一标识以及第二标识，其中，第一标识用于表征差异脚本的生成时间，第二标识为目标平台的平台标识。
8.进一步地，测试脚本的生成方法还包括：在根据差异脚本生成第一标识以及第二
标识之后，在每个平台上分别执行公用脚本，并生成第一执行结果，其中，执行结果用于表征公用脚本在每个平台上是否执行成功；在目标平台上执行差异脚本，并生成第二执行结果，其中，第二执行结果用于表征差异脚本在目标平台上是否执行成功。
9.进一步地，测试脚本的生成方法还包括：在根据目标分支与平台标识生成公用脚本以及多个函数库之后，获取待测试设备的目标平台标识，其中，待测试设备上至少运行有目标分支，目标平台标识表征待测试设备上所搭载的平台；根据目标平台标识从多个函数库中确定待测试设备对应的目标函数库，并从公用脚本以及差异脚本中确定待测试设备对应的目标脚本；基于目标脚本以及目标函数库对待测试设备进行测试，生成测试结果。
10.进一步地，测试脚本的生成方法还包括：在根据目标分支与平台标识生成公用脚本以及多个函数库之后，检测当前平台的测试流程中是否存在新增测试流程；在检测到当前平台的测试流程中存在新增测试流程时，检测其他测试平台的测试流程中是否存在新增测试流程，其中，其他测试平台为多个平台中除当前平台之外的平台；在其他测试平台的测试流程中存在新增测试流程时，根据新增测试流程生成新的公用脚本。
11.进一步地，测试脚本的生成方法还包括：在根据目标分支与平台标识生成公用脚本以及多个函数库之后，检测当前平台的测试流程中是否存在更新内容；在检测到当前平台的测试流程中存在更新内容时，检测其他测试平台的测试流程中是否存在更新内容；在其他测试平台的测试流程中存在更新内容时，根据更新内容对公用脚本进行更新。
12.进一步地，测试脚本的生成方法还包括：在根据目标分支与平台标识生成公用脚本以及多个函数库之后，检测当前平台中的操作指令是否存在更新，其中，操作指令为当前平台在执行测试操作时生成的指令，操作指令与当前平台的函数库中的函数相对应；在当前平台的操作指令存在更新时，确定更新后的操作指令所对应的目标函数；基于目标函数对当前平台所对应的函数库进行更新。
13.根据本技术实施例的另一方面，还提供了一种测试脚本的生成装置，包括：确定模块，用于从多个代码分支中确定目标分支，其中，代码分支为应用程序所对应的全部代码中的待测试代码，目标分支为多个代码分支中的任意一个代码分支；获取模块，用于获取目标分支所对应的多个平台标识，其中，平台标识对应于运行目标分支的平台；生成模块，用于根据目标分支与平台标识生成公用脚本以及多个函数库，其中，公用脚本为多个平台测试目标分支时所运行的公共测试脚本，每个函数库对应一个平台标识，函数库中包含多条函数，公用脚本通过调用函数库中的函数控制平台执行测试操作。
14.根据本技术实施例的另一方面，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述的测试脚本的生成方法。
15.根据本技术实施例的另一方面，还提供了一种电子设备，该电子设备包括一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现用于运行程序，其中，程序被设置为运行时上述的测试脚本的生成方法。
16.在本技术中，采用根据目标分支与平台标识生成公用脚本以及多个函数库的方式，首先从多个代码分支中确定目标分支，其中，代码分支为应用程序所对应的全部代码中的待测试代码，目标分支为多个代码分支中的任意一个代码分支，然后获取目标分支所对
应的多个平台标识，其中，平台标识对应于运行目标分支的平台，最后根据目标分支与平台标识生成公用脚本以及多个函数库，其中，公用脚本为多个平台测试目标分支时所运行的公共测试脚本，每个函数库对应一个平台标识，函数库中包含多条函数，公用脚本通过调用函数库中的函数控制平台执行测试操作。
17.由上述内容可知，本技术中所生成的公用脚本为多个平台测试目标分支时所运行的公共测试脚本，换言之，本技术将多个平台所涉及到的重复的测试脚本只保留了一份，即公共测试脚本，从而不仅避免了测试脚本重复的问题，还减少了测试脚本的数量，进而降低了测试脚本的维护成本。此外，本技术通过根据平台标识一一对应地生成函数库，保证了函数库是基于平台进行独立维护的，从而在需要使用测试脚本对某一平台上的目标分支进行测试时，可以确保测试脚本准确无误地调用该平台所对应的函数库，进而提高了测试脚本的稳定性。
18.由此可见，通过本技术的技术方案，达到了减少测试脚本的数量的目的，从而实现了提高测试脚本的维护效率的技术效果，进而解决了现有技术中不同平台之间所对应的测试脚本数量过多，导致的测试脚本维护成本高的技术问题。
附图说明
19.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
20.图1是根据现有技术的一种代码分支的示意图；
21.图2是根据现有技术的一种测试脚本及函数库的生成方法的示意图；
22.图3是根据本技术实施例的一种可选的测试脚本的生成方法的流程图；
23.图4是根据本技术实施例的一种在每个代码分支中共用一套测试脚本的示意图；
24.图5是根据本技术实施例的一种可选的测试脚本的生成方法的示意图；
25.图6是根据本技术实施例的一种可选的文件存储方案示意图；
26.图7是根据本技术实施例的一种基于脚本管理系统创建测试脚本的示意图；
27.图8是根据本技术实施例的一种脚本管理系统中的脚本列表的示意图；
28.图9是根据本技术实施例的一种可选的测试脚本的生成装置示意图。
具体实施方式
29.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分的实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本技术保护的范围。
30.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于
清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
31.实施例1
32.随着信息技术的发展，越来越多的用户会根据自身的需求选择定制化的应用程序以及运行该应用程序的定制设备。其中，开发人员为了快速响应用户定制化的需求，通常会基于应用程序的全部代码提取出多个代码分支，例如，每个代码分支对应应用程序的一个功能。
33.其中，图1是根据现有技术的一种代码分支的示意图。如图1所示，在一个主线分支上，可以先按照需求提取大版本分支，例如图1中的r1分支、r2分支。在得到每个大版本分支之后，可以在大版本分支上提取修复分支，对版本问题进行修复处理，例如，图1中的p1分支。另外，还可以在大版本分支上提取用户新增的临时需求开发分支，对临时需求进行开发，例如，图1中的f1分支。对于一些高级别用户，有一些定制需求实现，同样需要提取独立的分支进行开发处理，例如，图1中的m1分支。最后，各个大版本分支会按照需求进行主线合入。其中，上述的r1分支、r2分支、p1分支、f1分支以及m1分支都属于代码分支。
34.此外，根据用户的定制化需求，定制设备所搭载的平台也会存在多种选择。例如，以网络通信设备为例，为了满足不同客户群体需要，网络通信设备可以选用不同架构芯片(如x86，np，多核等)、设计不同的处理器走线方式、支持不同的板卡类型以及裁剪不同的规格等，从而制造出多类型平台的设备。
35.需要注意到的是，基于图1的各个代码分支，进行编译生成安装镜像时，需要通过设置标记区分，打包出用于不同平台的镜像，供不同平台的设备安装使用。由此可见，当分支和平台繁多的情况下，分支与平台的组合结果将呈几何倍的增长。如下表1所示，在有m个平台、n个分支时，其分支与平台之间的组合可以有m*n个。
36.表1
37.分支/平台平台1平台2平台3平台4平台5
…
平台m分支1image1image2image3image4image5 image
…
分支2
ꢀꢀꢀꢀꢀꢀꢀ
分支3
ꢀꢀꢀꢀꢀꢀꢀ
分支4
ꢀꢀꢀꢀꢀꢀꢀ…ꢀꢀꢀꢀꢀꢀꢀ
分支n
ꢀꢀꢀꢀꢀꢀ
image m*n
38.而在对一个代码分支进行修改，或者新增了一个代码分支时，通常需要使用测试脚本对修改的代码分支或者新增的代码分支进行测试，以保证功能的正常使用。其中，自动化测试作为一种快速进行回归测试的有效手段，必须要覆盖上述所有组合的测试。而自动化测试所依赖的测试脚本的数量和以及函数库的数量是与分支的数量和平台的数量存在对应关系的，因此，在代码分支频繁拉取合入，各种平台日益增多的情况下，测试脚本和其依赖的函数库的数量和复杂性可想而知。
39.图2是根据现有技术的一种测试脚本及函数库的生成方法的示意图。如图2所示，对于每个代码分支，现有技术会先确定该代码分支所对应的多个平台，然后对每个平台独立维护一套测试脚本以及函数库。但是，在一个代码分支下，即便是不同的平台，通常也会
存在大量相同的测试流程，例如，对于平台1与平台2，两个平台都搭载了板卡a，则对于两个平台而言，关于板卡a的测试流程时相同的。但是在这种情况下，由于现有技术是对每个平台单独维护测试脚本的，因此，现有技术会针对平台1对应生成一个关于板卡a的测试脚本，还会针对平台2对应生成一个关于板卡a的测试脚本。由此可见，在现有技术中，即便是在一个分支的情况下，不同平台之间也会对应生成大量重复的测试脚本，在代码分支，平台组合数量很多的情况下时，现有技术所生成的数量更是几何倍的增长，从而会造成维护成本过高的问题。此外，当某个改动在所有的平台上发生时，需要对每个平台所对应的测试脚本进行重复修改，换言之，现有技术无法进行有效的代码复用。
40.为了解决上述问题，根据本技术实施例，提供了一种测试脚本的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。其中，一种脚本管理系统可以作为本技术实施例中的测试脚本的生成方法的执行主体。
41.图3是根据本技术实施例的一种可选的测试脚本的生成方法的流程图，如图3所示，该方法包括如下步骤：
42.步骤s301，从多个代码分支中确定目标分支。
43.在步骤s301中，代码分支为应用程序所对应的全部代码中的待测试代码，目标分支为多个代码分支中的任意一个代码分支。具体的，以图1中的r1分支、r2分支、p1分支、f1分支以及m1分支为例，这些代码分支在被提取出来之后，都需要在不同的平台上进行测试，例如，由于p1分支是对版本问题进行修复处理的代码分支，因此，只有在对p1分支进行测试之后，才可以确定通过p1分支是否能够将版本问题进行修复。
44.另外，上述的目标分支可以是多个代码分支中的任意一个代码分支。由于多个代码分支之间相对独立，同一个功能，同时在多个代码分支上进行合入的情况较少，并且，随着时间的推移，通常旧的代码分支将不再维护，实际在维护的代码分支的数量相对固定，不会面临代码分支数量日益膨胀的问题。因此，本技术选择将各个代码分支的测试脚本、函数库进行独立维护，以提高每个代码分支下的测试脚本的稳定性。
45.为了更好的说明，以下以一个代码分支，即目标分支为例进行说明。
46.步骤s302，获取目标分支所对应的多个平台标识。
47.在步骤s302中，平台标识对应于运行目标分支的平台。具体的，一个平台标识与一种平台相对应。例如，以网络通信产品为例，为了满足不同客户群体需要，可以选用不同的架构芯片(如x86，np，多核等)、设计不同的处理器走线方式、支持不同的板卡类型以及裁剪不同的规格等，从而产出多平台的网络通信产品。其中，网络通信产品可以是工控计算机、台式计算机、笔记本计算机、防火墙设备以及服务器等网络通信设备。
48.步骤s303，根据目标分支与平台标识生成公用脚本以及多个函数库。
49.在步骤s303中，公用脚本为多个平台测试目标分支时所运行的公共测试脚本，每个函数库对应一个平台标识，函数库中包含多条函数，公用脚本通过调用函数库中的函数控制平台执行测试操作。
50.具体的，现有技术中是由于不同平台之间重复的测试脚本过多，从而导致的测试脚本数量大，维护成本高的问题。因此，为了解决现有技术的问题，需要避免产生重复的测
试脚本。其中，图4示出了一种在每个代码分支中共用一套测试脚本的示意图。如图4所示，在每个代码分支中，分别生成一套公用脚本以及一套函数库，其中，公用脚本可以用于表征多个平台在测试目标分支时所要执行的相同的测试流程。举例而言，有3个平台，分别为平台1、平台2以及平台3，其中，每个平台上都搭载了板卡a，在此基础上，对于3个平台而言，其关于对板卡a的测试流程是相同的，因此，针对板卡a的测试流程，只需要生成一个公用脚本即可，从而避免了重复的测试脚本的生成，降低了维护成本，实现了代码的可复用性。
51.另外，图4中还通过一套函数库实现对所有平台所对应的函数的维护，具体的，在函数库中通过if/else流程来区分不同的平台，例如，在图4中的函数库1中if平台＝1，则执行平台1对应的相关函数；else if平台＝2，则执行平台2对应的相关函数。
52.需要注意的是，图4中的一套公用脚本中可能存在脚本1、脚本2等多个公用脚本，这是因为在实际应用中，多个平台之间可能会存在多个相同的测试流程，例如，多个平台中同时存在板卡a、板卡b、板卡c，其中，每个板卡都会有对应的一种测试流程，进而会对应的生成三个公用脚本。同理，一套函数库中也可能会存在多个函数库。
53.另外，还需要注意到的是，虽然图4中通过公用脚本避免了测试脚本重复的问题，但是其在函数库中通过if/else流程来区分不同的平台，这种方式所构建的函数库中的函数数量会很多，而且由于存在大量的判断逻辑，会使得代码的可读性较差，难以维护，同时还容易出现判断错误的情况，导致测试脚本在调用相关函数时出现不稳定的问题。
54.基于上述问题，本技术在生成公用脚本的同时，选择基于每一种平台单独生成函数库，并独立进行维护，以避免由于大量使用if/else流程导致的测试脚本在测试过程中不稳定的问题。如图5所示，在目标分支下，脚本管理系统生成一套公用脚本，该公用脚本为多个平台测试目标分支时所运行的公共测试脚本，具体的，公用脚本的个数可根据多个平台之间相同的测试流程的个数来确定，如图5中的公用脚本1、公用脚本2。脚本管理系统还根据平台标识针对每个平台单独生成函数库，例如，针对于平台1，单独生成一个函数库1，其中，函数库1中包含有多条函数；针对于平台2，单独生成一个函数库2，其中，函数库2中包含有多条函数。在后续维护过程中，每个平台所对应的函数库也是独立进行维护的。
55.通过上述分析可知，本技术通过公用脚本可以最大化地实现代码复用，同时避免了在单个代码分支下，不同平台之间存在重复的测试脚本的问题，实现了减少测试脚本的数量的效果。另一方面，本技术将同分支下不同平台的函数库独立维护，实现了平台的差异化，从而避免了由于平台功能差异导致的脚本稳定性问题。例如，对于各个平台，由于其硬件架构不同，因此在编写测试脚本时，会存在命令行差异以及命令下发后的回显差异。因此，基于各个平台独立维护对应的函数库，可以有效隔离各个平台的测试，从而保证测试脚本的稳定性。比如，对于show_module函数，在有插槽的设备中的回显与无插槽的设备中的回显不同。即可以通过不同的show_module函数进行封装，返回相同的结构，供同一个脚本调用即可。
56.基于上述步骤s301至步骤s303的内容可知，在本技术中，采用根据目标分支与平台标识生成公用脚本以及多个函数库的方式，首先从多个代码分支中确定目标分支，其中，代码分支为应用程序所对应的全部代码中的待测试代码，目标分支为多个代码分支中的任意一个代码分支，然后获取目标分支所对应的多个平台标识，其中，平台标识对应于运行目标分支的平台，最后根据目标分支与平台标识生成公用脚本以及多个函数库，其中，公用脚
本为多个平台测试目标分支时所运行的公共测试脚本，每个函数库对应一个平台标识，函数库中包含多条函数，公用脚本通过调用函数库中的函数控制平台执行测试操作。
57.由上述内容可知，本技术中所生成的公用脚本为多个平台测试目标分支时所运行的公共测试脚本，换言之，本技术将多个平台所涉及到的重复的测试脚本只保留了一份，即公共测试脚本，从而不仅避免了测试脚本重复的问题，还减少了测试脚本的数量，进而降低了测试脚本的维护成本。此外，本技术通过根据平台标识一一对应地生成函数库，保证了函数库是基于平台进行独立维护的，从而在需要使用测试脚本对某一平台上的目标分支进行测试时，可以确保测试脚本准确无误地调用该平台所对应的函数库，进而提高了测试脚本的稳定性。
58.由此可见，通过本技术的技术方案，达到了减少测试脚本的数量的目的，从而实现了提高测试脚本的维护效率的技术效果，进而解决了现有技术中不同平台之间所对应的测试脚本数量过多，导致的测试脚本维护成本高的技术问题。
59.在一种可选的实施例中，脚本管理系统可以检测多个平台中是否存在目标平台，其中，目标平台的测试流程与其他平台的测试流程之间存在差异，其他平台为多个平台中除目标平台之外的平台。在多个平台中存在目标平台的情况下，脚本管理系统确定第一测试流程与第二测试流程之间的差异内容，其中，第一测试流程为目标平台的测试流程，第二测试流程为其他平台的测试流程。最后，脚本管理系统根据差异内容生成至少一个差异脚本；根据差异脚本生成第一标识以及第二标识，其中，第一标识用于表征差异脚本的生成时间，第二标识为目标平台的平台标识。
60.可选的，上述的目标平台可以是一个，也可以是多个。举例而言，多个平台可以是平台1、平台2以及平台3，其中，三个平台中都搭载有板卡a，因此，针对板卡a的测试流程，脚本管理系统可以生成一个公用脚本1。但是，平台1中还单独搭载有板卡b，而平台2与平台3中并没有搭载板卡b，因此，针对板卡b的测试流程，即可生成一个差异脚本，由于该差异脚本是适用于平台1的，因此该差异脚本的第二标识为平台1的平台标识。此外，根据差异脚本的生成时间，还可以生成一个第一标识，例如，时间戳，其中，该时间戳可以作为差异脚本的后缀。
61.可选的，如图5所示，在图5中，示出了支持不同平台的多个差异脚本，分别为差异脚本1、差异脚本2。
62.需要注意到的是，一个差异脚本可以同时支持多个平台，例如，如果上述的平台2后续也搭载了板卡b，则上述针对板卡b的测试流程生成的差异脚本也可以支持平台2。由此可见，无论是公用脚本还是差异脚本，通过脚本、分支、平台三个维度的结合，在脚本管理系统中具有唯一性，换言之，由于本技术通过为差异脚本设置了平台标记(即第二标识)，因此解决了存在少量无法在各个平台之间共用的测试用例的编写问题。
63.在一种可选的实施例中，在根据差异脚本生成第一标识以及第二标识之后，脚本管理系统会在每个平台上分别执行公用脚本，并生成第一执行结果，其中，执行结果用于表征公用脚本在每个平台上是否执行成功；脚本管理系统还会在目标平台上执行差异脚本，并生成第二执行结果，其中，第二执行结果用于表征差异脚本在目标平台上是否执行成功。
64.可选的，在生成得到公用脚本以及差异脚本之后，脚本管理系统需要先对公用脚本以及差异脚本进行验证，在验证通过之后，才会将公用脚本与差异脚本正式应用到对目
标分支以及运行有目标分支的待测试设备的测试过程中。由于对于公用脚本，一个公用脚本会支持所有平台；对于差异脚本，只会支持其中某个或者某几个平台。因此，脚本管理系统会将公用脚本与差异脚本进行分别验证。公用脚本需要在每个平台上进行执行，如果全部执行成功，则说明公用脚本适用于所有平台，如果在某一个平台上执行失败，则说明该公用脚本存在异常。差异脚本则只需要在对应的目标平台上进行执行即可，如果执行成功，则说明差异脚本处于正常状态，如果执行失败，则说明差异脚本存在异常。
65.通过对公用脚本和差异脚本进行验证，可以确保公用脚本与差异脚本与对应的平台相匹配，从而提高测试稳定性。
66.在一种可选的实施例中，在根据目标分支与平台标识生成公用脚本以及多个函数库之后，脚本管理系统首先获取待测试设备的目标平台标识，其中，待测试设备上至少运行有目标分支，目标平台标识表征待测试设备上所搭载的平台。然后，脚本管理系统根据目标平台标识从多个函数库中确定待测试设备对应的目标函数库，并从公用脚本以及差异脚本中确定待测试设备对应的目标脚本，最后，脚本管理系统基于目标脚本以及目标函数库对待测试设备进行测试，生成测试结果。
67.可选的，上述的待测试设备可以是防火墙设备、工控计算机、服务器以及边缘计算设备等网络通信设备，还可以是台式计算机、笔记本计算机等计算机设备。待测设备上可以搭载有多个平台中的任意一个平台，还可以运行代码分支中的任意一个分支，例如，目标分支。
68.通常而言，在发布了目标分支之后，需要对目标分支进行编译以及生成安装镜像，然后通过设置标记区分，打包出用于不同平台的镜像，供不同平台的产品安装使用。其中，产品可以是上述的待测试设备。以下以待测试设备上搭载的是平台1为例进行说明。
69.脚本管理系统首先通过获取目标平台标识，确定待测试设备所搭载的平台为平台1，然后脚本管理管理系统根据公用脚本和差异脚本的平台标识确定平台1对应的目标脚本。例如，由于公用脚本是适用于所有平台的，因此，平台1所对应的目标脚本中一定有公用脚本，另外，每个差异脚本的第二标识表示该差异脚本所支持的平台，因此，通过比对第二标识与目标平台标识是否相同，便可以确定平台1是否对应有差异脚本，以及在平台1对应有差异脚本时，确定该差异脚本也是目标脚本。
70.另外，由于每个平台下的函数库都是单独生成并维护的，因此，在确定了待测试设备所搭载的平台为平台1之后，脚本管理系统可直接确定平台1对应的目标函数库的位置，并将该位置加入python syspath系统路径中，随后目标脚本在被调用时会自动查找该路径下的目标函数库，以便完成对待测试设备的测试。在测试过程中，待测试设备会根据目标脚本的测试流程运行目标分支，以便检测目标分支在待测试设备中是否可以准确执行，在目标脚本的测试流程全部完成，并且测试结果符合预期要求的情况下，说明在待测试设备上，目标分支可以准确执行，同时脚本管理系统会标记目标脚本在平台1上已经通过测试。
71.在一种可选的实施例中，在根据目标分支与平台标识生成公用脚本以及多个函数库之后，脚本管理系统还会检测当前平台的测试流程中是否存在新增测试流程。在检测到当前平台的测试流程中存在新增测试流程时，脚本管理系统检测其他测试平台的测试流程中是否存在新增测试流程，其中，其他测试平台为多个平台中除当前平台之外的平台；在其他测试平台的测试流程中存在新增测试流程时，脚本管理系统根据新增测试流程生成新的
公用脚本。
72.可选的，当在所有的平台中新增某个功能时，该功能所对应的测试流程也需要在所有的平台中进行对应增加，基于这种情况，由于对于所有的平台而言，新增测试流程是相同的，因此，脚本管理系统只需要根据新增测试流程生成新的公用脚本即可，并且标记新的公用脚本支持所有的平台。
73.在一种可选的实施例中，在根据目标分支与平台标识生成公用脚本以及多个函数库之后，脚本管理系统还会检测当前平台的测试流程中是否存在更新内容。在检测到当前平台的测试流程中存在更新内容时，脚本管理系统检测其他测试平台的测试流程中是否存在更新内容，在其他测试的测试流程中存在更新内容时，脚本管理系统根据更新内容对公用脚本进行更新。
74.可选的，当某个功能在所有平台中发生改动时，如果是测试流程发生了改动，即测试流程中存在了更新内容，则脚本管理系统只需要对公用脚本进行更新即可。
75.在一种可选的实施例中，在根据目标分支与平台标识生成公用脚本以及多个函数库之后，脚本管理系统会检测当前平台中的操作指令是否存在更新，其中，操作指令为当前平台在执行测试操作时生成的指令，操作指令与当前平台的函数库中的函数相对应。在当前平台的操作指令存在更新时，脚本管理系统确定更新后的操作指令所对应的目标函数，并基于目标函数对当前平台所对应的函数库进行更新。
76.可选的，上述的操作指令可以是函数库中的函数对平台下发的命令行，当某一个平台上的命令行发生更新时，脚本管理系统首先会确定更新后的命令行所对应的目标函数，然后根据该目标函数对该平台所对应的函数库进行更新。
77.在一种可选的实施例中，如果是在不同的代码分支下需要对测试脚本以及函数库进行变更，则需要通过人工操作或者自动化工具，辅助实现批量覆盖等操作，考虑到处于活跃状态下的代码分支的数量有限，并且相对固定，此操作不会耗费过多的人力成本。
78.由上述分析可知，在本技术的技术方案中，通过测试脚本中只关注测试流程，测试函数库中实现功能封装，测试脚本调用测试函数库这种模式，将不同平台之间差异的测试流程通过差异脚本来表示，相同的测试流程通过公用脚本来表示，实现了最大化公用脚本的目的，避免了随着代码分支，平台组合的膨胀，测试脚本数量快速膨胀的问题。此外，通过增加差异脚本支持平台标记的功能，解决了存在少量无法在各个平台之间共用的测试用例的编写问题。与此同时，考虑到不同的代码分支之间差异较大，并且处于活跃状态的代码分支的数量相对固定且有限，因此将各个代码分支下的测试脚本、函数库独立维护，避免了各个代码分支下改动相互影响的问题，增强了测试脚本的稳定性。而且，考虑到单个代码分支下不同平台功能的差异性，在单个代码分支内，将各个平台的函数库进行独立维护，还可以避免不同平台功能差异导致的测试脚本稳定性差的问题。
79.在一种可选的实施例中，为了更好的对本技术的技术方案进行说明，以下对脚本管理系统的一种可选的数据表构建过程进行说明，具体如下：
80.首先构建脚本表。具体的，每个分支下，同样测试用例的脚本，命名相同：如script1。存储时，通过增加文件后缀进行区分。一个脚本表中，脚本名，文件后缀和分支三者组成唯一键。例如，下表2示出了一种脚本表。
81.表2
[0082][0083]
然后构建脚本支持平台表。具体的，对于公用脚本，一个脚本会支持所有平台。对于差异脚本，只会支持其中某个或者某几个平台。在脚本支持平台表中可以配置每个测试脚本与平台之间的对应关系，其中，“是否已测试通过”用于标识该测试脚本在支持平台上是否已测试通过。例如，下表3示出了一种脚本支持平台表。
[0084]
表3
[0085][0086]
最后构建函数库表，基于每个代码分支、平台维护一套独立的函数库。具体的，下表4示出了一种函数库表。
[0087]
表4
[0088][0089]
在一种可选的实施例中，图6示出了根据本技术实施例的一种可选的文件存储方案。如图6所示，在代码分支1下，单独存储一套公用脚本，其中，一套公用脚本中可以包括公用脚本1、公用脚本2、公用脚本3等多个公用脚本。与此同时，在代码分支1下，还会单独存储一套差异脚本，其中，一套差异脚本中可以包括差异脚本1、差异脚本2等多个差异脚本。最后，在代码分支下，还会根据每个平台单独维护对应的函数库，例如，平台1函数库与平台1相对应，平台2函数库与平台2相对应，平台3函数库与平台3相对应。
[0090]
在一种可选的实施例中，为了进一步地对本技术的技术方案进行说明，以下根据一种脚本管理系统进行操作说明。
[0091]
首先，图7示出了基于脚本管理系统创建测试脚本的示意图，如图7所示，对于新创建的脚本，需要指定其所属的代码分支，并标记其支持哪些平台(可支持多选)。测试脚本在保存时，需要确保测试脚本名+代码分支+支持平台是一个唯一值。
[0092]
图8示出了一种脚本列表，在该脚本列表中，包括多个列表项，分别用于过滤代码分支、过滤支持平台、显示测试脚本支持的平台以及显示未测试的平台。此外，对于同一个测试脚本，可能同时支持多个平台，如图8所示，对于脚本1，对应的代码分支为分支1，支持的平台可以是平台1以及平台2。
[0093]
另外，脚本管理系统还可以提供代码分支克隆的功能。具体的，脚本管理系统提供分支克隆入口，操作人员可以选择新的代码分支拷贝自哪个原有的代码分支，从而进行对原有的代码分支的全平台克隆，脚本管理系统还可以提供克隆日志以便操作人员随时查看。
[0094]
由上述内容可知，单个代码分支下的测试脚本可分为公用脚本和差异脚本。其中，公用脚本最大可能的实现了代码复用。此外，通过对单个分支下不同平台的函数库独立维护，实现了平台的差异化，避免了由于平台功能差异导致的脚本稳定性差的问题。最后，通过对不同的代码分支下的测试脚本进行独立维护，既保证了不同代码分支下的测试脚本的测试隔离性和稳定性，又因为旧的代码分支不断淘汰，活跃的代码分支数量有限，从而避免了脚本数量膨胀的问题。
[0095]
实施例2
[0096]
根据本技术实施例，还提供了一种测试脚本的生成装置的实施例，其中，图9是根据本技术实施例的一种可选的测试脚本的生成装置示意图，如图9所示，该装置包括：确定模块901、获取模块902以及生成模块903。
[0097]
其中，确定模块901，用于从多个代码分支中确定目标分支，其中，代码分支为应用程序所对应的全部代码中的待测试代码，目标分支为多个代码分支中的任意一个代码分支。具体的，以图1中的r1分支、r2分支、p1分支、f1分支以及m1分支为例，这些代码分支在被提取出来之后，都需要在不同的平台上进行测试，例如，由于p1分支是对版本问题进行修复处理的代码分支，因此，只有在对p1分支进行测试之后，才可以确定通过p1分支是否能够将版本问题进行修复。
[0098]
另外，上述的目标分支可以是多个代码分支中的任意一个代码分支。由于多个代码分支之间相对独立，同一个功能，同时在多个代码分支上进行合入的情况较少，并且，随着时间的推移，通常旧的代码分支将不再维护，实际在维护的代码分支的数量相对固定，不会面临代码分支数量日益膨胀的问题。因此，本技术选择将各个代码分支的测试脚本、函数库进行独立维护，以提高每个代码分支下的测试脚本的稳定性。
[0099]
获取模块902，用于获取目标分支所对应的多个平台标识，其中，平台标识对应于运行目标分支的平台。具体的，一个平台标识与一种平台相对应。例如，以网络通信产品为例，为了满足不同客户群体需要，可以选用不同的架构芯片(如x86，np，多核等)、设计不同的处理器走线方式、支持不同的板卡类型以及裁剪不同的规格等，从而产出多平台的网络通信产品。其中，网络通信产品可以是工控计算机、台式计算机、笔记本计算机、防火墙设备以及服务器等网络通信设备。
[0100]
生成模块903，用于根据目标分支与平台标识生成公用脚本以及多个函数库，其中，公用脚本为多个平台测试目标分支时所运行的公共测试脚本，每个函数库对应一个平台标识，函数库中包含多条函数，公用脚本通过调用函数库中的函数控制平台执行测试操作。
[0101]
具体的，现有技术中是由于不同平台之间重复的测试脚本过多，从而导致的测试脚本数量大，维护成本高的问题。因此，为了解决现有技术的问题，需要避免产生重复的测试脚本。其中，图4示出了一种在每个代码分支中共用一套测试脚本的示意图。如图4所示，在每个代码分支中，分别生成一套公用脚本以及一套函数库，其中，公用脚本可以用于表征多个平台在测试目标分支时所要执行的相同的测试流程。举例而言，有3个平台，分别为平台1、平台2以及平台3，其中，每个平台上都搭载了板卡a，在此基础上，对于3个平台而言，其关于对板卡a的测试流程是相同的，因此，针对板卡a的测试流程，只需要生成一个公用脚本即可，从而避免了重复的测试脚本的生成，降低了维护成本，实现了代码的可复用性。
[0102]
另外，图4中还通过一套函数库实现对所有平台所对应的函数的维护，具体的，在函数库中通过if/else流程来区分不同的平台，例如，在图4中的函数库1中if平台＝1，则执行平台1对应的相关函数；else if平台＝2，则执行平台2对应的相关函数。
[0103]
需要注意的是，图4中的一套公用脚本中可能存在脚本1、脚本2等多个公用脚本，这是因为在实际应用中，多个平台之间可能会存在多个相同的测试流程，例如，多个平台中同时存在板卡a、板卡b、板卡c，其中，每个板卡都会有对应的一种测试流程，进而会对应的生成三个公用脚本。同理，一套函数库中也可能会存在多个函数库。
[0104]
另外，还需要注意到的是，虽然图4中通过公用脚本避免了测试脚本重复的问题，但是其在函数库中通过if/else流程来区分不同的平台，这种方式所构建的函数库中的函数数量会很多，而且由于存在大量的判断逻辑，会使得代码的可读性较差，难以维护，同时还容易出现判断错误的情况，导致测试脚本在调用相关函数时出现不稳定的问题。
[0105]
基于上述问题，本技术在生成公用脚本的同时，选择基于每一种平台单独生成函数库，并独立进行维护，以避免由于大量使用if/else流程导致的测试脚本在测试过程中不稳定的问题。如图5所示，在目标分支下，测试脚本的生成装置生成一套公用脚本，该公用脚本为多个平台测试目标分支时所运行的公共测试脚本，具体的，公用脚本的个数可根据多个平台之间相同的测试流程的个数来确定，如图5中的公用脚本1、公用脚本2。测试脚本的生成装置还根据平台标识针对每个平台单独生成函数库，例如，针对于平台1，单独生成一个函数库1，其中，函数库1中包含有多条函数；针对于平台2，单独生成一个函数库2，其中，函数库2中包含有多条函数。在后续维护过程中，每个平台所对应的函数库也是独立进行维护的。
[0106]
通过上述分析可知，本技术通过公用脚本可以最大化地实现代码复用，同时避免了在单个代码分支下，不同平台之间存在重复的测试脚本的问题，实现了减少测试脚本的数量的效果。另一方面，本技术将同分支下不同平台的函数库独立维护，实现了平台的差异化，从而避免了由于平台功能差异导致的脚本稳定性问题。例如，对于各个平台，由于其硬件架构不同，因此在编写测试脚本时，会存在命令行差异以及命令下发后的回显差异。因此，基于各个平台独立维护对应的函数库，可以有效隔离各个平台的测试，从而保证测试脚本的稳定性。比如，对于show_module函数，在有插槽的设备中的回显与无插槽的设备中的回显不同。即可以通过不同的show_module函数进行封装，返回相同的结构，供同一个脚本调用即可。
[0107]
基于上述分析可知，在本技术中，采用根据目标分支与平台标识生成公用脚本以及多个函数库的方式，首先从多个代码分支中确定目标分支，其中，代码分支为应用程序所
对应的全部代码中的待测试代码，目标分支为多个代码分支中的任意一个代码分支，然后获取目标分支所对应的多个平台标识，其中，平台标识对应于运行目标分支的平台，最后根据目标分支与平台标识生成公用脚本以及多个函数库，其中，公用脚本为多个平台测试目标分支时所运行的公共测试脚本，每个函数库对应一个平台标识，函数库中包含多条函数，公用脚本通过调用函数库中的函数控制平台执行测试操作。
[0108]
由上述内容可知，本技术中所生成的公用脚本为多个平台测试目标分支时所运行的公共测试脚本，换言之，本技术将多个平台所涉及到的重复的测试脚本只保留了一份，即公共测试脚本，从而不仅避免了测试脚本重复的问题，还减少了测试脚本的数量，进而降低了测试脚本的维护成本。此外，本技术通过根据平台标识一一对应地生成函数库，保证了函数库是基于平台进行独立维护的，从而在需要使用测试脚本对某一平台上的目标分支进行测试时，可以确保测试脚本准确无误地调用该平台所对应的函数库，进而提高了测试脚本的稳定性。
[0109]
由此可见，通过本技术的技术方案，达到了减少测试脚本的数量的目的，从而实现了提高测试脚本的维护效率的技术效果，进而解决了现有技术中不同平台之间所对应的测试脚本数量过多，导致的测试脚本维护成本高的技术问题。
[0110]
可选的，测试脚本的生成装置还包括：检测模块、第一确定模块以及第一生成模块以及第二生成模块。其中，检测模块，用于检测多个平台中是否存在目标平台，其中，目标平台的测试流程与其他平台的测试流程之间存在差异，其他平台为多个平台中除目标平台之外的平台；第一确定模块，用于在多个平台中存在目标平台的情况下，确定第一测试流程与第二测试流程之间的差异内容，其中，第一测试流程为目标平台的测试流程，第二测试流程为其他平台的测试流程；第一生成模块，用于根据差异内容生成至少一个差异脚本；第二生成模块，用于根据差异脚本生成第一标识以及第二标识，其中，第一标识用于表征差异脚本的生成时间，第二标识为目标平台的平台标识。
[0111]
可选的，上述的目标平台可以是一个，也可以是多个。举例而言，多个平台可以是平台1、平台2以及平台3，其中，三个平台中都搭载有板卡a，因此，针对板卡a的测试流程，测试脚本的生成装置可以生成一个公用脚本1。但是，平台1中还单独搭载有板卡b，而平台2与平台3中并没有搭载板卡b，因此，针对板卡b的测试流程，即可生成一个差异脚本，由于该差异脚本是适用于平台1的，因此该差异脚本的第二标识为平台1的平台标识。此外，根据差异脚本的生成时间，还可以生成一个第一标识，例如，时间戳，其中，该时间戳可以作为差异脚本的后缀。
[0112]
可选的，如图5所示，在图5中，示出了支持不同平台的多个差异脚本，分别为差异脚本1、差异脚本2。
[0113]
需要注意到的是，一个差异脚本可以同时支持多个平台，例如，如果上述的平台2后续也搭载了板卡b，则上述针对板卡b的测试流程生成的差异脚本也可以支持平台2。由此可见，无论是公用脚本还是差异脚本，通过脚本、分支、平台三个维度的结合，在测试脚本的生成装置中具有唯一性，换言之，由于本技术通过为差异脚本设置了平台标记(即第二标识)，因此解决了存在少量无法在各个平台之间共用的测试用例的编写问题。可选的，测试脚本的生成装置还包括：第一执行模块以及第二执行模块。其中，第一执行模块，用于在每个平台上分别执行公用脚本，并生成第一执行结果，其中，执行结果用于表征公用脚本在每
个平台上是否执行成功；第二执行模块，用于在目标平台上执行差异脚本，并生成第二执行结果，其中，第二执行结果用于表征差异脚本在目标平台上是否执行成功。可选的，在生成得到公用脚本以及差异脚本之后，需要先对公用脚本以及差异脚本进行验证，在验证通过之后，才会将公用脚本与差异脚本正式应用到对目标分支以及运行有目标分支的待测试设备的测试过程中。由于对于公用脚本，一个公用脚本会支持所有平台；对于差异脚本，只会支持其中某个或者某几个平台。因此，公用脚本需要在每个平台上进行执行，如果全部执行成功，则说明公用脚本适用于所有平台，如果在某一个平台上执行失败，则说明该公用脚本存在异常。差异脚本则只需要在对应的目标平台上进行执行即可，如果执行成功，则说明差异脚本处于正常状态，如果执行失败，则说明差异脚本存在异常。
[0114]
通过对公用脚本和差异脚本进行验证，可以确保公用脚本与差异脚本与对应的平台相匹配，从而提高测试稳定性。
[0115]
可选的，测试脚本的生成装置还包括：第一获取模块、第二确定模块以及测试模块。其中，第一获取模块，用于获取待测试设备的目标平台标识，其中，待测试设备上至少运行有目标分支，目标平台标识表征待测试设备上所搭载的平台；第二确定模块，用于根据目标平台标识从多个函数库中确定待测试设备对应的目标函数库，并从公用脚本以及差异脚本中确定待测试设备对应的目标脚本；测试模块，用于基于目标脚本以及目标函数库对待测试设备进行测试，生成测试结果。
[0116]
可选的，上述的待测试设备可以是防火墙设备、工控计算机、服务器以及边缘计算设备等网络通信设备，还可以是台式计算机、笔记本计算机等计算机设备。待测设备上可以搭载有多个平台中的任意一个平台，还可以运行代码分支中的任意一个分支，例如，目标分支。
[0117]
通常而言，在发布了目标分支之后，需要对目标分支进行编译以及生成安装镜像，然后通过设置标记区分，打包出用于不同平台的镜像，供不同平台的产品安装使用。其中，产品可以是上述的待测试设备。以下以待测试设备上搭载的是平台1为例进行说明。
[0118]
首先通过获取目标平台标识，确定待测试设备所搭载的平台为平台1，然后根据公用脚本和差异脚本的平台标识确定平台1对应的目标脚本。例如，由于公用脚本是适用于所有平台的，因此，平台1所对应的目标脚本中一定有公用脚本，另外，每个差异脚本的第二标识表示该差异脚本所支持的平台，因此，通过比对第二标识与目标平台标识是否相同，便可以确定平台1是否对应有差异脚本，以及在平台1对应有差异脚本时，确定该差异脚本也是目标脚本。
[0119]
另外，由于每个平台下的函数库都是单独生成并维护的，因此，在确定了待测试设备所搭载的平台为平台1之后，可直接确定平台1对应的目标函数库的位置，并将该位置加入python syspath系统路径中，随后目标脚本在被调用时会自动查找该路径下的目标函数库，以便完成对待测试设备的测试。在测试过程中，待测试设备会根据目标脚本的测试流程运行目标分支，以便检测目标分支在待测试设备中是否可以准确执行，在目标脚本的测试流程全部完成，并且测试结果符合预期要求的情况下，说明在待测试设备上，目标分支可以准确执行，同时测试脚本的生成装置还会标记目标脚本在平台1上已经通过测试。
[0120]
可选的，测试脚本的生成装置还包括：第一检测模块、第二检测模块以及第三生成模块。其中，第一检测模块，用于检测当前平台的测试流程中是否存在新增测试流程；第二
检测模块，用于在检测到当前平台的测试流程中存在新增测试流程时，检测其他测试平台的测试流程中是否存在新增测试流程，其中，其他测试平台为多个平台中除当前平台之外的平台；第三检测模块，用于在其他测试平台的测试流程中存在新增测试流程时，根据新增测试流程生成新的公用脚本。
[0121]
可选的，当在所有的平台中新增某个功能时，该功能所对应的测试流程也需要在所有的平台中进行对应增加，基于这种情况，由于对于所有的平台而言，新增测试流程是相同的，因此，测试脚本的生成装置只需要根据新增测试流程生成新的公用脚本即可，并且标记新的公用脚本支持所有的平台。
[0122]
可选的，测试脚本的生成装置还包括：第三检测模块、第四检测模块以及更新模块。其中，第三检测模块，用于检测当前平台的测试流程中是否存在更新内容；第四检测模块，用于在检测到当前平台的测试流程中存在更新内容时，检测其他测试平台的测试流程中是否存在更新内容；更新模块，用于在其他测试的测试流程中存在更新内容时，根据更新内容对公用脚本进行更新。
[0123]
可选的，当某个功能在所有平台中发生改动时，如果是测试流程发生了改动，即测试流程中存在了更新内容，则测试脚本的生成装置只需要对公用脚本进行更新即可。
[0124]
可选的，测试脚本的生成装置还包括：第五检测模块、第三确定模块以及第一更新模块。其中，第五检测模块，用于检测当前平台中的操作指令是否存在更新，其中，操作指令为当前平台在执行测试操作时生成的指令，操作指令与当前平台的函数库中的函数相对应；第三确定模块，用于在当前平台的操作指令存在更新时，确定更新后的操作指令所对应的目标函数；第一更新模块，用于基于目标函数对当前平台所对应的函数库进行更新。
[0125]
可选的，上述的操作指令可以是函数库中的函数对平台下发的命令行，当某一个平台上的命令行发生更新时，测试脚本的生成装置首先会确定更新后的命令行所对应的目标函数，然后根据该目标函数对该平台所对应的函数库进行更新。
[0126]
在一种可选的实施例中，如果是在不同的代码分支下需要对测试脚本以及函数库进行变更，则需要通过人工操作或者自动化工具，辅助实现批量覆盖等操作，考虑到处于活跃状态下的代码分支的数量有限，并且相对固定，此操作不会耗费过多的人力成本。
[0127]
由上述分析可知，在本技术的技术方案中，通过测试脚本中只关注测试流程，测试函数库中实现功能封装，测试脚本调用测试函数库这种模式，将不同平台之间差异的测试流程通过差异脚本来表示，相同的测试流程通过公用脚本来表示，实现了最大化公用脚本的目的，避免了随着代码分支，平台组合的膨胀，测试脚本数量快速膨胀的问题。此外，通过增加差异脚本支持平台标记的功能，解决了存在少量无法在各个平台之间共用的测试用例的编写问题。与此同时，考虑到不同的代码分支之间差异较大，并且处于活跃状态的代码分支的数量相对固定且有限，因此将各个代码分支下的测试脚本、函数库独立维护，避免了各个代码分支下改动相互影响的问题，增强了测试脚本的稳定性。而且，考虑到单个代码分支下不同平台功能的差异性，在单个代码分支内，将各个平台的函数库进行独立维护，还可以避免不同平台功能差异导致的测试脚本稳定性差的问题。
[0128]
实施例3
[0129]
根据本技术实施例的另一方面，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述实施例1中的
测试脚本的生成方法。
[0130]
实施例4
[0131]
根据本技术实施例的另一方面，还提供了一种电子设备，该电子设备包括一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现用于运行程序，其中，程序被设置为运行时执行上述实施例1中的测试脚本的生成方法。
[0132]
上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
[0133]
在本技术的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
[0134]
在本技术所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
[0135]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0136]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0137]
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
[0138]
以上所述仅是本技术的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。
技术特征：1.一种测试脚本的生成方法，其特征在于，包括：从多个代码分支中确定目标分支，其中，所述代码分支为应用程序所对应的全部代码中的待测试代码，所述目标分支为所述多个代码分支中的任意一个代码分支；获取所述目标分支所对应的多个平台标识，其中，所述平台标识对应于运行所述目标分支的平台；根据所述目标分支与所述平台标识生成公用脚本以及多个函数库，其中，所述公用脚本为多个平台测试所述目标分支时所运行的公共测试脚本，每个所述函数库对应一个所述平台标识，所述函数库中包含多条函数，所述公用脚本通过调用所述函数库中的函数控制所述平台执行测试操作。2.根据权利要求1所述的方法，其特征在于，所述方法还包括：检测所述多个平台中是否存在目标平台，其中，所述目标平台的测试流程与其他平台的测试流程之间存在差异，所述其他平台为所述多个平台中除所述目标平台之外的平台；在所述多个平台中存在所述目标平台的情况下，确定第一测试流程与第二测试流程之间的差异内容，其中，所述第一测试流程为所述目标平台的测试流程，所述第二测试流程为所述其他平台的测试流程；根据所述差异内容生成至少一个差异脚本；根据所述差异脚本生成第一标识以及第二标识，其中，所述第一标识用于表征所述差异脚本的生成时间，所述第二标识为所述目标平台的平台标识。3.根据权利要求2所述的方法，其特征在于，在根据所述差异脚本生成第一标识以及第二标识之后，所述方法还包括：在每个平台上分别执行所述公用脚本，并生成第一执行结果，其中，所述第一执行结果用于表征所述公用脚本在所述每个平台上是否执行成功；在所述目标平台上执行所述差异脚本，并生成第二执行结果，其中，所述第二执行结果用于表征所述差异脚本在所述目标平台上是否执行成功。4.根据权利要求2所述的方法，其特征在于，在根据所述目标分支与所述平台标识生成公用脚本以及多个函数库之后，所述方法还包括：获取待测试设备的目标平台标识，其中，所述待测试设备上至少运行有目标分支，所述目标平台标识表征所述待测试设备上所搭载的平台；根据所述目标平台标识从所述多个函数库中确定所述待测试设备对应的目标函数库，并从所述公用脚本以及所述差异脚本中确定所述待测试设备对应的目标脚本；基于所述目标脚本以及所述目标函数库对所述待测试设备进行测试，生成测试结果。5.根据权利要求1-3中任意一项所述的方法，其特征在于，在根据所述目标分支与所述平台标识生成公用脚本以及多个函数库之后，所述方法还包括：检测当前平台的测试流程中是否存在新增测试流程；在检测到所述当前平台的测试流程中存在所述新增测试流程时，检测其他测试平台的测试流程中是否存在所述新增测试流程，其中，所述其他测试平台为所述多个平台中除所述当前平台之外的平台；在所述其他测试平台的测试流程中存在所述新增测试流程时，根据所述新增测试流程生成新的公用脚本。
6.根据权利要求1-3中任意一项所述的方法，其特征在于，在根据所述目标分支与所述平台标识生成公用脚本以及多个函数库之后，所述方法还包括：检测当前平台的测试流程中是否存在更新内容；在检测到所述当前平台的测试流程中存在所述更新内容时，检测其他测试平台的测试流程中是否存在所述更新内容；在所述其他测试平台的测试流程中存在所述更新内容时，根据所述更新内容对所述公用脚本进行更新。7.根据权利要求1-3中任意一项所述的方法，其特征在于，在根据所述目标分支与所述平台标识生成公用脚本以及多个函数库之后，所述方法还包括：检测当前平台中的操作指令是否存在更新，其中，所述操作指令为所述当前平台在执行测试操作时生成的指令，所述操作指令与所述当前平台的函数库中的函数相对应；在所述当前平台的操作指令存在更新时，确定更新后的操作指令所对应的目标函数；基于所述目标函数对所述当前平台所对应的函数库进行更新。8.一种测试脚本的生成装置，其特征在于，包括：确定模块，用于从多个代码分支中确定目标分支，其中，所述代码分支为应用程序所对应的全部代码中的待测试代码，所述目标分支为所述多个代码分支中的任意一个代码分支；获取模块，用于获取所述目标分支所对应的多个平台标识，其中，所述平台标识对应于运行所述目标分支的平台；生成模块，用于根据所述目标分支与所述平台标识生成公用脚本以及多个函数库，其中，所述公用脚本为多个平台测试所述目标分支时所运行的公共测试脚本，每个所述函数库对应一个所述平台标识，所述函数库中包含多条函数，所述公用脚本通过调用所述函数库中的函数控制所述平台执行测试操作。9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1-7任一项中所述的测试脚本的生成方法。10.一种电子设备，其特征在于，所述电子设备包括一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现用于运行程序，其中，所述程序被设置为运行时执行所述权利要求1-7任一项中所述的测试脚本的生成方法。
技术总结本申请公开了一种测试脚本的生成方法、装置及电子设备。其中，该方法包括：从多个代码分支中确定目标分支，其中，代码分支为应用程序所对应的全部代码中的待测试代码，目标分支为多个代码分支中的任意一个代码分支；获取目标分支所对应的多个平台标识，其中，平台标识对应于运行目标分支的平台；根据目标分支与平台标识生成公用脚本以及多个函数库，其中，公用脚本为多个平台测试目标分支时所运行的公共测试脚本，每个函数库对应一个平台标识，函数库中包含多条函数，公用脚本通过调用函数库中的函数控制平台执行测试操作。本申请解决了现有技术中不同平台之间所对应的测试脚本数量过多，导致的测试脚本维护成本高的技术问题。导致的测试脚本维护成本高的技术问题。导致的测试脚本维护成本高的技术问题。
技术研发人员：秦亭亭 张宇 嵇雯雯 马美晓 张峰
受保护的技术使用者：山石网科通信技术股份有限公司
技术研发日：2022.06.22
技术公布日：2022/11/1
