软件测试方法、装置、设备及存储介质与流程

文档序号:17441845发布日期:2019-04-17 04:52阅读:126来源:国知局
软件测试方法、装置、设备及存储介质与流程

本发明涉及软件软件测试技术领域,尤其涉及一种软件测试方法、装置、设备及存储介质。



背景技术:

对于多版本软件的软件测试,现有技术主要通过分别在不同物理机或不同虚拟机上进行不同版本的软件的软件测试,即在一台主机上运行一个版本软件的测试,或在一台主机上运行不同虚拟机,各个虚拟机运行一个版本软件测试,即进行多版本软件的测试需要耗费的硬件资源太多,损耗部分主机性能,导致启动及停止速度慢。

因此,如何减少多版本软件软件测试的资源消耗成为亟待解决的问题。



技术实现要素:

本发明的主要目的在于提供一种软件测试方法,旨在解决现有多版本软件测试中资源消耗过大的技术问题。

为实现上述目的,本发明提供一种软件测试方法,其特征在于,所述软件测试方法包括以下步骤:

在检测到启动测试指令时,获取所述启动测试指令对应的待测试项目、所述待测试项目的版本和版本数量;

确定各个待测试项目对应的测试目录,生成与所述版本数量对应数量的测试指令;

根据所述测试指令从所述测试目录下调用对应后台服务进行测试。

可选地,所述在检测到启动测试指令时,获取所述启动测试指令对应的待测试项目、所述待测试项目的版本和版本数量的步骤之前包括:

获取所有版本的待测试项目,为各版本待测试项目创建对应的测试目录。

可选地,所述在检测到启动测试指令时,获取所述启动测试指令对应的待测试项目、所述待测试项目的版本和版本数量的步骤之前包括:

获取所有版本的待测试项目,并获得各版本待测试项目的依赖包文件,基于各版本待测试项目对应的依赖包文件获取各版本待测试项目的依赖包;

将各版本待测试项目的依赖包进行对比,获取各版本待测试项目间的共用依赖包和冲突依赖包;

为所述共用依赖包创建共用目录,为各所述冲突依赖包分别创建各自的独立目录。

可选地,所述为各版本待测试项目创建对应的测试目录的步骤之后包括:

为各个所述待测试项目部署对应的基础环境;

在各个所述待测试项目各自对应的测试目录下安装各自的依赖包,并生成各个所述待测试项目对应的项目文件。

可选地,所述生成各个所述待测试项目对应的项目文件的步骤之后包括:

在检测到迁移指令时,获取所述项目文件;

基于所述项目文件安装对应的依赖包,以生成对应的待测试项目。

可选地,所述软件测试方法还包括:

在检测到用户点击任意所述测试目录的点击指令时,输出是否切换基础环境的提示;

当接收到用户基于所述提示输入的切换指令时,从所述测试目录中调用环境初始化脚本,切换到所述测试目录对应待测试项目的基础环境。

可选地,所述根据所述测试指令从所述测试目录下调用对应后台服务进行测试的步骤包括:

根据各待测试项目各自的测试指令从各自的测试目录下获取项目文件,并基于项目文件调用各待测试项目对应后台服务,其中,所述对应后台服务包括待测试项目测试所需依赖包、运行环境。

此外,为实现上述目的,本发明还提供一种软件测试装置,所述软件测试装置包括:

检测启动模块,用于在检测到启动测试指令时,获取所述启动测试指令对应的待测试项目、所述待测试项目的版本和版本数量;

测试指令生成模块,用于确定各个待测试项目对应的测试目录,生成与所述版本数量对应数量的测试指令;

测试模块,用于根据所述测试指令从所述测试目录下调用对应后台服务进行测试。

此外,为实现上述目的,本发明还提供一种软件测试设备,所述软件测试设备包括处理器、存储器、以及存储在所述存储器上并可被所述处理器执行的软件测试程序,其中所述软件测试程序被所述处理器执行时,实现如上述的软件测试方法的步骤。

此外,为实现上述目的,本发明还提供一种存储介质,所述存储介质上存储有软件测试程序,其中所述软件测试程序被处理器执行时,实现如上述的软件测试方法的步骤。

本发明实施例通过在检测到启动测试指令时,获取所述启动测试指令对应的待测试项目、所述待测试项目的版本和版本数量;确定各个待测试项目对应的测试目录,生成与所述版本数量对应数量的测试指令;根据所述测试指令从所述测试目录下调用对应后台服务进行测试,通过为不同版本待测试项目创建专属于各待测试项目的测试目录,对不同版本待测试项目的测试环境进行隔离,为各待测试项目创建所需运行环境和提供所需依赖包,实现对冲突依赖包的精准调用,以保证待测试项目顺利进行测试,实现在一台主机/虚拟机上支撑具有相同调用命令的不同软件包的测试,减少测试资源的消耗。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的软件测试设备结构示意图;

图2为本发明软件测试方法第一实施例的流程示意图;

图3为本发明软件测试方法第一实施例中创建测试目录的一实施例的流程示意图;

图4为本发明软件测试装置第一实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。

具体实施方式

应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。

请参见图1,图1为本发明所提供的软件测试设备的硬件结构示意图。

所述软件测试设备可为电梯控制设备,可以是pc,也可以是智能手机、平板电脑、便携计算机、台式计算机等设备,可选地,所述软件测试设备可以是服务器设备,存在软件测试的后端管理系统,用户通过所述后端管理系统对软件测试设备进行管理。

所述软件测试设备可以包括:处理器101以及存储器201等部件。在所述软件测试设备中,所述处理器101与所述存储器201连接,所述存储器201上存储有软件测试程序,处理器101可以调用存储器201中存储的软件测试程序,并实现如下述软件测试方法各实施例的步骤。

所述存储器201,可用于存储软件程序以及各种数据。存储器201可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序(比如软件测试程序)等。此外,存储器201可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器101,是软件测试设备的控制中心,利用各种接口和线路连接整个软件测试设备的各个部分,通过运行或执行存储在存储器201内的软件程序和/或模块,以及调用存储在存储器201内的数据,执行软件测试设备的各种功能和处理数据,从而对软件测试设备进行整体监控。处理器101可包括一个或多个处理单元;可选地,处理器101可集成应用处理器和调制解调处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等,调制解调处理器主要处理无线通信。可以理解的是,上述调制解调处理器也可以不集成到处理器101中。

本领域技术人员可以理解,图1中示出的软件测试设备结构并不构成对软件测试设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。

可选地,本发明提出的软件测试方法对应的软件测试程序配置于测试系统中,所述测试系统具有测试界面,以供用户基于测试界面进行软件测试。

基于上述硬件结构,提出本发明方法各个实施例,下文中的“测试设备”为软件测试设备的简称。

本发明提供一种软件测试方法。

参照图2,图2为本发明软件测试方法第一实施例的流程示意图。

在本发明软件测试方法第一实施例中,所述软件测试方法包括以下步骤:

步骤s10,在检测到启动测试指令时,获取所述启动测试指令对应的待测试项目、所述待测试项目的版本和版本数量;步骤s20,确定各个待测试项目对应的测试目录,生成与所述版本数量对应数量的测试指令;步骤s30,根据所述测试指令从所述测试目录下调用对应后台服务进行测试。

为便于理解本发明,对执行上述步骤的先行步骤进行描述,即本发明软件测试方法在所述步骤s10之前还包括:

步骤s40,获取所有版本的待测试项目,为各版本待测试项目创建对应的测试目录。

本实施例中,对待测试项目的测试发生在同一台物理机或虚拟机上,因目录创建步骤也发生在一台物理机或虚拟机上。

同一待测试项目,可能具有不同版本,此处的不同版本可以指不同编程语言的软件包,和/或具有不同要求的不同区域的软件包(eg:大陆vs香港),和/或不同版本的软件包,和/或不同自然语言的软件包(eg:中英文)。

待测试项目对应的测试目录,指安装待测试项目测试所需的测试软件、依赖包以及安装/基础环境脚本程序等的目录。待测试项目可能调用多个依赖包,如yum源、sshd、apt-get源、创建用户、配置用户密码等。不同版本的待测试项目可能调用一个或多个不同版本的依赖包。

可以根据用户操作为各版本待测试项目创建对应的测试目录,也可以由调用预置的配置文件自动为各版本待测试项目创建对应的测试目录,所述配置文件包括所需创建的项目/软件包的名称、对应版本。

通过为各版本待测试项目创建对应的测试目录,实现各待测试项目之间测试的隔离,实现在一台主机或一个虚拟机上即可实现多个待测试项目的同时测试。

进一步地,步骤s40之后包括:

步骤s41,为各个所述待测试项目部署对应的基础环境;

待测试项目的基础环境,指待测试项目正常运行测试所基于的安装/运行环境,例如配置主机名、集群用户管理、配置集群共享目录等,在进入到待测试项目对应的测试目录后,调用所述待测试项目的环境初始化脚本,切换到所述待测试项目的基础环境,以保障后续待测试项目的正常测试。

不同版本的待测试项目可能具有不同的安装环境或运行环境,因此,在安装待测试项目下的测试软件或依赖包之前,需要针对不同版本的待测试项目部署对应的基础环境。

步骤s42,在各个所述待测试项目各自对应的测试目录下安装各自的依赖包,并生成各个所述待测试项目对应的项目文件。

预先安装待测试项目测试所需的依赖包,以供后续测试顺利进行。

项目文件,包括待测试项目的安装过程日志,其中包括待测试项目所使用的依赖包,在检测到待测试项目安装、卸载一个或多个软件包时,自动更新该项目文件,项目文件还包括基础环境初始化脚本。

通过为各个所述待测试项目部署对应的基础环境,在各个所述待测试项目各自对应的测试目录下安装各自的依赖包,并生成各个所述待测试项目对应的项目文件,以供后续测试待测试项目时,顺利调用运行测试。

或,

为减少安装资源及存储资源的消耗,进一步提出:

如图3,在所述步骤s10之前,软件测试方法还包括:步骤s50,获取所有版本的待测试项目,并获得各版本待测试项目的依赖包文件,基于各版本待测试项目对应的依赖包文件获取各版本待测试项目的依赖包;

依赖包文件中包含对应的待测试项目的依赖包,可从中获得各版本待测试项目的依赖包。如果待测试项目一调用的依赖包a版本要求为1.5版本,而待测试项目二用到的依赖包a要求为2.7版本,则1.5版本的依赖包与2.7版本的依赖包就会产生冲突,即本实施例中的冲突依赖包。

步骤s51,将各版本待测试项目的依赖包进行对比,获取各版本待测试项目间的共用依赖包和冲突依赖包;

共用依赖包,即各版本待测试项目所使用的无冲突的软件包,冲突依赖包,即各版本待测试项目所使用的有冲突、无法在同一目录下共存的软件包。

步骤s52,为所述共用依赖包创建共用目录,为各所述冲突依赖包分别创建各自的独立目录。

若多个待测试项目使用的所有依赖包中只有一组或少数组冲突依赖包,则对其中的任意一组冲突依赖包,都执行:为一组冲突依赖包中的各冲突依赖包分别创建不同目录,以将属于一组的冲突依赖包隔离开,并将多个项目使用的冲突依赖包以外的依赖包安装到一个目录下,以减少重复创建时内存资源和运行资源的消耗。共用依赖包,即非冲突依赖包,即在调用共用依赖包时,不会产生软件冲突。

例如,待测试项目一和待测试项目二各有100个依赖包,其中,只有一组冲突依赖包、其他依赖包都相同(即为99个共用包),若只为待测试项目一和待测试项目二分别创建对应的目录一、目录二,则目录一中要安装待测试项目一的所有依赖包(100个依赖包)、目录二中要安装待测试项目二的所有依赖包(100个依赖包),总共安装200个依赖包。在本实施例中,为减少资源消耗,创建三个目录,一个为共用目录,用于安装共用依赖包(99个共用依赖包),其中一个目录用于安装待测试项目一的冲突依赖包(1个依赖包),另一目录用于安装待测试项目二的冲突依赖包(1个依赖包),则一共只安装了101个依赖包,大大减少了安装总量,也减少了快速迁移待测试项目时,迁移的数据量。

为所述共用依赖包创建共用目录,在运行待测试项目时,若要调用共用依赖包,则进入共用目录,调用对应的共用依赖包;为各所述冲突依赖包分别创建各自的独立目录,在运行待测试项目时,若要调用冲突依赖包,则进入独立目录,调用对应的冲突依赖包。通过为冲突依赖包创建专属于各冲突依赖包的对应目录,对冲突依赖包进行隔离,实现调用所需的冲突依赖包,实现对待测试软件的精准调用。

进一步地,步骤s51之后包括:

为所述共用目录部署所述共用依赖包的基础环境,为所述独立目录部署对应冲突依赖包的基础环境;在所述共用目录下安装所述共用依赖包,在所述独立目录下安装各自对应的冲突依赖包,并生成各所述待测试项目对应的项目文件。

待测试项目的基础环境,指待测试项目正常运行测试所基于的安装/运行环境,例如配置主机名、集群用户管理、配置集群共享目录等,在进入到待测试项目对应的测试目录后,调用所述待测试项目的环境初始化脚本,切换到所述待测试项目的基础环境,以保障后续待测试项目的正常测试。

不同版本的待测试项目可能具有不同的安装环境或运行环境,因此,在安装待测试项目下的测试软件或依赖包之前,需要针对不同版本的待测试项目部署对应的基础环境。

项目文件,包括待测试项目的安装过程日志,其中包括待测试项目所使用的依赖包,在检测到待测试项目安装、卸载一个或多个软件包时,自动更新该项目文件,项目文件还包括基础环境初始化脚本。

基于上述描述,所述软件测试方法具体包括:

步骤s10,在检测到启动测试指令时,获取所述启动测试指令对应的待测试项目、所述待测试项目的版本和版本数量;

启动测试指令可以由用户点击测试控件触发,也可由测试系统自行触发。

一实施例中,待测试项目预先配置于测试设备,配置于测试设备上的测试系统可调用待测试项目进行测试管理,测试系统的测试界面上可输出待测试项目列表,可由用户在测试系统给出的待测试项目列表中选择多个待测试项目进行测试,可选地,也可由测试系统自动对各待测试项目执行测试。其中,用户在点击待测试项目列表中任意待测试项目时,会触发生成启动测试指令。

启动测试指令包含用户选定的待测试项目,解析启动测试指令即可获取所有待测试项目相关信息,包括所有待测试项目的版本以及多少个不同版本的待测试项目,即版本数量。

步骤s20,确定各个待测试项目对应的测试目录,生成与所述版本数量对应数量的测试指令;

解析启动测试指令还可获得各待测试项目对应的测试目录地址,确定各待测试项目测试所需依赖包、环境脚本、项目文件等所在目录。

生成与各待测试项目对应的测试指令,即对每个待测试项目生成各自的测试指令,以触发各待测试项目的同时启动测试。

步骤s30,根据所述测试指令从所述测试目录下调用对应后台服务进行测试。

对于各待测试项目,根据各待测试项目各自的测试指令从各自的测试目录下获取项目文件,并基于项目文件调用各待测试项目对应后台服务,后台服务包括待测试项目测试所需依赖包、运行环境等。

在各待测试项目的目录中,调用对应后台服务后,即切换到对应的运行环境,以供对应的待测试项目进行测试。在运行测试的过程中,当检测到依赖包调用请求时,从待测试项目对应的测试目录下调用依赖包调用请求对应的依赖包。

此处不对测试的具体类型进行限定,本领域技术人员可以灵活选择,也就是说,本发明实施例提供的软件测试方法可以应用于多种测试场景,例如系统兼容性测试、软件最大支持节点数测试、软件稳定性测试、可移植性、高负载测试等。

本发明实施例通过在检测到启动测试指令时,获取所述启动测试指令对应的待测试项目、所述待测试项目的版本和版本数量;确定各个待测试项目对应的测试目录,生成与所述版本数量对应数量的测试指令;根据所述测试指令从所述测试目录下调用对应后台服务进行测试,通过为不同版本待测试项目创建专属于各待测试项目的测试目录,对不同版本待测试项目的测试环境进行隔离,为各待测试项目创建所需运行环境和提供所需依赖包,实现对冲突依赖包的精准调用,以保证待测试项目顺利进行测试,实现在一台主机/虚拟机上支撑具有相同调用命令的不同软件包的测试,减少测试资源的消耗。

进一步地,所述步骤s42之后包括:

步骤s42,在检测到迁移指令时,获取所述项目文件;

步骤s43,基于所述项目文件安装对应的依赖包,以生成对应的待测试项目。

迁移指令指将待测试项目迁移到测试设备的指令,因为项目文件中包括待测试项目的安装过程日志,待测试项目所使用的依赖包,以及待测试项目的环境初始化脚本程序。

因此,在进行项目迁移时,从项目文件获取安装日志以及所需安装的依赖包、环境初始化脚本程序,自动生成待测试项目。

本实施例可通过在检测到迁移指令时,获取所述项目文件;基于所述项目文件安装对应的依赖包,以生成对应的待测试项目,实现待测试项目的快速迁移,无需用户手动创建,节省了繁琐的测试项目创建步骤。

进一步地,所述软件测试方法还包括:

步骤s60,在检测到用户点击任意所述测试目录的点击指令时,输出是否切换基础环境的提示;

在用户手动操作进入任意待测试项目对应的测试目录下时,因为无法自主判断用户是否有测试需要,因此输出是否切换基础环境的提示,以接收用户自定义需求,提升测试系统的智能化。

步骤s61,当接收到用户基于所述提示输入的切换指令时,从所述测试目录中调用环境初始化脚本,切换到所述测试目录对应待测试项目的基础环境。

在接收到用户输入的切换指令,则根据用户需求切换到当前进入的待测试项目的基础环境,所有的安装,卸载,执行命令都只对该待测试项目下的代码生效。

为便于理解,现结合具体的路径示例,对上述方案进行解释说明。

本示例要实现的目的是:测试软件在python2和python3两个语言版本上、三个区域版本的运行效果。现有技术中,通常需要准备六台测试/开发机器(物理机/虚拟机),将python2、python3与三个区域版本软件包分别安装到六台测试/开发机器的/usr/lib/python/site-package目录下。

本示例中,

(1)在一台物理机/虚拟机下,创建多级目录,第一级是语言py2、py3,第二级是软件名称(例如本示例中为nspmonitor),第三级是三个区域版本的软件。将各语言版本、区域版本的待测试软件对应的软件包分别安装到对应的目录之下,例如,将py2|香港a版本软件存储在/home/py2/nspmonitor/nspmonitor_hka/lib/python2.7路径下,每个软件包都带有版本号,如alembic-0.8.9.dist-info指0.8.9版本的alembic。

py2/py3下可能包含多个与nspmonitor处于同一级别的软件,例如,py2|py3,下一级是app1|app2|app3|appn,每个app下面又可以分区域app1_region1|app1_region2....|app1_regionn。

nspmonitor具有不同的区域版本:nspmonitor_hka(香港a)、nspmonitor_hkb(香港b)、nspmonitor_sz1(智慧城市1),区域版本指根据区域定制化需求进行功能调整后的不同区域版本的同名称软件,软件可能不一样,不能共用。

(2)通过走到不同目录下的相同命令中,可实现对不同app的调用,格式为:

使用某个python版本/调用软件的某个命令

例如:/home/py2/nspmonitor/nspmonitor_hka/bin/nspmonitor

其中,py2(可为py3)指的python的大版本,包括python2.7|python2.8|python2.6...等具体小版本;nspmonitor是一个软件名称,可以是任意软件;nspmonitor_hka指软件名_区域版本;最后的“nspmonitor”指调用软件的某个具体命令,可以是该软件支持的任意命令。

此外,本发明还提供一种与上述软件测试方法各步骤对应的软件测试装置。

参照图4,图4为本发明软件测试装置第一实施例的功能模块示意图。

在本实施例中,本发明软件测试装置包括:

检测启动模块10,用于在检测到启动测试指令时,获取所述启动测试指令对应的待测试项目、所述待测试项目的版本和版本数量;

测试指令生成模块20,用于确定各个待测试项目对应的测试目录,生成与所述版本数量对应数量的测试指令;

测试模块30,用于根据所述测试指令从所述测试目录下调用对应后台服务进行测试。

进一步地,所述软件测试装置还包括:

第一目录创建模块,用于获取所有版本的待测试项目,为各版本待测试项目创建对应的测试目录。

进一步地,所述软件测试装置还包括:

第二目录创建模块,用于获取所有版本的待测试项目,并获得各版本待测试项目的依赖包文件,基于各版本待测试项目对应的依赖包文件获取各版本待测试项目的依赖包;将各版本待测试项目的依赖包进行对比,获取各版本待测试项目间的共用依赖包和冲突依赖包;为所述共用依赖包创建共用目录,为各所述冲突依赖包分别创建各自的独立目录。

进一步地,所述软件测试装置还包括:

测试配置模块,用于为各个所述待测试项目部署对应的基础环境;

在各个所述待测试项目各自对应的测试目录下安装各自的依赖包,并生成各个所述待测试项目对应的项目文件。

进一步地,所述软件测试装置还包括:

迁移模块,用于在检测到迁移指令时,获取所述项目文件;基于所述项目文件安装对应的依赖包,以生成对应的待测试项目。

进一步地,所述软件测试装置还包括:切换模块,用于在检测到用户点击任意所述测试目录的点击指令时,输出是否切换基础环境的提示;当接收到用户基于所述提示输入的切换指令时,从所述测试目录中调用环境初始化脚本,切换到所述测试目录对应待测试项目的基础环境。

进一步地,所述测试模块30,还用于根据各待测试项目各自的测试指令从各自的测试目录下获取项目文件,并基于项目文件调用各待测试项目对应后台服务,其中,所述对应后台服务包括待测试项目测试所需依赖包、运行环境。

本发明还提出一种存储介质,其上存储有计算机程序。所述存储介质可以是图1的软件测试设备中的存储器201,也可以是如rom(read-onlymemory,只读存储器)/ram(randomaccessmemory,随机存取存储器)、磁碟、光盘中的至少一种,所述存储介质包括若干指令用以使得一台具有处理器的设备(可以是手机,计算机,服务器,网络设备或本发明实施例中的软件测试设备等)执行本发明各个实施例所述的方法。

需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者服务端不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者服务端所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者服务端中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。

通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。

以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。

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