一种软件测试方法及系统
【技术领域】
本方案涉及软件测试技术领域,尤其涉及一种软件测试方法及系统。
【背景技术】
软件测试是每一版软件正式发布前,都必需多次、反复进行的一个测试验证步骤。目前软件测试的普遍做法是:软件工程师完成软件编译后,提请软件测试请求,输出软件包给软件测试工程师,软件测试工程使用下载工具把软件包下载到手机等移动设备中,然后,软件测试工程师按照测试用例手动操作手机,完成软件功能的测试验证,手动记录测试验证结果、并提交到测试bug管理系统,把测试结果反馈给工程师,由软件工程师完成bug的修改和性能优化,并重新输出软件给软件测试工程师测试,由此周而复始,直到软件验证通过。
在实现本方案过程中,发明人发现现有技术中至少存在如下问题:
实现软件测试需要一个庞大的测试工程师队伍,人力投入成本高;庞大的测试队伍需要装备庞大的测试样机,硬件投入成本也高;测试工程师只能白天上班,相对于自动测试系统,测试效率低50%以上。
【发明内容】
有鉴于此,本方案实施例提供了一种,用以解决当前软件测试效率低的技术问题。
第一方面,本方案实施例提供一种一种软件测试系统,包括:
至少一个操作终端,每个操作终端通过网络登录到测试控制终端的下载控制平台,通过所述下载控制平台选择测试终端、测试用例安装包,上传待测的软件包后向所述测试控制终端发送测试请求;
测试控制终端,与多个测试终端连接,通过下载控制平台收到任一操作终端发送的测试请求后,将该操作终端上传的软件包和选择的测试用例安装包下载到该操作终端选择的测试终端;
多个测试终端,每个测试终端收到软件包和对应的测试用例安装包后,通过测试用例安装包安装测试用例应用程序,通过所述软件包安装测试软件,在测试软件运行过程中通过所述测试用例应用程序对所述测试软件进行测试,生成软件测试报告。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述测试控制终端上有多个下载控制平台,每个下载控制平台对应连接多个测试终端;
所述每个操作终端还用于选择要登录的下载控制平台,根据所述下载控制平台连接的测试终端进行测试终端选择。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,该系统还包括:
Web服务器,所述每个操作终端通过所述web服务器与所述测试控制终端连接,所述web服务器用于实现所述每个操作终端与测试控制终端之间的通信。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,该系统还包括:
数据库服务器,与测试控制终端和web服务器连接,所述web服务器用于实现所述数据库服务器和测试控制终端间的通信,所述数据库服务器用于保存支持所述下载控制平台运行所需的数据,所述支持下载控制平台运行所需的数据包括测试终端信息、测试用例安装包、每个操作终端所选择的测试终端及测试用例安装包。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述测试控制终端,采用定时处理的方式,确定每个未被响应的测试请求指向的测试终端,在一个测试终端对应多个测试请求时,按照设定规则排队处理;在定时处理时,响应测试请求的方式为向处于空闲态的测试终端下载软件包和测试用例安装包。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述测试控制终端,还用于维护每个下载控制平台接收的测试请求的状态、测试终端的状态、测试终端进行软件包下载时的下载测试状态,根据所述维护的测试请求的状态,确定未被响应的测试请求,根据所维护测试终端的下载测试状态更新测试终端的状态,根据所维护的测试终端的状态确定出处于空闲态的测试终端。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述测试请求的状态包括请求状态、处理状态完成状态和失败状态,在测试终端未响应该测试请求开始下载软件包时为请求状态,在测试终端响应该测试请求的过程为处理状态,在测试终端成功响应该测试请求生成软件测试报告时为完成状态,在测试终端未成功响应该测试请求时为失败状态;
每个测试终端的下载测试状态包括完成态、忙态、失败态,其中,所述测试终端响应测试请求的过程为忙态,测试终端未成功响应该测试请求时为失败态,否则为完成态;
每个测试终端的状态包括空闲态、忙态和故障态,其中,在下载测试状态为完成态时所述测试终端的状态为空闲态,在下载测试状态为失败态时所述测试终端的状态为故障态,在下载测试状态为忙态时所述测试终端的状态为忙态。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述测试控制终端,还用于从测试终端获取软件测试报告并获取软件测的对应的测试用例模板,利用所述测试用例模板对软件测试结果中的测试bug进行解析,将bug信息录入到相应的bug管理系统。
第二方面,本方案实施例提供一种软件测试方法,其特征在于,包括:
操作终端通过网络登录到测试控制终端的下载控制平台,通过所述下载控制平台选择测试终端、测试用例安装包,上传待测的软件包后向所述测试控制终端发送测试请求;
所述测试控制终端通过下载控制平台收到任一操作终端发送的测试请求后,将该操作终端上传的软件包和选择的测试用例安装包下载到该操作终端选择的测试终端;
每个测试终端收到软件包和对应的测试用例安装包后,通过测试用例安装包安装测试用例应用程序,通过所述软件包安装测试软件,在测试软件运行过程中通过所述测试用例应用程序对所述测试软件进行测试,生成软件测试报告。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述测试控制终端上有多个下载控制平台,每个下载控制平台对应连接多个测试终端,则:
所述每个操作终端通过网络选择要登录的下载控制平台,根据所述下载控制平台连接的测试终端进行测试终端选择
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述测试控制终端,采用定时处理的方式,确定每个未被响应的测试请求指向的测试终端,在一个测试终端对应多个测试请求时,按照设定规则排队处理;在定时处理时,响应测试请求的方式为向处于空闲态的测试终端下载软件包和测试用例安装包。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,该方法还包括:
所述测试控制终端维护每个下载控制平台接收的测试请求的状态、测试终端的状态、测试终端进行软件包下载时的下载测试状态;
则所述测试控制终端根据所述维护的测试请求的状态,确定未被响应的测试请求,根据所维护测试终端的下载测试状态更新测试终端的状态,根据所维护的测试终端的状态确定出处于空闲态的测试终端。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,所述测试请求的状态包括请求状态、处理状态完成状态和失败状态,在测试终端未响应该测试请求开始下载软件包时为请求状态,在测试终端响应该测试请求的过程为处理状态,在测试终端成功响应该测试请求生成软件测试报告时为完成状态,在测试终端未成功响应该测试请求时为失败状态;
每个测试终端的下载测试状态包括完成态、忙态、失败态,其中,所述测试终端响应测试请求的过程为忙态,测试终端未成功响应该测试请求时为失败态,否则为完成态;
每个测试终端的状态包括空闲态、忙态和故障态,其中,在下载测试状态为完成态时所述测试终端的状态为空闲态,在下载测试状态为失败态时所述测试终端的状态为故障态,在下载测试状态为忙态时所述测试终端的状态为忙态。
如上所述的方面和任一可能的实现方式,进一步提供一种实现方式,该方法还包括:
所述测试控制终端从测试终端获取软件测试报告并获取软件测的对应的测试用例模板,利用所述测试用例模板对软件测试结果中的测试bug进行解析,将bug信息录入到相应的bug管理系统。
本发明实施例具有以下有益效果:
通过建立一个测试系统,实现远程控制测试终端进行软件包下载、自动测试从而获得测试报告,代替软件测试工程师的手动操作;
可以实现无人值守,自动完成软件下载、自动测试控制,并上报测试结果,可实现24小时运转,大大提高测试效率;
同一个下载控制平台可同时控制不同的测试终端分别下载不同的软件包和不同的测试用例,分别完成自动测试,并分别上报测试结果。
【附图说明】
为了更清楚地说明本方案实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本方案的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其它的附图。
图1为本发明实施例提供一种软件测试系统框图;
图2为本发明实施例提供的一种软件测试方法流程图;
图3本发明实施例提供的一种软件测试方法详细流程图。
【具体实施方式】
为了更好的理解本方案的技术方案,下面结合附图对本方案实施例进行详细描述。
应当明确,所描述的实施例仅仅是本方案一部分实施例,而不是全部的实施例。基于本方案中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例,都属于本方案保护的范围。
在本方案实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本方案。在本方案实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。
应当理解,本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地,取决于语境,短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。
本发明提高一种软件测试方法及系统,实现手机软件自助下载和实现测试包的自助下载、安装和启动运行,自动完成软件功能性测试,并获取测试报告,达到代替软件工程师手动完成软件测试的目的,大大提高了测试效率。
实施例一
本实施例提供一种软件测试系统,如图1所示,包括:
至少一个操作终端101,每个操作终端通过网络登录到测试控制终端的下载控制平台,通过所述下载控制平台选择测试终端、测试用例安装包,上传待测的软件包后向所述测试控制终端发送测试请求;
操作终端101可以是个人电脑,具体可以是软件工程师的办公电脑,软件工程师在完成软件编译后,通过局域网络与测试控制终端连接,通过IE浏览器登录下载控制平台。
测试控制终端102,与多个测试终端连接,通过下载控制平台收到任一操作终端发送的测试请求后,将该操作终端上传的软件包和选择的测试用例安装包下载到该操作终端选择的测试终端;
测试控制终端102可以是FPT服务器,在该FTP服务器上开发了下载控制平台,不同的芯片(如MTK,高通等)都有对应的下载控制平台,因此FPT服务器所提供的下载控制平台可以是多个,操作终端通过网络登录到FTP服务器后,可以根据想要测试的机型的芯片类型选择对应的下载控制平台。
本实施例中测试控制终端102中下载控制平台可以实现测试终端状态处理和下载请求扫描处理,具体可以通过软件下载处理模块和APK下载处理模块实现。
对于软件下载处理模块,用于实现所连接的测试终端的com端口设置,从而实现与测试终端可以通信,完成com端口设置后可以将com端口设置信息保持在数据库中;从数据库中获取所连接的测试终端的信息,该信息可以是测试终端的机型、软件版本信息等;操作终端上传的软件包及其保存路径具体可以是保存在数据库中,则测试控制终端可以从数据库中获取软件包的路径信息,从而可以获取操作终端上传的软件包;获取到软件包后可以控制所连接的测试终端进行软件包下载,在软件包下载完成后控制测试终端关机;之后控制测试终端开机并将测试终端最新的软件版本信息在数据库中更新。
APK下载处理模块,用于实现所连接的测试终端的ADB端口设置,完成ADB端口设置后可以将ADB端口设置信息保存在数据库中;测试用例安装包(APK文件)及其路径可以保存在数据库中,则该APK下载处理模块可以从数据库中捕获待下载的测试用例安装包(APK文件)路径;按照路径下载对应的APK文件;控制对应的测试终端安装APK文件;控制对应的测试终端启动运行APK文件,并监测APK文件的运行状态,抓取APK测试结果;上报APK测试结果至服务器。
由于测试控制终端102面向多个操作终端101和多个测试终端103,因此可以实现多线程软件下载,从而可以实现从多个操作终端上接收上传的软件包和测试用例安装包,及同时向多个测试终端下载软件包和测试用例安装包,及接收多个测试终端上传的测试报告等;具体可以在数据库中建立软件下载信息表和APK下载信息表来维护。从而可以控制同一机型的不同版本软件在同一个测试终端如手机上自动排队完成下载和测试,控制多型号手机移动设备同时进行下载和测试。
通过该测试控制终端102的下载控制平台,装载着下载控制程序,通过局域网络连接数据库系统,通过查询数据库表,测试终端可以浏览到该测试控制终端所连接的测试终端的信息,具体可以是机型等,从而可以选择测试终端,还可以浏览到测试用例安装包信息,从而选择相应的测试用例安装包,还可以上传测试请求,从而实现把指定的软件和APK测试包从FTP服务器上下载到指定的移动终端中去,并把下载状态和APK测试状态及最终的测试报告文件上传到服务器,供软件工程师通过操作终端查看,可以请求测试控制终端执行软件自动测试,可以获得最终需要的软件测试报告。
通过该测试控制终端102的下载控制平台,可以发布被测试软件及测试请求,方便操作人员查看。
多个测试终端103,每个测试终端收到软件包和对应的测试用例安装包后,通过测试用例安装包安装测试用例应用程序,通过所述软件包安装测试软件,在测试软件运行过程中通过所述测试用例应用程序对所述测试软件进行测试,生成软件测试报告。
测试终端103可以是手机等移动终端设备,但不限于手机,通过下载数据线连接到下载控制台上,用于运行下载到测试终端中的被测试软件,运行被安装到手机中的测试用例安装包对应的测试应用程序,具体可以是APK测试应用程序,APK测试应用程序按照预先设置好的测试步骤完成测试,生成测试报告,供下载控制台读取。
本实施例提供一种软件测试系统,实现Android手机等移动设备的软件自动下载,软件自动测试,自动上报测试结果功能;实现软件工程师自助化,无人值守下载,测试操作,达到减少软件测试工程师工作量的目的,该专利适用于手机等移动设备,但不仅限于手机。
可选地,所述测试控制终端上有多个下载控制平台,每个下载控制平台对应连接多个测试终端;
所述每个操作终端还用于选择要登录的下载控制平台,根据所述下载控制平台连接的测试终端进行测试终端选择。
本实施例中,该系统还包括:
Web服务器104,所述每个操作终端通过所述web服务器与所述测试控制终端连接,所述web服务器用于实现所述每个操作终端与测试控制终端之间的通信。
Web服务器中装载着web服务程序,供操作终端调用,响应操作终端使用IE浏览器发出去的请求,配合测试控制终端上的下载控制平台就可完成如下操作:选择测试控制终端上的下载控制平台、查看所选择的下载控制平台上连接的测试终端(手机等)的型号、测试终端的下载测试状态及软件版本信息;选择测试机器(手机等);上传被测试软件包;选择对应的测试用例的APK文件;查看最终的测试报告等;也可按照测试用例模板,对测试bug进行解析,跟公司的bug管理系统对接,把bug信息录入bug管理系统
本实施例中,该系统还包括:
数据库服务器105,与测试控制终端和web服务器连接,所述web服务器用于实现所述数据库服务器和测试控制终端间的通信,所述数据库服务器用于保存支持所述下载控制平台运行所需的数据,所述支持下载控制平台运行所需的数据包括测试终端信息、测试用例安装包、每个操作终端所选择的测试终端及测试用例安装包。
如前所述,下载控制平台的运行需要数据库的支持,该数据库可以在数据库服务器105,数据库服务器105可以是专门开发的一个服务器,也可以是同web服务器使用一个服务器,也可以是同测试控制终端一样使用FTP服务器。
数据库中具体可以维护如下信息:
com端口设置信息,在测试控制终端通过下载控制平台完成与所连接的测试终端的com端口配置后,可以在数据库中保存完成的com端口配置信息;
ADB端口设置,在测试控制终端通过下载控制平台完成与所连接的测试终端的ADB端口配置后,可以在数据库中保存完成的ADB端口配置信息;
测试终端信息,具体可以包括测试终端的机型、软件版本信息、下载测试状态等,下载测试状态包括空闲态、忙态、失败态,其中,所述测试终端响应测试请求开始下载软件包至生成软件测试报告为忙态,测试终端未成功响应该测试请求开始下载软件包时为失败态,否则为空闲态;
软件下载信息表,具体可以是正在被下载的软件包的列表信息;
APK下载信息表,具体可以是正在被下载的APK文件的列表信息;
待下载的软件包,操作终端上传的软件包被保存在数据库中,在下载控制平台可以通过保存路径获取对应的软件包;
待下载的APK文件,操作终端上传的APK文件被保存在数据库中,在下载控制平台可以通过保存路径获取对应的APK文件;
软件测试报告,测试终端上传的测试报告可以保存在数据库中。
本实施例中,用户可以通过下载控制平台查询对应的数据库中的信息,从而实现各种信息如下载测试状态及测试请求状态的查询。
本实施例中,所述测试控制终端,采用定时处理的方式,确定每个未被响应的测试请求指向的测试终端,在一个测试终端对应多个测试请求时,按照设定规则排队处理;在定时处理时,响应测试请求的方式为向处于空闲态的测试终端下载软件包和测试用例安装包。
可选地,所述测试控制终端,还用于维护每个下载控制平台接收的测试请求的状态、测试终端的状态、测试终端进行软件包下载时的下载测试状态,根据所述维护的测试请求的状态,确定未被响应的测试请求,根据所维护测试终端的下载测试状态更新测试终端的状态,根据所维护的测试终端的状态确定出处于空闲态的测试终端。
可选地,所述测试请求的状态包括请求状态、处理状态完成状态和失败状态,在测试终端未响应该测试请求开始下载软件包时为请求状态,在测试终端响应该测试请求的过程为处理状态,在测试终端成功响应该测试请求生成软件测试报告时为完成状态,在测试终端未成功响应该测试请求时为失败状态;
每个测试终端的下载测试状态包括完成态、忙态、失败态,其中,所述测试终端响应测试请求的过程为忙态,测试终端未成功响应该测试请求时为失败态,否则为完成态;
每个测试终端的状态包括空闲态、忙态和故障态,其中,在下载测试状态为完成态时所述测试终端的状态为空闲态,在下载测试状态为失败态时所述测试终端的状态为故障态,在下载测试状态为忙态时所述测试终端的状态为忙态。
所述测试控制终端,还用于从测试终端获取软件测试报告并获取软件测的对应的测试用例模板,利用所述测试用例模板对软件测试结果中的测试bug进行解析,将bug信息录入到相应的bug管理系统,可以省去测试工程师频繁重复的测试操作,节省人力。
本发明实施例提供的软件测试系统可实现无人值守,完成软件下载和软件测试操作,并获取测试报告,大大节省软件测试人员的人力投入;该系统可以实现测试移动终端的公用,不需要为每个有测试需求的人员都提供一个测试移动终端,大大节约测试手机的成本投入;该系统可实现一天24小时,不间断运行,能充分利用夜晚的时间,大大提高测试效率。
实施例二
本实施例基于实施例一所提供的软件测试系统,提供一种软件测试方法,如图2所示,该方法包括:
步骤201,操作终端通过网络登录到测试控制终端的下载控制平台,通过所述下载控制平台选择测试终端、测试用例安装包,上传待测的软件包后向所述测试控制终端发送测试请求;
步骤202,所述测试控制终端通过下载控制平台收到任一操作终端发送的测试请求后,将该操作终端上传的软件包和选择的测试用例安装包下载到该操作终端选择的测试终端;
步骤203,每个测试终端收到软件包和对应的测试用例安装包后,通过测试用例安装包安装测试用例应用程序,通过所述软件包安装测试软件,在测试软件运行过程中通过所述测试用例应用程序对所述测试软件进行测试,生成软件测试报告。
可选地,所述测试控制终端上有多个下载控制平台,每个下载控制平台对应连接多个测试终端,则:
所述每个操作终端通过网络选择要登录的下载控制平台,根据所述下载控制平台连接的测试终端进行测试终端选择
可选地,所述测试控制终端,采用定时处理的方式,确定每个未被响应的测试请求指向的测试终端,在一个测试终端对应多个测试请求时,按照设定规则排队处理;在定时处理时,响应测试请求的方式为向处于空闲态的测试终端下载软件包和测试用例安装包。
可选地,该方法还包括:
所述测试控制终端维护每个下载控制平台接收的测试请求的状态、测试终端的状态、测试终端进行软件包下载时的下载测试状态;
则所述测试控制终端根据所述维护的测试请求的状态,确定未被响应的测试请求,根据所维护测试终端的下载测试状态更新测试终端的状态,根据所维护的测试终端的状态确定出处于空闲态的测试终端。
可选地,所述测试请求的状态包括请求状态、处理状态完成状态和失败状态,在测试终端未响应该测试请求开始下载软件包时为请求状态,在测试终端响应该测试请求的过程为处理状态,在测试终端成功响应该测试请求生成软件测试报告时为完成状态,在测试终端未成功响应该测试请求时为失败状态;
每个测试终端的下载测试状态包括完成态、忙态、失败态,其中,所述测试终端响应测试请求的过程为忙态,测试终端未成功响应该测试请求时为失败态,否则为完成态;
每个测试终端的状态包括空闲态、忙态和故障态,其中,在下载测试状态为完成态时所述测试终端的状态为空闲态,在下载测试状态为失败态时所述测试终端的状态为故障态,在下载测试状态为忙态时所述测试终端的状态为忙态。
可选地,该方法还包括:
所述测试控制终端从测试终端获取软件测试报告并获取软件测的对应的测试用例模板,利用所述测试用例模板对软件测试结果中的测试bug进行解析,将bug信息录入到相应的bug管理系统。
本实施例中软件测试方法详细流程图如图3所示,包括:
步骤301,操作终端通过网络连接到测试控制终端的下载控制平台的登录页面;
想发起测试请求的软件工程师,在操作终端上(个人工作电脑上)使用IE浏览器,输入指定的IP地址,打开下载控制平台登录页面。
步骤302,在下载控制平台的登录页面进行身份验证,身份验证通过,执行步骤303,身份验证未通过,需要继续进行身份验证;
具体可以是在下载控制平台的登录页面输入用户名和密码,完成身份验证,不能完成身份的,不能登录下载控制平台登录页面。
步骤303,操作终端在下载控制平台登录页面,选择下载控制平台,选择测试终端,上传被测试的软件包,选择对应测试用例的APK文件包,发出测试请求;
如前所述,下载控制平台对应的数据库中保存有所连接的测试终端的信息、APK文件包等,因此可以通过下载控制平台可查看下载控制平台上连接的手机移动设备的型号、下载测试状态及软件版本信息,可根据测试需要,选择下载控制平台、选择测试移动终端、上传被测试软件包、选择对应测试用例的APK文件包、发出测试请求,并将测试请求的状态设置为请求状态。
步骤304,测试控制终端通过下载控制平台查询指向该控制平台上所有连接的移动终端的测试请求(即状态为asking的测试请求)。
具体的查询方式可以是定时查询,即每隔一段时间查询一次。
这些可以获得被请求测试的移动终端列表,且在该列表中,可以获得执行每个移动终端的至少一个测试请求,在测试请求为多个,按照设定机制排队。
步骤305,查询被请求的移动终端设备状态是否为空闲态idle,若不为idle,结束本次针对该移动终端的查询处理操作,继续等待下次查询,若为idle,执行步骤306。
具体的查询方式可以循环定时查询,即达到设定终端状态查询时间时,进行被请求的手机移动设备状态查询。
步骤306,获取被请求移动终端(针对该移动中的测试请求状态为asking)对应下载软件和APK文件的指向路径,并在下载控制平台上完成相关参数设置,若操作成功,执行步骤307,从而开始执行下载操作,若失败执行步骤308。
步骤307,把正在执行下载操作移动终端的测试请求状态由asking修改为Dling,把移动终端的设备状态由idle修改为busy,启动软件下载线程,开始软件下载,该移动终端进入步骤308或步骤309,并返回步骤304和步骤305循环执行测试请求状态查询及终端状态查询。
步骤308,当软件下载线程启动失败时,则结束本移动终端的下载和后续操作,跳转到End,把针对该移动终端的测试请求状态由asking修改为Fail,并报告原因,把该移动终端的设备状态由idle修改为fault,请求针对该手机移动设备进行人工干预,然后,循环执行其它被请求的操作。
步骤309,当软件下载线程启动成功时,启动定时查询下载测试状态,若为忙态ing,则结束本次查询操作,若为完成态pass,则进入步骤310,若为失败态fail,则结束本移动终端的下载和后续操作,跳转到End,把针对该移动终端的测试请求状态由处理态DLing修改为失败态Fail,并报告原因,把该移动终端的设备状态由忙态busy修改为故障态fault,请求针对该手机移动设备进行人工干预。
步骤310,控制手机重启,并等待手机重启后,从手机中读取软件版本信息与设备id号,更新设备信息,重启失败,或更新信息失败,则结束本移动终端的APK下载操作,跳转到End,把针对该移动终端的测试请求状态由DLing修改为Fail,并报告原因,把该移动终端的设备状态由busy修改为fault,请求针对该手机移动设备进行人工干预。
步骤311,下载APK文件到移动终端,失败,则跳转到End,把针对该移动终端的测试请求状态由DLing修改为Fail,并报告原因,把该移动终端的设备状态由busy修改为fault,请求针对该手机移动设备进行人工干预,成功,则执行步骤312。
步骤312,控制移动终端安装APK,失败,则跳转到End,把针对该移动终端的测试请求状态由DLing修改为Fail,并报告原因,把该移动终端的设备状态由busy修改为fault,请求针对该手机移动设备进行人工干预,成功,则执行步骤313。
步骤313,控制移动终端启动刚完成安装的自动测试APP,移动终端自动执行测试,并生成测试报告文件;失败,则跳转到End,把针对该移动终端的测试请求状态由DLing修改为Fail,并报告原因,把该移动终端的设备状态由busy修改为fault,请求针对该手机移动设备进行人工干预,成功,执行步骤314。
步骤314,启动定时查询自动测试APP是否已经完成测试,若完成测试,执行步骤315。
步骤315,从移动终端读取测试报告,并把该测试报告上传至服务器。
步骤306,把完成测试的移动终端测试请求状态由Dling修改为pass,把该移动终端状态由busy修改为idle;完成一次测试操作,该移动终端可以开始进行下一个测试请求操作。
本实施例所提供的软件测试方法,实现远程控制测试终端进行软件包下载、自动测试从而获得测试报告,代替软件测试工程师的手动操作;
可以实现无人值守,自动完成软件下载、自动测试控制,并上报测试结果,可实现24小时运转,大大提高测试效率;
同一个下载控制平台可同时控制不同的测试终端分别下载不同的软件包和不同的测试用例,分别完成自动测试,并分别上报测试结果。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本发明所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如,多个模块或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或模块的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能模块可以集成在一个处理单元中,也可以是各个模块单独物理存在,也可以两个或两个以上模块集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机装置(可以是个人计算机,服务器,或者网络装置等)或处理器(Processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本方案的较佳实施例而已,并不用以限制本方案,凡在本方案的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本方案保护的范围之内。