一种基于保障测试的应用发布质量管理方法及系统与流程

1.本发明属于软件测试技术领域，具体涉及一种基于保障测试的应用发布质量管理方法。


背景技术：

2.对于一个软件开发项目而言，每一次的迭代或功能模块的新增都可能导致项目质量出现问题，因此回归测试是软件生命周期的一个重要组成部分，目前回归测试的主要技术手段包括手工测试、接口自动化测试、ui自动化测试以及上下游链路测试等，以保障应用项目的稳定性。然而ui自动化对产品界面稳定性有一定要求，界面布局一旦调整会导致ui自动化脚本失效，人力维护成本高，实际产出较低；人工的手工和接口自动化回归测试，不仅考验测试人员对于业务的了解能力，可能存在回归场景不够全面的现象，而且需要进行人工触发，人力成本较高。


技术实现要素：

3.技术问题：针对现有技术中存在的上述问题，本发明所要解决的技术问题在于一种基于保障测试的应用发布质量管理方法及系统减少回归测试量，提高测试效率、保障应用发布质量。
4.技术方案：为了解决上述技术问题，本发明采用的技术方案如下：
5.一种基于保障测试的应用发布质量管理方法，包括以下步骤：
6.s1、配置任务：将需要自动化卡点的应用名单在运维平台的配置中心进行配置，在jenkins平台建立和配置任务，在建立任务时，任务名与应用名一一映射；在配置任务时，在构建触发器中指定任务对应的testng xml文件，将任务与接口自动化脚本进行关联；在jenkins的配置页面内，为对应任务配置动态参数，将应用的分支、制品id、应用名和executor作为四个字符串参数绑定在任务中；
7.s2、构建任务：当在运维平台上进行应用预发部署时，会将当前部署的应用名、分支以及制品id作为入参，调用测试平台构建任务的接口；由于需要卡点的应用名与jenkins任务名已一一映射，因此根据应用名入参查找并构建对应的jenkins任务；由于每次部署应用都会触发任务构建，因此为了提高效率，每次构建新任务都会将之前的任务进行终止，以任务的最新一次构建结果为准；最后将任务此次构建的序号及链接返回给运维平台；
8.s3、获取任务结果：当准备应用项目上线前，会在运维平台上将所测的应用分支状态更改为预发验证通过；当点击预发验证按钮时，运维平台获取当前应用分支的任务序号，并将应用名和序号作为入参，触发测试平台获取任务结果的接口，将自动化结果作为能否进行应用项目发布的一个依据。
9.优选的，所述步骤s1具体包括以下步骤：
10.s1.1、确定需要进行自动化卡点的应用名单，借助于运维平台的配置中心页面，将名单作为键值对配置在testcenter应用的配置中心内；
11.s1.2、根据s1.1配置的自动化卡点应用名单，在接口自动化工程中配置针对不同应用的testng配置文件，在配置文件中指定当前应用需要进行的回归脚本集；
12.s1.3、根据s1.1配置的自动化卡点应用名单，在jenkins平台建立和配置任务，建立的任务名和应用名一一映射；
13.s1.4、配置jenkins任务的工程源码相关信息及构建操作，在构建触发器的shell脚本中指定任务对应的testng配置文件，将任务与接口自动化脚本进行关联；
14.s1.5、在jenkins服务器中编写python脚本，用于发送企业沟通协同平台的通知，将应用的分支、制品id、应用名以及构建人信息通过占位符进行表示，以便进行动态传参；
15.s1.6、配置jenkins任务的构建动态参数，将应用的分支、制品id、应用名和executor作为四个字符串参数绑定在任务中。
16.优选的，所述步骤s2中构建任务具体包括以下步骤：
17.s2.1、读取配置中心的卡点应用名单，判断入参的应用名是否在白名单内，若在则继续构建，若不在则无需构建任务；
18.s2.2、根据入参的应用名遍历查找jenkins对应任务，并获取该任务的具体信息；
19.s2.3、根据任务具体信息，获取任务的下一次构建序号a以及上一次成功构建序号b，并将序号a以及b之间的任务终止；
20.s2.4、将入参的分支、制品id传给jenkins，进行任务的参数化构建；
21.s2.5、jenkins构建任务，将获取到的当前应用部署分支以及制品id通过企业沟通协同平台发送通知，告知当前自动化回归任务对应的构建人、分支、制品id以及用例数相关信息；
22.s2.6、获取jenkins任务队列，若队列已执行则获取并返回给运维平台此次构建的任务序号及链接。
23.优选的，所述步骤s3中获取任务结果具体包括以下步骤：
24.s3.1、读取配置中心的卡点应用名单，判断入参的应用名是否在白名单内，若在则继续获取结果，若不在则运维平台前端没有任何感知；
25.s3.2、根据入参的应用名遍历查找jenkins对应任务，并获取该任务的具体信息；
26.s3.3、根据任务具体信息，获取任务的上一次完整构建序号b，若序号b小于入参的此次构建序号a，则表明该任务还未执行完毕，返回任务状态为正在执行中；
27.s3.4、若任务执行完毕，则通过jenkins的api获取构建序号a任务执行详细信息，根据testng结果计算任务成功率，并根据业务提供的规则，判断当前任务状态是否通过；
28.s3.5、将任务执行状态及任务结果成功率返回给运维平台，运维平台会将任务执行结果及任务详情链接展示在前端，可点击链接跳转到jenkins平台的任务执行页面；若结果通过则出现可发布状态按钮，获取发布权限，而若结果未通过，则不出现可发布状态按钮，需重新调整接口自动化脚本，再次构建任务，直到当前任务状态为通过后才能发布；
29.s3.6、测试人员将应用发布线上之前，当任务结果不通过时，运维平台会将应用名、应用分支、任务通过率、紧急发布原因以及执行人作为入参调用测试平台的记录任务结果接口，以供后续对结果进行进一步分析。
30.优选的，所述步骤s3.3中当任务还未执行完毕时，用户可申请紧急发布，填写紧急发布原因，传入应用名、应用分支、执行人，手动点击执行通过，获取发布权限。
31.优选的，所述步骤s3.5中若任务执行结果未通过，且失败原因不造成功能影响，可以申请紧急发布，手动点击执行通过，附上原因，此时也可获取发布权限。
32.本发明还提供了一种基于保障测试的应用发布质量管理系统，包括：数据导入单元、数据处理单元、任务执行单元和结果统计单元；
33.所述数据导入单元用于导入构建任务所需的具体数据，包括回归卡点应用名单、应用名称、应用分支、制品id和构建人；
34.所述数据处理单元用于对导入数据进行相关预处理，包括针对名单处理接口自动化脚本、根据应用名、应用分支、制品id和构建人动态参数编写企业沟通协同平台通知脚本；
35.所述任务执行单元包括构建任务模块和获取结果模块，其中构建任务模块用于针对应用名、应用分支、制品id构建jenkins任务，获取结果模块用于根据应用名、构建序号获取任务结果；
36.所述结果统计单元用于将自动化回归失败结果进行记录，包括应用名称、制品id、构建人、失败原因信息，方便后续针对记录进行复盘。
37.有益效果：与现有技术相比，本发明具有以下优点：1、通过jenkins平台将测试场景进行沉淀，以便重复利用，方便后续项目迭代时维护测试场景；2、基于jenkins已有的api能力，打通测试平台及运维平台，结合运维平台已有的项目发布逻辑将自动化结果作为能否进行项目发布的一个依据，以此保障应用上线质量；3、结合项目发布流程，在项目预发部署时无感知进行自动化回归测试，无需手动触发回归脚本，大大提高回归测试效率；4、高效的自动化接口回归测试，减少回归测试量，提高测试效率，提高回归的场景数，多维度去校验本次修改内容，不局限于已知项目更改点；5、结合钉钉企业沟通协同平台自动发送用例执行通知，及时将回归自动化结果反馈给应用对应的开发负责人及测试负责人，以便在项目上线前提前暴露接口功能问题和接口性能问题；6、容易实施操作，降低测试成本。
附图说明
38.图1是本发明实施例方法整体流程图；
39.图2是本发明实施例中构建任务流程图；
40.图3是本发明实施例中获取任务结果流程图；
41.图4是本发明实施例系统结构示意图。
具体实施方式
42.下面结合具体实施例，进一步阐明本发明，实施例在以本发明技术方案为前提下进行实施，应理解这些实施例仅用于说明本发明而不用于限制本发明的范围。
43.本发明实施例提供了一种基于保障测试的应用发布质量管理方法，如图1、图2和图3所示，运维平台、测试平台和jenkins均为现有平台；
44.运维平台：用于支持项目整体发布流程的平台，集合了应用发布周期管理、项目管理、基础配置管理、日志管理、各类专项监控等多种运维工具。
45.测试平台：用于测试集成各种测试工具，帮助业务测试同学提高测试效率，支持业务数据的一键式生成、持续集成、安全扫描测试、数据看板、测试用例管理以及发布管控管
理。
46.jenkins是一个基于java开发的开源持续集成工具，用于监控持续性重复的工作，可以集成各种插件完成持续编译、部署、测试，支持构建接口自动化任务和获取报告结果。
47.该方法包括以下步骤：
48.步骤1、配置任务：将需要自动化卡点的应用名单在运维平台的配置中心进行配置，在jenkins平台建立和配置任务，在建立任务时，任务名与应用名一一映射；在配置任务时，在构建触发器中指定任务对应的testng xml文件，将任务与接口自动化脚本进行关联；在jenkins的配置页面内，为对应任务配置动态参数，将应用的分支、制品id、应用名和executor作为四个字符串参数绑定在任务中，具体包括：
49.步骤1.1、配置自动化回归卡点应用名单：确定需要进行自动化卡点的应用名单，借助于运维平台的配置中心页面，将名单作为键值对配置在testcenter应用的配置中心内。
50.步骤1.2、根据步骤1配置的自动化卡点应用名单，在接口自动化工程中配置针对不同应用的testng配置文件，在配置文件中指定当前应用需要进行的回归脚本集。
51.步骤1.3、根据步骤1配置的自动化卡点应用名单，在jenkins平台建立和配置任务，建立的任务名和应用名一一映射。
52.步骤1.4、配置jenkins任务的工程源码相关信息及构建操作，在构建触发器的shell脚本中指定任务对应的testng配置文件，将任务与接口自动化脚本进行关联。
53.步骤1.5、在jenkins服务器中编写python脚本，用于发送钉钉(一种企业沟通协同平台)通知，将应用的分支、制品id、应用名以及构建人信息通过占位符进行表示，以便进行动态传参。
54.步骤1.6、配置jenkins任务的构建动态参数，将应用的分支、制品id、应用名和executor作为四个字符串参数绑定在任务中。
55.步骤2、构建任务当在运维平台上进行应用项目的预发部署时，会将当前部署的应用名、分支以及制品id作为入参，调用测试平台构建任务的接口；由于需要卡点的应用名与jenkins任务名已一一映射，因此根据应用名入参查找并构建对应的jenkins任务；由于每次部署应用都会触发任务构建，因此为了提高效率，每次构建新任务都会将之前的任务进行终止，以任务的最新一次构建结果为准；执行对应任务，发送钉钉通知，返回任务队列，最后将任务此次构建序号及链接(url)返回给运维平台；具体包括(如图2所示)：
56.步骤2.1、运维平台传入应用名、分支、制品id，测试平台读取配置中心的应用白名单，判断入参的应用名是否在配置中心的应用白名单内，若是在白名单内则继续构建jenkinsserver，若不在则无需构建任务；
57.步骤2.2、根据应用名获取jenkins具体任务：根据入参的应用名遍历查找jenkins对应任务，并获取该任务的具体信息；
58.步骤2.3、根据jenkins任务具体信息，获取任务的下一次构建序号a以及上一次成功构建序号b，并将序号a以及序号b之间的任务进行终止；
59.步骤2.4、将入参的分支、制品号传给jenkins，进行任务的参数化构建；
60.步骤2.5、jenkins构建任务，将获取到的当前应用部署分支以及制品id通过钉钉(一种企业沟通协同平台)发送通知，告知当前自动化回归任务对应的构建人、分支、制品id
以及用例数相关信息；
61.步骤2.6、获取jenkins任务队列，若队列已执行(图2中队列执行“是”)则获取此次构建的任务序号以及根据任务信息和序号拼接url(链接)，返回给运维平台，运维平台将序号作为获取结果的入参，同时将url在前端进行展示；若队列未执行(图2中队列执行“否”)，则返回任务队列。
62.步骤3、获取任务结果：当准备应用项目上线前，会在运维平台上将所测的应用分支状态更改为预发验证通过；当点击应用预发验证按钮时，运维平台获取当前应用分支的任务序号，并将应用名和序号作为入参，触发测试平台获取任务结果的接口，将自动化结果作为能否进行应用项目发布的一个依据，具体包括(如图3所示)：
63.步骤3.1、运维平台传入应用名、此次构建的任务序号a，测试平台读取配置中心的应用白名单，判断入参的应用名是否在白名单内，若在则继续获取结果，若不在则运维平台前端没有任何感知，直接跳到生产验证状态；
64.步骤3.2、根据入参的应用名遍历查找jenkins对应任务，jenkins平台返回该任务的具体信息；
65.步骤3.3、根据任务具体信息，获取当前任务的上一次完整构建序号b，若序号b小于入参的此次构建序号a，则表明该任务还未执行完毕，返回任务状态为正在执行中，在运维平台展示状态，用户可选择重新请求或申请紧急发布，若申请紧急发布则需要填写紧急发布原因，传入应用名、应用分支、任务通过率和执行人，手动点击执行通过，跳转至待生产验证状态即出现可发布状态按钮，获取发布权限。
66.步骤3.4、若任务执行完毕(即a＜b)，则通过jenkins的api获取构建序号a对应的任务信息，根据用例总数、跳过数、失败数计算任务成功率，并根据业务提供的规则(成功率是否大于规定值)，判断当前任务状态是否通过；
67.步骤3.5、将任务成功率和链接返回给运维平台，运维平台会将任务执行结果及任务详情链接展示在前端，可点击链接跳转到jenkins平台的任务执行页面；若结果通过(成功率大于等于规定值)则跳转至待生产验证状态即出现可发布状态按钮，获取发布权限；而若结果未通过(成功率小于规定值)，则不出现可发布状态按钮，用户可选择重新请求或申请紧急发布，若用户选择重新请求，需重新调整接口自动化脚本，再次构建任务，直到脚本执行结果为成功率大于等于规定值后才能发布；若失败原因不造成功能影响，可以申请紧急发布，手动点击执行通过，附上原因，此时也可获取发布权限。
68.步骤3.6、测试人员将应用发布线上之前，当任务结果不通过时，运维平台会将应用名、应用分支、任务通过率、紧急发布原因以及执行人(指任务结果失败时申请紧急发布的人)作为入参调用测试平台的记录任务结果接口，以供后续对结果进行进一步分析。
69.本实施例还提供了一种基于保障测试的应用发布质量管理系统，如图4所示，包括：数据导入单元、数据处理单元、任务执行单元和结果统计单元；
70.数据导入单元用于导入构建任务所需的具体数据，包括回归卡点应用名单、应用名称、应用分支、制品id和构建人；
71.数据处理单元用于对导入数据进行相关预处理，包括针对名单处理接口自动化脚本、根据应用名、应用分支、制品id和构建人动态参数编写企业沟通协同平台通知脚本；
72.任务执行单元包括构建任务模块和获取结果模块，其中构建任务模块用于针对应
用名、应用分支、制品id构建jenkins任务，获取结果模块用于根据应用名、构建序号获取任务结果；
73.结果统计单元用于将自动化回归失败结果进行记录，包括应用名称、制品id、构建人、失败原因信息，方便后续针对记录进行复盘。
74.以发布“售后中心”的应用为例，本实施例的方法如下：
75.1.如需发布售后中心应用，首先需将售后中心应用名添加至自动化卡点的应用名单，例如，售后中心应用名为aftersalecenter，则可在运维平台中的配置中心页面，添加key为app.name.whitelist，value为aftersalecenter的键值对。
76.2.编写针对aftersalecenter应用的接口自动化脚本，并在testng配置文件指定该脚本的类路径。
77.3.建立jenkins任务，设置任务名为aftersalecenter，以便关联应用。
78.4.配置jenkins任务，为aftersalecenter任务设定branch、goodsid、applicationname和executor四个字符串参数，分别代表应用的分支、制品id、应用名及任务构建人；在源码管理配置中指定接口脚本工程的git url及账号信息；在构建shell脚本中指定对应testng配置文件；在构建后操作配置中指定allure报告的报告存储位置，以及编写发送钉钉通知的脚本，将此前设定的branch、goodsid、applicationname和executor四个字符串参数传入脚本中。
79.5.配置完成任务后，当aftersalecenter应用在运维平台进行预发部署时，会传入应用名、分支、制品id以及构建人四个参数到测试平台。
80.6.测试平台首先读取配置中心的应用名单，根据app.name.whitelist的key值获取名单，判断aftersalecenter是否在名单列表中。
81.7.当判断结果返回正确后，测试平台构建jenkinsserver，使用jenkinsserver的getjob方法获取目标任务，由于应用名与jenkins任务名已一一映射，因此向getjob方法传入应用名即可获取到对应的job详细数据。
82.8.由于只需获取最近一次任务的构建结果，因此通过job的详细数据，获取任务的下一次构建序号以及上次成功构建的序号，并将两个序号中间的任务进行停止；
83.9.通过对应任务的build方法构建jenkins任务，并对应第四步配置jenkins任务时设置的四个字符串参数，将运维平台传入的应用名、分支、制品id及构建人作为build方法的入参，完成jenkins任务的参数化构建。
84.10.测试平台将任务的构建序号及任务对应的jenkins链接返回给运维平台，运维平台将其存储到数据表中。
85.11.当aftersalecenter应用进行上线前，测试人员会在运维平台点击预发验证，此时运维平台会向测试平台传入应用名及任务序号，获取此次任务的构建结果。
86.12.测试平台首先根据应用名判断是否在回归卡点应用名单内，判断在名单内后，构建jenkinsserver，使用jenkinsserver的getjob方法获取目标任务。
87.13.根据目标任务数据，获取该任务上次完整构建的序号，将运维平台传入的序号a和该任务上次完整构建的序号b进行对比，如果序号a大于序号b，则表明该任务还未执行完毕，则将任务状态置为正在执行中，并返回给运维平台；否则直接获取该任务序号对应的任务结果数据。
88.14.获取任务结果数据的失败用例数failcount、跳过用例数skipcount和总用例数totalcount，根据(totalcount-failcount-skipcount)/totalcount公式计算得到成功率，若成功率为100％，则将任务状态置为通过，若成功率小于100％，则置为不通过，并将任务状态和成功率数据返回给运维平台。
89.15.运维平台将此任务对应的状态、成功率及此前存储的jenkins任务链接展示在前端，若状态为通过，则可将aftersalecenter发布到生产环境；若状态为不通过，则测试人员可点击jenkins任务链接进行问题的排查，当需要紧急发布时，测试人员也可点击申请紧急发布按钮，并填写紧急发布的原因进行到发布生产环境的状态。
90.若测试人员选择申请紧急发布，运维平台则将应用名、应用分支、任务通过率、紧急发布原因以及执行人信息传入到测试平台，测试平台将这些信息存储到数据表中，以便后续对问题进行分析和复盘。
91.以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。