CN111176975B - 一种测试方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本申请公开了一种测试方法、装置、设备及计算机可读存储介质，该方法包括：获取待测数据；所述待测数据为用于调用桩代码的参数数据，所述桩代码为对待测程序中的数据输出代码接口打桩得到的；抽取所述待测数据中包含的数据要素作为待测数据要素；基于预设的验证规则对所述待测数据要素进行验证，得到对应的验证结果，并基于所述验证结果确定所述待测程序是否正常。本申请中获取用于调用替代数据输出代码接口的桩代码的参数数据，进而基于对由参数数据中抽取的数据要素进行验证的结果确定待测程序是否正常，能够有效确定出待测程序是否正常，或者说能够有效确定出待测程序包含的各项功能是否正常，从而保证了待测程序的正常使用。

Description

一种测试方法、装置、设备及计算机可读存储介质

技术领域

本申请涉及程序测试技术领域，更具体地说，涉及一种测试方法、装置、设备及计算机可读存储介质。

背景技术

随着计算机技术的发展，人们在日常生活、商业活动等中需要实现的操作，越来越多的能够以计算机程序的方式实现，如网上支付、金融交易等，从而大大提高了其便利性。

在实际应用中，可能需要因实际需要或者其他因素对计算机程序进行修改等；为了使修改后的计算机程序可以正常使用，通常需要对计算机程序进行测试。现有的计算机程序的测试方案都是根据需求按功能验证，但是如果需求没有描述或者是与描述的需求非直接相关的错误修改的功能，就无法通过这种测试方案发现。

发明内容

本申请的目的是提供一种测试方法、装置、设备及计算机可读存储介质，能够有效确定出待测程序是否正常，或者说能够有效确定出待测程序包含的各项功能是否正常，从而保证了待测程序的正常使用。

为实现上述目的，一方面，本申请提供了一种测试方法，包括：

获取待测数据；所述待测数据为用于调用桩代码的参数数据，所述桩代码为对待测程序中的数据输出代码接口打桩得到的；

抽取所述待测数据中包含的数据要素作为待测数据要素；

基于预设的验证规则对所述待测数据要素进行验证，得到对应的验证结果，并基于所述验证结果确定所述待测程序是否正常。

又一方面，本申请还提供了一种测试方法，包括：

对待测程序中的数据输出代码接口打桩，得到对应的桩代码；

获取用于调用所述桩代码的参数数据，并将所述参数数据作为待测数据；

将所述待测数据传输至测试平台，以便所述测试平台基于所述待测数据实现对所述待测程序的测试。

又一方面，本申请还提供了一种测试装置，包括：

数据获取模块，用于：获取待测数据；所述待测数据为用于调用桩代码的参数数据，所述桩代码为对待测程序中的数据输出代码接口打桩得到的；

要素抽取模块，用于：抽取所述待测数据中包含的数据要素作为待测数据要素；

要素验证模块，用于：基于预设的验证规则对所述待测数据要素进行验证，得到对应的验证结果，并基于所述验证结果确定所述待测程序是否正常。

又一方面，本申请还提供了一种测试装置，包括：

接口打桩模块，用于：对待测程序中的数据输出代码接口打桩，得到对应的桩代码；

数据获取模块，用于：获取用于调用所述桩代码的参数数据，并将所述参数数据作为待测数据；

数据传输模块，用于：将所述待测数据传输至测试平台，以便所述测试平台基于所述待测数据实现对所述待测程序的测试。

又一方面，本申请还提供了一种测试设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现前述测试方法的步骤。

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

本申请公开的技术方案中，获取待测数据后抽取待测数据中包含的数据要素为待测数据要素，基于预设的验证规则对待测数据要素进行验证，进而基于验证结果确定待测程序是否正常，其中，待测数据为调用桩代码所用的参数数据，而桩代码为对待测程序中数据输出代码接口打桩得到的，因此对于桩代码的调用等同于对于数据输出代码接口的调用。由于待测程序在实现其所需实现的功能时是通过调用数据输出代码接口实现的，因此能否成功调用数据输出代码接口直接影响了待测程序的功能能否正常实现、或者说待测程序是否正常，而用于调用代替数据输出代码接口的参数数据是否正常又直接影响了能否成功调用数据输出代码接口，因此本申请中获取调用数据输出代码接口的参数数据，进而基于对由参数数据中抽取的数据要素进行验证的结果确定待测程序是否正常，能够有效确定出待测程序是否正常，或者说能够有效确定出待测程序包含的各项功能是否正常，从而保证了待测程序的正常使用；进而通过这种测试方案，实现待测程序中隐蔽缺陷的自动提前发现；为金融系统或支付系统等待测程序减少非预知风险，降低bug上线影响及资金风险等。

附图说明

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

图1为本申请实施例提供的一种测试方法所适用的系统架构的示意图；

图2为本申请实施例提供的一种测试方法的第一种流程图；

图3为本申请实施例提供的一种测试方法的第二种流程图；

图4为本申请实施例提供的一种测试方法的第三种流程图；

图5为本申请实施例提供的一种测试方法的第四种流程图；

图6为本申请实施例提供的一种测试方法在具体应用场景中的交互图；

图7为本申请实施例提供的一种测试方法的第五种流程图；

图8为本申请实施例提供的一种测试装置的第一种结构示意图；

图9为本申请实施例提供的一种测试装置的第二种结构示意图；

图10为本申请实施例提供的一种测试设备的结构示意图。

具体实施方式

在实际应用中，可能需要对计算机程序进行修改；如果修改出现错误则可能导致计算机程序的某些功能无法正常使用；现有的测试方案都是根据需求按功能验证，也即在实现测试时仅对需要使用的功能进行测试，如需要实现网上支付功能则仅对网上支付这一项功能进行测试，以确定这项功能能否正常实现；但是对于暂时不需要用到的功能或者是与需要使用的功能具有间接关系的功能，则无法通过上述测试方案确定这些功能是否存在问题，也就无法利用计算机程序正常使用这些功能。

鉴于目前所存在的上述问题，本申请提出了对计算机程序实现测试的技术方案，通过该技术方案，能够实现计算机程序存在的缺陷的自动发现，从而保证了计算机程序的正常使用。

为了便于理解，下面对本申请的技术方案所适用的系统架构进行介绍。参见图1，其示出了本申请的一种测试方法所适用的系统的组成架构。

如图1所示，本申请的测试方法所适用的系统的一种组成架构可以包括被测终端10、测试终端20和管理终端30，其中，被测终端10的数量可以为1个，也可以为大于1个的数量，图1以被测终端的数量为3个的实现方式进行展示。

其中，被测终端10、测试终端20及管理终端30均可以为计算机设备、智能终端或者其他能够利用计算机程序实现的终端，而被测终端10、测试终端20及管理终端30可以是相同的终端，也可以是不同的终端，在此不做具体限定；图1以被测终端10及测试终端20均为计算机设备，而管理终端30为智能终端的实现方式进行展示。

对于被测终端10，在一种可能的情况中，被测终端10可以包括待测程序，待测程序即为需要进行测试的计算机程序，待测程序具有打桩功能。在需要对待测程序实现测试时，待测程序可以对其包含的、需要进行测试的数据输出代码接口进行打桩，得到对应的待测数据，进而将待测数据输出至测试终端30，以便测试终端30基于待测数据实现对应的测试操作。

在一种可能的情况中，被测终端10可以包括待测程序及打桩程序，待测程序为需要进行测试的计算机程序，打桩程序为具有打桩功能的程序，在需要对待测程序实现测试时，打桩程序可以对待测程序包含的、需要进行测试的数据输出代码接口进行大装置，得到对应的待测数据，进而将待测数据输出至测试终端30，以便测试终端30基于待测数据实现对应的测试操作。

在一种可能的情况中，被测终端10可以包括监控程序，监控程序可以监控待测程序或者打桩程序的打桩功能。在待测程序或者打桩程序对需要进行测试的数据输出代码接口进行打桩的过程中，监控程序时刻监控待测程序或者打桩程序的打桩功能相应操作，以在待测程序或者打桩程序的打桩功能无法正常实现时输出对应的提示信息，以便测试人员在得知该提示信息后对待测程序或者打桩程序的打桩功能进行修复。

在一种可能的情况中，被测终端10还可以包括人机交互界面，该人机交互界面可以用于上述提示信息向外界的展示，还可以供外界测试人员在人机交互界面上发送测试指令，人机交互界面将测试指令传输给待测程序或者打桩程序，待测程序或者打桩程序在测试指令的触发下自动实现相应数据输出代码接口的打桩及对应待测数据的传输等操作。

对于测试终端20，测试终端20可以包括测试平台，测试平台用于对待测数据实现测试，具体来说，测试平台可以在接收到被测终端10发送的待测数据后，对待测数据提取待测数据要素，并基于预设的验证规则对待测数据要素进行验证，以基于验证结果确定待测程序是否正常。

在一种可能的情况中，测试终端20可以包括终端切换程序，由于被测终端10的数量可能为多个(大于1个)，此时则需要确定当前需要进行测试的被测数据所属的被测终端10，终端切换程序在接收到待测数据后确定出对应被测终端10，将接收到的待测数据对应被测终端10的信息通知给测试平台，以便测试平台以待测数据所属被测终端10对应的方式实现对待测数据的测试。

在一种可能的情况中，测试终端20可以包括数据接收程序，数据接收程序能够接收被测终端发送的待测数据，如果同时接收到多个被测终端10发送的待测数据，则确定各个被测终端10的优先级，按照优先级从高到低的顺序将对应的待测数据传输给终端切换程序，从而使得优先级高的被测终端10对应待测数据可以优先被测试。

在一种可能的情况中，为了实现对多个被测终端10对应待测数据的并行测试，测试终端20中的测试平台的数量可以为多个。此时，终端切换程序则需要确定出当前需要进行测试的每个待测数据所属的被测终端10，并将每个待测数据对应的被测终端的信息通知给每个待测数据对应的测试平台。

对于管理终端30，管理终端30可以包括指令响应程序，指令响应程度可以在接收输入指令后响应该指令实现对应操作，其中的指令可以为任意能够由管理终端30与测试终端20交互实现的指令，如指令响应程序可以在接收到外界输入的查询指令后，将查询指令发送给测试终端20，并接收到测试终端20反馈的信息后显示该信息；又如指令响应程序还可以在接收到外界输入的停止指令后，将停止指令发送至测试终端20，以指示测试终端20停止对应待测数据的测试，等。对应的，在一种可能的情况中，测试终端20还可以包括交互程序，交互程序可以实现与管理终端的交互及实现管理终端发送的指令对应的操作；如交互程序在接收到管理终端30发送的查询指令后，可以查询查询指令对应的信息并返回给管理终端30；查询的信息可以包括当前进行测试的待测数据所属被测终端10，当前进行测试的进度等；又如交互程序还可以在接收到管理终端30发送的停止指令后，停止对应的待测数据的测试，等。

请参阅图2，其示出了本申请实施例提供的一种测试方法的流程图，该测试方法可以包括：

S101：获取待测数据；待测数据为用于调用桩代码的参数数据，桩代码为对待测程序中的数据输出代码接口打桩得到的。

本申请实施例提供的一种测试方法的执行主语可以为对应的测试装置，而该装置可以设置于测试平台中，因此本申请实施例提供的一种测试方法的执行主语可以为测试平台，或者说该测试方法对应于测试平台侧；以下在需要时以执行主语为测试平台进行说明。

待测程序为需要进行测试的计算机程序或者说计算机程序系统，如用于实现网上支付功能的支付系统、用于实现金融交易等功能的金融系统等。在实际应用中，待测程序实现其能够实现的功能时是通过调用对应的接口来实现的，这些接口包含于待测程序中，具体可以是数据输出代码接口。

简单来说，数据输出代码接口为供待测程序调用、以使得待测程序向外界或者其他程序或者其他模块等输出相关信息以实现对应操作的接口，如输出调用信息以实现PRC(Remote Procedure Calls，远程过程调用)调用、输出访问信息以实现DB(数据库)访问等。如果想要实现数据输出代码接口的有效调用，进而有效实现对应操作，则需要保证调用数据输出代码接口的参数数据是正确的。

如果对待测程序的修改出现错误，也即待测程序中存在异常，则会导致调用数据输出代码接口的参数数据出现错误，进而对数据输出代码接口的调用出现错误，如在待测程序实现某项功能时调用了错误的数据输出代码接口或者无法成功调用需要调用的数据输出代码接口等，在实际使用的具体情境中，如在实现DB访问时，如果用于调用对应的数据输出代码接口的参数数据出现错误，则无法实现对应的数据输出代码接口的调用，进而会导致无法正确写入DB数据或者更新字段。因此，本实施例中通过对调用待测程序中数据输出代码接口所用的参数数据(或者说是重载数据输出代码接口的入参及值)进行测试，从而确定待测程序是否正常。

对数据输出代码接口进行打桩能够得到对应的桩代码，简单来说，桩代码就是用来代替数据输出代码接口的代码。本实施例中在需要获取用于调用数据输出代码接口的参数数据时，先对数据输出代码接口进行打桩得到对应的桩代码，从而利用桩代码代替数据输出代码接口被调用以实现对应的测试，不影响原有数据输出代码接口的接口逻辑，由此能够避免数据输出代码接口在测试过程中出现损害。

具体来说，待测程序实现其所能实现的功能时是存在对应的业务的，业务的执行过程即为待测程序实现对应功能的过程；对应的，业务在执行过程中会通过调用数据输出代码接口来实现相应的操作，在得到数据输出代码接口的桩代码后，则业务在执行过程中可以通过调用桩代码来实现相应的操作，那么则可以在业务调用桩代码时获取到业务调用桩代码所用的参数数据，进而利用这些获取的参数数据实现待测程序的测试。而调用桩代码所用的参数数据，可以为调用桩代码的语句中除表示所调用的函数之外的其他参数，如update语句中位于update之后的均可以作为参数数据。

S102：抽取待测数据中包含的数据要素作为待测数据要素。

抽取待测数据中包含的数据要素，即为抽取参数数据中包含的影响数据输出代码接口代码调用能否成功的信息要素，这些信息要素可以为预先根据实际需要进行设定的。具体来说，抽取的数据要素可以包括参数数据中包含的资源、属性、动作或者某些要验证的影响功能实现的关键字段，比如待测程序为支付系统时，待测数据中的商户号可以作为资源被抽取，商户的结算规则可以作为属性被抽取，结算费率等可以作为关键字段被抽取，是否转账或提现等字段可以作为动作被抽取，从而在步骤S103中的验证即可就不同属性检查对应资源的动作是否有异常，资源的关键字段计算后是否有异常等，从而确定出抽取的数据要素是否有异常，待测程序是否有异常。

需要进行说明的是，在后续对待测数据要素进行验证的过程中，可能是直接对待测数据要素进行验证，也可能是需要将待测数据要素进行计算后再对计算得到的值进行验证，这些都是可以根据实际需要进行设定。因此，为了方便后续对待测数据要素的验证，本实施例中抽取的待测数据要素可以是变量的形式进行保存，变量可供后续需要时直接引用取值参与计算，如待测系统为支付系统，后续对待测数据要素进行验证时为对扣费金额进行验证，则抽取的待测数据要素则可以包括商户的费率变量rate，商户的支付额变量amount，从而在对待测数据要素进行验证时则可以先利用(支付额amount*费率rate)计算出对应的预计扣费金额，再对预计扣费金额进行验证。

那么对于数据要素的抽取过程，可以根据实际需要预先设定对应的抽取规则进而通过代码自定义实现，具体来说，可以通过字段-变量的对应关系配置由待测数据中选择性抽取数据要素作为待测数据要素，也即可以设置需要抽取的数据要素的字段，从而由待测数据中抽取出与配置的字段对应的变量作为待测数据要素，如待测程序为支付系统，设置的字段包括费率，则可以由待测数据中抽取费率变量作为待测数据要素；如果内存资源充足，也可以默认将待测数据中包含的所有字段都作为变量进行抽取，这种方式能够对待测数据包含的全部字段进行验证，保证了验证结果符合待测数据包含的全部字段，进而保证了验证结果的有效性。另外，在得到待测数据要素后，可以将待测数据要素对应的全部变量对象系列化后进行存储，对应的，在对待测数据要素进行验证时则需要先对待测数据要素对应的全部变量对象反系列后再使用，从而便于对待测数据要素的保存管理。

S103：基于预设的验证规则对待测数据要素进行验证，得到对应的验证结果，并基于验证结果确定待测程序是否正常。

其中，预设的验证规则可以根据实际需要进行设定，基于预设的验证规则对待测数据要素进行验证，即为验证待测数据要素是否存在异常；由于待测数据要素为由用于调用桩代码实现相应功能的参数数据中抽取的，因此待测数据要素是否正常能够直接影响到对对应桩代码的调用是否成功，而对桩代码的调用是否成功则直接影响了对应功能的实现是否成功，动能的实现是否成功则表示了待测程序是否正常，正常的待测程序能够通过调用桩代码实现相应的功能，存在异常的待测程序则无法成功通过调用桩代码实现相应的功能。因此，本实施例中通过验证待测数据要素是否正常，确定待测程序是否正常。

本申请公开的技术方案中，获取待测数据后抽取待测数据中包含的数据要素为待测数据要素，基于预设的验证规则对待测数据要素进行验证，进而基于验证结果确定待测程序是否正常，其中，待测数据为调用桩代码所用的参数数据，而桩代码为对待测程序中数据输出代码接口打桩得到的，因此对于桩代码的调用等同于对于数据输出代码接口的调用。由于待测程序在实现其所需实现的功能时是通过调用数据输出代码接口实现的，因此能否成功调用数据输出代码接口直接影响了待测程序的功能能否正常实现、或者说待测程序是否正常，而用于调用代替数据输出代码接口的参数数据是否正常又直接影响了能否成功调用数据输出代码接口，因此本申请中获取调用数据输出代码接口的参数数据，进而基于对由参数数据中抽取的数据要素进行验证的结果确定待测程序是否正常，能够有效确定出待测程序是否正常，或者说能够有效确定出待测程序包含的各项功能是否正常，从而保证了待测程序的正常使用。

在一种具体实施方式中，本申请实施例提供的一种测试方法的流程图可以如图3所示，具体可以包括：

S201：获取待测数据；待测数据为用于调用桩代码的参数数据，桩代码为对待测程序中的数据输出代码接口打桩得到的。

S202：抽取待测数据中包含的数据要素作为待测数据要素。

S203：确定与待测数据要素对应的预期数据要素，验证待测数据要素与预期数据要素是否一致，得到对应的验证结果，并基于验证结果确定待测程序是否正常。

需要说明的是，本实施例中对待测数据要素的具体验证过程可以是将待测数据要素与对应的预期数据要素进行比对，进而将待测数据要素与预期数据要素是否一致的结果作为对应的验证结果，具体来说，可以是待测数据要素与预期数据要素一致，则得到的验证结果为验证通过，待测数据要素与预期数据要素不一致，则得到的验证结果为验证未通过。其中，预期数据要素可以为期望待测数据要素成为的数据信息，因此通过将预期数据要素与待测数据要素进行比对，即可获知待测数据要素是否为需要其成为的数据信息，进而有效确定出待测数据要素是否正常，另外这种验证方式操作简单，便于实现。

另外，上述情况为直接对待测数据要素进行验证的情况，而对于需要将待测数据要素进行计算后再对计算得到的值进行验证以间接对待测数据要素进行验证的情况，则需要将待测数据要素进行计后得到值与对应的预期数据要素(或者说预期值)进行比对，进而将比对得到的两者是否一致的结果作为验证结果，如上述例子中待测程序为支付系统，利用费率变量rate及支付额变量amount计算得到预计扣费金额后，则可以将预计扣费金额与历史扣费金额或者设定值进行比对，从而得出验证结果。

S204：如果确定待测程序正常，则判断当前待测程序是否满足预设的要素更新条件。

如果确定待测程序异常，则无需执行步骤S205。

S205：如果当前待测程序满足要素更新条件，则利用待测数据要素替换预期数据要素，以对预期数据要素进行更新。

如果当前待测程序不满足要素更新条件，则无需执行利用待测数据要素替换预期数据要素的步骤。

如果待测程序正常，则可以通过判断当前的待测程序是否满足预设的要素更新条件，确定是否利用待测数据要素对预期数据要素进行更新。具体来说，要素更新条件可以根据实际需要预先设定，如要素更新条件可以为在确定出预期数据要素之后待测程序是否发生变化(也即待测程序是否被修改)，如果待测程序未发生变化，则说明预期数据要素仍然有效，如果待测程序发生了变化，则为了保证用于实现验证的预期数据要素的有效性，则需要利用最新的标准数据要素、即待测数据要素替换预期数据要素作为新的预期数据要素；又如要素更新条件可以为待测程序对应的预期数据要素的确定时刻至当前时刻间的时间间隔，是否达到预先根据实际需要设定的要素更新时间间隔，如果是，则说明需要利用最新的标准数据要素、即待测数据要素替换预期数据要素作为新的预期数据要素。从而利用待测数据要素实现预期数据要素的替换，保证了用于实现验证的数据要素能够为最新的符合需求的数据要素，进而保证了验证有效性。

另外需要说明的是，本实施例还可以包括：

通过预设要素输入接口，接收外界输入的数据要素；

利用外界输入的数据要素替换预期数据要素，以对预期数据要素进行更新。

除了基于待测数据要素对预期数据要素进行更新，本实施例中还可以基于外界输入的数据要素对预期数据要素进行更新。具体来说，测试平台可以为外界提供预设要素输入接口，从而在测试人员需要对预期数据要素进行更新时，将数据要素通过预设要素输入接口输入至测试平台，测试平台在接收到外界输入的数据要素后，利用外界输入的数据要素替换预期数据要素，以实现预期数据要素的更新。由于对于待测程序的修改通常是由测试人员实现的，因此测试人员在实现对待测程序的修改后可能能够直接获知预期数据要素应发生何种改变，因此测试人员基于此对预期数据要素进行更新，能够保证预期数据要素的有效性。另外，对于测试平台中维护的预期数据要素，测试人员可以在每次确定出待测程序异常后和/或每次修改待测程序后和/或每经过根据实际需要设定的时间段后，检测预期数据要素是否需要发生改变，并在预期数据要素需要发生改变时实现对预期数据要素的更新，从而保证了预期数据要素的有效性，也就保证了基于预期数据要素实现的验证的有效性。

在另一种具体实施方式中，本申请实施例提供的一种测试方法的流程图可以如图4所示，具体可以包括：

S301：获取待测数据；待测数据为用于调用桩代码的参数数据，桩代码为对待测程序中的数据输出代码接口打桩得到的。

S302：抽取待测数据中包含的数据要素作为待测数据要素。

S303：调取预先存储的多个验证规则。

S304：从多个验证规则中识别出与待测程序对应的一个验证规则，并将该验证规则作为预设的验证规则。

S304：基于预设的验证规则对待测数据要素进行验证，得到对应的验证结果，并基于验证结果确定待测程序是否正常。

对于不同的待测程序，可能具有不同的验证规则；其中，验证规则的不同可以包括对待测数据要素进行验证的方法不同(如将待测数据要素与预期数据要素进行比对、将待测数据要素计算后与预期数据要素进行比对等)、预期数据要素的不同，等；因此，为了实现测试平台多不同待测程序的通用性，本实施例中在测试平台中维护有多个验证规则，从而在需要对待测数据要素进行验证前，首先由预先存储的多个验证规则中确定出与需要测试的待测程序对应的一个验证规则，进而基于该验证规则实现待测数据要素的验证。另外，验证规则可以采用json等文件格式定义或sql存储过程定义或直接python代码写作等，在此不做具体限定。

在又一种具体实施方式中，本申请实施例提供的一种测试方法的流程图可以如图5所示，具体可以包括：

S401：如果验证结果为待测数据要素验证未通过，则直接确定待测程序存在异常，执行步骤S406。

S402：如果验证结果为待测数据要素验证通过，则监测是否获取到外界输入的人工验证请求。

测试人员如果需要对待测数据要素进行人工验证，则可以向测试平台输入人工验证请求；对应的，如果验证结果表示待测数据要素验证通过，则可以监测是否接收到外界输入的人工验证请求，如果接收到外界输入的人工验证请求，则可以将人工验证请求对应人工验证作为对待测数据要素的第二重验证，从而通过双重验证进一步增加了测试有效性；如果没有接收到外界输入的人工验证请求，则可以直接确定待测程序正常。

需要说明的是，步骤S401至步骤S405为步骤基于验证结果确定待测程序是否正常的具体实现过程。而在另一种可能的情况中，基于验证结果确定待测程序是否正常的过程也可以包括：如果验证结果为待测数据要素验证通过，则确定待测程序正常，如果验证结果为待测数据要素验证未通过，则确定待测程序存在异常。至于确定出验证结果为待测数据要素通过后是否需要执行监测是否获取到外界输入的人工验证请求的步骤，则可以基于待测程序的安全性要求进行预先设定，即如果待测程序的安全性要求较高，则需要在确定出验证结果为待测数据要素通过后执行监测是否获取到外界输入的人工验证请求的步骤，否则则在确定出验证结果为待测数据要素通过后无需执行监测是否获取到外界输入的人工验证请求的步骤。

另外，在又一种可能的情况中，在对待测数据要素进行验证之前可以先监测是否获取到外界输入的人工验证请求，如果获取到外界输入的人工验证请求，则按照步骤S403至步骤S405的过程实现对待测数据要素的验证，如果未获取到外界输入的人工验证请求，则执行基于预设的验证规则对待测数据要素进行验证的步骤，从而增强了验证灵活性。

S403：如果监测到人工验证请求，则将待测数据要素输出至预设的人机交互界面。

如果监测到人工验证请求，则说明测试人员请求对待测数据要素进行人工验证，因此将待测数据要素输出至预先设定的人机交互界面；测试人工可以通过人机交互界面获取到待测数据要素，对待测数据要素进行验证，然后在人工交互界面上将表示验证所得结果的人工验证信息输入至测试平台。通过人机交互界面的设置方便了测试人员实现与测试平台的交互。

S404：通过人机交互界面，获取与人机交互界面上的待测数据要素对应的人工验证信息。

S405：如果人工验证通过，则确定待测程序正常，确定此次测试完成；如果人工验证未通过，则确定待测程序存在异常，执行步骤S406。

如果人工验证信息表示人工验证通过，则说明待测程序通过了基于匹配规则的自动验证和人工验证两重验证，此时确定待测程序正常；否则，则说明待测程序存在由匹配规则的自动验证无法检测出的异常，也即待测程序存在异常。从而通过双重验证的方式增加了验证有效性，实现了对待测程序的全面检测。

S406：确定最后一次确定出待测程序正常的时刻为第一时刻，确定最后一次获取待测数据的时刻为第二时刻，识别待测程序在第一时刻至第二时刻之间的变更内容，利用变更内容对待测程序中的异常部分进行定位。

本实施例中，对待测程序的测试可以是每经过根据实际需要设定的预设时间间隔则进行一次的，也即每经过预设时间间隔则获取待测数据，并执行后续步骤；也可以是在需要时(比如每次对待测程序进行修改后或者每根据实际需要设定的预设次对待测程序进行修改后)通过向测试平台输入对待测程序进行测试的指令，进而在该指令的触发下进行对待测程序的测试的；还可以根据实际需要进行其他设定。总之，对待测程序的测试通常是存在多次的，因此在确定出待测程序异常后，可以识别最后一次确定出待测程序正常至当前时刻待测程序发生的改变，也即变更内容；那么这些变更内容则为导致待测程序存在异常的部分，因此可以由这些变更内容中确定待测程序中的异常部分(存在异常的部分)。具体来说，利用变更内容对待测程序中的异常部分进行定位时，由于变更内容中的每部分均可能是异常部分，因此可以是确定变更内容中每个部分均为异常部分；由于改变内容越多越可能出现异常，因此也可以是将变更内容中改变内容较多的几个部分确定为异常部分；当然还可以根据实际需要进行其他设定。

S407：确定出与异常部分对应的检索关键词，利用检索关键词从程序变更日志文件中检索出相应的日志片段，并对日志片段进行输出。

为了方便后期查询，本实施例中在每次对待测程序进行修改后都会将此次修改记录到程序变更日志文件中，而记录的内容可以包括此次修改的开始时刻、结束时刻、修改位置、修改前内容、修改后内容等；对应的，在定位到异常部分后，可以确定出与异常部分对应的检索关键词，本实施例中检索关键词可以包括异常部分的修改的开始时刻、结束时刻、修改位置、修改后内容等，由此，基于检索关键词在程序变更日志文件中进行检索即可得到异常部分对应的日志片段。将日志片段输出可以是基于上述实施例中所说的人机交互界面将日志片段进行输出，也可以将日志片段输出至测试人员制定的智能终端中，以便于测试人员可以随时随地获取到该日志片段，从而使得测试人员可以通过对日志片段进行分析，确定出导致待测程序存在异常的修改，进而实现对应的修复等操作。

另外，在确定出待测程序存在异常之后，还可以按照预先设定的告警规则发出告警，以通知测试人员待测程序存在异常这一信息，方便其进行对应的检查、确认及修复等操作。其中，告警规则可以根据实际需要进行设定，可以包括发出告警的方式及发出告警的次数等，具体来说，按照告警规则发出告警可以是每经过根据实际需要设置的一定时间则将告警信息(告警信息可以包括待测程序的程序名称、待测数据、待测数据要素及预期数据要素等)发送至测试人员对应的智能终端，直至接收到智能终端返回的确认接收的信息或者直至发送告警信息的次数达到根据实际需要设置的次数阈值为止；也可以是发出待测程序存在异常的次数(可以根据实际需要设置)的提示音或者亮光等；当然还可以根据实际需要进行设定。

为了便于理解，请参考图6，结合本方案的一种应用场景进行介绍，下面以待测程序和测试平台，且待测程序为支付系统、支付系统仅具有支付功能对应数据输出代码接口作为应用场景说明对待测程序进行测试的过程。

待测程序对用于实现支付功能的数据输出代码接口打桩，得到桩代码；在实现支付功能的业务调用桩代码时截取用于调用桩代码的参数数据为待测数据，将待测数据存储至内存中，并利用工具agent将内存中的待测数据传输至测试平台中。

测试平台接收到待测数据后，抽取待测数据中包含的商户号、商户的结算规则、商户的费率、商户的支付额、是否转账或提现的字段作为待测数据要素以变量的形式保存，利用商户的费率变量和商户的支付额变量计算得到对应的预计扣费金额，进而将保存的商户号、商户的结算规则、预计扣费金额及是否转账或提现的变量分别与预期的对应的信息进行比对，如果比对结果为一致，则监测是否接收到外界输入的人工验证请求，如果接收到外界输入的人工验证请求，则将保存的作为待测数据要素的各变量输出至人机交互界面，并基于人机交互界面获取人工验证信息，基于人工验证信息确定待测程序是否正常，如果没有接收到外界输入的人工验证请求，则直接确定待测程序正常；如果比对结果为不一致，则直接确定待测程序异常。并且，在确定出待测程序异常后，发出对应的告警以将该情况告知给测试人员。

需要指出的是，如果待测程序存在异常，则会导致无法成功调用数据输出代码接口以实现对应的功能，如通过调用数据输出代码接口实现DB访问时，可能导致写入DB的数据或更新字段不正确或者该更新的字段没有更新等。可知的是，无论需求如何变化，待测程序出现异常，则肯定是待测程序中存在被忽略的异常修改或影响等，这些非明确的错误容易被忽略，对待测程序造成不良影响。并且，当前大量程序功能越来越大，难以保证每个新需求修改，都能够分析全面对功能的影响。而“海恩法则”表示任何严重事故都是有征兆的，每个事故征兆背后，还有300次左右的事故苗头，以及上千个事故隐患，要消除一次严重事故，就必须敏锐而及时地发现这些事故征兆和隐患并果断采取措施加以控制或消除。因此，本申请通过上述测试方法，确定待测程序是否存在异常，也即实现待测程序隐蔽缺陷的自动提前发现或异常告警等，以使得测试人员能够具有针对性的进行对应分析，也即通过这种方式全面的分析对待测程序的修改对待测程序的功能实现的影响，从而为待测程序建立了测试及安全防护网，减少非预知风险，降低bug上线影响，为待测程序为金融系统或支付系统等降低资金风险。

请参阅图7，其示出了本申请实施例提供的又一种测试方法的流程图，具体可以包括：

S501：对待测程序中的数据输出代码接口打桩，得到对应的桩代码。

需要说明的是，本申请实施例提供的一种测试方法的执行主语可以为对应的测试装置，而该测试装置可以设置于待测程序中，因此本申请实施例提供的一种测试方法的执行主语可以为待测程序，或者说该测试方法对应于待测程序侧；以下以执行主语为待测程序进行说明。在得到桩代码后，可以将桩代码作为lib编译进待测程序，以便实现对桩代码的调用。

S502：获取用于调用桩代码的参数数据，并将参数数据作为待测数据。

在获取到用于调用桩代码的参数数据后，可以将参数数据存储到内存中，进而通过数据传输工具(如工具agent等)将参数数据传输给测试平台，以便测试平台对待测数据进行测试。

S503：将待测数据传输至测试平台，以便测试平台基于待测数据实现对待测程序的测试。

本申请公开的技术方案中，并不是直接获取调用数据输出代码接口的参数数据，而是先对待测程序中的数据输出代码接口打桩，进而获取调用打桩得到的桩代码的参数数据作为待测数据，从而通过打桩的方式得到能够代替数据输出代码接口被调用的桩代码，进而获取到调用桩代码所用的参数数据，避免了在测试过程中对数据输出代码接口的损坏等不良影响，使得在正常实现对待测程序的测试的同时保护了待测程序包含的数据输出代码接口。

在一种可能的情况中，对待测程序中的数据输出代码接口打桩之前，还可以包括：

确定待测程序中包含的全部数据输出代码接口为候选代码接口；

确定能够供待测程序中每个业务调用的候选代码接口为需要进行打桩的数据输出代码接口。

需要说明的是，本申请中可以将待测程序包含的全部数据输出代码接口均作为需要进行打桩的数据输出代码接口；但是在实际应用中，待测程序中的数据输出代码接口中可能存在需要随着待测程序中的业务进行改动的部分，而这部分由于改动较频繁，对应的预期数据要素也会变化频繁，因此对其进行验证并不实际，还可能由于没有及时变更数据要素导致测试结果错误等情况；因此本实施例中仅对不随业务改动的部分、即每个业务均需调用的数据输出代码接口作为需要进行打桩的数据输出代码接口，这部分数据输出代码接口可以称为数据输出公共代码接口(例如用于实现RPC调用、DB访问等的数据输出代码接口)，从而有效实现对应的验证。

另外，本实施例中采取的候选代码接口也可以为较少随业务改动的数据输出代码接口(如公共lib等)，而判断候选代码接口是否随业务改动较少可以确定一段时间内候选代码接口随业务改动的次数，进而确定该次数小于根据实际需要设定的一定值的候选代码接口为需要进行打桩的数据输出代码接口，从而将较多的数据输出代码接口纳入测试范围内，以提高测试全面性。

本申请实施例还提供了一种测试装置，如图8所示，可以包括：

数据获取模块111，用于：获取待测数据；待测数据为用于调用桩代码的参数数据，桩代码为对待测程序中的数据输出代码接口打桩得到的；

要素抽取模块112，用于：抽取待测数据中包含的数据要素作为待测数据要素；

要素验证模块113，用于：基于预设的验证规则对待测数据要素进行验证，得到对应的验证结果，并基于验证结果确定待测程序是否正常。

在一种可能实现方式中，要素验证模块可以包括：

第一要素验证单元，用于：确定与待测数据要素对应的预期数据要素；验证待测数据要素与预期数据要素是否一致。

在一种可能实现方式中，测试装置还可以包括：

第一要素更新模块，用于：基于验证结果确定待测程序是否正常之后，如果确定待测程序正常，则判断当前待测程序是否满足预设的要素更新条件；如果当前待测程序满足要素更新条件，则利用待测数据要素替换预期数据要素，以对预期数据要素进行更新。

在一种可能实现方式中，测试装置还可以包括：

第二要素更新模块，用于：通过预设要素输入接口，接收外界输入的数据要素；利用外界输入的数据要素替换预期数据要素，以对预期数据要素进行更新。

在一种可能实现方式中，测试装置还可以包括：

规则确定模块，用于：基于预设的验证规则对待测数据要素进行验证之前，调取预先存储的多个验证规则；从多个验证规则中识别出与待测程序对应的一个验证规则，并将该验证规则作为预设的验证规则。

在一种可能实现方式中，要素验证模块可以包括：

第二要素验证单元，用于：如果验证结果为待测数据要素验证未通过，则直接确定待测程序存在异常；如果验证结果为待测数据要素验证通过，则监测是否获取到外界输入的人工验证请求；如果监测到人工验证请求，则将待测数据要素输出至预设的人机交互界面；通过人机交互界面，获取与人机交互界面上的待测数据要素对应的人工验证信息；如果人工验证通过，则确定待测程序正常，如果人工验证未通过，则确定待测程序存在异常。

在一种可能实现方式中，数据获取模块可以包括：

数据获取单元，用于：每经过预设时间间隔则获取待测数据；

测试装置还可以包括：

异常定位模块，用于：确定待测程序存在异常之后，确定最后一次确定出待测程序正常的时刻为第一时刻；确定最后一次获取待测数据的时刻为第二时刻；识别待测程序在第一时刻至第二时刻之间的变更内容；利用变更内容对待测程序中的异常部分进行定位。

在一种可能实现方式中，测试装置还可以包括：

日志输出模块，用于：利用变更内容对待测程序中的异常部分进行定位之后，确定出与异常部分对应的检索关键词；利用检索关键词从程序变更日志文件中检索出相应的日志片段，并对日志片段进行输出。

本申请实施例还提供了另一种测试装置，如图9所示，可以包括：

接口打桩模块211，用于：对待测程序中的数据输出代码接口打桩，得到对应的桩代码；

数据获取模块212，用于：获取用于调用桩代码的参数数据，并将参数数据作为待测数据；

数据传输模块213，用于：将待测数据传输至测试平台，以便测试平台基于待测数据实现对待测程序的测试。

在一种可能实现方式中，还可以包括：

接口确定模块，用于：对待测程序中的数据输出代码接口打桩之前，确定待测程序中包含的全部数据输出代码接口为候选代码接口；确定能够供待测程序中每个业务调用的候选代码接口为需要进行打桩的数据输出代码接口。

进一步的，本申请实施例还提供了一种测试设备，该测试设备可以是如图10所示的终端20，图10是根据一示例性实施例示出的测试设备结构图，图中的内容不能被认为是对本申请的使用范围的任何限制。

图10为本申请实施例提供的一种终端的结构示意图，该终端20具体可以包括但不限于智能手机、平板电脑、笔记本电脑或台式电脑等。

通常，本实施例中的终端20包括有：处理器21和存储器22。

其中，处理器21可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器21可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器21还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器22可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器22还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器22至少用于存储以下计算机程序221，其中，该计算机程序被处理器21执行时，能够实现前述任一实施例公开的由待测程序执行的测试方法中的相关步骤，或能够实现前述任一实施例公开的由测试平台执行的测试方法中的相关步骤。另外，存储器22所存储的资源还可以包括操作系统222和数据223等，存储方式可以是短暂存储或者永久存储。其中，操作系统222可以包括Windows、Unix、Linux等。数据223可以包括但不限于测试指令数据、用户身份数据等。

在一些实施例中，终端20还可包括有显示屏23、输入输出接口24、通信接口25、传感器22、电源27以及通信总线28。

本领域技术人员可以理解，图10中示出的结构并不构成对终端20的限定，可以包括比图示更多或更少的组件。

进一步的，本申请实施例还公开了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时，实现前述任一实施例公开的由测试平台执行的测试方法的步骤，或实现前述任一实施例公开的由待测程序执行的测试监管方法步骤。

需要指出的是，上述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

以上对本申请所提供的一种测试方法、装置、设备及计算机可读存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。

Claims (12)

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

获取待测数据；所述待测数据为用于调用桩代码的参数数据，所述桩代码为对待测程序中的数据输出代码接口打桩得到的；

抽取所述待测数据中包含的数据要素作为待测数据要素；

基于预设的验证规则对所述待测数据要素进行验证，得到对应的验证结果，并基于所述验证结果确定所述待测程序是否正常；

所述基于所述验证结果确定所述待测程序是否正常，包括：

如果所述验证结果为所述待测数据要素验证未通过，则直接确定所述待测程序存在异常；

如果所述验证结果为所述待测数据要素验证通过，则监测是否获取到外界输入的人工验证请求；

如果监测到所述人工验证请求，则将所述待测数据要素输出至预设的人机交互界面；

通过所述人机交互界面，获取与所述人机交互界面上的所述待测数据要素对应的人工验证信息；

如果人工验证通过，则确定所述待测程序正常，如果人工验证未通过，则确定所述待测程序存在异常。

2.根据权利要求1所述的方法，其特征在于，所述基于预设的验证规则对所述待测数据要素进行验证，包括：

确定与所述待测数据要素对应的预期数据要素；

验证所述待测数据要素与所述预期数据要素是否一致。

3.根据权利要求2所述的方法，其特征在于，所述基于所述验证结果确定所述待测程序是否正常之后，还包括：

如果确定所述待测程序正常，则判断当前所述待测程序是否满足预设的要素更新条件；

如果当前所述待测程序满足所述要素更新条件，则利用所述待测数据要素替换所述预期数据要素，以对所述预期数据要素进行更新。

4.根据权利要求2所述的方法，其特征在于，还包括：

通过预设要素输入接口，接收外界输入的数据要素；

利用所述外界输入的数据要素替换所述预期数据要素，以对所述预期数据要素进行更新。

5.根据权利要求1所述的方法，其特征在于，所述基于预设的验证规则对所述待测数据要素进行验证之前，还包括：

调取预先存储的多个验证规则；

从所述多个验证规则中识别出与所述待测程序对应的一个验证规则，并将该验证规则作为预设的验证规则。

6.根据权利要求1所述的方法，其特征在于，所述获取待测数据，包括：

每经过预设时间间隔则获取所述待测数据；

所述确定所述待测程序存在异常之后，还包括：

确定最后一次确定出所述待测程序正常的时刻为第一时刻；

确定最后一次获取所述待测数据的时刻为第二时刻；

识别所述待测程序在所述第一时刻至所述第二时刻之间的变更内容；

利用所述变更内容对所述待测程序中的异常部分进行定位。

7.根据权利要求6所述的方法，其特征在于，所述利用所述变更内容对所述待测程序中的异常部分进行定位之后，还包括：

确定出与所述异常部分对应的检索关键词；

利用所述检索关键词从程序变更日志文件中检索出相应的日志片段，并对所述日志片段进行输出。

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

对待测程序中的数据输出代码接口打桩，得到对应的桩代码；

获取用于调用所述桩代码的参数数据，并将所述参数数据作为待测数据；

将所述待测数据传输至测试平台，以便所述测试平台基于所述待测数据实现对所述待测程序的测试；

所述对待测程序中的数据输出代码接口打桩之前，还包括：

确定所述待测程序中包含的全部数据输出代码接口为候选代码接口；

确定能够供所述待测程序中每个业务调用的所述候选代码接口为需要进行打桩的数据输出代码接口。

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

数据获取模块，用于：获取待测数据；所述待测数据为用于调用桩代码的参数数据，所述桩代码为对待测程序中的数据输出代码接口打桩得到的；

要素抽取模块，用于：抽取所述待测数据中包含的数据要素作为待测数据要素；

要素验证模块，用于：基于预设的验证规则对所述待测数据要素进行验证，得到对应的验证结果，并基于所述验证结果确定所述待测程序是否正常；

所述要素验证模块包括：

第二要素验证单元，用于：如果所述验证结果为所述待测数据要素验证未通过，则直接确定所述待测程序存在异常；如果所述验证结果为所述待测数据要素验证通过，则监测是否获取到外界输入的人工验证请求；如果监测到所述人工验证请求，则将所述待测数据要素输出至预设的人机交互界面；通过所述人机交互界面，获取与所述人机交互界面上的所述待测数据要素对应的人工验证信息；如果人工验证通过，则确定所述待测程序正常，如果人工验证未通过，则确定所述待测程序存在异常。

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

接口打桩模块，用于：对待测程序中的数据输出代码接口打桩，得到对应的桩代码；

数据获取模块，用于：获取用于调用所述桩代码的参数数据，并将所述参数数据作为待测数据；

数据传输模块，用于：将所述待测数据传输至测试平台，以便所述测试平台基于所述待测数据实现对所述待测程序的测试；

所述装置还包括：

接口确定模块，用于：所述对待测程序中的数据输出代码接口打桩之前，确定所述待测程序中包含的全部数据输出代码接口为候选代码接口；确定能够供所述待测程序中每个业务调用的所述候选代码接口为需要进行打桩的数据输出代码接口。

11.一种测试设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至8任一项所述测试方法的步骤。

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

Images