系统测试方法、装置、设备、介质及程序产品

技术领域

本申请涉及计算机领域，尤其涉及一种系统测试方法、装置、设备、介质及程序产品。

背景技术

随着计算机软件系统的开发和版本迭代更新的需求不断增加，开发人员的测试工作量与日俱增，自动化测试就是一个解决开发人员测试工作压力的有效手段。

目前，系统开发逐渐实现了功能单元的模块化，这些功能单元在自动化测试中称为用例。随着时间的积累，自动化测试的用例越来越多。开发人员在进行自动化测试时，一般需要为每个测试单独编写一遍用例，或者是将现有的多个用例整合成为一个新的用例进行测试。每项测试都需要重复做一次，如果是一个复杂的系统，那么其测试需要重复整合编写的用例数量就会非常繁杂。这无疑又将原本减轻的测试工作又变得复杂了起来，严重影响了系统开发测试的效率，增加了开发人员的工作量。并且，过多的用例也让开发人员很难从整体上把握整个测试的逻辑结构。

综上，如何简化自动化测试中多个相关联的测试需要重复编写测试流程或整合多个用例成为了亟待解决的技术问题。

发明内容

本申请提供一种系统测试方法、装置、设备、介质及程序产品，以解决如何简化自动化测试中多个相关联的测试需要重复编写测试流程或整合多个用例的技术问题。

第一个方面，本申请提供一种系统测试方法，包括：

获取系统中预设业务的业务逻辑网络图，业务逻辑网络图中包括：多个功能单元以及测试数据在多个功能单元间的流通路径；

利用预设模型，根据业务逻辑网络图，确定在一个或多个测试单链；

利用预设测试模型，根据测试数据以及功能单元库，对各个测试单链进行测试，并在测试单链对应的链路图上显示测试结果。

在一种可能的设计中，链路图中包括各个目标功能单元所对应的用例控件，测试单链中包括一个或多个目标功能单元，在链路图上显示测试结果，包括：

当目标功能单元正确执行了目标功能时，以第一状态显示用例控件；

当目标功能单元没有正确执行目标功能时，以第二状态显示用例控件；

需要说明的是，第一状态与第二状态为不同的显示状态。

在一种可能的设计中，显示状态包括：用例控件的形状、颜色、尺寸大小、边框形式、显示名称中的至少一项。

在一种可能的设计中，利用预设测试模型，根据测试数据以及功能单元库，对各个测试单链进行测试，包括：

在功能单元库中筛选出测试单链中包含的各个目标功能单元；

将测试数据输入到测试单链中的第一个目标功能单元中；

若目标功能单元正确执行了目标功能，则返回执行成功信息，并将输出结果传递给下一个目标功能单元进行处理；

若目标功能单元不能正确执行目标功能，则返回执行失败信息；

测试结果包括：执行成功信息以及执行失败信息中的至少一个。

在一种可能的设计中，获取系统中预设业务的业务逻辑网络图，包括：

响应于用户输入的调用指令，将功能单元对应的用例控件显示在设计界面上；

响应于用户输入的关联指令，确定各个用例控件的输入通道和输出通道，以得到业务逻辑网络图。

可选的，该方法还包括：

响应于用户对链路图的调试指令，打开测试失败的目标功能单元的调整界面；

接收用户输入的调节指令，对应修改目标功能单元。

第二方面，本申请提供一种系统测试装置，包括：

获取模块，用于获取系统中预设业务的业务逻辑网络图，业务逻辑网络图中包括：多个功能单元以及测试数据在多个功能单元间的流通路径；

处理模块，用于利用预设模型，根据业务逻辑网络图，确定在一个或多个测试单链；

处理模块，还用于利用预设测试模型，根据测试数据以及功能单元库，对各个测试单链进行测试，并在测试单链对应的链路图上显示测试结果。

在一种可能的设计中，链路图中包括各个目标功能单元所对应的用例控件，测试单链中包括一个或多个目标功能单元，对应的，处理模块，用于：

当目标功能单元正确执行了目标功能时，以第一状态显示用例控件；

当目标功能单元没有正确执行目标功能时，以第二状态显示用例控件；

需要说明的是，第一状态与第二状态为不同的显示状态。

在一种可能的设计中，显示状态包括：用例控件的形状、颜色、尺寸大小、边框形式、显示名称中的至少一项。

在一种可能的设计中，处理模块，用于：

在功能单元库中筛选出测试单链中包含的各个目标功能单元；

将测试数据输入到测试单链中的第一个目标功能单元中；

若目标功能单元正确执行了目标功能，则返回执行成功信息，并将输出结果传递给下一个目标功能单元进行处理；

若目标功能单元不能正确执行目标功能，则返回执行失败信息；

测试结果包括：执行成功信息以及执行失败信息中的至少一个。

在一种可能的设计中，获取模块，用于：

响应于用户输入的调用指令，将功能单元对应的用例控件显示在设计界面上；

响应于用户输入的关联指令，确定各个用例控件的输入通道和输出通道，以得到业务逻辑网络图。

可选的，处理模块，还用于响应于用户对链路图的调试指令，打开测试失败的目标功能单元的调整界面；

获取模块，还用于接收用户输入的调节指令，对应修改目标功能单元。

第三方面，本申请提供一种电子设备，包括：

存储器，用于存储程序指令；

处理器，用于调用并执行所述存储器中的程序指令，执行第一方面所提供的任意一种可能的系统测试方法。

第四方面，本申请提供一种存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序用于执行第一方面所提供的任意一种可能的系统测试方法。

第五方面，本申请还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面所提供的任意一种可能的系统测试系统方法。

本申请提供了一种系统测试方法、装置、设备、介质及程序产品，通过获取系统中预设业务的业务逻辑网络图，该业务逻辑网络图中包括：多个功能单元以及测试数据在多个功能单元间的流通路径；然后利用预设模型，根据业务逻辑网络图，确定在一个或多个测试单链；再利用预设测试模型，根据测试数据以及功能单元库，对各个测试单链进行测试，并在测试单链对应的链路图上显示测试结果。通过业务逻辑网络图一次性构建了多个测试单链即测试流程，解决了如何简化自动化测试中多个相关联的测试需要重复编写测试流程或整合多个用例的技术问题。达到了一次设计多个关联测试项，并且让开发人员更清晰地整体掌握系统功能逻辑，还能够通过显示的测试结果快速发现和定位测试中出现的问题的技术效果。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请提供的一种数据汇总的场景示意图；

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

图3为本申请实施例提供的一种业务逻辑网络图的示意图；

图4为本申请实施提供的另一种系统测试方法的流程示意图；

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

图6为本申请提供的一种电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

下面先对本申请所涉及到的专业名词进行解释：

自动化测试，就是通过一些软件工具完成对系统某项或某些功能的测试工作，并验证其结果，把以人为驱动的测试行为转为机器执行的一种过程。自动化测试可以解放人力，被解放的人力可以从事其他方面的测试工作，大大的节约了人力成本。对于需要多次重复的测试、数据量较大的业务逻辑覆盖测试等测试场景，实施自动化测试将大幅提升测试效率。

用例，是系统中用于实现某个功能的单元模块。它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的交互。

测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

目前，现有的测试工作的实质，其实就是测试用例的编写过程，完成测试用例的编写后，让自动测试平台来进行自动测试。

但是，随着时间的积累，自动化测试的用例越来越多。开发人员在进行自动化测试时，一般需要为每个测试单独编写一遍用例，或者是将现有的多个用例整合成为一个新的用例进行测试。每项测试都需要重复做一次，如果是一个复杂的系统，那么其测试需要重复整合编写的用例数量就会非常繁杂。这无疑又将原本减轻的测试工作又变得复杂了起来，严重影响了系统开发测试的效率，增加了开发人员的工作量。并且，过多的用例也让开发人员很难从整体上把握整个测试的逻辑结构。

为解决上述技术问题。本申请的发明构思是：

摒弃为测试单独的功能而进行测试的惯用思想，转而从这个系统的整体功能逻辑架构上去自动构建出所需要的多个测试用例。也就是说，开发人员要做的是将系统的整体逻辑架构组建成完整的逻辑网络，由自动测试平台通过遍历逻辑网络来得到多个测试流程即测试用例。这样就避免了多次重复编写或整合测试用例的麻烦。并且，将测试的过程中，每个功能单元的测试结果都以图形化的形式展示出来，便于开发人员查找和定位导致测试失败的原因，并进行对应的修改。这样就能够极大地提高软件系统测试的效率。

图1为本申请提供的现有技术中软件系统测试的场景示意图。如图1所示，用户100对软件系统中的某项功能进行分析，提取出其逻辑步骤101，然后编制成测试用例102，将测试用例102输入到测试平台103中进行自动化测试。

这样的方式，随着系统的复杂程度的加深，测试系统中可以继承或调用的用例的增多，会使得用户100分析逻辑步骤101越来越吃力，无法准确把握各个用例之间的关联性。并且每测试一个功能，就要重复做一遍，导致了测试效率低的问题。

下面对本申请提供的系统测试方法如何处理简化处理自动化测试的用例构建过程进行详细介绍：

图2为本申请实施例提供的一种系统测试方法的流程示意图。如图2所示，该系统测试方法的具体步骤，包括：

S201、获取系统中预设业务的业务逻辑网络图。

在本步骤中，业务逻辑网络图中包括：多个功能单元以及测试数据在多个功能单元间的流通路径。

图3为本申请实施例提供的一种业务逻辑网络图的示意图。如图3所示，交易记录系统的业务逻辑图，根据交易记录的类型不同，分为了三种审批方式，非重要交易无需审批，低关注度的交易需要一人审批，而高关注度的交易需要双人审批，在审批通过后进行交易的录入、复核以及最终的记账存储。流通路径就是图3中从开始到结束之间各个箭头所指向的线路。

S202、利用预设模型，根据业务逻辑网络图，确定在一个或多个测试单链。

在本步骤中，测试单链用于表征测试数据在流通路径中流转时，各个目标功能单元对测试数据的处理顺序，在测试单链中包括至少一个目标功能单元。

需要说明的是，测试单链中每个目标功能单元只会输出一种数据，而不会得到两种结果，即测试单链中不会出现分支路径。

例如，如图3所示，利用预设模型遍历业务逻辑网络图中的每条路线，得到了6个测试单链，分别为：

测试单链1：发起申请→单人审批(同意)→录入→复核→存储。

测试单链2：发起申请→单人审批(不同意)。

测试单链3：发起申请→双人审批1(不同意)。

测试单链4：发起申请→双人审批1(同意)→双人审批2(不同意)。

测试单链5：发起申请→双人审批1(同意)→双人审批2(同意)→录入→复核→存储。

测试单链6：发起申请→录入→复核→存储。

S203、利用预设测试模型，根据测试数据以及功能单元库，对各个测试单链进行测试。

在本步骤中，将上一步所得到的测试单链中包含的各个目标功能模块，从功能单元库中筛选出来，然后根据测试单链的顺序进行组合，形成测试用例文件，输入到自动化测试平台中进行测试。自动化测试平台中包含有预设测试模型以及测试数据。

S204、在测试单链对应的链路图上显示测试结果。

在本步骤中，链路图中包括各个目标功能单元所对应的用例控件。

具体的，当目标功能单元正确执行了目标功能时，以第一状态显示用例控件；

当目标功能单元没有正确执行目标功能时，以第二状态显示用例控件；

需要说明的是，第一状态与第二状态为不同的显示状态。

可选的，显示状态包括：用例控件的形状、颜色、尺寸大小、边框形式、显示名称中的至少一项。

例如，在一个测试单链上具有多个目标功能单元，当测试进行到某个目标功能单元时，执行失败了，那么将此目标功能单元对应的用例控件显示为红色，以提示用户，在此位置发生了错误。

可以理解的是，如果目标功能单元执行成功，那么可以显示为绿色，代表此目标功能单元正确完成了目标功能。

本实施例提供了一种系统测试方法，通过获取系统中预设业务的业务逻辑网络图，该业务逻辑网络图中包括：多个功能单元以及测试数据在多个功能单元间的流通路径；然后利用预设模型，根据业务逻辑网络图，确定在一个或多个测试单链；再利用预设测试模型，根据测试数据以及功能单元库，对各个测试单链进行测试，并在测试单链对应的链路图上显示测试结果。通过业务逻辑网络图一次性构建了多个测试单链即测试流程，解决了如何简化自动化测试中多个相关联的测试需要重复编写测试流程或整合多个用例的技术问题。达到了一次设计多个关联测试项，并且让开发人员更清晰地整体掌握系统功能逻辑，还能够通过显示的测试结果快速发现和定位测试中出现的问题的技术效果。

图4为本申请实施提供的另一种系统测试方法的流程示意图。如图4所示，该系统测试方法的具体步骤包括：

S401、响应于用户输入的调用指令，将功能单元对应的用例控件显示在设计界面上。

在本实施例中，开发人员需要先构建系统的业务逻辑网络图，先通过图形化编辑器，将系统的业务逻辑中需要用到的功能单元所对应的用例控件从控件库中拖拽到设计界面上。

在一种可能的设计中，开发人员也可以通过点击选择、下拉框选择等方式添加用例控件。

S402、响应于用户输入的关联指令，确定各个用例控件的输入通道和输出通道，以得到业务逻辑网络图。

在本步骤中，在将功能单元所对应的用例控件添加到设计界面上后，再通过关联指令，比如用单向箭头连接任意两个用例控件来建立起各个用例控件间的联系，即建立各个用例控件的输入通道和输出通道，以此得到图3所示的业务逻辑网络图。

S403、利用预设模型，根据业务逻辑网络图，确定在一个或多个测试单链。

在本步骤中，通过预设遍历方式遍历整个业务逻辑网络图，得到至少一个测试单链。

S404、在功能单元库中筛选出测试单链中包含的各个目标功能单元。

在本步骤中，根据测试单链中各个目标功能单元及其连接顺序，从功能单元库中筛选出对应的功能单元模块。

S405、将测试数据输入到测试单链中的第一个目标功能单元中。

在本步骤中，从测试单链的第一个目标功能单元开始，输入测试数据，若该目标功能单元正确处理，得到了对应的输出数据，则将输出数据作为下一个目标功能单元的输入，循环执行测试，直至所有的目标功能单元都完成测试。

S406、若目标功能单元正确执行了目标功能，则返回执行成功信息，并将输出结果传递给下一个目标功能单元进行处理。

在本步骤中，在S405后，若目标功能单元测试通过，即正确执行了目标功能，则目标功能所对应的链路图上的用例空间显示为第一状态，如显示为绿色，即返回执行成功信息。然后将输出的结果传递给下一个目标功能单元继续进行测试，直至所有的目标功能单元都测试通过，或者是某个目标功能单元测试失败时，则停止测试。

S407、若目标功能单元不能正确执行目标功能，则返回执行失败信息。

在本步骤中，当测试单链中，某个目标功能单元不能正确执行目标功能时，其原因可能包括：对于上一个目标功能单元所传递来的数据识别不成功即接收错误；

或者是该目标功能单元内部的处理参数与当前的业务逻辑网络不对应，需要进行修正。

无论是何种原因，只要目标功能单元测试失败，则立即停止测试。对应的，将链路图上对应的用例控件的显示状态改为第二状态，如将其颜色改为红色，即返回执行失败信息。

S408、响应于用户对链路图的调试指令，打开测试失败的目标功能单元的调整界面。

在本实施例中，当测试失败时，用户可以点击链路图上第二状态的用例控件，如红色的用例控件，则对应打开测试失败信息记录，如测试日志LOG记录。

在一种可能的设计中，还可以进一步打开对应的目标功能单元的参数调节界面或者是编译界面。

S409、接收用户输入的调节指令，对应修改目标功能单元。

在本步骤中，用户在目标功能单元的调节界面或编译界面上，重新编写目标功能单元的内部设置程序，或者是修改对应的控制参数。

在修改完成后，用户可以重新执行上述测试程序，直至完成所有测试单链的测试。

本实施例提供了一种系统测试方法，通过获取系统中预设业务的业务逻辑网络图，该业务逻辑网络图中包括：多个功能单元以及测试数据在多个功能单元间的流通路径；然后利用预设模型，根据业务逻辑网络图，确定在一个或多个测试单链；再利用预设测试模型，根据测试数据以及功能单元库，对各个测试单链进行测试，并在测试单链对应的链路图上显示测试结果。通过业务逻辑网络图一次性构建了多个测试单链即测试流程，解决了如何简化自动化测试中多个相关联的测试需要重复编写测试流程或整合多个用例的技术问题。达到了一次设计多个关联测试项，并且让开发人员更清晰地整体掌握系统功能逻辑，还能够通过显示的测试结果快速发现和定位测试中出现的问题的技术效果。

图5为本申请实施例提供的一种系统测试装置的结构示意图。该系统测试装置可以通过软件、硬件或者两者的结合实现。

如图5所示，该系统测试装置500包括：

获取模块501，用于获取系统中预设业务的业务逻辑网络图，业务逻辑网络图中包括：多个功能单元以及测试数据在多个功能单元间的流通路径；

处理模块502，用于利用预设模型，根据业务逻辑网络图，确定在一个或多个测试单链；

处理模块502，还用于利用预设测试模型，根据测试数据以及功能单元库，对各个测试单链进行测试，并在测试单链对应的链路图上显示测试结果。

在一种可能的设计中，链路图中包括各个目标功能单元所对应的用例控件，测试单链中包括一个或多个目标功能单元，对应的，处理模块502，用于：

当目标功能单元正确执行了目标功能时，以第一状态显示用例控件；

当目标功能单元没有正确执行目标功能时，以第二状态显示用例控件；

需要说明的是，第一状态与第二状态为不同的显示状态。

在一种可能的设计中，显示状态包括：用例控件的形状、颜色、尺寸大小、边框形式、显示名称中的至少一项。

在一种可能的设计中，处理模块502，用于：

在功能单元库中筛选出测试单链中包含的各个目标功能单元；

将测试数据输入到测试单链中的第一个目标功能单元中；

若目标功能单元正确执行了目标功能，则返回执行成功信息，并将输出结果传递给下一个目标功能单元进行处理；

若目标功能单元不能正确执行目标功能，则返回执行失败信息；

测试结果包括：执行成功信息以及执行失败信息中的至少一个。

在一种可能的设计中，获取模块501，用于：

响应于用户输入的调用指令，将功能单元对应的用例控件显示在设计界面上；

响应于用户输入的关联指令，确定各个用例控件的输入通道和输出通道，以得到业务逻辑网络图。

可选的，处理模块502，还用于响应于用户对链路图的调试指令，打开测试失败的目标功能单元的调整界面；

获取模块501，还用于接收用户输入的调节指令，对应修改目标功能单元。

值得说明的是，图5所示实施例提供的装置，可以执行上述任一方法实施例中所提供的方法，其具体实现原理、技术特征、专业名词解释以及技术效果类似，在此不再赘述。

图6为本申请实施例提供的一种电子设备的结构示意图。如图6所示，该电子设备600，可以包括：至少一个处理器601和存储器602。图6示出的是以一个处理器为例的电子设备。

存储器602，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。

存储器602可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

处理器601用于执行存储器602存储的计算机执行指令，以实现以上各方法实施例所述的方法。

其中，处理器601可能是一个中央处理器(central processing unit，简称为CPU)，或者是特定集成电路(application specific integrated circuit，简称为ASIC)，或者是被配置成实施本申请实施例的一个或多个集成电路。

可选地，存储器602既可以是独立的，也可以跟处理器601集成在一起。当所述存储器602是独立于处理器601之外的器件时，所述电子设备600，还可以包括：

总线603，用于连接所述处理器601以及所述存储器602。总线可以是工业标准体系结构(industry standard architecture，简称为ISA)总线、外部设备互连(peripheralcomponent，PCI)总线或扩展工业标准体系结构(extended industry standardarchitecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器602和处理器601集成在一块芯片上实现，则存储器602和处理器601可以通过内部接口完成通信。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random accessmemory，RAM)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有程序指令，程序指令用于上述各方法实施例中的方法。

本申请实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由本申请的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。