CN115048311A - 测试环境的监测方法、装置、电子设备及可读存储介质 - Google Patents

Abstract

本申请公开了一种测试环境的监测方法、装置、电子设备及可读存储介质，其方法通过组件化软件开发平台实现，包括：识别待测试链路的链路类型；响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本；根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例；在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果。本申请极大程度上节约了线下测试环境维护的人工、时间和经济成本、且准确度高、可靠性强、针对性强、适应场景广泛，显著提高了测试环境的可信任度，为程序开发提供了坚实的基础。

Description

测试环境的监测方法、装置、电子设备及可读存储介质

技术领域

本申请涉及计算机技术领域，具体涉及一种测试环境的监测方法、装置、电子设备及可读存储介质。

背景技术

应用测试的线下环境的高可用性是保障高效研发的基础。

在现有技术中，对于线下环境的测试主要有两种方式，一种方式是采用人工的方式，由人工组建测试用例，并根据线下环境的数据，运行测试用例，在运行测试用例过程中，若发现问题，则上报有关部门或人员。这种采用人工的方式需要大量的人力维护测试用例和脚本，效率低下、易出错，严重影响了线下环境的信任度。另外一种方式是采用自动化流程，现有技术中，自动化测试通常是先构建测试用例，由人工跑完整个测试用例流程，整个测试通过后，上线功能，然后将人工跑完的测试用例编写成自动化测试脚本，这种方法，若功能发生变更，需要重复此操作，因此仍然需要极大的依赖人工介入结果，同样存在效率低下、人工成本高、可靠性低的问题。

发明内容

本申请实施例针对上述情况，提出了一种测试环境的监测方法、装置、电子设备及可读存储介质，该方法复用了组件化软件开发平台中的现有组件，能够显著降低人工成本、且可靠性强。

第一方面，本申请实施例提供了一种测试环境的监测方法，所述方法通过组件化软件开发平台实现，所述方法包括：

识别待测试链路的链路类型；

响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本；

根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例；

在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果。

第二方面，本申请实施例还提供了一种测试环境的监测装置，所述装置应用于组件化软件开发平台实现，所述装置包括：

识别单元，用于识别待测试链路的链路类型；

调用单元，用于响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本；

读取单元，用于根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例；

执行单元，用于在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果。

第三方面，本申请实施例还提供了一种电子设备，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行上述任一的方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行上述任一的方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本申请通过先识别待测试链路的链路类型，并根据组件调用指令，调用多个测试组件，使这些组件以指定形式，形成所述待测试链路的测试用例脚本，然后根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例；最后在目标测试环境执行所述测试用例，从而确定出测试环境的监测结果。本申请通过复用组件化软件开发平台上的现有组件，根据不同的链路类型，生成待测试链路的全链路自动化测试用例，并在测试环境中运行测试用例，以实现对测试环境的监测，本申请极大程度上节约了线下测试环境维护的人工、时间和经济成本、且准确度高、可靠性强、针对性强、适应场景广泛，显著提高了测试环境的可信任度，为程序开发提供了坚实的基础。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出根据本申请的一个实施例的测试环境的监测方法的流程示意图；

图2示出根据本申请的一个实施例的测试环境的监测装置的结构示意图；

图3为本申请实施例中一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

本申请的构思在于，测试环境，也可以称为线下环境，其可用性一直是影响研发体验的很重要的一个环节，尤其使对于肩负核心系统的研发工作的团队来说，更显的尤为重要。现有技术中，对于测试环境的监测普遍存在着人工成本高、效率低下、可靠性不强的缺陷，对此，本申请提供了一种测试环境的监测方法，该方法借助于现有的组件化、自动化软件开发平台，结合应用测试需求，通过复用软件开发平台的已有组件，形成一种操作简单、适用场景广泛、准确度高、成本低廉的测试环境的监测方法。

下面对本申请中可能出现的词汇进行简单解释。

测试环境，也称线下环境：指内部应用测试环境，与生产环境(线上环境)隔离，用于变更代码的集成测试。

应用可用率：线下环境中能完整成功跑通应用的比例，且在本申请中，应用可用性的度量是真实应用，而非单接口调用。

图1示出根据本申请的一个实施例的测试环境的监测方法的流程示意图，所述方法通过组件化软件开发平台实现，从图1中可以看出，本申请至少包括步骤S110～步骤S140：

步骤S110：识别待测试链路的链路类型。

人们生活越来越依赖电子商务，如网上买菜、网上点外卖等，本申请结合不同场景下的应用现状，提炼出多个链路，每个链路对应一个场景，如卡券售卖场景、外卖下单场景等。

在对测试环境进行监测时，首先，识别待测试链路的链路类型，后续根据不同的链路类型读取不同入参(输入参数)进行监测，以下以待测试链路为外卖下单链路为例。

步骤S120：响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本。

在确定以待测试链路的链路类型后，响应于组件调用指令，调用组件化软件开发平台上已有的多个测试组件，使这些测试组件按照指定形式连接在一起，形成待测试链路的测试用例脚本。其中，组件调用指令可以是测试人员根据待测试链路的链路类型确定的。

组件化软件开发平台是供软件开发人员进行开发的组件化、自动化的平台，在该平台中，存储有历史时间内，开发人员编写的各种组件。这些组件不局限于用于测试，如还可以是欲上线的功能或已经上线的功能，这些功能是以组件的形式存储的，各个组件通常是相互独立的。

需要说明的是，每个组件的功能通常是比较单一的，如查询店铺信息组件、aic修改库存组件等，因此，组成一个链路通常需要多个组件。

组件化软件开发平台使方便、快捷地复用之前已建立的功能模块得以实现，通过多个组件之间连接和出入参的传递，很方便的搭建了待测试链路的测试用例脚本。

以待测试链路为外卖下单链路为例，测试用例脚本可以为但不限于依次连接的：查询店铺信息组件、弹内提单页渲染build组件、弹内下单create组件、ALSC通用弹内支付组件、ATC订单查询并校验组件、AFP2履约商户接单组件、外卖中台算价校验组件。

需要说明的是，本申请中组件与组件之间的“连接”不是通常意义上的物理性的连接，可以理解为出入参的传递，即位置在前的组件的出参(输出参数)作为位置灾后的组件的入参，以此实现各组件之间的连接。

步骤S130：根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例。

在形成了测试用例脚本后，读取测试用例脚本的初始输入参数，即可形成待测试链路的测试用例。

读取初始输入参数时，可根据待测试链路的链路类型，对接到相应数据库中，进行检索和读取初始输入参数即可。

在本申请的一些实施例中，线下环境的监测经常会碰到数据失效或者需要重建的不理想情况，对此可以把所有的静态入参都通过第一个组件来输出，后续组件使用的参数，都从上游的组件的输出来关联，这样如果测试数据需要重建，只需要更新第一个组件的配置，其他组件都可以不用修改，同时通过修改参数，可以方便的把测试用例移植到预发环境去执行。也就是说，对于读取初始输入参数的具体形式可以在形成的测试用例脚本的所有组件的之前，前置一个读取组件，以进行初始输入参数的读取。

将读取到的初始输入参数输入到测试用例脚本，即可形成测试脚本。

步骤S140：在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果。

最后，在目标测试环境执行形成的测试用例，得到其的监测结果，在执行测试用例的过程监测结果中，若出现问题，则可显示出具体问题是什么，以便测试人员排除故障。

需要说明的是，出现故障通常是两种原因造成的，一种是真实应用的失败，即链路本身出现问题，由于真实应用的失败造成的监测结果异常主要包括：超时值低问题、依赖系统链接池满问题、依赖系统发布后配置问题导致应用出错、线下数据库连接池满等等，这些问题的解决可以借助人工的方法，如可以生成相应的信息发送至对应的人员，以进行故障排除或者维护，如对于线下数据库连接池满的问题，可以通知DBA(数据库管理员)修改线下数据库连接池配置。

两外一种原因通常是测试用例稳定性造成的失败，这种情况下，需要对测试用例或者待测试链路进行调试或治理，避免因为测试数据或者测试代码的问题造成的用例失败。

若监测结果通过，则说明测试环境没有问题。

由图1所示的方法可以看出，通过先识别待测试链路的链路类型，并根据组件调用指令，调用多个测试组件，使这些组件以指定形式，形成所述待测试链路的测试用例脚本，然后根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例；最后在目标测试环境执行所述测试用例，从而确定出测试环境的监测结果。本申请通过复用组件化软件开发平台上的现有组件，根据不同的链路类型，生成待测试链路的全链路自动化测试用例，并在测试环境中运行测试用例，以实现对测试环境的监测，本申请极大程度上节约了线下测试环境维护的人工、时间和经济成本、且准确度高、可靠性强、针对性强、适应场景广泛，显著提高了测试环境的可信任度，为程序开发提供了坚实的基础。

在本申请的一些实施例中，在上述方法中，在所述响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本的步骤之前，还包括：响应于测试组件添加指令，将与所述测试组件添加指令对应的测试组件，添加到所述组件化软件开发平台的已有组件。

对于一些组件化软件开发平台还不存在的功能，可以自定义的进行添加，具体的，可以将想要的功能开发为代码，然后将这些代码通过测试组件添加指令增加到组件化软件开发平台的已有组件中，方便后续的调用。

在本申请的一些实施例中，在上述方法中，所述响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本，包括：提供配置界面，通过配置界面接收所述组件调用指令，其中所述组件调用指令包括组件添加指令、组件删除指令，以及组件顺序调整指令中的至少一种，并响应于所述组件添加指令、所述组件删除指令，以及所述组件顺序调整指令，对各指令对应的测试组件执行相应的操作；将调用的多个测试组件，按照所述组件调用指令中的指定顺序以串联的形式整合，形成测试用例脚本，其中，各测试组件将前一测试组件的输出参数作为本测试组件的输入参数。

为了方便测试人员的操作，在本申请的一些实施例中，提供了可在终端展示的配置界面，在配置界面中，测试人员可以通过选择、点击等操作对测试组件进行添加、删除和顺序调整等，组件化软件开发平台响应于这些组件调用指令，对各指令对应测试组件执行响应的操作，最后，将调用的多个测试组件，按照所述组件调用指令中的指定顺序以串联的形式整合，形成测试用例脚本，在测试用例脚本中，对于一个测试组件而言，其前一测试组件的出参为该测试组件的入参，而该测试组件的出参作为后一测试组件的入参。通过组件串联，可以方便的任意变更测试逻辑，而不至于大范围修改代码，也不需要代码集成，更方便测试工作。

在本申请的一些实施例中，在上述方法中，所述根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例，包括：根据识别的链路类型，确定测试用例的入参数据源；连接所述入参数据源，并从所述入参数据源获取所述测试用例脚本的初始输入参数；将所述入参数据源输入所述测试用例脚本，形成所述待测试链路的测试用例。

读取初始输入参数时，首先根据识别出的待测试链路的链路类型，确定测试用例的入参数据源，以待测试链路为外卖订单链路为例，其入参数据源可以为前端外卖小程序中客户下单的信息，这种情况下，组件化软件开发平台可连接该前端外卖小程序，然后对客户下单的信息进行读取，作为测试用例脚本的初始输入参数，然后将入参数据源输入所述测试用例脚本，则形成所述待测试链路的测试用例。

在本申请的一些实施例种，在上述方法中，所述在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果，包括：建立测试实验室，所述测试实验室包括目标测试环境以及所述测试用例；在所述测试实验室中，按照第一预设周期，执行所述测试用例；若在某一预设周期，执行所述测试用例连续失败达到指定次数，则确定所述目标测试环境的监测结果为存在故障；根据所述监测结果，生成障碍维护工单，并发送至对应的障碍维护方。

在运行测试用例时，可建立一个测试实验室，在测试实验室中执行该测试用例，具体的，建立的测试实验室仅包含该测试用例，在建立测试实验室时可通过配置测试实验室的各项参数，如任务名、任务描述、任务类型、定时表达式、重复次数、失败反馈、是否开启通知、障碍维护方通讯方式及信息、使用协议、目标测试环境等等。这样测试用例就能够在上述设定的实验环境中进行测试。

在现有技术中，对于一个特定环境中的应用进行自动化测试通常是每天执行一次，这样不能准确、全面的反映一天中环境的变化情况。对此，本申请中可以通过定时表达式来随意指定执行频次，如可以指定60min执行一次，高频运行，可以最大程度上保证可用性度量结果和真实应用体感一致。

另外，若在某一预设周期，执行测试用例连续失败达到指定次数，则确定待测试链路的监测结果为存在故障，即在一次执行测试用例过程中，可以配置重复次数，比如3次，若连续执行未通过的次数小于3，则重新执行，当失败次数达到3次时，才确定待测试链路存在故障，并可以输出具体的故障信息，且在一些实施例中，相关的监测结果通过报表的形式直观展示。

在本申请的一些实施例中，本申请还引入了工单，对于出现故障的情况，根据监测结果生成工单，并根据配置的信息发送都对应的故障维护方，能做做到第一时间通知到相应的工作人员；另外还可以生成实验室报表，在实验室报表中，记录实验室测试整体的过往数据，以及反馈情况等等。

在本申请的一些实施例中，所述方法还包括：响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，以消除执行所述测试用例中出现的故障，其中，所述测试用例调整指令是根据所述监测结果确定的。

也就是说，在测试用例不稳定性的情况下，可以对测度用例进行调整，具体的，响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，以消除执行所述测试用例中出现的故障。

下面列举了几项测试用例不稳定的解决办法，如所述链路类型为外卖下单链路，所述监测结果为线下商品库存被清零导致下单失败，所述测试用例调整指令为前置修改商品库存组件指令；所述响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，包括：响应于所述前置修改商品库存组件指令，将修改商品库存组件添加至所述测试用例中的第一指定位置。

即若监测结果为线下商品库存被清零导致下单失败，则可以通过前置增加一个“aic修改商品库存”组件，减少被其他测试人员误改库存带来的用例失败。

又如所述链路类型为外卖下单链路，所述监测结果为线下门店失效，所述测试用例调整指令为前置更新店铺营业状态为开店指令；所述响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，包括：响应于所述前置更新店铺营业状态为开店指令，将更新店铺营业状态为开店组件添加至所述测试用例中的第二指定位置。

即若监测结果为线下门店失效，则可以通过前置增加一个“更新店铺营业状态为开店”节点，确保门店状态为开业状态。

再如所述链路类型为外卖下单链路，所述监测结果为自动化创建线下活动数量大于预设阈值导致处理超时，所述测试用例调整指令为增加外卖-根据sellerid删除该sellerid下的所有减类活动组件指令，所述响应于测试用例调整指令，对所述所述测试用例中的测试组件进行调整，包括：响应于所述增加外卖-根据sellerid删除该sellerid下的所有减类活动组件指令，将所述增加外卖-根据sellerid删除该sellerid下的所有减类活动组件添加至所述测试用例中的第三指定位置。

即如果由于自动化创建太多线下交易活动，导致交易超时，进而用例失败。可以通过前置增加“[alsc-mp]外卖-根据sellerid删除该sellerid下的所有减类活动”组件，让商户下所有已经存在的活动失效，确保后续交易活动创建后，交易使用的交易活动符合预期，并且少量的交易活动，更有利于测试用例稳定性的提升；同时自动化创建的交易活动有效期缩短，避免商户下积累更多交易活动。

在一些实施例中，所述链路类型为外卖下单链路，所述监测结果为回调消息超时引起订单状态校验失败，所述测试用例调整指令为增加等待节点组件指令；所述响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，包括：响应于所述增加等待节点组件指令，将增加等待节点组件添加至所述测试用例中的第四指定位置。

即若监测结果为回调消息超时引起订单状态校验失败，则可以通过增加等待节点来解决。

在另一些实施例中，所述链路类型为外卖下单链路，所述监测结果为交易活动与预期不符，所述测试用例调整指令为增设关闭线下交易的缓存开关组件指令；所述响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，包括：响应于所述增设关闭线下交易的缓存开关组件指令，将关闭线下交易的缓存开关组件添加至所述测试用例中的第五指定位置。

即若监测结果为交易活动规则与预期不符，出现这个监测结果的原因是线下交易有缓存并且更新不及时，则可以通过增设关闭线下交易的缓存开关组件来解决。

仍然以前述的待测试链路为外卖下单链路为例，测试用例脚本通过调整可以为但不限于依次连接的：平台对接数据库获取入参组件、aic修改商品库存组件、更新店铺营业状态为开店组件、查询店铺信息组件、[alsc-mp]外卖-根据sellerird删除该sellerird下所有的减类活动组件、[alsc-mp]外卖-减activity-dreateAndEnable组件、[alsc-mp]外卖-减promo-dreateAndEnable组件、弹内提单页渲染build组件、弹内下单create组件、[交易]等待组件、[交易]ALSC通用弹内支付组件、[交易]等待组件、ATC订单查询并校验组件、[交易]等待组件、AFP2履约商户接单组件、[交易]等待组件、外卖中台算价校验组件。

通过上述等方法的综合治理，通过实验，本申请的方法应用可用率能够达到93％以上。

图2示出根据本申请的一个实施例的测试环境的监测装置的结构示意图，该装置应用于组件化软件开发平台，所述装置200包括：

识别单元210，用于识别待测试链路的链路类型；

调用单元220，用于响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本；

读取单元230，用于根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例；

执行单元240，用于在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果。

在本申请的一些实施例中，上述装置还包括：组件添加单元，用于在所述响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本的步骤之前，响应于测试组件添加指令，将与所述测试组件添加指令对应的测试组件，添加到所述组件化软件开发平台的已有组件。

在本申请的一些实施例中，在上述装置中，调用单元220，用于提供配置界面，通过配置界面接收所述组件调用指令，其中所述组件调用指令包括组件添加指令、组件删除指令，以及组件顺序调整指令中的至少一种，并响应于所述组件添加指令、所述组件删除指令，以及所述组件顺序调整指令，对各指令对应的测试组件执行相应的操作；将调用的多个测试组件，按照所述组件调用指令中的指定顺序以串联的形式整合，形成测试用例脚本，其中，各测试组件将前一测试组件的输出参数作为本测试组件的输入参数。

在本申请的一些实施例中，在上述装置中，读取单元230，用于根据识别的链路类型，确定所述测试用例脚本的入参数据源；连接所述入参数据源，并从所述入参数据源获取所述测试用例脚本的初始输入参数；将所述入参数据源输入所述测试用例脚本，形成所述待测试链路的测试用例。

在本申请的一些实施例中，在上述装置中，执行单元240，用于建立测试实验室，所述测试实验室包括目标测试环境以及所述测试用例；在所述测试实验室中，按照第一预设周期，执行所述测试用例；若在某一预设周期，执行所述测试用例连续失败达到指定次数，则确定所述目标测试环境的监测结果为存在故障；根据所述监测结果，生成障碍维护工单，并发送至对应的障碍维护方。

在本申请的一些实施例中，在上述装置中，调用单元220，还用于响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，以消除执行所述测试用例中出现的故障，其中，所述测试用例调整指令是根据所述监测结果确定的。

在本申请的一些实施例中，在上述装置中，所述链路类型为外卖下单链路，所述监测结果为线下商品库存被清零导致下单失败，所述测试用例调整指令为前置修改商品库存组件指令；调用单元220，用于响应于所述前置修改商品库存组件指令，将修改商品库存组件添加至所述测试用例中的第一指定位置。

在本申请的一些实施例中，在上述装置中，所述链路类型为外卖下单链路，所述监测结果为线下门店失效，所述测试用例调整指令为前置更新店铺营业状态为开店指令；调用单元220，用于响应于所述前置更新店铺营业状态为开店指令，将更新店铺营业状态为开店组件添加至所述测试用例中的第二指定位置。

在本申请的一些实施例中，在上述装置中，所述链路类型为外卖下单链路，所述监测结果为自动化创建线下活动数量大于预设阈值导致处理超时，所述测试用例调整指令为增加外卖-根据sellerid删除该sellerid下的所有减类活动组件指令，调用单元220，用于响应于所述增加外卖-根据sellerid删除该sellerid下的所有减类活动组件指令，将所述增加外卖-根据sellerid删除该sellerid下的所有减类活动组件添加至所述测试用例中的第三指定位置。

在本申请的一些实施例中，在上述装置中，所述链路类型为外卖下单链路，所述监测结果为回调消息超时引起订单状态校验失败，所述测试用例调整指令为增加等待节点组件指令；调用单元220，用于响应于所述增加等待节点组件指令，将增加等待节点组件添加至所述测试用例中的第四指定位置。

在本申请的一些实施例中，在上述装置中，所述链路类型为外卖下单链路，所述监测结果为交易活动与预期不符，所述测试用例调整指令为增设关闭线下交易的缓存开关组件指令；调用单元220，用于响应于所述增设关闭线下交易的缓存开关组件指令，将关闭线下交易的缓存开关组件添加至所述测试用例中的第五指定位置。

需要说明的是，上述的测试环境的监测装置能够一一实现前述的测试环境的监测方法，这里不再一一赘述。

图3是本申请的一个实施例电子设备的结构示意图。请参考图3，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他应用所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图3中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成测试环境的监测装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

识别待测试链路的链路类型；

响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本；

根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例；

在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果。

上述如本申请图2所示实施例揭示的测试环境的监测装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图2中测试环境的监测装置执行的方法，并实现测试环境的监测装置在图2所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图2所示实施例中测试环境的监测装置执行的方法，并具体用于执行：

识别待测试链路的链路类型；

响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本；

根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例；

在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

1.一种测试环境的监测方法，其特征在于，所述方法通过组件化软件开发平台实现，所述方法包括：

识别待测试链路的链路类型；

响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本；

根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例；

在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果。

2.根据权利要求1所述的方法，其特征在于，在所述响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本的步骤之前，还包括：

响应于测试组件添加指令，将与所述测试组件添加指令对应的测试组件，添加到所述组件化软件开发平台的已有组件。

3.根据权利要求1所述的方法，其特征在于，所述响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本，包括：

提供配置界面，通过配置界面接收所述组件调用指令，其中所述组件调用指令包括组件添加指令、组件删除指令，以及组件顺序调整指令中的至少一种，并响应于所述组件添加指令、所述组件删除指令，以及所述组件顺序调整指令，对各指令对应的测试组件执行相应的操作；

将调用的多个测试组件，按照所述组件调用指令中的指定顺序以串联的形式整合，形成测试用例脚本，其中，各测试组件将前一测试组件的输出参数作为本测试组件的输入参数。

4.根据权利要求1所述的方法，其特征在于，所述根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例，包括：

根据识别的链路类型，确定所述测试用例脚本的入参数据源；

连接所述入参数据源，并从所述入参数据源获取所述测试用例脚本的初始输入参数；

将所述入参数据源输入所述测试用例脚本，形成所述待测试链路的测试用例。

5.根据权利要求1所述的方法，其特征在于，所述在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果，包括：

建立测试实验室，所述测试实验室包括目标测试环境以及所述测试用例；

在所述测试实验室中，按照第一预设周期，执行所述测试用例；

若在某一预设周期，执行所述测试用例连续失败达到指定次数，则确定所述目标测试环境的监测结果为存在故障；

根据所述监测结果，生成障碍维护工单，并发送至对应的障碍维护方。

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

响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，以消除执行所述测试用例中出现的故障，其中，所述测试用例调整指令是根据所述监测结果确定的。

7.根据权利要求6所述的方法，其特征在于，所述链路类型为外卖下单链路，所述监测结果为线下商品库存被清零导致下单失败，所述测试用例调整指令为前置修改商品库存组件指令；

所述响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，包括：

响应于所述前置修改商品库存组件指令，将修改商品库存组件添加至所述测试用例中的第一指定位置。

8.根据权利要求6所述的方法，其特征在于，所述链路类型为外卖下单链路，所述监测结果为线下门店失效，所述测试用例调整指令为前置更新店铺营业状态为开店指令；

所述响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，包括：

响应于所述前置更新店铺营业状态为开店指令，将更新店铺营业状态为开店组件添加至所述测试用例中的第二指定位置。

9.根据权利要求6所述的方法，其特征在于，所述链路类型为外卖下单链路，所述监测结果为自动化创建线下活动数量大于预设阈值导致处理超时，所述测试用例调整指令为增加外卖-根据sellerid删除该sellerid下的所有减类活动组件指令；

所述响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，包括：

响应于所述增加外卖-根据sellerid删除该sellerid下的所有减类活动组件指令，将所述增加外卖-根据sellerid删除该sellerid下的所有减类活动组件添加至所述测试用例中的第三指定位置。

10.根据权利要求6所述的方法，其特征在于，所述链路类型为外卖下单链路，所述监测结果为回调消息超时引起订单状态校验失败，所述测试用例调整指令为增加等待节点组件指令；

所述响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，包括：

响应于所述增加等待节点组件指令，将增加等待节点组件添加至所述测试用例中的第四指定位置。

11.根据权利要求6所述的方法，其特征在于，所述链路类型为外卖下单链路，所述监测结果为交易活动规则与预期不符，所述测试用例调整指令为增设关闭线下交易的缓存开关组件指令；

所述响应于测试用例调整指令，对所述测试用例中的测试组件进行调整，包括：

响应于所述增设关闭线下交易的缓存开关组件指令，将关闭线下交易的缓存开关组件添加至所述测试用例中的第五指定位置。

12.一种测试环境的监测装置，其特征在于，所述装置应用于组件化软件开发平台实现，所述装置包括：

识别单元，用于识别待测试链路的链路类型；

调用单元，用于响应于组件调用指令，调用多个测试组件，形成所述待测试链路的测试用例脚本；

读取单元，用于根据识别的链路类型，读取所述测试用例脚本的初始输入参数，形成所述待测试链路的测试用例；

执行单元，用于在目标测试环境执行所述测试用例，以确定所述目标测试环境的监测结果。

13.一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行所述权利要求1～11所述方法。

14.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行所述权利要求1～11所述方法。

Images