CN114328275A - 系统测试方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种系统测试方法、装置、计算机设备和存储介质。该方法包括：计算机设备获取待测系统的根据待测系统的测试功能所确定多个测试用例，在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果，在第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果。在本方法中，通过构建生产监控测试平台，以不侵入式的测试方法实现在测试环境、实际生产环境等不同环境下的系统的测试，测试用例均为在测试环境下验证通过的用例，保证了系统在生产环境下测试的安全性、准确性，提高了系统测试的效率。

Description

系统测试方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种系统测试方法、装置、计算机设备和存储介质。

背景技术

在系统的软件开发过程涉及到多工种多任务, 每个开发人员在任意流程中都可能人为引入缺陷, 尤其是对于负责业务和数据管理而言, 细微的数据是不可见的, 如果泄露到生产环境将会带来很大影响。为了确保信息系统或其他运行系统的生产安全，需要对系统进行系统测试，以确定系统的运行质量。传统的方式是在测试环境下对系统进行测试、检查与验证，测试环境包括单元测试、功能测试、集成测试、系统测试。

由于测试环境和生产环境的软硬件环境不同，往往会出现在测试环境下系统的测试结果表示验证通过，但系统上线至生产环境中却存在故障的情况，可见，基于测试环境得到的信息系统的测试结果不准确。

发明内容

基于此，有必要针对上述技术问题，提供一种能够在实际生产环境中对系统进行测试的系统测试方法、装置、计算机设备和存储介质。

第一方面，提供一种系统测试方法，应用于生产监控测试平台中，该方法包括：

获取待测系统的多个测试用例；测试用例根据待测系统的测试功能所确定；

在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果；

在第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果。

在其中一个可选的实施例中，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果，包括：

获取各测试用例对应的第一测试结果；

若所有测试用例的第一测试结果均为验证通过，则确定第一测试结果为验证通过；

若存在至少一个测试用例的第一测试结果为验证失败，则确定第一测试结果为验证失败。

在其中一个可选的实施例中，上述方法还包括：

若第一测试结果为验证失败，则输出验证失败的测试用例，以指示用户对验证失败的测试用例进行调整，得到调整后的测试用例；

根据调整后的测试用例，返回执行调用测试引擎，根据各待测试用例在测试环境下对待测系统进行测试，得到待测系统的第一测试结果的步骤，直到第一测试结果为验证通过。

在其中一个可选的实施例中，上述方法还包括：

将各测试用例的第一测试结果与对应的期望结果进行比较；

若第一测试结果与对应的期望结果一致，则确定第一测试结果为验证通过；

若第一测试结果与对应的期望结果不一致，则确定第一测试结果为验证失败。

在其中一个可选的实施例中，在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果，包括：

获取测试环境的IP接口；

调用测试引擎基于测试环境的IP接口将各测试用例输入至待测系统中，以对待测系统进行测试，得到测试环境下的待测系统的第一测试结果。

在其中一个可选的实施例中，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果，包括：

获取实际生产环境的IP接口；

调用测试引擎基于实际生产环境的IP接口将各测试用例输入至待测系统中，以对待测系统进行测试，得到实际生产环境下的第二测试结果。

在其中一个可选的实施例中，上述方法还包括：

将各测试用例的第二测试结果与对应的期望结果进行比较；

若测试用例的测试结果与期望结果一致，则确定测试用例对应的测试功能的验证结果为验证通过；

若测试用例的测试结果与期望结果不一致，则确定测试用例对应的测试功能的验证结果为验证失败；

根据各测试功能的验证结果，生成并输出待测系统在实际生产环境下的测试报告。

在其中一个可选的实施例中，上述获取待测系统的多个测试用例，包括：

从预设的用例数据库中获取初始用例；

根据待测系统的测试功能，对初始用例进行修改，得到修改后的初始用例；

基于预设功能逻辑模型，对修改后的初始用例进行逻辑检查，将检查通过的用例确定为测试用例。

在其中一个可选的实施例中，上述方法还包括：

在待测系统在实际生产环境的系统测试过程中，获取待测系统的运行数据；

将待测系统的运行数据生成运行日志，并将运行日志存储至预设数据库中。

第二方面，提供一种系统测试装置，其特征在于，该装置包括：

获取模块，用于获取待测系统的多个测试用例；测试用例根据待测系统的测试功能所确定；

测试模块，用于在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果；

测试模块，还用于在第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果。

第三方面，提供一种计算机设备，包括存储器和处理器，该存储器存储有计算机程序，该处理器执行该计算机程序时实现上述第一方面任一所述的系统测试方法。

第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述第一方面任一所述的系统测试方法。

上述系统测试方法、装置、计算机设备和存储介质，应用于生产监控测试平台上，计算机设备获取待测系统的根据待测系统的测试功能所确定多个测试用例，在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果，在第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果。在本方法中，通过构建生产监控测试平台，基于生产监控测试平台可以调用测试引擎，以不侵入式的测试方法实现在测试环境、实际生产环境等不同环境下的系统的测试，且测试用例均为在测试环境下验证通过的用例，一定程度上保证了系统在生产环境下测试的安全性和测试结果的准确性，避免了由于用例的逻辑错误导致的在生产环境下进行系统测试造成的系统事故，同时，基于生产监控测试平台进行系统测试，提高了系统测试的效率。

附图说明

图1为一个实施例中系统测试方法的应用环境图；

图2为一个实施例中生产监控测试平台的结构示意图；

图3为一个实施例中系统测试方法的流程示意图；

图4为一个实施例中系统测试方法的流程示意图；

图5为一个实施例中系统测试方法的流程示意图；

图6为一个实施例中系统测试方法的流程示意图；

图7为一个实施例中系统测试方法的流程示意图；

图8为一个实施例中系统测试方法的流程示意图；

图9为一个实施例中系统测试方法的流程示意图；

图10为一个实施例中系统测试方法的流程示意图；

图11为一个实施例中系统测试方法的流程示意图；

图12为一个实施例中系统测试装置的结构框图；

图13为一个实施例中系统测试装置的结构框图；

图14为一个实施例中系统测试装置的结构框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的系统测试方法，可以应用于如图1所示的应用环境中。在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图1所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC（近场通信）或其他技术实现。该计算机程序被处理器执行时以实现一种系统测试方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图1中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在本实施例中，构建一种生产监控测试平台node-monitor，生产监控测试平台部署在计算机设备上，计算机设备基于生产node-monitor可以实现对任意一个服务节点server node的监控，实现本实施例提供的系统测试方法。如图2所示，本实施例提供的系统测试方法可以通过服务器中的Jenkins平台和移动终端的Monitor APP共同实现。Jenkins平台和Monitor APP共同形成了本实施例提供生产监控测试平台。在待测系统的测试或生产应用过程中，待测系统将实时产生的运行数据存储至生产数据库中，生产监控测试平台可以从待测系统的生产数据库中获取待测系统的运行数据，并将该获取到的运行数据进行存储。

生产监控测试平台node-monitor 包括测试用例管理、用例回归执行、持续跟踪、执行结果分析、输出测试报告等环节，为生产发布提供了重要质量保障。基于 生产监控测试平台node-monitor，可以构建不同场景的需求用例，并在任何同构环境下兼容，实现了基于相同用例实现对待测系统进行测试环境以及生产环境下的监控和测试的目的，提高了用例执行效率，降低了内部成本。

其中，通过jenkins和git整合实现用例更新和持续集成，包括在Jenkins中配置用例资源库、配置shell脚本以触发测试任务、以及构建触发器定时任务。基于springboot+cloudtest的框架实现了可支持多数据源的分布式测试监控平台node-monitor，其中，通过springboot提供的不同的注解声明配置，获取不同的数据源。示例地，获取本地数据源可以表示为@ConfigurationProperties(prefix = "spring.datasource.local")；获取远程数据源可以表示为@ConfigurationProperties(prefix = "spring.datasource.remote")，其中，本地数据源主要包括用例数据库中的用例，可选地，可以根据待测系统的测试结果对本地数据源中用例进行增删改查常规管理；远程数据源主要包括待测系统在运行环境下产生的运行数据，用于监控和记录。生产监控测试平台node-monitor基于cloudtest和springboot的整合，提供了restful服务接口，实现了与待测系统、远程终端的交互。

另外，在构建生产监控测试平台node-monitor之前，定义了基于业务验证和发布脚本验证的开发规范和使用规范。其中包括，数据库发布脚本的检验，主要是检查当前发布版本里PLSQL/PKG、DDL、DML的配置数据在发布至生产环境后是否有遗漏或者是否存在发布版本的脚本兼容/冲突性问题；可选地，还包括业务验证数据检查，基于业务场景设计出业务数据分析语句，当业务运行通过时筛选满足条件的业务数据, 以确定待测系统的功能上线后工作正常。此外，还需要约定断言逻辑，通过对验证功能分析结果的预期, 定义4种断言类型,包括①is_null，用于生产发布后期望无数据的场景；②not_null，用于期望查到业务数据的场景；③is_true，用于数据分析逻辑最终返回true的场景，运行不报错即返回true；④is_false，用于数据分析逻辑最终返回false的场景。

在基于每个用例的返回结果对应的断言逻辑确定用例的运行结果，识别该用例是否已经验证通过,对验证失败的用例持续回归跟踪，示例地，生产监控测试平台node-monitor可以基于内置数据模型和匹配算法分析确认每个用例是否已经执行成功或者失败。对验证失败的用例持续执行跟踪，在生产环境默认每次回归只对验证失败的用例进行持续跟踪，对验证通过的用例会做记录管理，默认不做持续跟踪，以此提高验证执行的效率。示例地，运行时使用CasePath + @ + CaseId作为参数在本地数据查询当前用例是否验证通过，如果验证通过则忽略，否则继续回归执行。另外，由于不同的功能发布日期不同，用例生效日期也不同。因此，生产监控测试平台node-monitor还可以根据用例的日期，动态调整用例对应的运行参数。例如，生产监控测试平台node-monitor基于每一个用例的发布时间，运行时动态设定执行时间条件, 基于执行时间条件，动态执行的目标。不会因为用例多、版本不同、发布日期不同而导致验证参数有混乱不清的问题。

在对待测系统进行测试之后生成该待测系统的测试报告，可选地，可以以邮件形式输出该测试报告至远程终端。并且，用户也可以基于远程终端以邮件形式来触发对待测系统的系统测试。示例地，可以约定邮件请求的标题规范，例如，凡是以[首单验证:xxx]为前缀的邮件,都需要在xxx环境验证，实现邮件轮询，如果以标题[首单验证:xxx]开头就进行后续处理，邮件服务中心实时将任务转发给生产监控测试平台node-monitor处理测试任务，提取首单验证的服务描述，并运行用例任务。用例执行完毕后，邮件发送测试报告到请求人。以此，来实现基于远程终端的触发的自助式测试的操作，且，基于邮件可以直接查看待测系统的测试结果，不需要登录任何第三方系统进行查看，十分方便，优化用户体验，并且，生产监控测试平台node-monitor可以实现对每个服务节点server node的检查验证，确保生产发布结果的量化可控。

在具体应用的场景下，开发人员开发过程需要新增一组数据库脚本，本地开发环境执行完毕后, 手动在测试环境执行，但是漏掉提交脚本，导致脚本不能被成功发布到生产应用，如果不被识别到，将会引入严重的生产事故。引入监控方案后，基于生产监控测试平台node-monitor，开发人员提交验证脚本，检查脚本数据是否成功发布到生产。生产监控测试平台node-monitor会在生产发布前对灾备以及测试环境进行上百次检查，确保递交结果在各个环境的一致性。如果某个环境验证失败，会有验证报告邮件通知，告知开发团队哪个需求的那个脚本遗漏。开发人员收到报告后即使处理问题，确保问题在生产发布前被解决，从而避免的生产事故。

开发人员完成开发前，遵循测试驱动的原则，提前设定好该功能正常工作的数据预期，并提供验证脚本方案。功能递交测试后，仅且仅当测试团队按要求完成功能测试的时候验证脚本方案才给出通过的报告，否则会提示业务功能验证失败的报告，可能原因是开发人员的工作质量有问题，也可能是测试人员的工作有问题。对项目而言，通过这种相互监控确保递交质量可控。对项目管理人员而言，通过查看报告即可了解开发和测试人员的工作质量。

下面将通过实施例并结合附图具体地对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。需要说明的是，本申请图3-图11实施例提供的系统测试方法，其执行主体为计算机设备（生产监控测试平台），也可以是系统测试装置，该系统测试装置可以通过软件、硬件或者软硬件结合的方式成为计算机设备（生产监控测试平台）的部分或全部。下述方法实施例中，均以执行主体是计算机设备（生产监控测试平台）为例来进行说明。

在一个实施例中，如图3所示，提供了一种系统测试方法，涉及的是计算机设备获取待测系统的根据待测系统的测试功能所确定多个测试用例，在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果，在第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果的过程，包括以下步骤：

S201、获取待测系统的多个测试用例；测试用例根据待测系统的测试功能所确定。

其中，测试用例指的是用于对待测系统进行测试的、待测系统各个测试功能所对应的用例。不同的待测系统对应不同数量的、不同内容的测试用例。

在本实施例中，生产监控平台（计算机设备）可以从指定的数据库中获取当前待测系统对应的测试用例，可选地，指定的数据库可以为本地数据库，也可以为云数据库。生产监控平台获取到待测系统的测试用例之后，还可以对测试用例的运行逻辑进行检查，得到运行逻辑无误的测试用例。可选地，待测系统存在功能升级或新增功能的情况，生产监控平台还可以基于待测系统的新功能进行测试用例的新增或修改，本实施例对此不做限定。

S202、在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果。

其中，测试环境指的是待测系统在上线公布前的内部测试环境。测试指令可以包括测试环境的接口地址、测试时长等信息。

在本实施例中，用户可以基于生产监控测试平台的显示界面触发测试指令，生产监控测试平台在接收到测试指令之后，调用测试引擎基于测试指令中包括的测试环境的接口地址，使用测试用例对待测系统进行测试，在满足测试时长之后，确定待测系统的第一测试结果，可选地，待测系统的第一测试结果包括待测系统在测试环境下，各个测试用例对应的第一测试结果。

S203、在第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果。

其中，第一测试结果为验证通过指的是待测系统中各个用例的第一测试结果验证通过，可选地，在确定各个用例的第一测试结果验证是否通过时，生产监控测试平台可以基于各个用例的期望结果来确定第一测试结果验证是否通过；或者，生产监控测试平台还可以基于布尔逻辑来确定各个用例的第一测试结果验证是否通过；或者，生产监控测试平台可以将各个用例的第一测试结果输入至测试评估模型/测试评估系统中，确定各个用例的第一测试结果验证是否通过。

在本实施例中，生产监控测试平台可以在确定待测系统的第一测试结果为验证通过后执行在实际生产环境下的系统测试，还可以基于接收到的用户发送的测试指令，来执行在实际生产环境下的系统测试。其中，用户发送的测试指令可以是基于预定格式的邮件发送的测试指令。在实际生产环境下进行系统测试，与在测试环境下进行系统测试类似地，生产监控测试平台可以从步骤202中的测试指令中获取实际生产环境的接口地址，也可以从用户通过邮件发送的测试指令中获取实际生产环境的接口地址，生产监控测试平台在接收到测试指令之后，调用测试引擎基于测试指令中包括的实际生产环境的接口地址，使用测试用例对待测系统进行测试，得到待测系统的第二测试结果，可选地，待测系统的第二测试结果包括待测系统在实际生产环境的各个测试用例对应的第一测试结果。

上述系统测试方法中，应用于生产监控测试平台上，计算机设备获取待测系统的根据待测系统的测试功能所确定多个测试用例，在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果，在第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果。在本方法中，通过构建生产监控测试平台，基于生产监控测试平台可以调用测试引擎，以不侵入式的测试方法实现在测试环境、实际生产环境等不同环境下的系统的测试，且测试用例均为在测试环境下验证通过的用例，一定程度上保证了系统在生产环境下测试的安全性和测试结果的准确性，避免了由于用例的逻辑错误导致的在生产环境下进行系统测试造成的系统事故，同时，基于生产监控测试平台进行系统测试，提高了系统测试的效率。

生产监控测试平台在其中一个可选的实施例中，如图4所示，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果，包括：

S301、获取各测试用例对应的第一测试结果。

在本实施例中，计算机设备调用测试引擎Jenkins，在测试环境下使用测试用例对待测系统进行系统测试，并接收测试引擎返回的各个测试用例对应的第一测试结果，示例地，测试用例可以为身份信息100XXX20050212XXXX，对应的测试功能为“系统禁止未成年人使用”，测试过程可等效为，将身份信息输入至待测系统中以登录系统，对应的测试结果包括该测试用例可以登录系统、该测试用例不可以登录系统中一个，需要说明的是，待测系统的功能丰富，根据待测系统的测试功能的不同，各个测试用例的第一测试结果所表示的物理含义不同。

S302、若所有测试用例的第一测试结果均为验证通过，则确定第一测试结果为验证通过。

其中，可选地，确定第一测试结果是否验证通过的方法包括：

将各测试用例的第一测试结果与对应的期望结果进行比较；若第一测试结果与对应的期望结果一致，则确定第一测试结果为验证通过；若第一测试结果与对应的期望结果不一致，则确定第一测试结果为验证失败。

在本实施例中，以上述例子来说明，测试用例为身份信息100XXX20050212XXXX，对应的测试功能为“系统禁止未成年人使用”，该测试用例的期望结果为“用例登录系统失败”，若该用例的第一测试结果为可以登录系统，与该测试用例的期望结果不一致，则说明该测试用例对应的待测系统的测试功能出现了逻辑异常，此时，确定该测试用例的第一测试结果为验证失败；若该用例的第一测试结果为登录系统失败，与该测试用例的期望结果一致，则说明该测试用例对应的待测系统的测试功能运行正常，此时，确定该测试用例的第一测试结果为验证通过。

S303、若存在至少一个测试用例的第一测试结果为验证失败，则确定第一测试结果为验证失败。

在本实施例中，为了确保待测系统满足生产达标，则需要确定待测系统中所有测试用例的第一测试结果均为验证通知，因此，若存在至少一个测试用例的第一测试结果为验证失败，则确定当前待测系统的第一测试结果为验证失败。可选地，生产监控测试平台还可以根据第一测试结果生成待测系统在测试环境下的测试报告，并将该测试报告输出至用户终端。

在本实施例中，生产监控测试平台可以基于各个测试用例的第一测试结果确定待测系统的第一测试结果为验证通过或验证失败，该方法在一定程度上可以确保待测系统的所有功能对应的测试用例的有效性。

在确定第一测试结果为验证失败的情况下，计算机设备还可以针对验证失败的测试用例进行修改调整，在其中一个可选的实施例中，如图5所示，上述方法还包括：

S401、若第一测试结果为验证失败，则输出验证失败的测试用例，以指示用户对验证失败的测试用例进行调整，得到调整后的测试用例。

在本实施例中，若确定待测系统的第一测试结果为验证失败，即确定存在至少一个测试用例的第一测试结果与期望结果不一致，此时，生产监控测试平台可以提取该测试用例并输出至用户终端，以使用户修改该验证失败的测试用例。例如，修改该测试用例的具体参数值，或者增加该测试用例的运行逻辑，得到调整后的测试用例，本实施例对修改测试用例的方法不做限定。

S402、根据调整后的测试用例，返回执行调用测试引擎，根据各待测试用例在测试环境下对待测系统进行测试，得到待测系统的第一测试结果的步骤，直到第一测试结果为验证通过。

在本实施例中，在得到调整后的测试用例之后，类似的，用户将调整之后的测试用例提交至GIT代码库中，生产监控测试平台从GIT代码库中获取调整之后的测试用例进行待测系统的重复测试，直到得到的待测系统的各个测试用例的第一测试结果均为验证通过，即，各个测试用例的第一测试结果均与各自对应的期望结果一致，此时确定待测系统的第一测试结果为验证通过。

在本实施例中，基于测试环境下的待测系统的第一测试结果可以初步确定待测系统的测试用例所对应的功能是否运行正常，从而针对不同的结果进行相应的操作，例如，针对验证失败的用例进行修改，为后续在实际生产环境下进行系统测试提供数据支撑。

计算机设备需要基于测试环境的IP接口进行测试环境下的系统测试，在其中一个可选的实施例中，如图6所示，在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果，包括：

S501、获取测试环境的IP接口。

在本实施例中，生产监控测试平台在调用测试引擎进行待测系统的测试时，根据不同的环境调用不同的接口，针对测试环境的测试，则获取测试环境的IP接口。

S502、调用测试引擎基于测试环境的IP接口将各测试用例输入至待测系统中，以对待测系统进行测试，得到测试环境下的待测系统的第一测试结果。

在本实施例中，生产监控测试平台调用测试引擎基于获取到的测试环境的IP接口，使用测试用例对待测系统进行测试，得到各个测试用例在测试环境下的第一测试结果，形成待测系统的第一测试结果。

在本实施例中，生产监控测试平台基于测试环境的IP接口，调用测试引擎以不侵入的方式进行待测系统在测试环境下的测试，从而得到待测系统的第一测试结果，为后续进行待测系统的实际生产环境测试提供数据支撑。

计算机设备需要基于实际生产环境的IP接口进行实际生产环境下的系统测试，在其中一个可选的实施例中，如图7所示，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果，包括：

S601、获取实际生产环境的IP接口。

在本实施例中，生产监控测试平台在调用测试引擎进行待测系统的测试时，根据不同的环境调用不同的接口，针对实际生产环境的测试，则获取实际生产环境的IP接口。

S602、调用测试引擎基于实际生产环境的IP接口将各测试用例输入至待测系统中，以对待测系统进行测试，得到实际生产环境下的第二测试结果。

在本实施例中，生产监控测试平台调用测试引擎基于获取到的实际生产环境的IP接口，使用测试用例对待测系统进行测试，得到各个测试用例在实际生产环境下的第二测试结果，形成待测系统的第二测试结果。

在本实施例中，生产监控测试平台基于实际生产环境的IP接口，调用测试引擎以不侵入的方式进行待测系统在实际生产环境下的测试，从而实现对待测系统在实际生产环境进行测试的目的。

在获取到系统在实际生产环境下的各个系统功能的第二测试结果之后，在其中一个可选的实施例中，如图8所示，上述方法还包括：

S701、将各测试用例的第二测试结果与对应的期望结果进行比较。

在本实施例中，与上述图4给出的实施例类似的，生产监控测试平台在获取到各个测试用例在实际生产环境下得到的第二测试结果之后，分别将各个测试用例的第二测试结果与其对应的期望结果进行比较。

S702、若测试用例的测试结果与期望结果一致，则确定测试用例对应的测试功能的验证结果为验证通过。

在本实施例中，与上述图4给出的实施例类似的，以上述例子来说明，测试用例为身份信息100XXX20050212XXXX，对应的测试功能为“系统禁止未成年人使用”，该测试用例的期望结果为“用例登录系统失败”，若该用例的第二测试结果为登录系统失败，与该测试用例的期望结果一致，则说明该测试用例对应的待测系统的测试功能运行正常，此时，确定该测试用例的第二测试结果为验证通过。

S703、若测试用例的测试结果与期望结果不一致，则确定测试用例对应的测试功能的验证结果为验证失败。

在本实施例中，以上述例子来说明，若该用例的第二测试结果为可以登录系统，与该测试用例的期望结果不一致，则说明该测试用例对应的待测系统的测试功能出现了逻辑异常，此时，确定该测试用例的第二测试结果为验证失败。

S704、根据各测试功能的验证结果，生成并输出待测系统在实际生产环境下的测试报告。

在本实施例中，生产监控测试平台根据得到的待测系统在实际生产环境下各个测试用例的第二测试结果，以及，每个测试用例所对应的系统功能验证通过或验证失败的信息，可选地，生产监控测试平台还可以确定验证失败的原因，例如，测试用例的逻辑异常、待测系统的测试功能的业务逻辑异常等。在获取到这些信息之后，生产监控测试平台可以基于这些信息，生成待测系统在实际生产环境下的测试报告，并输出至用户终端，可选地，生产监控测试平台可以通过邮件的方式输出至用户终端，简化用户获取测试报告的方式，优化用户体验。

在本实施例中，生产监控测试平台可以基于各个测试用例的第二测试结果生成待测系统的测试报告并及时输出至用户终端，使得用户可以对当前待测系统的所有功能的测试结果及时了解，确保了待测系统的测试报告的时效性。

为了适应待测系统的测试功能，在其中一个可选的实施例中，如图9所示，上述获取待测系统的多个测试用例，包括：

S801、从预设的用例数据库中获取初始用例。

在本实施例中，预设的用例数据库可以为设定的线上共享数据库，例如，Git数据库。生产监控测试平台可以从Git数据库中获取当前待测系统的初始用例，可选地，生产监控测试平台可以基于用例列表，从Git数据库中获取用例列表中所包括的初始用例。

S802、根据待测系统的测试功能，对初始用例进行修改，得到修改后的初始用例。

在本实施例中，生产监控测试平台在获取到初始用例之后，根据当前待测系统的功能设计，对初始用例进行调整，例如，增加用例、修改用例参数、删除用例等，得到满足当前待测系统所有功能需求的用例。

S803、基于预设功能逻辑模型，对修改后的初始用例进行逻辑检查，将检查通过的用例确定为测试用例。

在本实施例中，生产监控测试平台在对初始用例进行调整，得到满足当前待测系统所有功能需求的用例之后，还需要对用例进行逻辑检查，即判断用例是否符合当前待测系统的运行逻辑，当前待测系统的运行逻辑可以从待测系统的功能逻辑模型中确定，生产监控测试平台基于当前待测系统的运行逻辑对修改后的初始用例进行逻辑检查，将检查通过的用例确定为进行系统测试的测试用例，本实施例对此不做限定。

在本实施例中，生产监控测试平台可以基于当前待测系统的功能进行用例的增加、删除、修改、查询等操作，得到符合当前待测系统功能需求，且符合待测系统的运行逻辑的测试用例，在测试用例设计阶段就初步确保测试用例的有效性。

此外，计算机设备还可以实时地获取待测系统的运行数据，实现对待测系统的实时监控，在其中一个可选的实施例中，如图10所示，上述方法还包括：

S901、在待测系统在实际生产环境的系统测试过程中，获取待测系统的运行数据。

在本实施例中，生产监控测试平台还可以实时获取待测系统的运行数据，例如，运行数据包括待测系统中各个功能执行所产生的实时数据。可选地，生产监控测试平台可以通过预设的远程接口从待测系统的数据库中获取运行数据，本实施例对此不做限定。

S902、将待测系统的运行数据生成运行日志，并将运行日志存储至预设数据库中。

在本实施例中，生产监控测试平台在获取到待测系统的运行数据之后，可选地，可以生产待测系统的运行日志，并将该运行日志存储至生产监控测试平台的指定存储空间中，例如存储至数据库中，本实施例对此不做限定。

在本实施例中，生产监控测试平台还可以实现对待测系统的实时运行监控，并可以获取待测系统的运行数据，用户可以基于该运行数据进行数据分析得到待测系统的运行状态，为该数据分析操作提供了数据支撑。

为了更好的说明上述方法，如图11所示，本实施例提供一种系统测试方法，按照时序逻辑，从三个阶段给出了系统测试方法的具体流程。

系统测试方法的第一阶段为用例开发设计阶段，在该阶段用户根据待测系统的功能进行用例的设计，例如，基于待测系统的功能新增用例、修改用例参数、删除用例等，在得到当前待测系统的一套用例之后，基于专家量化系统对该一整套用例进行用例评审，从用例的运行逻辑、用例的参数调整等维度对用例进行评估，得到通过专家量化系统评估之后的用例，以提交至git代码库，为后续生产监控测试平台进行待测系统的系统测试提供数据支撑。

系统测试方法的第二阶段为基于测试环境的内部测试阶段，生产监控测试平台可以从git代码库中获取当前待测系统的测试用例，通过调用测试引擎，以无侵入式在待测系统的测试环境中运行用例，得到测试环境下的待测系统的测试结果，可选地，基于该测试结果，可以以多种形式输出测试报告，并从测试结果中确定测试不通过的用例，向用户返回测试不通过的用例，以使用户对该用例进行修改，直到该用例测试通过，得到所有测试用过的用例，也即实现待测系统在测试环境下所有用例对应的功能均测试通过，待测系统生产上线达标的目的。

系统测试方法的第三阶段为基于生产环境的测试阶段，在确定当前待测系统中所有功能生产上线达标，则进入本阶段的测试。生产监控测试平台可以接收用户以邮件形式发送的对待测系统进行测试的指令，可选地，生产监控测试平台还可以接收其他形式接收的待测系统的测试指令，在接收到测试指令之后，基于最新用例，也即上一个阶段确定测试通过的所有用例，对待测系统进行生产环境下的用例测试，得到待测系统在生产环境下的测试报告，其中包括待测系统中在测试过程中，验证通过和/或验证失败的相关信息，可选地，生产监控测试平台可以将该测试报告以邮件或其他形式输出至用户终端，以使用户基于测试报告对待测系统进行风险评估、质量评估、异常处理等操作，与此同时，生产监控测试平台还可以对验证失败的用例对应的系统功能进行监控跟踪，在用户进行异常处理之后，还可以对异常处理之后的系统进行再次测试，直到待测系统中所有功能均验证通过，从而发布验证通过后的系统。

在本实施例中，系统测试的三个阶段均为自动化完全，提升了系统测试的执行效率；并且，在测试环境下对待测系统进行测试，确定用例均通过验证，系统功能达标之后，在实际生产环境下对待测系统进行测试，可以提前发现严重脚本遗漏或者错误, 避免在实际生产环境下进行系统测试所导致的严重生产事故；从制定生产需求、内部开发、内部测试到生产发布，生产监控测试平台可以实现实时监控和异常跟踪，确保了系统测试方法的可靠性。

上述实施例提供的系统测试方法，其实现原理和技术效果与上述方法实施例类似，在此不再赘述。

应该理解的是，虽然图3-11的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图3-11中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图12所示，提供了一种系统测试装置，包括：

获取模块01，用于获取待测系统的多个测试用例；测试用例根据待测系统的测试功能所确定；

测试模块02，用于在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果；

测试模块02，还用于在第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果。

在其中一个可选的实施例中，测试模块02，用于获取各测试用例对应的第一测试结果；若所有测试用例的第一测试结果均为验证通过，则确定第一测试结果为验证通过；若存在至少一个测试用例的第一测试结果为验证失败，则确定第一测试结果为验证失败。

在其中一个可选的实施例中，如图13所示，上述系统测试装置还包括输出模块03，用于在第一测试结果为验证失败的情况下，则输出验证失败的测试用例，以指示用户对验证失败的测试用例进行调整，得到调整后的测试用例；

测试模块02，用于根据调整后的测试用例，返回执行调用测试引擎，根据各待测试用例在测试环境下对待测系统进行测试，得到待测系统的第一测试结果的步骤，直到第一测试结果为验证通过。

在其中一个可选的实施例中，测试模块02，用于将各测试用例的第一测试结果与对应的期望结果进行比较；若第一测试结果与对应的期望结果一致，则确定第一测试结果为验证通过；若第一测试结果与对应的期望结果不一致，则确定第一测试结果为验证失败。

在其中一个可选的实施例中，测试模块02，用于获取测试环境的IP接口；调用测试引擎基于测试环境的IP接口将各测试用例输入至待测系统中，以对待测系统进行测试，得到测试环境下的待测系统的第一测试结果。

在其中一个可选的实施例中，测试模块02，用于获取实际生产环境的IP接口；调用测试引擎基于实际生产环境的IP接口将各测试用例输入至待测系统中，以对待测系统进行测试，得到实际生产环境下的第二测试结果。

在其中一个可选的实施例中，测试模块02，还用于将各测试用例的第二测试结果与对应的期望结果进行比较；若测试用例的测试结果与期望结果一致，则确定测试用例对应的测试功能的验证结果为验证通过；若测试用例的测试结果与期望结果不一致，则确定测试用例对应的测试功能的验证结果为验证失败；

输出模块03，还用于根据各测试功能的验证结果，生成并输出待测系统在实际生产环境下的测试报告。

在其中一个可选的实施例中，获取模块01，用于从预设的用例数据库中获取初始用例；根据待测系统的测试功能，对初始用例进行修改，得到修改后的初始用例；基于预设功能逻辑模型，对修改后的初始用例进行逻辑检查，将检查通过的用例确定为测试用例。

在其中一个可选的实施例中，如图14所示，上述系统测试装置还包括监控模块04，用于在待测系统在实际生产环境的系统测试过程中，获取待测系统的运行数据；将待测系统的运行数据生成运行日志，并将运行日志存储至预设数据库中。

关于系统测试装置的具体限定可以参见上文中对于系统测试方法的限定，在此不再赘述。上述系统测试装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

获取待测系统的多个测试用例；测试用例根据待测系统的测试功能所确定；

在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果；

在第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果。

上述实施例提供的计算机设备，其实现原理和技术效果与上述方法实施例类似，在此不再赘述。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

获取待测系统的多个测试用例；测试用例根据待测系统的测试功能所确定；

在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各测试用例对待测系统进行测试，得到待测系统的第一测试结果；

在第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各测试用例对待测系统进行测试，得到待测系统的第二测试结果。

上述实施例提供的计算机可读存储介质，其实现原理和技术效果与上述方法实施例类似，在此不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器（Read-Only Memory，ROM）、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器（Static Random Access Memory，SRAM）或动态随机存取存储器（Dynamic Random Access Memory，DRAM）等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (12)

1.一种系统测试方法，其特征在于，应用于生产监控测试平台中，所述方法包括：

获取待测系统的多个测试用例；所述测试用例根据所述待测系统的测试功能所确定；

在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各所述测试用例对所述待测系统进行测试，得到所述待测系统的第一测试结果；

在所述第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各所述测试用例对所述待测系统进行测试，得到所述待测系统的第二测试结果。

2.根据权利要求1所述的方法，其特征在于，所述调用测试引擎，在测试环境下根据各所述测试用例对所述待测系统进行测试，得到所述待测系统的第一测试结果，包括：

获取各所述测试用例对应的第一测试结果；

若所有所述测试用例的第一测试结果均为验证通过，则确定所述第一测试结果为验证通过；

若存在至少一个所述测试用例的第一测试结果为验证失败，则确定所述第一测试结果为验证失败。

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

若所述第一测试结果为验证失败，则输出所述验证失败的测试用例，以指示用户对所述验证失败的测试用例进行调整，得到调整后的测试用例；

根据所述调整后的测试用例，返回执行所述调用测试引擎，在测试环境下根据各所述测试用例对所述待测系统进行测试，得到所述待测系统的第一测试结果的步骤，直到所述第一测试结果为验证通过。

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

将各所述测试用例的第一测试结果与对应的期望结果进行比较；

若所述第一测试结果与对应的期望结果一致，则确定所述第一测试结果为验证通过；

若所述第一测试结果与对应的期望结果不一致，则确定所述第一测试结果为验证失败。

5.根据权利要求1-3任一项所述的方法，其特征在于，所述在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各所述测试用例对所述待测系统进行测试，得到所述待测系统的第一测试结果，包括：

获取所述测试环境的IP接口；

调用所述测试引擎基于所述测试环境的IP接口将各所述测试用例输入至所述待测系统中，以对所述待测系统进行测试，得到所述测试环境下的所述待测系统的所述第一测试结果。

6.根据权利要求1所述的方法，其特征在于，所述调用测试引擎，在实际生产环境下根据各所述测试用例对所述待测系统进行测试，得到所述待测系统的第二测试结果，包括：

获取所述实际生产环境的IP接口；

调用所述测试引擎基于所述实际生产环境的IP接口将各所述测试用例输入至所述待测系统中，以对所述待测系统进行测试，得到所述实际生产环境下的所述第二测试结果。

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

将各所述测试用例的第二测试结果与对应的期望结果进行比较；

若所述测试用例的测试结果与期望结果一致，则确定所述测试用例对应的测试功能的验证结果为验证通过；

若所述测试用例的测试结果与期望结果不一致，则确定所述测试用例对应的测试功能的验证结果为验证失败；

根据各所述测试功能的验证结果，生成并输出所述待测系统在所述实际生产环境下的测试报告。

8.根据权利要求1-3中任一项所述的方法，其特征在于，所述获取待测系统的多个测试用例，包括：

从预设的用例数据库中获取初始用例；

根据所述待测系统的测试功能，对所述初始用例进行修改，得到修改后的初始用例；

基于预设功能逻辑模型，对所述修改后的初始用例进行逻辑检查，将检查通过的用例确定为所述测试用例。

9.根据权利要求1-3中任一项所述的方法，其特征在于，所述方法还包括：

在所述待测系统在所述实际生产环境的系统测试过程中，获取所述待测系统的运行数据；

将所述待测系统的运行数据生成运行日志，并将所述运行日志存储至预设数据库中。

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

获取模块，用于获取待测系统的多个测试用例；所述测试用例根据所述待测系统的测试功能所确定；

测试模块，用于在接收到测试指令的情况下，调用测试引擎，在测试环境下根据各所述测试用例对所述待测系统进行测试，得到所述待测系统的第一测试结果；

测试模块，还用于在所述第一测试结果为验证通过的情况下，调用测试引擎，在实际生产环境下根据各所述测试用例对所述待测系统进行测试，得到所述待测系统的第二测试结果。

11.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至9中任一项所述的方法的步骤。

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

Images