本发明涉及环境系统可用性测试，具体为一种自动化进行系统可用性验证的方法及系统。
背景技术：
1、随着云计算和容器化技术的飞速发展，kubernetes和docker成为了现代软件开发和运维领域不可或缺的工具。kubernetes，作为一个开源的容器编排系统，通过提供自动化部署、扩展和管理容器化应用程序的能力，极大地简化了大规模、分布式系统的运维复杂性。docker则通过其轻量级的容器技术，为应用程序提供了高度可移植和可重复使用的运行环境。
2、在这种背景下，许多企业和组织开始摒弃传统的虚拟机部署方式，转而采用kubernetes+docker的生态体系来搭建和部署环境系统。这一转变带来了诸多优势。
3、然而，随着api测试在软件开发和部署过程中的重要性日益凸显，如何在kubernetes环境系统中高效地进行api测试及其结果处理成为了一个挑战。在k8s环境中，api测试的结果往往分布在多个容器和节点上，这使得将运行结果文件导出变得复杂且耗时。此外，对导出的结果进行批量分析也是一个繁琐且耗时的过程，需要人工介入并投入大量时间。
技术实现思路
1、本发明的目的在于提供一种自动化进行系统可用性验证的方法及系统，以解决上述背景技术中提出的问题。
2、为实现上述目的，本发明提供如下技术方案：一种自动化进行系统可用性验证的方法，所述方法包括以下步骤：
3、获取服务api对应的预设信息；
4、构建生成服务jmeter脚本；
5、执行可用性测试程序，收集测试结果，并分析测试结果；
6、清理环境测试数据。
7、优选的，获取服务api对应的预设信息的具体操作包括：
8、测试人员向预设的测试用例库中录入具体服务的api测试信息，录入api测试信息的方式通过预先配置好的预设信息模板进行操作，选择具体的api测试属性名和输入具体的api测试属性值来实现，通过进行简单的设置和修改参数，直接供环境系统可用性测试的使用。
9、优选的，构建生成服务jmeter脚本的具体操作包括：
10、根据测试用例库中测试人员存入的api预设信息，执行构建脚本通过设置jmx模板和完善jmx内容的方式对api预设信息进行构建，包括构建jxm的jmetertestplan标签数据、hashtree标签数据、arguments标签数据、threadgroup标签数据、httpsamplerproxy标签数据、resultcollector标签数据，同时为jmx脚本文件设置正则表达式提取器，用于动态数据关联，从而获取服务器相应的动态数据，在具体服务的线程组中添加设置监听器以及断言来判断请求相应的结果是否是预期结果，最终构建完成直接使用jmter执行的各个服务的jmx文件，供后续步骤使用。
11、优选的，执行可用性测试程序，收集测试结果，并分析测试结果的具体操作包括：
12、执行可用性测试程序，输入执行参数，第一个参数为当前环境系统的域名信息，第二个可选参数执行次数，满足执行多次，默认执行1次；开始执行后，测试脚本首先检测当前环境系统是否存在jmeter镜像，若不存在则解压并使用测试包中的jmeter镜像，通过docker容器的方式创建并启动jmeter镜像的容器，为该容器分配一个文件系统，并在只读的镜像层外面挂载一层可读可写层，同时使用add-host的方式，配置当前环境系统的hosts地址供容器使用，防止出现域名无法解析的问题，最后开始依次执行所有的*.jmx文件，即第二步中构建的各个服务jmeter脚本文件，同时根据执参数执行次数来判断是否需要循环执行多次，执行完毕后即进入测试结果的收集和分析阶段；
13、收集测试结果，测试脚本通过执行jmeter命令生成测试报告，使用非gui模式执行jmeter，测试计划保存的路径及文件名使用当前环境系统时间戳的方式来进行区分，测试结束后，生成测试报告，保存生成测试结果的文件，其中csv文件、log文件、reports文件均使用时间戳+服务名的方式进行保存，同时测试脚本会读取csv文件的内容，并使用条件过滤，将通过的和失败的结果分别保存到两个不同的文件中供后续输出测试结果的使用，最后输出整个测试过程中各个服务的api测试通过情况和失败情况、服务具体的api测试结果和整个部署环境系统的可用性结果；
14、分析测试结果，分析结果从jmeter结果和测试脚本处理两方面综合处理和分析，其中jmeter结果，包含了响应结果、响应状态码、响应时间，测试脚本处理主要包括，通过线程组中设置监听器以及断言来捕获测试结果，若断言信息中出现断言失败则判定用例执行失败，并统计异常信息，最终测试结果包含：执行结果、失败原因、前环境系统可用性分析结果。
15、优选的，清理环境测试数据的具体操作包括：
16、执行清理数据的脚本，再执行清理脚本前可以通过各个服务api对应的预设信息生成清理环境系统的jmeter脚本文件，同时清理脚本会进行全环境系统的检索和排查，捕获当前环境系统中是否存在其他需要清理的测试数据，包含临时创建和使用的测试命名空间数据，测试pvc数据、测试pv数据、测试lvmvg数据、测试配置文件数据、测试实例数据，通过对测试数据的扫描和彻底清理，保证了测试环境系统可用性完成后将环境系统恢复为最初状态，不影响环境系统后续的正常运行。
17、一种自动化进行系统可用性验证系统，所述系统由信息获取模块、脚本构建模块、程序执行模块以及数据清理模块组成；
18、信息获取模块，获取服务api对应的预设信息；
19、脚本构建模块，构建生成服务jmeter脚本；
20、程序执行模块，执行可用性测试程序，收集测试结果，并分析测试结果；
21、数据清理模块，清理环境测试数据。
22、优选的，所述信息获取模块，测试人员向预设的测试用例库中录入具体服务的api测试信息，录入api测试信息的方式通过预先配置好的预设信息模板进行操作，选择具体的api测试属性名和输入具体的api测试属性值来实现，通过进行简单的设置和修改参数，直接供环境系统可用性测试的使用。
23、优选的，所述脚本构建模块，根据测试用例库中测试人员存入的api预设信息，执行构建脚本通过设置jmx模板和完善jmx内容的方式对api预设信息进行构建，包括构建jxm的jmetertestplan标签数据、hashtree标签数据、arguments标签数据、threadgroup标签数据、httpsamplerproxy标签数据、resultcollector标签数据，同时为jmx脚本文件设置正则表达式提取器，用于动态数据关联，从而获取服务器相应的动态数据，在具体服务的线程组中添加设置监听器以及断言来判断请求相应的结果是否是预期结果，最终构建完成直接使用jmter执行的各个服务的jmx文件，供后续步骤使用。
24、优选的，所述程序执行模块，执行可用性测试程序，输入执行参数，第一个参数为当前环境系统的域名信息，第二个可选参数执行次数，满足执行多次，默认执行1次；开始执行后，测试脚本首先检测当前环境系统是否存在jmeter镜像，若不存在则解压并使用测试包中的jmeter镜像，通过docker容器的方式创建并启动jmeter镜像的容器，为该容器分配一个文件系统，并在只读的镜像层外面挂载一层可读可写层，同时使用add-host的方式，配置当前环境系统的hosts地址供容器使用，防止出现域名无法解析的问题，最后开始依次执行所有的*.jmx文件，即第二步中构建的各个服务jmeter脚本文件，同时根据执参数执行次数来判断是否需要循环执行多次，执行完毕后即进入测试结果的收集和分析阶段；
25、收集测试结果，测试脚本通过执行jmeter命令生成测试报告，使用非gui模式执行jmeter，测试计划保存的路径及文件名使用当前环境系统时间戳的方式来进行区分，测试结束后，生成测试报告，保存生成测试结果的文件，其中csv文件、log文件、reports文件均使用时间戳+服务名的方式进行保存，同时测试脚本会读取csv文件的内容，并使用条件过滤，将通过的和失败的结果分别保存到两个不同的文件中供后续输出测试结果的使用，最后输出整个测试过程中各个服务的api测试通过情况和失败情况、服务具体的api测试结果和整个部署环境系统的可用性结果；
26、分析测试结果，分析结果从jmeter结果和测试脚本处理两方面综合处理和分析，其中jmeter结果，包含了响应结果、响应状态码、响应时间，测试脚本处理主要包括，通过线程组中设置监听器以及断言来捕获测试结果，若断言信息中出现断言失败则判定用例执行失败，并统计异常信息，最终测试结果包含：执行结果、失败原因、前环境系统可用性分析结果。
27、优选的，所述数据清理模块，执行清理数据的脚本，再执行清理脚本前可以通过各个服务api对应的预设信息生成清理环境系统的jmeter脚本文件，同时清理脚本会进行全环境系统的检索和排查，捕获当前环境系统中是否存在其他需要清理的测试数据，包含临时创建和使用的测试命名空间数据，测试pvc数据、测试pv数据、测试lvmvg数据、测试配置文件数据、测试实例数据，通过对测试数据的扫描和彻底清理，保证了测试环境系统可用性完成后将环境系统恢复为最初状态，不影响环境系统后续的正常运行。
28、与现有技术相比，本发明的有益效果是：
29、本发明提出的自动化进行系统可用性验证的方法及系统，通过简单的设置和修改参数，自动化的方式执行，降低了人为干预的工作量，降低环境系统的可用性测试的测试难度，提高环境系统的可用性测试的效率；将环境系统可用性的测试结果进行整理和筛选，解决了在k8s环境系统中处理大量的api测试结果非常耗时的问题，同时测试完成后进行测试数据的清理，还原环境系统到最初状态，不会对环境系统产生测试数据污染。
1.一种自动化进行系统可用性验证的方法，其特征在于：所述方法包括以下步骤：
2.根据权利要求1所述的一种自动化进行系统可用性验证的方法，其特征在于：获取服务api对应的预设信息的具体操作包括：
3.根据权利要求1所述的一种自动化进行系统可用性验证的方法，其特征在于：构建生成服务jmeter脚本的具体操作包括：
4.根据权利要求1所述的一种自动化进行系统可用性验证的方法，其特征在于：执行可用性测试程序，收集测试结果，并分析测试结果的具体操作包括：
5.根据权利要求1所述的一种自动化进行系统可用性验证的方法，其特征在于：清理环境测试数据的具体操作包括：
6.一种根据权利要求1-5任意一项所述的自动化进行系统可用性验证的方法的自动化进行系统可用性验证系统，其特征在于：所述系统由信息获取模块、脚本构建模块、程序执行模块以及数据清理模块组成；
7.根据权利要求6所述的一种自动化进行系统可用性验证系统，其特征在于：所述信息获取模块，测试人员向预设的测试用例库中录入具体服务的api测试信息，录入api测试信息的方式通过预先配置好的预设信息模板进行操作，选择具体的api测试属性名和输入具体的api测试属性值来实现，通过进行简单的设置和修改参数，直接供环境系统可用性测试的使用。
8.根据权利要求6所述的一种自动化进行系统可用性验证系统，其特征在于：所述脚本构建模块，根据测试用例库中测试人员存入的api预设信息，执行构建脚本通过设置jmx模板和完善jmx内容的方式对api预设信息进行构建，包括构建jxm的jmetertestplan标签数据、hashtree标签数据、arguments标签数据、threadgroup标签数据、httpsamplerproxy标签数据、resultcollector标签数据，同时为jmx脚本文件设置正则表达式提取器，用于动态数据关联，从而获取服务器相应的动态数据，在具体服务的线程组中添加设置监听器以及断言来判断请求相应的结果是否是预期结果，最终构建完成直接使用jmter执行的各个服务的jmx文件，供后续步骤使用。
9.根据权利要求6所述的一种自动化进行系统可用性验证系统，其特征在于：所述程序执行模块，执行可用性测试程序，输入执行参数，第一个参数为当前环境系统的域名信息，第二个可选参数执行次数，满足执行多次，默认执行1次；开始执行后，测试脚本首先检测当前环境系统是否存在jmeter镜像，若不存在则解压并使用测试包中的jmeter镜像，通过docker容器的方式创建并启动jmeter镜像的容器，为该容器分配一个文件系统，并在只读的镜像层外面挂载一层可读可写层，同时使用add-host的方式，配置当前环境系统的hosts地址供容器使用，防止出现域名无法解析的问题，最后开始依次执行所有的*.jmx文件，即第二步中构建的各个服务jmeter脚本文件，同时根据执参数执行次数来判断是否需要循环执行多次，执行完毕后即进入测试结果的收集和分析阶段；
10.根据权利要求6所述的一种自动化进行系统可用性验证系统，其特征在于：所述数据清理模块，执行清理数据的脚本，再执行清理脚本前可以通过各个服务api对应的预设信息生成清理环境系统的jmeter脚本文件，同时清理脚本会进行全环境系统的检索和排查，捕获当前环境系统中是否存在其他需要清理的测试数据，包含临时创建和使用的测试命名空间数据，测试pvc数据、测试pv数据、测试lvmvg数据、测试配置文件数据、测试实例数据，通过对测试数据的扫描和彻底清理，保证了测试环境系统可用性完成后将环境系统恢复为最初状态，不影响环境系统后续的正常运行。
