一种自动化用例的测试方法、测试系统及存储介质与流程

文档序号:18009523发布日期:2019-06-25 23:49阅读:172来源:国知局
一种自动化用例的测试方法、测试系统及存储介质与流程

本发明涉及计算机技术领域,具体而言,涉及一种自动化用例的测试方法、测试系统及存储介质。



背景技术:

目前行业内的自动化工具大多是针对某个测试端提供能力,例如web(互联网)端的selenium(浏览器自动化测试框架),app(手机软件)端的uiautomator(ui(userinterface,用户界面)自动化测试工具)、appium(移动端自动化测试框架),接口的requests、jmeter等,其中requests为一种超文本传输协议库,jmeter为基于java的压力测试工具,产品在实现自动化时往往要分别针对接口、web、app设计测试用例,消耗大量的人力物力,产品ui或者接口变更时,又需要对大量的用例进行维护,导致自动化维护成本较高。

对于产品来说,自动化需要覆盖的业务逻辑和场景固定的情况下,不同测试端上的操作步骤不同并不会影响测试的关注点。对于测试人员来说,多个测试端都需要自动化测试的前提下,需要了解多个测试工具,或者对代码能力有较高的要求,不利于测试人员的能力规划和组织构成。



技术实现要素:

本发明旨在至少解决现有技术或相关技术中存在的技术问题之一。

为此,本发明的一个方面在于提出了一种自动化用例的测试方法。

本发明的另一个方面在于提出了一种自动化用例的测试系统。

本发明的再一个方面在于提出了一种计算机可读存储介质。

有鉴于此,根据本发明的一个方面,提出了一种自动化用例的测试方法,包括:获取业务对象的业务模型,并生成业务类型的操作命令和操作数据;将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例;分别在不同测试端上进行自动化用例的测试。

本发明提供的自动化用例的测试方法,根据业务对象抽象出可操作的业务模型,并提供操作命令和操作参数,针对不同测试端(例如接口、web、app等自动化工具),封装各测试端的业务类型、操作命令和操作数据,自动建立针对不同测试端的自动化用例。进一步地,在测试时分别在不同测试端上进行自动化用例的测试。采用本发明的技术方案,一方面,把测试用例通过业务模型针对不同测试端分离开来,并能适用多端多测试类型,可以降低自动化复杂度,提高用例复用性;另一方面,使得测试人员只关注业务流程和场景用例设计,不关注业务场景在多个测试端上的运行实现,能更好地设计出高覆盖度用例,提高自动化产出。

根据本发明的上述自动化用例的测试方法,还可以具有以下技术特征:

在上述技术方案中,优选地,将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例的步骤,具体包括:配置用例参数;针对不同测试端,将用例参数、业务类型、操作命令和操作数据针对不同测试端进行封装;组织测试步骤以及设定用例执行结果,以形成自动化用例。

在该技术方案中,配置用例参数,用例参数包括用例需要用到的账号、账套信息、指定预置数据需要使用的辅助能力、用例如需在多环境运行还需要提供额外的账号配置管理能力。将用例参数、业务类型、操作命令和操作数据针对不同测试端进行封装,根据业务场景选取合适的业务模型组织测试步骤,以及通过业务模型的查询方法获取状态数据判断用例执行结果,最终形成自动化用例。对于测试用例设计来说,相关技术中自动化框架大多针对测试过程设计用例,涉及复杂场景、多角色、多功能交互,对于不同测试端设计测试用例,使得用例设计非常困难、测试人员浪费严重,而本发明的技术方案,只关注业务流程和场景用例设计,不关注业务场景在多个测试端上的运行实现,能更好地设计出高覆盖度用例。

在上述任一技术方案中,优选地,分别在不同测试端上进行自动化用例的测试的步骤,具体包括:选择待运行的测试环境和测试设备,以及设定运行参数;分别在不同测试端上进行自动化用例的测试。

在该技术方案中,选取需要运行的测试环境及测试设备,指定运行中的额外运行参数,例如用例的串并行、并发设备数、用例先后顺序、统一的初始化事件等参数。进一步地,分别在不同测试端上进行对应的自动化用例的测试,实现自动化用例的多端复用。

在上述任一技术方案中,优选地,还包括:接收任一测试端的调整信息,调整任一测试端对应的对业务类型、操作命令和操作数据的封装。

在该技术方案中,在用例设计时只关注如何组织测试场景,使得场景用例可以在多个端复用,很大程度地节约测试工作量,当某个测试端改版时,也不必大量更新用例,调整任一测试端对应的对业务类型、操作命令和操作数据的封装即可,节约测试资源。

在上述任一技术方案中,优选地,还包括:将测试结果存储至日志,以及展示测试结果。

在该技术方案中,收集测试用例执行产生的数据,选择性地持久化和分析,统一汇总到测试结果,可以使用kafka等消息中间件实现,其中kafka为一种高吞吐量的分布式发布订阅消息系统,测试结果统一汇集到日志服务收集整理,并从前端查看测试结果。

根据本发明的另一个方面,提出了一种自动化用例的测试系统,包括:存储器,用于存储计算机程序;处理器,用于执行计算机程序以:获取业务对象的业务模型,并生成业务类型的操作命令和操作数据;将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例;分别在不同测试端上进行自动化用例的测试。

本发明提供的自动化用例的测试系统,根据业务对象抽象出可操作的业务模型,并提供操作命令和操作参数,针对不同测试端(例如接口、web、app等自动化工具),封装各测试端的业务类型、操作命令和操作数据,自动建立针对不同测试端的自动化用例。进一步地,在测试时分别在不同测试端上进行自动化用例的测试。采用本发明的技术方案,一方面,把测试用例通过业务模型针对不同测试端分离开来,并能适用多端多测试类型,可以降低自动化复杂度,提高用例复用性;另一方面,使得测试人员只关注业务流程和场景用例设计,不关注业务场景在多个测试端上的运行实现,能更好地设计出高覆盖度用例,提高自动化产出。

根据本发明的上述自动化用例的测试系统,还可以具有以下技术特征:

在上述技术方案中,优选地,处理器将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例,具体包括:配置用例参数;针对不同测试端,将用例参数、业务类型、操作命令和操作数据针对不同测试端进行封装;组织测试步骤以及设定用例执行结果,以形成自动化用例。

在该技术方案中,配置用例参数,用例参数包括用例需要用到的账号、账套信息、指定预置数据需要使用的辅助能力、用例如需在多环境运行还需要提供额外的账号配置管理能力。将用例参数、业务类型、操作命令和操作数据针对不同测试端进行封装,根据业务场景选取合适的业务模型组织测试步骤,以及通过业务模型的查询方法获取状态数据判断用例执行结果,最终形成自动化用例。对于测试用例设计来说,相关技术中自动化框架大多针对测试过程设计用例,涉及复杂场景、多角色、多功能交互,对于不同测试端设计测试用例,使得用例设计非常困难、测试人员浪费严重,而本发明的技术方案,只关注业务流程和场景用例设计,不关注业务场景在多个测试端上的运行实现,能更好地设计出高覆盖度用例。

在上述任一技术方案中,优选地,处理器分别在不同测试端上进行自动化用例的测试,具体包括:选择待运行的测试环境和测试设备,以及设定运行参数;分别在不同测试端上进行自动化用例的测试。

在该技术方案中,选取需要运行的测试环境及测试设备,指定运行中的额外运行参数,例如用例的串并行、并发设备数、用例先后顺序、统一的初始化事件等参数。进一步地,分别在不同测试端上进行对应的自动化用例的测试,实现自动化用例的多端复用。

在上述任一技术方案中,优选地,处理器还用于执行计算机程序以:接收任一测试端的调整信息,调整任一测试端对应的对业务类型、操作命令和操作数据的封装。

在该技术方案中,在用例设计时只关注如何组织测试场景,使得场景用例可以在多个端复用,很大程度地节约测试工作量,当某个测试端改版时,也不必大量更新用例,调整任一测试端对应的对业务类型、操作命令和操作数据的封装即可,节约测试资源。

在上述任一技术方案中,优选地,处理器还用于执行计算机程序以:将测试结果存储至日志,以及展示测试结果。

在该技术方案中,收集测试用例执行产生的数据,选择性地持久化和分析,统一汇总到测试结果,可以使用kafka等消息中间件实现,其中kafka为一种高吞吐量的分布式发布订阅消息系统,测试结果统一汇集到日志服务收集整理,并从前端查看测试结果。

根据本发明的再一个方面,提出了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现如上述任一技术方案的自动化用例的测试方法的步骤。

本发明提供的计算机可读存储介质,计算机程序被处理器执行时实现如上述任一技术方案的自动化用例的测试方法的步骤,因此该计算机可读存储介质包括上述任一技术方案的自动化用例的测试方法的全部有益效果。

本发明的附加方面和优点将在下面的描述部分中变得明显,或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解,其中:

图1示出了本发明的一个实施例的自动化用例的测试方法的流程示意图;

图2示出了本发明的另一个实施例的自动化用例的测试方法的流程示意图;

图3示出了本发明的再一个实施例的自动化用例的测试方法的流程示意图;

图4示出了本发明的一个实施例的自动化用例的测试系统的示意框图;

图5示出了本发明的一个具体实施例的自动化用例多端复用的装置的示意图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点,下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是,在不冲突的情况下,本发明的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是,本发明还可以采用其他不同于在此描述的其他方式来实施,因此,本发明的保护范围并不限于下面公开的具体实施例的限制。

本发明第一方面的实施例,提出一种自动化用例的测试方法,图1示出了本发明的一个实施例的自动化用例的测试方法的流程示意图。其中,该方法包括:

步骤102,获取业务对象的业务模型,并生成业务类型的操作命令和操作数据;

步骤104,将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例;

步骤106,分别在不同测试端上进行自动化用例的测试。

本发明提供的自动化用例的测试方法,根据业务对象抽象出可操作的业务模型,并提供操作命令和操作参数,针对不同测试端(例如接口、web、app等自动化工具),封装各测试端的业务类型、操作命令和操作数据,自动建立针对不同测试端的自动化用例。进一步地,在测试时分别在不同测试端上进行自动化用例的测试。采用本发明的技术方案,一方面,把测试用例通过业务模型针对不同测试端分离开来,并能适用多端多测试类型,可以降低自动化复杂度,提高用例复用性;另一方面,使得测试人员只关注业务流程和场景用例设计,不关注业务场景在多个测试端上的运行实现,能更好地设计出高覆盖度用例,提高自动化产出。

可选地,步骤104,将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例的步骤,具体包括:配置用例参数;针对不同测试端,将用例参数、业务类型、操作命令和操作数据针对不同测试端进行封装;组织测试步骤以及设定用例执行结果,以形成自动化用例。

在该实施例中,配置用例参数,用例参数包括用例需要用到的账号、账套信息、指定预置数据需要使用的辅助能力、用例如需在多环境运行还需要提供额外的账号配置管理能力。将用例参数、业务类型、操作命令和操作数据针对不同测试端进行封装,根据业务场景选取合适的业务模型组织测试步骤,以及通过业务模型的查询方法获取状态数据判断用例执行结果,最终形成自动化用例。对于测试用例设计来说,相关技术中自动化框架大多针对测试过程设计用例,涉及复杂场景、多角色、多功能交互,对于不同测试端设计测试用例,使得用例设计非常困难、测试人员浪费严重,而本发明的技术方案,只关注业务流程和场景用例设计,不关注业务场景在多个测试端上的运行实现,能更好地设计出高覆盖度用例。

可选地,步骤106,分别在不同测试端上进行自动化用例的测试的步骤,具体包括:选择待运行的测试环境和测试设备,以及设定运行参数;分别在不同测试端上进行自动化用例的测试。

在该实施例中,选取需要运行的测试环境及测试设备,指定运行中的额外运行参数,例如用例的串并行、并发设备数、用例先后顺序、统一的初始化事件等参数。进一步地,分别在不同测试端上进行对应的自动化用例的测试,实现自动化用例的多端复用。

图2示出了本发明的另一个实施例的自动化用例的测试方法的流程示意图。其中,该方法包括:

步骤202,获取业务对象的业务模型,并生成业务类型的操作命令和操作数据;

步骤204,将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例;

步骤206,分别在不同测试端上进行自动化用例的测试;

步骤208,接收任一测试端的调整信息,调整任一测试端对应的对业务类型、操作命令和操作数据的封装。

在该实施例中,在用例设计时只关注如何组织测试场景,使得场景用例可以在多个端复用,很大程度地节约测试工作量,当某个测试端改版时,也不必大量更新用例,调整任一测试端对应的对业务类型、操作命令和操作数据的封装即可,节约测试资源。

可选地,步骤204,将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例的步骤,具体包括:配置用例参数;针对不同测试端,将用例参数、业务类型、操作命令和操作数据针对不同测试端进行封装;组织测试步骤以及设定用例执行结果,以形成自动化用例。

可选地,步骤206,分别在不同测试端上进行自动化用例的测试的步骤,具体包括:选择待运行的测试环境和测试设备,以及设定运行参数;分别在不同测试端上进行自动化用例的测试。

图3示出了本发明的再一个实施例的自动化用例的测试方法的流程示意图。其中,该方法包括:

步骤302,获取业务对象的业务模型,并生成业务类型的操作命令和操作数据;

步骤304,将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例;

步骤306,分别在不同测试端上进行自动化用例的测试;

步骤308,将测试结果存储至日志,以及展示测试结果;

步骤310,接收任一测试端的调整信息,调整任一测试端对应的对业务类型、操作命令和操作数据的封装。

在该实施例中,收集测试用例执行产生的数据,选择性地持久化和分析,统一汇总到测试结果,可以使用kafka等消息中间件实现,其中kafka为一种高吞吐量的分布式发布订阅消息系统,测试结果统一汇集到日志服务收集整理,并从前端查看测试结果。

可选地,步骤304,将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例的步骤,具体包括:配置用例参数;针对不同测试端,将用例参数、业务类型、操作命令和操作数据针对不同测试端进行封装;组织测试步骤以及设定用例执行结果,以形成自动化用例。

可选地,步骤306,分别在不同测试端上进行自动化用例的测试的步骤,具体包括:选择待运行的测试环境和测试设备,以及设定运行参数;分别在不同测试端上进行自动化用例的测试。

本发明第二方面的实施例,提出一种自动化用例的测试系统,图4示出了本发明的一个实施例的自动化用例的测试系统40的示意框图。其中,该系统40包括:

存储器402,用于存储计算机程序;

处理器404,用于执行计算机程序以:

获取业务对象的业务模型,并生成业务类型的操作命令和操作数据;将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例;分别在不同测试端上进行自动化用例的测试。

本发明提供的自动化用例的测试系统40,根据业务对象抽象出可操作的业务模型,并提供操作命令和操作参数,针对不同测试端(例如接口、web、app等自动化工具),封装各测试端的业务类型、操作命令和操作数据,自动建立针对不同测试端的自动化用例。进一步地,在测试时分别在不同测试端上进行自动化用例的测试。采用本发明的技术方案,一方面,把测试用例通过业务模型针对不同测试端分离开来,并能适用多端多测试类型,可以降低自动化复杂度,提高用例复用性;另一方面,使得测试人员只关注业务流程和场景用例设计,不关注业务场景在多个测试端上的运行实现,能更好地设计出高覆盖度用例,提高自动化产出。

可选地,处理器404将业务类型、操作命令和操作数据针对不同测试端进行封装,建立自动化用例,具体包括:配置用例参数;针对不同测试端,将用例参数、业务类型、操作命令和操作数据针对不同测试端进行封装;组织测试步骤以及设定用例执行结果,以形成自动化用例。

在该实施例中,配置用例参数,用例参数包括用例需要用到的账号、账套信息、指定预置数据需要使用的辅助能力、用例如需在多环境运行还需要提供额外的账号配置管理能力。将用例参数、业务类型、操作命令和操作数据针对不同测试端进行封装,根据业务场景选取合适的业务模型组织测试步骤,以及通过业务模型的查询方法获取状态数据判断用例执行结果,最终形成自动化用例。对于测试用例设计来说,相关技术中自动化框架大多针对测试过程设计用例,涉及复杂场景、多角色、多功能交互,对于不同测试端设计测试用例,使得用例设计非常困难、测试人员浪费严重,而本发明的技术方案,只关注业务流程和场景用例设计,不关注业务场景在多个测试端上的运行实现,能更好地设计出高覆盖度用例。

可选地,处理器404分别在不同测试端上进行自动化用例的测试,具体包括:选择待运行的测试环境和测试设备,以及设定运行参数;分别在不同测试端上进行自动化用例的测试。

在该实施例中,选取需要运行的测试环境及测试设备,指定运行中的额外运行参数,例如用例的串并行、并发设备数、用例先后顺序、统一的初始化事件等参数。进一步地,分别在不同测试端上进行对应的自动化用例的测试,实现自动化用例的多端复用。

可选地,处理器404还用于执行计算机程序以:接收任一测试端的调整信息,调整任一测试端对应的对业务类型、操作命令和操作数据的封装。

在该实施例中,在用例设计时只关注如何组织测试场景,使得场景用例可以在多个端复用,很大程度地节约测试工作量,当某个测试端改版时,也不必大量更新用例,调整任一测试端对应的对业务类型、操作命令和操作数据的封装即可,节约测试资源。

可选地,处理器404还用于执行计算机程序以:将测试结果存储至日志,以及展示测试结果。

在该实施例中,收集测试用例执行产生的数据,选择性地持久化和分析,统一汇总到测试结果,可以使用kafka等消息中间件实现,其中kafka为一种高吞吐量的分布式发布订阅消息系统,测试结果统一汇集到日志服务收集整理,并从前端查看测试结果。

对于单个产品或某个领域业务流程相同、类似的产品,接口、web、app自动化用例需要覆盖的很多场景是大同小异的,例如用户的注册流程,在接口上实现注册只需调用接口传入适当的参数,对于web端和app端需要操作不同的浏览器执行复杂的操作,对于注册行为而言,测试者关注的是注册场景的可用性及错误场景覆盖、不同端的业务兼容性等,不同端上执行注册、输入和输出的预期都是相同的,不同之处只是在于调用端的方法、步骤不同,如果用例设计者只关注如何组织测试场景、场景用例可以在多个端复用,能在很大程度上节约测试工作量,当某个端改版时,也不必大量更新用例,以节约测试资源。本发明的具体实施例中提出一种自动化用例多端复用的装置,如图5所示,该装置包括:

模型层502:针对产品常用、公用的业务对象抽取出业务模型,并根据业务模型提供对应的操作方法,指定输入和校验数据类型,供使用者来组织测试用例,例如销货单包括增、删、改、查、审批等操作,每种操作的步骤和需要的数据都是不同的。

实现层504:对于每个提供的业务模型及对应操作,在不同端上操作的内容是不同的,例如销货单新增可以通过paas(platformasaservice,平台即服务)接口实现也可以通过saas(softwareasaservice,软件即服务)接口实现,也可以通过web端ui和app端ui实现,如果销货单的新增行为能够在多端运行,那么需要实现不同端上的操作方法。

驱动层506:为实现层504提供产品实际操作方法的封装和支持,例如接口配置和调用、ui的页面封装、元素查找和操作等。

执行层508:实际执行用例的部分,可以执行来自驱动层506传达的任务,例如接口调用用到的第三方库、web端用到的selenium驱动器等。

管理系统510:为装置提供其他能力,帮助实现账号管理、用例管理、设备管理、运行管理、结果收集展示、数据准备等,帮助测试用例较好的支持分布式运行及特殊用例、账号串行。

该装置的开发步骤包括:

(1)根据产品业务抽象出可操作的业务模型,提供操作命令格式和参数结构。

(2)针对接口、web、app等自动化工具,分别实现驱动方法和备操作元件管理,方便后续维护。

(3)封装各端的驱动方法实现业务模型及相应操作,根据传入的数据实现模型的业务调用。

(4)提供测试运行需要的账号、设备等管理工具,供用例设计使用。

(5)根据业务模型可用的方法设计测试用例,并输入到装置中运行测试。

测试用例的设计步骤包括:

(1)指定用例需要用到的账号、账套信息,指定预置数据需要使用的辅助能力,用例如需在多环境运行还需要提供额外的账号配置管理能力。

(2)根据业务场景选取合适的业务模型组织测试步骤形成测试用例。

(3)通过业务模型的查询方法获取状态数据判断用例执行结果。

(4)设置用例执行后的清理动作。

测试用例的执行步骤包括:

(1)选取需要执行的用例。

(2)选取需要运行的测试环境及测试设备。

(3)指定运行中的额外参数,例如用例的串、并行,并发设备数、用例先后顺序、统一的初始化事件等。

(4)启动测试并查看执行状态和执行结果。

本发明具体实施例的技术方案可使用常用的高级语言如java、python来开发,可使用最新版的selenium、appium等来做ui自动化,接口测试对单元框架没有特殊要求,使用junit、testng、unittest或其他java语言的测试框架都可以。本发明具体实施例的技术方案包括以下内容:

(1)运行节点,通过web服务的形式实现执行端服务,例如flask作为测试运行节点的管理服务,flask为轻量级web应用框架,对外提供测试启动接口、测试管理接口、能力查询接口,通过接口调用得到用例步骤执行测试,执行过程中测试结果传达给日志服务供结果收集和分析。

(2)注册中心,使用公共的注册中心和缓存作为用例执行端注册管理和过程数据共享的支持,例如zk(zookeeper)和redis,执行端启动后注册到zk上并汇报本节点能够支持的测试范围和测试端类型,zk为一个分布式的、开放源码的分布式应用程序协调服务,redis为一个数据库。

(3)测试设备管理,为了支持测试用例并行,需要对测试设备进行管理,接口层可用web服务实现,app端可以使用stf等开源工具,同样实现设备注册,供测试使用,其中stf为移动设备管理控制工具。

(4)日志收集,收集测试用例执行产生的数据,选择性地持久化和分析,统一汇总到测试结果,可以使用kafka等消息中间件实现,消息处理需要单独的服务实现。

(5)用例开发和管理、运行,提供统一的前端用于用例开发、编辑和运行,通过其他服务汇集的数据提供可运行资源,例如账号、设备、环境等,并能查看测试结果。

(6)其他辅助,管理环境、账号、设备等配置信息,提供公用的数据操作、初始化、清理接口,在执行测试时简化测试步骤,每条用例可以只关心当前测试点和测试流程。

(7)自动化驱动,针对不同端选取高效的驱动工具,由运行节点调用执行测试,例如seleniumserver、requests、appiumserver等。

(8)节点管理和部署,使用容器化管理方式,结合jenkins自动化部署实现节点快速部署和扩容,其中jenkins是一个开源软件项目。

以销货单核销为例,销货单销售后需要收款,核销后体现在多张报表中,装置针对销货单、收款单、报表等模型封装后提供给使用者,使用者组装多种模型,通过不同的传入数据覆盖多种核销场景,使用装置指定ui和接口分别运行用例,由于账号、账套限制,同样的一条用例在ui和接口排队运行,但不同的用例可以并行。装置根据传入的模型和数据调用底层驱动完成测试,结果统一汇集到日志服务收集整理,并从前端查看运行结果。如果销货单web端ui调整,但是现有业务流程不受影响,那么调整销货单对应操作方法的实现层代码,保证已有用例的可用性即可。对于相关技术中的自动化方式,实现销货单核销查询,需要分别在接口、web、app使用不同工具和用例实现方法实现,使用本发明的装置只需设计唯一的用例即可。

由于理解和使用上的惯性,测试人员常常把ui自动化和接口自动化都分别执行、独立又绝缘,本发明的技术方案能够使得ui自动化和接口自动化能结合在一起执行,达到提高执行效率、提高测试覆盖面的目的。

对于测试用例设计来说,现有自动化框架大多针对测试过程设计用例,涉及复杂场景多角色、多功能交互的用例设计非常困难,分别对于不同端设计测试用例对人员浪费严重,把测试用例通过测试模型分离开来,并能适用多端多测试类型,可以很大的节约自动化复杂度,提高用例复用性

本发明第三方面的实施例,提出了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现如上述任一实施例的自动化用例的测试方法的步骤。

本发明提供的计算机可读存储介质,计算机程序被处理器执行时实现如上述任一实施例的自动化用例的测试方法的步骤,因此该计算机可读存储介质包括上述任一实施例的自动化用例的测试方法的全部有益效果。

在本说明书的描述中,术语“第一”、“第二”仅用于描述的目的,而不能理解为指示或暗示相对重要性,除非另有明确的规定和限定;术语“连接”、“安装”、“固定”等均应做广义理解,例如,“连接”可以是固定连接,也可以是可拆卸连接,或一体地连接;可以是直接相连,也可以通过中间媒介间接相连。对于本领域的普通技术人员而言,可以根据具体情况理解上述术语在本发明中的具体含义。

在本说明书的描述中,术语“一个实施例”、“一些实施例”、“具体实施例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不一定指的是相同的实施例或实例。而且,描述的具体特征、结构、材料或特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

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

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1