CN117493158A - 测试方法及其装置、电子设备、存储介质 - Google Patents

Abstract

本公开提供了一种测试方法及其装置、电子设备、存储介质，该测试方法包括：基于待测试租户的租户信息和环境参数信息生成待测试租户的测试环境配置文件；测试环境配置文件包含待测试租户对应的测试配置信息；读取预先编写的测试用例，生成初始用例集；测试用例包含关键字段；关键字段的信息包括待配置参数；采用测试环境配置文件中的测试配置信息配置初始用例集中至少一个关键字段的待配置参数，得到目标用例集；执行目标用例集，根据目标用例集的执行结果生成测试报告。根据本公开的实施例避免不同租户之间的信息相互混淆，提高多租户场景下的测试效率、降低资源消耗。

Description

测试方法及其装置、电子设备、存储介质

技术领域

本公开实施例涉及云计算技术领域，特别涉及一种测试方法及其装置、电子设备、存储介质。

背景技术

随着互联网技术的发展，很多软件系统都由单租户软件架构技术向多租户软件架构技术转变，多租户系统主要面向企业用户，因此每次迭代都需要保证系统内部接口正确无误。因此如何在多租户软件架构技术上做自动化接口测试带来了挑战，针对于单租户架构技术开发的系统，在编写自动化接口用例时可以直接写死一些参数，每次执行某套用例集之前只需要对原有的数据做清洗，该套用例就可以反复执行，达到自动化接口测试的效果。随着业务的发展需要，单租户系统变为多租户系统，以前编写的接口用例在不同租户上不能成功运行，每个租户都需要单独的维护一套用例和清理脚本。另外，目前对于不同租户的信息没有进行单独维护，使得多租户场景下的租户信息容易混淆。

发明内容

本公开提供一种测试方法及其装置、电子设备、存储介质，能够避免不同租户之间的信息相互混淆，提高多租户场景下的测试效率、降低资源消耗。

第一方面，本公开提供了一种测试方法，所述方法包括：

基于待测试租户的租户信息和环境参数信息生成所述待测试租户的测试环境配置文件；所述测试环境配置文件包含与所述待测试租户对应的测试配置信息；

读取预先编写的测试用例，生成初始用例集；所述测试用例包含关键字段；所述关键字段的信息包括：待配置参数；

采用所述测试环境配置文件中的所述测试配置信息配置所述初始用例集中至少一个所述关键字段的待配置参数，得到目标用例集；

执行所述目标用例集，根据所述目标用例集的执行结果生成测试报告。

第二方面，本公开提供了一种测试装置，包括：

生成模块，用于基于待测试租户的租户信息和环境参数信息生成所述待测试租户的测试环境配置文件；所述测试环境配置文件包含与所述待测试租户对应的测试配置信息；

读取模块，用于读取预先编写的测试用例，生成初始用例集；所述测试用例包含关键字段；所述关键字段的信息包括：待配置参数；

填写模块，用于采用所述测试环境配置文件中的所述测试配置信息配置所述初始用例集中至少一个所述关键字段的待配置参数，得到目标用例集；

执行模块，用于执行所述目标用例集，根据所述目标用例集的执行结果生成测试报告。

第三方面，本公开提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的一个或多个计算机程序，一个或多个所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的测试方法。

第四方面，本公开提供了一种计算机可读存储介质，其上存储有计算机程序，其中，所述计算机程序在被处理器执行时实现上述的测试方法。

本公开所提供的实施例中根据租户信息和环境参数信息生成待测试租户的测试环境配置文件，在测试环境配置文件中存储有与待测试租户对应的测试配置信息，使得后续操作可以基于该测试环境配置文件完成，后续操作所需的待测试租户的测试配置信息均可以从该测试环境配置文件中获取，从而使得每个租户的测试配置信息得到统一管理，避免不同租户之间的信息相互混淆。另外，测试用例包含的关键字段的信息包括待配置参数，使得在多租户场景下，不同的租户进行测试时能够获得与自身身份匹配的测试配置信息，从而使得测试用例成为与当前测试的租户匹配的测试用例，测试系统不用维护多套用例，提高多租户场景下的测试效率，降低了多租户场景下的资源消耗。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用来提供对本公开的进一步理解，并且构成说明书的一部分，与本公开的实施例一起用于解释本公开，并不构成对本公开的限制。通过参考附图对详细示例实施例进行描述，以上和其他特征和优点对本领域技术人员将变得更加显而易见，在附图中：

图1为相关技术的自动测试方法示意图；

图2为本公开实施例提供的一种测试方法流程图；

图3为本公开实施例提供的一种测试方法示意图；

图4为本公开实施例提供的测试用例管理示意图；

图5为本公开实施例提供的一种测试装置的框图；

图6为本公开实施例提供的电子设备的框图。

具体实施方式

为使本领域的技术人员更好地理解本公开的技术方案，以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在不冲突的情况下，本公开各实施例及实施例中的各特征可相互组合。

如本文所使用的，术语“和/或”包括一个或多个相关列举条目的任何和所有组合。

本文所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其它特征、整体、步骤、操作、元件、组件和/或其群组。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。

除非另外限定，否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。

在接口测试(是指测试系统组件间接口的一种测试)领域，目前的自动化接口测试技术(自动化测试是指把以人为驱动的测试行为转化为机器执行的一种过程)实现方式为：requests+pytest(计算机编程语言Python的一种单元测试框架)+pytest-html(pytest的一个插件，它为测试结果生成超文本标记语言HTML报告)，该技术为一套基于代码接口测试框架，实现流程为：将每个测试用例(在后文中可简称为用例)写入到以test_开头的方法中，该方法中包含了请求的api(application program interface，应用编程接口)地址、请求参数、断言表达式等，每个方法的内部都是通过requests(请求)发起接口请求，然后进行接口校验，等待所有方法执行完成后生成测试报告。

当前技术存在以下缺点：

缺点一：在多租户场景下，需要维护多套用例和多套清理脚本(因为在接口测试时虽然对于不同的租户来说，所有的环境和租户的测试业务逻辑都是大致相同的，但是一个测试系统使用的人很多时，对于测试人员来说，在多租户测试系统下，大家都需要基于自己创建的租户进行测试，在自动化工具不成熟的情况下，就需要针对每个租户设计与该租户身份对应的用例和清理脚本，如图1所示。例如，一个主要原因是用例中支持sql参数化方式，所以在这种特性下，不同租户获取参数的sql(Structured Query Language，结构化查询语言)就有所区别，如果是在没有自动化工具针对不同租户生成测试用例的情况下，就需要维护多套测试用例和清理脚本)，即使不需要完全重新编写，但需要对内容手动进行微调整，当租户越来越多时，一个用例会经历多次人工修改，每套用例的维护也会耗费大量的人力。

下面通过举例说明该缺点：目前在编写测试用例时通常做一些参数化的设置。例如：一个接口中需要获取一个模型名为“服务态度”的id(Identity缩写，身份标识)，在以前单租户的场景中只需要通过sql：“select id from regular_model where model_name＝‘服务态度’and is_delete＝0；”这一语句就可以获取，然而在多租户场景下，该条sql需要改为：“select id from regular_model where model_name＝‘服务态度’and is_delete＝0and tenant_no＝‘zg’；”，其中“tenant_no＝‘zg’”用于指示当前租户id，“tenant_no＝‘zg’”中的‘zg’为固定参数，不能更改，因此，租户发生变化时，如果“tenant_no＝‘zg’”中的‘zg’不能更改，则编写的测试用例不能直接被新的租户使用，因为租户id未更改，该测试用例还是针对‘zg’的测试用例。此时或者重新编写适用于新租户的测试用例，或者对“tenant_no＝‘zg’”字段进行手动调整，耗时耗力，且效率低下。

其中，多租户是指：多租户技术或称多重租赁技术，简称SaaS，是一种软件架构技术，是实现如何在多用户环境下(此处的多用户一般是面向企业用户)共用相同的系统或程序组件，并且可确保多用户间数据的隔离性。

缺点二，目前对于不同租户的信息没有进行单独维护，使得多租户场景下的租户信息容易混淆。

本公开实施例根据租户信息和环境参数信息生成待测试租户的测试环境配置文件，在测试环境配置文件中存储有与待测试租户对应的测试配置信息，使得后续操作可以基于该测试环境配置文件完成，后续操作所需的待测试租户的测试配置信息均可以从该测试环境配置文件中获取，从而使得每个租户的测试配置信息得到统一管理，避免不同租户之间的信息相互混淆。

另外，本公开实施例的测试用例包含的关键字段中测试配置信息为待配置参数，使得在多租户场景下，不同的租户进行测试时能够更改测试配置信息，从而使得测试用例成为与当前测试的租户匹配的测试用例，测试系统不用维护多套用例和清理脚本，提高多租户场景下的测试效率，降低了多租户场景下的资源消耗。

根据本公开实施例的测试方法可以由终端设备或服务器等电子设备执行，终端设备可以为车载设备、用户设备(User Equipment，UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字助理(Personal Digital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等，所述测试方法可以通过处理器调用存储器中存储的计算机可读程序指令的方式来实现。或者，可通过服务器执行所述测试方法。

图2为本公开实施例提供的一种测试方法的流程图。参照图2，该方法可以包括步骤S11-S14：

S11、基于待测试租户的租户信息和环境参数信息生成待测试租户的测试环境配置文件；测试环境配置文件包含与待测试租户对应的测试配置信息。

S12、读取预先编写的测试用例，生成初始用例集；测试用例包含关键字段；关键字段中的信息包括：待配置参数。

S13、采用测试环境配置文件中的测试配置信息配置初始用例集中至少一个关键字段中的待配置参数，得到目标用例集。

S14、执行目标用例集，根据目标用例集的执行结果生成测试报告。

在本公开实施例中，图3为本公开实施例提供的一种测试方法的示意图。如图3所示，当任意一租户(如待测试租户)需要做接口自动化测试时，获取该租户的租户信息和环境参数信息，根据待测试租户的租户信息(可以包括但不限于租户id)以及待测试租户的环境参数信息(可以包括但不限于：环境id)生成相应的测试环境配置文件，后续操作可以基于该测试环境配置文件完成，后续操作所需的待测试租户的相关信息均可以从该测试环境配置文件中获取。其中，该租户信息和环境参数信息为人为输入的信息，例如，可以由待测试租户输入，也可以由测试人员输入。

在本公开实施例中，根据租户信息和环境参数信息生成待测试租户的测试环境配置文件，在测试环境配置文件中存储有与待测试租户对应的测试配置信息，使得后续操作可以基于该测试环境配置文件完成，后续操作所需的待测试租户的测试配置信息均可以从该测试环境配置文件中获取，从而使得待测试租户的测试配置信息得到统一管理，避免不同租户之间的信息相互混淆。

在本公开实施例中，基于待测试租户的租户信息和环境参数信息生成待测试租户的测试环境配置文件，可以包括：

通过待测试租户的环境id在预设的环境信息存储文件中查找对应的环境信息；其中，环境信息存储文件用于存储不同环境类型的环境信息；一个环境id对应一种环境类型以及该环境类型的环境信息；环境信息包括：IP地址；第一环境信息包括待测试租户的IP地址；

根据待测试租户的租户id，向测试业务系统登录接口发送验证信息获取请求，得到验证信息；该验证信息用于在待测试租户登录测试业务系统之前验证待测试租户的登录权限；

将包含第一环境信息、待测试租户的租户id和验证信息在内的测试配置信息保存在预设文件中，获得待测试租户的测试环境配置文件。

在本公开实施例中，由上述内容可知通过待测试租户对应的环境id获取相应的环境信息，通过待测试租户的租户id获取待测试租户的验证信息(可以包括但不限于令牌token)，将待测试租户的环境id、环境信息、租户id、验证信息等信息存储预设文件中，获取待测试租户对应的测试环境配置文件。

在本公开实施例中，可以通过与所述待测试租户的环境id在预设的环境信息存储文件中查找对应的环境信息；其中，所述环境信息存储文件用于存储多个不同环境类型的环境信息以及测试业务系统登录接口的登录信息(例如，可以包含但不限于登录账户和登录密码)；其中，不同环境id对应不同的环境类型，一种环境类型中包括至少一个环境信息。

在本公开实施例中，该预设的环境信息存储文件可以定义为environment_totals.yaml文件，environment_totals.yaml文件中可以以键值对形式存储有多个不同环境类型的环境信息，其中，一个键值对可以代表一个环境类型，其中，该键值对的键可以是环境id(例如，环境名称)，该键值对的值可以指示该环境id对应的环境信息。

在本公开实施例中，一个环境id可以唯一标识一种环境类型，并且对应该环境的环境信息，常用环境类型都可以定义一个id，例如：test1、test2、stage、online等。该环境id可以为environment_totals.yaml文件中的键名称。

在本公开实施例中，所有环境类型对应的环境信息都可以存储到该预设的环境信息存储文件中进行维护，例如前述的environment_totals.yaml文件，并通过环境id唯一标识该环境信息。其中待测试租户所需的环境信息可以定义为第一环境信息。

在本公开实施例中，环境信息可以包含硬件环境信息和软件环境信息，硬件环境信息可以包括但不限于PC(个人计算机)机对应的物理地址，软件环境信息可以包括但不限于：IP地址、账号、密码、软件运行的操作系统(主流的操作系统：视窗操作系统windows、林纳克斯Linux、尤尼斯Unix)、数据库(甲骨文Oracle、关系型数据库管理系统MySQL、结构化查询语言服务器SqlServer、数据库软件DB2等)、网页web应用服务器和集群环境(如负载均衡)等。

在本公开实施例中，租户id是指创建某个租户时，可以对该租户自定义一个id，执行测试任务时可以通过该id号区别不同的租户。

在本公开实施例中，自动化测试任务开始时，获取命令行输入的待测试租户的环境id和租户id(假设当前执行环境id为:test2，待测试租户的租户id为:zhtest01)，通过该环境id可以在environment_totals.yaml文件中查找对应的第一环境信息。

在本公开实施例中，可以通过与待测试租户的租户id获取待测试租户的验证信息，例如：根据所述待测试租户的租户id，向测试业务系统登录接口发送令牌token获取请求，得到待测试租户对应的token。

在本公开实施例中，环境信息存储文件还用于存储测试业务系统登录接口的登录信息；该登录信息为公用信息；

根据待测试租户的租户id，向测试业务系统登录接口发送验证信息获取请求，得到验证信息，可以包括：

从环境信息存储文件获取登录信息；

根据租户id和登录信息生成验证信息获取请求；

向测试业务系统登录接口发送验证信息获取请求，并在测试业务系统登录接口对验证信息获取请求验证通过后，得到测试业务系统登录接口返回的验证信息。

在本公开实施例中，该预设的环境信息存储文件(environment_totals.yaml文件)中还可以存储一个用于登录测试业务系统的登录信息(例如，可以包含但不限于登录账户和登录密码)，在多租户场景下，每个租户都可以使用该登录账户和登录密码进行登录，所以动态执行测试时，只需要输入待测试租户的租户id，根据该待测试租户的租户id，向测试业务系统登录接口发送令牌token获取请求，便可以得到待测试租户对应的token。

在本公开实施例中，通过环境信息存储文件存储测试业务系统的登录信息，并且将该登录信息作为公用信息，避免了为每个租户分别维护一套登录信息，降低了资源消耗，并且在获取验证信息之前仅需要提供租户id，减少了租户需要提供的验证数据的数量，提高了验证效率。

在本公开实施例中，在调用测试业务系统登录接口的时候，从environment_totals.yaml文件中获取account(登录账户)和password(登录密码)，并从命令行获取输入的租户id就可以成功获取token了，根据该公用的account和password，以及获取的token，便可以登录测试业务系统。

在本公开实施例中，将待测试租户的环境id、环境信息、租户id、验证信息等信息存储在预设文件中的相应位置便可以获取待测试租户对应的测试环境配置文件。如果预设文件中的相应位置处已经预存有初始的(或默认的)环境id、环境信息、租户id、验证信息等测试配置信息，可以将这些初始的测试配置信息替换为待测试租户的测试配置信息，从而获取待测试租户的测试环境配置文件。

在本公开实施例中，该预设文件可以定义为environment.yaml文件，该预设文件用于维护当前正在测试的待测试租户所需的环境信息、租户id和token等测试配置信息，因此，在获取待测试租户的环境信息以后，将该环境信息写入environment.yaml文件中，并将environment.yaml文件中预先配置的租户id替换为所述待测试租户的租户id；并在根据待测试租户的租户id获取待测试租户的令牌token后，将待测试租户的token更新在environment.yaml文件中，将更新后的environment.yaml文件作为与待测试租户对应的所述测试环境配置文件。

在本公开实施例中，通过待测试租户的环境id获取待测试租户的环境信息，通过租户id获取租户的验证信息，将包含待测试租户的环境信息、租户id和验证信息在内的测试配置信息保存在预设文件中获得待测试租户的测试环境配置文件，使得待测试租户相关的全部信息均放置于一个文件中，便于对当前测试的待测试租户信息的统一管理，并且通过待测试租户的输入信息(如环境id、租户id)能够获取到包括环境信息、验证信息在内的与租户相关的各种信息，保证了待测试租户相关信息的全面性，更利于待测试租户相关信息的统一管理。

在本公开实施例中，下面对测试用例的生成方法进行介绍。测试用例的生成方法可以包括：

获取测试点所需的测试数据；

从所述测试数据包含的字段中提取关键字段，所述关键字段为包含租户的测试配置信息的字段，将所述关键字段中的所述测试配置信息设置为待配置参数；

生成所述测试点对应的测试用例。

在本公开实施例中，测试用例包含的关键字段中测试配置信息为待配置参数，使得在多租户场景下，不同的租户进行测试时能够更改测试配置信息，从而使得测试用例成为与当前测试的租户匹配的测试用例，解决了针对多租户环境需要维护多套接口自动化化测试用例的问题，所有租户只需要维护一套测试用例，新增租户不需要更改测试用例内容，提高多租户场景下的测试效率，降低了多租户场景下的资源消耗。

在本公开实施例中，每个测试点可以实现一种或多种测试需求。

在本公开实施例中，可以基于SaaS的一个租户(可以为任意租户)的测试配置信息配置测试用例关键字段中的待配置参数，按照预先约定好的规则和/或定义好的用例模板，编写自动化接口用例。

在本公开实施例中，该约定好的规则可以包括：将预设的多个作为测试数据的字段按照一个或多个测试点所需的预设测试顺序进行排列，并可以在每个字段后标注所述字段对应的使用说明信息，将多个字段按照预设形式进行存储，其中，至少一个字段为使用到测试配置信息的关键字段，将关键字段中的测试配置信息设置为待配置参数，使得测试配置信息能够被替换为不同租户的测试配置信息。

在本公开实施例中，该用例模板可以是指按照上述约定好的规则，由测试数据(如，多个字段)生成的针对某一个或多个测试点的固定的模版，该模版可以是一个列表，按照该列表执行即可实现相应的一种或多种测试需求。

在本公开实施例中，由于本公开实施例中测试用例编写简单、易于理解，使得不会编写代码的人员也可以编写接自动化测试用例，他们只需要花费简短的时间学习预先定义好的用例编写规则，就可以高效编写基于用例文件(如yaml文件)管理的接口测试用例。

下面对本公开实施例的测试用例生成方法进行展开说明。

在本公开实施例中，所述测试数据包含的字段可以包括以下任意一种或多种：被测接口的地址字段(例如，path)、接口调用方法字段(例如，method)、用例描述字段(例如，remark)、用例是否执行的指示参数字段(例如，is_run)、请求头(例如，headers)、执行查询指令之前的参数获取字段(例如，precondition_sql)、自定义函数字段(例如，post_handle)、请求参数字段(例如，data)、调用方式为预设方式时的指示位字段(例如，file)、接口返回值获取字段(例如，extract_key)和断言传值字段(例如，assert_expression)；

所述字段的使用说明信息可以包括但不限于以下任意一种或多种：所述字段对应的含义、用途、类型、使用必要性、使用方法以及多个字段之间的排列顺序；

在一些可能的实现方式中，下面给出一个测试用例的实施例，该测试用例中包含的字段(例如，path、method、remark、is_run、headers、precondition_sql、post_handle、data、file、extract_key和assert_expression)可以按照下列顺序进行排列，并且这些字段包含的使用说明信息可以如字段右侧的注释内容所示：

在本公开实施例中，所述关键字段可以包括但不限于：被测接口的地址字段和/或执行查询指令之前的参数获取字段，例如，上述的path字段、precondition_sql字段；

测试配置信息可以包括但不限于：租户IP(Internet Protocol，网际协议)地址和/或租户id。

在本公开实施例中，由于实施path和sql相关字段的功能时通常用到租户id，在多租户模式下，对上述测试用例中path和/或precondition_sql关键字段的租户id进行简单替换，从而使得该测试用例变化为当前测试的租户的专用测试用例，使得测试系统不用维护多套用例和清理脚本，增加了测试用例的使用灵活性，为提高多租户场景下的测试效率，降低多租户场景下的资源消耗提供了技术基础。

在本公开实施例中，所述方法还可以包括：以第一键值对的方式对每个测试用例进行存储。

在本公开实施例中，所述第一键值对可以包括第一键和第一值；所述第一键用于标记所述测试用例的名称，所述第一值用于指示存储所述测试用例的存储容器；所述存储容器可以包括但不限于：字典。

在本公开实施例中，测试用例中的测试数据以第二键值对的形式存放于预设的存储容器中。

在本公开实施例中，所述第二键值对可以包括第二键和第二值；所述第二键用于标记所述测试数据包含的一个或多个字段，所述第二值用于指示所述字段的使用说明信息。

在本公开实施例中，第二键如上述的字段：path、method、remark、is_run、headers、precondition_sql、post_handle、data、file、extract_key和assert_expression等。第二值如上述path对应的使用说明信息【/api/rule/sys/login//被测接口的api地址】，如上述method对应的使用说明信息【post//接口调用方法；支持post、get、put(上传文件用)、e_post(下载文件)、i_put(导入文本、录音)】；……；在此不再一一列举。

在本公开实施例中，生成的全部用例可以传入预设的用例文件或者直接传入一个文件夹，并且可以传入一个用例文件或文件夹，也可以传入多个用例文件或文件夹。

在本公开实施例中，该用例文件可以包括但不限于yaml(一种简洁的非标记语言)文件，例如，还可以支持excel(微软办公套装软件的一个组成部分)、数据库等多种方式存放测试用例，只要每个测试用例都满足用例模板中定义的规则就行。

在本公开实施例中，每个用例文件(如yaml文件)中的测试用例以键值对(如上述的第一键值对)存储，里面有多少个键值对表示有多少条测试用例，并且采用键标记该条测试用例的名字，值的类型为字典，字典里面又以键值对(如上述的第二键值对)存放测试某一接口所需要用到的测试数据及其使用说明信息。

在本公开实施例中，通过键值对的形式对测试用例，及其测试数据和相应的使用说明信息进行存储，使得存储形式简单、便于实施存储，而且以键值对形式存储的测试用例中，一个键值对代表一个测试用例，可以对全部测试用例一目了然，防止用例混淆，并且便于管理和搜索。

在本公开实施例中，将所有预先创建的测试用例都维护在预设的用例文件中以后，可以使用一个或多个租户的测试配置信息作为测试样本对这些测试用例进行调试，直至这些测试用例满足预设要求。例如，可以基于定义好的测试用例，以及测试用例中每个字段支持的参数化方式，根据一个租户的测试配置信息编写相应的测试用例，并运行所编写的测试用例，直至成功运行，最终生成测试报告，其中，租户的测试配置信息可被替换。

在本公开实施例中，所述生成所述测试点对应的测试用例之后，所述方法还包括：将所述测试用例存储到预设用例库中，按照预设的管理规则对所述预设用例库中的测试用例进行管理；

所述管理规则可以包括但不限于：将测试用例存储于用例文件，将用例文件存储于相应的模块下进行管理；将模块存储于相应的项目下进行管理。

在本公开实施例中，可以按照不同的项目对测试用例进行存储，其中，不同的项目分别包含不同的模块，不同的模块包含一个或多个用例文件，每个用例文件中包含一个或多个测试用例；用例文件能够被整体调用。

在本公开实施例中，测试用例存储到用例文件中，再将用例文件存储到预设用例库单独管理，可以针对每个项目建立一个预设用例库，每个预设用例库又可以按照模块(或称项目模块)进行划分，每个模块中可以存储多个用例文件，存放独立功能的测试用例。

在本公开实施例中，通过对测试用例按照不同的项目进行存储，其中，不同的项目分别包含不同的模块，不同的模块包含一个或多个用例文件，每个用例文件中包含一个或多个测试用例，使得测试用例更易于被查找，而且增加了用例管理的系统性和便利性；另外，测试用例存储在用例文件中，用例文件能够被整体调用，使得在对某个项目或某个模块进行测试时，可以整体调用项目或模块中的用例文件，避免了单独调用一个个测试用例，从而提高了操作效率，提升了测试用例的使用效率和灵活性。

在一些可能的实现方式中，下面给出基于质检项目和催收项目的测试用例管理模块对预设用例库中的全部测试用例进行管理的实施例，如图4所示：

在智能质检系统中，可以包括：人员管理、模型中心、策略中心和通话管理等模块，每个模块分别存储有相应测试点的用例文件，这些用例文件中存储有与该模块对应的一个或多个测试点的测试用例。并且上述每个模块还可以包括二级菜单，甚至包括三级菜单、四级菜单等，可以根据需求进行设置。例如，在人员管理模块中还包含：用户管理、角色管理、机构管理和职场管理等二级菜单；在模型中心还包含：质检模型、规则配置、词库管理等二级菜单。每级的一个或多个菜单中分别存储有相应的一个或多个用例文件，这些用例文件中存储有与该菜单对应的一个或多个测试点的测试用例；

在催收系统中，可以包括：人员管理、贷款管理、呼叫中心和通话管理等模块，每个模块分别存储有相应的用例文件，这些用例文件中存储有与该模块对应的一个或多个测试点的测试用例。

在本公开实施例中，基于上述管理规则，使得完成一个测试点的全部测试用例可以独立包含于一个用例文件中，因此，在自动化测试过程中可以以用例文件为单位直接调用租户所需功能的用例文件，也可以以二级、三级、四级等菜单为单位，调取整个菜单中的用例文件或测试用例，还可以以模块为单位，调取整个模块中的用例文件或测试用例，通过该实施例方案，避免了单独调用一个个测试用例，从而提高了操作效率。

目前的测试方案中，测试用例的数据没有和测试用例的测试代码完全分离，新增一个接口的用例就需要编写新的测试代码(或称测试脚本)，增加了测试复杂度，当接口地址有变化时，需要去测试代码中更改与接口地址对应的请求参数，可能会出现改错或者改漏情况。本公开实施例中测试用例的数据与测试代码完全分离，该测试代码可以预先根据约定好的规则或者设置好的用例模板生成，使得执行一条测试用例和执行上百条测试用例的代码量是一样的，某个模块新增接口只需要将该接口的测试数据配置到该测试代码中，生成相应的测试用例添加到用例文件即可，无需改动任何测试代码。

在本公开实施例中，当任意一租户需要做接口自动化测试时，可以获取预先确定出的回归范围(例如，在质检系统中，每个模块都有相应的测试负责人，基于本次需求的测试改动点，可以由测试负责人评估一个回归范围)，并根据该回归范围确定出前述的测试用例管理模块所管理的各个项目、模块和/或菜单中所需的项目、模块和/或菜单，并形成相应的搜索路径(例如，/case/auto_model_regresion_testcase)，添加到测试脚本(即测试程序)中，使得该测试脚本执行时可以根据该搜索路径从预设用例库中挑选出当前的待测试租户所需的测试用例，或者直接挑选出所需的用例文件(如yaml文件)，最终将挑选出的测试用例或用例文件的名称传入到与待测试租户对应的指定位置即可，大大增加了测试用例使用的灵活性。

在本公开实施例中，可以基于场景实现自动挑选测试用例和/或用例文件：基于一些常用的场景，预挑选出需要执行的测试用例和/或用例文件，以键值对的方式管理到指定文件中，其中，键值对中的键指的是场景id，值为list(列表，可以为测试用例列表和/或用例文件列表)，通过键值对存储多个测试用例和/或用例文件。在本次迭代中，基于需求迭代，确定了回归范围和场景后，优先去场景库中查看是否已经存在所需场景的测试用例管理，如果存在，则直接使用该场景对应的用例集和/或用例文件集，如果不存在则基于回归范围重新挑选所需场景下的测试用例和/或用例文件。

在本公开实施例中，在将测试用例或用例文件的名称传入到与待测试租户对应的指定位置时，这里可以支持传入的是一个list，list中可以包含多个yaml文件，或者是一个文件夹，但传入的测试用例必须全部放到指定位置，例如：./case目录下，收集用例时会自动到该目录下进行全局搜索，找到满足条件的用例文件(在执行向./case目录中传送list过程中，传入的list包含的时用例文件名称，例如yaml文件名，最终需要在./case目录中找到该yaml文件名，获取到完整的路径，才可以读取出该yaml文件的内容，如果测试用例以第一键值对的方式存储在该yaml文件中，则可以根据第一键值对中的第一值找到存储测试用例的存储容器，根据第一键值对中的第一键获取测试用例的名称，从而读取出相应的测试用例，并可以将读取的测试用例整合到一个池子里，组成初始用例集，方便测试程序的执行。这里的条件可以是指：传入的yaml文件名在./case目录下存在即可)；如果传入的是一个文件夹，则在该./case目录下去找该文件夹名，获取该文件夹名下的所有以.yaml后缀结尾的文件，并读取该.yaml后缀结尾的文件中的测试用例，并可以将读取的测试用例整合到一个池子里，组成初始用例集，方便测试程序的执行。

在本公开实施例中，在通过上述方案获取待测试租户对应的所述测试环境配置文件以及初始用例集以后，就可以根据测试环境配置文件中的租户信息对初始用例集中的测试用例进行第一处理，以便获取适用于待测试租户的目标用例集。

在本公开实施例中，根据测试环境配置文件中的租户信息对初始用例集中的测试用例进行第一处理可以包括但不限于：采用测试环境配置文件中的测试配置信息配置初始用例集中至少一个关键字段。例如，将所述初始用例集中的测试用例包含的一个或多个关键字段所涉及的租户id替换为待测试租户的租户id，将一个或多个关键字段所涉及的IP地址替换为待测试租户对应的IP地址。

在本公开实施例中，关键字段的测试配置信息进行替换的原因包括：测试用例是预先以一个指定租户(该租户为任意租户)编写的，为了适应多租户执行，只维护一套测试用例，在编写的测试用例中利用了IP地址、租户id等测试配置信息，并且这些测试配置信息被设置为待配置参数，即，这些测试配置信息可以被替换，以便在不改动代码或者测试用例的前提下能够使得不同的租户顺利运行测试用例，此时仅替换关键字段中的测试配置信息，从而提高测试用例的应用灵活性，替换测试配置信息是在传入测试用例之后生成的测试集中进行的，因此并不改变原始的测试用例，也就不用清洗脚本，不用维护多套测试用例，提高了测试效率。

在本公开实施例中，所述关键字段可以包括但不限于：被测接口的地址字段和/或执行查询指令之前的参数获取字段；例如，前述的path字段和/或precondition_sql字段；所述测试配置信息可以包括但不限于：租户的IP地址和/或租户id。

在本公开实施例中，将测试用例包含的一个或多个关键字段所涉及的测试配置信息替换为所述待测试租户对应的租户信息，可以包括以下任意一种或多种：

将path字段中包含的IP地址替换为所述待测试租户对应的IP地址；

将sql字段中包含的租户id替换为所述待测试租户的租户id。

在本公开实施例中，上述的第一处理可以包括两件事情，一是：完善用例中path字段的值(例如，被测接口的请求地址)，二是：替换租户id，用例参数化时使用到了租户id，需要将用例中的租户id替换为当前运行环境的租户id。

在本公开实施例中，针对完善path字段中被测接口请求地址这一操作，path字段在编写测试用例的时候不能够直接完整的写入用例文件，因为对于接口测试来说，api地址一般确定之后是不会改变的，但是对于不同租户的运行环境是不确定的，如果提前将IP也写入测试用例中，随着不同租户对应的环境变化使得IP地址变化后，就需要对所有测试用例进行修改，因此这里需要在动态执行测试用例之前再传入一个完整的被测接口请求地址。

在本公开实施例中，完善path字段中被测接口请求地址方案可以包括：在测试用例(或用例文件，如yaml文件)中path字段存储的是api地址，如:“/api/tenant/keys”，一个完整的被测接口请求地址应该是：协议【http(HyperText Transfer Protocol，超文本传输协议)或者https(Hyper Text Transfer Protocol over Secure Socket Layer，是以安全为目标的http通道)】+IP+端口+api地址。因此这里从环境信息中获取与待测试租户相应的IP地址，并采用该待测试租户的IP地址替换原来租户的IP地址，该IP地址可以与端口信息和api地址进行拼接，构成一个完整的被测接口请求地址，存储在path字段，实现了待测试租户使用该测试用例时对path字段的完善，当其他租户再使用该测试用例时可以以同样的方式对path字段进行完善，将path字段中的IP地址替换为其他租户的IP地址即可，在此不再一一赘述。

在本公开实施例中，针对替换租户id这一操作，可以以智能质检为例进行说明，因为智能质检是多租户架构的，目前智能质检环境下的所有租户共用一套数据库，租户之间数据隔离通过tenant_no字段来实现，即，通过tenant_no标识不同的租户id。当测试用例中入参参数化是通过从数据库获取值实现时，原始的测试用例中sql均编写为tenant_no＝‘zg’(即，编写测试用例时使用的指定租户的租户id为‘zg’)，例如：“data.scoreTemplateId:sql-select id from score_template where tenant_no＝‘zg’and is_delete＝0and template_name like'test评分模板％'and online_status＝1order by create_time asc limit 1；”，因此，在待测试租户(例如，待测试租户的租户id为‘zhtest1’)上运行时，需要首先将测试用例中的sql字段中的tenant_no值进行替换，将‘zg’替换为‘zhtest1’，以便后面运行sql进行数据库查询时，能获取到当前运行的待测试租户的数据库数据。

在本公开实施例中，初始用例集经过第一处理后，可以获取目标用例集，该目标用例集是用于执行测试程序的用例集。

在本公开实施例中，执行测试程序时可以首先从目标用例集中获取一条测试用例。例如，可以通过yield传入一条测试用例的数据，假设该条测试用例为“智能任务-新建一个一次性智能任务”。其中，yield的功能是将控制权转移给其它图形对象，包括非PowerBuilder(用来进行客户/服务器开发的完全的可视化开发环境)对象；yield函数检测消息队列，如果有消息，就把消息取出；利用yield函数可以在执行耗时较长的操作时把控制权转让给其它应用。

在本公开实施例中，在执行目标用例集之前，该方法还可以包括：

检测关键字段是否属于需要进行参数解析的字段；

在关键字段属于需要进行参数解析的字段的情况下，根据关键字段进行参数解析，并使用参数解析后获取的返回值配置关键字段中的待配置参数。

在本公开实施例中，执行对测试用例的参数解析是指对传入的该条测试用例进行前置处理。

在本公开实施例中，前置处理可能需要执行，也可能不需要执行，并且当前置处理需要执行时可能涉及到与租户相关的参数，也可能不会涉及到与租户相关的参数。其中，当参数解析过程中涉及到与租户相关的参数时，返回待测试租户对应的参数值。

在本公开实施例中，在关键字段属于需要进行参数解析的字段的情况下，根据关键字段进行参数解析，并使用参数解析后获取的返回值配置关键字段中的待配置参数，包括以下任意一种或多种：

在关键字段为待执行的参数查询字段的情况下，根据参数查询字段进行数据库查值，并使用查询结果配置参数查询字段的待配置参数；

在关键字段为函数值字段的情况下，获得预设函数的函数值，并使用该函数值配置数值字段的待配置参数；

在关键字段为预设的取值语句字段的情况下，根据取值语句字段的取值路径从相应的存储空间获取存储值，并使用存储值配置取值语句字段的待配置参数。

在本公开实施例中，通过对参数查询字段、函数值字段、取值语句字段的参数解析，包括了测试用例中所需的参数解析场景，保证了本公开实施例的测试用例应用场景的全面性，使得本公开实施例的测试用例在每种需要进行参数解析的场景下均能执行。

在本公开实施例中，例如，参数查询字段可以为sql字段，函数值字段可以为某个特殊函数的返回值对应的字段(例如随机函数返回值对应的字段，可以称为随机数字段)，该取值语句字段可以为缓存池取值字段。

在本公开实施例中，获取到了一条测试用例后，对该测试用例进行前置处理，主要处理测试用例中的“precondition_sql、path、data、file”等几个字段，如果测试用例中的“precondition_sql、path、data、file”字段存在参数化，则需要对它们进行参数解析，获取参数值，并替换到该测试用例中【例如，如果当前测试用例在执行时需要用到前面测试用例执行结果中的一条或多条参数(这些参数可能与租户id相对应，即，不同的租户id可能具有不同的参数值)，则需要获取这些参数，并采用获取的这些参数的参数值替换当前测试用例相应参数位置处的参数值】。参数化支持三大类：sql参数化、特殊函数参数化、缓存池获取值参数化。具体地，测试用例的某些字段中包含待执行sql的，进行数据库查值，并将查询结果更新到该测试用例中；测试用例中包含特殊函数的，获取函数值，并更新到该测试用例中；测试用例中包含在缓存池中取值的，获取缓存池中的值，并更新到该测试用例中。

在本公开实施例中，通过将需要进行参数解析的关键字段中的测试配置信息设置为待配置参数，在执行测试用例之前对这些关键字段进行参数解析，使得测试用例所需的参数均提前获取并输入相应的关键字段，从而使得测试用例不会因为某些关键字段的参数未解析，或者解析后未能改变原有参数，而影响测试用例再次执行，关键字段的参数解析方案使得测试用例可以针对不同的环境和租户执行任意次数，不需要执行之前对数据库数据做删除操作，或者是重新编写接口用例，大大提高了接口自动化测试的投入产出比。

在本公开实施例中，仍以前述的“智能任务-新建一个一次性智能任务”这条测试用例进行举例说明：

sql参数化:

在测试用例的“data”中存在“sql-”关键字，提取出sql:“select id from score_template where tenant_no＝'zhtest01'and is_delete＝0and template_name like'test评分模板％'and online_status＝1order by create_time asc limit 1；”，到数据库进行查询，获取到id＝12，并将结果更新到测试用例中data.scoreTemplateId:12。

特殊函数参数化：

“data”中包含“+random_str(3)”函数，可以称为随机字符串函数，该“+random_str(3)”函数表示返回一个包含三个字符的字符串，这里的字符来源是预先定义好的一个字符池子，例如：'qwertyuioplkjhgfdsazxcvbnm'，如random_str(3)返回值为“qwr”，则data.name的值为“test智能任务01qwr”。随机字符串的加入，使得该任务为第任意次执行，保证了该条测试用例可以在任何环境、任何租户上执行任意次数。

缓存池获取值参数化：

通过关键字在缓存中取值，如果测试用例的“data”字段中存在以“$.”开头的字段，例如：$.groupid，表示在缓存中获取键为“groupid”的值，并将该值更新到测试用例中。

在本公开实施例中，通过以上方案可以实现对所述测试用例进行参数解析(即，对测试用例的前置处理)。

已知目前的接口用例参数化不够灵活，编写的测试用例不支持某些关键字参数化，因此，有的测试用例只能在一个环境中执行一次，如果想要二次执行，要么手动清除原有数据，要么修改测试用例。本公开实施例通过将需要进行参数化处理的字段均设置为关键字段，这些字段中的参数均为待配置参数，使得通过执行前置处理，在执行测试用例之前将测试用例所需的参数均提前获取并配置到相应的关键字段中，使得测试用例可以针对不同的环境和租户执行任意次数。

在本公开实施例中，对目标用例集中的测试用例执行完前置处理后便可以逐条获取目标用例集中的测试用例，并执行获取的每条测试用例。

在本公开实施例中，在执行获取的每条测试用例之前，所述方法还可以包括：对该条测试用例再次进行第一处理，即，再次采用测试环境配置文件中的测试配置信息替换至少一个关键字段中的待配置参数，例如，利用待测试租户的租户id替换测试用例中关键字段对应的租户id，利用待测试租户的IP地址替换测试用例中关键字段对应的IP地址。

在本公开实施例中，在执行每一条测试用例之前，再次对测试用例中使用到测试配置信息的关键字段进行测试配置信息替换，主要是起到一个保障与租户相关的测试配置信息完全替换的作用，可以避免第一次执行第一处理时关键字段的测试配置信息替换不完全，导致测试用例执行失败的情况发生。

在本公开实施例中，在再次执行第一处理后也可以再执行一次前置处理，然后逐条执行目标用例集中的测试用例。

在本公开实施例中，执行每条测试用例可以包括：发起接口请求、后置处理、断言处理以及最后判断等步骤，下面分别详细介绍。

在本公开实施例中，在执行每条测试用例时，可以根据测试用例中标明的请求方法类型，借助requests(请求)包发起接口请求(例如，发起http请求)。即，通过配置的method字段、path字段以及data字段等字段的信息，基于预先得到的token，生成http请求，并向多租户测试业务系统(例如智能质检系统)发送该http请求。

在本公开实施例中，这里对发起接口请求的方案进行详细介绍：首先可以根据测试用例中的“method”字段值判断调用requests的是post方法，还是get方法；“method”字段的枚举值包括：get、post、put，这里method为“post和put”时调用的都是requsts的post方法，只有method为“put”类型时接口支持上传文件。根据测试用例中的api地址、请求参数、以及从environment.yaml文件获取的header和IP地址就可以发起接口请求。

在本公开实施例中，在发起接口请求以后，可以对测试用例进行后置处理：接口调用完成，获取接口返回值，并转为预设格式，例如json格式(一种轻量级的数据交换格式)，提取部分字段值以键值对的方式存入到缓存。其中，测试用例中的“extract_key”字段标记了哪些字段需要从接口返回中提取数值，这些数值用于前置处理。

在本公开实施例中，对测试用例进行后置处理后，进行断言处理，可以借助python(计算机编程语言，是一个高层次的结合了解释性、编译性、互动性和面向对象的脚本语言)中assert函数(断言函数)进行断言，并记录断言经过。断言表达式来源是测试用例中的“assert_expression”字段值。

在本公开实施例中，下面以借助python中assert函数对“assert_expression”的值进行断言为例进行说明，例如：assert_expression:['"0"＝＝"$.code"']，表达式中以“$.”开头的字符串满足jsonpath的语法规则，jsonpath函数根据接口返回json和“$.code”字符串进行解析，获取“$.code”的值，如果提取出code＝0，则assert['"0"＝＝"0"']为True，则说明该条测试用例执行成功，和预期结果一致；如果提取出code不为0，则断言结果为Fasle，测试用例执行失败。

在本公开实施例中，结束断言处理后可以进行最后判断，即，判断该条用例是否为目标用例集中的最后一条，如果不是，则返回至获取目标用例集以后，对目标用例集进行第一次第一处理的步骤，继续执行后续步骤；如果当前测试用例为目标用例集中的最后一条，则获取所有测试用例的测试结果，利用allure(一款轻量级并且非常灵活的开源测试报告框架)生成测试报告。

在本公开实施例中，可以利用yaml+python+pytest+allure的架构搭建一个基于SaaS的接口自动化测试平台，显著提高接口自动化测试效率。

图5为本公开实施例提供的一种测试装置的框图。

参照图5，本公开实施例提供了一种测试装置100，该测试装置可以包括：

生成模块101，用于基于待测试租户的租户信息和环境参数信息生成待测试租户的测试环境配置文件；测试环境配置文件包含与待测试租户对应的测试配置信息；

读取模块102，用于读取预先编写的测试用例，生成初始用例集；测试用例包含关键字段；关键字段中的信息包括：待配置参数；

填写模块103，用于采用测试环境配置文件中的测试配置信息配置初始用例集中至少一个关键字段中的待配置参数，得到目标用例集；

执行模块104，用于执行目标用例集，根据目标用例集的执行结果生成测试报告。

图6为本公开实施例提供的一种电子设备的框图。

参照图6，本公开实施例提供了一种电子设备200，该电子设备200包括：至少一个处理器201；以及

与所述至少一个处理器201通信连接的存储器202；其中，

所述存储器202存储有可被所述至少一个处理器201执行的一个或多个计算机程序，一个或多个所述计算机程序被所述至少一个处理器201执行，以使所述至少一个处理器201能够执行上述的测试方法。

在本公开实施例中，电子设备200还可以包括：一个或多个I/O(输入/输出)接口203，连接在处理器201与存储器202之间。

本公开实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，其中，所述计算机程序在被处理器/处理核执行时实现上述的测试方法。计算机可读存储介质可以是易失性或非易失性计算机可读存储介质。

本公开实施例还提供了一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备的处理器中运行时，所述电子设备中的处理器执行上述的测试方法。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读存储介质上，计算机可读存储介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。

如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读程序指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM)、静态随机存取存储器(SRAM)、闪存或其他存储器技术、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读程序指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。

这里所描述的计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software DevelopmentKit，SDK)等等。

这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其他实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。

Claims (10)

1.一种测试方法，其特征在于，所述方法包括：

基于待测试租户的租户信息和环境参数信息生成所述待测试租户的测试环境配置文件；所述测试环境配置文件包含与所述待测试租户的测试配置信息；

读取预先编写的测试用例，生成初始用例集；所述测试用例包含关键字段，所述关键字段的信息包括：待配置参数；

采用所述测试配置信息配置所述初始用例集中至少一个所述关键字段的待配置参数，得到目标用例集；

执行所述目标用例集，根据所述目标用例集的执行结果生成测试报告。

2.根据权利要求1所述的测试方法，其特征在于，所述测试配置信息包括：环境信息；所述环境信息包括：网际协议IP地址。

3.根据权利要求2所述的测试方法，其特征在于，所述租户信息包括：租户身份标识id，所述环境参数信息包括：环境id；

所述基于待测试租户的租户信息和环境参数信息生成所述待测试租户的测试环境配置文件，包括：

通过所述待测试租户的环境id在预设的环境信息存储文件中查找对应的环境信息；其中，所述环境信息存储文件用于存储环境类型的环境信息；一个环境id对应一种环境类型以及该环境类型的环境信息；

根据所述待测试租户的租户id，向测试业务系统登录接口发送验证信息获取请求，得到验证信息；所述验证信息用于在所述待测试租户登录测试业务系统之前验证所述待测试租户的登录权限；

将包含所述环境信息、所述租户id和所述验证信息在内的所述测试配置信息保存在预设文件中，获得所述待测试租户的测试环境配置文件。

4.根据权利要求3所述的测试方法，其特征在于，所述环境信息存储文件还用于存储测试业务系统的登录信息；所述登录信息为公用信息；

所述根据所述待测试租户的租户id，向测试业务系统登录接口发送验证信息获取请求，得到验证信息，包括：

从所述环境信息存储文件得到所述登录信息；

根据所述租户id和所述登录信息生成所述验证信息获取请求；

向所述测试业务系统登录接口发送所述验证信息获取请求，并在所述测试业务系统登录接口对所述验证信息获取请求验证通过后，得到所述测试业务系统登录接口返回的所述验证信息。

5.根据权利要求1所述的测试方法，其特征在于，在执行所述目标用例集之前，所述方法还包括：

检测所述关键字段是否属于需要进行参数解析的字段；

在所述关键字段属于需要进行参数解析的字段的情况下，根据所述关键字段进行参数解析，并使用参数解析后获取的返回值配置所述关键字段的待配置参数。

6.根据权利要求5所述的测试方法，其特征在于，所述在所述关键字段属于需要进行参数解析的字段的情况下，根据所述关键字段进行参数解析，并使用参数解析后获取的返回值配置所述关键字段的待配置参数，包括以下任意一种或多种：

在所述关键字段为待执行的参数查询字段的情况下，根据所述参数查询字段进行数据库查值，并使用查询结果配置所述参数查询字段的待配置参数；

在所述关键字段为函数值字段的情况下，获得预设函数的函数值，并使用所述函数值配置所述函数值字段的待配置参数；

在所述关键字段为预设的取值语句字段的情况下，根据所述取值语句字段的取值路径从相应的存储空间获取存储值，并使用所述存储值配置所述取值语句字段的待配置参数。

7.根据权利要求1-6任意一项所述的测试方法，其特征在于，所述方法还包括：对所述测试用例按照预设的管理规则进行管理；

所述管理规则包括：将所述测试用例存储于用例文件，将所述用例文件存储于相应的模块下进行管理，将所述模块存储于相应的项目下进行管理。

8.一种测试装置，其特征在于，包括：

生成模块，用于基于待测试租户的租户信息和环境参数信息生成所述待测试租户的测试环境配置文件；所述测试环境配置文件包含与所述待测试租户对应的测试配置信息；

读取模块，用于读取预先编写的测试用例，生成初始用例集；所述测试用例包含关键字段；所述关键字段的信息包括：待配置参数；

填写模块，用于采用所述测试环境配置文件中的所述测试配置信息配置所述初始用例集中至少一个所述关键字段的待配置参数，得到目标用例集；

执行模块，用于执行所述目标用例集，根据所述目标用例集的执行结果生成测试报告。

9.一种电子设备，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的一个或多个计算机程序，一个或多个所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-7中任一项所述的测试方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序在被处理器执行时实现如权利要求1-7中任一项所述的测试方法。