交易场景的测试方法及装置、电子设备和可读存储介质与流程

本公开涉及计算机技术领域，更具体地，涉及一种交易场景的测试方法及装置、一种电子设备和一种计算机可读存储介质。

背景技术：

随着自动化测试技术的发展和推广使用，以及各种软件类系统的快速建设，测试人员日常测试过程中需要使用不同种类的自动化工具来进行日常的版本功能验证工作。随着工作的开展，每个测试人员需要维护的自动化脚本越来越多，脚本种类也越来越多样化。

由于每种自动化脚本编写时所依赖的测试工具不相同，而且各个脚本执行时对于环境配置的要求也存在一些差异性。各个功能脚本无法直接自动串联起来并且互相进行参数传递，测试过程中需要测试人员手工介入，按照测试步骤顺序手工提交脚本执行任务，并且对每个脚本执行后输出的数据和输入的数据进行拷贝粘贴，再展开输入输出项的核对工作，整个运行的结果无法自动核对，导致业务场景级自动化测试过程不连续，存在测试工作效率不高等问题。

技术实现要素：

有鉴于此，本公开提供了一种交易场景的测试方法及装置、一种电子设备和一种计算机可读存储介质。

本公开的一个方面提供了一种交易场景的测试方法，包括：获取不同类型的多个测试脚本，上述多个测试脚本用于验证目标交易场景是否正常；获取上述多个测试脚本中每个测试脚本的运行参数，其中，上述每个测试脚本的运行参数至少包括该测试脚本与其他测试脚本之间的相互依赖关系；使用与上述每个测试脚本对应的执行机，基于上述每个测试脚本的运行参数来运行上述多个测试脚本，得到多个运行结果；以及根据上述多个运行结果确定上述目标交易场景是否正常。

根据本公开的实施例，交易场景的测试方法还包括展示测试场景编辑界面；其中，获取上述多个测试脚本中每个测试脚本的运行参数包括：获取在上述测试场景编辑界面上输入的针对上述每个测试脚本的运行参数。

根据本公开的实施例，上述该测试脚本与其他测试脚本之间的依赖关系包括上述该测试脚本与其他测试脚本之间的运行顺序，基于上述每个测试脚本的运行参数来运行上述多个测试脚本包括：在基于上述每个测试脚本的运行顺序运行测试脚本的过程中，基于已经运行完成的测试脚本的运行结果，确定是否调整在上述已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序。

根据本公开的实施例，基于已经运行完成的测试脚本的运行结果，确定是否调整在上述已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序包括：判断上述已经运行完成的测试脚本的运行结果是否满足分支条件；以及在满足上述分支条件的情况下，将上述已经运行完成的测试脚本之后执行的脚本确定为与上述分支条件对应的测试脚本。

根据本公开的实施例，基于已经运行完成的测试脚本的运行结果，确定是否调整在上述已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序包括：根据核对规则对上述已经运行完成的测试脚本的运行结果进行核对；以及根据核对结果确定是否调整在上述已经运行完成的测试脚本之后执行的待执行测试脚本的运行顺序。

根据本公开的实施例，根据上述多个运行结果确定上述目标交易场景是否正常包括：确定上述多个运行结果与标准数据是否一致；以及在上述多个运行结果与上述标准数据一致的情况下，确定上述目标交易场景正常。

根据本公开的实施例，上述不同类型的多个测试脚本包括使用不同工具开发的测试脚本，和/或运行环境不同的测试脚本。

本公开的另一个方面提供了一种交易场景的测试装置，包括第一获取模块，用于获取不同类型的多个测试脚本，上述多个测试脚本用于验证目标交易场景是否正常；第二获取模块，用于获取上述多个测试脚本中每个测试脚本的运行参数，其中，上述每个测试脚本的运行参数至少包括该测试脚本与其他测试脚本之间的相互依赖关系；运行模块，用于使用与上述每个测试脚本对应的执行机，基于上述每个测试脚本的运行参数来运行上述多个测试脚本，得到多个运行结果；以及确定模块，用于根据上述多个运行结果确定上述目标交易场景是否正常。

根据本公开的实施例，交易场景的测试装置还包括展示模块，用于展示测试场景编辑界面；其中，上述第二获取模块用于获取在上述测试场景编辑界面上输入的针对上述每个测试脚本的运行参数。

根据本公开的实施例，上述该测试脚本与其他测试脚本之间的依赖关系包括上述该测试脚本与其他测试脚本之间的运行顺序，上述运行模块用于：在基于上述每个测试脚本的运行顺序运行测试脚本的过程中，基于已经运行完成的测试脚本的运行结果，确定是否调整在上述已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序。

根据本公开的实施例，基于已经运行完成的测试脚本的运行结果，确定是否调整在上述已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序包括：判断上述已经运行完成的测试脚本的运行结果是否满足分支条件；以及在满足上述分支条件的情况下，将上述已经运行完成的测试脚本之后执行的脚本确定为与上述分支条件对应的测试脚本。

根据本公开的实施例，基于已经运行完成的测试脚本的运行结果，确定是否调整在上述已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序包括：根据核对规则对上述已经运行完成的测试脚本的运行结果进行核对；以及根据核对结果确定是否调整在上述已经运行完成的测试脚本之后执行的待执行测试脚本的运行顺序。

根据本公开的实施例，上述确定模块用于确定上述多个运行结果与标准数据是否一致；在上述多个运行结果与上述标准数据一致的情况下，确定上述目标交易场景正常。

根据本公开的实施例，上述不同类型的多个测试脚本包括使用不同工具开发的测试脚本，和/或运行环境不同的测试脚本。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

根据本公开的实施例，可以获取用于验证目标交易场景是否正常的不同类型的多个测试脚本，使用与每个测试脚本对应的执行机，基于每个测试脚本的运行参数来运行多个测试脚本，根据多个运行结果确定目标交易场景是否正常。使得可以将各个功能的测试脚本直接自动串联起来，并且互相进行参数传递，即使编写自动化测试脚本所依赖的测试工具不相同，或者各个脚本执行时对于环境配置的要求存在差异性，测试过程中无需测试人员手工介入，无需对每个脚本执行后输出的数据和输入的数据进行拷贝粘贴，可以解决相关技术中，通过不同类别脚本测试交易场景时需要人工介入，导致业务场景级自动化测试过程不连续的技术问题，提高了测试工作效率。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的可以应用交易场景的测试方法及装置的示例性系统架构；

图2示意性示出了根据本公开实施例的交易场景的测试方法的流程图；

图3示意性示出了根据本公开实施例的交易场景的测试方法的流程图；

图4示意性示出了根据本公开实施例的交易场景的测试装置的框图；以及

图5示意性示出了根据本公开实施例的适于实现上文描述的测试方法的计算机系统的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。在使用类似于“a、b或c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b或c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。

在编制自动化测试脚本时，一般可以按照功能和测试意向对自动化脚本进行解耦拆分，形成模块化的公共脚本，提高自动化脚本的复用率，降低某个单向功能变动时已有自动化脚本的维护更新成本。

在这种脚本编制原则下，在做某个业务流程的自动化测试时，一般需要将功能测试的自动化脚本进行串联组装(或进行逻辑判断后串联)，形成一个测试脚本集合，并且在所有脚本运行完成后，将各个脚本中的输出数据进行一些逻辑计算后编写核对公式进行校验。

由于每种自动化脚本编写时所依赖的测试工具不相同，而且各个脚本执行时对于环境配置的要求也存在一些差异性。各个功能脚本无法直接自动串联起来并且互相进行参数传递，测试过程中需要测试人员手工介入，按照测试步骤顺序手工提交脚本执行任务。并且对每个脚本执行后输出的数据和输入的数据进行拷贝粘贴，再展开输入输出项的核对工作，整个运行的结果无法自动核对，导致业务场景级自动化测试过程不连续，存在测试工作效率不高等问题。

本公开的实施例提供了一种交易场景的测试方法，包括：获取不同类型的多个测试脚本，多个测试脚本用于验证目标交易场景是否正常；获取多个测试脚本中每个测试脚本的运行参数，其中，每个测试脚本的运行参数至少包括该测试脚本与其他测试脚本之间的相互依赖关系；使用与每个测试脚本对应的执行机，基于每个测试脚本的运行参数来运行多个测试脚本，得到多个运行结果；根据多个运行结果确定目标交易场景是否正常。

图1示意性示出了根据本公开实施例的可以应用交易场景的测试方法及装置的示例性系统架构。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构100可以包括终端设备101，执行机102、103、104和网络105。网络105用以在终端设备101和执行机102、103、104之间提供通信链路的介质。网络105可以包括各种连接类型，例如有线和/或无线通信链路等等。

终端设备101可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

执行机102、103、104可以是执行测试脚本的计算设备。

需要说明的是，本公开实施例所提供的交易场景的测试方法一般可以由终端设备101执行。相应地，本公开实施例所提供的交易场景的测试装置一般可以设置于终端设备101中。本公开实施例所提供的交易场景的测试方法也可以由不同于终端设备101且能够与终端设备101通信的其他设备执行。相应地，本公开实施例所提供的交易场景的测试装置也可以设置于不同于终端设备101且能够与终端设备101通信的其他设备中。

应该理解，图1中的终端设备、网络和执行机的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和执行机。

图2示意性示出了根据本公开实施例的交易场景的测试方法的流程图。

如图2所示，该方法包括操作s210～s240。

在操作s210，获取不同类型的多个测试脚本，多个测试脚本用于验证目标交易场景是否正常。

根据本公开的实施例，不同类型的多个测试脚本包括使用不同工具开发的测试脚本，和/或运行环境不同的测试脚本。

例如，基于不同工具开发的自动化测试脚本，如qtp脚本，selenium脚本等，由于开发和运行都是用的不同的工具。

例如，运行环境不同的测试脚本可以是基于不同平台的自动化测试脚本，如针对桌面应用的测试，针对web应用的测试、针对手机端的测试等。运行环境涉及web应用、客户端和移动终端等等，需要安装和维护各类测试环境。

根据本公开的实施例，目标交易场景可以是存款交易场景，转账交易场景等等。

在操作s220，获取多个测试脚本中每个测试脚本的运行参数，其中，每个测试脚本的运行参数至少包括该测试脚本与其他测试脚本之间的相互依赖关系。

根据本公开的实施例，每个测试脚本的运行参数可以包括测试脚本的运行数据、是否添加场景分支节点或核对节点、脚本配置的顺序、前后项关系、脚本间输入和输出参数的对照关系等。其中，依赖关系可以是脚本配置的顺序、前后项关系、脚本间输入和输出参数的对照关系等等。

在操作s230，使用与每个测试脚本对应的执行机，基于每个测试脚本的运行参数来运行多个测试脚本，得到多个运行结果。

根据本公开的实施例，可以对场景中的测试脚本进行调度执行。例如，根据脚本执行平台的不同将对应脚本分配到不同的执行机上运行，并保存运行结果、数据和截图。场景中的脚本全部运行完成后，使用人员可以多维度查看运行结果，并进行结果分析。

在操作s240，根据多个运行结果确定目标交易场景是否正常。

根据本公开的实施例，可以确定多个运行结果与标准数据是否一致，在多个运行结果与标准数据一致的情况下，可以确定目标交易场景正常。

在相关技术中，不同类型的测试脚本在执行时，无法使用已有的方法进行参数传递，并且在一个测试脚本运行完成后，不能直接调用另一个工具开发的脚本。通过本公开的实施例，可以获取用于验证目标交易场景是否正常的不同类型的多个测试脚本，使用与每个测试脚本对应的执行机，基于每个测试脚本的运行参数来运行多个测试脚本，根据多个运行结果确定目标交易场景是否正常。使得可以将各个功能的测试脚本直接自动串联起来，并且互相进行参数传递，即使编写自动化测试脚本所依赖的测试工具不相同，或者各个脚本执行时对于环境配置的要求存在差异性，测试过程中无需测试人员手工介入，无需对每个脚本执行后输出的数据和输入的数据进行拷贝粘贴，可以解决相关技术中，通过不同类别脚本测试交易场景时需要人工介入，导致业务场景级自动化测试过程不连续的技术问题，提高了测试工作效率。

根据本公开实施例，在对交易场景进行测试前，可以先展示测试场景编辑界面，用户可以在测试场景编辑界面编辑或选择交易场景所需的测试脚本，方便了用户操作。电子设备可以获取在测试场景编辑界面上输入的针对每个测试脚本的运行参数。

根据本公开的实施例，可以在测试场景编辑界面中对不同种类端到端测试工具编写的测试脚本的自动串联执行。例如，web浏览器端，手机端、pc客户端等等测试工具编写的测试脚本，解决了相关技术中针对一个交易场景测试中包含多种类型自动化测试脚本时需要人工介入协同执行的问题，从而满足自动化的测试完整业务流程的需要。

根据本公开的实施例，该测试脚本与其他测试脚本之间的依赖关系包括该测试脚本与其他测试脚本之间的运行顺序，基于每个测试脚本的运行参数来运行多个测试脚本包括：在基于每个测试脚本的运行顺序运行测试脚本的过程中，基于已经运行完成的测试脚本的运行结果，确定是否调整在已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序。

根据本公开的实施例，基于已经运行完成的测试脚本的运行结果，确定是否调整在已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序包括：判断已经运行完成的测试脚本的运行结果是否满足分支条件，在已经运行完成的测试脚本的运行结果满足分支条件的情况下，将已经运行完成的测试脚本之后执行的脚本确定为与分支条件对应的测试脚本。

根据本公开的实施例，在已经运行完成的测试脚本的运行结果不满足分支条件的情况下，可以不改变已经运行完成的测试脚本之后执行的脚本，按照预设的依赖关系，执行已经运行完成的测试脚本之后执行的脚本。

根据本公开的实施例，可以根据上一节点脚本运行后的结果或某一输出参数的值，判断之后的脚本运行路径。判断已经运行完成的测试脚本的运行结果是否满足分支条件可以分为两种：一是根据布尔值判断真假后选择对应的路径。另一种是根据实际运行获取到的值判断，比如获取到当前业务为美元，则运行美元对应的脚本路径。

根据本公开的实施例，通过场景化的公共脚本组装串接、脚本执行分支流程配置的模式，支持了多分支流程业务场景的自动化测试。解决了相关技术中涉及到多分支流程测试覆盖业务场景时，因公共脚本间无法进行分支串接，多个分支流程需要写在同一个自动化脚本内，导致单个自动化脚本包含的功能流程过长，某个系统功能发生改变时，所有涉及到该功能的存量自动化脚本维护更新工作量大的问题，降低了覆盖业务场景的自动化工作量投入。

根据本公开的实施例，基于已经运行完成的测试脚本的运行结果，确定是否调整在已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序包括：根据核对规则对已经运行完成的测试脚本的运行结果进行核对，根据核对结果确定是否调整在已经运行完成的测试脚本之后执行的待执行测试脚本的运行顺序。

根据本公开的实施例，在交易场景编辑过程中，也可以在需要校验的地方增加校验节点，在此校验节点中设置一个或多个核对规则以及对应的参数关系，实现自动校验的功能。场景运行顺序设置完成后，可以添加场景中所有脚本的参数关系映射，并为场景添加一套或多套运行数据，从而完成整个自动化测试的脚本准备和数据准备。校验规则例如可以是将运行结果与后台存储的标准数据进行比对，确定是否相同。

根据本公开的实施例，可以实现同一个交易场景模式下，支持不同类型的测试脚本之间数据核对，测试人员可以通过设置专门的结果核对节点，实现结果核对校验，从而支持了业务的全流程自动化测试。

下面参考图3，结合具体实施例对图2所示的方法做进一步说明。

图3示意性示出了根据本公开实施例的交易场景的测试方法的流程图。

如图3所示，该方法包括操作s301～s313。

在操作s301，新建场景并设置基本信息。

在操作s302，添加所需多种脚本至场景中。

根据本公开的实施例，可以将测试人员选择的交易场景测试中要运行的脚本添加到一个自动化场景中。进一步地，还可以设置不同脚本的运行参数。例如，设置脚本运行的前后项关系及输入、输出参数对照关系。在操作s303，进入场景编辑界面。

在操作s304，根据场景测试需要确定是否需要设置分支节点。

在操作s305，在确定需要设置分支节点的情况下，添加分支节点，设置分支判断条件，否则直接执行操作s309。

在操作s306，根据分支判断条件调整相应测试脚本的节点位置。

在操作s307，根据场景测试需要确定是否需要设置核对节点。

在操作s308，在确定需要设置核对节点的情况下，添加核对节点，设置核对规则。

在操作s309，根据场景测试需要配置每个测试脚本的执行顺序。

在操作s310，根据场景测试需要配置每个测试脚本的输入输出参数。

在操作s311，确定是否保存场景，如果不保存场景，则返回操作s303，如果保存场景，执行操作s312。

在操作s312，确定是否提交场景任务，，如果不提交场景任务，则返回操作s303，如果提交场景任务，执行操作s313。

在操作s313，提交场景任务。

根据本公开的实施例，在场景所需的测试脚本执行的过程中，可以自动将场景中的脚本下发到对应执行环境的后台公共执行机中运行，使得测试人员无需准备多个脚本执行环境的环境维护工作量。同时，通过后台公共执行机自动扩容的模式，也能够自动依据待执行任务的情况增加或减少执行机的数量，节约实际的测试时间，提升了测试效率，提高了环境资源的利用率。

根据本公开的实施例，可以针对不同测试工具和测试平台，进行脚本场景化组装配置，支持按业务流程对不同功能的脚本自动调用，以及脚本间输入/输出参数传递的功能，从而达到全流程测试自动化的目的。同时，可以通过系统界面访问方式，实现可视化的场景脚本的组装和参数配置。通过提供后台无人值守共享执行机环境的执行方式，解决了不同类型脚本对执行机环境多样性的需求，进一步释放了测试人员的电脑资源，提高了工作效率。

图4示意性示出了根据本公开实施例的交易场景的测试装置的框图。

如图4所示，交易场景的测试装置400包括第一获取模块410、第二获取模块420、运行模块430和确定模块440。

第一获取模块410用于获取不同类型的多个测试脚本，多个测试脚本用于验证目标交易场景是否正常。

第二获取模块420用于获取多个测试脚本中每个测试脚本的运行参数，其中，每个测试脚本的运行参数至少包括该测试脚本与其他测试脚本之间的相互依赖关系。

运行模块430用于使用与每个测试脚本对应的执行机，基于每个测试脚本的运行参数来运行多个测试脚本，得到多个运行结果。

确定模块440用于根据多个运行结果确定目标交易场景是否正常。

根据本公开的实施例，交易场景的测试装置400还包括展示模块，用于展示测试场景编辑界面。

根据本公开的实施例，第二获取模块420可以用于获取在测试场景编辑界面上输入的针对每个测试脚本的运行参数。

根据本公开的实施例，该测试脚本与其他测试脚本之间的依赖关系包括该测试脚本与其他测试脚本之间的运行顺序，运行模块430用于在基于每个测试脚本的运行顺序运行测试脚本的过程中，基于已经运行完成的测试脚本的运行结果，确定是否调整在已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序。

根据本公开的实施例，基于已经运行完成的测试脚本的运行结果，确定是否调整在已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序包括判断已经运行完成的测试脚本的运行结果是否满足分支条件；在满足分支条件的情况下，将已经运行完成的测试脚本之后执行的脚本确定为与分支条件对应的测试脚本。

根据本公开的实施例，基于已经运行完成的测试脚本的运行结果，确定是否调整在已经运行完的测试脚本之后执行的待执行测试脚本的运行顺序包括：根据核对规则对已经运行完成的测试脚本的运行结果进行核对；根据核对结果确定是否调整在已经运行完成的测试脚本之后执行的待执行测试脚本的运行顺序。

根据本公开的实施例，确定模块440用于确定多个运行结果与标准数据是否一致；在多个运行结果与标准数据一致的情况下，确定目标交易场景正常。

根据本公开的实施例，不同类型的多个测试脚本包括使用不同工具开发的测试脚本，和/或运行环境不同的测试脚本。

根据本公开的实施例，在使用与每个测试脚本对应的执行机执行测试脚本前，可以对执行机进行调度。

例如，本公开可以提供一种调度执行模块，负责对场景的调度和执行。首先，将待执行的场景以脚本为单位进行拆分，根据场景执行总体情况、每个测试脚本对执行机执行环境的要求，后台共享执行机池各个执行机环境的配置及及空闲状态等指标等，把测试脚本执行任务分配到相应执行机的执行队列中。然后，执行机从执行队列中获取任务，准备任务所要求的执行环境，开始执行任务。本公开还可以提供一种执行机监控模块，对整个执行过程的信息进行采集，将执行过程的关键脚本节点以及最终执行结果等信息记录到数据库存储。

根据本公开的实施例，调度执行模块包括任务调度单元，任务执行单元和结果记录单元。

任务调度单元负责场景的拆分以及任务的分配。将所有场景以节点为粒度进行拆分，单个节点依次执行。根据场景执行信息获取将要执行的节点环境信息，然后综合执行机池各个执行机的执行环境、任务排队状态以及该场景对执行时间、执行优先级等因素的要求，分配到适合的执行机的执行队列中。

任务执行单元用于保证节点任务的顺利执行。执行机池中的执行机在上一个任务节点执行完毕后，从分配到自己的执行队列中获取下一任务节点。根据下一任务节点的环境信息，判断是否需要进行环境的切换，环境准备完毕后，调用脚本执行。

结果记录单元用于记录执行过程和执行结果。在脚本开始运行后，该单元便开始对整个执行过程进行监控。在节点设置的关键执行点以及该单元默认的关键执行点都会进行执行现场的保存记录。同时，在脚本执行完毕后，该单元把执行过程中捕捉的需要后续节点参考使用的关键信息传递给后续节点，并判断最终运行结果是否正确，把运行结果和相关的执行日志等信息记录起来。

运行结束后，可以通过运行截图、日志等查看场景中的各脚本的执行结果和输出参数。

根据本公开的实施例，交易场景的测试装置可以包括调度执行模块和执行机监控模块。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，第一获取模块410、第二获取模块420、运行模块430和确定模块440中的任意多个可以合并在一个模块/单元/子单元中实现，或者其中的任意一个模块/单元/子单元可以被拆分成多个模块/单元/子单元。或者，这些模块/单元/子单元中的一个或多个模块/单元/子单元的至少部分功能可以与其他模块/单元/子单元的至少部分功能相结合，并在一个模块/单元/子单元中实现。根据本公开的实施例，第一获取模块410、第二获取模块420、运行模块430和确定模块440中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，第一获取模块410、第二获取模块420、运行模块430和确定模块440中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

需要说明的是，本公开的实施例中测试装置部分与本公开的实施例中测试方法部分是相对应的，测试装置部分的描述具体参考测试方法部分，在此不再赘述。

本公开还提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个指令，其中，当上述一个或多个指令被上述一个或多个处理器执行时，使得上述一个或多个处理器实现本公开所提供的测试方法。

根据本公开的实施例，以电子设备为计算机系统为例。

图5示意性示出了根据本公开实施例的适于实现上文描述的测试方法的计算机系统的框图。图5示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图5所示，根据本公开实施例的计算机系统500包括处理器501，其可以根据存储在只读存储器(rom)502中的程序或者从存储部分508加载到随机访问存储器(ram)503中的程序而执行各种适当的动作和处理。处理器501例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))，等等。处理器501还可以包括用于缓存用途的板载存储器。处理器501可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在ram503中，存储有系统500操作所需的各种程序和数据。处理器501、rom502以及ram503通过总线504彼此相连。处理器501通过执行rom502和/或ram503中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除rom502和ram503以外的一个或多个存储器中。处理器501也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统500还可以包括输入/输出(i/o)接口505，输入/输出(i/o)接口505也连接至总线504。系统500还可以包括连接至i/o接口505的以下部件中的一项或多项：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至i/o接口505。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511被安装。在该计算机程序被处理器501执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器实现本公开所提供的测试方法。

根据本公开的实施例，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质。例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom502和/或ram503和/或rom502和ram503以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。