测试系统、方法、设备及可读存储介质与流程

本发明实施例涉及系统测试领域，尤其涉及一种测试系统、方法、设备及可读存储介质。

背景技术：

在线旅行社与合作供应商进行双方系统对接，以接口实时交互的形式进行门票售卖各环节的运作，其中涉及的环节包括产品上单、用户下单与支付、订单退款、订单使用核销等流程在对接前需要进行自动化测试，以检测各种功能对接是否运行正常。其中，自动化测试是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。

现有技术中，在测试双方系统对接是否成功时，几乎不关心对接双方的接口特性(系统特性)与供应商不同产品特性(业务特性)，而只是用通用的一套或者一个测试用例进行通用测试。测试的预期为用例走通，则认为对接无异常。

然而，现有技术中所有产品都是使用一套固定的流程测试，而有些产品的特性测试不到或者测试结果判定有误。如果测试时没有针对性的生成用例，则测试结果往往不是测不全就是测不准。

技术实现要素：

本发明提供一种测试系统，以解决在先技术中在线旅行社与合作供应商进行双方系统对接中测试时测试结果测不全或者测不准的问题。

根据本发明的第一方面，提供了一种测试系统，所述系统包括：

接口特征接收模块，用于接收商家发送的业务对象接口特征；

业务对象特征接收模块，用于接收商家发送的业务对象特征；

测试用例生成模块，用于根据所述业务对象接口特征和所述业务对象特征，生成多个业务对象测试用例；

测试模块，用于使用多个所述业务对象测试用例执行遍历测试，得到实际测试结果。

根据本发明的第二方面，提供了一种测试方法，所述方法包括：

接收商家发送的业务对象接口特征请求；

接收商家发送的业务对象特征；

根据所述业务对象接口特征和所述业务对象特征，生成多个业务对象测试用例；

使用多个所述业务对象测试用例执行遍历测试，得到实际测试结果。

根据本发明的第三方面，提供了一种设备，包括：

处理器、存储器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如前述的测试系统。

根据本发明的第四方面，提供了一种可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够实现前述的测试系统。

本发明实施例提供的一种测试方法、系统、设备及可读存储介质，接收商家发送的业务对象接口特征；接收商家发送的业务对象特征；根据所述业务对象接口特征和所述业务对象特征，生成多个业务对象测试用例；使用多个所述业务对象测试用例执行遍历测试，得到实际测试结果。本发明的实施例解决了现有技术中所有产品都用一套固定的流程测试，生成用例没有针对性，测试结果测不全或者测不准的问题，实现了以具有针对性的测试用例进行测试，得到准确而不冗余的测试结果的有益效果。

附图说明

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

图1是本发明实施例提供的一种测试方法的步骤流程图；

图1a是本发明实施例提供的测试流程示意图；

图2是本发明实施例提供的一种测试方法的步骤流程图；

图2a是本发明实施例提供的遍历测试时序图示意图；

图2b是本发明实施例提供的测试用例特性选择示意图；

图2c是本发明实施例提供的测试用例模板列表示意图；

图2d是本发明实施例提供的遍历测试前端界面示意图；

图3是本发明实施例提供的一种测试系统的结构图；

图4是本发明实施例提供的一种测试系统的结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

参照图1，其示出了一种测试方法的步骤流程图，其具体步骤如下：

步骤101，接收商家发送的业务对象接口特征；

本发明实施例中，如图1a所示，ota(线上旅行社)与合作供应商进行双方系统对接，以接口实时交互的形式进行门票售卖各环节的运作。涉及的环节包括产品上单、用户下单与支付、订单退款、订单使用核销等。

可以理解地，在双方系统对接之前，要进行各种功能的对接测试，并且通常使用自动化测试，以减少人工成本，和提高执行效率。

其中，自动化测试一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。

所以，在进行测试之前，针对商家产品的需求，接收商家发送的接口特征，即接口配置请求。

其中，接口配置请求包括商家通过前端页面填写信息告诉线上旅行社想对接ota的哪些接口，同时告知接口地址，方便接口请求处理。

步骤102，接收商家发送的业务对象特征；

本发明实施例中，如图1a所示，为了更好的对接测试，还需要商家提供需要上线产品的特性，以便与ota对接测试时做出针对性处理。

其中，商家通过ota提供的产品配置提交页面，提交自己所含有的产品特性对应的特征请求，即业务对象特征，ota接收到该特征后，后续可根据该特征作出针对性处理。

步骤103，根据所述业务对象接口特征和所述业务对象特征，生成多个业务对象测试用例；

具体地，ota根据自助测试系统将接收到的接口配置请求和业务对象特征，按照自助测试系统订立的规则生成测试用例。

其中，如图1a所示，直连自助测试系统后台根据商家告知的接口特性和产品特性，可以得需要测试的场景有哪些，按照订立规则生成测试用例，测试用例包括测试的顺序、测试的内容、结果的判定等内容。

步骤104，使用多个所述业务对象测试用例执行遍历测试，得到实际测试结果。

具体地，如图1a所示，根据自动生成的测试用例程序按照规定顺序自动执行测试，对于每一个测试用例，可根据已有信息自动构建请求体或返回体。

可以理解地，在进行自动化测试之前，首先商家要通过ba认证，其中，ba认证是httpbasicauth的简称，是通过http头部加密的方式，使得验证双方都通过密码验证后，才可以进行自动化测试步骤。商家在进行测试之前首先会得到验证密码，以获得测试权限，即可通过ba认证。

综上所述，本发明实施例提供的一种测试方法，接收商家发送的业务对象接口特征；接收商家发送的业务对象特征；根据所述业务对象接口特征和所述业务对象特征，生成多个业务对象测试用例；使用多个所述业务对象测试用例执行遍历测试，得到实际测试结果。解决了现有技术中所有产品都用一套固定的流程测试，导致没有针对性的生成用例，测试结果测不全或者测不准的问题。实现了以具有针对性的测试用例进行测试，得到准确而不冗余的测试结果的有益效果。

实施例二

参照图2，其示出了一种测试方法的步骤流程图，其具体步骤如下：

步骤201，接收商家发送的业务对象接口特征；

此步骤与步骤101相同，在此不再详述。

步骤202，接收商家发送的业务对象特征。

此步骤与步骤102相同，在此不再详述。

步骤203，根据所述业务对象接口特征和所述业务对象特征，生成多个业务对象测试用例；

此步骤与步骤103相同，在此不再详述。

步骤204，接收商家发送的添加或删除所述业务对象接口特征，并更新所述业务对象接口特征。

本发明实施例中，在生成业务对象测试用例以后，商家还可能会对产品功能进行删除或者添加，所以对应的可能会对调用的接口进行修改。

其中，当在已生成业务对象测试用例后，自助测试系统接收到商家对接口配置的删除或者添加操作，则在自助测试系统中更新对应的接口配置。

具体地，商家选择测试接口和地址，在服务商路由open-tech中保存对应数据。若已生成测试用例后接口被更新，则用例也被更新，例如商家更新接口后添加了退款接口，那么测试用例中添加退款对应的测试用例，反之亦然。其中，open-tech是服务商路由项目，专门提供供应商、技术商及对应接口的基础数据。

步骤205，接收商家发送的更改所述业务对象特征的请求，并更新所述业务对象特征。

同样地，在生成业务对象测试用例以后，商家还可能会对产品功能进行删除或者添加，所以对应的可能会对产品性能进行修改。

其中，当在已生成业务对象测试用例后，自助测试系统接收到商家对产品性能的删除或者添加操作，则在自助测试系统中更新对应的业务对象特征。

具体地，商家新建测试产品类型，在自测seine中保存对应数据。若修改产品类型或删除测试产品，会更新测试用例，例如删除产品a，a对应的测试用例全部被删除。其中，seine是旅游门票直连自测系统，提供商家测试的沙箱环境。

步骤206，根据所述更新的业务对象接口特征，或所述更新的业务对象特征，更新各所述业务对象测试用例。

具体地，当在已生成业务对象测试用例后，接收到商家对业务对象接口特征，或者业务对象特征的更新操作，那么对应更新业务对象测试用例。

其中，自测平台生成测试用例的目标在于全面测试商家的各个接口配置api，根据门票业务的实际特性(核销不得在支付之前)以及不重复测试的需要，将所有可能的测试案例设置为模板并存储在测试用例模板表case_model中，如图2c所示；商家测试时根据录制产品在模板表中查找合适的测试用例进行测试。

具体地，当前每个测试用例代表一种生命周期，表现为一个订单从创建走向终态，比如测试用例“创建订单->同步支付->同步退款”，穷举接口特性如下：创建订单-订单关闭-同步支付-异步支付-同步退款-异步退款-部分退款-已退款消息-核销通知-查询核销。

其中，针对每一种特性，用0表示用例不使用这种特性，1表示使用这种特性，则用例模板，如图2b所示，“创建订单->同步支付->同步退款”可以表示为1010100000。

其中，假设商家a有订单关闭接口，产品配置如下图所示，则其特性可表示为1110100001，那么对于对应特性与其相同或不使用(0)的用例模板都可匹配，用例模板，如图2c所示，“创建订单->订单关闭”1100000000和“创建订单->同步支付->查询核销”1010000001都与产品匹配。

可以理解地，测试用例的更新过程与测试用例的生成过程一样，都是通过现有的接口配置请求和业务对象特征中的各个环节，和执行步骤，生成对应的测试用例。

步骤207，使用多个所述业务对象测试用例执行遍历测试，得到实际测试结果。

本发明实施例中，如图2a所示，根据自动生成的测试用例，如1010000001按照规定顺序自动执行测试，对于每一个用例，可根据已有信息自动构建请求体或返回体。

具体地，如图2c所示的测试用例模板，遍历测试过程描述如下：

a.进入遍历测试页面，前端查询该供应商当前所有测试用例，包含测试环节、操作类型、状态、结果、详情查看。

b.执行遍历测试，同步返回给前端执行中；并调用预订中心向商家发起请求，请求通过dispatch发送至预计中心，请求和响应经由网关open-gateway存储在自测seine的表中，响应结果经由mock异步回调给自测seine，根据测试用例类型进行下一步操作或完结。其中，dispatch是将当前请求转发到其它服务的路径，mock是指测试一个对象a时，构造的虚拟对象来模拟与a之间的交互，而mock对象的行为是由相关技术人员预先设定。

c.在遍历测试后，前端定时查询后端测试情况，只有商家每个用例都进入成功/失败/待手动处理的状态才会返回给前端具体结果，其它返回执行中；超时后查询用例的请求和响应，如果商家有数据但预订没有返回，则对商家数据做建单的结构校验并返回失败原因。

d.针对单个用例执行重新测试或执行测试，测试用例重新生成订单请求商家直到成功/失败/待手动处理。

步骤208，若所述实际测试结果和预设测试结果一致，则所述业务对象通过测试。

本发明实施例中，根据上述描述，程序会自动比对每个测试用例的预期结果与实际结果，判断该系统商是否通过测试，或者告知哪些环节出了问题，需要处理。

可以理解地，每个测试用例代表一种生命周期，表现为一个订单从创建走向终态，而每个测试用例又包括多个环节，即一个测试用例中的每个环节都走通后，表明该测试用例走通。

所以，在对比测试结果时，是针对每个测试用例的各个环节的测试结果进行对比的，而该测试用例的所有环节的实际测试结果都与预设测试结果一致，则该测试用例走通。

优选地，步骤208，包括：子步骤a1-a2；

子步骤a1，将各所述实际测试结果和预设测试结果进行对比，得到各测试用例的测试对比结果；

具体地，在遍历测试后，前端定时查询后端测试情况，只有商家每个用例都进入成功/失败/待手动处理的状态才会返回给前端具体结果。

其中，测试用例的成功/失败/待手动处理的状态都是测试用例中每个环节的实际测试结果与预设测试结果进行对比，得到的预设状态。

例如，测试用例中，环节一结束后的预设测试结果是b，而实际测试结果也是b，那么环节一顺利结束后，进入环节二。

子步骤a2，若各所述测试对比结果一致，则所述业务对象通过测试。

具体地，当测试用例中的每个环节结束后的实际测试结果都与预设测试结果一致，那么该测试用例测试通过。同样地，如果针对一个业务对象的所有测试用例都通过测试，那么该业务对象通过测试。

可以理解地，一个业务对象是一种类型的产品，该类型产品由于包含多个属性特征，则对应多个生命周期，即对应多个测试用例。

例如，产品类型a：不可退门票，可能的生命周期有：1：创建到取消2：创建到使用等。

产品类型b：可退门票可能的生命周期有：1：创建到取消2：创建到使用3.创建到退款等。

如上所描述的，产品类型的属性决定了测试的生命周期，而每种可能的周期即对应一个测试用例。如产品类型a对应的测试用例即包括创建到取消测试用例，和创建到使用测试用例。

优选地，还包括：

步骤b1，若各所述测试对比结果存在不一致，则在各业务对象测试用例中，提取对应不一致的所述测试对比结果的目标业务对象测试用例；

具体地，如图2d所示的遍历测试前段界面示意图，显示测试用例的执行状态，从中可以看出各测试用例模板的执行状态和执行结果。

本发明实施例中，在遍历测试后，前端定时查询后端测试情况，只有商家每个用例都进入成功/失败/待手动处理的状态才会返回给前端具体结果。

其中，测试用例的成功/失败/待手动处理的状态都是测试用例中每个环节的实际测试结果与预设测试结果进行对比，得到的预设状态。

具体地，当实际测试结果为失败或待手动处理状态，则提取该结果状态对应的测试用例，以及造成失败的具体环节。

步骤b2，重新执行所述目标业务对象测试用例。

具体地，重新执行上述提取的测试用例中的具体环节。

可以理解地，如果该环节在该测试用例中是整体不可分割的一部分，则重新执行该测试用例。

步骤209，接收商家发送的申请上线请求；

本发明实施例中，如图1a所示，测试完成后，程序会自动比对每1个测试用例的预期结果与实际结果，判断该系统商是否通过测试，或者告知哪些环节出了问题，需要处理。包含上述测试对比内容的报告成为测试质量报告。

其中，测试通过的系统商或者供应商，可发送正式上线申请。

步骤210，若所述业务对象通过测试，则根据所述申请上线请求，允许所述业务对象上线运行。

具体地，当ota接收到系统商或者供应商的上线申请后，查看该系统商或者供应商的测试报告，如果测试质量报告中显示该系统商或者供应商通过测试，则审批通过后就可正式上线售卖。

综上所述，本发明实施例提供的一种测试方法，通过接收商家发送的业务对象接口特征；接收商家发送的业务对象特征；根据所述业务对象接口特征和所述业务对象特征，生成多个业务对象测试用例；使用多个所述业务对象测试用例执行遍历测试，得到实际测试结果。本提案通过针对性的生成业务对象的测试用例，实现了覆盖全部不同用户行为的测试场景的目的。若所述实际测试结果和预设测试结果一致，则所述业务对象通过测试。接收商家发送的申请上线请求；若所述业务对象通过测试，则根据所述申请上线请求，允许所述业务对象上线运行。本提案通过针对性的生成业务对象的测试用例，实现了覆盖全部不同用户行为的测试场景的目的。

实施例三

参照图3，其示出了一种测试系统的结构框图，其具体如下：

接口特征接收模块301，用于接收商家发送的业务对象接口特征；

业务对象特征接收模块302，用于接收商家发送的业务对象特征；

测试用例生成模块303，用于根据所述业务对象接口特征和所述业务对象特征，生成多个业务对象测试用例；

测试模块304，用于使用多个所述业务对象测试用例执行遍历测试，得到实际测试结果。

参照图4，其示出了基于图3实施例的另一种测试系统的结构框图，其具体如下：

接口特征接收模块401，用于接收商家发送的业务对象接口特征；

业务对象特征接收模块402，用于接收商家发送的业务对象特征；

测试用例生成模块403，用于根据所述业务对象接口特征和所述业务对象特征，生成多个业务对象测试用例；

接口更新模块404，用于接收商家发送的添加或删除所述业务对象接口特征，并更新所述业务对象接口特征。

特征更新模块405，用于接收商家发送的更改所述业务对象特征的请求，并更新所述业务对象特征。

测试用例更新模块406，用于根据所述更新的业务对象接口特征，或所述更新的业务对象特征，更新各所述业务对象测试用例。

测试模块407，用于使用多个所述业务对象测试用例执行遍历测试，得到实际测试结果。

测试结果判定模块408，用于若所述实际测试结果和预设测试结果一致，则所述业务对象通过测试。

优选地，还包括：

测试用例提取模块，用于若各所述测试对比结果存在不一致，则在各业务对象测试用例中，提取对应不一致的所述测试对比结果的目标业务对象测试用例；

重新测试模块，用于重新执行所述目标业务对象测试用例。

申请上线请求接收模块409，用于接收商家发送的申请上线请求；

业务对象上线模块410，用于若所述业务对象通过测试，则根据所述申请上线请求，允许所述业务对象上线运行。

本发明实施例还提供一种设备，包括：处理器、存储器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如上述的一个或多个所述的测试系统。

本发明实施例还提供一种可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如所述的测试系统。

综上所述，本发明实施例提供的一种测试系统，通过接口特征接收模块，用于接收商家发送的业务对象接口特征；业务对象特征接收模块，用于接收商家发送的业务对象特征；测试用例生成模块，用于根据所述业务对象接口特征和所述业务对象特征，生成多个业务对象测试用例；接口更新模块，用于接收商家发送的添加或删除所述业务对象接口特征，并更新所述业务对象接口特征。特征更新模块，用于接收商家发送的更改所述业务对象特征的请求，并更新所述业务对象特征。测试用例更新模块，用于根据所述更新的业务对象接口特征，或所述更新的业务对象特征，更新各所述业务对象测试用例。测试模块，用于使用多个所述业务对象测试用例执行遍历测试，得到实际测试结果。测试结果判定模块，用于若所述实际测试结果和预设测试结果一致，则所述业务对象通过测试。重新测试模块，用于重新执行所述目标业务对象测试用例。申请上线请求接收模块，用于接收商家发送的申请上线请求；业务对象上线模块，用于若所述业务对象通过测试，则根据所述申请上线请求，允许所述业务对象上线运行。本提案通过针对性的生成业务对象的测试用例，实现了覆盖全部不同用户行为的测试场景的目的。其具有如下优点：

其一：测试用例覆盖所有用户行为及对应行为下可能发生的订单生命周期，更有实际意义，更好理解，也更全面。

其二，根据不同商家的技术特性和业务特性，针对性的启用用例，使得测试更精准。

其三、一定程度上摸清了商家的容错能力，更好的保证了对接质量，提升正式上线后的用户体验、降低了维护成本。

其四、用例模板结构化，通过模板库统一管理。后续如果尤其业务变动增加新功能，新增新的测试场景时，直接录入一条新模板即可，无需改动一条代码。

对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本发明实施例的支付信息处理设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者系统程序(例如，计算机程序和计算机程序商品数据)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干系统的单元权利要求中，这些系统中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、系统和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。