一种基于测试驱动开发的自动化动、静态测试方法与系统与流程

文档序号:32839912发布日期:2023-01-06 20:27阅读:86来源:国知局
一种基于测试驱动开发的自动化动、静态测试方法与系统与流程

1.本发明涉及软件开发技术领域,具体涉及一种基于测试驱动开发的自动化动、静态测试方法与系统。


背景技术:

2.随着敏捷开发的大规模落地应用,cicd(持续集成、持续交付)成为推动项目工作流的重要方法;它要求开发人员在代码提交后,及时对代码进行有效测试,以支持后续验收、部署、交付等流程的顺利进行。
3.但是在应用cicd流程的系统中,测试主要采取静态接口测试的方法,接口需要人员手动注册到测试工具系统中,没有考虑测试案例在真实应用中的关系,只提供单个接口基本功能的简单测试,无法对测试案例进行编排、组织。
4.现有的软件开发项目内部常分化为通用产品线和交付线并行研发的研发模式,通用产品线负责通用功能的开发,交付线负责针对客户定制化功能开发;两条产品线、多个代码分支的测试用例都由测试手动维护;进行测试代码调试时,需要手动进行接口返回和预期值的比对。
5.在未应用cicd的软件开发过程,传统的瀑布式开发过程中,测试系统以手工测试方法为主;测试在与开发、产品人员了解到产品需求后,到所需功能提测前,不再与产品、开发有系统交流,只有个人形式的交接;由于“部门墙”的存在,交接过程常常不够有效、准确。常见前后端分离的工程项目中,前端开发好页面后,使用mock数据进行页面渲染以查看效果,如果页面效果达不到产品功能要求,则前后端进行联调,直到满足提测要求为止。测试人员手动进行单元测试、回归测试、集成化测试、验收测试,将其中有问题的功能返工给开发修改,直到测试结果满足产品功能需求为止。
6.产品研发过程中,由于开发、测试的工作导向不同,开发着重关心技术实现,测试关心整体功能流程、测试分支,提测后常出现功能测试分支考虑不充分、功能模块之间存在交互缺陷等问题,从而导致产品功能大规模返工以进行问题修复。前后端分离项目实际开发过程中,后端考虑业务需求,对字段、数据类型进行的修改由于多种原因常常无法系统地、准确地和前端进行沟通,导致mock数据与真实数据存在较大差距,从而在前后端联调阶段耗费大量时间、精力,严重影响项目进度。
7.传统产品研发过程中,测试案例手动由测试人员手动维护,随着客户数增加、通用产品功能的完善,代码分支不断增加,测试用例数量迅速增多,测试案例管理、维护成本迅速增加,给项目顺利按期完成造成困难。
8.在应用cicd的系统中,通常采取静态测试的方式,只能对单个接口进行测试,或多个接口的简单并行测试,提供接口返回值、参数等的比对;每个接口测试案例单独进行,无法对接口测试案例进行组织、编排,不能对产品真实使用情况进行贴合的模拟,产品上线后使用中若出现问题,往往造成巨大损失。


技术实现要素:

9.本发明的目的在于提供一种基于测试驱动开发的自动化动、静态测试方法与系统,能降低测试人员的工作难度,减少测试总工作量和成本。
10.为解决上述技术问题,本发明提供一种基于测试驱动开发的自动化动、静态测试方法,包括以下步骤:
11.建立测试系统的测试计划;
12.创建微服务,将微服务的接口注册到测试系统中;
13.根据测试计划和微服务,从测试系统中拉取相应的接口到接口案例集;
14.对接口案例集中的接口进行自测;
15.若自测合格,则根据微服务的功能对接口案例集进行功能验证测试;
16.若功能验证测试合格,则对测试系统进行集成测试。
17.优选地,根据测试计划和微服务,从测试系统中拉取相应的接口到接口案例集,具体包括以下步骤:
18.根据测试计划和微服务的功能,从测试系统中拉取相应的接口到接口案例集,并对接口案例集中的接口进行排序。
19.优选地,还包括以下步骤:
20.若接口自测不合格,则处理接口自测不合格的接口。
21.优选地,前后端开发进入联调,根据微服务的功能对接口案例集进行功能验证测试;
22.若功能验证测试不通过,则重新对接口案例集中的接口进行自测。
23.优选地,对测试系统进行集成测试,具体包括以下步骤:
24.对测试系统中的所有的接口案例集进行全项目功能的集成测试;
25.若集成测试合格,则测试结束;
26.若集成测试不合格,则重新对接口案例集进行功能验证测试。
27.优选地,创建微服务,将微服务的接口注册到测试系统中,具体包括以下步骤:
28.创建微服务,在微服务上线时,调用测试系统的api接口;
29.根据测试系统的api接口,将微服务的接口注册到测试系统中。
30.优选地,所述测试计划包括计划名称、所属项目、创建人、负责人、测试进度、开始时间和结束时间。
31.本发明还提供一种基于测试驱动开发的自动化动、静态测试系统,包括:
32.测试计划模块,用于建立测试系统的测试计划;
33.微服务创建模块,用于创建微服务;
34.注册模块,用于将微服务的接口注册到测试系统中;
35.拉取模块,用于根据测试计划和微服务,从测试系统中拉取相应的接口到接口案例集;
36.接口测试模块,用于对接口案例集中的接口进行自测;
37.功能接口案例集模块,用于根据微服务的功能对接口案例集进行功能验证测试;
38.集成测试模块,用于对测试系统进行集成测试。
39.与现有技术相比,本发明的有益效果为:
40.本发明提供一种以测试驱动开发为导向的软件开发自动化测试系统,提供测试在项目生命周期中的跟踪、管理、维护,提供接口静态、动态测试,提供测试案例的编排、组合,以提升项目测试和真实环境相似度,提升项目研发过程中涉及测试环节的效率,降低项目测试人员使用门槛,保证项目交付质量。
41.采用本发明自动测试系统方法,应用于传统软件产品研发过程,实现测试自动化;能够能够实现项目测试的全生命周期管理,降低软件开发项目中测试的工作量、难度和复杂度;降低因为手动测试、前后端联调造成的时间开销。应用于cicd流程中,能对接口测试案例进行组织、编排成案例集,支持多案例链批量测试,对按照用户故事划分的功能模块进行一键验证。能够自动同步后端代码对接口所做更改到接口测试模块,增加测试案例在多个适用环境下的复用。能够对测试案例按照功能进行编排,测试后自动生成测试报告,方便各方人员对测试结果查看、分析;降低测试人员的工作难度,减少测试总工作量和成本。
附图说明
42.下面结合附图对本发明的具体实施方式作进一步详细说明。
43.图1是本发明一种基于测试驱动开发的自动化动、静态测试方法的流程示意图;
44.图2是测试计划的工作流分配示意图。
具体实施方式
45.在下面的描述中阐述了很多具体细节以便于充分理解本发明。但是本发明能够以很多不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本发明内涵的情况下做类似推广,因此本发明不受下面公开的具体实施的限制。
46.在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
47.应当理解,尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一也可以被称为第二,类似地,第二也可以被称为第一。取决于语境,如在此所使用的词语“如果”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”。
48.下面结合附图1-2对本发明做进一步的详细描述:
49.如图1所示,本发明提供一种基于测试驱动开发的自动化动、静态测试方法,包括以下步骤:
50.建立测试系统的测试计划;
51.创建微服务,将微服务的接口注册到测试系统中;
52.根据测试计划和微服务,从测试系统中拉取相应的接口到接口案例集;
53.对接口案例集中的接口进行自测;
54.若自测合格,则根据微服务的功能对接口案例集进行功能验证测试;
55.若功能验证测试合格,则对测试系统进行集成测试。
56.优选地一个实施例,根据测试计划和微服务,从测试系统中拉取相应的接口到接口案例集,具体包括以下步骤:
57.根据测试计划和微服务的功能,从测试系统中拉取相应的接口到接口案例集,并对接口案例集中的接口进行排序。
58.优选地一个实施例,还包括以下步骤:
59.若接口自测不合格,则处理接口自测不合格的接口。
60.优选地一个实施例,前后端开发进入联调,根据微服务的功能对接口案例集进行功能验证测试;
61.若功能验证测试不通过,则重新对接口案例集中的接口进行自测。
62.优选地一个实施例,对测试系统进行集成测试,具体包括以下步骤:
63.对测试系统中的所有的接口案例集进行全项目功能的集成测试;
64.若集成测试合格,则测试结束;
65.若集成测试不合格,则重新对接口案例集进行功能验证测试。
66.优选地一个实施例,创建微服务,将微服务的接口注册到测试系统中,具体包括以下步骤:
67.创建微服务,在微服务上线时,调用测试系统的api接口;
68.根据测试系统的api接口,将微服务的接口注册到测试系统中。
69.优选地一个实施例,所述测试计划包括计划名称、所属项目、创建人、负责人、测试进度、开始时间和结束时间。
70.通过本发明一种基于测试驱动开发的自动化动、静态测试方法,实现下述功能:
71.一、系统注册的微服务线上启动后,自动调用测试平台api,将微服务的所有接口信息注册到系统;
72.二、接口案例测试支持批量执行,支持断言验证;测试过程中,支持特性数据测试案例的手动增删改;
73.三、对接口测试案例进行编排、组织成案例集,案例集通过引用其中的案例,并非直接生成新的内容;案例集可支持接口执行按照先后顺序、并行顺序等组成案例链,以实现更贴合产品真实使用环境的测试;依据用户故事进行功能验证,支持使用断言进行验证;批量执行多测试案例链,实现功能一键验证;
74.四、接口测试案例修改后,测试平台对此案例数据库中存储数据进行修改,由于接口案例集只是对测试案例的引用,所有使用此测试案例的接口案例集能实现自动同步,保持测试案例的时效性,避免多处测试案例不同步造成混乱;
75.五、对测试执行过程中的数据进行自动分析、比对,自动生成测试报告。
76.本发明还提供一种基于测试驱动开发的自动化动、静态测试系统,包括:
77.测试计划模块,用于建立测试系统的测试计划;
78.测试计划模块提供分产品线的测试用例管理。根据产品迭代或者项目实施周期建立测试计划,对应产品或项目的测试生命周期,属性包括计划名称,所属项目,创建人,负责人,测试进度,开始时间,结束时间等,以便绑定产品/项目测试用例集合。
79.微服务创建模块,用于创建微服务;
80.注册模块,用于将微服务的接口注册到测试系统中;
81.拉取模块,用于根据测试计划和微服务,从测试系统中拉取相应的接口到接口案例集;
82.接口测试模块,用于对接口案例集中的接口进行自测;
83.接口测试模块提供接口的静态测试。系统注册的微服务在环境启动后,自动调用自动测试系统的api,将微服务自身的所有接口信息注册到系统,实现接口信息的自动维护;同时支持接口信息的手动增删改查操作,接口组合调用,断言等,支持一键转换接口测试数据为接口测试案例。
84.功能接口案例集模块,用于根据微服务的功能对接口案例集进行功能验证测试;
85.功能接口案例集模块提供接口测试案例编排、组织成以用户故事为依据的功能接口案例集,通过模拟用户操作某功能,测试整条功能链上的接口测试用例。支持功能案例的维护,提供多条接口测试案例链作为功能案例集,支持案例链批量执行,实现功能的一体化集成测试。
86.集成测试模块,用于对测试系统进行集成测试,在集成测试合格后,测试结束。
87.还包括:
88.微服务管理模块,用于提供服务的基础信息管理,主要属性包括服务名称、描述等基本信息。
89.环境管理模块,用于提供测试的分环境管理,对应一个微服务下的不同环境,比如正式环境、测试环境、开发环境等,主要管理环境名称、描述、部署地址等。
90.接口测试案例管理模块用于提供接口测试案例的维护功能。支持根据微服务环境,版本迭代等不同维度筛选,支持断言验证、批量执行接口测试案例,提供开发人员提测前的自我验证功能。
91.执行记录模块,用于记录接口调用记录、详细信息,包括参数、返回值等。支持记录的分享功能,在测试环节出现问题,能一键分享给相关人员及时整改。
92.测试报告模块,用于提供测试报告的生成、分析功能,支持测试报告的下载功能。
93.本发明一种基于测试驱动开发的自动化动、静态测试系统从测试驱动开发思想出发,使用职责明确、松耦合的多个功能模块,提供高效、灵活、系统的测试管理。主要有测试计划、微服务管理、环境管理的三个基础信息模块;和接口测试、接口测试案例管理、功能接口案例集三个测试业务模块;执行记录、测试报告两个记录分析模块。静、动态测试的实现,依靠微服务启动前注册服务到系统,启动后调用系统api自动注册所有接口册系统;在接口测试模块添加测试案例,添加断言,以支持静态的接口测试;依据功能将接口测试案例编排、组织成有先后、并行等顺序的接口案例集,并支持案例集的批量执行,以支持动态测试一键验证功能。
94.为了更好的说明本发明的技术效果,本发明提供如下具体实例说明上述技术流程:
95.实例1,如图2所示:
96.1、在系统测试计划管理模块按照项目开发计划创建项目,创建测试计划,测试计划包含开始时间,结束时间;标记此测试项目生命周期开始;
97.2、在系统微服务管理模块创建微服务b、f,属性包括服务名称、描述、地址等;在微
服务上线时系统自动调用api,将微服务中的接口自动注册到系统中;
98.3、按照功能创建对应的接口案例集,如微服务f提供用户注册功能,此功能由三个接口注册、登录、获取当前用户的菜单组成;为此微服务f的功能创建接口案例集,将对应接口拉取进功能的接口案例集,并按照用户注册-登录-获取菜单的顺序编排测试案例的执行顺序;系统后台将按照用户制定的执行顺序进行上锁,保证案例链顺序执行;
99.4、开发人员开发中,可使用系统的接口测试模块对每个接口自测,如果涉及到接口字段、数据类型修改、断言验证修改,系统会自动同步相应修改到所有此接口适用环境,让所有使用此系统的人员看到的数据实时、一致;在修改相关服务代码后,服务重启时,将修改过的接口覆盖原有接口,支持保留两者,方便代码进行对比。
100.5、待接口测试成功,按照功能批量测试相关案例集,系统执行后自动生成测试报告,测试报告可供系统中各方人员查阅;若测试报告出现问题,对测试集中案例链接口按顺序进行测试,定位问题接口、代码,相关责任人进行整改;如果接口测试失败,返回前后端开发人员工作流,由测试报告定位问题,相关责任人进行处理;如果接口集接口测试都通过,进入步骤6进行功能验证测试;
101.6、前后端开发进入联调,双方可同时使用系统,生成的问题报告可一键分享给相关责任人,出现问题的功能支持手动调试;联调过程问题体现在报告中;如果功能验证测试不通过,返回步骤5进行接口测试定位问题接口;如果功能验证测试都通过,进入步骤7集成测试;
102.7、功能验证完成,则发起系统集成测试,进行全项目功能自动测试,测试后自动生成报告;如果测试出现问题,返回步骤6进行功能验证测试,定位问题功能;如果测试通过,产品通过测试,可进行项目中的验收、部署、上线;则此版本或迭代的测试生命周期结束。
103.实例2:
104.有应用cicd流程研发项目,在cicd中的自动测试使用此系统进行动/静态测试。在 cicd流程中已完成持续开发,在使用此自动测试方法后,进入cicd的持续部署、持续交付部分。其中使用此系统步骤如下。
105.1)、将微服务注册到系统;包括地址、名称、描述等基本信息;微服务系统地址注册后,自动调用系统api将所有接口初始化注册到系统中;
106.2)、在系统中配置测试用例,将同功能下的测试用例按照先后执行顺序、参数传递关系编排、组织成接口案例集;
107.3)、对接口进行单接口测试,或批量执行,验证接口问题无误;
108.4)、对接口进行案例集测试,或批量执行多案例集批量测试,验证案例集功能无误;若案例集功能测试有误,则返回接口测试步骤;
109.5)、根据测试报告对接口、功能进行整改;
110.6)、进行集成测试,覆盖所有功能;若集成测试有误,则返回案例集测试步骤;若测试无误,则测试完成。
111.在本发明所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述模块、模组或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元、模组或组件可以结合或者可以集成到另一个装置,或一些特征可以忽略,或不执行。
112.所述单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是一个物理单元或多个物理单元,即可以位于一个地方,或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
113.另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
114.特别地,根据本发明公开的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分从网络上被下载和安装,和/或从可拆卸介质被安装。在该计算机程序被中央处理单元(cpu)执行时,执行本发明的方法中限定的上述功能。需要说明的是,本发明上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线段、或半导体的系统、装置或器件,或者任意以上的组合。
115.附图中的流程图和框图,图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
116.以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何在本发明揭露的技术范围内的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以所述权利要求的保护范围为准。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1