一种CICD提测一体化测试方法及平台与流程

一种cicd提测一体化测试方法及平台
技术领域
1.本发明涉及自动化持续集成开发过程中的软件测试领域，尤其是涉及一种 cicd提测一体化测试方法及平台。


背景技术：

2.软件开发时，往往会采用持续集成(continuous integration，ci)和持续交付 (continuous delivery，cd)的开发方法。随着互联网技术的发展和普及，软件的更新迭代愈发频繁，软件测试也从传统的手动测试往自动化测试转移，通过自动化测试脚本，代替大量的、频繁的手动测试。
3.在cicd开发中，单一的自动化测试并不能满足软件快速迭代发版的要求，还需要在开发人员提交代码后就能执行自动化测试，从而尽快的发现问题。在现有的背景下，通常采用在jenkins等持续集成工具上每次构建服务后便触发自动化测试，或者手动执行、配置测试任务并每天定时执行。
4.然而，由于每次涉及到的服务未必只有一个，在每个服务构建后触发自动化，由于其他关联的服务没有构建更新，在最后一个服务构建之前，此前执行出来的自动化结果都不准确，导致出现多次重复、没有意义的执行和报告，反倒给开发、测试人员带出困扰。
5.而手动执行自动化脚本的方案，虽然可以避免上述无效执行的问题，但是需要人工触发，没有做到自动化流水线能力。
6.每天定时执行，虽然可以避免了上述两种方案的问题，但是没有做到及时测试，不能尽早的暴露问题。
7.因此，如何在开发代码更新后，能够及时、精准、高效的执行自动化测试，是当前需要解决的技术问题。


技术实现要素：

8.本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种cicd提测一体化测试方法及平台。
9.本发明的目的可以通过以下技术方案来实现：
10.一种cicd提测一体化测试方法，包括以下步骤：
11.s1、提测，新建提测单，选择所属项目、测试人员、服务和服务对应的开发人员，所述服务的数量为多个；
12.s2、实时通知各个服务对应的开发人员，开发人员确认自己的服务及分支，当所有服务都被确认后，通知测试人员；
13.s3、测试人员在持续集成工具上部署服务，得到每个服务的构建结果；
14.s4、若任一服务构建失败，则通知服务对应的开发人员处理，返回步骤s3重新部署服务，若所有服务均成功构建，则判断是否关联测试计划，若无，则执行步骤s5，若有，则执行测试计划所关联的自动化用例，得到执行结果，执行结果通知测试人员和开发人员，若测
试计划的执行结果为测试通过，则执行步骤s5，若未通过，则通知开发人员进行处理，处理结束后返回步骤s3重新部署服务；
15.s5、进入冒烟测试。
16.进一步的，每个服务对应一个开发人员。
17.进一步的，多个服务按照构建时的依赖约束顺序排列，步骤s3中，在持续集成工具上按照顺序依次构建服务。
18.进一步的，按照顺序逐个手动构建服务。
19.进一步的，从第一个服务开始，一个服务部署并构建成功后进行下一个服务的构建，若一个服务部署后在预设时间间隔内未获取到结果则服务构建失败，继续进行下一个服务的构建。
20.进一步的，步骤s3中，服务构建失败后可以再次部署，以最后一次部署的结果作为该服务的构建结果。
21.进一步的，每个服务的构建结果存储在日志中，若服务构建失败，则将失败原因存储在日志中。
22.一种cicd提测一体化测试平台，包括：
23.用户层，提供交互界面，所述交互界面包括提测管理、项目管理、用例管理和测试计划，所述提测管理用于新建提测单，所述项目管理用于配置项目默认执行的测试计划，所述用例管理用于管理脚本中的用例，所述测试计划关联项目和用例；
24.平台层，接收用户层的界面操作并转换为逻辑操作，对接持续集成工具和通信工具；
25.数据层，存放用例表、项目表、测试计划表、测试流程表、服务表和服务分支表。
26.进一步的，测试人员和开发人员均注册在平台层对接的通信工具中，新建提测单时通过所述通信工具的用户目录拉取测试人员和开发人员，测试过程中由所述通信工具实时通知开发人员和测试人员。
27.进一步的，持续集成阶段开发人员新增的服务部署在持续集成工具上，新建提测单时通过所述持续集成工具的服务和分支目录拉取服务。
28.与现有技术相比，本发明具有以下有益效果：
29.在开发代码更新后，能够及时、精准、高效的执行自动化测试，并及时通知相关人员查看结果和跟进，从而达到持续代码集成、发布、测试、修改，循环迭代，测试效率和测试质量大幅提高，实现保质保量的快速迭代发布。
附图说明
30.图1为cicd提测一体化测试方法的流程图；
31.图2为cicd提测一体化测试系统的架构图；
32.图3为实施例2中服务确认的页面示意图；
33.图4为实施例2中服务部署的页面示意图。
具体实施方式
34.下面结合附图和具体实施例对本发明进行详细说明。本实施例以本发明技术方案
为前提进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。
35.在附图中，结构相同的部件以相同数字标号表示，各处结构或功能相似的组件以相似数字标号表示。附图所示的每一组件的尺寸和厚度是任意示出的，本发明并没有限定每个组件的尺寸和厚度。为了使图示更清晰，附图中有些地方适当夸大了部件。
36.实施例1：
37.一种cicd提测一体化测试方法，如图1所示，包括以下步骤：
38.s1、提测，新建提测单，选择所属项目、测试人员、服务和服务对应的开发人员以及其他需要配置的信息，服务的数量为多个，每个服务对应一个开发人员。
39.测试人员和开发人员均注册在平台层对接的通信工具中，新建提测单时通过通信工具的用户目录拉取测试人员和开发人员，测试过程中由通信工具实时通知开发人员和测试人员。持续集成阶段开发人员新增的服务部署在持续集成工具上，新建提测单时通过持续集成工具的服务和分支目录拉取服务。
40.s2、实时通知各个服务对应的开发人员，开发人员确认自己的服务及分支，当所有服务都被确认后，通知测试人员；
41.s3、测试人员在持续集成工具上部署服务，得到每个服务的构建结果；
42.多个服务按照构建时的依赖约束顺序排列，步骤s3中，在持续集成工具上按照顺序依次构建服务，可以按照顺序逐个手动构建服务，也可以从第一个服务开始，一个服务部署并构建成功后进行下一个服务的构建，若一个服务部署后在预设时间间隔内未获取到结果则服务构建失败，继续进行下一个服务的构建。服务构建失败后可以再次部署，以最后一次部署的结果作为该服务的构建结果。
43.每个服务的构建结果存储在日志中，若服务构建失败，则将失败原因存储在日志中。
44.s4、若任一服务构建失败，则通知服务对应的开发人员处理，返回步骤s3重新部署服务，若所有服务均成功构建，则判断是否关联测试计划，若无，则执行步骤s5，若有，则执行测试计划所关联的自动化用例，得到执行结果，执行结果通知测试人员和开发人员，若测试计划的执行结果为测试通过，则执行步骤s5，若未通过，则通知开发人员进行处理，处理结束后返回步骤s3重新部署服务；
45.s5、进入冒烟测试。
46.通过本发明，在开发代码更新后，能够及时、精准、高效的执行自动化测试，并及时通知相关人员查看结果和跟进，从而达到持续代码集成、发布、测试、修改，循环迭代，测试效率和测试质量大幅提高，实现保质保量的快速迭代发布。
47.实施例2：
48.一种cicd提测一体化测试平台，如图2所示，包括三层结构，上层、中层和底层分别对应用户层、平台层和数据层；
49.用户层，提供交互界面，交互界面包括提测管理、项目管理、用例管理和测试计划，负责人在提测管理中新建提测单，项目管理中可以配置项目默认执行的测试计划，用例管理用于管理脚本中的用例，如新增或一键同步脚本中的用例，支持增删改查等操作，测试计划可以自定义关联哪些项目和用例；
50.平台层，接收用户层的界面操作并转换为逻辑操作，并进行对应的视图可视化操作，对接持续集成工具和通信工具，持续集成工具可以是jenkins，通信工具可以是飞书等即时聊天工具；
51.数据层，采用mysql实现，存放用例表、项目表、测试计划表、测试流程表、服务表和服务分支表等等。
52.具体提测流程如下：
53.开发负责人提测，在提测管理中，新建提测单，选择所属项目、测试人员、服务以及对应的开发人员，以及其他信息，确认提测。
54.其中，如图3所示，服务列表由测试平台后端对接jenkins，自动拉取，支持模糊搜索；一个服务对应一个开发人员，可以新增多个服务，多个服务从上到下顺序排列，若服务之间存在构建顺序约束，如必须先构建a再构建b，则可以拖动调整上下位置，确保依赖的服务优先构建，服务分支包括release、master、branch 等。
55.其中，测试人员以及开发人员可以定期或手动拉取飞书用户信息，同步到测试平台的数据层。
56.提测后，飞书通知对应的开发人员，开发人员可以直接点击链接跳转到测试平台中处理，开发人员各自确认自己的服务及分支，点击确认。分支同样从jenkins 上自动拉取，支持模糊搜索。待最后一个服务确认后，飞书通知测试人员；
57.如图4所示，所有服务确认后，测试人员可以一键部署所有的服务，也可以单一部署。单一部署时，直接点击服务的“部署”按钮，立即调用jenkins构建该服务；一键部署时，最上面的服务先调用jenkins构建，间隔时间循环获取jenkins 构建结果，超时没有获取到结果，则默认构建失败，待结果返回，停止循环，自动触发下一个服务的构建，以此类推，直到构建完所有的服务。每个服务的构建结果会实时推送到到测试平台的用户层界面展示，构建失败的服务可以手动再次部署，以最后一次部署的结果作为该服务的构建结果；
58.有任意服务构建失败时，则不触发自动化测试，飞书会自动通知相关人员处理，可在测试平台上直接查看日志确认原因，处理后重新部署。待所有的服务部署成功，判断是否关联测试计划，如有，则自动执行测试计划所关联的自动化用例；如无，则跳过，进入冒烟测试；
59.若在项目管理中配置了默认的测试计划，则所有服务成功构建后就会执行默认的自动化测试计划，执行该测试计划关联的自动化用例。
60.测试计划的执行结果，飞书会自动通知到相关人员，相关人员可以通过pc端或手机点击跳转到测试报告详情页面，随时随地查看和跟进测试结果。
61.测试通过，则进入冒烟测试，测试不通过，则待相关开发人员处理，处理后提交代码，通知测试人员重新部署服务，部署成功后再次执行自动化测试计划，依次循环，持续集成、部署，直到问题解决，测试通过，进入冒烟测试。
62.本司自研提测流程，选择所属业务线以及涉及的后端应用，通过即时通信聊天工具通知开发人员确认各自的服务和分支，测试人员调用jenkins构建和部署服务，自动执行所关联的测试计划，执行后查看测试报告，根据测试结果控制下一步流程，不通过则快速回滚，由开发人员处理，从而实现持续集成、持续部署、持续测试和发布。
63.以上详细描述了本发明的较佳具体实施例。应当理解，本领域的普通技术人员无
需创造性劳动就可以根据本发明的构思作出诸多修改和变化。因此，凡本技术领域中技术人员依本发明的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案，皆应在由权利要求书所确定的保护范围内。