本发明涉及软件监测领域，尤其涉及一种基于漏斗模型的自动化监测方法及终端。
背景技术：
在敏捷开发时代，快速交付已经成为一个普遍的现象，但是快速交付带来的风险不言而喻。因此，产品上线前需要部署一套完整的故障应急监测体系去确认产品运行的情况。对于一些重点项目，短暂的故障时长都有可能造成用户的流失，这将给产品带来无法估量的损失，因此，需要对产品进行监测，并在出现故障时尽可能缩短故障处理时间。
现如今产品线上质量拨测方案众多，基本上是根据用户需求，定时去检测产品的可用性来确保服务质量，但是，现有的拨测方式存在以下问题：
第一，对产品质量监控方案的部署对部署人员而言是一个挑战，部署人员需要非常清楚产品的核心业务流程、用户行为场景等，才能保证所部署的监控方案能够涵盖需求，否则就会出现监控漏洞；但是，如果为了避免监控漏洞的出现，对产品的所有业务都进行检测，将会造成耗时长，目标分散，当故障并发时，就可能分散故障排查人员的精力，降低故障处理效率，并且不同的业务等级，故障响应的机制不同，若所有业务都部署监控，就需要人工对预警信息进行二次甄别、排列优先级；
第二，故障影响层面仅从程序层面评估不足，业务关联性或用户使用习惯情况不得而知，且用户对故障恢复后的响应情况需要另外评估，目前的拨测方案大部分拘泥于可用性的监测，实际上产品可能存在其他非故障类的可优化点。
技术实现要素：
本发明所要解决的技术问题是：提高一种全面、高效的基于漏斗模型的自动化监测方法及终端。
为了解决上述技术问题，本发明采用的一种技术方案为：
一种基于漏斗模型的自动化监测方法，包括步骤：
s1、为待监测项目构建对应的漏斗模型，获取漏斗模型分析数据；
s2、根据所述漏斗模型分析数据确定所述待监测项目中需要监测的模块；
s3、根据所述需要监测的模块，获取对应的拨测脚本，将所述拨测脚本组装，生成所述待监测项目的测试代码，利用所述测试代码对所述待监测项目进行监测。
为了解决上述技术问题，本发明采用的另一种技术方案为：
一种基于漏斗模型的自动化监测终端，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
s1、为待监测项目构建对应的漏斗模型，获取漏斗模型分析数据；
s2、根据所述漏斗模型分析数据确定所述待监测项目中需要监测的模块；
s3、根据所述需要监测的模块，获取对应的拨测脚本，将所述拨测脚本组装，生成所述待监测项目的测试代码，利用所述测试代码对所述待监测项目进行监测。
本发明的有益效果在于：通过为待监测项目构建对应的漏斗模型，获取漏斗模型分析数据，基于所述漏斗模型分析数据确定需要监测的模块，自动化获取并组装需要监测的模块对应的测试脚本，对待监测项目进行测试，基于漏斗模型分析数据能够有针对性、准确地确定出需要监测的核心模块，并且基于确定出的模块实现自动化获取并组装对应的测试脚本，实现了高效、全面的自动化监测。
附图说明
图1为本发明实施例的一种基于漏斗模型的自动化监测方法的流程图；
图2为本发明实施例的一种基于漏斗模型的自动化监测终端的结构示意图；
标号说明：
1、一种基于漏斗模型的自动化监测终端；2、存储器；3、处理器。
具体实施方式
为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。
本发明最关键的构思在于：通过为待监测项目构建对应的漏斗模型，获取漏斗模型分析数据，基于所述漏斗模型分析数据确定需要监测的模块，自动化获取并组装需要监测的模块对应的测试代码，对待监测项目进行测试。
请参照图1，一种基于漏斗模型的自动化监测方法，包括步骤：
s1、为待监测项目构建对应的漏斗模型，获取漏斗模型分析数据；
s2、根据所述漏斗模型分析数据确定所述待监测项目中需要监测的模块；
s3、根据所述需要监测的模块，获取对应的拨测脚本，将所述拨测脚本组装，生成所述待监测项目的测试代码，利用所述测试代码对所述待监测项目进行监测。
从上述描述可知，本发明的有益效果在于：通过为待监测项目构建对应的漏斗模型，获取漏斗模型分析数据，基于所述漏斗模型分析数据确定需要监测的模块，自动化获取并组装需要监测的模块对应的测试脚本，对待监测项目进行测试，基于漏斗模型分析数据能够有针对性、准确地确定出需要监测的核心模块，并且基于确定出的模块实现自动化获取并组装对应的测试脚本，实现了高效、全面的自动化监测。
进一步的，所述步骤s1包括：
s11、将待监测项目分解成多个模块，每个模块实现不同的功能；
s12、采集所述待监测项目的用户数据，基于所述用户数据，构建与所述待监测项目对应的漏斗模型；
s13、分析所述漏斗模型，获取所述漏斗模型中每一模块对应的用户使用数以及每一模块的用户流失率。
由上述描述可知，通过分析漏斗模型，获取体现用户行为的用户数据，能够保证所确定出的需要监测的模块的更具针对性。
进一步的，所述步骤s2包括：
获取用户使用数大于第一预设值或用户流失率大于第二预设值的模块作为需要监测的模块。
由上述描述可知，用户使用数越多，则表明对应的模块是待监测项目的核心模块，而用户流失率越高，则说明对应的模块，可能存在问题，将上述模块作为重点监测的对象，满足实际使用情况的需要，具有合理性，能够比较全面地覆盖待测项目中需要监测的模块，避免监测漏洞的出现。
进一步的，所述步骤s3中所述利用所述测试代码对所述待监测项目进行监测包括：
s31、根据预设的监测频率，定时触发拨测，获取服务端和客户端发送的拨测数据；
s32、分析所述拨测数据，判断是否存在待排故障，若是，则执行步骤s33，否则，返回执行步骤s31；
s33、判断所述待排故障是否属于所述待监测项目的未恢复故障，若是，更新所述未恢复故障的故障信息，若否，新增故障记录；
s34、根据所记录的故障信息，判断是否大于告警阈值，若是，进行告警，否则，返回执行步骤s31。
由上述描述可知，通过监测频率以及告警阈值的设置，并对拨测过程中出现的故障信息进行及时记录，能够保证准确、快速地获知监测过程中出现的问题，并对出现的问题进行及时排查。
进一步的，还包括步骤：
当接收到告警信息时，对告警信息对应的故障进行定位，确定发生故障的模块；
通过所述漏斗模型确定与所述发生故障的模块关联的模块，获取所述关联的模块对应的拨测脚本；
在进行下一次拨测时，根据所述发生故障的模块以及关联的模块对应的拨测脚本进行回归测试。
由上述描述可知，基于漏斗模型确定与发生故障的模块关联的模块，在下一次拨测时进行回归测试，能够确保故障影响的范围全面恢复，提高故障排除的可靠性。
请参照图2，一种基于漏斗模型的自动化监测终端，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
s1、为待监测项目构建对应的漏斗模型，获取漏斗模型分析数据；
s2、根据所述漏斗模型分析数据确定所述待监测项目中需要监测的模块；
s3、根据所述需要监测的模块，获取对应的拨测脚本，将所述拨测脚本组装，生成所述待监测项目的测试代码，利用所述测试代码对所述待监测项目进行监测。
从上述描述可知，本发明的有益效果在于：通过为待监测项目构建对应的漏斗模型，获取漏斗模型分析数据，基于所述漏斗模型分析数据确定需要监测的模块，自动化获取并组装需要监测的模块对应的测试脚本，对待监测项目进行测试，基于漏斗模型分析数据能够有针对性、准确地确定出需要监测的核心模块，并且基于确定出的模块实现自动化获取并组装对应的测试脚本，实现了高效、全面的自动化监测。
进一步的，所述步骤s1包括：
s11、将待监测项目分解成多个模块，每个模块实现不同的功能；
s12、采集所述待监测项目的用户数据，基于所述用户数据，构建与所述待监测项目对应的漏斗模型；
s13、分析所述漏斗模型，获取所述漏斗模型中每一模块对应的用户使用数以及每一模块的用户流失率。
由上述描述可知，通过分析漏斗模型，获取体现用户行为的用户数据，能够保证所确定出的需要监测的模块的更具针对性。
进一步的，所述步骤s2包括：
获取用户使用数大于第一预设值或用户流失率大于第二预设值的模块作为需要监测的模块。
由上述描述可知，用户使用数越多，则表明对应的模块是待监测项目的核心模块，而用户流失率越高，则说明对应的模块，可能存在问题，将上述模块作为重点监测的对象，满足实际使用情况的需要，具有合理性，能够比较全面地覆盖待测项目中需要监测的模块，避免监测漏洞的出现。
进一步的，所述步骤s3中所述利用所述测试代码对所述待监测项目进行监测包括：
s31、根据预设的监测频率，定时触发拨测，获取服务端和客户端发送的拨测数据；
s32、分析所述拨测数据，判断是否存在待排故障，若是，则执行步骤s33，否则，返回执行步骤s31；
s33、判断所述待排故障是否属于所述待监测项目的未恢复故障，若是，更新所述未恢复故障的故障信息，若否，新增故障记录；
s34、根据所记录的故障信息，判断是否大于告警阈值，若是，进行告警，否则，返回执行步骤s31。
由上述描述可知，通过监测频率以及告警阈值的设置，并对拨测过程中出现的故障信息进行及时记录，能够保证准确、快速地获知监测过程中出现的问题，并对出现的问题进行及时排查。
进一步的，还包括步骤：
当接收到告警信息时，对告警信息对应的故障进行定位，确定发生故障的模块；
通过所述漏斗模型确定与所述发生故障的模块关联的模块，获取所述关联的模块对应的拨测脚本；
在进行下一次拨测时，根据所述发生故障的模块以及关联的模块对应的拨测脚本进行回归测试。
由上述描述可知，基于漏斗模型确定与发生故障的模块关联的模块，在下一次拨测时进行回归测试，能够确保故障影响的范围全面恢复，提高故障排除的可靠性。
实施例一
请参照图1，一种基于漏斗模型的自动化监测方法，包括步骤：
s1、为待监测项目构建对应的漏斗模型，获取漏斗模型分析数据；
具体的，包括如下子步骤：
s11、将待监测项目分解成多个模块，每个模块实现不同的功能；
s12、采集所述待监测项目的用户数据，基于所述用户数据，构建与所述待监测项目对应的漏斗模型；
s13、分析所述漏斗模型，获取所述漏斗模型中每一模块对应的用户使用数以及每一模块的用户流失率；
s2、根据所述漏斗模型分析数据确定所述待监测项目中需要监测的模块；
具体的，获取用户使用数大于第一预设值或用户流失率大于第二预设值的模块作为需要监测的模块，每个模块中只要对应的用户使用数或用户流失率任意一个大于预设的阈值，则将所述模块作为需要监测的模块；
s3、根据所述需要监测的模块，获取对应的拨测脚本，将所述拨测脚本组装，生成所述待监测项目的测试代码，利用所述测试代码对所述待监测项目进行监测；
利用所述测试代码对所述待监测项目进行监测具体包括：
s31、根据预设的监测频率，定时触发拨测，获取服务端和客户端发送的拨测数据；
s32、分析所述拨测数据，判断是否存在待排故障，若是，则执行步骤s33，否则，返回执行步骤s31；
s33、判断所述待排故障是否属于所述待监测项目的未恢复故障，若是，更新所述未恢复故障的故障信息，若否，新增故障记录；
s34、根据所记录的故障信息，判断是否大于告警阈值，若是，进行告警，否则，返回执行步骤s31。
实施例二
本实施例与实施例一的不同在于，还包括步骤：
当接收到告警信息时，对告警信息对应的故障进行定位，确定发生故障的模块；
通过所述漏斗模型确定与所述发生故障的模块关联的模块，获取所述关联的模块对应的拨测脚本；
在进行下一次拨测时，根据所述发生故障的模块以及关联的模块对应的拨测脚本进行回归测试。
实施例三
请参照图2，一种基于漏斗模型的自动化监测终端1，包括存储器2、处理器3以及存储在所述存储器2上并可在所述处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现实施例一的各个步骤。
实施例四
请参照图2，一种基于漏斗模型的自动化监测终端1，包括存储器2、处理器3以及存储在所述存储器2上并可在所述处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现实施例二的各个步骤。
实施例五
本实施例将上述的基于漏斗模型的自动化监测方法应用于具体的场景：
比如待测项目为一电商购物平台，可以基于各个模块实现的功能将所述电商购物平台划分为如下几个模块：选购商品、添加购物车、购物车结算、核查订单、提交订单、支付方式选择以及支付结束；
从数据平台获取该电商购物平台的用户数据，对所述用户数据进行分析，根据所采集到的数据得到各个模块的用户数分别为：1000人、700人、500人、250人、120人、30人以及26人，基于所述各个模块的用户数确定各个模块的用户占比分别为：100％、70％、50％、25％、12％、3％以及2.6％，所述占比的计算方式是当前模块的人数除以选购商品模块的人数，接着基于模块间人数的减少计算各个模块的用户流失率分别为：30％、29％、50％、52％、75％以及13％，由此就建立起了针对该电商购物平台的漏斗模型，其中，各个模块的用户占比和用户流失率为所述漏斗模型的漏斗分析数据；
选取用户占比大于第一预设值的模块或者用户流失率大于第二预设值的模块作为需要监测的模块，比如选取第一预设值为60％，第二预设值为55％，则就选取选购商品、添加购物车以及支付方式选择模块作为需要监测的模块；
基于所选取的监测模块获取对应的拨测脚本，将所述拨测脚本组装，生成所述待监测项目的测试代码，利用所述测试代码对所述待监测项目进行监测；
其中，准备一台pc作为拨测服务器，拨测服务器上承载着待测项目的所有拨测脚本数据；
在进行监测之前，可以配置对应的待测项目信息、监测频率、告警阈值、推送机制等，其中，告警阈值指的是当所述待监测项目中相应故障数大于所述告警阈值时，即进行告警，可以根据实际情况需要，对不同等级的故障设置不同的告警阈值，比如如果是非常重要的模块，则设置告警阈值为0，只要出故障即进行告警，而对于重要性不是很高的模块，则可以设置所述告警阈值为3，即相同的故障出现3次以上，才进行告警，所述推送机制也是类似，可以设置对于非常重要的模块，测试失败，即出故障，就推送告警信息，如果重要性不是很高的模块，则连续出故障3次以上并且测试通过率低于一预设值时才进行告警信息的推送；
具体进行监测时，包括如下步骤：
s31、根据所述监测频率，设置拨测定时器进行计时，当到达拨测时间时，触发拨测，利用所述测试代码对所述待检测项目的模块进行监测，获取服务端和客户端发送的拨测数据；
s32、获取到拨测数据后，分析所述拨测数据，判断是否存在待排故障，若是，则执行步骤s33，否则，返回执行步骤s31；
s33、判断所述待排故障是否属于所述待监测项目的未恢复故障，若是，更新所述未恢复故障的故障信息，若否，新增故障记录，在进行故障信息纪录时，可以列一个待修复故障的列表，通过查表就可以确定所述待排故障是否属于未恢复故障，若是新增的故障，则直接填入所述待修复故障的列表，更新所述待修复故障的列表，若是属于未恢复的故障，则相应故障的次数加1；
s34、根据所记录的故障信息，判断是否大于告警阈值，若是，进行告警，否则，返回执行步骤s31。
接收到告警信息之后，启动告警机制，根据预设的推送机制将告警信息推送给目标用户，并启动故障应急处理，其中故障应急处理主要包括：接收到故障信息后，对故障信息进行定位，确定发送故障的模块，然后通知对应的开发端，使开发端进行故障处理，处理完之后进行故障验收，故障验收之后进行开发经理验收，接着是产品验收，运维验收，最后用户验收，用户验收听过后，消除告警，然后又返回步骤s31；
在接收到告警信息，定位到发生故障的模块后，还通过所述漏斗模型确定与所述发生故障的模块关联的模块，获取所述关联的模块对应的拨测脚本；
在进行下一次拨测时，根据所述发生故障的模块以及关联的模块对应的拨测脚本进行回归测试，从而确保故障影响范围全面恢复；
在进行监测时，可以根据漏斗模型的分析数据来确定各个模块的故障优先级，比如用户占比越高，故障优先级越高，用户流失率越高，故障优先级越高，基于故障优先级可以确定进行故障排除的先后，若多个模块同时出现故障，则故障优先级高的进行优先处理；
其中，所述漏斗模型的分析数据是动态变化的，在故障排除之后，可以根据对应模块故障前后的漏斗模型分析数据，确认故障对产品的影响，并输出故障报告，同时由于漏斗模型分析是根据各个模块用户的使用数据而动态变化的，所以即便待监测项目未出现故障信息，也可以基于漏斗模型分析数据通过阶段性数据对比发现产品可优化的节点，并给产品后续优化提供参考，比如基于各个模块的用户流失率，加上所监测产品的各个模块都是运行正常的，但是通过分析发现某个时间段内某两个模块用户流失率很高，这时候就要进行产品评测，是否存在用户体验上的问题，如因为某些控件放置区域不适用于用户使用习惯等，以此可以来反馈故障信息以外的信息以利于产品的调整。
综上所述，本发明提供的一种基于漏斗模型的自动化监测方法及终端，通过为待监测项目构建对应的漏斗模型，获取漏斗模型分析数据，基于所述漏斗模型分析数据确定需要监测的模块，自动化获取并组装需要监测的模块对应的测试脚本，对待监测项目进行测试，基于漏斗模型分析数据能够确认待监测项目的核心用户行为，不仅能够有针对性、准确地确定出需要监测的核心模块，基于确定出的模块实现自动化获取并组装对应的测试脚本，实现了高效、全面的自动化监测，而且由于是基于漏斗模型，通过阶段性的漏斗模型分析数据对比，能够发现非故障类的可优化点并给出建议，使得测试不仅仅局限于程序层面，同时可以根据漏斗模型分析数据自动化实现故障定级、预警、通知、跟进等一系列应急处理流程，快速高效。
以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等同变换，或直接或间接运用在相关的技术领域，均同理包括在本发明的专利保护范围内。