测试脚本的生成方法以及生成装置与流程

1.本技术涉及生成测试脚本领域，具体而言，涉及一种测试脚本的生成方法、生成装置、计算机可读存储介质、处理器以及电子设备。


背景技术：

2.随着微服务框架的推广，接口自动化测试成为开发运维一体化模式中必不可少的环节，如何快速编写更新接口自动化测试脚本成为测试人员的首要任务。
3.业界通用的自动化测试工具往往采用即编写即生成测试脚本文件的机制。以jmeter(压力测试工具)为例：
4.步骤1，测试人员新建一个计划时，后台就自动创建一个xml(extensible markup language，可扩展置标语言)格式的jmx(java management extensions，java管理扩展)脚本文件；
5.步骤2，在计划上面添加组件，如取样器、前置处理器、后置处理器、断言、逻辑控制器等，后台jmx脚本文件会即时新增相应的xml标签项，此时项值为空；
6.步骤3，填写组件属性值，后台xml标签项也被同步赋值；
7.步骤4，编写完成点击保存即生成可执行的测试脚本；
8.步骤5，无论脚本简单还是复杂、包含单个接口还是多个接口，都以单个jmx文件方式存储于后台；
9.步骤6，执行测试脚本时，直接调用步骤5中的jmx文件即可。
10.业界通用的接口自动化测试工具往往采用即配置即生成测试脚本文件的机制，这种机制的缺点是对于多接口组合测试场景，更新测试脚本的成本过高。多接口组合场景是由多个单接口按照一定的业务逻辑串联而成，当某个单接口发生变更时，由于上述机制，所有涉及此接口业务逻辑的多接口组合场景测试脚本都需要逐一进行更新。
11.如图1所示，多接口组合测试脚本1由接口a和接口b组成，脚本2由接口b和接口c组成。由于在编写测试脚本时，接口b的组件和其属性是作为脚本文件的一部分被分别写入到脚本1和脚本2中的，所以当接口b发生变更时，脚本1和脚本2都需要测试人员逐个进行手动更新。这种一个接口对应多个测试脚本的情况在实际工作中很常见，采用上述脚本编写机制导致高昂的脚本更新维护成本。
12.在背景技术部分中公开的以上信息只是用来加强对本文所描述技术的背景技术的理解，因此，背景技术中可能包含某些信息，这些信息对于本领域技术人员来说并未形成在本国已知的现有技术。


技术实现要素：

13.本技术的主要目的在于提供一种测试脚本的生成方法、生成装置、计算机可读存储介质、处理器以及电子设备，以解决现有技术中多接口组合测试场景下，接口变更时脚本的维护成本较高的问题。
14.根据本发明实施例的一个方面，提供了一种测试脚本的生成方法，包括：获取多个接口的组件信息，并将各所述组件信息存储至组件库中；在接收到测试指令的情况下，根据所述测试指令以及所述组件库，生成目标测试脚本，其中，所述测试指令为表征执行目标测试脚本的指令，所述测试指令携带有测试用例。
15.可选地，根据所述测试指令以及所述组件库，生成目标测试脚本，包括：根据所述测试用例，从所述组件库中获取目标组件信息，其中，所述目标组件信息为执行所述测试用例所需的所述组件信息；根据所述目标组件信息，生成xml格式的所述目标测试脚本。
16.可选地，所述测试用例包括用例编号，根据所述测试用例，从所述组件库中获取目标组件信息，包括：创建测试计划；以所述测试计划为父节点，形成作为子节点的线程组节点；从所述组件库中获取所述用例编号对应的逻辑控制器以及取样器，并以所述线程组节点为所述父节点，分别形成作为子节点的逻辑控制器节点以及取样器节点；从所述组件库中依次获取所述取样器对应的第一请求头、第一前置处理器、第一后置处理器、第一参数以及第一断言，并以所述取样器节点为所述父节点，依次形成作为子节点的第一请求头节点、第一前置处理器节点、第一后置处理器节点、第一参数节点以及第一断言节点。
17.可选地，在从所述组件库中依次获取所述取样器对应的第一请求头、第一前置处理器、第一后置处理器、第一参数以及第一断言，并以所述取样器节点为所述父节点，依次形成作为子节点的第一请求头节点、第一前置处理器节点、第一后置处理器节点、第一参数节点以及第一断言节点之后，所述方法还包括：确定步骤，确定是否存在目标子节点，所述目标子节点为以所述逻辑控制器节点为所述父节点形成的、作为所述子节点的所述取样器节点，所述目标子节点对应的所述取样器为目标取样器；获取步骤，在存在所述目标子节点的情况下，从所述组件库中依次获取所述目标取样器对应的第二请求头、第二前置处理器、第二后置处理器、第二参数以及第二断言，并以所述目标子节点为所述父节点，依次形成作为子节点的第二请求头节点、第二前置处理器节点、第二后置处理器节点、第二参数节点以及第二断言节点；循环步骤，依次按照所述确定步骤以及所述获取步骤处理所有的所述目标子节点。
18.可选地，所述组件信息包括组件以及逻辑信息，所述逻辑信息为测试时各所述接口之间的逻辑关系，获取多个接口的组件信息，包括：获取各所述接口的接口信息；从各所述接口信息中提取对应的所述组件；获取各所述接口之间的所述逻辑关系。
19.可选地，所述组件库包括多个xml标签库，将各所述组件信息存储至组件库中，包括：获取映射关系表，所述映射关系表用于表征所述xml标签库与所述组件信息之间的对应关系；根据所述映射关系表，将各所述组件信息存储至对应的所述xml标签库中。
20.根据本发明实施例的另一方面，还提供了一种测试脚本的生成装置，包括：获取单元，用于获取多个接口的组件信息，并将各所述组件信息存储至组件库中；生成单元，用于在接收到测试指令的情况下，根据所述测试指令以及所述组件库，生成目标测试脚本，其中，所述测试指令为表征执行目标测试脚本的指令，所述测试指令携带有测试用例。
21.根据本发明实施例的再一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质包括存储的程序，其中，所述程序执行任意一种所述的方法。
22.本发明实施例的另一方面，还提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行任意一种所述的方法。
23.根据本发明实施例的又一方面，还提供了一种电子设备，包括：一个或多个处理器，存储器以及一个或多个程序，其中，所述一个或多个程序被存储在所述存储器中，并且被配置为由所述一个或多个处理器执行，所述一个或多个程序包括用于执行任意一种所述的方法。
24.采用本技术的实施例，所述的测试脚本的生成方法中，首先获取到多个接口的组件信息并将各个组件信息存储至组件库中，然后，在接收到执行目标测试脚本且携带有测试用例的测试指令的情况下，根据测试指令以及所述组件库，生成目标测试脚本。相比现有技术中即编写即生成测试脚本，造成多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，本技术通过将接口的组件信息存储至组件库中，在需要运行自动化测试脚本时，才从组件库中调用对应的组件信息生成测试脚本并运行，即编写时仅存储接口的组件信息，执行时才拼装组件信息生成脚本文件，组件信息的提取和脚本文件的生成是异步的，并且以组件库中的组件作为媒介，这样，在某个接口需要变更时，只需要变更组件库中该接口对应的组件信息即可，无需变更该接口对应的所有测试脚本的信息，可以批量的更新多接口组合测试场景下的脚本，从而解决了现有技术中多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，保证了自动化测试脚本的维护成本较低。
附图说明
25.构成本技术的一部分的说明书附图用来提供对本技术的进一步理解，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
26.图1示出了现有的多接口组合测试场景下接口与测试脚本的对应关系示意图；
27.图2示出了根据本技术的实施例的测试脚本的生成方法的流程示意图；
28.图3示出了根据本技术的实施例的测试脚本的方法原理示意图；
29.图4示出了根据本技术的实施例的测试脚本的生成装置的示意图。
30.其中，上述附图包括以下附图标记：
31.10、获取单元；20、生成单元。
具体实施方式
32.需要说明的是，在不冲突的情况下，本技术中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本技术。
33.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分的实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本技术保护的范围。
34.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清
楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
35.应该理解的是，当元件(诸如层、膜、区域、或衬底)描述为在另一元件“上”时，该元件可直接在该另一元件上，或者也可存在中间元件。而且，在说明书以及权利要求书中，当描述有元件“连接”至另一元件时，该元件可“直接连接”至该另一元件，或者通过第三元件“连接”至该另一元件。
36.正如背景技术中所说的，现有技术中的多接口组合测试场景下，接口变更时脚本的维护成本较高，为了解决上述问题，本技术的一种典型的实施方式中，提供了一种测试脚本的生成方法、生成装置、计算机可读存储介质、处理器以及电子设备。
37.根据本技术的实施例，提供了一种测试脚本的生成方法。
38.图2是根据本技术实施例的测试脚本的生成方法的流程图。如图2所示，该方法包括以下步骤：
39.步骤s101，获取多个接口的组件信息，并将各上述组件信息存储至组件库中；
40.步骤s102，在接收到测试指令的情况下，根据上述测试指令以及上述组件库，生成目标测试脚本，其中，上述测试指令为表征执行目标测试脚本的指令，上述测试指令携带有测试用例。
41.本技术上述的测试脚本的生成方法中，首先获取到多个接口的组件信息并将各个组件信息存储至组件库中，然后，在接收到执行目标测试脚本且携带有测试用例的测试指令的情况下，根据测试指令以及上述组件库，生成目标测试脚本。相比现有技术中即编写即生成测试脚本，造成多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，本技术通过将接口的组件信息存储至组件库中，在需要运行自动化测试脚本时，才从组件库中调用对应的组件信息生成测试脚本并运行，即编写时仅存储接口的组件信息，执行时才拼装组件信息生成脚本文件，组件信息的提取和脚本文件的生成是异步的，并且以组件库中的组件作为媒介，这样，在某个接口需要变更时，只需要变更组件库中该接口对应的组件信息即可，无需变更该接口对应的所有测试脚本的信息，可以批量的更新多接口组合测试场景下的脚本，从而解决了现有技术中多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，保证了自动化测试脚本的维护成本较低。
42.为了进一步解决在多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，根据本技术的一种具体实施例，根据上述测试指令以及上述组件库，生成目标测试脚本，包括：根据上述测试用例，从上述组件库中获取目标组件信息，其中，上述目标组件信息为执行上述测试用例所需的上述组件信息；根据上述目标组件信息，生成xml格式的上述目标测试脚本。本实施例中，根据测试用例来从组件库中获取执行上述测试用例所需的目标组件信息，再根据获取的上述目标组件信息，来生成xml格式的上述目标测试脚本，这样可以进一步地使得执行测试指令时才从组件库中获取组件信息生成脚本文件，进一步地实现了在执行时才生成自动化测试脚本，从而进一步地保证了自动化测试脚本的维护成本较低。
43.根据本技术的又一种具体实施例，上述测试用例包括用例编号，根据上述测试用例，从上述组件库中获取目标组件信息，包括：创建测试计划；以上述测试计划为父节点，形成作为子节点的线程组节点；从上述组件库中获取上述用例编号对应的逻辑控制器以及取样器，并以上述线程组节点为上述父节点，分别形成作为子节点的逻辑控制器节点以及取
样器节点；从上述组件库中依次获取上述取样器对应的第一请求头、第一前置处理器、第一后置处理器、第一参数以及第一断言，并以上述取样器节点为上述父节点，依次形成作为子节点的第一请求头节点、第一前置处理器节点、第一后置处理器节点、第一参数节点以及第一断言节点。在测试脚本执行时，脚本拼装器从组件库中读取组件信息，按照xml模板结构拼装生成测试脚本。测试脚本拼装按照先拼装外层再拼装内层的顺序进行，主要分为4个层级：最外层是测试计划，作为测试脚本的根节点，拼装全局配置、用户自定义参数、线程组；次外层是线程组，线程组是测试计划的开始点，在一个测试计划中的所有元件都必须在某个线程下，线程组用于封装取样器和逻辑控制器；第三层是取样器和逻辑控制器，来模拟用户的操作和业务流程；最内层是是请求头信息、前置处理器、后置处理器、断言和参数信息。本实施例中，依次从测试计划、线程组、取样器以及逻辑控制器、以及请求头、前置处理器、后置处理器、参数以及断言这4个层次来进行组件信息的拼接，即实现了从外层到内层的顺序层层拼接，从而进一步地保证了较为简单快捷且准确地得到xml格式的上述目标组件信息。
44.其中，上述测试计划作为测试脚本的根节点，拼装全局配置、用户自定义参数、线程组，上述线程组是测试计划的开始点，在一个测试计划中的所有元件都必须在某个线程下，线程组用于封装取样器和逻辑控制器，上述取样器和上述逻辑控制器用于模拟用户的操作和业务流程。
45.在实际的应用过程中，以上述线程组节点为上述父节点，分别形成作为子节点的逻辑控制器节点以及取样器节点的过程中，作为子节点的逻辑控制器节点是形成在上述线程组节点后的，作为子节点的取样器节点可以形成在上述线程组节点后，也可以形成在逻辑控制器节点后，即取样器节点为上述逻辑控制器的子节点，逻辑控制器为线程组节点的子节点，这种情况下，为了避免部分节点内容被忽略，从而避免得到的目标组件信息不完整，根据本技术的另一种具体实施例，在从上述组件库中依次获取上述取样器对应的第一请求头、第一前置处理器、第一后置处理器、第一参数以及第一断言，并以上述取样器节点为上述父节点，依次形成作为子节点的第一请求头节点、第一前置处理器节点、第一后置处理器节点、第一参数节点以及第一断言节点之后，上述方法还包括：确定步骤，确定是否存在目标子节点，上述目标子节点为以上述逻辑控制器节点为上述父节点形成的、作为上述子节点的上述取样器节点，上述目标子节点对应的上述取样器为目标取样器；获取步骤，在存在上述目标子节点的情况下，从上述组件库中依次获取上述目标取样器对应的第二请求头、第二前置处理器、第二后置处理器、第二参数以及第二断言，并以上述目标子节点为上述父节点，依次形成作为子节点的第二请求头节点、第二前置处理器节点、第二后置处理器节点、第二参数节点以及第二断言节点；循环步骤，依次按照上述确定步骤以及上述获取步骤处理所有的上述目标子节点。通过循环处理所有目标子节点，避免丢失内容，进一步地使得到的目标测试脚本比较准确完整。
46.一种具体的实施例中，根据上述测试用例，从上述组件库中获取目标组件信息的具体过程如下：
47.步骤s201：以测试计划作为根节点创建xml脚本对象。
48.步骤s202：以测试计划节点为父节点创建线程组子节点。
49.步骤s203：获取多接口组合场景测试用例信息。
50.步骤s204：根据测试用例id(identity document，身份标识号，即上述的用例编号)获取逻辑控制器信息，以线程组节点为父节点创建逻辑控制器子节点。
51.步骤s205：根据测试用例id获取取样器信息，以线程组节点为父节点创建取样器子节点，其中，上述取样器信息包括取样器id。
52.步骤s206：根据取样器id获取请求头信息，以取样器节点为父节点创建请求头子节点。
53.步骤s207：根据取样器id获取前置处理器信息，以取样器节点为父节点创建前置处理器子节点。
54.步骤s208：根据取样器id获取后置处理器信息，以取样器节点为父节点创建后置处理器子节点。
55.步骤s209：根据取样器id获取参数信息，以取样器节点为父节点创建参数子节点。
56.步骤s210：根据取样器id获取断言信息，以取样器节点为父节点创建检查点子节点。
57.步骤s211：根据步骤s204中的逻辑控制器id判断其是否有上述目标子节点对应的取样器，如若没有则退出，得到目标组件信息，如若有则以此逻辑控制器节点为父节点创建取样器子节点。
58.步骤s212：重复步骤s206至步骤s210，得到上述目标组件信息。
59.为了进一步地保证较为快捷方便地获取接口的组件信息，从而方便后续在需要运行自动化测试脚本时，从组件库中调用对应的组件信息生成测试脚本并运行，根据本技术的再一种具体实施例，上述组件信息包括组件以及逻辑信息，上述逻辑信息为测试时各上述接口之间的逻辑关系，获取多个接口的组件信息，包括：获取各上述接口的接口信息；从各上述接口信息中提取对应的上述组件；获取各上述接口之间的上述逻辑关系。
60.具体地，上述组件信息还包括上述接口的属性值。
61.在实际的应用过程中，拼装生成的测试脚本是符合一定规则的xml格式的文件，此时，为了进一步地方便后续在需要运行自动化测试脚本时，能从组件库中较为快捷且高效地调用到对应的组件信息，来生成测试脚本并运行，从而进一步地保证多接口组合测试场景下，接口变更时脚本的维护成本较低，根据本技术的一种具体实施例，上述组件库包括多个xml标签库，将各上述组件信息存储至组件库中，包括：获取映射关系表，上述映射关系表用于表征上述xml标签库与上述组件信息之间的对应关系；根据上述映射关系表，将各上述组件信息存储至对应的上述xml标签库中。将提取出来的组件存储进对应的库表中，通过xml标签库与组件信息之间的映射关系标表，在执行时只需要拼装组件就可以生成脚本文件，若接口变更也只需要变更组件库中该接口对应的组件信息即可，更加方便获取目标测试脚本，进一步降低了接口更新成本。
62.具体地，多接口组合测试场景下，当多个测试脚本引用同一个单接口时，只需要更新这个单接口的信息，组件库中关于这个接口的组件即被更新，从而实现批量更新所有引用此接口的测试脚本的目的，这种机制极大的降低了更新多接口组合测试脚本的成本。
63.其中，一种具体的实施例中，由于组件库是测试脚本拼装的数据源，而拼装生成的脚本是符合一定规则的xml格式的文件，因此在提取组件时需按照xml的模板结构进行，即按照xml模板的标签项进行提取以及组件提取规则，即上述映射关系表的具体内容xml拼装
模板的标签项与各组件的映射关系，如表1所示：
64.表1
[0065][0066][0067]
一种具体的实施例中，本技术的原理图如图3所示，通过对各个接口进行接口定义，得到多个接口对应的接口信息，在通过组件提取器来从接口信息中提取得到各接口信息中的组件以及属性值，通过逻辑控制器确定多接口组合的逻辑信息，组件、属性值以及逻辑信息构成组件信息，将这些组件信息存储至组件库中，在需要执行测试脚本的情况下，通过脚本拼接器从组件库中调取需要的组件信息进行拼装，得到测试脚本。在接口被更改时，只需要对组件库中接口对应的组件信息进行修改。
[0068]
需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
[0069]
本技术实施例还提供了一种测试脚本的生成装置，需要说明的是，本技术实施例的测试脚本的生成装置可以用于执行本技术实施例所提供的用于测试脚本的生成方法。以下对本技术实施例提供的测试脚本的生成装置进行介绍。
[0070]
图4是根据本技术实施例的测试脚本的生成装置的示意图。如图4所示，该装置包括获取单元10以及生成单元20，其中，上述获取单元10用于获取多个接口的组件信息，并将各上述组件信息存储至组件库中；上述生成单元20用于在接收到测试指令的情况下，根据上述测试指令以及上述组件库，生成目标测试脚本，其中，上述测试指令为表征执行目标测试脚本的指令，上述测试指令携带有测试用例。
[0071]
本技术采用一种测试脚本的生成装置，通过上述获取单元获取到多个接口的组件信息并将各个组件信息存储至组件中，通过上述生成单元在接收到执行目标测试脚本且携带有测试用例的测试指令的情况下，根据测试指令以及上述组件库，生成目标测试脚本。相比现有技术中即编写即生成测试脚本，造成多接口组合测试场景下，接口变更时脚本的维
护成本较高的问题，本技术通过将接口的组件信息存储至组件库中，在需要运行自动化测试脚本时，才从组件库中调用对应的组件信息生成测试脚本并运行，即编写时仅存储接口的组件信息，执行时才拼装组件信息生成脚本文件，组件信息的提取和脚本文件的生成是异步的，并且以组件库中的组件作为媒介，这样，在某个接口需要变更时，只需要变更组件库中该接口对应的组件信息即可，无需变更该接口对应的所有测试脚本的信息，可以批量的更新多接口组合测试场景下的脚本，从而解决了现有技术中多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，保证了自动化测试脚本的维护成本较低。
[0072]
为了进一步解决在多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，根据本技术的一种具体实施例，上述生成单元包括获取第一模块以及生成模块，其中，上述获取第一模块用于根据上述测试用例，从上述组件库中获取目标组件信息，其中，上述目标组件信息为执行上述测试用例所需的上述组件信息；上述生成模块用于根据上述目标组件信息，生成xml格式的上述目标测试脚本。本实施例中，根据测试用例来从组件库中获取执行上述测试用例所需的目标组件信息，再根据获取的上述目标组件信息，来生成xml格式的上述目标测试脚本，这样可以进一步地使得执行测试指令时才从组件库中获取组件信息生成脚本文件，进一步地实现了在执行时才生成自动化测试脚本，从而进一步地保证了自动化测试脚本的维护成本较低。
[0073]
根据本技术的又一种具体实施例，上述测试用例包括用例编号，上述获取第一模块包括创建子模块、形成第一子模块、形成第二子模块以及获取第一子模块，其中，上述创建子模块用于创建测试计划；上述形成第一子模块用于以上述测试计划为父节点，形成作为子节点的线程组节点；上述形成第二子模块用于从上述组件库中获取上述用例编号对应的逻辑控制器以及取样器，并以上述线程组节点为上述父节点，分别形成作为子节点的逻辑控制器节点以及取样器节点；上述获取第一子模块用于从上述组件库中依次获取上述取样器对应的第一请求头、第一前置处理器、第一后置处理器、第一参数以及第一断言，并以上述取样器节点为上述父节点，依次形成作为子节点的第一请求头节点、第一前置处理器节点、第一后置处理器节点、第一参数节点以及第一断言节点。在测试脚本执行时，脚本拼装器从组件库中读取组件信息，按照xml模板结构拼装生成测试脚本。测试脚本拼装按照先拼装外层再拼装内层的顺序进行，主要分为4个层级：最外层是测试计划，作为测试脚本的根节点，拼装全局配置、用户自定义参数、线程组；次外层是线程组，线程组是测试计划的开始点，在一个测试计划中的所有元件都必须在某个线程下，线程组用于封装取样器和逻辑控制器；第三层是取样器和逻辑控制器，来模拟用户的操作和业务流程；最内层是是请求头信息、前置处理器、后置处理器、断言和参数信息。本实施例中，依次从测试计划、线程组、取样器以及逻辑控制器、以及请求头、前置处理器、后置处理器、参数以及断言这4个层次来进行组件信息的拼接，即实现了从外层到内层的顺序层层拼接，从而进一步地保证了较为简单快捷且准确地得到xml格式的上述目标组件信息。
[0074]
其中，上述测试计划作为测试脚本的根节点，拼装全局配置、用户自定义参数、线程组，上述线程组是测试计划的开始点，在一个测试计划中的所有元件都必须在某个线程下，线程组用于封装取样器和逻辑控制器，上述取样器和上述逻辑控制器用于模拟用户的操作和业务流程。
[0075]
在实际的应用过程中，以上述线程组节点为上述父节点，分别形成作为子节点的
逻辑控制器节点以及取样器节点的过程中，作为子节点的逻辑控制器节点是形成在上述线程组节点后的，作为子节点的取样器节点可以形成在上述线程组节点后，也可以形成在逻辑控制器节点后，即取样器节点为上述逻辑控制器的子节点，逻辑控制器为线程组节点的子节点，这种情况下，为了避免部分节点内容被忽略，从而避免得到的目标组件信息不完整，根据本技术的另一种具体实施例，上述获取子模块还包括确定子模块、获取第二子模块以及循环子模块，其中，上述确定子模块用于确定步骤，确定是否存在目标子节点，上述目标子节点为以上述逻辑控制器节点为上述父节点形成的、作为上述子节点的上述取样器节点，上述目标子节点对应的上述取样器为目标取样器；上述获取第二子模块用于获取步骤，在存在上述目标子节点的情况下，从上述组件库中依次获取上述目标取样器对应的第二请求头、第二前置处理器、第二后置处理器、第二参数以及第二断言，并以上述目标子节点为上述父节点，依次形成作为子节点的第二请求头节点、第二前置处理器节点、第二后置处理器节点、第二参数节点以及第二断言节点；上述循环子模块用于循环步骤，依次按照上述确定步骤以及上述获取步骤处理所有的上述目标子节点。通过循环处理所有目标子节点，避免丢失内容，进一步地使得到的目标测试脚本比较准确完整。
[0076]
一种具体的实施例中，根据上述测试用例，从上述组件库中获取目标组件信息的具体过程如下：
[0077]
步骤s201：以测试计划作为根节点创建xml脚本对象。
[0078]
步骤s202：以测试计划节点为父节点创建线程组子节点。
[0079]
步骤s203：获取多接口组合场景测试用例信息。
[0080]
步骤s204：根据测试用例id获取逻辑控制器信息，以线程组节点为父节点创建逻辑控制器子节点。
[0081]
步骤s205：根据测试用例id获取取样器信息，以线程组节点为父节点创建取样器子节点,其中，上述取样器信息包括取样器id。
[0082]
步骤s206：根据取样器id获取请求头信息，以取样器节点为父节点创建请求头子节点。
[0083]
步骤s207：根据取样器id获取前置处理器信息，以取样器节点为父节点创建前置处理器子节点。
[0084]
步骤s208：根据取样器id获取后置处理器信息，以取样器节点为父节点创建后置处理器子节点。
[0085]
步骤s209：根据取样器id获取参数信息，以取样器节点为父节点创建参数子节点。
[0086]
步骤s210：根据取样器id获取断言信息，以取样器节点为父节点创建检查点子节点。
[0087]
步骤s211：根据步骤s204中的逻辑控制器id判断其是否有上述目标子节点对应的取样器，如若没有则退出，得到目标组件信息，如若有则以此逻辑控制器节点为父节点创建取样器子节点。
[0088]
步骤s212：重复步骤s206至步骤s210，得到上述目标组件信息。
[0089]
为了进一步地保证较为快捷方便地获取接口的组件信息，从而方便后续在需要运行自动化测试脚本时，从组件库中调用对应的组件信息生成测试脚本并运行，根据本技术的再一种具体实施例，上述组件信息包括组件以及逻辑信息，上述逻辑信息为测试时各上
述接口之间的逻辑关系，上述获取单元包括获取第二模块、提取模块以及获取第三模块，其中，上述获取第二模块用于获取各上述接口的接口信息；上述提取模块用于从各上述接口信息中提取对应的上述组件；上述获取第三模块用于获取各上述接口之间的上述逻辑关系。
[0090]
具体地，上述组件信息还包括上述接口的属性值。
[0091]
在实际的应用过程中，拼装生成的测试脚本是符合一定规则的xml格式的文件，此时，为了进一步地方便后续在需要运行自动化测试脚本时，能从组件库中较为快捷且高效地调用到对应的组件信息，来生成测试脚本并运行，从而进一步地保证多接口组合测试场景下，接口变更时脚本的维护成本较低，根据本技术的一种具体实施例，上述组件库包括多个xml标签库，上述获取单元包括获取第四模块以及存储模块，其中，上述获取第四模块用于获取映射关系表，上述映射关系表用于表征上述xml标签库与上述组件信息之间的对应关系；上述存储模块用于根据上述映射关系表，将各上述组件信息存储至对应的上述xml标签库中。将提取出来的组件存储进对应的库表中，通过xml标签库与组件信息之间的映射关系标表，在执行时只需要拼装组件就可以生成脚本文件，若接口变更也只需要变更组件库中该接口对应的组件信息即可，更加方便获取目标测试脚本，进一步降低了接口更新成本。
[0092]
具体地，多接口组合测试场景下，当多个测试脚本引用同一个单接口时，只需要更新这个单接口的信息，组件库中关于这个接口的组件即被更新，从而实现批量更新所有引用此接口的测试脚本的目的，这种机制极大的降低了更新多接口组合测试脚本的成本。
[0093]
其中，一种具体的实施例中，由于组件库是测试脚本拼装的数据源，而拼装生成的脚本是符合一定规则的xml格式的文件，因此在提取组件时需按照xml的模板结构进行，即按照xml模板的标签项进行提取以及组件提取规则，即上述映射关系表的具体内容xml拼装模板的标签项与各组件的映射关系，如表1所示。
[0094]
一种具体的实施例中，本技术的原理图如图3所示，通过对各个接口进行接口定义，得到多个接口对应的接口信息，在通过组件提取器来从接口信息中提取得到各接口信息中的组件以及属性值，通过逻辑控制器确定多接口组合的逻辑信息，组件、属性值以及逻辑信息构成组件信息，将这些组件信息存储至组件库中，在需要执行测试脚本的情况下，通过脚本拼接器从组件库中调取需要的组件信息进行拼装，得到测试脚本。在接口被更改时，只需要对组件库中接口对应的组件信息进行修改。
[0095]
上述测试脚本的生成装置包括处理器和存储器，上述获取单元以及上述生成单元等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。
[0096]
处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来解决现有技术中多接口组合测试场景下，接口变更时脚本的维护成本较高的问题。
[0097]
存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)，存储器包括至少一个存储芯片。
[0098]
本发明实施例提供了一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时实现上述测试脚本的生成方法。
[0099]
本发明实施例提供了一种处理器，上述处理器用于运行程序，其中，上述程序运行时执行上述测试脚本的生成方法。
[0100]
本发明实施例提供了一种设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现至少以下步骤：
[0101]
步骤s101，获取多个接口的组件信息，并将各上述组件信息存储至组件库中；
[0102]
步骤s102，在接收到测试指令的情况下，根据上述测试指令以及上述组件库，生成目标测试脚本，其中，上述测试指令为表征执行目标测试脚本的指令，上述测试指令携带有测试用例。
[0103]
本文中的设备可以是服务器、pc、pad、手机等。
[0104]
本技术还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有至少如下方法步骤的程序：
[0105]
步骤s101，获取多个接口的组件信息，并将各上述组件信息存储至组件库中；
[0106]
步骤s102，在接收到测试指令的情况下，根据上述测试指令以及上述组件库，生成目标测试脚本，其中，上述测试指令为表征执行目标测试脚本的指令，上述测试指令携带有测试用例。
[0107]
在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
[0108]
在本技术所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如上述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
[0109]
上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0110]
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0111]
上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例上述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
[0112]
从以上的描述中，可以看出，本技术上述的实施例实现了如下技术效果：
[0113]
1)、本技术的上述测试脚本的生成方法，首先获取到多个接口的组件信息并将各
个组件信息存储至组件库中，然后，在接收到执行目标测试脚本且携带有测试用例的测试指令的情况下，根据测试指令以及上述组件库，生成目标测试脚本。相比现有技术中即编写即生成测试脚本，造成多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，本技术通过将接口的组件信息存储至组件库中，在需要运行自动化测试脚本时，才从组件库中调用对应的组件信息生成测试脚本并运行，即编写时仅存储接口的组件信息，执行时才拼装组件信息生成脚本文件，组件信息的提取和脚本文件的生成是异步的，并且以组件库中的组件作为媒介，这样，在某个接口需要变更时，只需要变更组件库中该接口对应的组件信息即可，无需变更该接口对应的所有测试脚本的信息，可以批量的更新多接口组合测试场景下的脚本，从而解决了现有技术中多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，保证了自动化测试脚本的维护成本较低。
[0114]
2)、本技术的上述测试脚本的生成装置，通过上述获取单元获取到多个接口的组件信息并将各个组件信息存储至组件中，通过上述生成单元在接收到执行目标测试脚本且携带有测试用例的测试指令的情况下，根据测试指令以及上述组件库，生成目标测试脚本。相比现有技术中即编写即生成测试脚本，造成多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，本技术通过将接口的组件信息存储至组件库中，在需要运行自动化测试脚本时，才从组件库中调用对应的组件信息生成测试脚本并运行，即编写时仅存储接口的组件信息，执行时才拼装组件信息生成脚本文件，组件信息的提取和脚本文件的生成是异步的，并且以组件库中的组件作为媒介，这样，在某个接口需要变更时，只需要变更组件库中该接口对应的组件信息即可，无需变更该接口对应的所有测试脚本的信息，可以批量的更新多接口组合测试场景下的脚本，从而解决了现有技术中多接口组合测试场景下，接口变更时脚本的维护成本较高的问题，保证了自动化测试脚本的维护成本较低。
[0115]
以上所述仅为本技术的优选实施例而已，并不用于限制本技术，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。