CN117271278A - 一种基于DevOps的性能评估方法、装置和电子设备 - Google Patents

一种基于DevOps的性能评估方法、装置和电子设备 Download PDF

Info

Publication number
CN117271278A
CN117271278A CN202210664639.4A CN202210664639A CN117271278A CN 117271278 A CN117271278 A CN 117271278A CN 202210664639 A CN202210664639 A CN 202210664639A CN 117271278 A CN117271278 A CN 117271278A
Authority
CN
China
Prior art keywords
target
devops
determining
functional module
test case
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210664639.4A
Other languages
English (en)
Inventor
周实奇
陈智扬
黄倚霄
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
China Mobile Group Guangdong Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Group Guangdong Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd, China Mobile Group Guangdong Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN202210664639.4A priority Critical patent/CN117271278A/zh
Publication of CN117271278A publication Critical patent/CN117271278A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/008—Reliability or availability analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3495—Performance evaluation by tracing or monitoring for systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开了一种基于DevOps的性能评估方法、装置和电子设备，属于信息科技技术领域，其中，方法包括：获取目标功能模块的测试用例集目标功能模块为目标DevOps平台中的功能模块；根据测试用例集，确定状态集；根据测试用例集中的每一个测试用例的发生概率，确定状态转移概率矩阵；根据测试用例集中的每一个测试用例在第一时刻的发生概率，确定初始概率分布；根据状态集、状态转移概率矩阵和初始概率分布，确定马尔科夫链模型；基于马尔科夫链模型，确定目标功能模块的调用执行效率。本发明实施例能够对Devops平台中各功能模块的调用执行情况，采用马尔科夫链方法进行评价分析，得到各个功能模块的调用执行效率。

Description

一种基于DevOps的性能评估方法、装置和电子设备
技术领域
本发明属于信息科技技术领域，具体涉及一种基于DevOps的性能评估方法、装置和电子设备。
背景技术
开发和运维(Development and Operations，DevOps)(其也称之为过程、方法与系统的统称)，包括自动化、架构设计等一系列软件工程的最佳实践，能够使得构建、测试以及发布软件更加快捷、频繁和可靠。
但是，相关技术中，对于基于DevOps的运维平台，在DevOps云原生转型过程中，由于不明确DevOps云原生转型过程中的各个功能模块的调用执行效率等，若要得出满足要求的DevOps运维平台，需要在DevOps云原生转型过程中对DevOps运维平台进行大量的调试，这样会增加DevOps云原生转型过程的整合难度和成本。
发明内容
本发明的目的是提供一种基于DevOps的性能评估方法、装置和电子设备。能够在DevOps云原生转型过程中评估DevOps运维平台中的各个功能模块的调用执行效率，该调用执行效率，可以用于确定调用执行效率最优或者局部最优的DevOps运维平台，从而降低了DevOps云原生转型过程的整合难度和成本。
为了解决上述技术问题，本发明是这样实现的：
第一方面，本发明提供了一种基于DevOps的性能评估方法，包括：
获取目标功能模块的测试用例集，其中，所述测试用例集中的测试用例覆盖所述目标功能模块在测试过程中的每个执行语句，所述目标功能模块为目标DevOps平台中的功能模块；
根据所述测试用例集，确定状态集；
根据所述测试用例集中的每一个测试用例的发生概率，确定状态转移概率矩阵；
根据所述测试用例集中的每一个测试用例在第一时刻的发生概率，确定初始概率分布；
根据所述状态集、所述状态转移概率矩阵和所述初始概率分布，确定马尔科夫链模型；
基于所述马尔科夫链模型，确定所述目标功能模块的调用执行效率。
第二方面，本发明还提供了一种基于DevOps的性能评估装置，包括：
第一获取模块，用于获取目标功能模块的测试用例集，其中，所述测试用例集中的测试用例覆盖所述目标功能模块在测试过程中的每个执行语句，所述目标功能模块为目标DevOps平台中的功能模块；
第一确定模块，用于根据所述测试用例集，确定状态集；
第二确定模块，用于根据所述测试用例集中的每一个测试用例的发生概率，确定状态转移概率矩阵；
第三确定模块，用于根据所述测试用例集中的每一个测试用例在第一时刻的发生概率，确定初始概率分布；
第四确定模块，用于根据所述状态集、所述状态转移概率矩阵和所述初始概率分布，确定马尔科夫链模型；
第五确定模块，用于基于所述马尔科夫链模型，确定所述目标功能模块的调用执行效率。
第三方面，本发明还提供了一种电子设备，该电子设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤。
第四方面，本发明还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤。
在本发明实施例中，获取目标功能模块的测试用例集，其中，所述测试用例集中的测试用例覆盖所述目标功能模块在测试过程中的每个执行语句，所述目标功能模块为目标DevOps平台中的功能模块；根据所述测试用例集，确定状态集；根据所述测试用例集中的每一个测试用例的发生概率，确定状态转移概率矩阵；根据所述测试用例集中的每一个测试用例在第一时刻的发生概率，确定初始概率分布；根据所述状态集、所述状态转移概率矩阵和所述初始概率分布，确定马尔科夫链模型；基于所述马尔科夫链模型，确定所述目标功能模块的调用执行效率。这样，能够对Devops平台中各功能模块的调用执行情况，采用马尔科夫链(简称：马氏链)方法，建立马尔科夫链模型，以采用该马尔科夫链模型根据各功能模块的调用执行情况进行执行效率的评价分析，得到各个功能模块的调用执行效率，这些调用执行效率可以用于辅助DevOps云原生转型，例如：根据该调用执行效率来优化DevOps云原生转型过程中各个功能模块的执行效率，以得到调用执行效率最优或者局部最优的DevOps平台，这样，基于DevOps平台中各个功能模块的调用执行效率可以降低DevOps云原生转型过程的整合难度和成本。
附图说明
图1是本发明提供的一种基于DevOps的性能评估方法的流程图；
图2是DevOps平台的管理框架示意图；
图3是本发明实施例中确定DevOps平台的健康度的流程图；
图4是本发明提供的一种基于DevOps的性能评估装置的结构示意图；
图5是本发明提供的一种电子设备的结构图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。
DevOps包括自动化、架构设计等一系列软件工程的最佳实践，能够使得构建、测试以及发布软件更加快捷、频繁和可靠。
以DevOps能力编排引擎-DORY为例，其亮点包括：
1、使用go语言实现，具有极高的执行效率和极低的资源消耗；
2、覆盖完整的过程与结果指标；
3、抽取步骤的关键执行信息，实现更精细的度量指标；
4、可以跟踪各类功能模块的步骤执行记录，掌控功能模块健康度。
本申请实施例中，针对DevOps云原生转型中整合难、要求高、成本高的问题，提出了一种辅助DevOps云原生转型的方法，能够提升DevOps云原生转型过程中的效率。
请参阅图1，是本发明实施例提供的一种基于DevOps的性能评估方法的流程图，如图1所示，该基于DevOps的性能评估方法可以包括以下步骤：
步骤101、获取目标功能模块的测试用例集，其中，所述测试用例集中的测试用例覆盖所述目标功能模块在测试过程中的每个执行语句，所述目标功能模块为目标DevOps平台中的功能模块。其中，功能模块的定义可以是逻辑结构或逻辑模块，其能够执行指定的逻辑处理或功能。
例如：如图2所示，目标DevOps平台中的功能模块可以包括以下至少一项：
(1)项目管理模块21，该项目管理模块通过Jira(一种项目与事务跟踪工具)进行需求管理、变更管理、缺陷管理和进度管理，且该项目管理模块还使用看板来进行项目的开发与协作。在应用中，DevOps平台通过对接Jira、同步看板和迭代、代码提交与Jira项目任务关联。
(2)持续集成模块22，具备多语言构建环境，用于自动化的编译和单元测试、代码质量扫描、生成介质并上传到介质库。
(3)持续测试模块23，从功能和性能等方面，在测试和预生产环境对介质库中的介质进行验证，并对通过验证的介质打标签。
(4)持续部署和发布模块24，通过Jenkins(Jenkins为一个开源软件项目，是基于Java计算机编程语言开发的一种持续集成工具，用于监控持续重复的工作)将持续测试模块已经通过测试的介质部署到测试、预发布和生产环境,并将通过测试验证的介质发布给用户，同时也具备一键回滚(即一键将数据恢复至上一次正确状态的行为)的能力。
(5)持续运维模块25，使用OpenFalcon(一种人性化的互联网企业级监控系统)和计算机辅助测试(Computer-Aided Test，CAT)分别来监控基础设施和业务的可用性，使用ELK(表示弹性搜索(Elasticsearch)、日志存储(Logstash)和Kibana这三种工具的统称)收集业务日志。
(6)度量反馈模块26，用于实现交付过程的结果指标以及过程指标的采集、存储和呈现，直观表现软件交付过程的效率和质量。
本发明实施例中，可以分别针对每一个需要进行执行效率评估的功能模块，分别执行步骤101至步骤106，为了便于说明，本发明实施例中，将目标DevOps平台中的任一个功能模块称之为目标功能模块，并以评估该目标功能模块的调用执行效率为例，对本发明实施例提供的基于DevOps的性能评估方法进行举例说明，在此不构成具体限定。
可选地，上述目标功能模块的测试用例集可以基于现有的方法得到，例如：基于逻辑覆盖和基本路径测试方法生成目标功能模块的测试用例集，以使该测试用例集能够覆盖目标功能模块的所有测试，确保该测试用例集才测试中，使得目标功能模块的每个执行语句至少执行一次。这样，这些测试用例构成了一个完整的测试实验样本空间，且其中的每个测试用例一定会发生，并且发生的概率相同。
步骤102、根据所述测试用例集，确定状态集。
其中，马氏链是满足下面两个假设的一种随机过程：
假设1：t+1时刻系统状态的概率分布只与t时刻的状态有关，与t时刻以前的状态无关；
假设2：从t时刻到t+1时刻的状态转移与t的值无关。
具体的，一个马氏链模型可表示为M＝(S,P,Q)，其中，各元的含义如下：
S是系统所有可能的状态(即目标功能模块的项目代码的各种可能的执行效果)所组成的非空的状态集，有时也称之为系统的状态空间，它可以是有限的、可列的集合或任意非空集。本文中假定S是可数集(即有限或可列)，且用小写字母i、j等来表示状态集S中的状态。是系统的状态转移概率矩阵。其中，pij表示系统在时刻t处于状态i，在下一时刻t+1处于状态j的概率，N是系统所有可能的状态的总数。对于任意i∈S，有
Q＝[q1，q2，…qn]是系统的初始概率分布，qi是系统在初始时刻处于状态i的概率，满足
本步骤中，基于测试用例集中的测试用例构成了一个完整的测试实验样本空间，且其中的每个测试用例一定会发生，并且发生的概率相同的特性，与马尔科夫链模型中的状态集S具有相似的特性，从而可以将测试用例集作为马尔科夫链模型中的状态集S。
具体地，可以把一个完全正确的逻辑结构或模块(目标功能模块)对应的状态集看成在时刻t处于的状态集，则状态集中的每一个状态对应一个测试用例，从而构成一个完整的满足马氏链模型的测试用例集；同样，把接下来要测试的逻辑结构或模块所处的状态看做下一时刻t+1处于的状态。
步骤103、根据所述测试用例集中的每一个测试用例的发生概率，确定状态转移概率矩阵。
本步骤中，根据测试用例集中的每一个测试用例的发生概率，来确定各个测试用例之间的状态转移概率，从而遍历测试用例集中的任意两个测试用例之间的状态转移概率，来确定马尔科夫模型中的状态转移概率矩阵P。
步骤104、根据所述测试用例集中的每一个测试用例在第一时刻的发生概率，确定初始概率分布。
本步骤中，根据某一时刻对应的测试用例集中的每一个测试用例的发生概率分布情况，来确定马尔科夫模型中的初始概率分布Q。
其中，假设Q＝[q1,q2,...,qn]，且P({qi})表示t时刻第i个测试用例发生的概率，则P({qi})满足以下条件：
P({q1})＝P({q2})＝…P({qk})＝1/k；
P({q1})+P({q2})+…+P({qk})＝1。
其中，P({qi})满足上述两个条件，可以表示：在t时刻，测试用例集中的每个测试用例全都发生，并且发生概率相同。
步骤105、根据所述状态集、所述状态转移概率矩阵和所述初始概率分布，确定马尔科夫链模型。
本步骤中，可以基于上述步骤102至步骤104中确定的S，P，Q确定完整的马尔科夫链模型M＝(S,P,Q)。
步骤106、基于所述马尔科夫链模型，确定所述目标功能模块的调用执行效率。
本步骤中，在完成马尔科夫链模型的建立后，可以基于该马尔科夫链模型来估计目标功能模块的调用执行效率。
作为一种可选的实施方式，所述基于所述马尔科夫链模型，确定所述目标功能模块的调用执行效率，包括：
基于所述马尔科夫链模型，按照第一预设评价指标对所述目标功能模块进行评价，得到所述目标功能模块的调用执行效率。
其中，第一预设评价指标可以是预先设置的用于评价调用执行效率的指标，例如，第一预设评价指标可以包括以下至少一项：
(1)响应时间：请求或者某个操作从发出的时间到收到服务器响应的时间的差值就是响应时间。请求可能经过的处理路径和节点，那么响应时间的计算方式就是所有路径消耗的时间和每个服务器节点处理时间的累加，通常是网络时间+应用程序的处理时间。
(2)每秒交易数(Transaction Per Second，TPS)：事务是自定义的某个操作或者一组操作的集合。该TPS标识系统每秒能够处理的交易和事务的数量，一般统计的是每秒处理的事务数。
(3)并发用户数：在真实的用户操作中，用户的每个相邻操作之间都会有一定的间隔时间,并发用户数是指系统可以同时承载的正常使用系统功能的用户总数量。
在实施中，并发用户又可以分为绝对并发用户和相对并发用户：
3-1)绝对并发，某个时间点同时一起向服务器发起的请求的并发用户数；
3-2)相对并发，一段时间内向服务器发出请求的并发用户总数。
(4)吞吐量：对于软件系统来说，“吞”进去的是请求，“吐”出来的是结果，而吞吐量反映的就是软件系统的“饭量”，也就是系统的处理能力，具体说来，就是指软件系统在每单位时间内能处理多少个事务/请求/单位数据等。吞吐量的大小由负载(如用户的数量)或行为方式来决定。
(5)资源使用率：常见的资源有中央处理器(central processing unit，CPU)占用率、内存使用率、磁盘输入/输出(Input/Output，I/O)、网络I/O。
(6)点击率：该指标反映客户端每秒向服务端提交的请求数。
本实施方式中，可以预先设置一些调用执行效率指标，以通过这些调用执行效率指标来反映功能模块的调用执行情况，进而可以采用马尔科夫链模型来按照该调用执行效率指标对目标功能模块的调用执行效率进行评价。
作为一种可选的实施方式，所述基于DevOps的性能评估方法还包括：
获取所述目标DevOps平台中的每一个功能模块的测试数据；
根据所述测试数据，按照第二预设评价指标对所述目标DevOps平台中的每一个功能模块进行评价，得到所述目标DevOps平台中的每一个功能模块的健康度；
根据所述目标DevOps平台中的每一个功能模块的目标权重，确定所述目标DevOps平台的健康度，其中，所述目标权重及对应的功能模块的健康度与所述目标DevOps平台的健康度的影响正相关。
其中，第二预设评价指标可以是健康度评价指标，在实施中，模块健康度评价指标的选择主要遵循SMART原则，该SMART表示：特有的(Specific)、可测量的(Measurable)、可实现的(Attainable)、有意义的(Relevant)和有时限的(Time bound)。
Specific，表示健康评价模型中的各可评价指标是明确的，不笼统的；
Measurable，表示健康评价模型中的各可评价指标是可以用数量来表示的；
Attainable，表示健康评价模型中的各可评价指标可以量化评估；
Relevant，表示健康评价模型中的各可评价指标与信息系统相关的，能够给信息运维工作提供参考有助于提升信息运维水平；
Time bound，表示健康评价模型中的各可评价指标是在特定时期内的，如果没有时间限制，所做的评估也就没有意义，无法给运维工作提供相关的支持。
例如，基于上述SMART原则，可以确定所述第二预设评价指标包括以下至少一项：
交付时间、自动化测试通过百分比、错误逃逸率、可用性、错误率、平均监测时间(Media Time To Diagnose，MTTD)、平均恢复时间(Mean Time To Repair，MTTR)。
选项一，对于快速发布代码，交付时间是一个非常关键的指标，该交付时间定义为从工作项开始到它被部署之间的时间。
选项二，自动化测试通过百分比可以用于反映代码更改导致测试中断的频率，由于DevOps严重依赖于自动化，所以跟踪自动化测试工作的好坏是一个DevOps指标。
选项三，错误(bug)逃逸率是DevOps一个很大的指标，用来跟踪这些bug在生产过程中经常发生的情况，基于该bug逃逸率可以在开始生产之前发现软件bug，能够快速地发现bug，并发布正确的代码。
选项四，可用性，根据应用类型以及部署方案，可能会有一些停机时间作为计划维护的一部分，根据跟踪各个功能模块的可用性，可以获知停机时间。当然，除了上述可用性之外，还可以更新所有计划外的停机。
选项五，在应用中跟踪错误率非常重要。它们不仅是质量问题的指示器，而且是与持续性能和正常运行时间相关的问题。好的异常处理最佳实践对于良好的软件是至关重要的。
选项六，平均监测时间MTTD可以用于评价发送故障的时间。在应用中，当问题发生时，重要的是你要快速地识别它们，而不希望在出现重大的部分或广泛的系统中断时，却找不到原因，即拥有强大的应用监控和良好的覆盖将有助于快速发现问题。
选项七，在发送故障后，通常需要快速的修复故障，而平均恢复时间MTTR这一指标可以帮助跟踪从故障中恢复需要多长时间。它通常是按小时计算的，可能是指工作时间，而不是时钟时间。拥有良好的应用程序监视工具可以快速识别问题并快速部署修复程序，这对减少MTTR非常重要。
其中，根据所述测试数据，按照第二预设评价指标对所述目标DevOps平台中的每一个功能模块进行评价，得到所述目标DevOps平台中的每一个功能模块的健康度，可以是按照现有技术中的综合赋值方法对功能模块的各个健康度评价指标进行赋值，从而得到各个功能模块的健康度。在实施中，基于综合赋值方法确定的各个功能模块的健康度，并不能准确反映目标DevOps平台的健康度。
本实施方式中，在获取目标DevOps平台中的每一个功能模块的健康度之后，还根据所述目标DevOps平台中的每一个功能模块的目标权重，对目标DevOps平台中的每一个功能模块的健康度进行融合，得到所述目标DevOps平台的健康度，这样，对于不同重要程度的功能模块，可以对应不同的目标权重，从而在根据该目标权重对目标DevOps平台中的每一个功能模块的健康度进行融合的过程中，能够突出一些重要的功能模块对目标DevOps平台的健康度的影响。
可选地，在所述根据所述目标DevOps平台中的每一个功能模块的目标权重之前，所述基于DevOps的性能评估方法还包括：
获取m个第二预设评价指标，m为大于1的整数；
按照所述m个第二预设评价指标，分别对所述目标DevOps平台中的每一个功能模块在n组测试中的健康度进行评价，得到n×m的无量纲化数据矩阵，n为大于1的整数；
采用熵值修正方法，根据所述n×m的无量纲化数据矩阵确定所述m个第二预设评价指标的熵权；
将所述m个第二预设评价指标按照熵权取值大小依次排列，得到目标熵权序列；
根据所述目标熵权序列中相邻的熵权的比值，确定所述m个第二预设评价指标的第一权重；
根据所述m个第二预设评价指标的第一权重，确定所述目标DevOps平台中的每一个功能模块的目标权重。
本实施方式中，采用熵值修正G1法确定综合权重，针对现阶段综合赋值方法存在的问题，通过熵值修正G1法确定综合权重，保证赋值的合理性和科学性。
具体过程如下：
步骤一：分n组实验，每一组实验都按照m个健康度评价指标(以下简称指标)来对待测功能模块的健康度进行描述，得到的无量纲化数据矩阵表示为：Y＝(yij)n×m。
首先，计算在第i次实验下的第j个被研究对象的指标所占的比重Fij，可以表示为以下公式：
其次，计算第j项指标的熵值Hj，可以表示为以下公式：
其中，当Fij＝0时，定义Hj＝0。
此时，第j项评价指标的权重的熵权可以表示为以下公式：
其中，0≤Wj≤1；
步骤二：将评价指标xi按照指标的熵值大小进行排序，得出第i次实验中的xj的目标熵权序列的关系式：x1＞x2＞…＞xm。
步骤三：由指标的熵值大小给出指标xj和xj-1的相对重要程度之比Wj-1/Wj的理性赋值为：
当Wj-1≥Wj时，ri＝Wj-1/Wj，反之ri＝1。
通过计算的ri值，可以求出第m个指标的权重Pm，为：
根据上述Pm，可以确定第m-1、m-2等指标的权重为：Pk-1＝riPk,k＝m,m-1,…2。
相对健康度HD＝F(交付时间,自动化测试通过百分比,bug逃逸率,可用性,错误率,MTTD,MTTR)＝F{g(z1,z2,z3,z4,z5,z6,z7)}，式中，z1、z2、……z7为选取的代表性指标(如：交付时间、自动化测试通过百分比、bug逃逸率、可用性、错误率、MTTD、MTTR)；g()为各指标的函数。
构造各指标的无量纲判断矩阵，应用熵值修正G1法，确定相对应的综合权重，则HD的公式转化为：
综上，上述根据所述目标DevOps平台中的每一个功能模块的目标权重，确定所述目标DevOps平台的健康度，可以是根据以下公式确定：
HD＝F{g(z1,z2,z3,z4,z5,z6,z7)}＝P1G1+P2G2+…P7G7
其中，P为综合权重向量；G为指标矩阵。
需要说明的是，在实施中，不同功能模块可以对应不同的综合权重向量，即相同的健康度评价指标在不同的功能模块中可以具有不同的权重(即第一权重)。此外，不同的功能模块，基于同一健康度评价指标进行评价所得到的指标值也可以不同。则对于某一个功能模块而言，其健康度可以是对应同一健康度评价指标的第一权重与指标值的加权求和。
当然，在实际应用中，在分别对每一个功能模块的综合权重向量与指标矩阵进行相乘后得到该功能模块的健康度之后，还可以对全部功能模块的健康度进行相加、归一化处理等进一步处理，以得到整个系统的健康度，在此并不限定整个系统的健康度的计算公式。
本实施方式中，先计算指标的熵值大小，通过熵值大小来确定相应指标的重要性程度之比，该重要性程度之比能够更加准确地反映数据本身所包含的实际信息量大小，巧妙地将指标数据信息和经验信息结合在一起，既能避免赋权重的主观性，又规避了主客观权重合成中权重的分配不准问题。经实验，基于上述健康度评价模型在模块健康度评估中的准确率可达到95％，精确度可达到90％，与其他评价模型相比均处于优势状态。此外，本实施方式中，对DevOps云原生转型中各功能模块的健康度情况采用数学建模技术进行评价分析，评价更加客观，更具有可推广性和可移植性。
需要说明的是，在实施中，除了采用熵值修正权重的方法来确定上述目标权重之外，该目标权重还可以是用户设置的，或者是通过其他方法确定的，在此不作具体限定。
下面以如图3所示实施例，对DevOps平台中的各个功能模块的健康度进行估计，并根据估计得到的DevOps平台中的全部功能模块的健康度以及各个功能模块的影响权重，来确定DevOps平台的健康度的流程进行具体说明，如图3所示，DevOps平台的健康度估计可以包括以下步骤：
步骤301、数据收集。
本步骤中，可以收集DevOps平台的各个功能模块在测试过程中的全部数据。
步骤302、特征信息提取。
本步骤可以基于步骤301中收集的数据，来确定DevOps平台的各个功能模块的各个健康度评价指标的指标值，例如：分别针对DevOps平台的每一个功能模块，确定交付时间、自动化测试通过百分比、bug逃逸率、可用性、错误率、MTTD、MTTR这7个健康度指标的取值。
步骤303、数据预处理。
本步骤中，可以对步骤302中提取的特征信息进行异常数据剔除、完整性对比等初步的数据处理，以提升特征信息的可靠性。
步骤304、将待测数据与历史数据进行比对。
本步骤中，通过将待测数据与历史数据进行必定对，可以获得每一个功能模块的当前数据与历史数据之间的差异程度，从而据此确定当前数据的可靠性，例如：若待测数据与历史数据的差异太大，可以重新获取待测数据，或者将历史数据与该待测数据进行融合，以更新待测数据。
步骤305、评价功能模块健康度。
本步骤中，可以根据步骤304处理后的健康度指标的取值，来确定DevOps平台的每一个功能模块的健康度，例如：通过以下公式来确定DevOps平台的每一个功能模块的健康度：
相对健康度HD＝F(交付时间,自动化测试通过百分比,bug逃逸率,可用性,错误率,MTTD,MTTR)＝F{g(z1,z2,z3,z4,z5,z6,z7)}。
步骤306、计算各个功能模块的影响权重。
本步骤中，可以采用熵值修正方法，根据DevOps平台的每一个功能模块的熵权来计算各个模块的影响权重(即目标权重)，具体可以参考上述实施方式中确定目标权重的解释，在此不再赘述。
步骤307、对各功能模块健康度进行合成，评价DevOps平台的健康度。
本步骤中，可以根据步骤306中得到的各个功能模块的影响权重来对步骤305中确定的各个功能模块的健康度进行整合，得到整个DevOps平台的健康度。
步骤308、输出DevOps平台的健康度评价结果。
本实施例中，针对Devops各模块被调用后的调用情况、出错情况、执行情况等多角度来评价其健康度情况，并对Devops平台中的每一个功能模块分别进行健康度评价，然后，根据模块的健康度及它的重要性来研究整个系统的健康度。
在本发明实施例中，获取目标功能模块的测试用例集，其中，所述测试用例集中的测试用例覆盖所述目标功能模块在测试过程中的每个执行语句，所述目标功能模块为目标DevOps平台中的功能模块；根据所述测试用例集，确定状态集；根据所述测试用例集中的每一个测试用例的发生概率，确定状态转移概率矩阵；根据所述测试用例集中的每一个测试用例在第一时刻的发生概率，确定初始概率分布；根据所述状态集、所述状态转移概率矩阵和所述初始概率分布，确定马尔科夫链模型；基于所述马尔科夫链模型，确定所述目标功能模块的调用执行效率。这样，能够对Devops平台中各功能模块的调用执行情况，采用马尔科夫链(简称：马氏链)方法，建立马尔科夫链模型，以采用该马尔科夫链模型根据各功能模块的调用执行情况进行执行效率的评价分析，得到各个功能模块的调用执行效率，这些调用执行效率可以用于辅助DevOps云原生转型，例如：根据该调用执行效率来优化DevOps云原生转型过程中各个功能模块的执行效率，以得到调用执行效率最优或者局部最优的DevOps平台，这样，基于DevOps平台中各个功能模块的调用执行效率可以降低DevOps云原生转型过程的整合难度和成本。
请参阅图4，是本发明实施例提供的一种基于DevOps的性能评估装置的结构图，如图4所示，该基于DevOps的性能评估装置400，包括：
第一获取模块，用于获取目标功能模块的测试用例集，其中，所述测试用例集中的测试用例覆盖所述目标功能模块在测试过程中的每个执行语句，所述目标功能模块为目标DevOps平台中的功能模块；
第一确定模块401，用于根据所述测试用例集，确定状态集；
第二确定模块402，用于根据所述测试用例集中的每一个测试用例的发生概率，确定状态转移概率矩阵；
第三确定模块403，用于根据所述测试用例集中的每一个测试用例在第一时刻的发生概率，确定初始概率分布；
第四确定模块404，用于根据所述状态集、所述状态转移概率矩阵和所述初始概率分布，确定马尔科夫链模型；
第五确定模块405，用于基于所述马尔科夫链模型，确定所述目标功能模块的调用执行效率。
可选的，第五确定模块405，具体用于：
基于所述马尔科夫链模型，按照第一预设评价指标对所述目标功能模块进行评价，得到所述目标功能模块的调用执行效率。
可选的，所述第一预设评价指标包括以下至少一项：
响应时间、每秒交易数TPS、并发用户数、吞吐量、资源使用率、点击率。
可选的，基于DevOps的性能评估装置400还包括：
第二获取模块，用于获取所述目标DevOps平台中的每一个功能模块的测试数据；
第一评价模块，用于根据所述测试数据，按照第二预设评价指标对所述目标DevOps平台中的每一个功能模块进行评价，得到所述目标DevOps平台中的每一个功能模块的健康度；
第六确定模块，用于根据所述目标DevOps平台中的每一个功能模块的目标权重，确定所述目标DevOps平台的健康度，其中，所述目标权重及对应的功能模块的健康度与所述目标DevOps平台的健康度的影响正相关。
可选的，基于DevOps的性能评估装置400还包括：
第三获取模块，用于获取m个第二预设评价指标，m为大于1的整数；
第二评价模块，用于按照所述m个第二预设评价指标，分别对所述目标DevOps平台中的每一个功能模块在n组测试中的健康度进行评价，得到n×m的无量纲化数据矩阵，n为大于1的整数；
第七确定模块，用于采用熵值修正方法，根据所述n×m的无量纲化数据矩阵确定所述m个第二预设评价指标的熵权；
排序模块，用于将所述m个第二预设评价指标按照熵权取值大小依次排列，得到目标熵权序列；
第八确定模块，用于根据所述目标熵权序列中相邻的熵权的比值，确定所述m个第二预设评价指标的第一权重；
第九确定模块，用于根据所述m个第二预设评价指标的第一权重，确定所述目标DevOps平台中的每一个功能模块的目标权重。
可选的，所述第二预设评价指标包括以下至少一项：
交付时间、自动化测试通过百分比、错误逃逸率、可用性、错误率、平均监测时间MTTD、平均恢复时间MTTR。
本发明实施例提供的基于DevOps的性能评估装置400能够实现图1所示的方法实施例实现的各个过程，且能够取得相同的有益效果，为避免重复，这里不再赘述。
可选的，如图5所示，本发明实施例还提供一种电子设备500，包括处理器501，存储器502，存储在存储器502上并可在所述处理器501上运行的程序或指令，该程序或指令被处理器501执行时实现如图4所示装置实施例中的各个模型实现的功能，且能达到相同的技术效果，为避免重复，这里不再赘述。
本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现如图1所示方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本发明实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。
上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。

Claims (10)

1.一种基于DevOps的性能评估方法，其特征在于，包括：
获取目标功能模块的测试用例集，其中，所述测试用例集中的测试用例覆盖所述目标功能模块在测试过程中的每个执行语句，所述目标功能模块为目标DevOps平台中的功能模块；
根据所述测试用例集，确定状态集；
根据所述测试用例集中的每一个测试用例的发生概率，确定状态转移概率矩阵；
根据所述测试用例集中的每一个测试用例在第一时刻的发生概率，确定初始概率分布；
根据所述状态集、所述状态转移概率矩阵和所述初始概率分布，确定马尔科夫链模型；
基于所述马尔科夫链模型，确定所述目标功能模块的调用执行效率。
2.根据权利要求1所述的方法，其特征在于，所述基于所述马尔科夫链模型，确定所述目标功能模块的调用执行效率，包括：
基于所述马尔科夫链模型，按照第一预设评价指标对所述目标功能模块进行评价，得到所述目标功能模块的调用执行效率。
3.根据权利要求2所述的方法，其特征在于，所述第一预设评价指标包括以下至少一项：
响应时间、每秒交易数TPS、并发用户数、吞吐量、资源使用率、点击率。
4.根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：
获取所述目标DevOps平台中的每一个功能模块的测试数据；
根据所述测试数据，按照第二预设评价指标对所述目标DevOps平台中的每一个功能模块进行评价，得到所述目标DevOps平台中的每一个功能模块的健康度；
根据所述目标DevOps平台中的每一个功能模块的目标权重，确定所述目标DevOps平台的健康度，其中，所述目标权重及对应的功能模块的健康度与所述目标DevOps平台的健康度的影响正相关。
5.根据权利要求4所述的方法，其特征在于，在所述根据所述目标DevOps平台中的每一个功能模块的目标权重之前，所述方法还包括：
获取m个第二预设评价指标，m为大于1的整数；
按照所述m个第二预设评价指标，分别对所述目标DevOps平台中的每一个功能模块在n组测试中的健康度进行评价，得到n×m的无量纲化数据矩阵，n为大于1的整数；
采用熵值修正方法，根据所述n×m的无量纲化数据矩阵确定所述m个第二预设评价指标的熵权；
将所述m个第二预设评价指标按照熵权取值大小依次排列，得到目标熵权序列；
根据所述目标熵权序列中相邻的熵权的比值，确定所述m个第二预设评价指标的第一权重；
根据所述m个第二预设评价指标的第一权重，确定所述目标DevOps平台中的每一个功能模块的目标权重。
6.根据权利要求4所述的方法，其特征在于，所述第二预设评价指标包括以下至少一项：
交付时间、自动化测试通过百分比、错误逃逸率、可用性、错误率、平均监测时间MTTD、平均恢复时间MTTR。
7.一种基于DevOps的性能评估装置，其特征在于，包括：
第一获取模块，用于获取目标功能模块的测试用例集，其中，所述测试用例集中的测试用例覆盖所述目标功能模块在测试过程中的每个执行语句，所述目标功能模块为目标DevOps平台中的功能模块；
第一确定模块，用于根据所述测试用例集，确定状态集；
第二确定模块，用于根据所述测试用例集中的每一个测试用例的发生概率，确定状态转移概率矩阵；
第三确定模块，用于根据所述测试用例集中的每一个测试用例在第一时刻的发生概率，确定初始概率分布；
第四确定模块，用于根据所述状态集、所述状态转移概率矩阵和所述初始概率分布，确定马尔科夫链模型；
第五确定模块，用于基于所述马尔科夫链模型，确定所述目标功能模块的调用执行效率。
8.根据权利要求7所述的装置，其特征在于，所述装置还包括：
第二获取模块，用于获取所述目标DevOps平台中的每一个功能模块的测试数据；
第一评价模块，用于根据所述测试数据，按照第二预设评价指标对所述目标DevOps平台中的每一个功能模块进行评价，得到所述目标DevOps平台中的每一个功能模块的健康度；
第六确定模块，用于根据所述目标DevOps平台中的每一个功能模块的目标权重，确定所述目标DevOps平台的健康度，其中，所述目标权重及对应的功能模块的健康度与所述目标DevOps平台的健康度的影响正相关。
9.一种电子设备，其特征在于，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至6中任一项所述的基于DevOps的性能评估方法中的步骤。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6中任一项所述的基于DevOps的性能评估方法中的步骤。
CN202210664639.4A 2022-06-13 2022-06-13 一种基于DevOps的性能评估方法、装置和电子设备 Pending CN117271278A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210664639.4A CN117271278A (zh) 2022-06-13 2022-06-13 一种基于DevOps的性能评估方法、装置和电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210664639.4A CN117271278A (zh) 2022-06-13 2022-06-13 一种基于DevOps的性能评估方法、装置和电子设备

Publications (1)

Publication Number Publication Date
CN117271278A true CN117271278A (zh) 2023-12-22

Family

ID=89206808

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210664639.4A Pending CN117271278A (zh) 2022-06-13 2022-06-13 一种基于DevOps的性能评估方法、装置和电子设备

Country Status (1)

Country Link
CN (1) CN117271278A (zh)

Similar Documents

Publication Publication Date Title
Li et al. Architectural technical debt identification based on architecture decisions and change scenarios
Borade et al. Software project effort and cost estimation techniques
Okamura et al. SRATS: Software reliability assessment tool on spreadsheet (Experience report)
Chu et al. Review of quantitative software reliability methods
Xia et al. Modeling and performance evaluation of BPEL processes: a stochastic-petri-net-based approach
Lin Analyzing the effect of imperfect debugging on software fault detection and correction processes via a simulation framework
US20120174231A1 (en) Assessing System Performance Impact of Security Attacks
Cinque et al. On the impact of debugging on software reliability growth analysis: a case study
Nafreen et al. Connecting software reliability growth models to software defect tracking
Saxena et al. Ranking of software reliability growth models: a entropy-ELECTRE hybrid approach
CN113742248A (zh) 一种基于项目测量数据进行组织过程预测的方法及系统
Liu et al. Software reliability forecasting: singular spectrum analysis and ARIMA hybrid model
Dong et al. Prognostics 102: efficient Bayesian-based prognostics algorithm in Matlab
US20090099821A1 (en) Model-diversity technique for improved proactive fault monitoring
Abdulshaheed et al. Mining historical software testing outcomes to predict future results
Kirschenmann et al. Decision dependent stochastic processes
CN117271278A (zh) 一种基于DevOps的性能评估方法、装置和电子设备
US20160004982A1 (en) Method and system for estimating the progress and completion of a project based on a bayesian network
CN112800037B (zh) 工程造价数据处理的优化方法及装置
Yang A Comparative Evaluation on the Performance of Finite Failure NHPP Software Reliability Model Based on Gamma Family Distribution
Kadam et al. Increases the Reliability of Software using Enhanced Non Homogenous Poisson Process (EHPP), Functional Point and Test Point Analysis
Wild et al. Determining software product release readiness by the change-error correlation function: on the importance of the change-error time lag
Singh et al. Prediction of software quality model using gene expression programming
Garg et al. A Method for Selecting a Model to Estimate Software Reliability at the Design Phase of Component-Based Real-Time System Development.
CN114398291B (zh) 一种软件回归测试影响域分析方法及系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination