CN109240918A - 大数据冒烟测试方法、装置、计算机设备和存储介质 - Google Patents
大数据冒烟测试方法、装置、计算机设备和存储介质 Download PDFInfo
- Publication number
- CN109240918A CN109240918A CN201810948598.5A CN201810948598A CN109240918A CN 109240918 A CN109240918 A CN 109240918A CN 201810948598 A CN201810948598 A CN 201810948598A CN 109240918 A CN109240918 A CN 109240918A
- Authority
- CN
- China
- Prior art keywords
- task
- dependence
- smoke test
- data
- tasks
- 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.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
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)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
本申请揭示了一种大数据冒烟测试方法、装置、计算机设备和存储介质,用于对处理海量数据的大数据架构软件进行冒烟测试,其中方法包括:获取多个参与冒烟测试的任务;分析各所述任务之间的依赖关系;将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。本申请先对多个参与冒烟测试的任务进行依赖关系的分析,然后将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试,本申请可以同时对多个任务进行并发的冒烟测试,冒烟测试效率极大提升,快速地将大数据建构软件的风险查找出来。
Description
技术领域
本申请涉及到计算机领域,特别是涉及到一种大数据冒烟测试方法、装置、计算机设备和存储介质。
背景技术
在软件中,“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行,且不会破坏整个版本的稳定性。
传统项目的冒烟测试无法满足大数据的批量任务,需要遍历几百个.sh脚本耗时长,无法快速识别软件风险,效率较低。
发明内容
本申请的主要目的为提供一种大数据冒烟测试方法、装置、计算机设备和存储介质,旨在解决现有技术中冒烟测试效率低的问题。
为了实现上述发明目的,本申请提出一种大数据冒烟测试方法,包括:
获取多个参与冒烟测试的任务;
分析各所述任务之间的依赖关系;
将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。
进一步地,所述将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试的步骤之前,包括:
获取各任务对应的数据;
按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据。
进一步地,所述按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据的步骤之后,包括:
判断各任务对应的剩余数据的数据量是否满足冒烟测试的需求;
若否,则根据任务的属性构造对应的构造数据;
将所述构造数据插入到所述剩余数据中。
进一步地,所述获取多个参与冒烟测试的任务的步骤之前,包括:
判断当前时间是否为指定时间;
若为指定时间,则生成开启冒烟测试的命令。
进一步地,所述若为指定时间,则生成开启冒烟测试的命令的步骤,包括:
若为指定时间,则判断所述当前的数据量是否达到预设量;
如果达到所述预设量,则生成开启冒烟测试的命令。
进一步地,所述判断所述当前的数据量是否达到预设量的步骤之后,包括:
如果未达到所述预设量,则开始按照预设频率监察数据库中的数据量;
当数据量达到预设量,则生成开启冒烟测试的命令。
进一步地,所述分析各所述任务之间的依赖关系的步骤之后,包括:
将存在依赖关系的所述任务按照依赖顺序存放到预设的依赖关系表中,以及将没有依赖关系的离散任务存放到预设的离散任务表中。
本申请还提供一种大数据冒烟测试装置,包括:
获取单元,用于获取多个参与冒烟测试的任务;
分析单元,用于分析各所述任务之间的依赖关系;
测试单元,用于将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。
本申请还提供一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,所述处理器执行所述计算机程序时实现上述任一项所述方法的步骤。
本申请还提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述任一项所述的方法的步骤。
本申请的大数据冒烟测试方法、装置、计算机设备和存储介质,先对多个参与冒烟测试的任务进行依赖关系的分析,然后将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。本申请可以同时对多个任务进行冒烟测试,冒烟测试效率极大提升,快速地将大数据建构软件的风险查找出来。
附图说明
图1为本申请一实施例的大数据冒烟测试方法的流程示意图;
图2为本申请一实施例的各任务之间的依赖关系的示意图;
图3为本申请一实施例的大数据冒烟测试装置的结构示意框图;
图4为本申请一实施例的计算机设备的结构示意框图。
本申请目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
参照图1,本申请提供一种大数据冒烟测试方法,包括步骤:
S1、获取多个参与冒烟测试的任务;
S2、分析各所述任务之间的依赖关系;
S3、将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。
如上述步骤S1所述,上述冒烟测试是指在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码更改后,会按预期运行,且不会破坏整个版本的稳定性。大数据架构的软件主要进行大数据分析等任务,所以会同时并发多个任务,而在各任务执行具体操作之前,需要定时进行冒烟测试,以确定大数据架构软件的稳定性。本申请中,获取冒烟任务的方法包括多种,第一种是接收人为选取的任务作为参与冒烟测试的任务;第二种,在一张预设的第一任务列表中,随机抽取指定数量的任务作为参与冒烟测试的任务;第三种,在指定时间,获取预设的第二任务列表,该第二任务列表中的全部任务作为参与冒烟测试的任务等。
如上述步骤S2所述,上述依赖关系亦称“逻辑关系”。在项目管理中,表示两个活动(前导活动和后续活动)中一个活动的变更将会影响到另一个活动的关系。通常活动之间的依赖关系包括强制依赖关系、可自由处理的依赖关系和外部依赖关系三种形式。其中,强制依赖关系是工作任务中固有的依赖关系,是一种不可以违背的逻辑关系,又称硬逻辑关系,它是因为客观规律和位置条件的限制造成的。自由依赖关系是由项目团队定义的,例如:一个项目团队可能遵守一些好的做法,只有当用户签字认可后才开始新信息系统的详细设计,自由依赖关系有时也被称为软逻辑关系。外部依赖关系是指项目和非项目活动之间的关系。本申请中的依赖关系主要指上述的强制依赖关系。
本实施例中,在多个任务中,与其它任务没有依赖关系的任务,可以看做是离散任务;与其它任务有依赖关系的任务,可以看做是依赖任务,而各依赖任务又可能存在多条主脉和支脉等,可以将各主脉上的第一个任务看做第一顺为任务。具体地如图2所示,图2中包括A、B、C、D、E、F、G、H、I等多个任务,其中A、B、C与其它任务均没有依赖关系,则A、B、C为离散任务;D分别与E、F存在依赖关系,且D为第一顺为任务;G、H、I依次存在依赖关系,G为第一顺为任务。
如上述步骤S3所述,即将离散任务和第一顺位任务并发进行冒烟测试,具体地,如上述提及的A、B、C、D、E、F、G、H、I等多个任务,首先将上述的A、B、C三个离散任务和D、G两个第一顺位任务并发进行冒烟测试,当D任务完成后,分别对E、F任务进行冒烟测试,当G任务完成后,对H任务进行冒烟测试,当H任务后,对I任务进行冒烟测试。具体的并发触发可以使用多种方式进行,比如通过如linkdo的调度平台进行批量触发等,再此不赘述。
在一个实施例中,上述将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试的步骤S3之前,包括:
S301、获取各任务对应的数据;
S302、按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据。
如上述步骤S301和S302所述,不同的任务,其进行冒烟测试的数据不同,所以先获取对应任务的数据。获取的方法包括多种,比如根据预设的字段到源数据中进行调取等。上述将各任务对应的数据进行清洗,即为将不符合要求的数据进行清除处理的过程,上述脚本即为设定清洗规则语句的脚本,如针对某一任务的数据为数量值,则可以规定清除大于指定数量值的数,以及小于指定数量值的数等。将不符合要求的数据清理之后,可以提高冒烟测试的效率。
在一个实施例中,上述按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据的步骤S302之后,包括:
S303、判断各任务对应的剩余数据的数据量是否满足冒烟测试的需求;
S304、若否,则根据任务的属性构造对应的构造数据;
S305、将所述构造数据插入到所述剩余数据中。
如上述步骤S303至S305所述,冒烟测试时,需要一定量的测试数据,如果通过上述步骤S302后,剩余数据的数据量小于预设的阈值,则无法完成对应任务的冒烟测试,所以需要构造一些符合要求的数据,具体的构造过程包括:在指定数据库中检索符合要求的检索数据,并将检索到的检索数据插入到剩余数据中,如果插入检索数据后的剩余数据的数据量仍然达不到预设的阈值,则根据任务的属性以及对应的规则生成对应的构造数据,然后将构造数据也插入到剩余数据中。本实施例中,将检索数据和构造数据插入到剩余数据中的过程,会根据不同的表格式、是否含有敏感信息等信息使用不同的方法插入数据,数据插入的具体方法为常规方法,在此不在赘述。
在一个实施例中,上述获取多个参与冒烟测试的任务的步骤S1之前,包括:
S101、判断当前时间是否为指定时间;
S102、若为指定时间,则生成开启冒烟测试的命令。
如上述步骤S101和S102中,上述指定时间是用户设定的时间,因为大数据环境中,为了提高各任务的执行稳定性,要常常的对各大数据架构软件进行冒烟测试,本实施例中,会预设一个开启时间作为标记,当获取到该时间标记时,即会生成开启冒烟测试的命令,以执行上述冒烟测试的过程。在一个具体实施例中,上述指定时间一般为每天的某一个时刻,或者多个时刻等,具体的指定时间,可以根据大数据软件处理的数据类型合格任务类型而定。即可以将测试频率设定的高一点,也可以设定测试的频率低一点,只要能满足需求即可。
在一个实施例中,上述若为指定时间,则生成开启冒烟测试的命令的步骤102,包括:
S1021、若为指定时间,则判断所述当前的数据量是否达到预设量;
S1022、如果达到所述预设量,则生成开启冒烟测试的命令。
如上述步骤S1021和S1022所述,大数据一般为通过各种指定途径获取的需要的数据,有的时候,通过各种指定途径获取到的数据并不能达到预设量,比如,对某商场的大数据进行测试,但是由于商场当天的销售业绩等不佳,一次产生的相关数据较少,此时进行冒烟测试,则没有必要,反而会浪费测试资源,所以在开启冒烟测试的命令之前,先判定是否有冒烟测试的必要,如果达到预设量,则开启冒烟测试的命令,否则不开启冒烟测试的命令。
在一个实施例中,上述判断所述当前的数据量是否达到预设量的步骤S1022之后,包括:
S1023、如果未达到所述预设量,则开始按照预设频率监察数据库中的数据量;
S1024、当数据量达到预设量,则生成开启冒烟测试的命令。
如上述步骤S1023和S1024所述,即为如果数据量没有达到指定的预设量,则不会进行冒烟测试,但是并不会停止冒烟测试的要求,所以会按照预设频率监察数据中的数据量,上述的预设频率可以为每小时、每分钟、每3小时监察一次等。也就是说,即使在预设的时间没有进行冒烟测试,但是并不代表要等到下一个预设时间才能做冒烟测试,而是会在当前时间之后,实时监测数据量,当达到预设量时任然会进行冒烟测试。
在一个实施例中,上述分析各所述任务之间的依赖关系的步骤S2之后,包括:
S201、将存在依赖关系的所述任务按照依赖顺序存放到预设的依赖关系表中,以及将没有依赖关系的离散任务存放到预设的离散任务表中。
如上述步骤S201所述,因为大数据架构软件在形成之后,其在一定时间并不会进行修改等,所以其执行的任务一般不会改变,那么可能参与冒烟测试的任务并不会增加,所以将各任务按照依赖关系分别存放到两个列表中,当下一次进行冒烟测试的时候,可以直接调用两个表,以了解个任务的依赖关系,从而快速地进行冒烟测试。
在一个实施例中,上述将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试的步骤S3,包括:
S31、在所述依赖关系表中按照第一预设比例抽取存在依赖关系的任务,以及在所述离散任务表中按照第二预设比例抽取离散任务;
S32、将抽取的存在依赖关系的各任务的第一顺位任务,以及抽取的各离散任务并发进行冒烟测试,抽取的存在依赖关系的各任务按照依赖顺序进行冒烟测试。
如上述步骤S31和S32所述,每一次的冒烟测试并不需要对大数据架构软件的全部任务进行测试,只需要对部分任务进行冒烟测试即可,即以抽检的方式进行冒烟测试,以节省测试资源。
在又一个实施例中,先获上述依赖关系表中的多个离散任务进行冒烟测试,当离散任务全部完成冒烟测试后,对依赖关系表多个存在依赖关系的各任务进行冒烟测试。因为离散任务只是一个任务,如果每个任务的数据量相同的情况下,并发处理多个离散任务,其使用的时间基本相同,即同时开始,同时结束,方便管理等。
本申请实施例的大数据冒烟测试方法,先对多个参与冒烟测试的任务进行依赖关系的分析,然后将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。本申请可以同时对多个任务进行冒烟测试,冒烟测试效率极大提升,快速地将大数据建构软件的风险查找出来。
参照图3,本申请实施例中提供一种大数据冒烟测试装置,包括:
获取单元10,用于获取多个参与冒烟测试的任务;
分析单元20,用于分析各所述任务之间的依赖关系;
测试单元30,用于将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。
在上述获取单元10中,上述冒烟测试是指在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码更改后,会按预期运行,且不会破坏整个版本的稳定性。大数据架构的软件主要进行大数据分析等任务,所以会同时并发多个任务,而在各任务执行具体操作之前,需要定时进行冒烟测试,以确定大数据架构软件的稳定性。本申请中,获取冒烟任务的方法包括多种,第一种是接收人为选取的任务作为参与冒烟测试的任务;第二种,在一张预设的第一任务列表中,随机抽取指定数量的任务作为参与冒烟测试的任务;第三种,在指定时间,获取预设的第二任务列表,该第二任务列表中的全部任务作为参与冒烟测试的任务等。
在上述分析单元20中,上述依赖关系亦称“逻辑关系”。在项目管理中,表示两个活动(前导活动和后续活动)中一个活动的变更将会影响到另一个活动的关系。通常活动之间的依赖关系包括强制依赖关系、可自由处理的依赖关系和外部依赖关系三种形式。其中,强制依赖关系是工作任务中固有的依赖关系,是一种不可以违背的逻辑关系,又称硬逻辑关系,它是因为客观规律和位置条件的限制造成的。自由依赖关系是由项目团队定义的,例如:一个项目团队可能遵守一些好的做法,只有当用户签字认可后才开始新信息系统的详细设计,自由依赖关系有时也被称为软逻辑关系。外部依赖关系是指项目和非项目活动之间的关系。本申请中的依赖关系主要指上述的强制依赖关系。
本实施例中,在多个任务中,与其它任务没有依赖关系的任务,可以看做是离散任务;与其它任务有依赖关系的任务,可以看做是依赖任务,而各依赖任务又可能存在多条主脉和支脉等,可以将各主脉上的第一个任务看做第一顺为任务。具体地如图2所示。图2中包括A、B、C、D、E、F、G、H、I等多个任务,其中A、B、C与其它任务均没有依赖关系,则A、B、C为离散任务;D分别与E、F存在依赖关系,且D为第一顺为任务;G、H、I依次存在依赖关系,G为第一顺为任务。
在上述测试单元30中,即将离散任务和第一顺位任务并发进行冒烟测试,具体地,如上述提及的A、B、C、D、E、F、G、H、I等多个任务,首先将上述的A、B、C三个离散任务和D、G两个第一顺位任务并发进行冒烟测试,当D任务完成后,分别对E、F任务进行冒烟测试,当G任务完成后,对H任务进行冒烟测试,当H任务后,对I任务进行冒烟测试。具体的并发触发可以使用多种方式进行,比如通过如平安科技开发的linkdo的调度平台进行批量触发等,再此不赘述。
在一个实施例中,上述大数据冒烟测试装置,还包括:
数据获取单元,用于获取各任务对应的数据;
清洗单元,用于按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据。
本实施例中,不同的任务,其进行冒烟测试的数据不同,所以先通过数据获取单元获取对应任务的数据。数据获取单元获取数据的方法包括多种,比如根据预设的字段到源数据中进行调取等。上述将各任务对应的数据进行清洗,即为将不符合要求的数据进行清除处理的过程,上述脚本即为设定清洗规则语句的脚本,如针对某一任务的数据为数量值,则可以规定清除大于指定数量值的数,以及小于指定数量值的数等。将不符合要求的数据清理之后,可以提高冒烟测试的效率。
在一个实施例中,上述大数据冒烟测试装置,还包括:
第一判断单元,用于判断各任务对应的剩余数据的数据量是否满足冒烟测试的需求;
数据构造单元,用于若上述剩余数据的数据量不能满足冒烟测试的需求,则根据任务的属性构造对应的构造数据;
插入单元,用于将所述构造数据插入到所述剩余数据中。
本实施例中,在大数据冒烟测试时,需要一定量的测试数据,如果通过上述清洗单元对数据进行清洗之后,剩余数据的数据量小于预设的阈值,则无法完成对应任务的冒烟测试,所以需要构造一些符合要求的数据,数据构造单元具体的构造过程包括:在指定数据库中检索符合要求的检索数据,并将检索到的检索数据插入到剩余数据中,如果插入检索数据后的剩余数据的数据量仍然达不到预设的阈值,则根据任务的属性以及对应的规则生成对应的构造数据,然后将构造数据也插入到剩余数据中。本实施例中,将检索数据和构造数据插入到剩余数据中的过程,会根据不同的表格式、是否含有敏感信息等信息使用不同的方法插入数据,数据插入的具体方法为常规方法,在此不在赘述。
在一个实施例中,上述大数据冒烟测试装置,还包括:
第二判断单元,用于判断当前时间是否为指定时间;
生成单元,用于若当前时间是指定时间,则生成开启冒烟测试的命令。
在本实施例中,上述指定时间是用户设定的时间,因为大数据环境中,为了提高各任务的执行稳定性,要常常的对各大数据架构软件进行冒烟测试,本实施例中,会预设一个开启时间作为标记,当获取到该时间标记时,即会生成开启冒烟测试的命令,以执行上述冒烟测试的过程。在一个具体实施例中,上述指定时间一般为每天的某一个时刻,或者多个时刻等,具体的指定时间,可以根据大数据软件处理的数据类型合格任务类型而定。即可以将测试频率设定的高一点,也可以设定测试的频率低一点,只要能满足需求即可。
在一个实施例中,上述生成单元,包括:
判断模块,用于判断所述当前的数据量是否达到预设量;
第一生成模块,用于如果当前的数据量达到预设量,则生成开启冒烟测试的命令。
在本实施例中,大数据一般为通过各种指定途径获取的需要的数据,有的时候,通过各种指定途径获取到的数据并不能达到预设量,比如,对某商场的大数据进行测试,但是由于商场当天的销售业绩等不佳,一次产生的相关数据较少,此时进行冒烟测试,则没有必要,反而会浪费测试资源,所以在开启冒烟测试的命令之前,先判定是否有冒烟测试的必要,如果达到预设量,则开启冒烟测试的命令,否则不开启冒烟测试的命令。
在一个实施例中,上述上述生成单元,还包括:
监察模块,用于如果当前的数据量未达到预设量,则开始按照预设频率监察数据库中的数据量;
第二生成模块,用于当数据量达到预设量,则生成冒烟测试的命令。
本实施例中,即为如果数据量没有达到指定的预设量,则不会进行冒烟测试,但是并不会停止冒烟测试的要求,所以会按照预设频率监察数据中的数据量,上述的预设频率可以为每小时、每分钟、每3小时监察一次等。也就是说,即使在预设的时间没有进行冒烟测试,但是并不代表要等到下一个预设时间才能做冒烟测试,而是会在当前时间之后,实时监测数据量,当达到预设量时任然会进行冒烟测试。
在一个实施例中,上述大数据冒烟测试装置,还包括:
存储单元,用于将存在依赖关系的所述任务按照依赖顺序存放到预设的依赖关系表中,以及将没有依赖关系的离散任务存放到预设的离散任务表中。
在上述存储单元中,因为大数据架构软件在形成之后,其在一定时间并不会进行修改等,所以其执行的任务一般不会改变,那么可能参与冒烟测试的任务并不会增加,所以将各任务按照依赖关系分别存放到两个列表中,当下一次进行冒烟测试的时候,可以直接调用两个表,以了解个任务的依赖关系,从而快速地进行冒烟测试。
在一个实施例中,上述测试单元30,包括:
抽取模块,用于在所述依赖关系表中按照第一预设比例抽取存在依赖关系的任务,以及在所述离散任务表中按照第二预设比例抽取离散任务;
测试模块,用于将抽取的存在依赖关系的各任务的第一顺位任务,以及抽取的各离散任务并发进行冒烟测试,抽取的存在依赖关系的各任务按照依赖顺序进行冒烟测试。
在本实施例中,每一次的冒烟测试并不需要对大数据架构软件的全部任务进行测试,只需要对部分任务进行冒烟测试即可,即以抽检的方式进行冒烟测试,以节省测试资源。
在又一个实施例中,上述大数据冒烟测试装置,还包括:
分级测试单元,用于先获上述依赖关系表中的多个离散任务进行冒烟测试,当离散任务全部完成冒烟测试后,对依赖关系表多个存在依赖关系的各任务进行冒烟测试。因为离散任务只是一个任务,如果每个任务的数据量相同的情况下,并发处理多个离散任务,其使用的时间基本相同,即同时开始,同时结束,方便管理等。
本申请实施例的大数据冒烟测试装置,先对多个参与冒烟测试的任务进行依赖关系的分析,然后将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。本申请可以同时对多个任务进行冒烟测试,冒烟测试效率极大提升,快速地将大数据建构软件的风险查找出来。
参照图4,本申请实施例中还提供一种计算机设备,该计算机设备可以是服务器,其内部结构可以如图4所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中,该计算机设计的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储冒烟测试脚本、依赖关系表等数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种大数据冒烟测试方法。
上述处理器执行上述大数据冒烟测试方法的步骤为:获取多个参与冒烟测试的任务;分析各所述任务之间的依赖关系;将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。
在一个实施例中,上述将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试的步骤之前,包括:获取各任务对应的数据;按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据。
在一个实施例中,上述按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据的步骤之后,包括:判断各任务对应的剩余数据的数据量是否满足冒烟测试的需求;若否,则根据任务的属性构造对应的构造数据;将所述构造数据插入到所述剩余数据中。
在一个实施例中,上述获取多个参与冒烟测试的任务的步骤之前,包括:判断当前时间是否为指定时间;若为指定时间,则生成开启冒烟测试的命令。
在一个实施例中,上述若为指定时间,则生成开启冒烟测试的命令的步骤,包括:若为指定时间,则判断所述当前的数据量是否达到预设量;如果达到所述预设量,则生成开启冒烟测试的命令。
在一个实施例中,上述判断所述当前的数据量是否达到预设量的步骤之后,包括:如果未达到所述预设量,则开始按照预设频率监察数据库中的数据量;当数据量达到预设量,则生成开启冒烟测试的命令。
在一个实施例中,上述分析各所述任务之间的依赖关系的步骤之后,包括:将存在依赖关系的所述任务按照依赖顺序存放到预设的依赖关系表中,以及将没有依赖关系的离散任务存放到预设的离散任务表中。
本领域技术人员可以理解,图4中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定。
本申请实施例的计算机设备,先对多个参与冒烟测试的任务进行依赖关系的分析,然后将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。本申请可以同时对多个任务进行冒烟测试,冒烟测试效率极大提升,快速地将大数据建构软件的风险查找出来。
本申请一实施例还提供一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现一种大数据冒烟测试方法,具体为:获取多个参与冒烟测试的任务;分析各所述任务之间的依赖关系;将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。
上述大数据冒烟测试方法,先对多个参与冒烟测试的任务进行依赖关系的分析,然后将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。本申请可以同时对多个任务进行冒烟测试,冒烟测试效率极大提升,快速地将大数据建构软件的风险查找出来。
在一个实施例中,上述处理器将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试的步骤之前,包括:获取各任务对应的数据;按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据。
在一个实施例中,上述处理器按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据的步骤之后,包括:判断各任务对应的剩余数据的数据量是否满足冒烟测试的需求;若否,则根据任务的属性构造对应的构造数据;将所述构造数据插入到所述剩余数据中。
在一个实施例中,上述处理器获取多个参与冒烟测试的任务的步骤之前,包括:判断当前时间是否为指定时间;若为指定时间,则生成开启冒烟测试的命令。
在一个实施例中,上述处理器若为指定时间,则生成开启冒烟测试的命令的步骤,包括:若为指定时间,则判断所述当前的数据量是否达到预设量;如果达到所述预设量,则生成开启冒烟测试的命令。
在一个实施例中,上述处理器判断所述当前的数据量是否达到预设量的步骤之后,包括:如果未达到所述预设量,则开始按照预设频率监察数据库中的数据量;当数据量达到预设量,则生成开启冒烟测试的命令。
在一个实施例中,上述处理器分析各所述任务之间的依赖关系的步骤之后,包括:将存在依赖关系的所述任务按照依赖顺序存放到预设的依赖关系表中,以及将没有依赖关系的离散任务存放到预设的离散任务表中。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的和实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和/或易失性存储器。非易失性存储器可以包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限,RAM以多种形式可得,诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双速据率SDRAM(SSRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。
以上所述仅为本申请的优选实施例,并非因此限制本申请的专利范围,凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本申请的专利保护范围内。
Claims (10)
1.一种大数据冒烟测试方法,其特征在于,包括:
获取多个参与冒烟测试的任务;
分析各所述任务之间的依赖关系;
将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。
2.根据权利要求1所述的大数据冒烟测试方法,其特征在于,所述将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试的步骤之前,包括:
获取各任务对应的数据;
按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据。
3.根据权利要求2所述的大数据冒烟测试方法,其特征在于,所述按照预设脚本,将各任务对应的数据进行清洗,以得到用于针对各任务进行冒烟测试的剩余数据的步骤之后,包括:
判断各任务对应的剩余数据的数据量是否满足冒烟测试的需求;
若否,则根据任务的属性构造对应的构造数据;
将所述构造数据插入到所述剩余数据中。
4.根据权利要求1所述的大数据冒烟测试方法,其特征在于,所述获取多个参与冒烟测试的任务的步骤之前,包括:
判断当前时间是否为指定时间;
若为指定时间,则生成开启冒烟测试的命令。
5.根据权利要求4所述的大数据冒烟测试方法,其特征在于,所述若为指定时间,则生成开启冒烟测试的命令的步骤,包括:
若为指定时间,则判断所述当前的数据量是否达到预设量;
如果达到所述预设量,则生成开启冒烟测试的命令。
6.根据权利要求5所述的大数据冒烟测试方法,其特征在于,所述判断所述当前的数据量是否达到预设量的步骤之后,包括:
如果未达到所述预设量,则开始按照预设频率监察数据库中的数据量;
当数据量达到预设量,则生成开启冒烟测试的命令。
7.根据权利要求1所述的大数据冒烟测试方法,其特征在于,所述分析各所述任务之间的依赖关系的步骤之后,包括:
将存在依赖关系的所述任务按照依赖顺序存放到预设的依赖关系表中,以及将没有依赖关系的离散任务存放到预设的离散任务表中。
8.一种大数据冒烟测试装置,其特征在于,包括:
获取单元,用于获取多个参与冒烟测试的任务;
分析单元,用于分析各所述任务之间的依赖关系;
测试单元,用于将存在依赖关系的各任务的第一顺位任务,以及与其它任务没有依赖关系的离散任务并发进行冒烟测试,将有依赖关系的任务按照依赖顺序进行冒烟测试。
9.一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810948598.5A CN109240918A (zh) | 2018-08-20 | 2018-08-20 | 大数据冒烟测试方法、装置、计算机设备和存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810948598.5A CN109240918A (zh) | 2018-08-20 | 2018-08-20 | 大数据冒烟测试方法、装置、计算机设备和存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN109240918A true CN109240918A (zh) | 2019-01-18 |
Family
ID=65070174
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810948598.5A Pending CN109240918A (zh) | 2018-08-20 | 2018-08-20 | 大数据冒烟测试方法、装置、计算机设备和存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109240918A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110188046A (zh) * | 2019-05-31 | 2019-08-30 | 北京银企融合技术开发有限公司 | 研发质量的测评方法及装置 |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060265172A1 (en) * | 2005-05-13 | 2006-11-23 | Basham Robert B | Heterogeneous multipath path network test system |
CN101853201A (zh) * | 2010-05-24 | 2010-10-06 | 南京航空航天大学 | 一种基于着色petri网的软件并行测试方法及工具 |
CN102981946A (zh) * | 2011-09-07 | 2013-03-20 | 阿里巴巴集团控股有限公司 | Etl冒烟测试方法 |
CN105320589A (zh) * | 2014-07-14 | 2016-02-10 | 上海计算机软件技术开发中心 | 云测试环境中测试脚本自动解析系统及其实现方法 |
CN105426312A (zh) * | 2015-12-31 | 2016-03-23 | 北京经纬恒润科技有限公司 | 一种冒烟测试用例集生成方法和装置 |
CN105824746A (zh) * | 2015-01-05 | 2016-08-03 | 中国移动(深圳)有限公司 | 一种基于用例依赖关系自动生成测试调度的方法和装置 |
CN106407100A (zh) * | 2015-07-29 | 2017-02-15 | 中兴通讯股份有限公司 | 一种实现持续集成测试的方法及装置 |
CN106708719A (zh) * | 2015-08-04 | 2017-05-24 | 阿里巴巴集团控股有限公司 | 业务功能的测试方法和装置 |
CN107943708A (zh) * | 2017-12-19 | 2018-04-20 | 郑州云海信息技术有限公司 | 一种基于并行执行的web自动化测试方法 |
-
2018
- 2018-08-20 CN CN201810948598.5A patent/CN109240918A/zh active Pending
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060265172A1 (en) * | 2005-05-13 | 2006-11-23 | Basham Robert B | Heterogeneous multipath path network test system |
CN101853201A (zh) * | 2010-05-24 | 2010-10-06 | 南京航空航天大学 | 一种基于着色petri网的软件并行测试方法及工具 |
CN102981946A (zh) * | 2011-09-07 | 2013-03-20 | 阿里巴巴集团控股有限公司 | Etl冒烟测试方法 |
CN105320589A (zh) * | 2014-07-14 | 2016-02-10 | 上海计算机软件技术开发中心 | 云测试环境中测试脚本自动解析系统及其实现方法 |
CN105824746A (zh) * | 2015-01-05 | 2016-08-03 | 中国移动(深圳)有限公司 | 一种基于用例依赖关系自动生成测试调度的方法和装置 |
CN106407100A (zh) * | 2015-07-29 | 2017-02-15 | 中兴通讯股份有限公司 | 一种实现持续集成测试的方法及装置 |
CN106708719A (zh) * | 2015-08-04 | 2017-05-24 | 阿里巴巴集团控股有限公司 | 业务功能的测试方法和装置 |
CN105426312A (zh) * | 2015-12-31 | 2016-03-23 | 北京经纬恒润科技有限公司 | 一种冒烟测试用例集生成方法和装置 |
CN107943708A (zh) * | 2017-12-19 | 2018-04-20 | 郑州云海信息技术有限公司 | 一种基于并行执行的web自动化测试方法 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110188046A (zh) * | 2019-05-31 | 2019-08-30 | 北京银企融合技术开发有限公司 | 研发质量的测评方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Samoladas et al. | Survival analysis on the duration of open source projects | |
CN110490720A (zh) | 财务数据分析预警方法、装置、计算机设备和存储介质 | |
US10997637B2 (en) | Method and system for determining quality of application based on user behaviors of application management | |
CN106681913A (zh) | 一种应用卡顿定位系统及方法 | |
Madeira | Definition of software fault emulation operators: A field data study | |
Strandberg et al. | Experience report: Automated system level regression test prioritization using multiple factors | |
CN109189675A (zh) | 大数据架构软件测试方法、装置、计算机设备和存储介质 | |
CN103631713A (zh) | Erp软件自动化测试系统及方法 | |
Asghar et al. | Impact and challenges of requirements elicitation & prioritization in quality to agile process: Scrum as a case scenario | |
CN106227654A (zh) | 一种测试平台 | |
CN108681505B (zh) | 一种基于决策树的测试用例排序方法和装置 | |
Andersson et al. | A spiral process model for case studies on software quality monitoring—method and metrics | |
CN112632179A (zh) | 模型构建方法、装置、存储介质及设备 | |
CN106874306B (zh) | 人口信息人像比对系统关键性能指标评测方法 | |
CN115730947A (zh) | 银行客户流失预测方法及装置 | |
Majumdar et al. | Assessing software upgradation attributes and optimal release planning using DEMATEL and MAUT | |
CN109240918A (zh) | 大数据冒烟测试方法、装置、计算机设备和存储介质 | |
CN111459796B (zh) | 自动化测试方法、装置、计算机设备和存储介质 | |
Singla et al. | Analysis of software engineering for agile machine learning projects | |
Jalote et al. | The When–Who–How analysis of defects for improving the quality control process | |
CN115860430A (zh) | 一种信息系统监理项目的进度管理方法及系统 | |
CN112860527A (zh) | 应用服务器的故障监测方法及装置 | |
CN115599621A (zh) | 微服务异常诊断方法、装置、设备及存储介质 | |
CN112015648A (zh) | 基于自动化脚本的测试方法、装置、计算机设备和介质 | |
Kamma et al. | High productivity programmers use effective task processes in unit-testing |
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 |