业务测试方法、装置、业务测试设备及存储介质

技术领域

本申请属于研发管理技术领域，尤其涉及一种业务测试方法、装置、业务测试设备及存储介质。

背景技术

现有技术中，为适应业务发展的需要，很多企业都开发或引入了业务系统，这样的业务系统因其业务种类、业务操作等，其复杂度不同。例如，银行核心的业务系统，其作为银行存款、贷款账务处理等的重要组成部分，凡关于银行存款、贷款账务的业务操作都是在业务系统中完成。基于此，为了确定业务系统中的各个业务模块是否能正常进行运行，以适应每个业务模块在进行实际业务操作时可能发生的各种场景，则需要对业务系统中的各个业务模块进行测试。

目前，用户对业务系统中的业务模块进行测试时，均需要为业务模块中每套测试环境配置与外部渠道对接的域名，以使业务系统可使用外部渠道对业务模块对应的业务进行测试。然而，使用外部渠道对业务进行测试的过程中，若外部渠道出现异常，则无法正常对业务进行测试。

发明内容

本申请实施例提供了一种业务测试方法、装置、业务测试设备及存储介质方法及装置，可以解决使用外部渠道对业务进行测试的过程中，若外部渠道出现异常，则无法正常对业务进行测试的问题。

第一方面，本申请实施例提供了一种业务测试方法，应用于业务测试设备，所述方法包括：

在用于对目标业务进行测试的外部渠道异常时，接收业务系统发送的针对所述目标业务的测试请求，所述测试请求包括服务ID、场景ID和测试参数信息；

根据所述服务ID和场景ID，从所述目标业务的多个测试场景中确定目标测试场景，并确定所述目标测试场景所需使用的多个发送渠道的模板内容；

从数据池中获取满足所述测试参数信息的测试参数；

组合所述测试参数与所述多个发送渠道的模板内容，得到测试场景信息；

将所述测试场景信息返回所述业务系统，所述业务系统用于根据所述测试场景信息和预设测试场景信息生成针对所述目标业务的测试结果。

在一实施例中，根据所述服务ID和场景ID，从所述目标业务的多个测试场景中确定目标测试场景，并确定所述目标测试场景所需使用的多个发送渠道的模板内容，包括：

根据所述服务ID，确定所述目标业务对应使用的多个发送渠道；以及，

根据所述场景ID，从所述多个测试场景中确定目标测试场景；

基于所述多个发送渠道，分别获取所述目标测试场景中与所述多个发送渠道对应的模板内容。

在一实施例中，所述模板内容包括静态模板信息和动态逻辑规则信息；

组合所述测试参数与所述多个发送渠道的模板内容，得到测试场景信息中，包括：

针对任一发送渠道的模板内容，若所述测试参数具有多个，则分别根据所述模板内容中的动态逻辑规则信息，从多个测试参数中依次确定符合每个动态逻辑规则的目标测试参数；

将多个目标测试参数分别对应替换所述动态逻辑规则信息；

将替换后的所述动态逻辑规则信息和所述静态目标信息进行组合，得到所述测试场景信息。

在一实施例中，所述测试参数信息包括对所述目标业务进行测试的上一测试状态和对所述目标业务进行测试时的测试编号；所述方法还包括：

若所述测试请求中未包括场景ID，则获取所述测试参数信息中包含的测试编号；

根据所述测试编号和所述上一测试状态，确定对所述目标业务进行测试的下一测试状态；

从所述目标业务的多个测试场景中，确定用于对所述目标业务的下一测试状态进行测试的目标测试场景。

在一实施例中，在组合所述测试参数与所述多个发送渠道的模板内容，得到测试场景信息之后，还包括：

从所述数据池中，获取与所述目标测试场景关联的业务数据；

基于所述业务数据的配置规则，对所述测试场景信息进行再配置，得到目标测试场景信息，所述目标测试场景信息满足所述目标业务的业务校验规则。

在一实施例中，所述方法还包括：

针对所述目标业务的任一测试场景，若多个外部渠道正常，则分别获取通过所述多个外部渠道对当前测试场景进行测试后生成的多个渠道测试场景信息；

分别对所述多个渠道测试场景信息进行数据清洗，得到在所述当前测试场景下所述多个渠道测试场景信息分别对应的渠道测试参数；

确定通过所述多个外部渠道对所述当前测试场景进行测试时所述业务系统发送的渠道测试请求；

将所述渠道测试参数与所述渠道测试请求进行关联，并存储至所述数据池中。

在一实施例中，在分别获取通过所述多个外部渠道对当前测试场景进行测试后生成的多个渠道测试场景信息之前，还包括：

监控所述多个外部渠道的渠道状态；

若所述多个外部渠道的渠道状态均恢复为正常状态，则通过所述多个外部渠道对所述目标业务下的多个测试场景进行测试，并对所述业务系统执行提醒操作。

第二方面，本申请实施例提供了一种业务测试装置，应用于业务测试设备，包括：

接收模块，用于在用于对目标业务进行测试的外部渠道异常时，接收业务系统发送的针对所述目标业务的测试请求，所述测试请求包括服务ID、场景ID和测试参数信息；

第一确定模块，用于根据所述服务ID和场景ID，从所述目标业务的多个测试场景中确定目标测试场景，并确定所述目标测试场景所需使用的多个发送渠道的模板内容；

第一获取模块，用于从数据池中获取满足所述测试参数信息的测试参数；

组合模块，用于组合所述测试参数与所述多个发送渠道的模板内容，得到测试场景信息；

返回模块，用于将所述测试场景信息返回所述业务系统，所述业务系统用于根据所述测试场景信息和预设测试场景信息生成针对所述目标业务的测试结果。

第三方面，本申请实施例提供了一种业务测试设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面任一项所述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面任一项所述的方法。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在业务测试设备上运行时，使得业务测试设备执行上述第一方面中任一项所述的方法。

本申请实施例与现有技术相比存在的有益效果是：在确定外部渠道异常时，通过业务测试设备接收业务系统发送的针对目标业务进行测试的测试请求。之后，基于测试请求中的服务ID以及场景ID确定目标业务的目标测试场景，以及该目标测试场景下各个外部发送渠道对应的模板内容，以使业务测试设备当前确定的模板内容与外部渠道正常时对应的模板内容一致。进一步的，可使业务测试设备在从数据池中获取相应的测试参数对该模板内容进行组合后，生成的测试场景信息更接近于外部渠道正常时的测试场景信息。进而，可使测试人员根据接收到的测试场景信息更准确的确定业务的测试结果，以正常对业务进行测试。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一实施例提供的一种业务测试方法的实现流程图；

图2是本申请一实施例提供的一种业务测试方法的S102的一种实现方式示意图；

图3是本申请一实施例提供的一种业务测试方法的S104的一种实现方式示意图；

图4是本申请一实施例提供的另一种业务测试方法的实现流程图；

图5是本申请一实施例提供的又一种业务测试方法的实现流程图；

图6是本申请一实施例提供的再一种业务测试方法的实现流程图；

图7是本申请一实施例提供的再一种业务测试方法的实现流程图；

图8是本申请一实施例提供的一种业务测试装置的结构框图；

图9是本申请一实施例提供的一种业务测试设备的结构框图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

本申请实施例提供的业务测试方法可以应用于笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)等业务测试设备上，还可以应用于业务测试平台。具体的，上述业务测试平台可以为mock平台。本申请实施例对业务测试设备的具体类型不作任何限制。

请参阅图1，图1示出了本申请实施例提供的一种业务测试方法的实现流程图，该方法包括如下步骤：

S101、在用于对目标业务进行测试的外部渠道异常时，接收业务系统发送的针对所述目标业务的测试请求，所述测试请求包括服务ID、场景ID和测试参数信息。

在本申请实施例中，上述业务系统为发起业务测试的系统，通常的，一个业务系统包括多种业务模块，以执行多种业务相对应的功能。另外，对于业务系统中每个新上线的业务，通常需要预先对该业务对应的业务模块进行业务测试，以确定业务模块在实际场景下是否能够正常运行，达到预期效果。

通常的，测试人员在进行业务测试时，均需预先配置相应对测试场景，而后发起进行业务测试的测试请求至业务测试设备，得到相应的测试场景信息。之后，将测试场景信息分别通过对应的外部渠道发送至业务系统中，并由测试人员根据业务系统实际接收到的测试场景信息进行判断，确定业务的测试结果。

然而，在实际过程中，外部渠道通常由其他渠道商负责。因此，可以理解的是，测试人员在进行业务测试时对外部渠道的依赖性强。即当外部渠道发生异常时，测试人员无法正常对业务进行测试。因此，本实施例为针对外部渠道异常时，为避免业务测试受阻所提出的针对性的示例说明。需要补充的是，在进行业务测试时，需要通过外部渠道发送测试场景信息的原因在于：业务上线后，在执行业务相应功能的过程中，其产生的业务信息(包括但不限于通知信息、验证信息等)，均是通过外部渠道(短信发送渠道、APP发送渠道等)发送至用户。因此，通过外部渠道对业务进行测试，可以使业务系统接收到的测试场景信息更接近于用户实际接收到的信息。以此，使用外部渠道进行业务测试，可使测试人员根据接收到的测试场景信息更准确的确定业务的测试结果。

基于此，在本实施例中，在外部渠道异常时，执行上述业务测试的业务测试设备可以为用户预先设置多种业务测试策略的设备，可用于根据测试请求生成测试场景信息，且将测试场景信息发送至业务系统。其中，上述业务测试设备具体可以为mock平台，其具有可模拟和控制外部或者系统级别对象或接口的功能，使测试人员在进行业务测试时，可不必与真实环境(通过外部渠道发送测试场景信息的环境)交互即可完成对业务模块的测试。

在本申请实施例中，上述测试请求为业务系统需对某个业务进行测试时发起的请求，其中，该测试请求包括但不限于业务的服务ID、场景ID以及测试参数信息。其中，服务ID可用于标识该业务，并使业务测试设备根据该服务ID确定该业务在测试时可能需要的所有外部渠道。之后，测试设备可根据场景ID确定目标测试场景，以此得到在目标测试场景下每个外部渠道各自对应的模板内容。上述测试参数信息包括但不限于对该业务进行测试时的订单号、订单状态等信息。

在本申请实施例中，上述服务ID和场景ID包括但不限于数字、字母或其相结合的方式，对此不作限定。可以理解的是，上述服务ID和场景ID均具有唯一性，其服务ID用于对多个业务进行唯一标识，场景ID用于对多个测试场景进行唯一标识。

需要说明的是，在外部渠道正常时，上述在每个测试场景中使用的多个外部渠道分别对应的模板内容，均需预先在业务测试设备内部进行存储，以使业务测试设备根据场景ID和服务ID确定的模板内容，与实际设置的模板内容一致。

S102、根据所述服务ID和场景ID，从所述目标业务的多个测试场景中确定目标测试场景，并确定所述目标测试场景所需使用的多个发送渠道的模板内容。

在本申请实施例中，上述目标测试场景为针对该业务进行测试的测试场景。其中，每个测试场景通常可由配置人员预先进行配置，其配置内容包括但不限于为测试场景配置场景ID、为测试场景配置对应的发送渠道以及为该测试场景下使用的每个发送渠道配置对应的模板内容。

在本申请实施例中，在外部渠道正常时，业务系统发起的测试请求中所包含的服务ID，用于确定该业务所有可能返回测试场景信息的多个渠道。具体的，对于信息通知类型的业务，其信息发送的可用外部渠道通常包括APP发送渠道、短信发送渠道、邮件发送渠道。然而，对于正在进行测试的目标业务，其也许只能够通过短信渠道和/或微信公众号渠道发送测试场景信息。此时，业务测试设备可根据测试请求中包含的服务ID，从多个外部渠道中，确定目标业务所需使用的多个外部渠道。

在本申请实施例中，上述模板内容可为配置人员预先在业务的测试场景中设置信息内容。其中，对于一个测试场景下的模板内容，其通常包括多种。即一个测试场景下的每种外部渠道通常分别对应的一种模板内容。例如，同一个测试场景同时包括短信发送渠道下的模板内容与APP发送渠道的模板内容。需要说明的是，为每个发送渠道配置相应的模板内容的原因在于：短信发送渠道下的模板内容与APP发送渠道的模板内容中，两者模板内容属于不同的信息发送类型，其各自配置逻辑规则不同。因此，每种外部渠道通常分别对应的一种模板内容，以使基于该模板内容生成的测试场景信息可通过对应的外部渠道进行发送。

可以理解的是，同一个测试场景下，虽然每种外部渠道通常分别对应一种模板内容，但是基于每种模板内容生成的测试场景信息是相同的。即在目标场景下，生成的APP通知信息和短信通知信息发送至同一个用户的终端上时，其显示的信息内容是相同的。

S103、从数据池中获取满足所述测试参数信息的测试参数。

在本申请实施例中，数据池中预先存储有大量的测试参数，然而，每个测试场景下所需的测试参数各不相同。基于此，业务测试设备可从数据池中获取满足测试参数信息的测试参数。上述数据池可以为业务测试设备的数据池，也可为业务系统中的数据池，其可与业务测试设备进行数据连接，对此不作限定。

示例性的，上述测试参数信息可以包括用户信息条件，业务测试设备根据用户信息条件，从数据池中获取满足用户信息条件的用户信息作为测试参数。例如，数据池中记载了大量用户的短信联系方式和/或邮件联系方式。若用户信息条件为获取短信联系方式的条件，业务测试设备可将记录有用户短信联系方式的用户，确定为目标用户，并同时获取数据池中存储的目标用户的其他信息作为测试参数，进行后续处理。

需要说明的是，对于同一个测试场景下不同发送渠道对应的模板内容，上述S102已说明模板内容属于不同的信息发送类型，其各自配置逻辑规则不同。因此，基于测试参数信息得到的测试参数，应当具有多种，其分别适配于对应模板内容的配置逻辑规则。

S104、组合所述测试参数与所述多个发送渠道的模板内容，得到测试场景信息。

应用中，上述模板内容已在上述S102中进行描述，对此不再进行说明。通常的，模板内容包括静态模板信息和动态逻辑规则信息。其中，上述静态模板息为固定的内容，动态逻辑规则信息可以被配置人员预先配置的逻辑代码替换为具体的测试参数。

示例性的，测试场景为通知用户领用代金券的场景，其对应的模板内容可以为“尊敬的【#姓氏#】【#称呼#】，在xx年x月x日您已消费满一百元，请前往【#领取地址#】领取优惠券”。其中，“尊敬的”、“您已消费满一百元”等信息均为静态模板信息，“【#姓氏#】”、“【#称呼#】”均为动态逻辑规则信息。业务测试设备可基于动态逻辑规则信息和获取的测试参数进行替换。例如，若测试参数包括用户姓名以及用户性别，则测试设备可基于“姓氏”的动态逻辑规则信息，获取用户姓名中的姓氏，并进行替换；以及，基于“称呼”的动态逻辑规则信息，将“称呼”更换为“先生”或“女士”，对此不作限定。即上述模板内容中的动态逻辑规则信息可被预先配置的逻辑语句代码替换为相应的测试参数，对此不作限定。其中，上述逻辑语句代码可以为SQL语句。

可以理解的是，上述S102中已说明模板内容具有多个，且S103中已说明基于测试参数信息得到的测试参数，应当具有多种，其分别适配于对应模板内容的配置逻辑规则。基于此，业务测试设备生成的测试场景信息具有多个，且每个测试场景信息的实际内容虽然一致，但因信息发送类型不同，每个测试场景信息分别对应一种发送渠道。

S105、将所述测试场景信息返回所述业务系统，所述业务系统用于根据所述测试场景信息和预设测试场景信息生成针对所述目标业务的测试结果。

在本申请实施例中，上述测试场景信息在生成后，可直接由业务测试设备返回至业务系统，由业务系统的测试人员对其进行处理。进而，可在外部渠道异常时，还可使测试人员正常进行业务。其中，业务系统中预先存储有每个测试场景正常时的预设测试场景信息。业务系统可基于测试场景信息中携带的场景ID，获取对应的预设测试场景信息，而后与实际返回的测试场景信息进行比较，以使测试人员确定该目标业务的测试结果。

可以理解的是，一个测试场景下生成的多个测试场景信息，其每个测试场景信息的信息内容通常一致。因此，该预设场景信息的数量可以为1。

在本实施例中，在确定外部渠道异常时，通过业务测试设备接收业务系统发送的针对目标业务进行测试的测试请求。之后，基于测试请求中的服务ID以及场景ID确定目标业务的目标测试场景，以及该目标测试场景下各个外部发送渠道对应的模板内容，以使业务测试设备当前确定的模板内容与外部渠道正常时对应的模板内容一致。进一步的，可使业务测试设备在从数据池中获取相应的测试参数对该模板内容进行组合后，生成的测试场景信息更接近于外部渠道正常时的测试场景信息。进而，可使测试人员根据接收到的测试场景信息更准确的确定业务的测试结果，以正常对业务进行测试。

参照图2，在一实施例中，在S102根据所述服务ID和场景ID，从所述目标业务的多个测试场景中确定目标测试场景，并确定所述目标测试场景所需使用的多个发送渠道的模板内容中，具体包括如下子步骤S1021-1023，详述如下：

S1021、根据所述服务ID，确定所述目标业务对应使用的多个发送渠道。

S1022、根据所述场景ID，从所述多个测试场景中确定目标测试场景。

S1023、基于所述多个发送渠道，分别获取所述目标测试场景中与所述多个发送渠道对应的模板内容。

在本申请实施例中，上述服务ID、场景ID均已在上述S101中进行解释，对此不再进行说明。

在本申请实施例中，业务测试设备可先根据服务ID确定该业务下所有能够使用的发送渠道。之后，根据测试请求中的场景ID，确定目标测试场景。进而，业务测试设备可基于已确定的发送渠道，获取该目标测试场景中与已确定的发送渠道对应的模板内容。例如，短信发送渠道对应的短息发送模板或APP发送渠道对应的APP信息发送模板。

可以理解的是，在业务测试设备根据测试请求中的测试参数信息对短信模板内容进行处理，生成相应的测试场景信息后，该测试场景信息只可通过短信发送渠道进行发送。同样的，上述APP发送渠道与短信发送渠道类似，对此不再详细描述。

参照图3，在一实施例中，所述模板内容包括静态模板信息和动态逻辑规则信息；在S104组合所述测试参数与所述多个发送渠道的模板内容，得到测试场景信息中，具体包括如下子步骤S1041-1043，详述如下：

S1041、针对任一发送渠道的模板内容，若所述测试参数具有多个，则分别根据所述模板内容中的动态逻辑规则信息，从多个测试参数中依次确定符合每个动态逻辑规则的目标测试参数。

在本申请实施例中，对于模板内容中的静态模板信息和动态逻辑规则信息，通常的，动态逻辑规则信息具有多个，且根据测试参数信息从数据池中获取的测试参数通常也具有多个。基于此，业务测试设备可依次根据动态逻辑规则信息，从上述多个测试参数中确定符合每个动态逻辑规则的目标测试参数。

具体的，可参照上述S104中的示例，目标测试场景为通知用户领用代金券的场景。该目标测试场景中，业务测试设备可基于测试参数可依次根据【#姓氏#】、【#称呼#】、【#领取地址#】等动态逻辑规则信息，从多个测试参数(用户姓名、活动地址、用户联系方式)中，确定符合每个动态逻辑规则的目标测试参数。

S1042、将多个目标测试参数分别对应替换所述动态逻辑规则信息。

S1043、将替换后的所述动态逻辑规则信息和所述静态目标信息进行组合，得到所述测试场景信息。

在本申请实施例中，在基于S1041步骤确定目标测试参数后，业务测试设备可依次根据上述模板内容中动态逻辑规则信息对应的逻辑语句代码，将动态逻辑规则信息替换为相应的目标测试参数。基于此，替换后的动态逻辑规则信息(目标测试参数)和静态目标信息进行组合后，即可得到测试场景信息。

示例性的，上述测试参数可以以xml表格的形式存储在数据池中。针对任一外部渠道对应的模板内容，业务测试设备在确定模板内容后，可获取动态逻辑规则信息中的逻辑语句代码。之后，执行该代码以自动将目标测试参数写入到模板内容预留的位置中(即对动态逻辑规则信息所在位置进行替换)。具体的，动态逻辑规则信息以占位符的形式设置在模板内容中。例如，该占位符可以通过“${parameter＝A}”的形式进行设置。其中，parameter表示为参数，即此处占位符的参数为“A”，“A”表示在执行动态逻辑规则信息的代码后，将从数据池中获取到的测试参数替换“A”所在的占位符，以自动对模板内容进行组合，得到测试场景信息。

参照图4，在一实施例中，所述测试参数信息包括对所述目标业务进行测试的上一测试状态和对所述目标业务进行测试时的测试编号；业务测试方法还包括如下步骤S111-S113，详述如下：

S111、若所述测试请求中未包括场景ID，则获取所述测试参数信息中包含的测试编号。

在本申请实施例中，上述测试参数信息还包括对目标业务进行测试的测试状态，具体的为对目标业务进行测试时的上一测试状态，以及对目标业务进行测试时的测试编号。

在本申请实施例中，上述测试参数信息可以记录在对目标业务进行测试的测试订单上，该测试订单中记录的测试参数信息可以预先由测试人员进行处理。而后，将生成的测试订单发送至业务测试设备。其中，上述测试订单可以理解为业务发起的每次测试请求中均会携带的测试订单，该测试订单用于记录测试请求中的所有测试参数信息(包括但不限于测试订单得到测试编号和测试订单的上一测试状态)。

在本申请实施例中，在上述测试参数信息中未包括场景ID时，此时业务测试设备无法直接确定是对目标业务的何种测试场景进行具体的业务测试。基于此，业务测试设备在确定目标业务所对应使用的多个发送渠道后，可基于测试参数信中上一测试状态确定目标测试场景。

S112、根据所述测试编号和所述上一测试状态，确定对所述目标业务进行测试的下一测试状态。

S113、从所述目标业务的多个测试场景中，确定用于对所述目标业务的下一测试状态进行测试的目标测试场景。

在本申请实施例中，测试编号可用于标识业务测试设备每次进行测试时的业务。示例性的，业务测试设备可将当前接收到的测试编号与之前时刻接收到的多个测试编号进行比对，确定之前时刻是否已接收到相同的测试编号。若确定具有相同的测试编号，则可基于之前时刻接收到的测试编号，确定之前时刻的测试编号对应进行测试的业务，并将该业务确定为目标业务。同时，在确定目标业务后，业务测试设备可直接确定该目标业务中的多个测试场景、每个测试场景对应的测试状态，以及测试状态的测试顺序。基于此，业务测试设备根据上一测试状态和测试顺序，确定对目标业务进行测试的下一测试状态。之后，根据每个测试场景对应的测试状态，确定用于对目标业务的下一测试状态进行测试的目标测试场景。

具体的，上述一个业务中包含多个测试场景，通常每个测试场景中对应的模板内容不同，其分别用于测试同一个业务下的不同业务场景。示例性的，目标业务包括了活动初期的A测试场景，以及活动完成后的B测试场景。对于A测试场景，在活动初期，该测试场景中对应的模板内容可以为，如“尊敬的【#姓氏#】【#称呼#】，您好！您已报名参加在xxxx年x月x日的活动，请准时前往”。而在活动完成后对应的B测试场景中的模板内容可以为，如“尊敬的【#姓氏#】【#称呼#】，您好！您在xxxx年x月x日的活动中获得【#X#】等奖，请准时领取”等等。此时，A测试场景与B测试场景为对目标业务下的两种活动状态(活动初期状态和活动已完成状态)进行测试的场景。基于此，业务测试设备在确定上一测试状态为处于活动初期状态时，即代表业务测试设备已使用测试场景A对处于活动初期状态的场景进行测试。之后，业务测试设备对当前时刻下接收到的该业务发起的业务测试请求时，可确定对目标业务进行测试的下一状态为活动已完成状态。之后，将活动已完成状态对应的B测试场景，确定为业务测试设备所需使用的目标测试场景。

需要说明的是，业务测试设备在对该目标测试场景进行测试后，返回至业务系统的测试场景信息中，还可包括该目标测试场景对应的测试状态以及测试编号，以便业务系统可将该测试状态以及测试编号作为测试参数信息写入测试订单中。进而，可使业务系统再次对该目标业务发起的测试请求中，可以不包括测试人员写入的场景ID。进一步地，可避免测试人员在配置测试请求中的场景ID时，因目标业务中测试场景的数量过多，导致测试请求中场景ID配置错误，造成某个或多个测试场景漏测的情况。

参照图5，在一实施例中，在S104组合所述测试参数与所述多个发送渠道的模板内容，得到测试场景信息之后，还包括如下步骤S141-142，详述如下：

S141、从所述数据池中，获取与所述目标测试场景关联的业务数据。

在本申请实施例中，通常在使用上述目标测试场景对业务进行测试时，只需从数据池中获取测试参数对模板内容进行替换即可。然而，在实际情况中，业务所需进行的测试，还存在特殊的测试场景。业务在该测试场景下进行测试时，需要实际的业务数据对其进行补充，以使生成的测试场景信息可满足业务校验规则。该类需要满足业务校验规则的数据，均为相应的业务数据。

在本申请实施例中，上述业务数据均可由测试人员预先将其与相对应的目标测试场景进行关联，并将该关联关系进行存储，以便业务测试设备可基于该关联关系从数据池中获取业务数据，

S142、基于所述业务数据的配置规则，对所述测试场景信息进行再配置，得到目标测试场景信息，所述目标测试场景信息满足所述目标业务的业务校验规则。

在本申请实施例中，上述业务数据的配置规则与S1041中使用测试参数替换动态逻辑规则信息的方式类似。

示例性的，对业务进行测试时，通常是对该业务的某一测试场景进行连续性的测试。具体的，对于消费业务的测试场景，业务发起的测试请求中还包括消费者消费金额的测试参数信息。之后，生成的测试场景信息中可为“您此次消费金额为“M$”，消费总额为“N$”。此时，业务测试设备再次对该测试场景重复进行测试时，若此次业务发起的测试请求中包括消费者消费金额的测试参数为“L$”，其生成的的测试场景信息应当为“您此次消费金额为“L$”，消费总额为“N+L$””。基于此，可认为对于目标测试场景中的第二次测试时，其需要从数据池中获取该目标测试场景中预先存储的业务数据(即上一次进行测试时所记录的消费总额“N$”)。若未获取到该业务数据，则生成的测试场景信息将不符合消费者的实际情况，将使消费者的权益受损。以此，业务测试设备通过获取与该目标测试场景相关的业务数据，可以使业务系统接收到的目标测试场景信息更接近于用户接收到的实际信息。进而，使测试人员根据接收到的测试场景信息更准确的确定业务的测试结果。

参照图6，在一实施例中，所述业务测试方法还包括如下步骤S114-S117，详述如下：

S114、针对所述目标业务的任一测试场景，若多个外部渠道正常，则分别获取通过所述多个外部渠道对当前测试场景进行测试后生成的多个渠道测试场景信息。

在本申请实施例中，在外部渠道正常时，通常由外部渠道发送测试场景信息。因业务上线后，其对外发送的各种信息均是由外部渠道进行发送。因此，在外部渠道正常时，使用外部渠道发送测试场景信息，可以使业务系统接收到的信息更接近于实际情况。此时，外部渠道发送的测试场景信息即为渠道测试场景信息。可以理解的是，外部渠道具有多个时，其生成的渠道测试场景信息也具有多个。

需要说明的是，针对目标业务中任一测试场景进行的测试，若其对应的多个外部渠道中有任意一个外部渠道异常，则可采用上述业务测试方法进行业务测试，以使业务测试设备可基于测试请求完成该目标测试场景的业务测试，解决业务系统因外部渠道异常造成测试受阻的问题。

S115、分别对所述多个渠道测试场景信息进行数据清洗，得到在所述当前测试场景下所述多个渠道测试场景信息分别对应的渠道测试参数。

在本申请实施例中，上述对渠道测试场景信息进行数据清洗可以为，清洗渠道测试场景信息中的静态模板信息，保留其内部动态逻辑规则信息对应的测试参数，以及对应测试场景关联的业务数据。

示例性的，针对任一渠道测试场景信息，若渠道测试场景信息为：“尊敬的【#M#】【#N#】，您好！您已报名参加在xxxx年x月x日的活动，请准时前往”。对渠道测试场景信息进行清洗后，可保留其中的【#M#】、【#N#】等信息作为渠道测试参数。

S116、确定所述多个外部渠道对所述当前测试场景进行测试时所述业务系统发送的渠道测试请求。

S117、将所述渠道测试参数信息与所述渠道测试请求进行关联，并存储至所述数据池中。

在本申请实施例中，通过外部渠道进行业务测试时，业务系统发起的业务请求(即渠道测试请求)中将包含所需进行测试的测试场景ID，以及相应的测试参数信息(渠道测试参数信息)。基于此，在得到当前测试场景下每个渠道测试场景信息分别对应的渠道测试参数后，可将该渠道测试参数与渠道测试请求进行关联并存储，以使外部渠道异常时，业务测试设备可基于测试请求从数据池中获取相对应的测试参数。

可以理解的是，上述将渠道测试参数与渠道测试请求进行关联具体可以为：将渠道测试参数与渠道测试请求中的测试参数信息进行关联。基于此，在外部渠道异常时，业务测试设备可基于业务请求中的测试参数信息，从数据池中获取相对应的测试参数，生成测试场景信息。

参照图7，在一实施例中，在S114分别获取通过所述多个外部渠道对当前测试场景进行测试后生成的多个渠道测试场景信息之前，具体包括如下步骤S118-S119，详述如下：

S118、监控所述多个外部渠道的渠道状态。

S119、若所述多个外部渠道的渠道状态均恢复为正常状态，则通过所述多个外部渠道对所述目标业务下的多个测试场景进行测试，并对所述业务系统执行提醒操作。

在本申请实施例中，上述渠道状态包括正常状态以及异常状态。上述多个外部渠道的渠道状态可以由业务系统进行监控。具体的，因业务系统需使用外部渠道进行业务测试，因此，业务系统可时刻监控每个外部渠道的渠道状态。基于此，在业务系统确定每个外部渠道的渠道状态后，可将该渠道状态发送至业务测试设备。

在本申请实施例中，上述提醒操作包括但不限于短信、邮件等方式进行提醒，对此不作限定。

需要说明的是，因上述每种业务对应使用的外部渠道可能各不相同，因此，在某个外部渠道处于异常状态时，其只影响使用该外部渠道进行业务测试的相关业务。基于此，在任一外部渠道的渠道状态恢复为正常状态时，其即可对业务系统执行提醒操作。之后，业务系统可确定使用该外部渠道进行业务测试的相关业务，并在该相关业务中所对应使用的其他外部渠道的渠道状态均处于正常状态时，使用外部渠道对该相关业务进行测试。

请参阅图8，图8是本申请实施例提供的一种业务测试装置的结构框图。本实施例中业务测试装置包括的各模块用于执行图1至图7对应的实施例中的各步骤。具体请参阅图1至图7以及图1至图7所对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。参见图8，业务测试装置800包括：接收模块810、第一确定模块820、第一获取模块830、组合模块840以及返回模块850，其中：

接收模块810，用于在用于对目标业务进行测试的外部渠道异常时，接收业务系统发送的针对所述目标业务的测试请求，所述测试请求包括服务ID、场景ID和测试参数信息。

第一确定模块820，用于根据所述服务ID和场景ID，从所述目标业务的多个测试场景中确定目标测试场景，并确定所述目标测试场景所需使用的多个发送渠道的模板内容。

第一获取模块830，用于从数据池中获取满足所述测试参数信息的测试参数。

组合模块840，用于组合所述测试参数与所述多个发送渠道的模板内容，得到测试场景信息。

返回模块850，用于将所述测试场景信息返回所述业务系统，所述业务系统用于根据所述测试场景信息和预设测试场景信息生成针对所述目标业务的测试结果。

在一实施例中，根据所述服务ID和场景ID，第一确定模块820还用于：

根据所述服务ID，确定所述目标业务对应使用的多个发送渠道；以及，

根据所述场景ID，从所述多个测试场景中确定目标测试场景；

基于所述多个发送渠道，分别获取所述目标测试场景中与所述多个发送渠道对应的模板内容。

在一实施例中，所述模板内容包括静态模板信息和动态逻辑规则信息；组合模块830还用于：

针对任一发送渠道的模板内容，若所述测试参数具有多个，则分别根据所述模板内容中的动态逻辑规则信息，从多个测试参数中依次确定符合每个动态逻辑规则的目标测试参数；

将多个目标测试参数分别对应替换所述动态逻辑规则信息；

将替换后的所述动态逻辑规则信息和所述静态目标信息进行组合，得到所述测试场景信息。

在一实施例中，所述测试参数信息包括对所述目标业务进行测试的上一测试状态和对所述目标业务进行测试时的测试编号；业务测试装置800还包括以下模块：

第二获取模块，用于若所述测试请求中未包括场景ID，则获取所述测试参数信息中包含的测试编号。

第二确定模块，用于根据所述测试编号和所述上一测试状态，确定对所述目标业务进行测试的下一测试状态。

第三确定模块，用于从所述目标业务的多个测试场景中，确定用于对所述目标业务的下一测试状态进行测试的目标测试场景。

在一实施例中，业务测试装置800还包括以下模块：

第三获取模块，从所述数据池中，获取与所述目标测试场景关联的业务数据。

配置模块，用于基于所述业务数据的配置规则，对所述测试场景信息进行再配置，得到目标测试场景信息，所述目标测试场景信息满足所述目标业务的业务校验规则。

在一实施例中，业务测试装置800还包括以下模块：

第四获取模块，用于针对所述目标业务的任一测试场景，若多个外部渠道正常，则分别获取通过所述多个外部渠道对当前测试场景进行测试后生成的多个渠道测试场景信息。

数据清洗模块，用于分别对所述多个渠道测试场景信息进行数据清洗，得到在所述当前测试场景下所述多个渠道测试场景信息分别对应的渠道测试参数。

第四确定模块，用于确定通过所述多个外部渠道对所述当前测试场景进行测试时所述业务系统发送的渠道测试请求。

存储模块，用于将所述渠道测试参数与所述渠道测试请求进行关联，并存储至所述数据池中。

在一实施例中，业务测试装置800还包括以下模块：

监控模块，用于监控所述多个外部渠道的渠道状态。

提醒模块，用于若所述多个外部渠道的渠道状态均恢复为正常状态，则通过所述多个外部渠道对所述目标业务下的多个测试场景进行测试，并对所述业务系统执行提醒操作。

当理解的是，图8示出的业务测试装置的结构框图中，各单元/模块用于执行图1至图7对应的实施例中的各步骤，而对于图1至图7对应的实施例中的各步骤已在上述实施例中进行详细解释，具体请参阅图1至图7以及图1至图7所对应的实施例中的相关描述，此处不再赘述。

图9是本申请另一实施例提供的一种业务测试设备的结构框图。如图9所示，该实施例的业务测试设备900包括：处理器910、存储器920以及存储在存储器920中并可在处理器910运行的计算机程序930，例如业务测试方法的程序。处理器910执行计算机程序930时实现上述各个业务测试方法各实施例中的步骤，例如图1所示的S101至S105。或者，处理器910执行计算机程序930时实现上述图8对应的实施例中各模块的功能，例如，图8所示的模块810至850的功能，具体请参阅图8对应的实施例中的相关描述。

示例性的，计算机程序930可以被分割成一个或多个单元，一个或者多个单元被存储在存储器920中，并由处理器910执行，以完成本申请。一个或多个单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序930在业务测试设备900中的执行过程。

业务测试设备900可包括，但不仅限于，处理器910、存储器920。本领域技术人员可以理解，图9仅仅是业务测试设备900的示例，并不构成对业务测试设备900的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如业务测试设备还可以包括输入输出设备、网络接入设备、总线等。

所称处理器910可以是中央处理单元，还可以是其他通用处理器、数字信号处理器、专用集成电路、现成可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器920可以是业务测试设备900的内部存储单元，例如业务测试设备900的硬盘或内存。存储器920也可以是业务测试设备900的外部存储设备，例如业务测试设备900上配备的插接式硬盘，智能存储卡，闪存卡等。进一步地，存储器920还可以既包括业务测试设备900的内部存储单元也包括外部存储设备。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/业务测试设备的任何实体或装置、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。