CN115687054A - 基于业务分割还原的自适应测试方法以及装置 - Google Patents

Abstract

本申请公开了一种基于业务分割还原的自适应测试方法以及装置。该方法包括基于预设测试用例提交业务测试数据；根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态；根据所述当前业务的下一个业务环节信息、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据；基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告。通过本申请动态地构建测试脚本，实现了脚本自适应功能，提高了自动化测试的执行效率。

Description

基于业务分割还原的自适应测试方法以及装置

技术领域

本申请涉及软件测试领域，具体而言，涉及一种基于业务分割还原的自适应测试方法以及装置。

背景技术

随着企业信息化的普及，企业的各种业务活动都以数字化信息技术实现，形成了企业的信息系统。企业的信息系统里包含了不同业务的应用模块，每个应用里，包含了处理该业务的多种业务逻辑。

在针对业务的测试工作中，需要验证基于业务逻辑的数据表现及操作。业务验证的端到端的测试用例由一组连续的、多个业务参与者参与的交互事件构成。测试用例从提交业务表单开始，到根据业务规则流转每个业务环节，以每个参与者身份验证每个环节的业务数据显示完备性、正确性及操作能否正确执行，直至整个业务流程结束。通常采用自动化测试脚本进行测试时按照测试用例的执行顺序，将交互事件及事件参与者以硬编码地形式写在脚本里。

但是当测试环境配置或者业务发生变化，会导致业务流程或者参与者有变，测试脚本失效，回归测试执行失败。增加了测试脚本的维护成本，同时也会延长软件交付周期。

针对相关技术中采用自动化测试脚本时效率低且受到测试环境影响的问题，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种基于业务分割还原的自适应测试方法以及装置，以解决采用自动化测试脚本时效率低且受到测试环境影响的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种基于业务分割还原的自适应测试方法。

根据本申请的基于业务分割还原的自适应测试方法括：基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成；根据所述业务测试数据中的唯一标识信息，按照从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节信息、当前业务的下一个业务环节的参与者；根据所述当前业务的下一个业务环节信息、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据；基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告。

进一步地，所述基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成，包括：基于所述信息系统的业务流程测试，按照业务参与者或者业务场景进行业务分割之后，得到所述业务模块，用以形成所述业务模块测试脚本；根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节、当前业务的下一个业务环节的参与者，包括：在执行业务验证的自动化测试脚本时，通过系统的API接口和/或UI界面上提供的查询接口，按照所述测试业务流程的所述唯一标识信息从业务系统查询还原出所述业务流程的实时状态。

进一步地，所述根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，还包括：通过所述系统的API接口按照所述测试业务流程从业务系统查询还原出所述业务流程的当前业务的下一个业务环节、当前业务的下一个业务环节的参与者。

进一步地，所述根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，还包括：通过所述UI界面按照所述测试业务流程从业务系统查询还原出所述业务流程的当前业务的下一个业务环节、当前业务的下一个业务环节的参与者。

进一步地，所述根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，还包括：在所述业务环节的参与者包括多个的情况下，根据预设业务规则过滤出一个或多个参与者，并将所述一个或多个参与者信息从测试系统配置文件中至少匹配出所述参与者的登录账号信息。

进一步地，所述根据所述当前业务的下一个业务环节、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据包括：判断所述当前业务是否是结束环节；如果判断所述当前业务不是结束环节，则根据查询还原出的环节信息调用相应的业务模块测试脚本。

进一步地，所述基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告，包括：基于测试脚本不断重复所述根据所述当前业务的下一个业务环节、所述当前业务的下一个业务环节的参与者，调用所述相应的业务模块测试脚本，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试；根据所述测试脚本执行过程中实际调用的各业务测试流程的汇总结果，对比是否实现了所述预设测试用例的测试目标，生成所述测试报告。

进一步地，所述基于预设测试用例提交业务测试数据之前，还包括：基于预设测试用例以业务流程从开始到结束的预设顺序，对业务中的每个操作以业务参与者、业务场景两个因素进行标注；所述业务流程以第一个操作为{0,0}开始，如果操作业务的参与者改变，且业务场景不变，则标注为{1,0}；如果操作业务参与者不变化，且业务场景发生变化，则标注为{0,1}；如果操作业务参与者、所述业务场景两者都不发生变化，则标注为{0,0}；如果操作业务参与者、所述业务场景两者均发生变化，则标注为{1,1}。

进一步地，所述基于预设测试用例以业务流程从开始到结束的预设顺序，对业务中的每个操作以业务参与者、业务场景两个因素进行标注之后，还包括：在根据所述操作业务参与者的变化为基准对业务进行分割的情况下，在所述操作业务参与者发生变化即标注结果为{1,*}的情况下，对所述业务进行分割；在根据所述业务场景的变化为基准对业务进行分割的情况下，在所述操作业务场景发生变化即标注结果为{*,1}的情况下，对所述业务进行分割；在根据所述业务参与者或者业务场景的变化为基准对业务进行细颗粒度分割的情况下，即标注结果为非{0,0}的情况下，对所述业务进行分割。至于采用上述哪种分割方式，则是根据实际测试需要以及业务系统提供的还原能力以及还原颗粒度确定的。

为了实现上述目的，根据本申请的另一方面，提供了一种基于业务分割还原的自适应测试装置。

根据本申请的基于业务分割还原的自适应测试装置包括：提交模块，用于基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成；查询模块，用于根据所述业务测试数据中的唯一标识信息，按照从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节、当前业务的下一个业务环节的参与者；控制模块，用于根据所述当前业务的下一个业务环节、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据；测试模块，用于基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告。

为了实现上述目的，根据本申请的另一方面，提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述的方法。

在本申请实施例中基于业务分割还原的自适应测试方法以及装置，采用基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成，通过根据所述业务测试数据中的唯一标识信息，按照从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节信息、当前业务的下一个业务环节的参与者，达到了基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告的目的，从而实现了脚本自适应以及提高了自动化测试的执行效率的技术效果，进而解决了采用自动化测试脚本时效率低且受到测试环境影响的技术问题。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的基于业务分割还原的自适应测试方法的系统示意图；

图2是根据本申请实施例的基于业务分割还原的自适应测试方法流程示意图；

图3是根据本申请实施例的基于业务分割还原的自适应测试装置结构示意图；

图4是根据本申请实施例的基于业务分割还原的自适应测试方法中优选实施方式的流程示意图；

图5是根据本申请实施例的基于业务分割还原的自适应测试方法中业务分割原理示意图。

具体实施方式

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

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

在针对业务的测试工作中，专注于验证基于业务逻辑的数据表现及操作。业务验证的端到端的测试用例由一组连续的、多个业务参与者参与的交互事件构成。测试用例从提交业务表单开始，到根据业务规则流转每个业务环节，以每个参与者身份验证每个环节的业务数据显示完备性、正确性及操作能否正确执行，直至整个业务流程结束。

实际软件开发中，在每次系统迭代升级前，都应该对系统进行回归测试，以保证系统的质量，降低后期发现BUG的修复成本。但如果每次都单单依靠手工测试去填写众多的表格，执行复杂的业务逻辑进行测试，效率很低，且工作量巨大，不可能实现全面的回归测试。采取自动化测试势在必行。

发明人研究发现，一般地，自动化测试脚本按照测试用例的执行顺序，将交互事件及事件参与者以硬编码地形式写在脚本里。如果采用硬编码形式编写的测试脚本，维护性较差，相似业务逻辑的测试脚本不能复用。业务逻辑发生变更时，需要维护多处脚本。业务环节的参与者发生变化时，脚本也要随之改变。

更进一步地，在实际测试中，管理信息系统庞大、配置复杂，不可能每次都重置环境，而且测试环境多人共享，如果测试环境系统配置有变，也会导致业务逻辑或者业务参与者发生变化。此时，测试脚本会失效，执行会失败，需要花费成本维护修改测试脚本。

本申请实施例中提出的自适应测试方法，同时适用于自动化测试中的API测试和UI测试。针对基于业务逻辑的信息系统进行业务测试时，如果将测试业务场景及业务参与者以硬编码形式写入测试脚本，脚本的可维护性很差，且不易扩展。而且如果测试环境配置或者业务发生变化，会导致业务流程或者参与者有变，测试脚本失效，回归测试执行失败。此时需要修改测试脚本才能执行回归测试，增加了测试脚本的维护成本，延长了软件交付周期。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

如图1所示，信息系统前端是PC界面层或者移动界面层，后端是Web服务器、应用服务器及数据库服务器等，并提供RESTfulAPI服务层，负责前后端的通信和数据交换。对于这些系统，自动化测试可分为API测试和UI测试。两种测试都能实现功能测试的目的。

API测试，针对系统后端的服务层，利用服务层提供的RESTfulAPI，测试软件向服务层发送基于HTTP协议的API命令，获取返回信息，验证系统的响应。实现API测试的工具有很多，有Java、Python、Jmeter等，在本申请中并不进行具体限定。

UI测试，针对系统前端的PC界面层或者移动界面层的，通过模拟现实中用户的手动操作，以真实用户的视角，对系统进行操作、验证。实现UI测试的工具，目前普遍的是Selenium，也有本实施例中用到的新兴工具Nightwatch。

实施例一

如图2所示，该方法包括如下的步骤S201至步骤S204：

步骤S201，基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成；

步骤S202，根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节信息、当前业务的下一个业务环节的参与者；

步骤S203，根据所述当前业务的下一个业务环节信息、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据；

步骤S204，基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告。

从以上的描述中，可以看出，本申请实现了如下技术效果：

采用基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成，通过根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节信息、当前业务的下一个业务环节的参与者，达到了基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告目的，从而实现了脚本自适应以及提高了自动化测试的执行效率的技术效果，进而解决了采用自动化测试脚本时效率低且受到测试环境影响的技术问题。

在上述步骤S201中会基于预设测试用例提交业务测试数据。

根据测试业务流程是预先经过业务分割得到的原则能划分出清晰的业务边界，考虑到当操作业务参与者发生改变或者业务场景转变，所以需要确定并提炼出操作业务参与者与业务场景的特征。从而根据所述提炼出操作业务参与者或业务场景的特征划分出清晰的业务边界。不论是API测试还是UI测试，都可以遵循此原则对业务进行分割。针对分割后的业务模块，形成业务模块测试脚本。

本实施例中，在以工作流引擎为流程支撑的信息系统，主要以业务参与者变化作为业务流程上环节的转换。在实施例中，以业务参与者为基准进行业务分割，即可认为是按照工作流各个环节进行业务分割。将参与者，业务特征等信息作为参数提炼出来。自动化测试脚本运行时，由控制模块根据测试脚本及实时业务数据，进行参数传递。

作为一种可选地实施方式，所述业务测试数据提交后所有可能经过的业务流程是可以由预先经过业务分割的业务模块组成。

作为一种优选地实施方式，通过分析预设测试用例，以业务流程从开始到结束为顺序，对业务中的每个操作以业务参与者、业务场景两个因素进行标注。

在上述步骤S202中根据上述步骤中得到的所述业务测试数据中确定的唯一标识信息，按照从业务系统查询还原出所述业务流程的实时状态。

作为一种可选地实施方式，以信息系统为例，一个业务流程实例从开始到结束，都有一个唯一标识贯穿始终，这个唯一标识信息可以是业务单据号，也可以是流程实例ID。

作为一种优选地实施方式，被还原出的所述实时状态至少包括如下之一：当前业务的下一个业务环节、当前业务的下一个业务环节的参与者。

根据还原信息，调用相应的业务模块测试脚本，对业务流程进行还原。从控制模块提取出下一个业务环节的种类及参与者登录信息，测试脚本以该参与者身份的账号登录系统，执行下一个业务环节对应的业务模块测试脚本中描述的业务操作，验证业务数据、结果，完成该环节的业务测试。

举例而言，如果从控制模块调出部门负责人审批环节的测试脚本，以李四登录系统，执行部门负责人审批环节的测试脚本，检验该环节业务数据的完备性，及进行审批操作，比如“同意”的操作，进入下一个环节。实时更新还原信息，当环节测试脚本执行完成时，也许业务数据已经发生了变化，后续环节已更新。所以测试脚本在执行下一个环节之前，应该重新调用查询模块或具有相同功能的模块，实时查询下一个环节及参与者信息。

在上一个例子中，如果业务测试目标是“所领导审批”，测试脚本模拟部门负责人审批时，选择了“需要所领导审批”的选项，则此时查询模块查询出的下一个环节由原定的财务审核环节被更新成了所领导审批环节。同样，如果业务测试目标是“驳回”，测试脚本模拟部门负责人审批时，选择了“驳回”，则此时查询模块查询出的下一个环节是，回到表单提交环节。同样，如果系统配置被更改了，配置变成了部门负责人审批结束后，需要“归口部门审批”。则当部门负责人审批业务模块测试脚本执行结束以后，查询模块查询出的下一个环节是，归口部门审批。控制模块应调用归口部门审批业务模块测试脚本。

需要注意的是，上述的业务模块测试脚本、控制模块、查询模块用于作为描述某个软件模块所实现的功能，在本申请中并不进行具体限定。

在上述步骤S203中根据所述当前业务的下一个业务环节信息、所述当前业务的下一个业务环节的参与者，可以调用相应的业务模块测试脚本数据。

作为一种可选地实施方式，相应的业务模块测试脚本数据与具体的信息系统的业务数据流程相关。

作为一种优选地实施方式，所述当前业务的下一个业务环节的参与者可以包括多个，当参与者有多个的时候，根据业务规则过滤出一个或多个参与者，将最终得到的参与者信息。

本实施例的信息系统是指通过工作流引擎，根据业务规则，有效地把业务流程上各个环节的资源整合起来，使文档、信息或任务在不同的参与者之间进行传递与执行，实现各应用的业务逻辑。

在上述步骤S204中基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述调用的相应的业务模块测试脚本，生成测试报告。

作为一种可选地实施方式，当前环节测试脚本输数据执行完成时，也许业务数据已经发生了变化，后续环节已更新。所以测试脚本在执行下一个环节之前，会实时查询下一个环节及参与者信息。

根据实时业务还原的测试情况生成最终测试报告，由于测试脚本在执行过程中，能适应信息系统，动态调用业务测试模块中的具体某一项业务的业务模块测试脚本。除了原定的测试目标外，还会产生额外的测试覆盖。最终测试脚本会根据本次测试用例中已完成的一系列业务测试模块的断言结果，对比是否实现了所述预设测试用例的测试目标，生成测试结果报告。

作为本实施例中的优选，如图5所示，所述基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成，包括：基于所述信息系统的业务流程测试，按照业务参与者或者业务场景进行业务分割之后，得到所述业务模块，用以形成所述业务模块测试脚本；根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节、当前业务的下一个业务环节的参与者，包括：在执行业务验证的自动化测试脚本时，通过系统的API接口和/或UI界面上提供的查询接口，按照所述测试业务流程的所述唯一标识信息从业务系统查询还原出所述业务流程的实时状态。

具体实施时，基于业务参与者及业务场景对业务进行分割。通过分析测试用例，以业务流程从开始到结束为顺序，对业务中的每个操作以业务参与者、业务场景两个因素进行标注。

作为本实施例中的优选，所述基于预设测试用例提交业务测试数据之前，还包括：基于预设测试用例以业务流程从开始到结束的预设顺序，对业务中的每个操作以业务参与者、业务场景两个因素进行标注；所述业务流程以第一个操作为{0,0}开始，如果操作业务的参与者改变，且业务场景不变，则标注为{1,0}；如果操作业务参与者不变化，且业务场景发生变化，则标注为{0,1}；如果操作业务参与者、所述业务场景两者都不发生变化，则标注为{0,0}；如果操作业务参与者、所述业务场景两者均发生变化，则标注为{1,1}。

举例来说，业务流程以第一个操作为{0,0}开始。之后的业务操作遵循如下原则标注：如果操作业务参与者改变，业务场景不变，则标注为{1,0}；如果操作业务参与者不变化，业务场景发生变化，则标注为{0,1}；二者都不发生变化，则标注为{0,0}；二者均发生变化，则标注为{1,1}。

作为本实施例中的优选，所述基于预设测试用例以业务流程从开始到结束的预设顺序，对业务中的每个操作以业务参与者、业务场景两个因素进行标注之后，还包括：在根据所述操作业务参与者的变化为基准对业务进行分割的情况下，在所述操作业务参与者发生变化即标注结果为{1,*}的情况下，对所述业务进行分割；在根据所述业务场景的变化为基准对业务进行分割的情况下，在所述操作业务场景发生变化即标注结果为{*,1}的情况下，对所述业务进行分割；在根据所述业务参与者或者业务场景的变化为基准对业务进行细颗粒度分割的情况下，即标注结果为非{0,0}的情况下，对所述业务进行分割。

此外，至于采用上述哪种分割方式，则是根据实际测试需要以及业务系统提供的还原能力以及还原颗粒度确定的。

以图5为例，一组以业务操作顺序的标注。如果以业务参与者改变为基准对业务进行分割，将会得到图中组一的业务分割分组：①②，③④，⑤⑥，⑦。如果以业务参与者改变或者业务场景改变为基准进行细颗粒度分割，将会得到图5中组二的业务分割分组：①，②，③，④，⑤⑥，⑦。根据此原则能划分出清晰的业务边界，提取出参与者与业务场景特征。

根据测试需要及信息系统提供的业务流程还原能力，选择一种适合的分割准则。

不论是API测试还是UI测试，都可以遵循此原则对业务进行分割。针对分割后的业务模块，形成了业务模块的测试脚本，这些脚本组合形成业务测试模块。

本实施例中，在以工作流引擎为流程支撑的信息系统，主要以业务参与者变化作为业务流程上环节的转换。在实施例中，以业务参与者为基准进行业务分割，即可认为是按照工作流各个环节进行业务分割。将参与者，业务特征等信息作为参数提炼出来。自动化测试脚本运行时，由控制模块根据测试脚本及实时业务数据，进行参数传递。

作为本实施例中的优选，所述根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，还包括：通过所述系统的API接口按照所述测试业务流程从业务系统查询还原出所述业务流程的当前业务的下一个业务环节、当前业务的下一个业务环节的参与者。

具体实施时，在信息数据系统中，一个业务流程实例从开始到结束，都有一个唯一标识贯穿始终，这个标识可能是业务单据号，也可能是流程实例ID。

在测试脚本中，利用这个业务流程实例的唯一标识，从系统提供的API或者UI上，查询出该业务流程的实时状态。API查询方法，测试脚本传入提交的业务单据号、业务数据等信息，发送HTTP请求，通过RESTfulAPI返回的信息查询出后续环节的种类及参与者信息，将取得信息放入控制模块。UI查询方法，UI测试脚本在系统的UI界面提供的业务流程实时显示界面或者流程校验界面，传入提交的业务单据号、业务数据等信息查询验证，通过在网页上定位页面环节相关页面元素，提取出页面显示的后续环节的种类及参与者信息，将取得信息放入控制模块。

作为本实施例中的优选，所述根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，还包括：通过所述UI界面按照所述测试业务流程从业务系统查询还原出所述业务流程的当前业务的下一个业务环节、当前业务的下一个业务环节的参与者。

作为本实施例中的优选，所述根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，还包括：在所述业务环节的参与者包括多个的情况下，根据预设业务规则过滤出一个或多个参与者，并将所述一个或多个参与者信息从测试系统配置文件中至少匹配出所述参与者的登录账号信息。

具体实施时，将API或者UI得到的参与者信息，通过配置文件等手段或者其他手段转换成信息系统的参与者登录信息，将参与者登录信息放入控制模块。当参与者有多个的时候，根据业务规则过滤出一个或多个参与者，将最终得到的参与者信息，从配置文件中匹配出所有的参与者登录账号等信息，将参与者登录信息依次写入控制模块。

在API自动化测试中，查询模块支持API查询方法。根据采用的测试工具，调用RESTfulAPI命令查询环节信息。分析HTTP返回信息的JSON报文，利用JSON提取器等手段，得到环节相关信息，放入控制模块保存。在UI自动化测试中，查询模块既支持API查询方法又支持UI查询方法。如果使用API查询方法，需要UI测试脚本嵌入API发送接收工具。

优选地，本实施例中采用Nightwatch作为UI测试脚本的开发语言，它是用Node.js编写的。在测试脚本中引用基于原生ES6 Promise的HTTP库Axios，利用它发送RESTful API命令查询环节信息。在UI查询方法中，利用Nightwatch提供的getText等方法，传入UI中环节信息元素的位置作为参数，在该方法的回调函数callBack()中，得到该元素显示的文本即环节信息，将环节信息写入控制模块。

举例说明，比如测试财务应用的报销业务，测试脚本以申请人张三身份提交报销表单后，在查询模块取出显示了下一个环节是部门负责人李四审批，通过配置文件，查出李四的系统登录账号和密码，将此环节信息，部门负责人审批，及参与者李四登录信息放入控制模块。

作为本实施例中的优选，所述根据所述当前业务的下一个业务环节、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据包括：判断所述当前业务是否是结束环节；如果判断所述当前业务是结束环节，则根据查询还原出的环节信息调用相应的业务模块测试脚本，其中所述查询还原出的环节信息通过一次性查询获得或者在每一次的业务环节结束之后实时查询获得。

具体实施时，判断所述当前业务是否是结束环节；如果判断所述当前业务不是结束环节，则根据查询还原出的环节信息调用相应的业务模块测试脚本。

此外，所述查询还原出的环节信息通过一次性查询获得即不用每次业务环节结束后都去查询模块查询，而是在业务数据提交后，一次性查询，将整个流程环节的每个环节信息及参与者一次性写入控制模块。可以适用于当业务数据提交后，业务流程就固定下来的情况。

此外，当环节测试脚本执行完成时，也许业务数据已经发生了变化，后续环节已更新。所以测试脚本在执行下一个环节之前，通过查询模块实时查询下一个环节及参与者信息。

作为本实施例中的优选，所述基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告，包括：基于测试脚本不断重复所述根据所述当前业务的下一个业务环节、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试；根据所述测试脚本执行过程中实际调用的各业务测试流程的汇总结果，对比是否实现了所述预设测试用例的测试目标，生成所述测试报告。

具体实施时，基于测试脚本不断重复所述根据所述当前业务的下一个业务环节以及所述当前业务的下一个业务环节的参与者，从而能够调用相应的业务模块测试脚本数据以及所述基于所述相应的业务模块测试脚本数据。通过调用业务模块测试脚本数据还原整个业务流程。进一步，根据所述测试脚本执行过程中实际调用的各业务测试流程的汇总结果，对比是否实现了所述预设测试用例的测试目标，生成所述测试报告。通过不断重复上述步骤，测试脚本可实现对整个业务流程的完整还原，并在这个过程中验证业务数据及操作。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例二

根据本申请实施例，还提供了一种用于实施上述方法的基于业务分割还原的自适应测试装置，如图3所示，该装置包括：

提交模块301，用于基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成；

查询模块302，用于根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节信息、当前业务的下一个业务环节的参与者；

控制模块303，用于根据所述当前业务的下一个业务环节信息、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据；

测试模块304，用于基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告。

本申请实施例中的提交模块301中会基于预设测试用例提交业务测试数据。

根据测试业务流程是按照预先经过业务分割的业务模块组成的原则能划分出清晰的业务边界，考虑到当操作业务参与者发生改变或者业务场景转变，所以需要确定并提炼出操作业务参与者与业务场景的特征。从而根据所述提炼出操作业务参与者或业务场景的特征划分出清晰的业务边界。不论是API测试还是UI测试，都可以遵循此原则对业务进行分割。针对分割后的业务模块，形成业务模块测试脚本。

本实施例中，在以工作流引擎为流程支撑的信息系统，主要以业务参与者变化作为业务流程上环节的转换。在实施例中，以业务参与者为基准进行业务分割，即可认为是按照工作流各个环节进行业务分割。将参与者，业务特征等信息作为参数提炼出来。自动化测试脚本运行时，由控制模块根据测试脚本及实时业务数据，进行参数传递。

作为一种可选地实施方式，所述业务测试数据提交后所有可能经过的业务流程是可以由预先经过业务分割的业务模块组成。

作为一种优选地实施方式，通过分析预设测试用例，以业务流程从开始到结束为顺序，对业务中的每个操作以业务参与者、业务场景两个因素进行标注。

本申请实施例中的查询模块302中根据上述步骤中得到的所述业务测试数据中确定的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态。

作为一种可选地实施方式，以信息系统为例，一个业务流程实例从开始到结束，都有一个唯一标识贯穿始终，这个唯一标识信息可以是业务单据号，也可以是流程实例ID。

作为一种优选地实施方式，被还原出的所述实时状态至少包括如下之一：当前业务的下一个业务环节信息、当前业务的下一个业务环节的参与者。

本申请实施例中的控制模块303中根据所述当前业务的下一个业务环节信息、所述当前业务的下一个业务环节的参与者，可以调用相应的业务模块测试脚本数据。

作为一种可选地实施方式，相应的业务模块测试脚本数据与具体的信息系统的业务数据流程相关。

作为一种优选地实施方式，所述当前业务的下一个业务环节的参与者可以包括多个，当参与者有多个的时候，根据业务规则过滤出一个或多个参与者，将最终得到的参与者信息。

本实施例的信息系统是指通过工作流引擎，根据业务规则，有效地把业务流程上各个环节的资源整合起来，使文档、信息或任务在不同的参与者之间进行传递与执行，实现各应用的业务逻辑。

本申请实施例中的测试模块304中基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述调用的相应的业务模块测试脚本，生成测试报告。

作为一种可选地实施方式，当前环节测试脚本输数据执行完成时，也许业务数据已经发生了变化，后续环节已更新。所以测试脚本在执行下一个环节之前，会实时查询下一个环节及参与者信息。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

为了更好的理解上述基于业务分割还原的自适应测试方法流程，以下结合优选实施例对上述技术方案进行解释说明，但不用于限定本发明实施例的技术方案。

本申请实施例中的方法，在执行业务验证的自动化测试脚本时，根据实时情况，对业务进行还原，通过系统的API或者UI上提供的查询接口，将业务测试脚本动态地结合起来，使测试脚本能在一定程度上，无需修改、自动适应目标测试系统。该装置增强了测试脚本的稳定性、健壮性，降低了测试脚本的维护成本。

如图4所示，是本申请实施例中基于业务分割还原的自适应测试方法的流程示意图，基于预先划分的查询模块、控制模块、相应测试脚本，以信息系统为例，实现的具体过程包括如下步骤：

步骤S1，提交表单测试模块。

测试脚本以提交人身份，填写业务数据，提交表单。比如，获得表单提交成功后的业务单号。

步骤S2，查询模块。

测试脚本调用查询模块，查询出下一个业务环节及参与者，将环节信息依次写入控制模块。

查询模块取得该业务的工作流实例里环节信息的方法分成两种，一种通过系统的API，传入提交的业务单号、业务数据等信息，发送HTTP请求，通过RESTfulAPI查询出后续环节的种类及参与者信息，将取得信息放入控制模块。

在一种可选地实施方中，通过信息系统UI界面提供的流程实时显示界面、流程仿真界面或者流程校验界面，通过定位页面环节相关元素，提取出页面显示的后续环节的种类及参与者信息，将取得信息放入控制模块。

在一种可选地实施方中，将得到的参与者信息，通过配置文件等手段或者其他手段转换成信息系统的参与者登录信息，将参与者登录信息放入控制模块。

当参与者有多个的时候，根据业务规则过滤出一个或多个参与者，将最终得到的参与者信息，从测试系统配置文件中匹配出参与者登录账号等信息，将参与者登录信息依次写入控制模块。

步骤S3，控制模块中判断业务流程是否结束，如果结束进入步骤S5。

测试脚本在控制模块里，根据下一个业务环节的相关信息，调用相应的业务模块测试脚本。

控制模块判断当前业务是否是结束环节。如果是，则生成测试结果报告，结束执行测试脚本；否则将根据查询出的环节信息调用下一个业务模块测试脚本，以参数形式传入参与者登录信息及取得的相关业务信息。

步骤S4，调用部门审批测试脚本、归口审核测试脚本、财务审核测试脚本等。

所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试。

执行业务模块测试脚本，以参与者登录信息登录，以该参与者身份执行该环节的测试脚本，验证业务数据，执行业务操作。

测试脚本不断重复S3和S4的操作，则还原了整个业务流程，完成了整个流程的业务测试，直到S3中判断该流程已经结束，调用S5生成测试报告。

从测试脚本提交业务表单开始，在每次执行下一个业务环节前，通过从API接口或Web界面取得该业务流程实例的实时信息，从中提取下一个业务环节的类型和参与者信息，根据这些信息，匹配出相应的业务测试脚本，然后用业务参与者身份执行匹配出的测试脚本中的业务操作以及业务验证，最终完成该业务端到端的业务测试。

步骤S5，生成测试报告。

根据测试脚本执行过程中，实际调用的各业务测试脚本，汇总结果，对比是否实现了所述预设测试用例的测试目标，生成最终的测试报告。

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

Claims (10)

1.一种基于业务分割还原的自适应测试方法，其特征在于，包括：

基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成；

根据所述业务测试数据中的唯一标识信息，按照从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节信息、当前业务的下一个业务环节的参与者；

根据所述当前业务的下一个业务环节信息、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据；

基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告。

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

所述基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成，包括：

基于所述信息系统的业务流程测试，按照业务参与者或者业务场景进行业务分割之后，得到所述业务模块，用以形成所述业务模块测试脚本；

根据所述业务测试数据中的唯一标识信息，按照所述测试业务流程从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节、当前业务的下一个业务环节的参与者，包括：

在执行业务验证的自动化测试脚本时，通过系统的API接口和/或UI界面上提供的查询接口，按照所述测试业务流程的所述唯一标识信息从业务系统查询还原出所述业务流程的实时状态。

3.根据权利要求2所述的方法，其特征在于，所述根据所述业务测试数据中的唯一标识信息，按照从业务系统查询还原出所述业务流程的实时状态，还包括：

通过所述系统的API接口按照所述测试业务流程从业务系统查询还原出所述业务流程的当前业务的下一个业务环节、当前业务的下一个业务环节的参与者。

4.根据权利要求2所述的方法，其特征在于，所述根据所述业务测试数据中的唯一标识信息，按照从业务系统查询还原出所述业务流程的实时状态，还包括：

通过所述UI界面按照所述测试业务流程从业务系统查询还原出所述业务流程的当前业务的下一个业务环节、当前业务的下一个业务环节的参与者。

5.根据权利要求2所述的方法，其特征在于，所述根据所述业务测试数据中的唯一标识信息，按照从业务系统查询还原出所述业务流程的实时状态，还包括：

在所述业务环节的参与者包括多个的情况下，根据预设业务规则过滤出一个或多个参与者，并将所述一个或多个参与者信息从测试系统配置文件中至少匹配出所述参与者的登录账号信息。

6.根据权利要求1所述的方法，其特征在于，所述根据所述当前业务的下一个业务环节信息、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据包括：

判断所述当前业务是否是结束环节；

如果判断所述当前业务不是结束环节，则根据查询还原出的环节信息调用相应的业务模块测试脚本，其中所述查询还原出的环节信息通过一次性查询获得或者在每一次的业务环节结束之后实时查询获得。

7.根据权利要求1或6所述的方法，其特征在于，所述基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告，包括：

基于测试脚本重复所述根据所述当前业务的下一个业务环节、所述当前业务的下一个业务环节的参与者，调用所述相应的业务模块测试脚本，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试；

根据所述测试脚本执行过程中实际调用的各业务测试流程的汇总结果，对比是否实现了所述预设测试用例的测试目标，生成所述测试报告。

8.根据权利要求1所述的方法，其特征在于，所述基于预设测试用例提交业务测试数据之前，还包括：

基于预设测试用例以业务流程从开始到结束的预设顺序，对业务中的每个操作以业务参与者、业务场景两个因素进行标注；

所述业务流程以第一个操作为{0,0}开始，如果操作业务的参与者改变，且业务场景不变，则标注为{1,0}；

如果操作业务参与者不变化，且业务场景发生变化，则标注为{0,1}；

如果操作业务参与者、所述业务场景两者都不发生变化，则标注为{0,0}；

如果操作业务参与者、所述业务场景两者均发生变化，则标注为{1,1}。

9.根据权利要求8所述的方法，其特征在于，所述基于预设测试用例以业务流程从开始到结束的预设顺序，对业务中的每个操作以业务参与者、业务场景两个因素进行标注之后，还包括：

在根据所述操作业务参与者的变化为基准对业务进行分割的情况下，在所述操作业务参与者发生变化即标注结果为{1,*}的情况下，对所述业务进行分割；

在根据所述业务场景的变化为基准对业务进行分割的情况下，在所述操作业务场景发生变化即标注结果为{*,1}的情况下，对所述业务进行分割；

在根据所述业务参与者或者业务场景的变化为基准对业务进行细颗粒度分割的情况下，即标注结果为非{0,0}的情况下，对所述业务进行分割。

10.一种基于业务分割还原的自适应测试装置，其特征在于，包括：

提交模块，用于基于预设测试用例提交业务测试数据，其中所述业务测试数据提交后所要经过的预设业务流程按照预先经过业务分割的业务模块组成；

查询模块，用于根据所述业务测试数据中的唯一标识信息，按照从业务系统查询还原出所述业务流程的实时状态，其中所述实时状态至少包括如下之一：当前业务的下一个业务环节信息、当前业务的下一个业务环节的参与者；

控制模块，用于根据所述当前业务的下一个业务环节信息、所述当前业务的下一个业务环节的参与者，调用相应的业务模块测试脚本数据；

测试模块，用于基于所述相应的业务模块测试脚本数据，以所述当前业务的下一个业务环节的参与者的身份执行所述相应的业务模块的业务操作以及业务验证，用以实现对业务模块的测试，并生成测试报告。

Images