一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

单元测试案例自动生成方法、装置、设备及存储介质与流程

2022-03-16 16:57:09 来源:中国专利 TAG:


1.本技术涉及计算机程序测试技术领域,特别是涉及一种单元测试案例自动生成方法、装置、设备及存储介质。


背景技术:

2.为快速响应市场变化,目前很多公司采用敏捷开发模式,实现快速迭代,为保证迭代质量,迭代过程中通过单元测试、接口测试和集成测试等提升交付质量,其中单元测试作为第一道关口必不可少,否则会导致问题延迟到应用编译发布完成后才发现,此时需要代码修复后重新编译发布,时间成本较高,bug暴露的越晚成本越高。目前市场上与很多成熟的单元测试框架,如junit、testng等,也有很多的mock框架如powermock、easymock等来实现单元测试时的环境隔离,使用该类框架需要测试人员或开发人员分析接口方法逻辑,并手工编写单元测试案例,为保证案例有效性,涉及到资源访问或其它业务逻辑层需要进行模拟mock,案例执行情况也需要人工发起后进行结果分析判断,人力和时间成本较高。为此,很多公司采用自动化的手段实现单元测试案例的编写和执行,以节约开发时间和开发成本,提升测试效率。一种方法是通过预设的单元测试标准,分析源代码结构,根据分析的出入参参数类型进行参数构造,从而生成单元测试案例。另一种方法是通过针对测试数据库进行模拟mock以得到mock api,生成包括所述mock api的嵌入式关系型数据库,当需要对被测单元进行单元测试时,采用所述嵌入式关系型数据库包括的所述mockapi对所述被测单元进行单元测试。
3.现有的单元测试案例录制和执行技术存在如下缺陷:
4.单元测试主要是针对系统最基本的单元代码进行测试,测试时主要从接口、独立路径、出错处理、边界条件和局部数据五个方面进行测试,通过这五个方面来验证代码是与设计相符合的,同时能够在编码阶段发现问题,减少泄露到测试阶段的缺陷,缩短测试阶段时间,提升交付效率。
5.现有的基于bdd的单元测试系统,是实现自动生成测试案例的工具,其功能主要有utpjunit组件、utp idea插件、utp单元测试平台,其中的utp idea插件用于生成utpjuint风格的单元测试用例模板,对于具体的代码逻辑完全需要人工填充,工作量比较大,自动化率比较低。


技术实现要素:

6.本技术提供一种单元测试案例自动生成方法、装置、设备及存储介质,以解决现有的程序测试方法自动化率较低、占用人力资源过多的问题。
7.为解决上述技术问题,本技术采用的一个技术方案是:提供一种单元测试案例自动生成方法,包括:获取待测试单元的测试请求,测试请求包括待测试单元的基本参数信息;基于基本参数信息解析待测试单元编译后的文件,得到文件解析后的参数信息;基于预设的测试案例模板,根据文件解析后的参数信息生成测试案例,并将测试案例按预先指定
的存储路径进行保存。
8.作为本技术的进一步改进,基于基本参数信息解析待测试单元编译后的文件,得到文件解析后的参数信息,包括:从测试请求中获取当前案例生成过程所需的类的存储路径息;按照类的存储路径,获取待测试单元编译后的文件,并从文件中解析得到每个方法的参数信息,得到参数信息。
9.作为本技术的进一步改进,当测试请求中还包括数据库挡板信息时,根据文件解析后的参数信息生成测试案例,包括:解析数据库挡板信息得到环境调试信息;根据参数信息生成测试案例,并将环境调试信息导入至测试案例的测试环境的数据库中。
10.作为本技术的进一步改进,基于预设的测试案例模板,根据文件解析后的参数信息生成测试案例,并将测试案例按预先指定的存储路径进行保存,包括:根据文件解析后的参数信息从预设的测试案例模板中选取匹配的目标测试案例模板;将参数信息赋值给目标测试案例模板,以生成对应的测试案例;将测试案例中的测试方法声明和执行写入自动生成的java文件保存,且将测试案例中的模拟数据和断言信息写入自动生成的xml文件保存。
11.作为本技术的进一步改进,测试请求包括为待测试单元设定的mock参数信息;根据文件解析后的参数信息生成测试案例之前,还包括:当文件解析后的参数信息中存在预先指定的需要进行mock的信息时,根据mock参数信息对需要进行mock的信息进行mock操作并返回相应的值。
12.作为本技术的进一步改进,根据文件解析后的参数信息生成测试案例之前,还包括:自动生成案例基类,案例基类存储待测试单元的初始化配置。
13.作为本技术的进一步改进,单元测试案例自动生成方法基于sirius插件实现。
14.为解决上述技术问题,本技术采用的另一个技术方案是:提供一种单元测试案例自动生成装置,包括:获取模块,用于获取待测试单元的测试请求,测试请求包括待测试单元的基本参数信息;解析模块,用于基于基本参数信息解析待测试单元编译后的文件,得到文件解析后的参数信息;生成模块,用于基于预设的测试案例模板,根据文件解析后的参数信息生成测试案例,并将测试案例按预先指定的存储路径进行保存。
15.为解决上述技术问题,本技术采用的再一个技术方案是:提供一种计算机设备,所述计算机设备包括处理器、与所述处理器耦接的存储器,所述存储器中存储有程序指令,所述程序指令被所述处理器执行时,使得所述处理器执行如权利要求1-7中任一项所述的单元测试案例自动生成方法的步骤。
16.为解决上述技术问题,本技术采用的再一个技术方案是:提供一种存储介质,存储有能够实现上述单元测试案例自动生成方法的程序指令。
17.本技术的有益效果是:本技术的单元测试案例自动生成方法通过获取待测试单元的测试请求后,基于基本参数信息解析待测试单元编译后的文件,得到文件解析后的参数信息,再根据文件解析后的参数信息生成测试案例,其根据测试请求,自动查询到待测试单元编译后的文件,再进行解析以获取案例生成所需的参数信息,再根据参数信息自动生成该待测试单元的测试案例,整个测试案例的生成过程都是自动化实现的,弥补了现有单元测试案例需要人工编写的不足,降低了对人力资源的占用。
附图说明
18.图1是本发明第一实施例的单元测试案例自动生成方法的流程示意图;
19.图2是本发明第二实施例的单元测试案例自动生成方法的流程示意图;
20.图3是本发明第三实施例的单元测试案例自动生成方法的流程示意图;
21.图4是本发明实施例的单元测试案例自动生成装置的功能模块示意图;
22.图5是本发明实施例的计算机设备的结构示意图;
23.图6是本发明实施例的存储介质的结构示意图。
具体实施方式
24.下面将结合本技术实施例中的附图,对本技术实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本技术的一部分实施例,而不是全部的实施例。基于本技术中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本技术保护的范围。
25.本技术中的术语“第一”、“第二”、“第三”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”、“第三”的特征可以明示或者隐含地包括至少一个该特征。本技术的描述中,“多个”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。本技术实施例中所有方向性指示(诸如上、下、左、右、前、后
……
)仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等,如果该特定姿态发生改变时,则该方向性指示也相应地随之改变。此外,术语“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
26.在本文中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例,也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本文所描述的实施例可以与其它实施例相结合。
27.图1是本发明第一实施例的单元测试案例自动生成方法的流程示意图。需注意的是,若有实质上相同的结果,本发明的方法并不以图1所示的流程顺序为限。如图1所示,该方法包括步骤:
28.步骤s101:获取待测试单元的测试请求,测试请求包括待测试单元的基本参数信息。
29.需要说明的是,待测试单元可以为一个待测试项目中的一个单元,通常地,一个待生成项目可能包含多个业务,一个业务包括多个测试对象。比如,一个待生成项目可能包含登录业务、注册业务、上传业务等等。若想要对待生成项目中的某个业务进行测试,即存在待生成项目的测试请求时,获取与该待生成项目的测试请求相关的待测试单元,并对该待测试单元发起测试请求,即可自动生成该待测试请求的相应的测试案例。需要理解的是,本实施例中,可同时实现对多个待测试单元进行批量的测试案例生成。
30.进一步的,本实施例中,所述单元测试案例自动生成方法基于sirius插件实现。
31.具体地,该sirius插件为测试案例的生成过程提供了可视化的信息配置界面,通过该信息配置界面,用户可以很方便的输入测试请求以生成测试案例。可以理解的是,本实施例中,通过采用sirius插件来实现测试案例的自动生成,其不需要借助第三方工具,从而降低了源码被泄露的可能性,并且,该sirius插件提供的图形化操作界面,大大优化了用户的操作体验,使用方便且效率更高。
32.步骤s102:基于基本参数信息解析待测试单元编译后的文件,得到文件解析后的参数信息。
33.具体地,在获取到测试请求后,根据该测试请求获取到待测试单元的基本参数信息和生成案例的案例参数信息,该基本参数信息中包含了待测试单元的存储路径,通过该存储路径,即可找到该待测试单元编译后生成的文件,通过解析该文件,从而获取生成测试案例所需要的参数信息。
34.进一步的,在一些实施例中,步骤s102具体包括:
35.1、从测试请求中获取当前案例生成过程所需的类的存储路径。
36.进一步的,还需从该测试请求中获取当前案例生成过程所需的cpu核心数、所需占用的内存、需要生成测试案例的类、类个数、生成的测试案例的存放路径、是否生成数据库挡板信息、测试案例的模式信息和默认参数信息等信息。
37.具体地,测试请求中的参数可通过预先输入的脚本命令来获取,例如,以如下脚本命令为例进行说明:mvn-dmemoryinmb=2048-dcores=2-dcuts=xxx.xxx.xxx.xxx-dtargetfolder=src/test/java-dspringdbmock=false-dtestmode=powermockrunner sirius:clean sirius:generate sirius:export,其中,dmemoryinmb=2048是指所需占用的内容为2048mb,dcores=2是指所需的cpu核心数为2个,dcuts=xxx.xxx.xxx.xxx是指需要生成测试案例的类、类个数以及类的存储路径,当存在多个类时,类之间可通过英文逗号分隔开,dtargetfolder=src/test/java是指生成的测试案例的存放路径,dspringdbmock是指是否需要生成数据库挡板信息,当dspringdbmock=false时,即为不需要生成数据库挡板信息,当dspringdbmock=ture时,即为需要生成数据库挡板信息,dtestmode=powermockrunner是指测试案例的模式,sirius:generate sirius:export是指sirius插件的默认参数。
38.2、按照类的存储路径,获取待测试单元编译后的文件,并从文件中解析得到每个方法的参数信息,得到参数信息。
39.具体地,根据获取到的类的存储路径,从而获取到待测试单元编译后生成的文件,对该文件中的内容进行识别从而得到import内容、类声明、方法声明、注解、接口注入等相关信息,将这些信息分别提取到相应的集合中,再解析该文件中的每个方法即方法参数、参数类型、方法中使用到的接口、静态类、方法调用等相关信息,将其作为解析得到的参数信息。
40.步骤s103:基于预设的测试案例模板,根据文件解析后的参数信息生成测试案例,并将测试案例按预先指定的存储路径进行保存。
41.需要说明的是,测试人员根据日常测试需求,预先开发了针对各种测试案例模板,通过该测试案例模板可以生成对应的测试案例程序。具体地,当通过解析编译后的文件得到参数信息,根据该参数信息赋值给对应的测试案例模板,即可自动生成该待测试单元的
测试案例,再将该测试案子按照案例参数信息中指定的案例存放路径进行保存,从而完成该待测试单元的测试案例自动化生成。
42.进一步的,在一些实施例中,在使用bbd的单元测试系统时,基于bdd的测试案例,不是完全测试我们的最小代码单元,测试的是类似场景,虽然也使用了jmockit生成挡板,但未做到静态方法,私有方法的mock,因此,当测试请求中还包括数据库挡板信息时,步骤s103具体包括:
43.1、解析数据库挡板信息得到环境调试信息;
44.需要说明的是,挡板测试可以理解为:在一些跨系统的性能测试项目中,往往由于客观因素的限制(测试硬件资源有限、多系统之间的协调等),无法搭建一个完整的测试环境来完成测试工作,此时,一般会搭建出被测系统,然后采用软件程序来模拟其他相关系统的功能,该软件程序一般被称为挡板。此外,该挡板还可以被称为“线下系统”、“沙盒系统”等。
45.2、根据参数信息生成测试案例,并将环境调试信息导入至测试案例的测试环境的数据库中。
46.具体地,在得到数据库挡板信息后,根据该数据库挡板信息生成对应的测试挡板,即将从数据库挡板信息中获取的环境调试信息写入至该测试案例的测试环境的数据库中,当执行该测试案例时,根据该环境调试信息生成该测试案例的测试环境。
47.本实施例中,该测试请求中数据库挡板信息的待测试单元通常是静态类或私有方法,从而为静态类和私有方法实现挡板功能,而且,其还可根据用户的需求,通过多种方式进行配置化的挡板,且通过sirius插件来实现,其提供的图形化界面使得mock配置过程更为方便灵活。
48.进一步的,在一些实施例中,为了方便用户对测试案例进行管理,步骤s103具体包括:
49.1、根据文件解析后的参数信息息从预设的测试案例模板中选取匹配的目标测试案例模板;
50.2、将参数信息赋值给目标测试案例模板,以生成对应的测试案例;
51.3、将测试案例中的测试方法声明和执行写入自动生成的java文件保存,且将测试案例中的模拟数据和断言信息写入自动生成的xml文件保存。
52.具体地,测试案例模板为测试人员预先设定,其中包括有针对于各种不同测试需求的案例模板,因此,为了实现自动化的生成测试案例,将解析得到的参数信息分别与测试案例模板进行匹配,选取最优的测试案例模板作为目标测试案例模板来生成测试案例。
53.本实施例中,在根据参数信息生成测试案例后,为了方便对测试案例进行管理,将测试案例中的数据分为两个部分进行保存,其中一个部分为测试案例中的测试方法声明和执行数据,将其写入自动生成的java文件中进行保存,而另一部分的测试案例中的模拟数据和断言信息则写入自动生成的xml文件中进行保存,从而使得用户对测试案例进行管理。
54.本发明第一实施例的单元测试案例自动生成方法通过获取待测试单元的测试请求后,基于基本参数信息解析待测试单元编译后的文件,得到文件解析后的参数信息,再根据文件解析后的参数信息生成测试案例,其根据测试请求,自动查询到待测试单元编译后的文件,再进行解析以获取案例生成所需的参数信息,再根据参数信息自动生成该待测试
单元的测试案例,整个测试案例的生成过程都是自动化实现的,弥补了现有单元测试案例需要人工编写的不足,降低了对人力资源的占用。
55.图2是本发明第二实施例的单元测试案例自动生成方法的流程示意图。需注意的是,若有实质上相同的结果,本发明的方法并不以图2所示的流程顺序为限。如图2所示,该方法包括步骤:
56.步骤s201:获取待测试单元的测试请求,测试请求包括待测试单元的基本参数信息。
57.在本实施例中,图2中的步骤s201和图1中的步骤s101类似,为简约起见,在此不再赘述。
58.步骤s202:基于基本参数信息解析待测试单元编译后的文件,得到文件解析后的参数信息。
59.在本实施例中,图2中的步骤s202和图1中的步骤s102类似,为简约起见,在此不再赘述。
60.步骤s203:当文件解析后的参数信息中存在预先指定的需要进行mock的信息时,根据mock参数信息对需要进行mock的信息进行mock操作并返回相应的值。
61.需要说明的是,本实施例中,测试请求包括为待测试单元设定的mock参数信息。
62.具体地,当根据文件解析后的参数信息中存在需要进行mock操作的信息时,还需要根据所述案例参数中的mock参数信息对所述需要进行mock的信息进行mock操作并返回相应的值,以供生成测试案例时使用。
63.需要说明的是,mock是指在测试过程中,对于某些不容易构造或者不容易获取的对象,用一个虚拟的对象来创建以便测试的测试方法。例如,一个闹钟根据时间来进行提醒服务,如果过了下午5点钟就播放音频文件提醒大家下班了,如果要利用真实的对象来测试的话就只能等到下午五点才可实现测试,为了避免这种情况,可以利用mock对象来进行测试,从而模拟控制时间了,而不用等待时钟转到下午5点钟了。
64.步骤s204:基于预设的测试案例模板,根据文件解析后的参数信息生成测试案例,并将测试案例按预先指定的存储路径进行保存。
65.在本实施例中,图2中的步骤s204和图1中的步骤s103类似,为简约起见,在此不再赘述。
66.本发明第二实施例的单元测试案例自动生成方法在第一实施例的基础上,通过确定解析后的参数信息中存在需要进行mock的信息时,根据该mock参数信息进行mock操作后返回相应的值,将该返回的值用于生成测试案例,从而使得生成的测试案例能够进行更为灵活的配置。
67.图3是本发明第三实施例的单元测试案例自动生成方法的流程示意图。需注意的是,若有实质上相同的结果,本发明的方法并不以图3所示的流程顺序为限。如图3所示,该方法包括步骤:
68.步骤s301:获取待测试单元的测试请求,测试请求包括待测试单元的基本参数信息。
69.在本实施例中,图3中的步骤s301和图1中的步骤s101类似,为简约起见,在此不再赘述。
70.步骤s302:基于基本参数信息解析待测试单元编译后的文件,得到文件解析后的参数信息。
71.在本实施例中,图3中的步骤s302和图1中的步骤s102类似,为简约起见,在此不再赘述。
72.步骤s303:自动生成案例基类,案例基类存储待测试单元的初始化配置。
73.具体地,在生成测试案例时,还需要生成一个基类来存储待测试单元的初始化配置,在执行测试时,根据该初始化配置信息完成对待测试单元的初始化配置。本实施例中,该案例基类为basejunit的基类。
74.步骤s304:基于预设的测试案例模板,根据文件解析后的参数信息生成测试案例,并将测试案例按预先指定的存储路径进行保存。
75.在本实施例中,图3中的步骤s304和图1中的步骤s103类似,为简约起见,在此不再赘述。
76.本发明第三实施例的单元测试案例自动生成方法在第一实施例的基础上,通过在生成测试案例时,自动化地生成该测试案例的案例基类,以存储该自动生成的测试案例的初始化配置,在后续需要使用该测试案例时,根据该初始化配置自动配置测试案例中的相关参数,不需要人为配置。
77.图4是本发明实施例的单元测试案例自动生成装置的功能模块示意图。如图4所示,该装置40包括获取模块41、解析模块42和生成模块43。
78.获取模块41,用于获取待测试单元的测试请求,测试请求包括待测试单元的基本参数信息;
79.解析模块42,用于基于基本参数信息解析待测试单元编译后的文件,得到文件解析后的参数信息;
80.生成模块43,用于基于预设的测试案例模板,根据文件解析后的参数信息生成测试案例,并将测试案例按预先指定的存储路径进行保存。
81.可选地,解析模块42执行基于基本参数信息解析待测试单元编译后的文件,得到文件解析后的参数信息的操作,具体包括:从测试请求中获取当前案例生成过程所需的类的存储路径;按照类的存储路径,获取待测试单元编译后的文件,并从文件中解析得到每个方法的参数信息,得到参数信息。
82.可选地,当测试请求中还包括数据库挡板信息时,生成模块43执行根据文件解析后的参数信息生成测试案例的操作,具体包括:解析数据库挡板信息得到环境调试信息;根据参数信息生成测试案例,并将环境调试信息导入至测试案例的测试环境的数据库中。
83.可选地,生成模块43执行基于预设的测试案例模板,根据文件解析后的参数信息生成测试案例,并将测试案例按预先指定的存储路径进行保存的操作,还可以包括:根据文件解析后的参数信息从预设的测试案例模板中选取匹配的目标测试案例模板;将参数信息赋值给目标测试案例模板,以生成对应的测试案例;将测试案例中的测试方法声明和执行写入自动生成的java文件保存,且将测试案例中的模拟数据和断言信息写入自动生成的xml文件保存。
84.可选地,测试请求包括为待测试单元设定的mock参数信息,生成模块43执行根据文件解析后的参数信息生成测试案例的操作之前,还用于:当文件解析后的参数信息中存
在预先指定的需要进行mock的信息时,根据mock参数信息对需要进行mock的信息进行mock操作并返回相应的值。
85.可选地,生成模块43执行根据文件解析后的参数信息生成测试案例的操作之前,还用于:自动生成案例基类,案例基类存储待测试单元的初始化配置。
86.可选地,单元测试案例自动生成方法基于sirius插件实现。
87.关于上述实施例单元测试案例自动生成装置中各模块实现技术方案的其他细节,可参见上述实施例中的单元测试案例自动生成方法中的描述,此处不再赘述。
88.需要说明的是,本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
89.请参阅图5,图5为本发明实施例的计算机设备的结构示意图。如图5所示,该计算机设备50包括处理器51及和处理器51耦接的存储器52,存储器52中存储有程序指令,程序指令被处理器51执行时,使得处理器51执行上述任一实施例所述的单元测试案例自动生成方法的步骤。
90.其中,处理器51还可以称为cpu(central processing unit,中央处理单元)。处理器51可能是一种集成电路芯片,具有信号的处理能力。处理器51还可以是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
91.参阅图6,图6为本发明实施例的存储介质的结构示意图。本发明实施例的存储介质存储有能够实现上述所有方法的程序指令61,其中,该程序指令61可以以软件产品的形式存储在上述存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本技术各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(rom,read-only memory)、随机存取存储器(ram,random access memory)、磁碟或者光盘等各种可以存储程序代码的介质,或者是计算机、服务器、手机、平板等计算机设备设备。
92.在本技术所提供的几个实施例中,应该理解到,所揭露的计算机设备,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
93.另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。以上仅为本技术的实施方式,并非因此限制本技术的专利范围,凡是利用本技术说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本技术的专利保护范围内。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献