CN114721931B - 一种数据处理方法、装置、设备及存储介质 - Google Patents

一种数据处理方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN114721931B
CN114721931B CN202110014546.2A CN202110014546A CN114721931B CN 114721931 B CN114721931 B CN 114721931B CN 202110014546 A CN202110014546 A CN 202110014546A CN 114721931 B CN114721931 B CN 114721931B
Authority
CN
China
Prior art keywords
service
path
node
case
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110014546.2A
Other languages
English (en)
Other versions
CN114721931A (zh
Inventor
徐新杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202110014546.2A priority Critical patent/CN114721931B/zh
Publication of CN114721931A publication Critical patent/CN114721931A/zh
Application granted granted Critical
Publication of CN114721931B publication Critical patent/CN114721931B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3684Test management for test design, e.g. generating new test cases
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请实施例提供一种数据处理方法、装置、设备及计算机可读存储介质。其中的方法包括:获取需求数据,并根据需求数据构建有向图,从有向图中探索得到目标用例路径,该目标用例路径是指经过有向图中的目标关键业务节点的路径,获取目标关键业务节点所使用的业务规则,该业务规则包括多个规则因子,对规则因子进行组合分析,得到目标测试用例的前置条件。可见,通过对规则因子进行组合可以较好地保证前置条件覆盖需求数据中的测试需求,通过对组合的结果进行分析可以过滤非必要的前置条件(如该前置条件的各个组成部分已被其他的前置条件包含),控制前置条件的数量,进而提高测试投入产出比例,降低测试用例的维护成本。

Description

一种数据处理方法、装置、设备及存储介质
技术领域
本发明涉及计算机技术领域,具体涉及一种数据处理方法、装置、设备及计算机可读存储介质。
背景技术
在业务开发过程中,开发人员在编写完业务的代码后往往需要对开发的业务进行测试,以确保该业务满足业务需求。在业务的实际测试过程中,通常采用测试用例来对业务进行待测试的业务进行测试。通常采用的测试方法是生成待测业务在各种前置条件下的测试用例,由于各个测试用例的前置条件不同,一个待测业务往往对应海量的测试用例。实践发现,生成的测试用例数量较多时会增加测试用例的维护成本,导致测试投入产出比较低。
发明内容
本申请实施例提供了一种数据处理方法、装置、设备及存储介质,可以提高测试投入产出比例。
一方面,本申请实施例提供了一种数据处理方法,包括:
获取需求数据,该需求数据包括被测业务的业务路径及该业务路径下的业务操作步骤;
根据需求数据构建有向图,该有向图包括业务节点和边,业务节点用于表示被测业务中的业务操作步骤,边用于表示被测业务中的业务操作步骤之间的跳转逻辑;
从有向图中探索得到目标用例路径,该目标用例路径是指经过有向图中的目标关键业务节点的路径;目标用例路径用于表示被测业务的一个业务操作序列,且目标用例路径用于生成目标测试用例;
获取目标关键业务节点所使用的业务规则,该业务规则包括多个规则因子;
对规则因子进行组合分析,得到目标测试用例的前置条件。
一方面,本申请实施例提供了一种数据处理装置,该数据处理装置包括:
获取单元,用于获取需求数据,该需求数据包括被测业务的业务路径及该业务路径下的业务操作步骤;
处理单元,用于根据需求数据构建有向图,该有向图包括业务节点和边,业务节点用于表示被测业务中的业务操作步骤,边用于表示被测业务中的业务操作步骤之间的跳转逻辑;以及用于从有向图中探索得到目标用例路径,该目标用例路径是指经过有向图中的目标关键业务节点的路径;目标用例路径用于表示被测业务的一个业务操作序列,且目标用例路径用于生成目标测试用例;
获取单元,还用于获取目标关键业务节点所使用的业务规则,该业务规则包括多个规则因子;
处理单元,还用于对规则因子进行组合分析,得到目标测试用例的前置条件。
在一种实施方式中,目标关键业务节点所使用的业务规则包括M个规则因子,M为正整数;处理单元用于,对规则因子进行组合分析,得到目标测试用例的前置条件,具体用于:
按照笛卡尔展开算法对M个规则因子进行组合,得到目标测试用例的P种前置条件;
采用结对测试法对P种前置条件进行筛选,得到目标测试用例的Q种前置条件,Q为正整数,且Q≤P;
其中,设M个规则因子中第i个规则因子包括种规则项,则P的值为/>
在一种实施方式中,被测业务包括N个业务操作步骤,有向图包括N个业务节点;处理单元用于,根据需求数据构建有向图,具体用于:
将被测业务的第i个业务操作步骤确定为有向图中的第i个业务节点,将被测业务的第j个业务操作步骤确定为有向图中的第j个业务节点;以及,
将第i个业务操作步骤与第j个业务操作步骤之间的跳转逻辑确定为有向图中第i个业务节点与第j个业务节点之间的边;
依据确定的业务节点和边构建有向图;
其中,N为大于1的整数,i、j均为正整数,并且i≤N,j≤N。
在一种实施方式中,处理单元还用于:
遍历有向图中的业务节点,得到用例路径集合,该用例路径集合中包含至少一条用例路径,每一条用例路径分别用于表示被测业务的一个业务操作序列;
其中,用例路径集合中的用例路径的类型包括主用例路径或关键用例路径。
在一种实施方式中,业务路径包括基本业务路径,该基本业务路径下包含N个业务操作步骤;N为正整数;有向图还包括起始节点和结束节点;处理单元用于,遍历有向图中的业务节点,得到用例路径集合,具体用于:
从起始节点开始,按照基本业务路径下的N个业务操作步骤的执行顺序,依次遍历有向图中的N个业务节点,直至结束节点停止;N个业务节点与基本业务路径下的N个业务操作步骤一一对应;
将穿过起始节点、N个业务节点以及结束节点的遍历路径确定为主用例路径。
在一种实施方式中,有向图还包括起始节点和结束节点;处理单元用于,从有向图中探索得到目标用例路径,具体用于:
在有向图中确定目标关键业务节点;
采用最短路径图遍历算法在有向图中遍历查找起始节点与目标关键业务节点之间的第一路径;以及,在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径;
将第一路径与第二路径拼接形成的路径确定为目标用例路径。
在一种实施方式中,处理单元用于,在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径,具体用于:
若目标关键业务节点的类型为第一类型,则在有向图中探索得到主用例路径,沿结束节点的方向在有向图中探索从目标关键业务节点返回至主用例路径,并沿主用例路径到达结束节点的第二路径;或者,
若目标关键业务节点的类型为第一类型,采用最短路径图遍历算法在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径;或者,
若目标关键业务节点的类型为第二类型,则将目标关键业务节点与结束节点相连接形成的路径确定为第二路径;
其中,若目标关键业务节点用于表示由被测业务向被测业务中的用户提供交互界面的业务操作步骤,则目标关键业务节点的类型为第一类型;若目标关键业务节点用于表示由用户在交互界面中产生交互行为,并由被测业务对交互行为进行感知反馈的业务操作步骤,则目标关键业务节点的类型为第二类型。
在一种实施方式中,用例路径集合包括第一用例路径集合和第二用例路径集合,第一用例路径集合和第二用例路径集合中均包含一条或多条用例路径,其中,第一用例路径集合中的用例路径用于生成验证业务操作行为的测试用例,第二用例路径集合中的用例路径用于生成验证业务规则的测试用例;处理单元还用于:
对第一用例路径集合和第二用例路径集合进行优化处理。
在一种实施方式中,处理单元用于,对第一用例路径集合和第二用例路径集合进行优化处理,具体用于:
若第一用例路径集合与第二用例路径集合包含相同的用例路径,则在第二用例路径集合中删除相同的用例路径。
在一种实施方式中,处理单元用于,获取需求数据,具体用于:
获取需求描述文档,需求描述文档用于描述被测业务的业务操作流程,且需求描述文档为第一格式的文档;
对需求描述文档进行解析,得到需求数据,需求数据为第二格式的数据。
在一种实施方式中,处理单元还用于:
从目标用例路径中提取目标用例步骤;
根据前置条件和目标用例步骤生成目标测试用例;
采用目标测试用例对被测业务执行测试,得到测试结果。
一方面,本申请提供了一种数据处理设备,该设备包括:
处理器,用于加载并执行计算机程序;
计算机可读存储介质,该计算机可读存储介质中存储有计算机程序,该计算机程序被处理器执行时,实现上述数据处理方法。
一方面,本申请提供了一种计算机可读存储介质,计算机可读存储介质存储有计算机程序,该计算机程序适于由处理器加载并执行上述数据处理方法。
一方面,本申请提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述数据处理方法。
本申请实施例中,获取需求数据,并根据需求数据构建有向图,从有向图中探索得到目标用例路径,该目标用例路径是指经过有向图中的目标关键业务节点的路径,获取目标关键业务节点所使用的业务规则,该业务规则包括多个规则因子,对规则因子进行组合分析,得到目标测试用例的前置条件。可见,通过对规则因子进行组合可以较好地保证前置条件覆盖需求数据中的测试需求,通过对组合的结果进行分析可以过滤非必要的前置条件(如该前置条件的各个组成部分已被其他的前置条件包含),控制前置条件的数量,进而提高测试投入产出比例,降低测试用例的维护成本。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1示出了本申请一个示例性实施例提供的一种系统用例的示意图;
图2a示出了本申请一个示例性实施例提供的一种数据处理系统的架构示意图;
图2b示出了本申请一个示例性实施例提供的一种数据处理逻辑关系示意图;
图2c示出了本申请一个示例性实施例提供的一种数据处理的时序图;
图3a示出了本申请一个示例性实施例提供的一种上传需求描述文档的界面示意图;
图3b示出了本申请一个示例性实施例提供的一种查看需求描述文档的处理流程的示意图;
图3c示出了本申请一个示例性实施例提供的一种查阅业务路径步骤的界面示意图;
图3d示出了本申请一个示例性实施例提供的一种查阅补充约束的界面示意图;
图3e示出了本申请一个示例性实施例提供的一种修改需求描述文档的界面示意图;
图4示出了本申请一个示例性实施例提供的一种测试用例的示意图;
图5示出了本申请一个示例性实施例提供的一种数据处理方法的流程示意图;
图6示出了本申请一个示例性实施例提供的另一种数据处理方法的流程示意图;
图7a示出了本申请一个示例性实施例提供的一种有向图;
图7b示出了本申请一个示例性实施例提供的另一种有向图;
图7c示出了本申请一个示例性实施例提供的一种确定用例路径集合的流程图;
图8示出了本申请一个示例性实施例提供的一种业务规则表的示意图;
图9示出了本申请一个示例性实施例提供的一种引用规则因子的示意图;
图10示出了本申请一个示例性实施例提供的一种数据处理装置的结构示意图;
图11示出了本申请一个示例性实施例提供的一种数据处理设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请实施例涉及软件测试(Software Testing),软件测试是软件开发过程中的一个重要的组成部分,是贯穿整个软件开发生命周期、对软件产品(包括阶段性产品)进行验证和确认的活动过程,其目的是尽快尽早地发现在软件产品中所存在的各种问题,例如软件产品与用户需求不一致的问题、软件产品的功能与预先定义的功能不一致的问题等等。通过对软件产品进行测试,能够及时发现软件产品中存在的问题,以便于开发人员对软件产品进行优化。其中,软件产品是指向用户提供的计算机软件、信息系统或设备中嵌入的软件或在提供计算机信息系统集成、应用服务等技术服务时提供的计算机软件等等。其中,测试用例(Test Case)是软件测试过程中不可或缺的重要组成部分。所谓测试用例是指对一项特定的软件产品进行测试任务的描述。测试用例可以体现测试方案、方法、技术和策略。采用测试用例对软件产品进行测试,可检验软件产品是否满足客户需求,因而一个软件产品往往对应海量的测试用例,各测试用例的测试任务相同或不同。
MBT(Model Based Testing,基于模型的测试)是属于软件测试领域的一种测试方法,基于MBT思想的软件测试过程大致可以包括以下四个步骤:①获取业务系统中被测业务的业务需求,此处的业务系统是指为用户提供各类互联网业务的系统,包括但不限于:支付业务系统、即时通讯业务系统、内容社交业务系统等等。被测业务可以是业务系统本身(例如某个支付业务系统本身是一个支付类的软件产品),也可以是业务系统中的任一个功能业务(例如某个即时通讯业务系统同时支持支付、即时通讯、电子地图等多种互联网业务,被测业务可以是其中的任一种功能业务)。业务需求可以采用需求描述文档来描述,需求描述文档往往是根据被测业务的业务需求编写的,需求描述文档通常是关于被测业务的功能方面的描述。②建模人员对需求描述文档中的业务需求进行高度抽象,通过UML图例、建模工具脚本等构建需求模型。③在需求模型的基础上,测试人员根据需求模型编写相应的测试用例。④通过测试用例对业务系统中的被测业务进行测试。
其中,测试用例(Test Case)可以是指对一项特定的软件产品(例如可以是一个新开发的业务系统)进行测试任务的描述,体现测试方案、测试方法、测试技术和测试策略;测试用例可以包括测试目标、测试环境、输入数据、用例步骤、预期结果、测试脚本等等。换句话说,测试用例是为某个特殊目标(例如,测试业务的某种功能)而编制的一组测试输入、执行条件以及预期结果,用于核实业务系统中的被测业务是否满足业务需求。
需要说明的是,在软件测试场景中,根据被测业务的需求描述文档生成测试用例时,涉及的最主要数据包括:基本业务路径、扩展业务路径、前置条件、后置条件以及补充约束,这些数据是对被测业务的需求描述文档进行处理得到的,这些数据组成被测业务的系统用例。其中,组成系统用例的各部分数据之间的关系示意图可参见图1,图1示出了本申请一个示例性实施例提供的一种系统用例的示意图;如图1所示,系统用例主要包括:执行者、涉众利益、业务路径(包括基本业务路径、扩展业务路径)、前置条件、后置条件以及补充约束等等。其中,执行者包括主执行者和辅助执行者,例如,在支付测试场景中,主执行者可以是指已注册相关支付信息的用户,辅助执行者可以是指用于付款的银行系统。涉众利益是指与被测业务相关联的多方用户,这些用户可能与被测业务之间存在利益关系,分析各用户之间的利益关系对于生成测试用例具有指导性作用。前置条件是指触发开始执行测试用例的条件,若同一业务路径引用不同的前置条件,则可生成不同的测试用例。后置条件规定了测试用例的执行结果应该满足的条件,即后置条件可以对测试用例的执行结果进行校验。业务路径存在多个业务操作步骤,各业务操作步骤按照业务操作流程形成业务路径,其中,当把业务操作步骤理解为一个业务节点时,路径由多个节点组成;每一业务路径可生成一个测试用例。业务路径下的基本业务路径是指被测业务的基础业务操作步骤之间相连形成的路径。以及,业务路径下的扩展业务路径是指被测业务的扩展业务操作步骤之间相连形成的路径,扩展路径能够提供更多的测试场景。
基于上述描述可知,除了基于业务路径生成各业务功能对应的测试用例以外,由于被测业务还涉及多种前置条件,当某一路径包含多种前置条件时,可以生成该路径对应的各前置条件关联的测试用例,以满足被测业务的测试需求。
但实践发现,对被测业务的所有前置条件进行展开生成测试用例时,测试产出投入比例较高,实用性较低。基于此发现,本申请实施例提供一种数据处理方案,
该数据处理方案能够获取目标关键业务节点(即目标用例路径所穿过的业务节点)所使用的业务规则,该业务规则包括多个规则因子,对业务因子进行组合分析,得到目标用例的前置条件。上述过程中,通过组合得到P种不同的规则因子组合(即P种前置条件),并对P种前置条件进行分析,得到目标测试用例的Q种前置条件,P,Q均为正整数,且Q≤P。可见,通过对规则因子进行组合分析,可以较好地保证前置条件覆盖需求数据中的需求,并控制前置条件的数量,进而提高测试投入产出比例,降低测试用例的维护成本。
上述描述的用于生成测试用例的数据处理方案可应用于数据处理系统。数据处理系统可参见图2a,图2a示出了本申请一个示例性实施例提供的一种数据处理系统的架构示意图,该数据处理系统包括终端201和服务器202,本申请实施例对终端201和服务器的数量不作限定。其中,终端201可以是指用来接收需求描述文档以及展现需求数据、执行结果等数据的设备。终端可以包括但不限于:PC(Personal Computer,个人计算机)、PDA(平板电脑)、手机、可穿戴智能设备等等;终端往往配置有显示装置,显示装置也可为显示器、显示屏、触摸屏等等,触摸屏也可为触控屏、触控面板等等。服务器可以为终端提供计算和应用服务支持。服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端和服务器之间可以通过有线通信或者无线通信方式进行直接或间接地连接,本申请在此不做限制。
用例生成系统的数据处理架构可参见图2b,图2b示出了本申请一个示例性实施例提供的一种数据处理逻辑关系示意图,用例生成系统中的各模块之间进行数据交互以实现生成目标测试用例的过程可简要地描述为:首先,用户的终端201向需求管理模块2021输入被测业务的业务需求(或需求描述文档),需求管理模块2021可以对业务需求进行结构化处理(如将业务需求转换为用例图),得到需求数据;其次,特征管理模块2022从需求管理模块2021中提取需求描述文档的语料信息,并对语料信息进行特征化(如关键词提取)和分类处理(即对不同的特征按照划分规则进行分类)。所谓需求描述文档是用于描述被测业务的业务操作流程、且为第一格式的文档;第一格式的文档是指用自然语言描述的文档,该文档可以是以DOCX格式为格式的文档。所谓需求数据是对需求描述文档进行解析得到的、为第二格式的数据;第二格式的文档是指用计算机语言描述的文档,第二格式可以是指json(JavaScript Object Notation,JS对象简谱)格式,是一种轻量级的数据交换格式。最后,用例生成模块2023基于从需求管理模块2021和特征管理模块2022读取的数据(即需求数据、语料分类信息和冲突语料信息)生成被测业务的目标测试用例。需要说明的是,需求管理模块2021,特征管理模块2022和用例生成模块2023可以分别独立部署于不同的服务器中,也可以是部署于同一个服务器中,本申请实施例对此不作限制。在一种实现方式中,该用例生成系统可以部署在服务器202,由服务器202为用例生成系统提供软硬件环境,其中,硬件环境参数可包括但不限于服务器机型、内存、中央处理器、硬盘等等;软件参数可包括但不限于操作系统、数据库、Web服务器、编程语言、开源软件等等。上述硬件环境参数以及软件环境参数仅用于示例,实际应用场景中,用例生成系统部署的硬件环境参数和软件环境参数还可以为其他情况,本申请实施例对此不做限定。
终端201和服务器202按照B/S(Browser/Server)的模式进行架构,即浏览器—服务器架构模式。采用这种架构模式使得只需要在终端上运行浏览器以及在服务器部署数据库,就可以让浏览器与数据库之间进行数据交互。这能够使得业务的开发、测试和维护变得更加便捷。下面对服务器202中的各个模块进行较为详细的介绍,其中:
一、需求管理模块。需求管理模块用于将通过自然语言描述的需求文档转换为计算机语言描述的需求数据。在生成测试用例的场景中,需求管理模块2021支持通过浏览器接收业务人员上传的被测业务的需求描述文档,测试数据可以是指业务人员上传的第一格式的文本文档,也可以是指业务人员在浏览器提供的需求管理界面中配置的、生成测试用例的数据文档。其中,需求管理界面可以按照UML用例规约进行设计,业务人员在需求管理界面中配置时按照UML用例规范编写数据。UML是一种建模语言,通常是指用模型元素来组建整个系统的模型,模型元素包括系统中的类、类和类之间的关联类的实例相互配合实现系统的动态行为等。
需求管理模块2021在获取需求描述文档后,将第一格式的文本文档或者数据文档转换为第二格式的需求数据,并提供对这些需求数据的增删改查功能。下面结合需求管理模块2021的数据处理时序图来对上述描述的增删改查功能进行较为详细的阐述。请参见图2c,图2c示出了本申请一个示例性实施例提供的一种数据处理的时序图;如图2c所示,数据处理时序包括三个数据处理周期,分别为:新增数据周期、查阅数据周期以及修改数据周期。其中,在新增数据周期内,业务人员可上传被测业务的需求内容;在查阅数据周期内,业务人员可对上传的被测业务的需求内容进行查看;在修改数据周期内,业务人员可对上传的被测业务的需求内容进行修改、删除等操作。此处的需求内容可以是指前述描述的需求数据、需求描述文档。
1)数据处理时序为新增数据周期。在新增数据周期内,业务人员上传需求描述文档的界面示意图可参见图3a,图3a示出了本申请一个示例性实施例提供的一种上传需求描述文档的界面示意图;如图3a所示,在服务界面中显示有需求描述文档的上传入口301;当上传入口301被触发时,显示文档选取页面,并从文档选取页面中选取需求描述文档;当服务界面中的确认选项302被选中时,表示上传当前选取的需求描述文档,则将需求描述文档从浏览器上传至需求管理模块2021,并在服务界面中显示上传进度(如上传50%、上传100%......)。相应的,后台实现新增需求描述文档的流程可包括但不限于:s11,业务人员将自然语言描述的需求描述文档通过浏览器上传至需求管理模块2021的逻辑层;逻辑层对需求描述文档进行解析以得到json格式描述的需求数据。s12,逻辑层将处理得到的需求数据的语料信息上传至特征库数据系统,并接收特征库数据系统返回的上传结果(如上传成功);以及,逻辑层还将需求数据发送至处理层,以便于处理层将需求数据发送至数据库进行录入(即存储)。s13,逻辑层接收处理层返回的录入结果,并将录入结果返回给浏览器进行显示,以便于业务人员确认录入结果。另外,当上传需求描述文档之后,可对需求描述文档的处理流程进行查看,例如:查看需求描述文档的合法性等。请参见图3b,图3b示出了本申请一个示例性实施例提供的一种查看需求描述文档的处理流程的示意图;如图3b所示,业务人员通过触发“上一步”标识303或“下一步”标识304可对新增需求描述文档的各个处理步骤进行查看。
2)数据处理时序为查阅数据周期。在查阅数据周期内,业务人员查阅需求描述文档的界面示意图可参见图3c和图3d,图3c示出了本申请一个示例性实施例提供的一种查阅业务路径步骤的界面示意图;图3d示出了本申请一个示例性实施例提供的一种查阅补充约束的界面示意图;如图所示,在服务界面中显示被测业务对应的系统用例(可参见前述对系统用例的描述),在服务界面中显示有涉众利益选项、前置条件选项、后置条件选项、业务路径步骤选项以及补充约束选项等等;当用户选中任意选项时,服务界面显示被选中的选项对应的内容,以满足用户查阅被测业务的多种业务内容的需求。例如:选中路径步骤选项时,在服务界面中显示基本业务路径和扩展业务路径。相应的,后台响应查阅需求描述文档的流程可包括但不限于:业务人员通过浏览器发起查询请求;需求管理系统的逻辑层响应查询请求,并向处理层发送数据获取请求;处理层从数据库中获取数据,并将数据返回给逻辑层;逻辑层将数据发送至浏览器,以便于浏览器显示数据。这能帮助业务人员对上传的需求描述文档的数据进行确定,使得系统在正确的需求数据的基础之上执行后续的生成测试用例的步骤,提高测试用例的正确性和完整性。
3)数据处理时序为修改数据周期。在修改数据周期内,业务人员修改需求描述文档的界面示意图可参见图3e,图3e示出了本申请一个示例性实施例提供的一种修改需求描述文档的界面示意图;如图3e所示,在服务界面中显示有修改选项305,且当前服务界面中显示有补充约束选项下业务规则的信息;当用户存在对业务规则的修改需求时,用户可选中修改选项305,此时服务界面中业务规则所在区域306为可编辑状态,用户在可编辑状态下支持用户对业务规则进行编辑。相应的,后台响应修改需求描述文档的流程可包括但不限于:接收业务人员通过浏览器发起修改请求,修改请求中携带修改数据;需求管理系统的逻辑层响应修改请求,并向特征管理模块上传修改数据;特征管理模块向逻辑层返回修改数据的上传结果;逻辑层还向处理层发送修改请求,以便于处理层能够对数据库中存储的历史数据进行更新(包括:数据更新、删除以及新增);逻辑层接收处理层返回的更新结果,并将更新结果返回给网页浏览器,以便于业务人员能够确认本次修改操作是否成功,例如:当更新结果为更新失败时,业务人员可再次执行编辑操作,直至更新结果显示为更新成功。这能帮助业务人员便捷地完善业务数据,丰富业务需求。
综上所述,需求管理模块在接收到第一格式的需求描述文档之后,还可以接收对该需求描述文档的查阅、修改等操作,并基于最终确定的需求描述文档生成第二格式(即json格式)的需求数据。以被测业务为支付业务为例,简要给出一种对被测业务的需求描述文档进行解析处理,得到第二格式的需求数据的实现方式:
{
"code" : ,
"msg": "ok",
"data":{
"targetsystem": "支付系统" , //被测业务
"targetsystemid": 3, //被测业务标识
"caseclass": "支付系统-XX收款", //用例类
"caseid" :"1" //用例标识
"casever": "97",
"branchid": "1", //分支编号
"branchtype": "1", //分支类型
"casename": "收款", //用例名称
"mainactor": { //主执行者
"mainactorid": 9, //主执行者标识
"mainactorname": "直连商户的系统" //主执行者名称
},
"assitactor": [ … ],//辅助执行者
"precondition": [], //前置条件
"postcondition": [ …],//后置条件
"procedure": [ … ], //基本业务路径
"expand": [ ... ], //扩展业务路径
"round":[ ...],
"constraint": { … } //补充约束
}
}
通过json格式表示需求数据,能够较好地描述需求数据中各个数据(即前置条件、后置条件、执行者、业务路径以及业务路径下的业务操作步骤等等)之间的结构化关系。
二、特征管理模块。特征管理模块用于辅助需求管理模块将自然语言描述的需求描述文档转换为计算机语言描述的需求数据;此外,特征管理模块还用于对需求描述文档进行冲突校验,以确保需求描述文档的可行性。特征管理模块可以从需求管理模块2021中提取需求描述文档的语料信息,并对语料信息进行特征处理和冲突处理。其中,所谓特征处理可以理解为将语料信息进行特征化处理,经过特征化后的语料被打上分类标签,以便于为每一类别的语料信息分配不同的实现方式(如分配接口)。所谓冲突处理可以理解为分析语料信息之间的关系,将矛盾的、重复的语料信息打上冲突标签,以便于后续处理语料信息时,将这些冲突的语料信息进行过滤。特征管理模块处理后的数据可作为生成测试用例的参考素材。
三、用例生成模块。用例生成模块用于对需求数据进行分析处理,进而生成测试用例,具体的实施方式可参考方法实施例中的描述。用例生成模块通过从需求管理模块2021和特征管理模块2022中提取被测业务的数据,来生成测试用例。正如前述所描述的,用于生成测试用例的最主要数据包括:基本业务路径、扩展路径、前置条件、后置条件以及补充约束。其中,基本业务路径和扩展业务路径下会有业务路径关联的补充约束,补充约束包括字段列表、业务规则、非功能需求以及设计约束等,这些内容大多以表格形式进行展示。例如,根据被测业务的业务路径下的业务操作步骤的类型以及补充约束的类型可以将展示的表格分为三类,具体可参见表1。
表 1
如表1所示,业务规则类型可以包括系统校验类型、系统处理类型以及系统反馈类型,每一种业务规则类型对应有多种业务规则表格类型。表1中业务规则类型也可以作为扩展业务路径下的各个业务操作步骤的步骤类型。
综上所述,通过用例生成系统中各设备的处理,可生成被测业务的测试用例,测试用例可以以excel的形式进行展现,方便用户查看。其中,excel表的表头分别为:用例类型、自动化、用例名、前置条件、用例步骤及预期结果。以被测业务为支付业务为例,给出一种测试用例的excel的展现形式,可参见图4。图4示出了本申请一个示例性实施例提供的一种测试用例的示意图;如图4所示,excel的每一行代表一种测试用例,被测业务可对应多种测试用例这样提高测试用例的可读性。
本申请实施例中,需求管理模块可以对被测业务的需求描述文档进行解析,得到被测业务的需求数据。特征管理模块可以对需求描述文档中采用自然语言描述的业务需求步骤进行特征化处理,提取需求描述文档中特征数据(例如可以是业务操作步骤的类型、业务操作步骤的构造方式以及业务操作步骤的冲突语料)。用例生成模块可以根据被测业务的需求数据自动生成被测业务的测试用例的前置条件,该测试用例的前置条件是根据规则因子进行组合分析得到的,该测试用例的前置条件用于与目标用例路径进行组合得到测试用例。本申请实施例实现了从自然语言描述的需求描述文档到用例步骤的自动生成过程,相比于传统的MBT建模方式而言,不仅降低了对建模人员抽象思维的要求,还降低了建模成本。
下面结合附图,对本申请实施例提供的数据处理方案进行详细介绍。
请参见图5,图5示出了本申请一个示例性实施例提供的一种数据处理方法的流程示意图。该数据处理方案可由上述描述的服务器202来执行;该方案包括步骤S501-S505,其中:
S501、服务器获取需求数据。
需求数据包括被测业务的一条或多条业务路径,每条业务路径包括至少一个完成该业务所需要执行的业务操作步骤;业务路径用于指示各个业务操作步骤的执行顺序,以及业务操作步骤之间的跳转逻辑;例如,在转账时需要先输入转账金额,再进行密码验证,因此转账业务的业务路径包括“输入金额”和“身份验证”两个业务操作步骤,业务路径用于指示在完成“输入金额”后,进行“身份验证”,即执行完“输入金额”的操作步骤后,跳转至“身份验证”的操作步骤,在执行“身份验证”的操作步骤之前需要执行“输入金额”的操作步骤。其中,被测业务是由一条或多条计算机代码组成的集合;例如,被测业务可以是一个软件,也可以是一个应用子程序。
S502、服务器根据需求数据构建有向图。
有向图是由有向边和节点组成的、用于描述被测业务的业务操作流程的一种图。为了更好地理解有向图的概念,下面先对有向图涉及的相关术语和概念进行介绍,参见表2:
表 2
需要说明的是,表2中业务节点类型可以是上述数据管理系统中的特征管理模块2022在对需求描述文档进行特征化时确定的,特征管理模块2022可以对需求描述文档中采用自然语言描述的业务操作步骤进行特征化处理,提取业务操作步骤中的特征,并根据提取到的特征确定业务操作步骤的类型,例如可以根据提取到的业务操作步骤的特征确定该业务操作步骤属于用户选择类型、系统校验类型、系统处理类型或系统反馈类型中的一种。
在本申请实施例中,有向图的业务节点是根据需求数据中携带的业务操作步骤生成的,有向图中的每一个业务节点对应需求数据中的一个业务操作步骤;有向图的边是根据各个业务操作步骤之间的跳转逻辑确定的。具体地,将被测业务的第i个业务操作步骤确定为有向图中的第i个业务节点,将被测业务的第j个业务操作步骤确定为有向图中的第j个业务节点;并将第i个业务操作步骤与第j个业务操作步骤之间的跳转逻辑确定为有向图中第i个业务节点与第j个业务节点之间的边,其中,i、j均为正整数,且i,j均小于被测业务包括的业务操作步骤的数量N。例如,假设业务操作步骤A对应有向图中的业务节点A,业务操作步骤B对应有向图中的业务节点B,且业务操作步骤A与业务操作步骤B之间的跳转逻辑为:在执行完业务操作步骤A后执行业务操作步骤B,则建立业务节点A与业务节点B之间的连边,该连边的方向由业务节点A指向业务节点B。
S503、从有向图中探索得到目标用例路径。
目标用例路径是指经过有向图中的目标关键业务节点的路径。目标用例路径用于表示被测业务的一个业务操作序列,例如,未绑定银行卡的用户在使用银行卡支付业务时,需要先进行银行卡绑定,然后确定支付金额,再进行身份验证。此外,目标用例路径还用于生成目标测试用例。目标测试用例用于指示被测业务的测试方案,是为测试被测业务而编制的一组测试输入、执行条件以及预期结果,用于核实被测业务是否满足需求,目标测试用例可以包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。
在一种实施方式中,服务器首先在有向图中确定目标关键业务节点,该目标关键业务节点可以是由需求数据指定的业务节点,也可以是根据筛选规则从有向图中筛选出的业务节点。然后采用最短路径图遍历算法在有向图中遍历查找起始节点与目标关键业务节点之间的第一路径;以及,在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径;并将第一路径与第二路径拼接形成的路径确定为目标用例路径。
S504、服务器获取目标关键业务节点所使用的业务规则。
目标关键业务节点所使用的业务规则用于构成目标关键业务节点的前置条件。目标关键业务节点所使用的业务规则包括M个规则因子,每个规则因子对应目标关键业务节点的一个子条件,目标关键业务节点的前置条件是由一个或多个子条件构成的(即目标关键业务节点的前置条件是由M个规则因子中的一个或多个规则因子组合成的)。在一种实施方式中,目标关键业务节点所使用的业务规则是由需求数据指示的。
S505、服务器对规则因子进行组合分析,得到目标测试用例的前置条件。
目标测试用例的前置条件用于指示对目标用例进行测试所需的前提条件,例如,测试银行卡支付业务所需的前提条件包括:当前用户已绑定至少一张银行卡。对规则因子进行组合分析是指按照组合规则对规则因子进行组合,并对得到的组合进行分析处理(如按照用户或需求数据的指示或预设算法,对得到的组合进行筛选过滤;或者,依据各个步骤的权重等因素,分析得到具有测试价值(如权重超过阈值)的前置条件);组合规则可以是由用户指定的规则(如用户指定将规则因子进行两两组合),也可以是根据组合算法(如笛卡尔展开算法)确定的规则,还可以是对历史数据进行分析得到的规则。具体地,组合规则可以是需求数据中携带的,也可以是由当前用户指定的,还可以是由开发人员预先设置的,或者是根据历史数据分析结果生成的。
本申请实施例中,获取需求数据,并根据需求数据构建有向图,从有向图中探索得到目标用例路径,该目标用例路径是指经过有向图中的目标关键业务节点的路径,获取目标关键业务节点所使用的业务规则,该业务规则包括多个规则因子,对规则因子进行组合分析,得到目标测试用例的前置条件。可见,通过对规则因子进行组合可以较好地保证前置条件覆盖需求数据中的测试需求,通过对组合的结果进行分析可以过滤非必要的前置条件(如该前置条件的各个组成部分已被其他的前置条件包含),控制前置条件的数量,进而提高测试投入产出比例,降低测试用例的维护成本。
请参见图6,图6示出了本申请一个示例性实施例提供的另一种数据处理方法的流程示意图。该数据处理方案可由上述描述的服务器202来执行;该方案包括步骤S601-S608,其中:
S601、服务器获取需求描述文档,并对需求描述文档进行解析,得到需求数据。
步骤S601的具体实施方式可参考图2b中需求管理模块根据需求描述文档到的需求数据的实施方式,在此不再赘述。
S602、服务器根据需求数据构建有向图。
步骤S602的具体实施方式可参考图5步骤S502的实施方式,在此不再赘述。
S603、服务器遍历有向图中的业务节点,得到用例路径集合。
服务器按照有向图中各个业务节点以及各条有向边的指示对有向图进行遍历,得到用例路径集合。该用例路径集合中包含至少一条用例路径(即主用例路径),此外,用例路径集合中还可以包含一条或多条扩展路径,用例路径集合中的每一条用例路径分别用于表示被测业务的一个业务操作序列;例如,用例路径集合中,主用例路径集合用于表示支付业务的业务操作序列,扩展路径1用于表示采用银行卡支付的业务操作序列,扩展路径2用于表示采用余额支付的业务操作序列。可以理解的是,若用例路径集合中只包含一条用例路径,则该用例路径即为主用例路径;若用例路径集合中包含多条用例路径,则主用例路径是由有向图和需求数据共同确定的。
具体地,服务器从起始节点开始,按照基本业务路径下的N个业务操作步骤的执行顺序,依次遍历有向图中的N个业务节点,直至结束节点停止(N个业务节点与基本业务路径下的N个业务操作步骤一一对应),将穿过起始节点、N个业务节点以及结束节点的遍历路径确定为主用例路径;其中,基本业务路径是由需求数据指示的。图7a示出了本申请一个示例性实施例提供的一种有向图。如图7a所示,有向图中包括起始节点,业务节点A,业务节点B,业务节点C1,业务节点C21,业务节点C22,业务节点D,业务节点E和结束节点,业务节点A对应操作步骤1,业务节点B对应操作步骤2,业务节点C1对应操作步骤3,业务节点C21对应操作步骤4,业务节点C22对应操作步骤5,业务节点D对应操作步骤6,业务节点E对应操作步骤7,需求数据指示的基本路径下的操作步骤的执行顺序为:步骤1→步骤2→步骤3→步骤6→步骤7,则按照该基本业务路径下的5个业务操作步骤的执行顺序,将用例路径“起始节点→业务节点A→业务节点B→业务节点C1→业务节点D→业务节点E→结束节点”确定为主用例路径。
进一步地,服务器从有向图中探索得到目标用例路径。目标用例路径是指经过有向图中的目标关键业务节点的路径。目标用例路径用于表示被测业务的一个业务操作序列,例如,未绑定银行卡的用户在使用银行卡支付业务时,需要先进行银行卡绑定,然后确定支付金额,再进行身份验证。此外,目标用例路径还用于生成目标测试用例。目标测试用例用于指示被测业务的测试方案,是为测试被测业务而编制的一组测试输入、执行条件以及预期结果,用于核实被测业务是否满足需求,目标测试用例可以包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。
具体地,服务器在有向图中确定目标关键业务节点,该目标关键业务节点可以是由需求数据指定的业务节点,也可以是根据筛选规则从有向图中筛选出的业务节点。在一种实施方式中,目标关键业务节点包括两种类型,第一类型的目标关键业务节点用于表示由被测业务向被测业务中的用户提供交互界面的业务操作步骤;可选的,被测业务提供的交互界面中包括至少一个交互入口;例如,在支付业务中,用户触发支付业务时,支付业务向用户展示支付界面(即交互界面),支付界面中包括“银行卡支付”、“信用卡支付”、“零钱支付”等选项;其中,展示支付界面对应的业务节点为第一类型的关键业务节点,支付界面中的“银行卡支付”、“信用卡支付”、“零钱支付”等选项即为交互入口。第二类型的目标关键业务节点用于表示由用户在交互界面中产生交互行为,并由被测业务对交互行为进行感知反馈的业务操作步骤(即第二类型的关键业务节点的触发执行条件包括:该第二类型的关键业务节点关联的至少一个交互入口被触发);例如,在支付界面中,用户触发“银行卡支付”时,显示“银行卡支付”的相关信息(如银行卡卡号,密码输入栏等),其中,用户触发“银行卡支付”为交互界面中产生交互行为,显示“银行卡支付”的相关信息为被测业务对交互行为进行感知后反馈的业务操作步骤。图7b示出了本申请一个示例性实施例提供的另一种有向图。如图7b所示,假设业务节点C21为目标关键节点,起始节点与业务节点C21之间的路径包括:起始节点→业务节点A→业务节点B1→业务节点C21,以及起始节点→业务节点A→业务节点B21→业务节点B22→业务节点C21;由于起始节点→业务节点A→业务节点B1→业务节点C21包含的节点数量最少,因此将该路径确定为起始节点与业务节点C21之间的第一路径。
服务器采用最短路径图遍历算法在有向图中遍历查找起始节点与目标关键业务节点之间的第一路径。在一种实施方式中,最短路径是指两个节点之间包含的节点数量最少的路径。可选的,若两条路径或者两条以上路径包含的节点数量相同,则将各条路径中,有向边的权重之和最小的路径确定为最短路径;其中,有向边的权重可以是根据执行的次序或者需求数据确定的。在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径。
在一种实施方式中,目标关键业务节点的类型为第一类型(即目标关键业务节点用于表示由被测业务向被测业务中的用户提供交互界面的业务操作步骤),且有向图中存在从目标关键业务节点返回至主用例路径的至少一条路径;则服务器将从目标关键业务节点返回至主用例路径的最短路径,并沿主用例路径到达结束节点的路径确定为第二路径。具体地,主用例路径中存在中间节点k,中间节点k为主用例路径上的执行顺序在目标关键业务节点之后的任一业务节点,且从目标关键节点至结束节点的路径中存在至少一条路径经过该中间节点k。将从目标关键节点至中间节点k的最短路径和从中间节点k结束节点的路径确定为第二路径。
在另一种实施方式中,目标关键业务节点的类型为第一类型(即目标关键业务节点用于表示由被测业务向被测业务中的用户提供交互界面的业务操作步骤),且有向图中不存在从目标关键业务节点返回至主用例路径的路径(即主用例路径中不存在中间节点k);则服务器采用最短路径图遍历算法将有向图中从目标关键业务节点至结束节点之间的最短路径确定为第二路径。
在又一种实施方式中,目标关键业务节点的类型为第二类型(即目标关键业务节点用于表示由所述用户在所述交互界面中产生交互行为,并由所述被测业务对所述交互行为进行感知反馈的业务操作步骤),则服务器将目标关键业务节点与结束节点直接相连接形成的路径确定为第二路径。
在确定第一路径与第二路径后,服务器将第一路径与第二路径拼接形成的路径确定为目标用例路径。
在一种实施方式中,用例路径集合包括第一用例路径集合和第二用例路径集合,第一用例路径集合和第二用例路径集合中均包含一条或多条用例路径,其中,第一用例路径集合中的用例路径用于生成验证业务操作行为的测试用例,即第一用例路径集合是经过第一类型的目标关键业务节点的用例路径的集合,第二用例路径集合中的用例路径用于生成验证业务规则的测试用例,即第二用例路径集合是经过第二类型的目标关键业务节点的用例路径的集合。服务器根据优化需求,对第一用例路径集合和第二用例路径集合进行优化处理。在一种具体的优化方式中,若第一用例路径集合与第二用例路径集合包含相同的用例路径,则在第二用例路径集合中删除该相同的用例路径。
基于步骤S601-S603所描述的实施过程可得到被测业务的主用例路径和关键用例路径,基于主用例路径和关键用例路径可生成被测业务的多种测试用例。下面结合附图7c对步骤S601-S603所描述的实施过程进行总结性描述,请参见图7c,图7c示出了本申请一个示例性实施例提供的一种确定用例路径集合的流程图;如图7c所示,首先,通过分析被测业务的业务路径下的业务操作步骤和业务操作序列,构建得到有向图;其次,采用上述方法遍历得到主用例路径,以及为每个目标关键业务节点生成目标用例路径;最后,对第一用例路径集合和第二用例路径集合进行优化处理,得到优化处理后的用例路径集合。基于优化后的用例路径集合即可生成满足测试需求的多个测试用例。
S604、服务器按照笛卡尔展开算法对M个规则因子进行组合分析,得到目标测试用例的P种前置条件。
笛卡尔展开算法用于计算两个集合(X集合和Y集合)的笛卡尔积,笛卡尔积又称直积,表示为X×Y,第一个对象是X的成员而第二个对象是Y的所有可能有序对的其中一个成员。假设集合A={a, b},集合B={0, 1, 2},则X集合和Y集合的笛卡尔积(X×Y)为{(a, 0),(a, 1), (a, 2), (b, 0), (b, 1), (b, 2)}。
由前述可知,目标关键业务节点对应的目标用例路径代表着确定性的业务操作序列,如果目标关键业务节点未挂载业务规则(即目标关键业务节点未使用业务规则),那么按照该业务操作序列执行可得到确定的执行结果。例如,如果目标关键业务节点的类型为第二类型,且目标关键业务节点上未挂载业务规则,则按照模板关键业务节点对应的业务操作序列执行后,可给到用户确定的界面反馈。反之,如果目标关键业务节点上挂载有业务规则(即目标关键业务节点使用业务规则),那么即使按照该业务操作序列执行,也可得到多种可能的执行结果。这是由于目标关键业务节点上挂载的业务规则所包含的多个规则项导致的,一个规则项对应一种前置条件;当执行的规则项不同时,执行结果就可能不相同。
需要说明的是,目标关键业务节点上挂载的业务规则可以以表的形式进行呈现,即目标关键业务节点上挂载业务规则表,该业务规则表包括一列或多列的规则列,本申请实施例将规则列称为规则项。业务规则表可参见图8,图8示出了本申请一个示例性实施例提供的一种业务规则表的示意图;如图8所示,该业务规则表中包括5列规则项,代表着该业务规则表所挂载的目标关键业务节点所在的目标用例路径至少有5中前置条件,对应可生成至少5种测试用例。
另外,目标关键业务节点所关联的业务规则表的任意规则项还可以引用其他业务规则表,本申请实施例将规则项所引用的业务规则表称为规则因子。这种情况下,目标关键业务节点的前置条件的数量会跟随规则因子的数量增加,对应的测试用例的生成数量也相应增加。其中,规则项引用业务规则表的示意图可参见图9,图9示出了本申请一个示例性实施例提供的一种引用规则因子的示意图;如图9所示,目标关键业务节点上挂载的业务规则表中的规则项引用了其他多个规则因子,当规则项与一个或多个规则因子进行组合时,可得到多种前置条件。例如:规则项与规则因子A组合得到前置条件A;规则项与规则因子A和规则因子B组合得到前置条件B;等等。
在一种实施方式中,服务器获取目标关键业务节点所使用的业务规则,该业务规则包括多个规则因子,每个规则因子包括至少一个规则项,设M个规则因子中第i个规则因子包括种规则项,则P的值为/>;例如,假设目标关键节点所使用的业务规则包括4个规则因子,规则因子1包括1个规则项,规则因子2包括2个规则项,规则因子3包括3个规则项,规则因子4包括4个规则项,则服务器按照笛卡尔展开算法对4个规则因子进行组合分析,得到目标测试用例的前置条件的数量为:1/>2/>3/>4=24。
S605、服务器采用结对测试法对P种前置条件进行筛选,得到目标测试用例的Q种前置条件。
结对测试法用于确保两个规则因子间的每种规则项组合至少被测试一次,设M个规则因子中第i个规则因子包括种规则项,第j个规则因子包括/>种规则项,且第i个规则因子和第j个规则因子为M个规则因子中包含规则项的数量最多的两个规则因子,则Q的值为/>;例如,假设目标关键节点所使用的业务规则包括3个规则因子,规则因子1包括2个规则项(A,B),规则因子2包括3个规则项(O,P,Q),规则因子3包括2个规则项(X,Y),则服务器按照笛卡尔展开算法对3个规则因子进行组合分析,得到目标测试用例的前置条件的数量为:2/>3/>2=12,具体组合方式如表3所示:
表3
如表3所示,对目标关键节点所使用的业务规则中包括的3个规则因子进行展开后,可以得到12种前置条件组合。服务器采用结对测试法对12种前置条件进行筛选;例如,序号12所在行中的组合“BQY”,由于“BQ”被包含于序号11所在行中的组合“BQX”中,且“QY”被包含于序号6所在行中的组合“AQY”中,即序号12所在行中的组合“BQY”中不包含其他11种组合所没有的组合,因此删除序号12所在行。同理,按照由下至上的顺序依次检测序号11至序号1中的前置条件组合。表4为采用结对测试法对12种前置条件进行筛选后的结果:
表4
如表4所示,筛选后的前置条件组合中,任一组合中均包含有其他组合中未包含的规则项组合。例如,序号2所在行中的组合“AO”和“OY”均未被包含于其他组合中。
S606、服务器从目标用例路径中提取目标用例步骤
服务器从目标用例路径中提取目标用例步骤的具体实现方式可包括:(1)从目标用例路径表示的业务操作序列中提取一组或多组组合步骤;其中,任一组组合步骤用于表示被测业务中的用户与被测业务之间的一个界面交互行为,任一组组合步骤包括第一业务操作步骤和第二业务操作步骤,第一业务操作步骤是指由被测业务向用户提供交互界面的步骤,第二业务操作步骤是指由用户在交互界面中产生交互行为,并由被测业务对交互行为进行感知反馈的步骤。(2)将一组或多组组合步骤形成的序列确定为目标用例步骤。
下面以支付业务场景中的一个业务操作序列为例进行说明,支付业务场景中的业务操作需求如下所示:
业务操作步骤1.【被测业务】请求用户确认XX信息
业务操作步骤2b.【被测业务】验证用户反馈的结果为确认XX信息,且需要引导用户绑定银行卡
业务操作步骤2b1.【被测业务】请求用户添加银行卡
业务操作步骤2b11.【被测业务】获取银行卡卡号
业务操作步骤2b12.【被测业务】验证银行卡卡号
业务操作步骤2b13.【被测业务】请求获取银行支付授权
业务操作步骤2b14.【被测业务】验证支付权限
业务操作步骤2b15.【被测业务】进入业务操作步骤2
业务操作步骤2d.【被测业务】验证用户反馈的结果为确认XX信息,且需要引导用户实名认证
业务操作步骤2d1.【被测业务】请求用户提交实名认证信息
业务操作步骤2d2.【被测业务】验证用户反馈的结果为提交实名认证信息
业务操作步骤2d3.【被测业务】进入业务操作步骤2
业务操作步骤2.【被测业务】请求用户提交支付密码
业务操作步骤3.【被测业务】验证用户反馈的结果为提交支付密码
上述业务操作序列中,业务操作步骤后面的数字或字母表示业务操作步骤的编号,业务操作步骤的编号中不包含字母的业务操作步骤1至业务操作步骤3所形成的业务操作序列对应主用例路径。业务操作步骤2d中,由用户在交互界面中产生交互行为(即通过交互界面反馈XX信息),并由被测业务对交互行为进行感知反馈(即对反馈的XX信息的结果进行校验),由此可知,业务操作步骤2d对应的业务节点是第一类型的目标关键业务节点。由业务操作步骤1至业务操作步骤2d所形成的业务操作序列对应第一路径;由业务操作步骤2d至业务操作步骤2所形成的业务操作序列,对应从目标关键业务节点返回主用例路径的路径;由业务操作步骤2至业务操作步骤3所形成的业务操作序列,对应沿主用例路径到达结束节点的路径;即由业务操作步骤2d至业务操作步骤3所形成的业务操作序列对应第二路径。同理,业务操作步骤2b对应的业务节点是第一类型的目标关键业务节点。由业务操作步骤1至业务操作步骤2b所形成的业务操作序列对应第一路径;由业务操作步骤2b至业务操作步骤2所形成的业务操作序列,对应从目标关键业务节点返回主用例路径的路径;由业务操作步骤2至业务操作步骤3所形成的业务操作序列,对应沿主用例路径到达结束节点的路径;即由业务操作步骤2b至业务操作步骤3所形成的业务操作序列对应第二路径。
根据上述支付场景中的业务操作序列提取到的组合用例步骤如下所示:
组合步骤1.【被测业务】请求用户确认XX信息_【被测业务】验证用户反馈的结果为确认XX信息,且需要引导用户实名认证
组合步骤2.【被测业务】请求用户提交实名认证信息_【被测业务】验证用户反馈的结果为提交实名认证信息
组合步骤3.【被测业务】请求用户添加银行卡_【被测业务】验证银行卡卡号
组合步骤4.【被测业务】请求获取银行支付授权_【被测业务】验证支付权限
组合步骤5.【被测业务】请求用户提交XX密码_【被测业务】验证用户反馈的结果为提交XX密码
由上述组合用例步骤可知,组合用例步骤包括信息获取步骤和信息验证步骤。以组合步骤1为例,组合步骤1包括的第一业务操作步骤为业务操作步骤1,组合步骤1包括的第二业务操作步骤为业务操作步骤2d,业务操作步骤1是指由被测业务向用户提供包含XX信息的交互界面的步骤(即信息获取步骤),业务操作步骤2d是指由用户在交互界面中产生交互行为(即通过包含XX信息的交互界面反馈确认XX信息),并由被测业务对交互行为进行感知反馈(即对反馈的XX信息的结果进行校验)的步骤(即信息验证步骤)。业务操作步骤1和业务操作步骤2d组成组合步骤1,组合步骤1表示了被测业务中的用户与被测业务之间的一个界面(包含XX信息的交互界面)交互行为。以此类推,可以从上述支付场景下的业务操作序列中继续提取目标用例步骤中的组合步骤2至组合步骤5。
S607、服务器根据前置条件和目标用例步骤生成目标测试用例
从目标遍历路径中提取得到目标用例步骤之后,服务器将筛选得到的Q种前置条件与目标用例进行组合,即可生成目标用例路径对应的目标测试用例;例如,假设目标用例步骤对应3种前置条件组合,则服务器将目标用例步骤分别与3种前置条件进行组合,进而生成3个目标测试用例。
S608、服务器采用目标测试用例对被测业务执行测试,得到测试结果。
在一种实施方式中,服务器对生成的目标测试用例对被测业务执行测试,得到测试结果。该测试结果的好坏用于评判软件产品的质量。
可以理解的是,上述步骤S602-步骤S608可由图2b中的用例生成模块来完成。
本申请实施例中,服务器获取目标关键业务节点(即目标用例路径所穿过的业务节点)所使用的业务规则,该业务规则包括多个规则因子,首先通过笛卡尔展开算法对各个规则因子中包含的规则项进行组合,再采用结对测试法对组合的规则项组合进行筛选,得到目标用例的前置条件。上述过程中,在保证两个规则因子中的任一组规则项组合至少被测一次的前提下,对P种前置条件进行筛选,得到目标测试用例的Q种前置条件,P,Q均为正整数,且Q≤P。可见,通过对规则因子进行组合分析,既可以较好地保证前置条件覆盖需求数据中的需求,又可以控制前置条件的数量,进而提高测试投入产出比例,降低测试用例的维护成本。
上述详细阐述了本申请实施例的方法,为了便于更好地实施本申请实施例的上述方案,相应地,下面提供了本申请实施例的装置。
请参见图10,图10示出了本申请一个示例性实施例提供的一种数据处理装置的结构示意图,该数据处理装置可以搭载在服务器中;该数据处理装置可以是数据处理设备中的一个应用程序或插件。图10所示的数据处理装置可以用于执行上述图5和图6所描述的方法实施例中的部分或全部功能。其中,各个单元的详细描述如下:
获取单元1001,用于获取需求数据,该需求数据包括被测业务的业务路径及该业务路径下的业务操作步骤;
处理单元1002,用于根据需求数据构建有向图,该有向图包括业务节点和边,业务节点用于表示被测业务中的业务操作步骤,边用于表示被测业务中的业务操作步骤之间的跳转逻辑;以及用于从有向图中探索得到目标用例路径,该目标用例路径是指经过有向图中的目标关键业务节点的路径;目标用例路径用于表示被测业务的一个业务操作序列,且目标用例路径用于生成目标测试用例;
获取单元1001,还用于获取目标关键业务节点所使用的业务规则,该业务规则包括多个规则因子;
处理单元1002,还用于对规则因子进行组合分析,得到目标测试用例的前置条件。
在一种实施方式中,目标关键业务节点所使用的业务规则包括M个规则因子,M为正整数;处理单元1002用于,对规则因子进行组合分析,得到目标测试用例的前置条件,具体用于:
按照笛卡尔展开算法对M个规则因子进行组合,得到目标测试用例的P种前置条件;
采用结对测试法对P种前置条件进行筛选,得到目标测试用例的Q种前置条件,Q为正整数,且Q≤P;
其中,设M个规则因子中第i个规则因子包括种规则项,则P的值为/>
在一种实施方式中,被测业务包括N个业务操作步骤,有向图包括N个业务节点;处理单元1002用于,根据需求数据构建有向图,具体用于:
将被测业务的第i个业务操作步骤确定为有向图中的第i个业务节点,将被测业务的第j个业务操作步骤确定为有向图中的第j个业务节点;以及,
将第i个业务操作步骤与第j个业务操作步骤之间的跳转逻辑确定为有向图中第i个业务节点与第j个业务节点之间的边;
依据确定的业务节点和边构建有向图;
其中,N为大于1的整数,i、j均为正整数,并且i≤N,j≤N。
在一种实施方式中,处理单元1002还用于:
遍历有向图中的业务节点,得到用例路径集合,该用例路径集合中包含至少一条用例路径,每一条用例路径分别用于表示被测业务的一个业务操作序列;
其中,用例路径集合中的用例路径的类型包括主用例路径或关键用例路径。
在一种实施方式中,业务路径包括基本业务路径,该基本业务路径下包含N个业务操作步骤;N为正整数;有向图还包括起始节点和结束节点;处理单元1002用于,遍历有向图中的业务节点,得到用例路径集合,具体用于:
从起始节点开始,按照基本业务路径下的N个业务操作步骤的执行顺序,依次遍历有向图中的N个业务节点,直至结束节点停止;N个业务节点与基本业务路径下的N个业务操作步骤一一对应;
将穿过起始节点、N个业务节点以及结束节点的遍历路径确定为主用例路径。
在一种实施方式中,有向图还包括起始节点和结束节点;处理单元1002用于,从有向图中探索得到目标用例路径,具体用于:
在有向图中确定目标关键业务节点;
采用最短路径图遍历算法在有向图中遍历查找起始节点与目标关键业务节点之间的第一路径;以及,在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径;
将第一路径与第二路径拼接形成的路径确定为目标用例路径。
在一种实施方式中,处理单元1002用于,在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径,具体用于:
若目标关键业务节点的类型为第一类型,则在有向图中探索得到主用例路径,沿结束节点的方向在有向图中探索从目标关键业务节点返回至主用例路径,并沿主用例路径到达结束节点的第二路径;或者,
若目标关键业务节点的类型为第一类型,采用最短路径图遍历算法在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径;或者,
若目标关键业务节点的类型为第二类型,则将目标关键业务节点与结束节点相连接形成的路径确定为第二路径;
其中,若目标关键业务节点用于表示由被测业务向被测业务中的用户提供交互界面的业务操作步骤,则目标关键业务节点的类型为第一类型;若目标关键业务节点用于表示由用户在交互界面中产生交互行为,并由被测业务对交互行为进行感知反馈的业务操作步骤,则目标关键业务节点的类型为第二类型。
在一种实施方式中,用例路径集合包括第一用例路径集合和第二用例路径集合,第一用例路径集合和第二用例路径集合中均包含一条或多条用例路径,其中,第一用例路径集合中的用例路径用于生成验证业务操作行为的测试用例,第二用例路径集合中的用例路径用于生成验证业务规则的测试用例;处理单元1002还用于:
对第一用例路径集合和第二用例路径集合进行优化处理。
在一种实施方式中,处理单元1002用于,对第一用例路径集合和第二用例路径集合进行优化处理,具体用于:
若第一用例路径集合与第二用例路径集合包含相同的用例路径,则在第二用例路径集合中删除相同的用例路径。
在一种实施方式中,处理单元1002用于,获取需求数据,具体用于:
获取需求描述文档,需求描述文档用于描述被测业务的业务操作流程,且需求描述文档为第一格式的文档;
对需求描述文档进行解析,得到需求数据,需求数据为第二格式的数据。
在一种实施方式中,处理单元1002还用于:
从目标用例路径中提取目标用例步骤;
根据前置条件和目标用例步骤生成目标测试用例;
采用目标测试用例对被测业务执行测试,得到测试结果。
根据本申请的一个实施例,图5和图6所示的数据处理方法所涉及的部分步骤可由图10所示的数据处理装置中的各个单元来执行。例如,图5中所示的步骤S501和步骤S504可由图10所示的获取单元1001执行,步骤S502,步骤S503和步骤S505可由图10所示的处理单元1002执行。图6中所示的步骤S601可由图10所示的获取单元1001执行,步骤S602-步骤S608可由图10所示的处理单元1002执行。图10所示的数据处理装置中的各个单元可以分别或全部合并为一个或若干个另外的单元来构成,或者其中的某个(些)单元还可以再拆分为功能上更小的多个单元来构成,这可以实现同样的操作,而不影响本申请的实施例的技术效果的实现。上述单元是基于逻辑功能划分的,在实际应用中,一个单元的功能也可以由多个单元来实现,或者多个单元的功能由一个单元实现。在本申请的其它实施例中,数据处理装置也可以包括其它单元,在实际应用中,这些功能也可以由其它单元协助实现,并且可以由多个单元协作实现。
根据本申请的另一个实施例,可以通过在包括中央处理单元(CPU)、随机存取存储介质(RAM)、只读存储介质(ROM)等处理元件和存储元件的例如计算机的通用计算装置上运行能够执行如图5和图6中所示的相应方法所涉及的各步骤的计算机程序(包括程序代码),来构造如图10中所示的数据处理装置,以及来实现本申请实施例的数据处理方法。计算机程序可以记载于例如计算机可读记录介质上,并通过计算机可读记录介质装载于上述计算装置中,并在其中运行。
基于同一发明构思,本申请实施例中提供的数据处理装置解决问题的原理与有益效果与本申请方法实施例中数据处理方法解决问题的原理和有益效果相似,可以参见方法的实施的原理和有益效果,为简洁描述,在这里不再赘述。
请参阅图11,图11示出了本申请一个示例性实施例提供的一种数据处理设备的结构示意图,该数据处理设备可以是参与社交会话的用户所使用的终端设备;该数据处理设备至少包括处理器1101、通信接口1102和存储器1103。其中,处理器1101、通信接口1102和存储器1103可通过总线或其他方式连接,本申请实施例以通过总线连接为例。其中,处理器1101(或称中央处理器(Central Processing Unit,CPU))是数据处理设备的计算核心以及控制核心,其可以解析终端设备内的各类指令以及处理终端设备的各类数据,例如:CPU可以用于解析用户向终端设备所发送的开关机指令,并控制终端设备进行开关机操作;再如:CPU可以在终端设备内部结构之间传输各类交互数据,等等。通信接口1102可选的可以包括标准的有线接口、无线接口(如WI-FI、移动通信接口等),受处理器1101的控制可以用于收发数据;通信接口1102还可以用于终端设备内部数据的传输以及交互。存储器1103(Memory)是终端设备中的记忆设备,用于存放程序和数据。可以理解的是,此处的存储器1103既可以包括终端设备的内置存储器,当然也可以包括终端设备所支持的扩展存储器。存储器1103提供存储空间,该存储空间存储了终端设备的操作系统,可包括但不限于:Android系统、iOS系统、Windows Phone系统等等,本申请对此并不作限定。
在本申请实施例中,处理器1101通过运行存储器1103中的可执行程序代码,执行如下操作:
获取需求数据,该需求数据包括被测业务的业务路径及该业务路径下的业务操作步骤;
根据需求数据构建有向图,该有向图包括业务节点和边,业务节点用于表示被测业务中的业务操作步骤,边用于表示被测业务中的业务操作步骤之间的跳转逻辑;
从有向图中探索得到目标用例路径,该目标用例路径是指经过有向图中的目标关键业务节点的路径;目标用例路径用于表示被测业务的一个业务操作序列,且目标用例路径用于生成目标测试用例;
获取目标关键业务节点所使用的业务规则,该业务规则包括多个规则因子;
对规则因子进行组合分析,得到目标测试用例的前置条件。
作为一种可选的实施方式,目标关键业务节点所使用的业务规则包括M个规则因子,M为正整数;处理器1101对规则因子进行组合分析,得到目标测试用例的前置条件的具体实施方式为:
按照笛卡尔展开算法对M个规则因子进行组合,得到目标测试用例的P种前置条件;
采用结对测试法对P种前置条件进行筛选,得到目标测试用例的Q种前置条件,Q为正整数,且Q≤P;
其中,设M个规则因子中第i个规则因子包括种规则项,则P的值为/>
作为一种可选的实施方式,被测业务包括N个业务操作步骤,有向图包括N个业务节点;处理器1101根据需求数据构建有向图的具体实施方式为:
将被测业务的第i个业务操作步骤确定为有向图中的第i个业务节点,将被测业务的第j个业务操作步骤确定为有向图中的第j个业务节点;以及,
将第i个业务操作步骤与第j个业务操作步骤之间的跳转逻辑确定为有向图中第i个业务节点与第j个业务节点之间的边;
依据确定的业务节点和边构建有向图;
其中,N为大于1的整数,i、j均为正整数,并且i≤N,j≤N。
作为一种可选的实施方式,处理器1101通过运行存储器1103中的可执行程序代码,还执行如下操作:
遍历有向图中的业务节点,得到用例路径集合,该用例路径集合中包含至少一条用例路径,每一条用例路径分别用于表示被测业务的一个业务操作序列;
其中,用例路径集合中的用例路径的类型包括主用例路径或关键用例路径。
作为一种可选的实施方式,业务路径包括基本业务路径,该基本业务路径下包含N个业务操作步骤;N为正整数;有向图还包括起始节点和结束节点;处理器1101遍历有向图中的业务节点,得到用例路径集合的具体实施方式为:
从起始节点开始,按照基本业务路径下的N个业务操作步骤的执行顺序,依次遍历有向图中的N个业务节点,直至结束节点停止;N个业务节点与基本业务路径下的N个业务操作步骤一一对应;
将穿过起始节点、N个业务节点以及结束节点的遍历路径确定为主用例路径。
作为一种可选的实施方式,有向图还包括起始节点和结束节点;处理器1101从有向图中探索得到目标用例路径的具体实施方式为:
在有向图中确定目标关键业务节点;
采用最短路径图遍历算法在有向图中遍历查找起始节点与目标关键业务节点之间的第一路径;以及,在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径;
将第一路径与第二路径拼接形成的路径确定为目标用例路径。
作为一种可选的实施方式,处理器1101在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径的具体实施方式为:
若目标关键业务节点的类型为第一类型,则在有向图中探索得到主用例路径,沿结束节点的方向在有向图中探索从目标关键业务节点返回至主用例路径,并沿主用例路径到达结束节点的第二路径;或者,
若目标关键业务节点的类型为第一类型,采用最短路径图遍历算法在有向图中遍历查找目标关键业务节点与结束节点之间的第二路径;或者,
若目标关键业务节点的类型为第二类型,则将目标关键业务节点与结束节点相连接形成的路径确定为第二路径;
其中,若目标关键业务节点用于表示由被测业务向被测业务中的用户提供交互界面的业务操作步骤,则目标关键业务节点的类型为第一类型;若目标关键业务节点用于表示由用户在交互界面中产生交互行为,并由被测业务对交互行为进行感知反馈的业务操作步骤,则目标关键业务节点的类型为第二类型。作为一种可选的实施方式,用例路径集合包括第一用例路径集合和第二用例路径集合,第一用例路径集合和第二用例路径集合中均包含一条或多条用例路径,其中,第一用例路径集合中的用例路径用于生成验证业务操作行为的测试用例,第二用例路径集合中的用例路径用于生成验证业务规则的测试用例;处理器1101通过运行存储器1103中的可执行程序代码,还执行如下操作:
对第一用例路径集合和第二用例路径集合进行优化处理。
作为一种可选的实施方式,处理器1101对第一用例路径集合和第二用例路径集合进行优化处理的具体实施方式为:
若第一用例路径集合与第二用例路径集合包含相同的用例路径,则在第二用例路径集合中删除相同的用例路径。
作为一种可选的实施方式,处理器1101获取需求数据的具体实施方式为:
获取需求描述文档,需求描述文档用于描述被测业务的业务操作流程,且需求描述文档为第一格式的文档;
对需求描述文档进行解析,得到需求数据,需求数据为第二格式的数据。
作为一种可选的实施方式,处理器1101通过运行存储器1103中的可执行程序代码,还执行如下操作:
从目标用例路径中提取目标用例步骤;
根据前置条件和目标用例步骤生成目标测试用例;
采用目标测试用例对被测业务执行测试,得到测试结果。
基于同一发明构思,本申请实施例中提供的数据处理设备解决问题的原理与有益效果与本申请方法实施例中数据处理方法解决问题的原理和有益效果相似,可以参见方法的实施的原理和有益效果,为简洁描述,在这里不再赘述。
本申请实施例还提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机程序,该计算机程序适于由处理器加载并执行上述方法实施例的数据处理方法。
本申请实施例还提供一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行上述数据处理的方法。
需要说明的是,对于前述的各个方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某一些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。
本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,可读存储介质可以包括:闪存盘、只读存储器(Read-Only Memory ,ROM)、随机存取器(RandomAccess Memory,RAM)、磁盘或光盘等。
以上所揭露的仅为本申请一种较佳实施例而已,当然不能以此来限定本申请之权利范围,本领域普通技术人员可以理解实现上述实施例的全部或部分流程,并依本申请权利要求所作的等同变化,仍属于申请所涵盖的范围。

Claims (13)

1.一种数据处理方法,其特征在于,所述方法包括:
获取需求数据,所述需求数据包括被测业务的业务路径及所述业务路径下的业务操作步骤;
根据所述需求数据构建有向图,所述有向图包括业务节点和边,所述有向图还包括起始节点和结束节点;所述业务节点用于表示所述被测业务中的业务操作步骤,所述边用于表示所述被测业务中的业务操作步骤之间的跳转逻辑;
从所述有向图中探索得到目标用例路径,所述目标用例路径是指经过所述有向图中的目标关键业务节点的路径;所述目标用例路径用于表示所述被测业务的一个业务操作序列,且所述目标用例路径用于生成目标测试用例;遍历所述有向图中的业务节点得到的用例路径的类型包括主用例路径或关键用例路径;
获取所述目标关键业务节点所使用的业务规则,所述业务规则包括多个规则因子;
对所述规则因子进行组合分析,得到所述目标测试用例的前置条件;
其中,所述从所述有向图中探索得到目标用例路径,包括:在所述有向图中确定所述目标关键业务节点;采用最短路径图遍历算法在所述有向图中遍历查找所述起始节点与所述目标关键业务节点之间的第一路径;以及,在所述有向图中遍历查找所述目标关键业务节点与所述结束节点之间的第二路径;将所述第一路径与所述第二路径拼接形成的路径确定为所述目标用例路径;
所述在所述有向图中遍历查找所述目标关键业务节点与所述结束节点之间的第二路径,包括:若所述目标关键业务节点的类型为第一类型,则在所述有向图中探索得到主用例路径,沿所述结束节点的方向在所述有向图中探索从所述目标关键业务节点返回至所述主用例路径,并沿所述主用例路径到达所述结束节点的第二路径;若所述目标关键业务节点的类型为第二类型,则将所述目标关键业务节点与所述结束节点相连接形成的路径确定为所述第二路径;
若所述目标关键业务节点用于表示由所述被测业务的用户在交互界面中产生交互行为,并由所述被测业务对所述交互行为进行感知反馈的业务操作步骤,则所述目标关键业务节点的类型为所述第一类型;若所述目标关键业务节点用于表示由所述被测业务向所述用户提供所述交互界面的业务操作步骤,则所述目标关键业务节点的类型为所述第二类型。
2.如权利要求1所述的方法,其特征在于,所述目标关键业务节点所使用的业务规则包括M个规则因子,M为正整数;
所述对所述规则因子进行组合分析,得到所述目标测试用例的前置条件,包括:
按照笛卡尔展开算法对所述M个规则因子进行组合,得到所述目标测试用例的P种前置条件;
采用结对测试法对所述P种前置条件进行筛选,得到所述目标测试用例的Q种前置条件,Q为正整数,且Q≤P;
其中,设M个规则因子中第i个规则因子包括种规则项,则P的值为/>
3.如权利要求1所述的方法,其特征在于,所述被测业务包括N个业务操作步骤,所述有向图包括N个业务节点;所述根据所述需求数据构建有向图,包括:
将所述被测业务的第i个业务操作步骤确定为所述有向图中的第i个业务节点,将所述被测业务的第j个业务操作步骤确定为所述有向图中的第j个业务节点;以及,
将所述第i个业务操作步骤与所述第j个业务操作步骤之间的跳转逻辑确定为所述有向图中所述第i个业务节点与所述第j个业务节点之间的边;
依据确定的业务节点和边构建所述有向图;
其中,N为大于1的整数,i、j均为正整数,并且i≤N,j≤N。
4.如权利要求1所述的方法,其特征在于,所述方法还包括:
遍历所述有向图中的业务节点,得到用例路径集合,所述用例路径集合中包含至少一条用例路径,每一条用例路径分别用于表示所述被测业务的一个业务操作序列;
其中,所述用例路径集合中的用例路径的类型包括主用例路径或关键用例路径。
5.如权利要求4所述的方法,其特征在于,所述业务路径包括基本业务路径,所述基本业务路径下包含N个业务操作步骤;N为正整数;所述有向图还包括起始节点和结束节点;所述遍历所述有向图中的业务节点,得到用例路径集合,包括:
从所述起始节点开始,按照所述基本业务路径下的N个业务操作步骤的执行顺序,依次遍历所述有向图中的N个业务节点,直至所述结束节点停止;所述N个业务节点与所述基本业务路径下的N个业务操作步骤一一对应;
将穿过所述起始节点、所述N个业务节点以及所述结束节点的遍历路径确定为主用例路径。
6.如权利要求4所述的方法,其特征在于,所述用例路径集合包括第一用例路径集合和第二用例路径集合,所述第一用例路径集合和所述第二用例路径集合中均包含一条或多条用例路径,其中,所述第一用例路径集合中的用例路径用于生成验证业务操作行为的测试用例,所述第二用例路径集合中的用例路径用于生成验证业务规则的测试用例;所述方法还包括:
对所述第一用例路径集合和所述第二用例路径集合进行优化处理。
7.如权利要求6所述的方法,其特征在于,所述对所述第一用例路径集合和所述第二用例路径集合进行优化处理,包括:
若所述第一用例路径集合与所述第二用例路径集合包含相同的用例路径,则在所述第二用例路径集合中删除所述相同的用例路径。
8.如权利要求1所述的方法,其特征在于,所述获取需求数据包括:
获取需求描述文档,所述需求描述文档用于描述被测业务的业务操作流程,且所述需求描述文档为第一格式的文档;
对所述需求描述文档进行解析,得到所述需求数据,所述需求数据为第二格式的数据。
9.如权利要求1所述的方法,其特征在于,所述方法还包括:
从所述目标用例路径中提取目标用例步骤;
根据所述前置条件和所述目标用例步骤生成所述目标测试用例;
采用所述目标测试用例对所述被测业务执行测试,得到测试结果。
10.一种数据处理装置,其特征在于,所述数据处理装置包括:
获取单元,用于获取需求数据,所述需求数据包括被测业务的业务路径及所述业务路径下的业务操作步骤;
处理单元,根据所述需求数据构建有向图,所述有向图包括业务节点和边,所述有向图还包括起始节点和结束节点;所述业务节点用于表示所述被测业务中的业务操作步骤,所述边用于表示所述被测业务中的业务操作步骤之间的跳转逻辑;以及用于从所述有向图中探索得到目标用例路径,所述目标用例路径是指经过所述有向图中的目标关键业务节点的路径;所述目标用例路径用于表示所述被测业务的一个业务操作序列,且所述目标用例路径用于生成目标测试用例;遍历所述有向图中的业务节点得到的用例路径的类型包括主用例路径或关键用例路径;
所述获取单元,还用于获取所述目标关键业务节点所使用的业务规则,所述业务规则包括多个规则因子;
所述处理单元,还用于对所述规则因子进行组合分析,得到所述目标测试用例的前置条件;
其中,所述从所述有向图中探索得到目标用例路径,包括:在所述有向图中确定所述目标关键业务节点;采用最短路径图遍历算法在所述有向图中遍历查找所述起始节点与所述目标关键业务节点之间的第一路径;以及,在所述有向图中遍历查找所述目标关键业务节点与所述结束节点之间的第二路径;将所述第一路径与所述第二路径拼接形成的路径确定为所述目标用例路径;
所述在所述有向图中遍历查找所述目标关键业务节点与所述结束节点之间的第二路径,包括:若所述目标关键业务节点的类型为第一类型,则在所述有向图中探索得到主用例路径,沿所述结束节点的方向在所述有向图中探索从所述目标关键业务节点返回至所述主用例路径,并沿所述主用例路径到达所述结束节点的第二路径;若所述目标关键业务节点的类型为第二类型,则将所述目标关键业务节点与所述结束节点相连接形成的路径确定为所述第二路径;
若所述目标关键业务节点用于表示由所述被测业务的用户在交互界面中产生交互行为,并由所述被测业务对所述交互行为进行感知反馈的业务操作步骤,则所述目标关键业务节点的类型为所述第一类型;若所述目标关键业务节点用于表示由所述被测业务向所述用户提供所述交互界面的业务操作步骤,则所述目标关键业务节点的类型为所述第二类型。
11.一种数据处理设备,其特征在于,包括:存储装置和处理器;
所述存储装置中存储有计算机程序;
处理器,用于加载并执行所述计算机程序,以实现如权利要求1-9任一项所述的数据处理方法。
12.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有计算机程序,所述计算机程序适于被处理器加载并执行如权利要求1-9任一项所述的数据处理方法。
13.一种计算机程序产品,其特征在于,所述计算机程序产品包括计算机指令,所述计算机指令被计算机设备的处理器读取并执行时,使得所述计算机设备执行如权利要求1-9任一项所述的数据处理方法。
CN202110014546.2A 2021-01-06 2021-01-06 一种数据处理方法、装置、设备及存储介质 Active CN114721931B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110014546.2A CN114721931B (zh) 2021-01-06 2021-01-06 一种数据处理方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110014546.2A CN114721931B (zh) 2021-01-06 2021-01-06 一种数据处理方法、装置、设备及存储介质

Publications (2)

Publication Number Publication Date
CN114721931A CN114721931A (zh) 2022-07-08
CN114721931B true CN114721931B (zh) 2024-04-09

Family

ID=82234476

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110014546.2A Active CN114721931B (zh) 2021-01-06 2021-01-06 一种数据处理方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN114721931B (zh)

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101788907A (zh) * 2010-01-04 2010-07-28 北京航空航天大学 组合服务精简测试用例的自动生成方法及装置
CN105022691A (zh) * 2015-07-22 2015-11-04 国家电网公司 一种基于uml图的高度自动化软件测试方法
CN107832231A (zh) * 2017-12-05 2018-03-23 郑州云海信息技术有限公司 一种系统测试方法、装置及介质
CN109117363A (zh) * 2018-06-28 2019-01-01 腾讯科技(深圳)有限公司 一种测试用例生成方法、装置及服务器
CN109656802A (zh) * 2017-10-10 2019-04-19 大连飞创信息技术有限公司 基于高耦合自动匹配技术的测试用例设计系统
CN110162468A (zh) * 2019-04-26 2019-08-23 腾讯科技(深圳)有限公司 一种测试方法、装置以及计算机可读存储介质
CN110389894A (zh) * 2019-05-27 2019-10-29 南京祖母绿智能科技有限公司 测试用例生成的方法和装置
CN110990295A (zh) * 2019-12-19 2020-04-10 卡斯柯信号(北京)有限公司 测试用例的验证方法、装置及电子设备
CN111240983A (zh) * 2020-01-14 2020-06-05 北京思特奇信息技术股份有限公司 一种电信计费业务自动化测试的实现方法及装置
CN111506498A (zh) * 2020-03-16 2020-08-07 平安科技(深圳)有限公司 测试用例的自动生成方法、装置、计算机设备及存储介质
CN111694741A (zh) * 2020-06-05 2020-09-22 中国工程物理研究院计算机应用研究所 一种基于路径深度覆盖的测试用例设计方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8949795B2 (en) * 2012-08-23 2015-02-03 International Business Machines Corporation Generating test cases for covering enterprise rules and predicates
US10339485B2 (en) * 2012-12-14 2019-07-02 International Business Machines Corporation Efficiently generating test cases
US20150286555A1 (en) * 2014-04-08 2015-10-08 M/S. Cigniti Technologies Limited System and method for converting the business processes to test-centric activity diagrams

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101788907A (zh) * 2010-01-04 2010-07-28 北京航空航天大学 组合服务精简测试用例的自动生成方法及装置
CN105022691A (zh) * 2015-07-22 2015-11-04 国家电网公司 一种基于uml图的高度自动化软件测试方法
CN109656802A (zh) * 2017-10-10 2019-04-19 大连飞创信息技术有限公司 基于高耦合自动匹配技术的测试用例设计系统
CN107832231A (zh) * 2017-12-05 2018-03-23 郑州云海信息技术有限公司 一种系统测试方法、装置及介质
CN109117363A (zh) * 2018-06-28 2019-01-01 腾讯科技(深圳)有限公司 一种测试用例生成方法、装置及服务器
CN110162468A (zh) * 2019-04-26 2019-08-23 腾讯科技(深圳)有限公司 一种测试方法、装置以及计算机可读存储介质
CN110389894A (zh) * 2019-05-27 2019-10-29 南京祖母绿智能科技有限公司 测试用例生成的方法和装置
CN110990295A (zh) * 2019-12-19 2020-04-10 卡斯柯信号(北京)有限公司 测试用例的验证方法、装置及电子设备
CN111240983A (zh) * 2020-01-14 2020-06-05 北京思特奇信息技术股份有限公司 一种电信计费业务自动化测试的实现方法及装置
CN111506498A (zh) * 2020-03-16 2020-08-07 平安科技(深圳)有限公司 测试用例的自动生成方法、装置、计算机设备及存储介质
CN111694741A (zh) * 2020-06-05 2020-09-22 中国工程物理研究院计算机应用研究所 一种基于路径深度覆盖的测试用例设计方法

Also Published As

Publication number Publication date
CN114721931A (zh) 2022-07-08

Similar Documents

Publication Publication Date Title
AU2022202630A1 (en) Data reconciliation based on computer analysis of data
CN112711526B (zh) Ui测试方法、装置、设备及存储介质
CN110851167B (zh) 容器环境更新方法、装置、设备及存储介质
US20140372963A1 (en) Method and apparatus for customized software development kit (sdk) generation
CN112036577B (zh) 基于数据形式的应用机器学习的方法、装置和电子设备
CN111563220A (zh) 业务网站项目构建方法、装置、计算机设备和存储介质
Sim et al. Empowering requirements engineering activities with personas
CN104111826A (zh) 一种软件项目开发方法及装置
CN110941467A (zh) 数据处理方法、装置及系统
CN109726105A (zh) 测试数据构造方法、装置、设备及存储介质
US10579354B2 (en) Method and system for rapid deployment and execution of customized functionality across multiple distinct platforms
CN105393226A (zh) 脚本测试案例和手动测试案例的自动生成
Falkenthal et al. Efficient pattern application: validating the concept of solution implementations in different domains
CN113641591B (zh) 测试用例生成方法及装置、测试方法及装置
CN112799782A (zh) 模型生成系统、方法、电子设备及存储介质
CN106484389A (zh) 动作流分段管理
KR20210036167A (ko) 어플리케이션의 테스트 자동화
CN114253436B (zh) 一种页面展示方法、装置及存储介质
US20170277710A1 (en) Data comparison
CN114721932B (zh) 一种数据处理方法、装置、设备及存储介质
CN114721931B (zh) 一种数据处理方法、装置、设备及存储介质
CN113837210A (zh) 小程序分类方法、装置、设备及计算机可读存储介质
CN114721930A (zh) 一种数据处理方法、装置、设备及介质
CN116719735A (zh) 一种测试用例生成方法及装置
Shrivastava Learning Salesforce Einstein

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant