CN113051180A - 测试任务的监测方法、装置、设备及存储介质 - Google Patents
测试任务的监测方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN113051180A CN113051180A CN202110482322.4A CN202110482322A CN113051180A CN 113051180 A CN113051180 A CN 113051180A CN 202110482322 A CN202110482322 A CN 202110482322A CN 113051180 A CN113051180 A CN 113051180A
- Authority
- CN
- China
- Prior art keywords
- test
- monitoring
- task
- monitored
- historical
- 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.)
- Granted
Links
Images
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/3684—Test management for test design, e.g. generating new test cases
-
- 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
-
- 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/3692—Test management for test results analysis
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
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)
- Debugging And Monitoring (AREA)
Abstract
本发明涉及研发管理技术领域,公开了一种测试任务的监测方法、装置、设备及存储介质。本方法包括:确定待监测系统,并根据获取的与待监测系统对应的历史缺陷集合和待监测系统的参数信息生成待监测任务;将待监测任务发送到对应待监测系统,生成监测任务列表中的所有监测任务;通过预设任务执行顺序执行监测任务,获取监测任务中所有测试任务的运行结果;根据预置结果验证数据对运行结果进行验证,判断历史缺陷是否复现;生成监测报告;确定历史缺陷复现的原因,发送告警邮件至预设邮箱。解决了无法对逻辑缺陷和定制化登录场景下的历史缺陷进行监测的技术问题。
Description
技术领域
本发明涉及研发管理技术领域,尤其涉及一种测试任务的监测方法、装置、设备及存储介质。
背景技术
在软件开发过程中或者开发完后,通常需要对软件进行相关测试,及时发现问题,从而保证软件在发布后能够正常运行。测试任务的监测是指对所测试的系统(或对象)历史上已发现并修复的缺陷进行监测,目的是当由于运行环境切换、运行机器变更等因素出现导致历史缺陷再次出现时,可以第一时间发现。避免历史缺陷复现对系统造成风险。
目前,已有的历史缺陷扫描工具都是基于已有的缺陷POC或者现象进行的监测,因逻辑缺陷需要在不同的系统角色进行切换操作,根据返回的现象不同来判断,需要自定义监测内容,且很多系统的缺陷需要在已登录状态才会显现,所以不能用对逻辑缺陷和系统定制化对应的登录场景下的历史缺陷等无表象的缺陷进行监测;即使缺陷复现后可监测但无法判断由于什么变更导致。加上历史出现过的严重缺陷,一旦由于运营或者其它因素导致缺陷的复现,将对系统带来很大的风险,从而影响公司的营收。
发明内容
本发明的主要目的是解决了无法对测试任务中的逻辑缺陷和特定登录场景下的历史缺陷进行监测的技术问题,提高了测试效率。
本发明第一方面提供了一种测试任务的监测方法,包括:
确定待监测系统,获取与所述待监测系统对应的历史缺陷集合与所述待监测系统的参数信息,并根据所述历史缺陷集合和所述参数信息生成监测任务,其中,所述历史缺陷集和中包括至少一个历史缺陷,所述监测任务中包括至少一个测试任务;
将所述监测任务发送至所述待监测系统,生成监测任务列表,其中所述监测任务列表中包含至少一个监测任务,所述监测任务中包含至少一个测试任务;
基于预设任务执行顺序执行所述监测任务,获取所述监测任务中所有测试任务的运行结果;
根据预置结果验证数据对所述测试任务的运行结果进行验证,基于所述验证结果判断所述历史缺陷集合中是否有历史缺陷复现,并生成监测报告;
若存在历史缺陷复现,则基于所述监测报告确定所述待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
可选地,在本发明第一方面的第一种实现方式中,在确定待监测系统,获取与所述待监测系统对应的历史缺陷集合与所述待监测系统的参数信息,并根据所述历史缺陷集合和所述参数信息生成监测任务之前,还包括:
获取目标测试脚本,并将所述目标测试脚本发送至预置用例测试管理平台,其中,所述目标测试脚本是所述待监测系统对应的初始测试用例的测试脚本;
基于所述目标测试脚本进行测试,获取测试结果,其中,所述测试结果包括通过标识或未通过标识;
将携带未通过标识的所述测试结果上传至预置用例缺陷管理平台,得到与测试用例对应的缺陷,并根据所述缺陷得到所述待监测系统的历史缺陷集合。
可选地,在本发明第一方面的第二种实现方式中,所述确定待监测系统,获取与所述待监测系统对应的历史缺陷集合与所述待监测系统的参数信息,并根据所述历史缺陷集合和所述参数信息生成监测任务包括:
确定待监测系统,并获取所述待监测系统的初始测试用例;
获取所述历史缺陷集合中的所有历史缺陷,根据所述历史缺陷分别从预置测试用例模板集中选取与所述所有历史缺陷对应的预设测试用例模板,其中,所述测试用例模板集中包含至少一个测试用例模板;
根据所述测试用例模板及所述初始测试用例,分别生成与所述所有历史缺陷对应的所有目标测试用例;
根据所述所有目标测试用例,生成监测任务。
可选地,在本发明第一方面的第三种实现方式中,所述根据所述测试用例模板及所述初始测试用例,分别生成与所述所有历史缺陷对应的所有目标测试用例包括:
从所述初始测试用例中提取参数信息,其中,所述参数信息包括测试输入信息、执行参数信息以及预期结果;
根据所述预设测试用例模板以及所述参数信息,生成与所述历史缺陷对应的目标测试用例。
可选地,在本发明第一方面的第四种实现方式中,所述基于预设任务执行顺序执行所述监测任务,获取所述监测任务中所有测试任务的运行结果包括:
建立至少一个目标测试用例与至少一个历史缺陷的映射关系;
确定每个所述目标测试用例检测所有所述历史缺陷时对应的每种影响因子的能力值;
通过每种所述影响因子对应的预设权重值和所述能力值,确定每个所述目标测试用例的优先级取值;
将每个所述目标测试用例按照所述优先级取值进行优先级排序,得到排序结果;
基于排序结果,对所述监测任务中的目标测试用例进行测试,得到所述测试任务的运行结果。
可选地,在本发明第一方面的第五种实现方式中,根据预置结果验证数据对所述测试任务的运行结果进行验证,基于所述验证结果判断所述历史缺陷集合中是否有历史缺陷复现包括:
获取所述测试任务运行结果,其中,所述测试任务运行结果中包括多个目标测试用例对应的测试结果;
将预置结果验证数据与所述目标测试用例对应的测试结果进行比对,分别判断所述目标测试用例对应的测试结果与所述结果验证数据是否一致;
若所述目标测试用例对应的测试结果与所述结果验证数据不一致,则存在历史缺陷复现。
本发明第二方面提供了一种测试任务的监测装置,包括:
生成模块,用于确定待监测系统,获取与所述待监测系统对应的历史缺陷集合与所述待监测系统的参数信息,并根据所述历史缺陷集合和所述参数信息生成监测任务,其中,所述历史缺陷集和中包括至少一个历史缺陷,所述监测任务中包括至少一个测试任务;
发送模块,用于将所述监测任务发送至所述待监测系统,生成监测任务列表,其中所述监测任务列表中包含至少一个监测任务,所述监测任务中包含至少一个测试任务;
第一获取模块,用于基于预设任务执行顺序执行所述监测任务,获取所述监测任务中所有测试任务的运行结果;
判断模块,用于根据预置结果验证数据对所述测试任务的运行结果进行验证,基于所述验证结果判断所述历史缺陷集合中是否有历史缺陷复现,并生成监测报告;
确定模块,用于当存在历史缺陷复现时,基于所述监测报告确定所述待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
可选地,在本发明第二方面的第一种实现方式中,所述测试任务的监测装置还包括:
第二获取模块,用于获取目标测试脚本,并将所述目标测试脚本发送至预置用例测试管理平台,其中,所述目标测试脚本是所述待监测系统对应的初始测试用例的测试脚本;
测试模块,用于基于所述目标测试脚本进行测试,获取测试结果,其中,所述测试结果包括通过标识或未通过标识;
上传模块,用于将携带未通过标识的所述测试结果上传至预置用例缺陷管理平台,得到与测试用例对应的缺陷,并根据所述缺陷得到所述待监测系统的历史缺陷集合。
可选地,在本发明第二方面的第二种实现方式中,所述生成模块包括:
确定单元,用于确定待监测系统,并获取所述待监测系统的初始测试用例;
选取单元,用于获取所述历史缺陷集合中的所有历史缺陷,根据所述历史缺陷分别从预置测试用例模板集中选取与所述所有历史缺陷对应的预设测试用例模板,其中,所述测试用例模板集中包含至少一个测试用例模板;
生成单元,用于根据所述测试用例模板及所述初始测试用例,分别生成与所述所有历史缺陷对应的目标测试用例;根据所述所有目标测试用例,生成监测任务。
可选地,在本发明第二方面的第三种实现方式中,所述生成单元具体用于:
从所述初始测试用例中提取参数信息,其中,所述参数信息包括测试输入信息、执行参数信息以及预期结果;
根据所述预设测试用例模板以及所述参数信息,生成与所述历史缺陷对应的目标测试用例。
可选地,在本发明第二方面的第四种实现方式中,所述第一获取模块具体用于:
建立至少一个目标测试用例与至少一个历史缺陷的映射关系;
确定每个所述目标测试用例检测所有所述历史缺陷时对应的每种影响因子的能力值;
通过每种所述影响因子对应的预设权重值和所述能力值,确定每个所述目标测试用例的优先级取值;
将每个所述目标测试用例按照所述优先级取值进行优先级排序,得到排序结果;
基于排序结果,对所述监测任务中的目标测试用例进行测试,得到所述测试任务的运行结果。
可选地,在本发明第二方面的第五种实现方式中,所述判断模块具体用于:
获取所述测试任务运行结果,其中,所述测试任务运行结果中包括多个目标测试用例对应的测试结果;
将预置结果验证数据与所述目标测试用例对应的测试结果进行比对,分别判断所述目标测试用例对应的测试结果与所述结果验证数据是否一致;
若所述目标测试用例对应的测试结果与所述结果验证数据不一致,则存在历史缺陷复现。
本发明第三方面提供了一种测试任务的监测设备,包括:存储器和至少一个处理器,所述存储器中存储有指令,所述存储器和所述至少一个处理器通过线路互连;
所述至少一个处理器调用所述存储器中的所述指令,以使得所述测试任务的监测设备执行上述的测试任务的监测方法。
本发明的第四方面提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述的测试任务的监测方法。
本发明提供的技术方案中,确定待监测系统,并根据获取的与待监测系统对应的历史缺陷集合和待监测系统的参数信息生成待监测任务;将待监测任务发送到对应待监测系统,生成监测任务列表中的所有监测任务;通过预设任务执行顺序执行监测任务,获取监测任务中所有测试任务的运行结果;根据预置结果验证数据对运行结果进行验证,判断历史缺陷是否复现;生成监测报告;确定历史缺陷复现的原因,发送告警邮件至预设邮箱。解决了无法对逻辑缺陷和定制化登录场景下的历史缺陷进行监测的技术问题。
附图说明
图1为本发明测试任务的监测方法的第一个实施例示意图;
图2为本发明测试任务的监测方法的第二个实施例示意图;
图3为本发明测试任务的监测方法的第三个实施例示意图;
图4为本发明测试任务的监测方法的第四个实施例示意图;
图5为本发明测试任务的监测方法的第五个实施例示意图;
图6为本发明测试任务的监测装置的第一个实施例示意图;
图7为本发明测试任务的监测装置的第二个实施例示意图;
图8为本发明测试任务的监测设备的一个实施例示意图。
具体实施方式
本发明实施例提供了一种测试任务的监测方法、装置、设备及存储介质,本发明的技术方案中,先确定待监测系统,并根据获取的与待监测系统对应的历史缺陷集合和待监测系统的参数信息生成待监测任务;将待监测任务发送到对应待监测系统,生成监测任务列表中的所有监测任务;通过预设任务执行顺序执行监测任务,获取监测任务中所有测试任务的运行结果;根据预置结果验证数据对运行结果进行验证,判断历史缺陷是否复现;生成监测报告;确定历史缺陷复现的原因,发送告警邮件至预设邮箱。解决了无法对逻辑缺陷和定制化登录场景下的历史缺陷进行监测的技术问题。
本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”或“具有”及其任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
为便于理解,下面对本发明实施例的具体流程进行描述,请参阅图1,本发明实施例中测试任务的监测方法的第一个实施例包括:
101、确定待监测系统,并获取与待监测系统对应的历史缺陷集合与待监测系统的参数信息,并根据历史缺陷集合和参数信息生成监测任务,其中,缺陷集合中包括至少一个历史缺陷;
本实施例中,待监测系统也可以叫测试对象,是指需要进行测试任务的某特定的软件系统。测试人员登录配置中心,添加需要监测缺陷的系统、系统URL地址、请求参数、登录地址、登录帐号密码(如需要,可能为多个)、缺陷类型、验证方法、验证匹配内容、监测频率、内/外网环境、是否启用等信息,添加后同时有修改功能,可随时进行修改或者启用/禁用操作。
本实施例中,缺陷(Bug,缺陷)为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷产生的原因一般包括:需求表达理解、解码过程中一起的错误;系统设计架构引起的错误;开发过程中缺乏有效的沟通及监督;程序员编码过程产生的错误;软件开发工具本身的问题;软件需求、复杂度越来越高或者与用户需求不符合,即使本身不存在某种意义上的错误。
根据缺陷对系统运行造成的影响来划分缺陷的严重性,一般分为四个等级:致命缺陷、严重缺陷、普通缺陷、轻微缺陷。
102、将监测任务发送至待监测系统,生成监测任务列表;
本实施例中,监测平台根据内/外网环境将监测任务下发到上一步配置的待监测的系统上,被检测的系统收到平台下发的任务后,将任务加入到系统的计划程序,其中,计划程序指的是windows的任务计划程序、linux的crond服务。
103、基于预设任务执行顺序执行监测任务,获取待监测系统中所有测试任务的运行结果;
本实施例中,根据监测任务确定待监测系统对目标测试用例,进一步地,建立至少一个目标测试用例与至少一个历史缺陷的映射关系,例如,每个缺陷都有其对应执行的测试用例,找出他们的映射关系,形成一个矩阵,其中的取值为1或0;当第i个测试用例发现了软件的第j个缺陷时,取值为1,否则为0;i=1、2、3、……、m,j=1、2、3、……、n。
根据目标测试用例对待监测系统进行测试,得到该监测任务的任务运行结果,其中,任务运行结果中包含有多个目标测试用例对应的测试结果,并记录日志信息生成监测报告。
104、根据预置结果验证数据对测试任务的运行结果进行验证,并基于验证的结果判断历史缺陷集合中是否有历史缺陷复现,并生成监测报告;
本实施例中,根据目标测试用例的排序结果和待监测系统在进行上轮测试时对应的运行环境信息对待监测系统进行测试,得到该监测任务的任务运行结果,其中,任务运行结果中包含有多个目标测试用例对应的测试结果,并记录日志信息生成监测报告。若目标测试用例对应的测试结果与预期结果一致,则说明待检测系统运行正常,没有缺陷,也即历史缺陷未复现;并将每一个目标测试用例对应的测试结果和对应运行环境等信息以日志形式记录,生成监测报告。监测报告中包括运行环境信息、应用版本号及所述待监测系统对应的代码版本等信息。
105、若存在历史缺陷复现,则基于监测报告确定待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
本实施例中,当历史缺陷复现,说明待监测系统在本次检测中,上次出现过的(历史)缺陷本次又再一次出现则根据监测报告确定历史缺陷复现的原因,比如目标系统的代码版本、运行环境信息、应用版本等相关信息改变,同时,将向相关人员发送告警邮件,若为严重缺陷,可编辑发送短信通知,直至告警关闭为止。根据缺陷对系统运行造成的影响来划分缺陷的严重性,一般分为四个等级:致命缺陷、严重缺陷、普通缺陷、轻微缺陷。
本发明实施例通过确定待监测系统,并从预置用例缺陷管理平台获取与待监测系统对应的缺陷集合与待监测系统的参数信息,生成待监测任务;将待监测任务发送到对应待监测系统,得到监测任务列表;获取监测任务列表中的所有监测任务,并根据每个监测任务对应的历史缺陷,对待监测系统进行监测,得到任务运行结果;根据预置结果验证数据对任务运行结果进行验证,判断历史缺陷是否复现,记录对应日志信息并生成监测报告;根据所述监测报告,确定历史缺陷复现的原因,并发送告警邮件至预设邮箱。本方案可以解决现有历史缺陷扫描工具无法对逻辑缺陷和系统定制化对应的登录场景下的历史缺陷进行监测的技术问题。可以检测各系统的历史缺陷,对环境变更或者代码变更等一些未知影响实现监测,并支持对逻辑性缺陷的验证和多用户操作模拟,多登录状态的验证。平台带有邮箱、短信通知告警功能,使相关人员能够在第一时间内获取监测报告,快速做出响应。避免历史出现过的严重缺陷复现,对系统带来巨大风险。
本发明实施例中,确定待监测系统,并根据获取的与待监测系统对应的历史缺陷集合和待监测系统的参数信息生成待监测任务;将待监测任务发送到对应待监测系统,生成监测任务列表中的所有监测任务;通过预设任务执行顺序执行监测任务,获取监测任务中所有测试任务的运行结果;根据预置结果验证数据对运行结果进行验证,判断历史缺陷是否复现;生成监测报告;确定历史缺陷复现的原因,发送告警邮件至预设邮箱。解决了无法对逻辑缺陷和定制化登录场景下的历史缺陷进行监测的技术问题。
请参阅图2,本发明实施例中测试任务的监测方法的第二个实施例包括:
201、获取目标测试脚本,并将目标测试脚本发送至预置用例测试管理平台,其中,目标测试脚本是待监测系统对应的初始测试用例的测试脚本;
本实施例中,自动化测试需要根据测试脚本进行测试,因此需要将目标测试用例进行脚本化处理。目标测试脚本是将测试人员编辑好的测试用例进行脚本化处理得到的测试脚本。具体地,用例编辑管理平台会将得到的目标测试脚本发送到用例测试管理平台。在用例编辑管理平台中基于目标测试用例,依序调用与至少两个用例执行编号对应的基础动作,形成原始测试脚本。其中,用例执行编号与基础动作关联,数据库中存储有每个基础动作的动作ID对应的动作执行代码。具体地,用例编辑管理平台在接收到用例审核平台发送的携带有审核通过标识的目标测试用例后,会获取测试人员输入的用例脚本化指令。该用例脚本化指令包括与至少两个用例执行编号相关联的动作ID。用例编辑管理平台会基于动作ID依序调用目标测试用例中每个用例执行编号对应的动作执行代码,以形成原始测试脚本。
获取用户输入的脚本修改指令,脚本修改指令包括动作ID和调节参数。可以理解地,每一基础动作对应的动作执行代码包括方法函数和对应的原始参数。其中,调节参数是指测试人员根据系统需求对原始测试脚本进行修改时所输入的参数。具体地,动作执行代码包括用于实现基础动作的方法函数和对应的原始参数;此时,用户可向用例编辑管理平台输入脚本修改指令,以将原始参数修改为脚本修改指令中的调节参数。例如当测试人员选择的基础动作为“打开浏览器”时,其对应的动作执行脚本包括用于实现打印浏览器功能的方法函数和对应的原始参数,可以对浏览器的网址进行更改,输入所需的调节参数(即所需网址),以使原始测试用例更合符合待测试系统的需求。
对原始测试脚本进行修改,以形成目标测试脚本。具体地,通过获取的每一动作执行代码对应的调节参数修改原始测试脚本中与动作ID对应的动作执行代码,以形成目标测试脚本,并将目标测试脚本发送到用例测试管理平台。
202、基于目标测试脚本进行测试,获取测试结果,其中,测试结果包括通过标识或未通过标识;
本实施例中,测试结果包括通过标识和未通过标识。具体地,在测试完成后,用例测试管理平台会将测试结果发送到与测试人员ID对应的邮箱。
203、将携带未通过标识的测试结果上传至预置用例缺陷管理平台,得到与测试用例对应的缺陷,并根据缺陷得到待监测系统的历史缺陷集合;
本实施例中,用例缺陷管理平台是指分析人员对测试结果进行分析获取缺陷报告的平台。具体地,用例测试管理平台接收携带未通过标识的测试结果之后,将测试结果上传到用例缺陷管理平台。本实施例中,当测试人员对待测试系统进行批量测试时,可能会得到多个携带未通过标识的测试结果,则测试人员在点击“上传”时,会弹出“是否选择批量上传”的窗口,测试人员只要点击“是”即可输入批量上传指令,基于该批量上传指令可将所选中的多个携带未通过标识的测试结果批量上传到用例缺陷管理平台。
分析人员在用例缺陷管理平台上查看用例测试管理平台上传的携带未通过标识的测试结果时,可基于该测试结果分析确定其对应的测试缺陷名称,并上传相应的该测试缺陷名称和缺陷处理方法,点击确认按钮后即可向用例缺陷管理平台输入缺陷编辑请求。用例缺陷管理平台获取到的每一缺陷编辑请求时,会在与用例缺陷管理平台对应的数据库中存储测试缺陷名称和对应的缺陷处理方法,例如测试缺陷的名称为“按钮控件中的文字被截断”,则对应的缺陷处理方法为设置按钮的背景色替换系统自带的背景色,让文字完整显示。通过在在数据库中预存储测试缺陷名称和对应的缺陷处理方法,以便于后续调用相应的缺陷处理方法进行处理,提高处理效率。
本实施例中,采用聚类算法对至少两个测试缺陷名称进行聚类处理,以使用例缺陷管理平台对测试缺陷名称进行分类管理,形成分级显示的测试缺陷列表。其中,测试缺陷列表是预先存储好的包括至少两个测试缺陷的缺陷列表。具体地,采用K-means聚类算法对至少两个测试缺陷名称进行聚类处理,以使用例缺陷管理平台对测试缺陷名称进行分类管理,形成分级显示的测试缺陷列表,方便管理并可使用户能够更直观的查看服务器存储的所有测试缺陷。
204、确定待监测系统,并获取与待监测系统对应的历史缺陷集合与待监测系统的参数信息,并根据历史缺陷集合和参数信息生成监测任务;
205、将监测任务发送至待监测系统,生成监测任务列表;
206、基于预设任务执行顺序执行监测任务,获取待监测系统中所有测试任务的运行结果;
207、根据预置结果验证数据对测试任务的运行结果进行验证,并基于验证的结果判断历史缺陷集合中是否有历史缺陷复现,并生成监测报告;
208、若存在历史缺陷复现,则基于监测报告确定待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
本实施例中步骤204-208与第一实施例中的步骤101-105类似,此处不再赘述。
本发明实施例中,确定待监测系统,并根据获取的与待监测系统对应的历史缺陷集合和待监测系统的参数信息生成待监测任务;将待监测任务发送到对应待监测系统,生成监测任务列表中的所有监测任务;通过预设任务执行顺序执行监测任务,获取监测任务中所有测试任务的运行结果;根据预置结果验证数据对运行结果进行验证,判断历史缺陷是否复现;生成监测报告;确定历史缺陷复现的原因,发送告警邮件至预设邮箱。解决了无法对逻辑缺陷和定制化登录场景下的历史缺陷进行监测的技术问题。
请参阅图3,本发明实施例中测试任务的监测方法的第三个实施例包括:
301、确定待监测系统,并获取待监测系统的初始测试用例;
本实施例中,待监测系统可以是指某些进行功能测试的功能性APP,比如支付宝,微信,手机银行app等,这些功能软件所具有的功能可以通过程序代码实现,为了方便安装以及方便程序代码的维护,代码中设置多个API(Application Programming Interface,应用程序编程接口)接口,其中,API接口(应用程序编程接口)是一些预先定义的函数,目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力,而又无需访问源码,或理解内部工作机制的细节。其中,各个功能在推向市场供用户使用之前,为了确保其功能的正常实现,需要对接口进行测试,以实现支付功能的接口为例,当账户名与输入的支付密码都正确时,才能实现支付成功,可能只有一种场景;但是当账户或者密码有一个错误的时候,支付便不会成功,这个包括多种场景,例如,账户名和密码均错误或者账户名或者密码有一个错的,均不能支付成功,对于支付成功或者失败均需要进行测试,将支付成功和各种支付不成功时用到的参数,编辑到接口文档数据中,储存在电脑或者手机等终端设备的文档库中。此时,“实现支付功能的接口”就是一个待监测系统。
测试用例(Test Case,测试用例)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果的测试模型,以便实现在测试某个输入信息在其设定的执行条件和参数下得到的运行结果是否满足预期结果的测试功能。
初始测试用例是指,待监测系统为了实现在推向市场供用户使用之前,为了确保其功能的正常实现,需要对接口进行的测试对应的所有测试用例中,实际(测试)结果与预期(测试)结果不相符的测试用例,又叫做初始测试用例。
302、获取历史缺陷集合中的所有历史缺陷,根据历史缺陷分别从预置测试用例模板集中选取与所有历史缺陷对应的预设测试用例模板;
本实施例中,缺陷集中包含至少一个历史缺陷,历史缺陷是指待监测系统在上一轮测试使用的测试用例检测系统时发现的缺陷,是根据初始测试用例的实际(测试)结果与预期(测试)结果确定的。
本实施例中,通常情况下,在对待监测系统对应的测试用例,都是基于不同的测试需求来生成的。然而,在实际的测试过程中,不同的测试用例的测试结果是不同的,有的测试结果符合预期结果,有的则不符合预期结果。因此,对于此类测试结果不符合预期的测试用例,在测试系统中会生成对应的测试报告。
本实施例中,可以根据上述测试报告中获取实际(测试)结果与预期(测试)结果不相符的测试用例作为初始测试用例。并以此初始测试用例来确定待监测系统在(上一轮)测试过程中存在的缺陷,即本实施例所述的历史缺陷。
当然,在本实施例中,对于初始测试用例的获取方式包括但不限于上述所述的方法,还可以根据实际需要选取其他的方式进行,在此不做具体的限定。
本实施例中,预设测试用例模板集合中至少包含一个预设测试用例模板。具体的,在本实施例中,预设测试用例模板可以根据用户需要进行设定。例如,可以根据需要设定用于实现支付功能的接口测试用例的测试用例模板。当然,在本实施例中,预设测试用例模板的构建方式可以选取现有的测试用例的构建方式来进行,在此并不做限定。
在本实施例中,预设测试用例模板可以对应不同的缺陷来进行设定,因此,在本步骤中,在选取对应历史缺陷的预设测试用例模板时,可以根据预设测试用例模板集中每一个的预设测试用例模板的缺陷标签来选取,具体的,标签的种类和添加标签的方式与构建所述预设测试用例模板集合时所确定,在此并不做限定,但是要确保预设测试用例模板能够与测试过程中可能存在的不同的历史缺陷相对应。
本实施例中,通过初试测试用例中获取对应的参数信息。具体的,本步骤可以包括:首先,从初始测试用例中提取参数信息,其中,在该参数信息中包括测试输入信息、执行参数信息以及预期结果。然后,根据预设测试用例模板以及参数信息,构建对应历史缺陷的目标测试用例。
303、根据测试用例模板及初始测试用例,分别生成与所有历史缺陷对应的所有目标测试用例;
本实施例中,预设测试用例模板集合中至少包含一个预设测试用例模板,测试用例模板集合中的每个预设测试用例分别对应不同的测试类型。
具体的,本步骤可以按照以下方式进行:首先,确定对应历史缺陷的测试类型。然后,从测试用例模板集合中获取对应测试类型的预设测试用例模板。
本实施例中,测试类型分别为:组合类型、顺序类型、触发类型、反馈类型等多种类型。例如,组合类型可以理解为对于测试目标的输入信息中的多种不同的输入信息需要根据一定的排列组合才能确定测试目标的功能是否正常的测试类型;顺序类型可以理解为针对一定的时间顺序将输入信息进行输入的测试类型。
由于已经确定了对应目标缺陷的预设测试用例模板,并且由于测试用例的生成是通过模板及参数信息生成的,因此,在本步骤中需要通过初试测试用例中获取对应的参数信息。具体的,本步骤可以包括:首先,从初始测试用例中提取参数信息,其中,在该参数信息中包括测试输入信息、执行参数信息以及预期结果。然后,根据预设测试用例模板以及参数信息,构建对应历史缺陷的目标测试用例。
由此,通过从初始测试用例中提取参数信息,能够确保参数信息的准确,从而为生成目标测试用例的准确性提供保障。
304、根据所有目标测试用例,生成监测任务;
本实施例中,根据生成的目标测试用例,对待监测系统进行二次测试,根据测试结果,确定历史缺陷是否复现。此处的测试过程,就是对应的测试任务。比如,微信,支付宝,淘宝等,这些功能软件所具有的功能可以通过程序代码实现,为了方便安装以及方便程序代码的维护,代码中设置多个API(Application Programming Interface,应用程序编程接口)接口其中,各个功能在推向市场供用户使用之前,为了确保其功能的正常实现,需要对接口进行测试,得到对应的此事结果,以发现系统可能存在的缺陷。为了防止由于环境切换、运行机器变更等原因,导致这些缺陷再次出现对系统造成风险的情况出现,需要根据这些缺陷对应的测试用例,对待监测系统进行二次测试,判断历史缺陷是否复现并确定缺陷复现的原因。
305、将监测任务发送至待监测系统,生成监测任务列表;
306、基于预设任务执行顺序执行监测任务,获取待监测系统中所有测试任务的;
307、根据预置结果验证数据对测试任务的运行结果进行验证,并基于验证的结果判断历史缺陷集合中是否有历史缺陷复现,并生成监测报告;
308、若存在历史缺陷复现,则基于监测报告确定待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
本实施例中步骤305-308与第一实施例中的步骤102-105类似,此处不再赘述。
本发明实施例中,确定待监测系统,并根据获取的与待监测系统对应的历史缺陷集合和待监测系统的参数信息生成待监测任务;将待监测任务发送到对应待监测系统,生成监测任务列表中的所有监测任务;通过预设任务执行顺序执行监测任务,获取监测任务中所有测试任务的运行结果;根据预置结果验证数据对运行结果进行验证,判断历史缺陷是否复现;生成监测报告;确定历史缺陷复现的原因,发送告警邮件至预设邮箱。解决了无法对逻辑缺陷和定制化登录场景下的历史缺陷进行监测的技术问题。
请参阅图4,本发明实施例中测试任务的监测方法的第四个实施例包括:
401、确定待监测系统,并获取与待监测系统对应的历史缺陷集合与待监测系统的参数信息,并根据历史缺陷集合和参数信息生成监测任务;
402、将监测任务发送至待监测系统,生成监测任务列表;
403、建立至少一个目标测试用例与至少一个历史缺陷的映射关系;
本实施例中,给每个目标测试用例按“1、2、3、……、m”的顺序编号,其中m为目标测试用例的个数;给每个(历史)缺陷按“1、2、3、……、n”的顺序编号,其中n为(历史)缺陷的个数。
建立至少一个目标测试用例与至少一个缺陷的映射关系,例如,每个缺陷都有其对应执行的测试用例,找出他们的映射关系,形成一个矩阵,其中的取值为1或0;当第i个测试用例发现了软件的第j个缺陷时,取值为1,否则为0;i=1、2、3、……、m,j=1、2、3、……、n。
404、确定每个目标测试用例检测所有历史缺陷时对应的每种影响因子的能力值;
本实施例中,目标测试用例是上一轮测试使用的测试用例,(历史)缺陷是上一轮测试使用的测试用例检测软件时发现的缺陷。
本实施例中,影响因子是预设的,将发现缺陷的严重性、优先级和出错原因等作为监测待监测系统缺陷能力的影响因子。针对各个影响因子,分别得出检测每个影响因子的能力值。通过检测出每个影响因子的能力值,进而决定对该测试用例检测软件缺陷的优先级。
根据所有测试用例的缺陷严重性值和中最大值的缺陷严重性值和,量化得到每个测试用例的严重性影响因子的能力值。在本步骤中,计算缺陷严重性值和的计算公式如下:
其中,Si表示第i个测试用例检测所有缺陷时的缺陷严重性值和,dsj表示第i个测试用例检测软件时发现的第j个缺陷的严重性的量化值,ki表示第i个测试用例检测软件时发现的缺陷个数。
同时,在该步骤中,每个测试用例的严重性影响因子的能力值的计算公式如下:
其中,ESi表示第i个测试用例的严重性影响因子的能力值,max(S)表示所有测试用例中最大值的缺陷严重性值和。
确定每个测试用例检测所有缺陷时对应的优先级影响因子的能力值:
确定每个测试用例检测所有缺陷时对应的缺陷优先级值和,其中,缺陷优先级值和的计算公式如下:
其中,Pi表示第i个测试用例检测所有缺陷时的缺陷优先级值和,dPj表示第i个测试用例检测软件时发现的第j个缺陷的优先级的量化值。
本实施例中,根据所有测试用例检测的缺陷优先级值和中最大值的缺陷优先级值和,量化得到每个测试用例的优先级影响因子的能力值。每个测试用例的优先级影响因子的能力值的计算公式如下:
其中,EPi表示第i个测试用例的优先级影响因子的能力值,max(P)表示所有测试用例中最大值的缺陷优先级值和。
405、通过每种影响因子对应的预设权重值和能力值,确定每个目标测试用例的优先级取值;
本实施例中,影响因子的预设权重值可以根据实际情况来调整,但是必须满足所有的影响因子的预设权重值之和等于1。权重值和能力值越大,优先级越靠前。进一步地,利用每种影响因子对应的预设权重值和能力值,确定每个测试用例的优先级取值。
406、将每个目标测试用例按照优先级取值进行优先级排序,得到排序结果;
本实施例中,将上一轮测试待监测系统时出现的历史缺陷对应使用的目标测试用例按照检测系统缺陷的能力大小进行优先级排序,并依次按照优先级高低的顺序选择目标测试用例重新检测待监测系统。至于优先级排序,此处此处不限定,可以使从大到小排列,也可以是从小到大排列。
407、基于排序结果,对监测任务中的目标测试用例进行测试,得到测试任务的运行结果;
本实施例中,根据目标测试用例的排序结果对待监测系统中检测任务列表中的多个目标测试用例进行测试,得到该监测任务的任务运行结果,其中,任务运行结果中包含有多个目标测试用例对应的测试结果,并记录日志信息生成监测报告。
需要说明得是,监测报告记录目标测试用例的测试结果可以是以图表的形式,也可以是以文本的形式,还可以是其他的形式,具体此处不做限制。
408、根据预置结果验证数据对测试任务的运行结果进行验证,并基于验证的结果判断历史缺陷集合中是否有历史缺陷复现,并生成监测报告;
409、若存在历史缺陷复现,则基于监测报告确定待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
本实施例中步骤401-402和408-409与第一实施例中的步骤101-102和104-105类似,此处不再赘述。
本发明实施例中,确定待监测系统,并根据获取的与待监测系统对应的历史缺陷集合和待监测系统的参数信息生成待监测任务;将待监测任务发送到对应待监测系统,生成监测任务列表中的所有监测任务;通过预设任务执行顺序执行监测任务,获取监测任务中所有测试任务的运行结果;根据预置结果验证数据对运行结果进行验证,判断历史缺陷是否复现;生成监测报告;确定历史缺陷复现的原因,发送告警邮件至预设邮箱。解决了无法对逻辑缺陷和定制化登录场景下的历史缺陷进行监测的技术问题。
请参阅图5,本发明实施例中测试任务的监测方法的第五个实施例包括:
501、确定待监测系统,并获取与待监测系统对应的历史缺陷集合与待监测系统的参数信息,并根据历史缺陷集合和参数信息生成监测任务;
502、将监测任务发送至待监测系统,生成监测任务列表;
503、基于预设任务执行顺序执行监测任务,获取待监测系统中的所有测试任务的运行结果;
504、获取所述测试任务运行结果;
本实施例中,测试用例中包含有用于测试过程中的测试信息,例如,输入信息、预期结果、实际结果、执行条件等。
由于服务器配置了测试用例与测试脚本之间的关联关系,所以,当终端执行测试用例后,就可以触发服务器执行自动化测试脚本的操作。通过结合测试用例和自动化测试脚本,能够实现在终端端的应用上和服务器上同步显示测试用例的测试结果。
505、将预置结果验证数据与目标测试用例对应的测试结果进行比对,分并判断目标测试用例对应的测试结果与结果验证数据是否一致;
本实施例中,缺陷是根据目标测试用例的实际(测试)结果与预期结果确定的。
通常情况下,在对某些功能性测试生成对应的测试用例时,都是基于不同的测试需求来生成的。以实现支付功能的接口为例,当账户名与输入的支付密码都正确时,才能实现支付成功,可能只有一种场景;但是当账户或者密码有一个错误的时候,支付便不会成功,这个包括多种场景,例如,账户名和密码均错误或者账户名或者密码有一个错的,均不能支付成功,对于支付成功或者失败均需要进行测试。然而,在实际的测试过程中,不同的测试用例的测试结果是不同的,有的测试结果符合预期结果,有的则不符合预期结果。不符合预期结果的,就是待监测系统在测试过程中存在的缺陷,也即本实施例中的历史缺陷。
506、若目标测试用例对应的测试结果与所述结果验证数据不一致,则存在历史缺陷复现。
本实施例中,可以根据目标测试用例的测试结果来确定系统是否出现了缺陷。判断目标测试用例的测试结果是否与预期效果一致,预期效果包括预期文本值以及预期字段值。测试结果为服务器执行目标测试用例后,测试页面上显示的结果或者后端中相关目标测试对象返回的测试结果,预期效果为根据需求预设的预期值。“测试结果达到了预期效果”意思就是“测试结果与预期结果一致”。比如,小明在9月份数学科目的月考中,有10个知识点没有掌握,试卷上与该10个知识点相关的题目回答错误。10月份,老师为了测试小明是否已经完全掌握了这些知识点,就以这10个知识点编了一套新的随堂测试卷对小明进行测试。测试结果是指小明参加随堂测试时,试卷上写下的答案;预期结果是指该随堂测试试卷的参考答案。若试卷上小明写下的答案与试卷的参考答案并不完全一致,则说明,小明本次考试并未获得满分,也即上次出错的知识点并未完全掌握,上次试卷中出现的相关知识点的错误复现;若试卷上小明写下的答案与试卷的参考答案完全一致,考试成绩为100分,10个知识点一个都没错,则代表小明掌握了上次答错的10个知识点,也即,历史缺陷未复现。
507、若存在历史缺陷复现,则基于监测报告确定待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
本实施例中步骤501-503、507与第一实施例中的101-103、105类似,此处不再赘述。
在本发明实施例中,确定待监测系统,并根据获取的与待监测系统对应的历史缺陷集合和待监测系统的参数信息生成待监测任务;将待监测任务发送到对应待监测系统,生成监测任务列表中的所有监测任务;通过预设任务执行顺序执行监测任务,获取监测任务中所有测试任务的运行结果;根据预置结果验证数据对运行结果进行验证,判断历史缺陷是否复现;生成监测报告;确定历史缺陷复现的原因,发送告警邮件至预设邮箱。解决了无法对逻辑缺陷和定制化登录场景下的历史缺陷进行监测的技术问题。
上面对本发明实施例中测试任务的监测方法进行了描述,下面对本发明实施例中测试任务的监测装置进行描述,请参阅图6,本发明实施例中测试任务的监测装置的第一个实施例包括:
生成模块601,用于确定待监测系统,获取与所述待监测系统对应的历史缺陷集合与所述待监测系统的参数信息,并根据所述历史缺陷集合和所述参数信息生成监测任务,其中,所述历史缺陷集和中包括至少一个历史缺陷,所述监测任务中包括至少一个测试任务;
发送模块602,用于将所述监测任务发送至所述待监测系统,生成监测任务列表,其中所述监测任务列表中包含至少一个监测任务,所述监测任务中包含至少一个测试任务;
第一获取模块603,用于基于预设任务执行顺序执行所述监测任务,获取所述监测任务中所有测试任务的运行结果;
判断模块604,用于根据预置结果验证数据对所述测试任务的运行结果进行验证,基于所述验证结果判断所述历史缺陷集合中是否有历史缺陷复现,并生成监测报告;
确定模块605,用于当存在历史缺陷复现时,基于所述监测报告确定所述待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
本发明实施例中,确定待监测系统,并根据获取的与待监测系统对应的历史缺陷集合和待监测系统的参数信息生成待监测任务;将待监测任务发送到对应待监测系统,生成监测任务列表中的所有监测任务;通过预设任务执行顺序执行监测任务,获取监测任务中所有测试任务的运行结果;根据预置结果验证数据对运行结果进行验证,判断历史缺陷是否复现;生成监测报告;确定历史缺陷复现的原因,发送告警邮件至预设邮箱。解决了无法对逻辑缺陷和定制化登录场景下的历史缺陷进行监测的技术问题。
请参阅图7,本发明实施例中测试任务的监测装置的第二个实施例,该测试任务的监测装置具体包括:
生成模块601,用于确定待监测系统,获取与所述待监测系统对应的历史缺陷集合与所述待监测系统的参数信息,并根据所述历史缺陷集合和所述参数信息生成监测任务,其中,所述历史缺陷集和中包括至少一个历史缺陷,所述监测任务中包括至少一个测试任务;
发送模块602,用于将所述监测任务发送至所述待监测系统,生成监测任务列表,其中所述监测任务列表中包含至少一个监测任务,所述监测任务中包含至少一个测试任务;
第一获取模块603,用于基于预设任务执行顺序执行所述监测任务,获取所述监测任务中所有测试任务的运行结果;
判断模块604,用于根据预置结果验证数据对所述测试任务的运行结果进行验证,基于所述验证结果判断所述历史缺陷集合中是否有历史缺陷复现,并生成监测报告;
确定模块605,用于当存在历史缺陷复现时,基于所述监测报告,确定所述待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
本实施例中,所述测试任务的监测装置还包括:
第二获取模块606,用于获取目标测试脚本,并将所述目标测试脚本发送至预置用例测试管理平台,其中,所述目标测试脚本是所述待监测系统对应的初始测试用例的测试脚本;
测试模块607,用于基于所述目标测试脚本进行测试,获取测试结果,其中,所述测试结果包括通过标识或未通过标识;
上传模块608,用于将携带未通过标识的所述测试结果上传至预置用例缺陷管理平台,得到与测试用例对应的缺陷,并根据所述缺陷得到所述待监测系统的历史缺陷集合。
本实施例中,所述生成模块601包括:
确定单元6011,用于确定待监测系统,并获取所述待监测系统的初始测试用例;
选取单元6012,用于获取所述历史缺陷集合中的所有历史缺陷,根据所述历史缺陷分别从预置测试用例模板集中选取与所述所有历史缺陷对应的预设测试用例模板,其中,所述测试用例模板集中包含至少一个测试用例模板;
生成单元6013,用于根据所述测试用例模板及所述初始测试用例,分别生成与所述所有历史缺陷对应的目标测试用例;根据所述所有目标测试用例,生成监测任务。
本实施例中,所述生成单元6013具体用于:
从所述初始测试用例中提取参数信息,其中,所述参数信息包括测试输入信息、执行参数信息以及预期结果;
根据所述预设测试用例模板以及所述参数信息,生成与所述历史缺陷对应的目标测试用例。
本实施例中,所述第一获取模块603具体用于:
建立至少一个目标测试用例与至少一个历史缺陷的映射关系,其中,所述历史缺陷是上一轮测试使用的测试用例检测系统时发现的缺陷;
确定每个所述目标测试用例检测所有所述历史缺陷时对应的每种影响因子的能力值;
通过每种所述影响因子对应的预设权重值和所述能力值,确定每个所述目标测试用例的优先级取值;
将每个所述目标测试用例按照所述优先级取值进行优先级排序,得到排序结果;
基于排序结果,对所述监测任务中的目标测试用例进行测试,得到所述测试任务的运行结果。
本实施例中,所述判断模块604具体用于:
获取所述测试任务运行结果,其中,所述测试任务运行结果中包括多个目标测试用例对应的测试结果;
将预置结果验证数据与所述目标测试用例对应的测试结果进行比对,判断所述目标测试用例对应的测试结果与所述结果验证数据是否一致;
若否,则将所述测试结果与所述待监测系统对应的历史缺陷进行匹配,得到匹配结果;
根据所述匹配结果,判断所述历史缺陷是否复现。
本发明实施例中,确定待监测系统,并根据获取的与待监测系统对应的历史缺陷集合和待监测系统的参数信息生成待监测任务;将待监测任务发送到对应待监测系统,生成监测任务列表中的所有监测任务;通过预设任务执行顺序执行监测任务,获取监测任务中所有测试任务的运行结果;根据预置结果验证数据对运行结果进行验证,判断历史缺陷是否复现;生成监测报告;确定历史缺陷复现的原因,发送告警邮件至预设邮箱。解决了无法对逻辑缺陷和定制化登录场景下的历史缺陷进行监测的技术问题。
上面图6和图7从模块化功能实体的角度对本发明实施例中的测试任务的监测装置进行详细描述,下面从硬件处理的角度对本发明实施例中测试任务的监测设备进行详细描述。
图8是本发明实施例提供的一种测试任务的监测设备的结构示意图,该测试任务的监测设备800可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上处理器(central processing units,CPU)810(例如,一个或一个以上处理器)和存储器820,一个或一个以上存储应用程序833或数据832的存储介质830(例如一个或一个以上海量存储设备)。其中,存储器820和存储介质830可以是短暂存储或持久存储。存储在存储介质830的程序可以包括一个或一个以上模块(图示没标出),每个模块可以包括对测试任务的监测设备800中的一系列指令操作。更进一步地,处理器810可以设置为与存储介质830通信,在测试任务的监测设备800上执行存储介质830中的一系列指令操作,以实现上述各方法实施例提供的测试任务的监测方法的步骤。
测试任务的监测设备800还可以包括一个或一个以上电源840,一个或一个以上有线或无线网络接口850,一个或一个以上输入输出接口860,和/或,一个或一个以上操作系统831,例如Windows Serve,Mac OS X,Unix,Linux,FreeBSD等等。本领域技术人员可以理解,图8示出的测试任务的监测设备结构并不构成对本申请提供的测试任务的监测设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
本发明还提供一种计算机可读存储介质,该计算机可读存储介质可以为非易失性计算机可读存储介质,该计算机可读存储介质也可以为易失性计算机可读存储介质,所述计算机可读存储介质中存储有指令,当所述指令在计算机上运行时,使得计算机执行上述测试任务的监测方法的步骤。
本发明所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain),本质上是一个去中心化的数据库,是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。
所述领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read-only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (10)
1.一种测试任务的监测方法,其特征在于,所述测试任务的监测方法包括:
确定待监测系统,获取与所述待监测系统对应的历史缺陷集合与所述待监测系统的参数信息,并根据所述历史缺陷集合和所述参数信息生成监测任务,其中,所述历史缺陷集和中包括至少一个历史缺陷,所述监测任务中包括至少一个测试任务;
将所述监测任务发送至所述待监测系统,生成监测任务列表,其中所述监测任务列表中包含至少一个监测任务,所述监测任务中包含至少一个测试任务;
基于预设任务执行顺序执行所述监测任务,获取所述监测任务中所有测试任务的运行结果;
根据预置结果验证数据对所述测试任务的运行结果进行验证,基于所述验证结果判断所述历史缺陷集合中是否有历史缺陷复现,并生成监测报告;
若存在历史缺陷复现,则基于所述监测报告确定所述待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
2.根据权利要求1所述的测试任务的监测方法,其特征在于,在确定待监测系统,获取与所述待监测系统对应的历史缺陷集合与所述待监测系统的参数信息,并根据所述历史缺陷集合和所述参数信息生成监测任务之前,还包括:
获取目标测试脚本,并将所述目标测试脚本发送至预置用例测试管理平台,其中,所述目标测试脚本是所述待监测系统对应的初始测试用例的测试脚本;
基于所述目标测试脚本进行测试,获取测试结果,其中,所述测试结果包括通过标识或未通过标识;
将携带未通过标识的所述测试结果上传至预置用例缺陷管理平台,得到与测试用例对应的缺陷,并根据所述缺陷得到所述待监测系统的历史缺陷集合。
3.根据权利要求1所述的测试任务的监测方法,其特征在于,所述确定待监测系统,获取与所述待监测系统对应的历史缺陷集合与所述待监测系统的参数信息,并根据所述历史缺陷集合和所述参数信息生成监测任务包括:
确定待监测系统,并获取所述待监测系统的初始测试用例;
获取所述历史缺陷集合中的所有历史缺陷,根据所述历史缺陷分别从预置测试用例模板集中选取与所述所有历史缺陷对应的预设测试用例模板,其中,所述测试用例模板集中包含至少一个测试用例模板;
根据所述测试用例模板及所述初始测试用例,分别生成与所述所有历史缺陷对应的所有目标测试用例;
根据所述所有目标测试用例,生成监测任务。
4.根据权利要求3所述的测试任务的监测方法,其特征在于,所述根据所述测试用例模板及所述初始测试用例,分别生成与所述所有历史缺陷对应的所有目标测试用例包括:
从所述初始测试用例中提取参数信息,其中,所述参数信息包括测试输入信息、执行参数信息以及预期结果;
根据所述预设测试用例模板以及所述参数信息,生成与所述历史缺陷对应的目标测试用例。
5.根据权利要求4所述的测试任务的监测方法,其特征在于,所述基于预设任务执行顺序执行所述监测任务,获取所述监测任务中所有测试任务的运行结果包括:
建立至少一个目标测试用例与至少一个历史缺陷的映射关系;
确定每个所述目标测试用例检测所有所述历史缺陷时对应的每种影响因子的能力值;
通过每种所述影响因子对应的预设权重值和所述能力值,确定每个所述目标测试用例的优先级取值;
将每个所述目标测试用例按照所述优先级取值进行优先级排序,得到排序结果;
基于排序结果,对所述监测任务中的目标测试用例进行测试,得到所述测试任务的运行结果。
6.根据权利要求4所述的测试任务的监测方法,其特征在于,所述根据预置结果验证数据对所述测试任务的运行结果进行验证,基于所述验证结果判断所述历史缺陷集合中是否有历史缺陷复现包括:
获取所述测试任务运行结果,其中,所述测试任务运行结果中包括多个目标测试用例对应的测试结果;
将预置结果验证数据与所述目标测试用例对应的测试结果进行比对,分别判断所述目标测试用例对应的测试结果与所述结果验证数据是否一致;
若所述目标测试用例对应的测试结果与所述结果验证数据不一致,则存在历史缺陷复现。
7.一种测试任务的监测装置,其特征在于,所述测试任务的监测装置包括:
生成模块,用于确定待监测系统,获取与所述待监测系统对应的历史缺陷集合与所述待监测系统的参数信息,并根据所述历史缺陷集合和所述参数信息生成监测任务,其中,所述历史缺陷集和中包括至少一个历史缺陷,所述监测任务中包括至少一个测试任务;
发送模块,用于将所述监测任务发送至所述待监测系统,生成监测任务列表,其中所述监测任务列表中包含至少一个监测任务,所述监测任务中包含至少一个测试任务;
第一获取模块,用于基于预设任务执行顺序执行所述监测任务,获取所述监测任务中所有测试任务的运行结果;
判断模块,用于根据预置结果验证数据对所述测试任务的运行结果进行验证,基于所述验证结果判断所述历史缺陷集合中是否有历史缺陷复现,并生成监测报告;
确定模块,用于当存在历史缺陷复现时,基于所述监测报告确定所述待监测系统对应历史缺陷复现的原因,并发送告警邮件至预设邮箱。
8.根据权利要求7所述的测试任务的监测装置,其特征在于,所述测试任务的监测装置,还包括:
第二获取模块,用于获取目标测试脚本,并将所述目标测试脚本发送至预置用例测试管理平台,其中,所述目标测试脚本是所述待监测系统对应的初始测试用例的测试脚本;
测试模块,用于基于所述目标测试脚本进行测试,获取测试结果,其中,所述测试结果包括通过标识或未通过标识;
上传模块,用于将携带未通过标识的所述测试结果上传至预置用例缺陷管理平台,得到与测试用例对应的缺陷,并根据所述缺陷得到所述待监测系统的历史缺陷集合。
9.一种测试任务的监测设备,其特征在于,所述测试任务的监测设备包括:存储器和至少一个处理器,所述存储器中存储有指令,所述存储器和所述至少一个处理器通过线路互连;
所述至少一个处理器调用所述存储器中的所述指令,以使得所述测试任务的监测设备执行如权利要求1-6中任一项所述的测试任务的监测方法。
10.一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1-6中任一项所述的测试任务的监测方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110482322.4A CN113051180B (zh) | 2021-04-30 | 2021-04-30 | 测试任务的监测方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110482322.4A CN113051180B (zh) | 2021-04-30 | 2021-04-30 | 测试任务的监测方法、装置、设备及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113051180A true CN113051180A (zh) | 2021-06-29 |
CN113051180B CN113051180B (zh) | 2023-09-29 |
Family
ID=76517976
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110482322.4A Active CN113051180B (zh) | 2021-04-30 | 2021-04-30 | 测试任务的监测方法、装置、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113051180B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113468053A (zh) * | 2021-07-02 | 2021-10-01 | 建信金融科技有限责任公司 | 一种应用系统的测试方法和装置 |
CN114418019A (zh) * | 2022-01-24 | 2022-04-29 | 平安科技(深圳)有限公司 | 缺陷任务的处理方法、装置、设备及存储介质 |
CN114721703A (zh) * | 2022-05-26 | 2022-07-08 | 青服(深圳)技术研究有限公司 | 一种基于大数据的软件维护方法及系统 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1648872A (zh) * | 2004-12-08 | 2005-08-03 | 上海科泰世纪科技有限公司 | 自动化测试构建方法 |
US20110321007A1 (en) * | 2010-06-29 | 2011-12-29 | International Business Machines Corporation | Targeting code sections for correcting computer program product defects using records of a defect tracking system |
US20150074648A1 (en) * | 2012-04-23 | 2015-03-12 | Dekel Tal | Software defect verification |
CN108241574A (zh) * | 2016-12-26 | 2018-07-03 | 航天信息股份有限公司 | 一种基于测试管理工具qc对软件测试缺陷进行分析的方法及系统 |
US20190089577A1 (en) * | 2017-09-15 | 2019-03-21 | Accenture Global Solutions Limited | Learning based incident or defect resolution, and test generation |
CN111562937A (zh) * | 2020-04-17 | 2020-08-21 | 北京简单一点科技有限公司 | 一种代码方法级缺陷预警方法 |
CN111611172A (zh) * | 2020-05-26 | 2020-09-01 | 深圳壹账通智能科技有限公司 | 项目测试缺陷分析方法、装置、设备及存储介质 |
-
2021
- 2021-04-30 CN CN202110482322.4A patent/CN113051180B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1648872A (zh) * | 2004-12-08 | 2005-08-03 | 上海科泰世纪科技有限公司 | 自动化测试构建方法 |
US20110321007A1 (en) * | 2010-06-29 | 2011-12-29 | International Business Machines Corporation | Targeting code sections for correcting computer program product defects using records of a defect tracking system |
US20150074648A1 (en) * | 2012-04-23 | 2015-03-12 | Dekel Tal | Software defect verification |
CN108241574A (zh) * | 2016-12-26 | 2018-07-03 | 航天信息股份有限公司 | 一种基于测试管理工具qc对软件测试缺陷进行分析的方法及系统 |
US20190089577A1 (en) * | 2017-09-15 | 2019-03-21 | Accenture Global Solutions Limited | Learning based incident or defect resolution, and test generation |
CN111562937A (zh) * | 2020-04-17 | 2020-08-21 | 北京简单一点科技有限公司 | 一种代码方法级缺陷预警方法 |
CN111611172A (zh) * | 2020-05-26 | 2020-09-01 | 深圳壹账通智能科技有限公司 | 项目测试缺陷分析方法、装置、设备及存储介质 |
Non-Patent Citations (1)
Title |
---|
史高翔;赵逢禹;: "基于缺陷相似度与再分配图的软件缺陷分配方法", 计算机科学, no. 11, pages 253 - 258 * |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113468053A (zh) * | 2021-07-02 | 2021-10-01 | 建信金融科技有限责任公司 | 一种应用系统的测试方法和装置 |
CN113468053B (zh) * | 2021-07-02 | 2022-11-15 | 中国建设银行股份有限公司 | 一种应用系统的测试方法和装置 |
CN114418019A (zh) * | 2022-01-24 | 2022-04-29 | 平安科技(深圳)有限公司 | 缺陷任务的处理方法、装置、设备及存储介质 |
CN114721703A (zh) * | 2022-05-26 | 2022-07-08 | 青服(深圳)技术研究有限公司 | 一种基于大数据的软件维护方法及系统 |
CN114721703B (zh) * | 2022-05-26 | 2024-02-23 | 青服(深圳)技术研究有限公司 | 一种基于大数据的软件维护方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN113051180B (zh) | 2023-09-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113051180A (zh) | 测试任务的监测方法、装置、设备及存储介质 | |
CN109726099B (zh) | 一种应用灰度发布方法、装置及设备 | |
US7451051B2 (en) | Method and system to develop a process improvement methodology | |
CN110088744B (zh) | 一种数据库维护方法及其系统 | |
CN112380255A (zh) | 一种业务处理方法、装置、设备和存储介质 | |
CN112540924A (zh) | 接口自动化测试方法、装置、设备及存储介质 | |
CN115952081A (zh) | 一种软件测试方法、装置、存储介质及设备 | |
CN103440460A (zh) | 一种应用系统变更验证方法及验证系统 | |
CN110990289A (zh) | 一种自动提交bug的方法、装置、电子设备及存储介质 | |
CN115114064A (zh) | 一种微服务故障分析方法、系统、设备及存储介质 | |
CN116340934A (zh) | 终端异常行为检测方法、装置、设备及存储介质 | |
CN117493188A (zh) | 接口测试方法及装置、电子设备及存储介质 | |
US11790249B1 (en) | Automatically evaluating application architecture through architecture-as-code | |
CN116662197A (zh) | 一种接口自动化测试方法、系统、计算机和可读存储介质 | |
CN111209180B (zh) | 一种基于模糊匹配的回归测试方法和装置 | |
CN116431522A (zh) | 一种低代码对象存储网关自动化测试方法及系统 | |
KR20120111618A (ko) | Plc 명령어 테스트 장치 및 방법 | |
CN115203025A (zh) | 一种测试缺陷分析方法及装置 | |
CN113656003A (zh) | 一种软件包管理方法及相关设备 | |
CN115204539A (zh) | 主机安全基线管理方法、装置、设备及介质 | |
CN115639972B (zh) | 数据迁移方法、装置、电子设备以及存储介质 | |
Kapel et al. | On the Difficulty of Identifying Incident-Inducing Changes | |
CN117271316A (zh) | 软件故障检测方法、装置、电子设备及存储介质 | |
CN118277234A (zh) | 代码提测校验方法、装置、设备及存储介质 | |
CN114416565A (zh) | 一种数据处理方法、装置、服务器及存储介质 |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |