应急指挥系统测试方法、装置、电子设备及存储介质
文献发布时间:2023-06-19 19:27:02
技术领域
本发明涉及计算机技术领域,特别是涉及应急指挥系统测试方法、装置、电子设备及存储介质。
背景技术
在应急指挥场景中,利用应急指挥系统可以使得主持方能够实时调度参与方并与参与方进行对讲通话,因此在对讲通话时应急指挥系统是否稳定尤为重要。应急指挥系统是否稳定可以理解为对讲通话时参与方是否存在掉线的情况,若存在掉线的情况,则应急指挥系统不稳定,若不存在掉线的情况,则应急指挥系统稳定。一般可以通过对应急指挥系统进行测试以确定应急指挥系统的稳定性,目前的测试方法是人工长时间观察并记录应急指挥会议的各参与方的掉线情况,即相关技中对于应急指挥系统的测试完全依赖人工。
发明内容
本发明实施例的目的在于提供一种应急指挥系统测试方法、装置、电子设备及存储介质,以实现应急指挥系统自动化测试。具体技术方案如下:
根据本发明实施例的第一方面,提供了一种应急指挥系统测试方法,所述方法包括:
获取用于测试应急指挥系统的测试程序;
利用所述测试程序多次获取应急指挥会议各参与方的工作状态;所述工作状态包括以下状态中的一种:在线和掉线;
如果在多次获取的所述工作状态中,至少存在一次获取的所述工作状态中一个参与方的工作状态为掉线,则测试结果为应急指挥系统不稳定;
如果多次获取的所述工作状态中各参与方的工作状态均为在线,则测试结果为应急指挥系统稳定。
在一种可能的实施方式中,所述利用所述测试程序多次获取应急指挥会议各参与方的工作状态,包括:
调用所述测试程序勾选所述应急指挥会议的各参与方;
调用所述测试程序点击所述应急指挥会议召开按钮;
在所述应急指挥会议开启之后获取一次所述应急指挥会议的掉线列表,并每隔预设时间段获取一次所述掉线列表,直至获取掉线列表的次数达到预设数量;其中,所述掉线列表中记录有各参与方中工作状态为掉线的参与方的设备名称信息。
在一种可能的实施方式中,所述预设数量为两次;
所述在所述应急指挥会议开启之后获取一次所述应急指挥会议的掉线列表,并每隔预设时间段获取一次所述掉线列表,直至获取掉线列表的次数达到预设数量,包括:
获取所述应急指挥会议的时长;
在所述应急指挥会议开启之后获取一次所述掉线列表,从所述应急指挥会议开启的时刻起等待所述时长后再次获取所述掉线列表。
在一种可能的实施方式中,在所述利用所述测试程序多次获取应急指挥会议各参与方的工作状态之后,所述方法还包括:
将多次获取得到的多个掉线列表,写入预设文档中;
所述如果在多次获取的所述工作状态中,至少存在一次获取的所述工作状态中一个参与方的工作状态为掉线,则测试结果为应急指挥系统不稳定;如果多次获取的所述工作状态中各参与方的工作状态均为在线,则测试结果为应急指挥系统稳定,包括:
检测所述预设文档中的多个掉线列表中记录的设备名称信息;
如果从所述多个掉线列表中检测到至少一个设备名称信息,则应急指挥系统不稳定;
如果未从所述多个掉线列表中检测到设备名称信息,则所述应急指挥系统稳定。
在一种可能的实施方式中,所述测试程序基于预设控制策略和预先获取的页面控件信息而得到;所述页面控件信息包含所述应急指挥会议召开前的页面的控件信息和所述应急指挥会议召开中的页面的控件信息;所述预设控制策略包含测试所述应急指挥系统的测试步骤。
根据本发明实施例的第二方面,提供了一种应急指挥系统测试装置,所述装置包括:
第一获取模块,用于获取用于测试应急指挥系统的测试程序;
第二获取模块,用于利用所述测试程序多次获取应急指挥会议各参与方的工作状态;所述工作状态包括以下状态中的一种:在线和掉线;
测试结果得到模块,用于如果在多次获取的所述工作状态中,至少存在一次获取的所述工作状态中一个参与方的工作状态为掉线,则测试结果为应急指挥系统不稳定;如果多次获取的所述工作状态中各参与方的工作状态均为在线,则测试结果为应急指挥系统稳定。
在一种可能的实施方式中,所述第二获取模块,包括:
勾选子模块,用于调用所述测试程序勾选所述应急指挥会议的各参与方;
点击子模块,用于调用所述测试程序点击所述应急指挥会议召开按钮;
获取子模块,用于在所述应急指挥会议开启之后获取一次所述应急指挥会议的掉线列表,并每隔预设时间段获取一次所述掉线列表,直至获取掉线列表的次数达到预设数量;其中,所述掉线列表中记录有各参与方中工作状态为掉线的参与方的设备名称信息
在一种可能的实施方式中,所述预设数量为两次;
所述获取子模块,具体用于获取所述应急指挥会议的时长;在所述应急指挥会议开启之后获取一次所述掉线列表,从所述应急指挥会议开启的时刻起等待所述时长后再次获取所述掉线列表。
在一种可能的实施方式中,所述装置还包括:
写入模块,用于将多次获取得到的多个掉线列表,写入预设文档中;
所述测试结果得到模块,具体用于检测所述预设文档中的多个掉线列表中记录的设备名称信息;如果从所述多个掉线列表中检测到至少一个设备名称信息,则应急指挥系统不稳定;如果未从所述多个掉线列表中检测到设备名称信息,则所述应急指挥系统稳定。
在一种可能的实施方式中,所述测试程序基于预设控制策略和预先获取的页面控件信息而得到;所述页面控件信息包含所述应急指挥会议召开前的页面的控件信息和所述应急指挥会议召开中的页面的控件信息;所述预设控制策略包含测试所述应急指挥系统的测试步骤。
根据本发明实施的第三方面,还提供了一种电子设备,包括:处理器、通信接口、存储器和通信总线,其中,处理器,通信接口,存储器通过通信总线完成相互间的通信,
存储器,用于存放计算机程序;
处理器,用于执行存储器上所存放的程序时,实现第一方面中任一所述的方法步骤。
根据本发明实施的第四方面,还提供了一种计算机可读存储介质,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现上述任一所述的应急指挥系统测试方法。
本发明实施例还提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述任一所述的应急指挥系统测试方法。
本发明实施例有益效果:
本发明实施例提供的应急指挥系统测试方法、装置、电子设备及存储介质,通过获取用于测试应急指挥系统的测试程序;利用测试程序多次获取应急指挥会议各参与方的工作状态,如果多次获取到的各参与方的工作状态中包含掉线状态,则应急指挥系统不稳定,如果多次获取到的各参与方的工作状态中均为在线,则应急指挥系统稳定。即本发明实施例中可以通过程序自动获取各参与方的工作状态,自动根据工作状态得到测试结果,相比于相关技术中需要人工长时间观察并记录应急指挥会议的各参与方的掉线情况,本发明实施例能够实现应急指挥系统的自动化测试。
当然,实施本发明的任一产品或方法并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的实施例。
图1为本发明实施例提供的应急指挥系统测试方法的一种流程图;
图2为本发明实施例提供的获取测试程序的流程图;
图3为本发明实施例提供的应急指挥系统测试方法的另一种流程图;
图4为本发明实施例提供的应急指挥系统测试方法的再一种流程图;
图5为本发明实施例提供的应急指挥系统测试装置的一种结构示意图;
图6为本发明实施例提供的一种电子设备结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员基于本发明所获得的所有其他实施例,都属于本发明保护的范围。
应急指挥系统是一个集信息采集、呼叫受理、值守、指挥、调度、控制、分析、决策等功能为一体的综合性应用系统,可在突发事件预警、上报、响应、指挥等各个环节实现突发应急保障。应急指挥系统广泛适用于交通、能源、气象、医疗、卫生、电信、银行等大型公共服务机构。以银行为例,当出现重大事故时,银行会通过安防物联平台的应急指挥系统召开应急指挥会议对总行、一级分行、二级分行和重点部位进行应急调度。应急指挥会议的形式可以是视频会议的形式,在应急指挥会议的召开过程中应急指挥系统是否稳定,应急指挥会议的各参与方是否存在掉线的情况十分重要,因此,需要对应急指挥系统进行测试。
图1为本发明实施例提供的应急指挥系统测试方法的一种流程图,如图1所示,包括:
步骤S101,获取用于测试应急指挥系统的测试程序;
步骤S102,利用测试程序多次获取应急指挥会议各参与方的工作状态;工作状态包括以下状态中的一种:在线和掉线;
步骤S103,如果在多次获取的工作状态中,至少存在一次获取的工作状态中一个参与方的工作状态为掉线,则测试结果为应急指挥系统不稳定;
步骤S104,如果多次获取的工作状态中各参与方的工作状态均为在线,则测试结果为应急指挥系统稳定。
本发明实施例中,通过获取用于测试应急指挥系统的测试程序;利用测试程序多次获取应急指挥会议各参与方的工作状态,如果多次获取到的各参与方的工作状态中包含掉线状态,则应急指挥系统不稳定,如果多次获取到的各参与方的工作状态中均为在线,则应急指挥系统稳定。即本发明实施例中可以通过程序自动获取各参与方的工作状态,自动根据工作状态得到测试结果,相比于相关技术中需要人工长时间观察并记录应急指挥会议的各参与方的掉线情况,本发明实施例能够实现应急指挥系统的自动化测试。
关于步骤S101,通常情况下,测试程序由测试人员在测试应急指挥系统之前编写得到,可以直接获取。测试程序可以是由多种计算机语言编写得到的代码,例如python(一种计算机语言)代码,c语言代码等。
在得到编写好的测试程序后,可以由测试人员人工开启测试程序的执行,开启测试程序的执行即为开启对应急指挥系统的测试,通过执行测试程序能够实现对应急指挥系统的测试,测试程序执行完成时即完成对于应急指挥系统的测试。
测试程序用于测试应急指挥系统是否稳定,具体通过基于应急指挥系统召开的应急指挥会议中各参与方的工作状态来确定,若各参与方在应急指挥会议过程中出现了掉线状态,则说明应急指挥系统不稳定,如果各参与方在应急指挥会议过程中均为出现掉线状态,即全都保持在线状态,则说明应急指挥系统稳定。
在一种可能的实施方式中,测试程序基于预设控制策略和预先获取的页面控件信息而得到。
页面控件信息包含应急指挥会议召开前的页面的控件信息和应急指挥会议召开中的页面的控件信息。
页面控件指可在窗体上放置的可视化图形“元件”,如按钮、文件编辑框等。其中大多数是具有执行功能或通过引发代码运行并完成响应的功能。本发明实施例中的页面控件信息可以是与应急指挥会议相关的页面控件信息,例如,会议召开按钮、会议离开按钮、会议勾选框、返回按钮、会议名称文本框等页面控件信息。页面控件信息可以包含控件所属的页面、控件在所属页面中所处的位置、控件的类型等,控件的类型可以包含按钮控件、文本框控件、密码框控件等。页面控件信息可以通过抓取页面信息的工具获取,例如应用程序测试工具(python selenium库)、页面数据采集器(Easy Web Data Scraper)等工具。
预设控制策略包含测试应急指挥系统的测试步骤,预设控制策略可以理解为测试人员为测试应急指挥系统而预先设计的测试所需的整体流程,例如预设控制策略包含以下步骤,第一步为选择应急指挥会议的参与方;第二步为召开应急指挥会议;第三步为获取各参与方的工作状态,第四步为生成测试结果。
当应急指挥系统发生变动时,例如,开发人员对应急指挥系统进行了升级或做出了调整,具体可以是开发人员对于会议召开按钮、返回按钮等页面控件信息做出调整,此时需要重新获取页面控件信息,并基于重新获取的页面控件信息对测试程序做出调整,再通过执行测试程序对应急指挥系统进行测试。
本发明实施例中,根据预设控制策略和预先获取的页面控件信息得到测试程序,以便于利用测试程序对应急指挥系统进行测试,得到测试结果,从而可以实现应急指挥系统的自动化测试。
在获取测试程序之前,可以进行制定预设控制策略、获取页面控件信息等步骤,如图2所示,可以包括:
步骤S1,制定预设控制策略;
步骤S2,引入python selenium库;
python selenium库作为一种抓取页面控件信息的工具,在此步骤中引入的目的是获取应急指挥会议召开前页面和召开中页面的空间信息。
步骤S3,获取应急指挥系统的页面控件信息;
通过python selenium库获取应急指挥系统的页面控件信息。
步骤S4,根据预设控制策略和页面控件信息编写python代码;
python代码相当于测试程序,本发明实施例中采用python语言编写测试程序。
步骤S5,执行python代码并输出测试结果。
在测试时执行python代码并输出测试结果,即可完成对应急指挥系统的测试。
本发明实施例中,通过python代码控制应急指挥系统,执行python代码也可以理解为实现预设控制策略,通过执行python代码记录当前应急指挥会议中参与方的工作状态,进而获得测试结果并将测试结果输出成文件,实现应急指挥系统自动化测试。
关于步骤S102,应急指挥系统会记录应急指挥会议中各个参与方实时的工作状态,例如将各参与方的工作状态记录在表格中,或针对各个参与方标记在线或掉线的标签信息,当参与方的工作状态发生变化时,如从在线状态变为掉线状态或从掉线状态变为在线状态,应急指挥系统会实时更新所记录的参与方的工作状态,调用测试程序可以读取各参与方的工作状态。
多次获取各参与方的工作状态可以是在应急指挥会议中定时获取参与方的工作状态,例如,从应急指挥会议开始时获取一次,然后每隔预设时长获取一次,得到多次获取的各参与方的工作状态,预设时长可以根据实际需求或经验设置,例如5分钟、10分钟等。
关于步骤S103,若在应急指挥会议召开过程中存在参与方掉线的情况,则说明应急指挥系统不稳定,具体为在多次获取到的工作状态中,若存在一个或多个参与方的工作状态为掉线,则测试结果为应急指挥系统不稳定。
关于步骤S104,若在应急指挥会议召开过程中各参与方均为在线状态,则说明应急指挥系统稳定,具体为在多次获取到的工作状态中,若各参与方的工作状态均为在线,不存在掉线的情况,则测试结果为应急指挥系统稳定。
在得到应急指挥系统的测试结果后可以将测试结果以文件的形式输出并展示,以便于测试人员得到测试结果。
相关技术中,在对应急指挥系统进行测试时完全依赖人工,首先需要主持方手动勾选参与方以将参与方设备加入应急指挥会议,手动点击应急指挥会议召开按钮,再通过人工观察记录参与方的工作状态,这样会导致测试过程耗费人力,且完全依赖人工操作也会使测试结果准确性较低,测试用时较长导致时间成本较高。本发明实施例中可以调用测试程序,实现自动化的测试过程,包括自动将参与方加入应急指挥会议,自动召开应急指挥会议等,具体可通过如图3所示的实施方式实现。
图3为本发明实施例提供的应急指挥系统测试方法的另一种流程图,如图3所示,可以包括以下步骤:
步骤S101,获取用于测试应急指挥系统的测试程序;
步骤S1021,调用测试程序勾选应急指挥会议的各参与方;
会议勾选框属于页面控件信息,在编写测试程序前获得,在编写测试程序的过程中通过计算机语言组成的代码针对各参与方对应的会议勾选框设置操作指令,若勾选某个参与方对应的会议勾选框,表示将该参与方的设备加入应急指挥会议,在执行测试程序时完成操作指令,实现对于应急指挥会议参与方的勾选动作。
具体勾选哪些参与方可以在预先在测试程序中进行设置,通常情况下,为了保证测试的准确性,可以将所有的参与方加入应急指挥会议中。
步骤S1022,调用测试程序点击应急指挥会议召开按钮;
召开按钮的控件信息在编写测试程序前获得,在编写测试程序时对召开按钮的控件信息设置操作指令,进而测试过程中调用测试程序,执行代码以完成召开按钮控件对应的操作指令,实现点击召开按钮的动作。在点击召开按钮前可以获取应急指挥会议的会议名称,会议名称可以理解为一种页面控件信息,在测试程序的编写过程中以代码的形式包含于测试程序中,可以理解为在测试程序中定义了对以该会议名称为名的应急指挥会议进行测试,从而在测试程序的执行过程中直接对该应急指挥会议进行测试。应急指挥会议的形式可以时多种形式,例如视频会议,电话会议等。
如果在测试时还未登录应急指挥系统,则需要调用测试程序先登录应急指挥系统,再点击召开按钮,进行测试,具体过程可以为打开浏览器,登录平台地址,选择登录机构,输入账号密码,点击登录按钮,进入应急指挥会议召开前的页面,判断是否有正在召开的会议,如果没有,点击应急指挥系统召开按钮。
步骤S1023,在应急指挥会议开启之后获取一次应急指挥会议的掉线列表,并每隔预设时间段获取一次掉线列表,直至获取掉线列表的次数达到预设数量;
其中,掉线列表中记录有各参与方中工作状态为掉线的参与方的设备名称信息,应急指挥系统在检测到某个参与方的工作状态为掉线状态时,会将该参与方的设备名称信息记录到掉线列表中,在对应急指挥系统进行测试的过程中可以调用测试程序直接获取掉线列表。
在应急指挥会议开启之后获取一次应急指挥会议的掉线列表可以理解为在应急指挥会议刚开始的时候获取一次掉线列表,可以将点击应急指挥会议召开按钮理解为开启应急指挥会议,在一种可行的实施方式中,在点击应急指挥会议召开按钮后获取一次掉线列表。
预设时间段可以根据经验或实际需求进行设置,例如5分钟、10分钟等,预设数量可以是将应急指挥会议时长按照预设时间段进行划分得到的,例如应急指挥会议时长为30分钟,预设时间段为10分钟,则预设数量为3次。
可以理解,在图1所示实施例基础上,步骤S102可以包括步骤S1021至S1023。
步骤S103,如果在多次获取的工作状态中,至少存在一次获取的工作状态中一个参与方的工作状态为掉线,则测试结果为应急指挥系统不稳定;
步骤S104,如果多次获取的工作状态中各参与方的工作状态均为在线,则测试结果为应急指挥系统稳定。
本发明实施例中,调用测试程序实现勾选各参与方、点击召开按钮、获取掉线列表,从而能够替代人工操作,实现自动化测试,从而也可以节省人工成本。由于相关技术中需要人工手动召开应急指挥会议,并长时间观察并记录应急指挥会议的各参与方的掉线情况,而人工操作可能会存在观察失误或未及时记录的情况,从而导致测试结果准确性较低,并且完全依赖人工操作,需要更长的时间来完成测试,导致时间成本较高,调用测试程序实现的自动化测试能够减少人工操作带来的不确定性,从而提高测试结果的准确性,还可以节省时间成本。而且由于执行测试程序的过程即为测试过程,即测试过程不需要人工干预,因此也可以降低测试的成本;进一步地,由于不需要人工干预,因此可以全天候24小时进行测试,能够提高测试效率。
图4为本发明实施例提供的应急指挥系统测试方法的再一种流程图,如图4所示,可以包括以下步骤:
步骤S101,获取用于测试应急指挥系统的测试程序;
步骤S1021,调用测试程序勾选应急指挥会议的各参与方;
步骤S1022,调用测试程序点击应急指挥会议召开按钮;
步骤S401,获取应急指挥会议的时长;
在对应急指挥系统进行测试时,召开应急指挥会议的目的是模拟真实应急指挥场景中的应急指挥会议,因此,测试时召开的应急指挥会议的时长可以是预先设置好的,例如设置为30分钟、40分钟等,在进行测试时可以直接获取。具体可以时在编写测试程序时利用代码预先定义应急指挥会议的时长。
步骤S402,在应急指挥会议开启之后获取一次所述掉线列表,从应急指挥会议开启的时刻起等待所述时长后再次获取所述掉线列表。
可以理解为在应急指挥会议刚开启时获取一次掉线列表,在应急指挥会议结束前再次获取掉线列表。
可以理解,在图3所示实施例基础上,预设数量为两次的情况下,步骤S1023可以包括S401至S402。
本发明实施例中,获取应急指挥会议的时长,在应急指挥会议开启之后获取一次掉线列表,从应急指挥会议开启的时刻起等待会议的时长后再次获取掉线列表,进而可以根据两次获取的掉线列表得到测试结果,有利于实现应急指挥系统自动化测试。
在一种可能的实施方式中,应急指挥系统测试方法还可以包括:
步骤S403,将多次获取得到的多个掉线列表,写入预设文档中;
可以理解为将多次获取得到的掉线列表显示在预设文档中,预设文档的格式可以自定义设置,例如,流式文档、版式文档等。
步骤S404,检测预设文档中的多个掉线列表中记录的设备名称信息;
掉线列表中记录的是在应急指挥会议中工作状态为掉线状态的参与方的设备名称信息,通常情况下以文字的形式记录参与方设备的名称或编号。因此可以检测掉线列表中是否记录有表示参与方设备名称或编号的文字即可,具体可以通过文字检测模型进行检测,进一步地,还可以检测掉线列表中记录的设备名称信息所属的参与方。
将多个掉线列表写入预设文档以及检测多个掉线列表中记录的设备名称信息均是调用测试程序实现。
步骤S103可以包括:
步骤S1031,如果从多个掉线列表中检测到至少一个设备名称信息,则应急指挥系统不稳定;
每次获取都会得到一个掉线列表,多次获取则会得到多个掉线列表,如果检测到多个掉线列表中记录有至少一个设备名称信息,则说明在应急指挥会议的召开过程中存在参与方掉线的情况,则测试结果为应急指挥系统不稳定,
步骤S104可以包括:
步骤S1041,如果未从多个掉线列表中检测到设备名称信息,则应急指挥系统稳定。
如果没有从多个掉线列表中检测到设备名称信息,则说明在应急指挥会议的召开过程中个参与方的工作状态均为在线,则测试结果为应急指挥系统稳定。
本发明实施例中,调用测试程序将多个掉线列表写入预设文档,并检测预设文档中的多个掉线列表中的设备名称信息,根据检测结果自动确定测试结果为应急指挥系统稳定或不稳定,从而可以实现应急指挥系统自动化测试。
图5为本发明实施例提供的应急指挥系统测试装置的一种结构示意图,参照图5,该装置可以包括:
第一获取模块501,用于获取用于测试应急指挥系统的测试程序;
第二获取模块502,用于利用测试程序多次获取应急指挥会议各参与方的工作状态;工作状态包括以下状态中的一种:在线和掉线;
测试结果得到模块503,用于如果在多次获取的工作状态中,至少存在一次获取的工作状态中一个参与方的工作状态为掉线,则测试结果为应急指挥系统不稳定;如果多次获取的工作状态中各参与方的工作状态均为在线,则测试结果为应急指挥系统稳定。
本发明实施例中,通过获取用于测试应急指挥系统的测试程序;利用测试程序多次获取应急指挥会议各参与方的工作状态,如果多次获取到的各参与方的工作状态中包含掉线状态,则应急指挥系统不稳定,如果多次获取到的各参与方的工作状态中均为在线,则应急指挥系统稳定。即本发明实施例中可以通过程序自动获取各参与方的工作状态,自动根据工作状态得到测试结果,相比于相关技术中需要人工长时间观察并记录应急指挥会议的各参与方的掉线情况,本发明实施例能够实现应急指挥系统的自动化测试。
在一种可能的实施方式中,第二获取模块502,包括:
勾选子模块,用于调用测试程序勾选应急指挥会议的各参与方;
点击子模块,用于调用测试程序点击应急指挥会议召开按钮;
获取子模块,用于在所述应急指挥会议开启之后获取一次所述应急指挥会议的掉线列表,并每隔预设时间段获取一次所述掉线列表,直至获取掉线列表的次数达到预设数量;其中,所述掉线列表中记录有各参与方中工作状态为掉线的参与方的设备名称信息。
在一种可能的实施方式中,预设数量为两次;
获取子模块,具体用于获取应急指挥会议的时长;在所述应急指挥会议开启之后获取一次所述掉线列表,从所述应急指挥会议开启的时刻起等待所述时长后再次获取所述掉线列表。
在一种可能的实施方式中,应急指挥系统测试装置还包括:
写入模块,用于将多次获取得到的多个掉线列表,写入预设文档中;
测试结果得到模块,具体用于检测预设文档中的多个掉线列表中记录的设备名称信息;如果从多个掉线列表中检测到至少一个设备名称信息,则应急指挥系统不稳定;如果未从多个掉线列表中检测到设备名称信息,则应急指挥系统稳定。
在一种可能的实施方式中,测试程序基于预设控制策略和预先获取的页面控件信息而得到;页面控件信息包含应急指挥会议召开前的页面的控件信息和应急指挥会议召开中的页面的控件信息;预设控制策略包含测试应急指挥系统的测试步骤。
本发明实施例还提供了一种电子设备,如图6所示,包括处理器601、通信接口602、存储器603和通信总线604,其中,处理器601,通信接口602,存储器603通过通信总线604完成相互间的通信,
存储器603,用于存放计算机程序;
处理器601,用于执行存储器603上所存放的程序时,实现上述任一所述的应急指挥系统测试方法。
上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect,PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture,EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
在本发明提供的又一实施例中,还提供了一种计算机可读存储介质,该计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现上述任一所述的应急指挥系统测试方法的步骤。
在本发明提供的又一实施例中,还提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述实施例中任一所述的应急指挥系统测试方法的步骤。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置、电子设备、存储介质及计算机程序产品实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本发明的较佳实施例,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等,均包含在本发明的保护范围内。
- Monkey测试方法、装置、电子设备及计算机可读存储介质
- 保险产品的测试方法及装置、存储介质及电子设备
- 接口测试方法、接口测试装置、电子设备及存储介质
- 联网软件升级测试方法、装置、电子设备和存储介质
- 一种测试方法、装置、电子设备和存储介质
- 电子设备的测试方法、装置、存储介质及电子设备
- 电子设备的测试方法、装置、电子设备和存储介质