1.本发明涉及数据安全领域,具体而言,涉及一种应用
测试方法、装置及电子设备。
背景技术:
2.应用安全测试是应用测试的重要组成部分,漏洞范围广,手工测试所消耗人力成本高,且由于手工测试问题登记跟踪等机制不健全等原因,会导致应用安全质量监控手段弱,无法评估在系统上线时是否符合质量要求。
3.针对上述的问题,目前尚未提出有效的解决方案。
技术实现要素:
4.本发明实施例提供了一种应用测试方法、装置及电子设备,以至少解决相关技术中应用上线前进行测试时,步骤繁多杂糅,出现的测试效率低的技术问题。
5.根据本发明实施例的一个方面,提供了一种应用测试方法,包括:获取预定应用的预定
代码的
静态需求规则,并基于
所述静态需求规则测试所述预定代码,得到静态需求测试结果,其中,所述静态需求规则包括所述预定应用中包括的预定操作和与所述预定操作对应的限定功能相匹配的规则;在所述静态需求测试结果为测试通过的情况下,获取所述预定代码的结构测试规则,并基于所述结构测试规则测试所述预定代码,得到结构测试结果,其中,所述结构测试规则包括数据格式规则;在所述结构测试结果为测试通过的情况下,获取预定漏洞库,并基于所述预定漏洞库漏洞匹配所述预定代码,得到漏洞测试结果;在所述漏洞测试结果为测试通过的情况下,获取冒烟测试脚本,并基于所述冒烟测试脚本冒烟测试所述预定代码,得到冒烟测试结果,其中,所述冒烟测试脚本依据与所述预定代码的冒烟测试用例预先生成;在所述冒烟测试结果为测试通过的情况下,获取黑盒测试脚本,并基于所述黑盒测试脚本测试所述预定代码,得到黑盒测试结果,其中,所述黑盒测试脚本依据预定设备与所述预定代码预先生成;依据所述黑盒测试结果,确定所述预定应用的目标测试结果。
6.可选地,所述依据所述黑盒测试结果,确定所述预定应用的目标测试结果之后,包括:在所述黑盒测试结果为测试通过的情况下,对所述预定应用进行预定方面的评估,得到评估分数;在所述评估分数高于预定阈值的情况下,得到所述预定应用可上线的上线结果。
7.可选地,所述获取预定漏洞库,包括:获取对所述预定应用进行测试的测试环境,所述测试环境的测试框架与测试构件版本信息;依据所述测试环境,所述测试框架与所述测试构建版本信息,确定所述预定漏洞库。
8.可选地,所述获取黑盒测试脚本,包括:确定所述预定设备的硬件接口协议;依据所述预定代码与所述硬件接口协议,生成所述黑盒测试脚本。
9.可选地,该方法包括:在所述静态需求测试结果,所述结构测试结果,所述漏洞测试结果,所述冒烟测试结果与所述黑盒测试结果中的任意一项测试结果为测试过程中出现测试故障的情况下,确定故障信息;依据所述故障信息,确定故障是否为可自修复故障的自
动修复结果;在所述自动修复结果为可自修复故障的情况下,自修复所述故障,并重新执行测试结果为测试过程中出现测试故障的测试。
10.可选地,该方法包括:在所述自动修复结果为不可自修复故障的情况下,发送所述故障信息至预定终端。
11.可选地,所述获取预定应用的预定代码的静态需求规则,并基于所述静态需求规则测试所述预定代码,得到静态需求测试结果之前,包括:搭建对所述预定应用进行测试的测试环境,并在所述测试环境中编译与所述预定应用的所述预定代码。
12.根据本发明实施例的一个方面,提供了一种应用测试装置,包括:第一测试模块,用于获取预定应用的预定代码的静态需求规则,并基于所述静态需求规则测试所述预定代码,得到静态需求测试结果,其中,所述静态需求规则包括所述预定应用中包括的预定操作和与所述预定操作对应的限定功能相匹配的规则;第二测试模块,用于在所述静态需求测试结果为测试通过的情况下,获取所述预定代码的结构测试规则,并基于所述结构测试规则测试所述预定代码,得到结构测试结果,其中,所述结构测试规则包括数据格式规则;第三测试模块,用于在所述结构测试结果为测试通过的情况下,获取预定漏洞库,并基于所述预定漏洞库漏洞匹配所述预定代码,得到漏洞测试结果;第四测试模块,用于在所述漏洞测试结果为测试通过的情况下,获取冒烟测试脚本,并基于所述冒烟测试脚本冒烟测试所述预定代码,得到冒烟测试结果,其中,所述冒烟测试脚本依据与所述预定代码的冒烟测试用例预先生成;第五测试模块,用于在所述冒烟测试结果为测试通过的情况下,获取黑盒测试脚本,并基于所述黑盒测试脚本测试所述预定代码,得到黑盒测试结果,其中,所述黑盒测试脚本依据预定设备与所述预定代码预先生成;第六测试模块,用于依据所述黑盒测试结果,确定所述预定应用的目标测试结果。
13.根据本发明实施例的一个方面,提供了一种电子设备,包括:处理器;用于存储所述处理器可执行指令的存储器;其中,所述处理器被配置为执行所述指令,以实现上述任一项所述的应用测试方法。
14.根据本发明实施例的一个方面,提供了一种计算机可读存储介质,当所述计算机可读存储介质中的指令由电子设备的处理器执行时,使得电子设备能够执行上述任一项所述的应用测试方法。
15.在本发明实施例中,获取预定应用的预定代码的静态需求规则,并基于静态需求规则测试预定代码,得到静态需求测试结果。在静态需求测试结果为测试通过的情况下,获取预定代码的结构测试规则,并基于结构测试规则测试预定代码,得到结构测试结果。在结构测试结果为测试通过的情况下,获取预定漏洞库,并基于预定漏洞库漏洞匹配预定代码,得到漏洞测试结果。在漏洞测试结果为测试通过的情况下,获取冒烟测试脚本,并基于冒烟测试脚本冒烟测试预定代码,得到冒烟测试结果。在冒烟测试结果为测试通过的情况下,获取黑盒测试脚本,并基于黑盒测试脚本测试预定代码,得到黑盒测试结果。依据黑盒测试结果,确定预定应用的目标测试结果,即能够全面自动化的进行应用各方面的测试,因为自动获取了规则、库或脚本进行测试,大大提升了测试应用的便捷性,而且自动化的进行顺序测试,提高了测试效率,进而解决了相关技术中应用上线前进行测试时,步骤繁多杂糅,出现的测试效率低的技术问题。
附图说明
16.此处所说明的附图用来提供对本发明的进一步理解,构成本技术的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
17.图1是根据本发明实施例的应用测试方法的流程图;
18.图2是根据本发明实施例的应用测试装置的结构框图。
具体实施方式
19.为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
20.需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
21.首先,在对本技术实施例进行描述的过程中出现的部分名词或术语适用于如下解释:
22.结构测试:又称白盒测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,即清楚盒子内部的东西以及里面是如何运作的。盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和修改条件判断覆盖。
23.黑盒测试:通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。
24.冒烟测试:将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后,冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行,且不会破坏整个版本的稳定性。
25.实施例1
26.根据本发明实施例,提供了一种应用测试方法的实施例,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
27.图1是根据本发明实施例的应用测试方法的流程图,如图1所示,该方法包括如下步骤:
28.步骤s102,获取预定应用的预定代码的静态需求规则,并基于静态需求规则测试预定代码,得到静态需求测试结果,其中,静态需求规则包括预定应用中包括的预定操作和与预定操作对应的限定功能相匹配的规则;
29.在本技术所记载的步骤s102中,需要获取预定应用的预定代码的静态需求规则,其中,该测试应用于需求制定、系统设计阶段,在该测试中,要确认是否涉及某类具体的安全类改造,依据预先设计的安全数据字典和在系统中归档的非功能需求说明书改造需求清单和系统总体设计的改造点清单进行文本匹配,确定出静态需求规则。确定出的静态需求规则即为预定应用中包括的预定操作和与预定操作对应的限定功能相匹配的规则,即如为场景+安全改造类型,具体地,例如登录+密码传输加密、图形验证码+随机生成、订单退款+防重放、留言板+防sql(structured query language,结构化查询语言)注入等。将文档静态检查纳入持续集成流水线,当检测到安全类改造内容时,基于静态需求规则测试预定代码,得到静态需求测试结果。
30.步骤s104,在静态需求测试结果为测试通过的情况下,获取预定代码的结构测试规则,并基于结构测试规则测试预定代码,得到结构测试结果,其中,结构测试规则包括数据格式规则;
31.在本技术所记载的步骤s104中,需要获取预定代码的结构测试规则,如数据格式规则,其中,该测试应用于开发阶段,在该测试中,要确认代码中是否出现符合ip格式/邮箱格式/手机格式的数据且未做脱敏处理的、出现符合简单转码格式的数据(可能是需要加密但仅做了转码的数据)、sql语句未对变量进行转义等,保证数据是符合目标格式的,且是否加密是否脱敏是符合要求的,保障了一定的安全性。
32.步骤s106,在结构测试结果为测试通过的情况下,获取预定漏洞库,并基于预定漏洞库漏洞匹配预定代码,得到漏洞测试结果;
33.在本技术所记载的步骤s106中,需要获取预定漏洞库,如已经记载可通过名单和不可通过名单的漏洞库,根据漏洞库的可通过名单和不可通过名单进行筛选,能够直接使得可通过名单通过,并筛除不可通过名单,因此,能够过滤到以记录的漏洞,保证代码的安全性。
34.步骤s108,在漏洞测试结果为测试通过的情况下,获取冒烟测试脚本,并基于冒烟测试脚本冒烟测试预定代码,得到冒烟测试结果,其中,冒烟测试脚本依据与预定代码的冒烟测试用例预先生成;
35.在本技术所记载的步骤s108中,以需求制定、系统设计阶段触发关联的安全测试案例、以及测试设计环节补充的安全测试案例为安全测试范围,获取对应的冒烟测试脚本,能够快速的进行基础功能的测试,提高测试的效率。
36.步骤s110,在冒烟测试结果为测试通过的情况下,获取黑盒测试脚本,并基于黑盒测试脚本测试预定代码,得到黑盒测试结果,其中,黑盒测试脚本依据预定设备与预定代码预先生成;
37.在本技术所记载的步骤s110中,通过黑盒测试,能够从用户的角度出发知晓用户可能会遇到的问题和功能,能够执行效率较高的测试。
38.步骤s112,依据黑盒测试结果,确定预定应用的目标测试结果。
39.在本技术所记载的步骤s112中,进行黑盒测试得到黑盒测试的结果后,由于进行完了整个自动化的测试进程,也可以相当于确定出了预定应用的目标测试结果,实现了对应用的一体化测试。
40.通过上述步骤,获取预定应用的预定代码的静态需求规则,并基于静态需求规则测试预定代码,得到静态需求测试结果。在静态需求测试结果为测试通过的情况下,获取预定代码的结构测试规则,并基于结构测试规则测试预定代码,得到结构测试结果。在结构测试结果为测试通过的情况下,获取预定漏洞库,并基于预定漏洞库漏洞匹配预定代码,得到漏洞测试结果。在漏洞测试结果为测试通过的情况下,获取冒烟测试脚本,并基于冒烟测试脚本冒烟测试预定代码,得到冒烟测试结果。在冒烟测试结果为测试通过的情况下,获取黑盒测试脚本,并基于黑盒测试脚本测试预定代码,得到黑盒测试结果。依据黑盒测试结果,确定预定应用的目标测试结果,即能够全面自动化的进行应用各方面的测试,因为自动获取了规则、库或脚本进行测试,大大提升了测试应用的便捷性,而且自动化的进行顺序测试,提高了测试效率,进而解决了相关技术中应用上线前进行测试时,步骤繁多杂糅,出现的测试效率低的技术问题。
41.作为一种可选的实施例,步骤s112,依据黑盒测试结果,确定预定应用的目标测试结果之后,包括:在黑盒测试结果为测试通过的情况下,对预定应用进行预定方面的评估,得到评估分数;在评估分数高于预定阈值的情况下,得到预定应用可上线的上线结果。
42.在该实施例中,预定方面可以为多种方面,例如,可以为测试方面的综合评分,也可以是对该应用进行数据量压力测试,以及试验员对该应用进行体验打分,也可以根据事先制定的质量门禁进行安全质量评估能否上线,比如应要求各阶段的问题修复率达到100%且案例执行率达到100%才能上线等等,在此不做限定,可以根据实际的应用与场景进行自定义的设置。在评估分数高于预定阈值的情况下,得到预定应用可上线的上线结果,即能够使得应用上线。
43.需要说明的是,对应同期上线的应用可在不同时间节点进行相应量化打分,用以横向和纵向比较应用a和应用b同期质量、应用a当期和应用a往期质量。对于质量不合格的应用可以进行下线或禁止上线处理。
44.作为一种可选的实施例,获取预定漏洞库,包括:获取对预定应用进行测试的测试环境,测试环境的测试框架与测试构件版本信息;依据测试环境,测试框架与测试构建版本信息,确定预定漏洞库。
45.在该实施例中,即依据部署时配置的环境、框架、构件版本信息确定预定漏洞库,确定出与测试环境,测试框架与测试构建版本信息对应的漏洞库,有利于更好的漏洞匹配。
46.作为一种可选的实施例,获取黑盒测试脚本,包括:确定预定设备的硬件接口协议;依据预定代码与硬件接口协议,生成黑盒测试脚本。
47.在该实施例中,即能够确定协议接口是否能够实现与接口对应的功能,即考虑在接口上,输入是否能正确的输入,输出能否能输出正确的结果。以实现基本功能的测试。
48.作为一种可选的实施例,在静态需求测试结果,结构测试结果,漏洞测试结果,冒烟测试结果与黑盒测试结果中的任意一项测试结果为测试过程中出现测试故障的情况下,确定故障信息;依据故障信息,确定故障是否为可自修复故障的自动修复结果;在自动修复
结果为可自修复故障的情况下,自修复故障,并重新执行测试结果为测试过程中出现测试故障的测试。
49.在该实施例中,在静态需求测试结果为测试过程中出现测试故障的情况下,则在自动提问题进行跟踪,确定故障是否为可自修复故障的自动修复结果,在自动修复结果为可自修复故障的情况下,自修复故障,并重新执行测试结果为测试过程中出现测试故障的测试,直到再测试没有发现故障后关闭问题。在结构测试结果为测试过程中出现测试故障的情况下,则自动提问题进行跟踪,确定故障是否为可自修复故障的自动修复结果,在自动修复结果为可自修复故障的情况下,自修复故障,并重新执行测试结果为测试过程中出现测试故障的测试,直到再测试不再命中后关闭问题。在漏洞测试结果为测试过程中出现测试故障的情况下,如命中不可通过名单或未命中可通过名单,则在自动提问题进行跟踪,确定故障是否为可自修复故障的自动修复结果,在自动修复结果为可自修复故障的情况下,自修复故障,并重新执行测试结果为测试过程中出现测试故障的测试,直到符合漏洞筛选条件后关闭问题。在冒烟测试结果为测试过程中出现测试故障的情况下,则自动提问题进行跟踪,确定故障是否为可自修复故障的自动修复结果,在自动修复结果为可自修复故障的情况下,自修复故障,并重新执行测试结果为测试过程中出现测试故障的测试,直到再测试不再命中后关闭问题。在黑盒测试结果为测试过程中出现测试故障的情况下,则自动提问题进行跟踪,确定故障是否为可自修复故障的自动修复结果,在自动修复结果为可自修复故障的情况下,自修复故障,并重新执行测试结果为测试过程中出现测试故障的测试,直到再测试不再命中后关闭问题。
50.作为一种可选的实施例,在自动修复结果为不可自修复故障的情况下,发送故障信息至预定终端。
51.在该实施例中,即在静态需求测试结果为测试过程中出现测试故障,且故障不可自动修复的情况下,需要安全质量保证人员进行手工干预,并及时更新检查静态需求规则。在结构测试结果为测试过程中出现测试故障,且故障不可自动修复的情况下,针对一些特例则需要安全质量保证人员进行手工干预,比如简单转码不一定都是该加密但未加密数据,并及时更新结构测试规则。在漏洞测试结果为测试过程中出现测试故障,且故障不可自动修复的情况下,针对一些特例则需要安全质量保证人员进行手工干预,如使用可通过名单有最新版本未进行登记导致未命中的,并及时更新获取预定漏洞库。在冒烟测试结果为测试过程中出现测试故障,且故障不可自动修复的情况下,针对一些特例则需要安全质量保证人员进行手工干预,,并及时更新冒烟测试脚本。在黑盒测试结果为测试过程中出现测试故障,且故障不可自动修复的情况下,针对一些特例则需要安全质量保证人员进行手工干预,并及时更新黑盒测试脚本。
52.作为一种可选的实施例,获取预定应用的预定代码的静态需求规则,并基于静态需求规则测试预定代码,得到静态需求测试结果之前,包括:搭建对预定应用进行测试的测试环境,并在测试环境中编译与预定应用的预定代码。
53.在该实施例中,搭建环境并编译代码的过程可以是自动搭建的,可以直接调取与预定代码的对应的部署包以实现环境的搭建和代码的编译,直接部署好能够执行上述操作的环境,有利于加快测试的一体化进程。
54.需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列
的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
55.通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例的方法。
56.实施例2
57.根据本发明实施例,还提供了一种用于实施上述应用测试方法的装置,图2是根据本发明实施例的应用测试装置的结构框图,如图2所示,该装置包括:第一测试模块202,第二测试模块204,第三测试模块206,第四测试模块208,第五测试模块210和第六测试模块212,下面对该装置进行详细说明。
58.第一测试模块202,用于获取预定应用的预定代码的静态需求规则,并基于静态需求规则测试预定代码,得到静态需求测试结果,其中,静态需求规则包括预定应用中包括的预定操作和与预定操作对应的限定功能相匹配的规则;第二测试模块204,连接于上述第一测试模块202,用于在静态需求测试结果为测试通过的情况下,获取预定代码的结构测试规则,并基于结构测试规则测试预定代码,得到结构测试结果,其中,结构测试规则包括数据格式规则;第三测试模块206,连接于上述第二测试模块204,用于在结构测试结果为测试通过的情况下,获取预定漏洞库,并基于预定漏洞库漏洞匹配预定代码,得到漏洞测试结果;第四测试模块208,连接于上述第三测试模块206,用于在漏洞测试结果为测试通过的情况下,获取冒烟测试脚本,并基于冒烟测试脚本冒烟测试预定代码,得到冒烟测试结果,其中,冒烟测试脚本依据与预定代码的冒烟测试用例预先生成;第五测试模块210,连接于上述第四测试模块208,用于在冒烟测试结果为测试通过的情况下,获取黑盒测试脚本,并基于黑盒测试脚本测试预定代码,得到黑盒测试结果,其中,黑盒测试脚本依据预定设备与预定代码预先生成;第六测试模块212,连接于上述第五测试模块210,用于依据黑盒测试结果,确定预定应用的目标测试结果。
59.此处需要说明的是,上述第一测试模块202,第二测试模块204,第三测试模块206,第四测试模块208,第五测试模块210和第六测试模块212对应于实施应用测试方法中的步骤s102至步骤s112,多个模块与对应的步骤所实现的实例和应用场景相同,但不限于上述实施例1所公开的内容。
60.实施例3
61.根据本发明实施例的另外一个方面,还提供了一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器,其中,处理器被配置为执行指令,以实现上述任一项的应用测试方法。
62.实施例4
63.根据本发明实施例的另外一个方面,还提供了一种计算机可读存储介质,当计算
机可读存储介质中的指令由电子设备的处理器执行时,使得电子设备能够执行上述任一项的应用测试方法。
64.上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
65.在本发明的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
66.在本技术所提供的几个实施例中,应该理解到,所揭露的技术内容,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,可以为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
67.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
68.另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
69.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:u盘、只读存储器(rom,read-only memory)、随机存取存储器(ram,random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
70.以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
技术特征:
1.一种应用测试方法,其特征在于,包括:获取预定应用的预定代码的静态需求规则,并基于所述静态需求规则测试所述预定代码,得到静态需求测试结果,其中,所述静态需求规则包括所述预定应用中包括的预定操作和与所述预定操作对应的限定功能相匹配的规则;在所述静态需求测试结果为测试通过的情况下,获取所述预定代码的结构测试规则,并基于所述结构测试规则测试所述预定代码,得到结构测试结果,其中,所述结构测试规则包括数据格式规则;在所述结构测试结果为测试通过的情况下,获取预定漏洞库,并基于所述预定漏洞库漏洞匹配所述预定代码,得到漏洞测试结果;在所述漏洞测试结果为测试通过的情况下,获取冒烟测试脚本,并基于所述冒烟测试脚本冒烟测试所述预定代码,得到冒烟测试结果,其中,所述冒烟测试脚本依据与所述预定代码的冒烟测试用例预先生成;在所述冒烟测试结果为测试通过的情况下,获取黑盒测试脚本,并基于所述黑盒测试脚本测试所述预定代码,得到黑盒测试结果,其中,所述黑盒测试脚本依据预定设备与所述预定代码预先生成;依据所述黑盒测试结果,确定所述预定应用的目标测试结果。2.根据权利要求1所述的方法,其特征在于,所述依据所述黑盒测试结果,确定所述预定应用的目标测试结果之后,包括:在所述黑盒测试结果为测试通过的情况下,对所述预定应用进行预定方面的评估,得到评估分数;在所述评估分数高于预定阈值的情况下,得到所述预定应用可上线的上线结果。3.根据权利要求1所述的方法,其特征在于,所述获取预定漏洞库,包括:获取对所述预定应用进行测试的测试环境,所述测试环境的测试框架与测试构件版本信息;依据所述测试环境,所述测试框架与所述测试构建版本信息,确定所述预定漏洞库。4.根据权利要求1所述的方法,其特征在于,所述获取黑盒测试脚本,包括:确定所述预定设备的硬件接口协议;依据所述预定代码与所述硬件接口协议,生成所述黑盒测试脚本。5.根据权利要求1所述的方法,其特征在于,包括:在所述静态需求测试结果,所述结构测试结果,所述漏洞测试结果,所述冒烟测试结果与所述黑盒测试结果中的任意一项测试结果为测试过程中出现测试故障的情况下,确定故障信息;依据所述故障信息,确定故障是否为可自修复故障的自动修复结果;在所述自动修复结果为可自修复故障的情况下,自修复所述故障,并重新执行测试结果为测试过程中出现测试故障的测试。6.根据权利要求5所述的方法,其特征在于,包括:在所述自动修复结果为不可自修复故障的情况下,发送所述故障信息至预定终端。7.根据权利要求1至6中任意一项所述的方法,其特征在于,所述获取预定应用的预定代码的静态需求规则,并基于所述静态需求规则测试所述预定代码,得到静态需求测试结
果之前,包括:搭建对所述预定应用进行测试的测试环境,并在所述测试环境中编译与所述预定应用的所述预定代码。8.一种应用测试装置,其特征在于,包括:第一测试模块,用于获取预定应用的预定代码的静态需求规则,并基于所述静态需求规则测试所述预定代码,得到静态需求测试结果,其中,所述静态需求规则包括所述预定应用中包括的预定操作和与所述预定操作对应的限定功能相匹配的规则;第二测试模块,用于在所述静态需求测试结果为测试通过的情况下,获取所述预定代码的结构测试规则,并基于所述结构测试规则测试所述预定代码,得到结构测试结果,其中,所述结构测试规则包括数据格式规则;第三测试模块,用于在所述结构测试结果为测试通过的情况下,获取预定漏洞库,并基于所述预定漏洞库漏洞匹配所述预定代码,得到漏洞测试结果;第四测试模块,用于在所述漏洞测试结果为测试通过的情况下,获取冒烟测试脚本,并基于所述冒烟测试脚本冒烟测试所述预定代码,得到冒烟测试结果,其中,所述冒烟测试脚本依据与所述预定代码的冒烟测试用例预先生成;第五测试模块,用于在所述冒烟测试结果为测试通过的情况下,获取黑盒测试脚本,并基于所述黑盒测试脚本测试所述预定代码,得到黑盒测试结果,其中,所述黑盒测试脚本依据预定设备与所述预定代码预先生成;第六测试模块,用于依据所述黑盒测试结果,确定所述预定应用的目标测试结果。9.一种电子设备,其特征在于,包括:处理器;用于存储所述处理器可执行指令的存储器;其中,所述处理器被配置为执行所述指令,以实现如权利要求1至7中任一项所述的应用测试方法。10.一种计算机可读存储介质,其特征在于,当所述计算机可读存储介质中的指令由电子设备的处理器执行时,使得电子设备能够执行如权利要求1至7中任一项所述的应用测试方法。
技术总结
本发明公开了一种应用测试方法、装置及电子设备,涉及数据安全领域。其中,该方法包括:基于静态需求规则测试预定代码,得到静态需求测试结果;静态需求测试结果为测试通过的情况下,基于结构测试规则测试预定代码,得到结构测试结果;结构测试结果为测试通过的情况下,基于预定漏洞库漏洞匹配预定代码,得到漏洞测试结果;漏洞测试结果为测试通过的情况下,基于冒烟测试脚本冒烟测试预定代码,得到冒烟测试结果;冒烟测试结果为测试通过的情况下,基于黑盒测试脚本测试预定代码,得到黑盒测试结果;依据黑盒测试结果,确定预定应用的目标测试结果。本发明解决了相关技术中应用上线前进行测试时,步骤繁多杂糅,出现的测试效率低的技术问题。技术问题。技术问题。
技术研发人员:
张卉 杨洋 翁丛
受保护的技术使用者:
中国工商银行股份有限公司
技术研发日:
2022.11.16
技术公布日:
2023/2/3