没有合适的资源?快使用搜索试试~ 我知道了~
源代码分析技术自动检测软件性能回归
埃及信息学杂志21(2020)219使用源代码分析技术检测软件性能问题Salma Eida,Soha Makadyb,Manal Ismailaa埃及国立电子学习大学计算机和信息技术学院,埃及b埃及开罗大学计算机与人工智能学院计算机科学系阿提奇莱因福奥文章历史记录:收到2019年2020年2月2日修订2020年2月9日接受在线预订2020年保留字:性能回归性能感知单元测试版本控制系统源代码分析A B S T R A C T软件正在迅速发展。许多软件系统在短迭代中发布新版本。这些版本中的代码更改可能是增强、错误修复或新功能。虽然保留了其中的一些更改,但与以前的版本相比,软件的功能可能会意外地降低其在新版本中的性能,从而引入性能回归。开发人员很难找到导致性能下降的代码更改,尤其是大量的代码更改。检测性能退化的成本随着变化的大小增加而大幅增加。在本文中,我们提出了一种新的方法,自动识别潜在的代码变化,导致性能回归从一个系统版本到随后的源代码分析技术。这种方法是通过一个名为PerfDetect的原型工具实现的。PerfDetect检索特定应用程序源代码的新版本和以前版本中更改的源代码。PerfDetect自动:(a)识别新版本内的改变的源代码的相关单元测试用例,(b)使用各种负载来比较这些相关测试用例在新的和先前的系统版本上的执行时间,以检测性能回归,以及(c)分析相应源代码内的这种性能回归的根本原因。如果按照步骤(a)没有找到相关的单元测试,则在步骤(a)中使用为更改的代码自动生成的单元测试。所提出的方法进行了评估,四个开源应用程序,以评估其检测性能退化,并确定其根本原因的能力。评估结果表明,所提出的方法可以在较短的时间内自动检测性能回归的根本原因相比,替代性能检测方法。此外,PerfDetect检测每一次回归,这是其他性能回归技术所错过的,因为它依赖于源代码分析技术。©2020制作和主办由爱思唯尔B. V.代表计算机和人工智能学院-埃及开罗大学。这是一篇CC BY-NC-ND许可证下的开放获取文章(http://creative-commons.org/licenses/by-nc-nd/4.0/)上提供。1. 介绍性能回归是指与以前的版本相比,软件在新版本中执行缓慢的情况。两个系统*通讯作者。电 子 邮 件 地 址 : seid@eelu.edu.eg ( S. 开 斋 节 ) , s. fci-cu.edu.eg ( S.Makady),mismaeel@eelu.edu.eg(M. Ismail)。开罗大学计算机和信息系负责同行审查。版本,检测性能退化和识别它们的相关原因代码更改的成本费用增加主要有两个原因。首先,找到适当检查分析系统以检测性能回归的输入所需的工作量随着系统总体代码大小的增加而增加其次,由于两个系统版本之间可能存在大量代码更改,并且新系统版本中没有新添加代码的先前性能记录,因此识别导致(或促成)任何已识别性能退化的代码更改一些识别两个系统版本性能回归的方法要求存在性能感知单元测试[1];这是一个在应用程序中很难找到的要求。开发人员通常不愿意编写单元测试[2]。其他性能https://doi.org/10.1016/j.eij.2020.02.0021110-8665/©2020制作和主办由Elsevier B. V.代表开罗大学计算机和人工智能学院这是一篇基于CC BY-NC-ND许可证的开放获取文章(http://creativecommons.org/licenses/by-nc-nd/4.0/)。制作和主办:Elsevier可在ScienceDirect上获得目录列表埃及信息学杂志杂志主页:www.sciencedirect.com220S. Eid et al./Egyptian Informatics Journal 21(2020)219回归检测技术:(i)依赖于将随机输入应用于完整系统,以检测性能回归[3],(ii)要求存在两个正在运行的被分析应用程序版本[1,3]。这种方法不考虑利用感兴趣的应用程序的源代码来识别性能回归。我们提出了一种新的方法,用于检测性能回归,在两个版本的软件使用源代码分析。所提出的方法使用两个版本之间的代码差异来识别直接/间接执行修改后的代码部分的相关单元测试这样的测试识别过程使用静态和动态源代码分析技术来完成。在新系统版本和先前系统版本上执行已识别的相关测试这些测试用例的执行时间如果没有手动编写的相关单元测试,则使用自动生成的单元测试。所提出的方法是通过一个名为PerfDetect的原型工具。所提出的方法在以下各个方面取代替代性能回归检测技术:(i)不需要完全运行的应用程序,(ii)如果感兴趣,不探索应用程序的未改变部分,因此减少了性能回归检测时间,(iii)依赖于单元测试,与随机生成的测试输入相比,单元测试高度保证访问应用程序源代码的特定部分,随机生成的测试输入可能容易错过应用程序源代码的特定部分[3],以及(iv)与替代方法相反,利用源代码分析技术。本文的主要贡献如下:(1)一部小说方法来检测两个系统版本的性能回归,同时利用单元测试使用源代码分析技术。(2)实证评估所提出的方法进行真正的性能回归,在两个不同的版本,为四个开源应用程序,即:AgileFant,ApacheCommons数学,Apache Commons IO和Xalan。结果表明,我们提出的方法可以成功地识别性能回归和改进在四个系统。更重要的是,我们提出的方法依赖于更细粒度的单元测试,而不是随机生成的测试输入。因此,PerfDetect可以检测其他性能回归检测方法所遗漏的其他性能回归。本文件的结构如下。我们首先解释第二节中的问题陈述。第三节介绍了我们提出的方法,而第四节显示了我们的实验装置。第五节展示了我们的研究结果,而第六节讨论了剩余的问题。第七节总结了论文,同时指出了未来的研究方向。2. 问题陈述当前的方法旨在识别性能回归问题,并在源代码中分析其根本原因,这些方法在以下几个方面受到限制。(1)这种方法需要运行一个完整的测试套件来比较和检测两个版本之间的性能问题,这对于大型测试套件来说是一个非常耗时的过程。(2)现有的方法依赖于所分析的系统的执行跟踪的存在。这样的执行痕迹几乎不可能存在,特别是如果系统正在经历一个重大的变化,阻碍了一个完全运行的版本。此外,分析的质量依赖于这些跟踪的强度和代码覆盖率。(3)这种方法将被分析的系统视为黑盒可执行程序,而忽略了丰富的信息财富(4)现有方法忽略了新添加的特性,这些特性可能是间接影响另一段代码的性能回归的原因之一。目前,开发人员必须为所有系统运行一套完整的测试用例,这是一个非常耗时的过程,需要大量的测试套件。开发人员必须有一个完全运行的版本。使用的测试套件必须准确,以揭示性能回归。作为性能回归的一个例子,考虑我们有两个系统版本vi(当前版本)和vi-1(以前的版本)。当前版本有一些修改后的代码部分,与以前的版本不同。如图1所示,在当前版本Vi中,称为retrieveByName()的方法被修改,并且在类settingDAO中被称为getByName()的方法,而不是在类settingCashe中的get()方法。当软件工程师执行当前版本时,他们注意到当前版本Vi的执行时间与先前版本Vi-1相比增加。由于在当前版本中提交了所有代码更改,开发人员可能没有意识到此特定更改导致整个应用程序的执行时间增加。开发人员需要检查当前更改的源代码,以检查是否存在性能回归,并检测哪个代码部分负责此性能回归。仅依靠黑盒技术来寻找性能回归可能无法检测到这种方法导致性能回归。这样的失败归因于这样的事实,即这样的特定代码改变可能根本不会被随机化的输入执行。随机输入可能不覆盖此版本中的所有代码分支。或者,如果一些开发人员决定穷尽地运行应用程序的所有源代码来检测性能回归,则这样的任务将是繁忙的。这项任务需要覆盖给定应用程序源代码的所有分支;这是一项除了耗时之外,执行应用程序的所有这种未更改代码部分的执行是一种冗余活动,会延迟检测性能退化。3. 方法3.1. 概述我们的方法确定性能退化,其根本原因在两个系统版本。这种方法可以缓解(1)跨两个系统版本运行完整的测试套件以识别性能问题,这对于大型测试套件是极其耗时的过程; 2)依赖于被分析系统的执行跟踪的存在,这很难存在,特别是如果系统正在经历阻碍具有完整运行版本的重大改变时;3)依赖于所使用的输入的质量如果执行跟踪由执行完整系统场景的输入产生,则这样的输入可以忽略其修改导致性能降级的特定修改的源代码元素。因此,我们的方法利用不同的信息,以避免执行整个系统来检测性能问题。此类信息是(a)两个系统版本的版本控制信息,(b)两个系统版本中添加/修改的代码,(c)修改后的源代码及其相应测试套件之间的依赖关系。所提出的方法假设存在(a)具有至少一个先前版本的现有系统版本(将被用作S. Eid et al./Egyptian Informatics Journal 21(2020)219221←Vi-1ViFig. 1. 两个版本Vi-1和Vi之间的变化示例。(a)两个版本的完整源代码;(b)两个版本的JUnit测试;(c)两个版本的版本控制历史,如Git存储库中的项目如图2所示,该方法遵循这些步骤:(1)选择两个版本之间的改变的代码部分,(2)识别与当前版本内的改变的代码相关的测试用例(如果有的话),(3)如果没有相关的JUnit测试用例,则该方法生成JUnit测试用例并将它们的性能与参考版本进行比较,(4)根据前一步骤的结果分析性能问题,并使用这些信息来识别导致这种性能下降的源代码更改。3.2. 确定添加/更改的代码部分为了应用所提出的方法,一个原型工具命名为性能检测已经建成。所提出的方法的第一步是通过比较两个版本的源代码来确定代码的哪些部分被更改或添加。然后识别受这些变化影响的方法,以作为用于分析和检测性能回归的输入。算法1:检测-更改-代码输入:两个软件版本(vi-1,vi)输出:vi(M)中更改的方法列表1:F←比较两个版本的源代码2:对于所有的fjeF做3: 比较vi-1和vi中的源代码4:标记所有在方法中删除或添加的语句5:定义每个更改语句的方法m 6:M添加方法m7:结束8:返回M该第一步骤在算法Alg中表示。1 DETECT- CHANGED-CODE,获取当前版本的源代码(vi)和前一个(vi-1)作为输入。PerfDetect通过一些版本控制系统(例如,Git),保存每个版本及其更改历史。PerfDe- tect输出当前版本vi中所有更改的文件。PerfDetect比较两个版本中每个更改文件(fj)的源代码,以使用GitHub API[5]识别添加/更改的代码。图 3显示了(fj)中更改的代码部分之一的示例,v i-1中的语句(以红色突出显示)在v i中更改(以绿色突出显示)。PerfDetect像前面的例子一样分析每个更改的语句,以获得受更改影响的直接方法(m)。因此,PerfDetect将方法(m)添加到列表中(M)如图4所示。图4显示了跨两个系统版本的已识别的已更改方法的累积列表,如retrieveByName()方法。直接方法将作为输入方法,用于在以下步骤中检测性能回归。所提出的方法依赖于运行只与更改的方法相关的测试用例,而不是运行图二. 我们方法的工作流程。图三. 语句在当前版本和以前版本中发生了更改。完整的测试套件,以最大限度地减少大型测试套件的耗时过程。因此,识别列表(M)将用于在以下步骤中定位此类相关测试用例(参见第C节)。3.3. 相关测试用例的识别PerfDetect使用EclipseCallHierarchy插件以自动化的方式222S. Eid et al./Egyptian Informatics Journal 21(2020)219←←←JJJJJJ←←←1) business/impl/MenuBusinessImpl/constructBacklogMenuData()2) business/impl/PortfolioBusinessImpl/getPortfolioData()3) business/impl/SearchBusinessImpl/searchByReference()4) business/impl/SettingBusinessImpl/retrieveByName()5) business/impl/SettingBusinessImpl/storeSetting()6) model/WidgetCollection/getWidgets()7) Web/TeamAction/retrieveAll()8) model/Project/setRank()9) business/impl/DailyWorkBusinessImpl/setStoryRanks()10) business/impl/SearchBusinessImpl/taskListSearchResult()11) business/impl/SearchBusinessImpl/checkAccess().................见图4。受影响的变更方法的示例。[6]的文件。Eclipse Call Hierarchy插件用于查找方法的引用该步骤在Alg中表示。 2个IDENTIFY-RELEVANT-TEST-CASES,将变更方法列表(M)、两个系统版本(T)中的所有测试用例作为输入。在每个改变的方法(mj)中,PerfDetect识别(mj)的所有调用者方法,并通过以下方式之一来检测每个调用者方法(tdirect)是否是测试用例:(1)调用者方法具有JUnit 4@Test注释,(2)调用者方法的父类是TestCase类。算法的复杂度为O(n2)+ O(n2*CT),因为O(n2)是嵌套两个循环的复杂度,O(n2*CT)是测试用例的复杂度乘以嵌套两个循环的次数[40]。有时修改后的方法没有相关的测试用例原因有很多(a)没有调用者方法直接或间接地调用它们,(b)调用它们的方法没有测试用例,或者(c)调用者方法位于第三方或标准库中。Eclipse Call Hierarchy插件依赖于静态分析来找到调用者方法[15]。这个插件涉及检查源代码,并根据收集的有关代码的数据对未来进行推断,静态分析的一个局限性是,像Eclipse Call Hierarchy这样的自动化工具会产生误报的调用者方法(即,candi- date调用者方法实际上在运行时不执行这种局限性导致PerfDetect有时会检测到与修改后的方法相关的假阳性例如,如果Java接口I中存在修改的方法m,则该方法将在该接口的所有子类中被修改(例如,C1、C2和C3)。对于该方法,PerfDetect检测C1,C2和C3中所有方法出现的所有相关测试为了消除这种误报,PerfDetect需要通过使用动态分析[7-10]进一步确保所识别的相关测试用例是否实际/动态地调用了正确子类或另一个子类中的修改方法动态分析基于在运行测试用例时,避免报告错误的相关测试算法2:身份相关测试案例输入:变更方法列表(M),所有测试用例(T)输出:相关测试用例列表(T相关)1:对于所有mjsM do2:获取调用此mj的所有调用方方法3:当相关测试用例未找到时,4:如果调用者方法是测试用例(直接测试用例)(tdirect)5:执行测试用例(t直接)6:if t直接调用目标方法7:T相关t直接第八章:休息9:如果结束10:如果结束11:结束时12:如果mj的相关T为空13:tindirect←identify indirect relevant test case(mj)14:Trelevanttindirect15:如果结束第16章:结束17:返回T相关在检测到每个修改的相关JUnit测试用例与变更方法无关的病例(假阳性),并验证静态代码分析结果。PerfDetect使用静态和动态分析,以确保它分别选择每个修改方法的正确相关测试用例3.4. 分析更改的代码导致性能下降单元测试只关注功能测试,通常使用最少的测试用例集来测试组件的功能。为了正确检测性能回归并获得最佳结果,我们提出的方法需要性能感知单元测试,这些单元测试是针对性能要求而开发的单元测试,而不仅仅是针对功能性测试用例,这些测试用例可能对目标应用程序上下文中的代码性能至关重要[1]。因此,我们使用ContiPerf[11]或JUnitPerf[12]等工具修改相关测试用例以评估性能。这两种工具都是软件工程师用来评估JUnit测试性能的。这是通过为每个JUnit测试构建这些工具来完成的,以增加执行单元测试用例的工作负载(用户数量)。为了测量每个修改后的方法的执行时间,我们使用了像JProfiler[13]这样的工具。JProfiler是一个全功能的Java分析工具(分析器),致力于分析J2SE和J2EE应用程序,将CPU,内存和线程分析结合在一个应用程序中。方法,针对两个系统版本,确定相关测试案件属于两类之一。(1)直接调用修改方法的直接测试用例(tdirect),以及(2)间接测试用例(tindi-算法3:执行相关测试用例rect)调用其他源代码方法,这些方法调用修改后的方法. PerfDetect通过检查更改的方法(mj)是否具有相关的直接测试用例开始。如果没有找到相关的直接测试用例,PerfDetect搜索相关的间接测试用例。PerfDetect输出列表中的所有相关测试用例,无论是直接测试用例还是间接测试用例(T相关)。计算算法的复杂度取决于所选择的相关测试用例的复杂度(参见算法2中的第5行)。这种相关测试用例的复杂性基于所选测试用例的内容而变化。因为我们不能确定这样的测试用例的复杂性,直到我们运行的算法和执行这些测试。因此,我们假设每个执行的测试用例的复杂度是CT。因此,com-输入:相关测试用例列表(T相关)输出:导致性能回归的变更列表(结果)1:对于所有的tjsTdo2: tirunt inv3: ti+1runt inv4:tdj ti+1-ti其中tdje差分执行时间列表(TD)5:结束6:结果顺序TD7:返回结果我我S. Eid et al./Egyptian Informatics Journal 21(2020)219223在最后阶段,Alg。3 EXECUTE-RELEVANT-TEST-CASE将相关测试用例列表作为输入,并输出导致性能回归的更改列表。PerfDetect通过每种改进方法的相关单元测试用例,刻画了不同工作负载下两个版本(tij,ti+1j然后计算两个版本之间的执行时间差(tdj)。最后,PerfDetect根据以下条件对所有更改的方法的执行时间差异进行排序:执行时间的差异;更高的差异是导致性能回归的原因[1]。3.5. 为更改的代码部分对于没有相关测试用例的修改方法,PerfDe- tect为直接或间接没有相关测试用例的更改代码生成新的测试用例PerfDetect 通过Evosuite[14]利用遗传算法生成测试用例,以揭示两个系统版本之间的任何性能回归Evosuite采用了一种新的混合方法,可以生成和优化具有不同覆盖标准的测试用例,如单个语句,分支,输出和突变测试。Evosuite的目标是生成带有断言的测试用例,以帮助开发人员检测与预期行为的偏差。该目标与PerfDetect不同,PerfDetect的目标是检测性能变化行为。PerfDetect依赖Evosuite为Java代码编写 的 类 生 成 JUnit 测 试 用 例 一 旦 这 些 测 试 由 EvoSuite 生 成 ,PerfDetect应用上述步骤(参见第D节),该步骤用于使这些生成的测试用例成为性能感知测试,以便使它们能够检测性能回归。4. 评价4.1. 研究问题RQ1:PerfDetect能否识别导致性能下降的更改代码部分RQ2:与其他方法相比,PerfDetect在推荐导致性能下降的更改代码部分方面有多好?为了回答RQ 1,PerfDetect被应用于具有不同性能回归问题的四个开源系统,以评估其检测性能回归的能力(参见第V. A、V. B、V.C和V.D节)。在评价中遵循三个步骤首先,识别两个系统版本中所有更改的源代码。第二,通过两个版本确定每个更改代码的相关测试用例。第三,使用不同的工作负载(5、10、15、20和25个用户)执行每个测试用例,以分析所识别的更改每个工作负载运行五次,然后计算每个工作负载运行五次的平均值,以获得每个测试用例中每个工作负载的稳定结果。在评估中,四个开源系统与其手动编写的单元测试一起使用,以使用我们的方法检测性能回归(参见第V. A、V.B、V. C和V.D节)。此外,其中一个系统(Commons Math)与自动生成的单位一起使用(见第五.F节)。该比较是针对四个最初选择的开源系统中的两个进行的4.2. 受试者AUT我们在四个实际应用程序上评估了PerfDetect,这四个实际应用程序是 Apache Commons Mathematics Library ( Commons MathV2.13 ,V2.24 ),Apache Commons IO(V2.05 ,V2.16 )和Xalan(V2.7.17,V2.7.28)。敏捷软件是一个开源的Web应用程序,用于帮助软件工程师更快地管理敏捷软件开发。Agile- fant部署在服务器核心i5中,使用Tomcat7.0.47作为Web服务器环境,MySQL作为后端数据库。CommonsMath是一个轻量级的数学和统计组件库,用于解决Java编程语言中无法解决的常见问题。Commons IO是一个实用程序库,用于帮助开发人员实现输入和输出功能。Xalan是一个可编程处理器,它提供了包括Java在内的不同语言。所有应用程序都是用Java编写的,并有自己的测试用例。测试人员Commons Maths和Commons IO的测试用例使用JUnit编写Xalan在某些版本中有性能测试套件4.3. 设置环境Commons Math[18]、Commons IO[19]和Xalan[20]应用程序的版本位于版本控制系统(Git Repository)[4]中。该方法适用于任何基于Java 的 软 件 系 统 和 纯 JUnit 4 测 试 , 无 需 任 何 其 他 框 架 ( 如EasyMock)。EasyMock用于为接口提供模拟对象,方法是动态生成这些对象,可以将虚拟功能添加到可以在单元测试中使用的模拟对象。PerfDetect需要测试真实场景对于每个分量,没有任何伪数据。因此,PerfDetect测试单元测试用例的性能及其影响集,而不仅仅是那些测试功能。这样做是为了获得影响集中每个方法的实际执行时间,从而确定可能对目标应用程序上下文中的代码性能至关重要的情况。所以EasyMock与我们的方法不一致。5. 实证结果本节分析了四个真实Java应用程序的结果,这些应用程序验证了本文所介绍的方法。5.1. 检测性能回归本节分析了测试后两个系统版本(v3.2和v3.3)中修改代码的经验结果分析了49个变化的方法,包括10个增加的方法,3个删除的方法,36个修改的方法,无论是从旧版本还是新版本。这是通过(1)识别在两个系统版本之间已经改变的源代码差异,(2)使用eclipse的调用者层次结构找到代码差异的相关测试用例,(3)测试,使用我们的方法检测性能回归(请参见第五.E节)。对于该系统,Apache Commons Math,评估表明,我们可以使用手动编写的单元测试和自动生成的单元测试来检测相同的性能回归。为了回答RQ 2,将通过Perf-Detect检测到的性能回归与通过其他方法检测到的性能回归进行比较,以评估PerfDetect结果1https://github.com/Agilefant/agilefant/tree/v3.2。2https://github.com/Agilefant/agilefant/tree/v3.3。3https://github.com/apache/commons-math/tree/MATH_2_1。4https://github.com/apache/commons-math/tree/MATH_2_2。5https://github.com/apache/commons-io/blob/commons-io-2.0。6https://github.com/apache/commons-io/blob/commons-io-2.1。7https://github.com/apache/xalan-j/tree/xalan-j_2_7_1。8https://github.com/apache/xalan-j/tree/xalan-j_2_7_2224S. Eid et al./Egyptian Informatics Journal 21(2020)219表1变更了在测试用例中直接相关的方法方法添加的行联系我们测试用例1 business/impl/MenuBusinessImpl/constructBacklogMenuData()1022 business/impl/PortfolioBusinessImpl/getPortfolioData()22223 business/impl/SearchBusinessImpl/searchByReference()1184 business/impl/SettingBusinessImpl/retrieveByName()1115 business/impl/SettingBusinessImpl/storeSetting()0116 model/WidgetCollection/getWidgets()1117 web/TeamAction/retrieveAll()10218 model/Project/setRank()1139 model/Task/setRank()111610 model/WhatsNextEntry/setRank()112表2变更了在测试用例中具有间接相关性的方法方法添加的行联系我们测试用例11 business/impl/DailyWorkBusinessImpl/setStoryRanks()272512 business/impl/SearchBusinessImpl/taskListSearchResult()21413 business/impl/SearchBusinessImpl/checkAccess()145914 business/impl/TransferObjectBusinessImpl/getBacklogDataRecurseNames()11815 web/UserAction/getTeamMembers()164transfer/PortfolioTO/getRankedProjects()1162transfer/PortfolioTO/getUnrankedProjects()1162使用JPro-filer和ContiPerf测量每个相关测试用例的执行时间。PerfDetect使用Github API识别两个版本中添加/更改的代码。初步结果是49个变化的方法,包括10个增加的方法,3个删除的方法,36个修改的方法,无论是从旧版本还是新版本。对两个系统版本中每种改进方法的相关测试用例进行检测的结果表 明 , 在 JUnit 测 试 用 例 中 , 大 多 数 JUnit 测 试 用 例 使 用 的 是EasyMock框架,这对检测性能回归没有帮助。我们将测试用例转换为单元测试用例,而不使用Mocking[21,22]来删除任何虚拟数据并获得真实结果。有些修改的方法没有直接的测试用例,但是有一个调用者方法,它有一个相关的测试用例,我们间接地将它用作相关的测试用例。识别相关测试用例的结果是17个方法有测试用例,其中10个直接测试用例如表1所示,7个间接测试用例如表2所示,18个方法没有测试用例,这表1和表2列出了3.3版中变更的方法列表,并指出了每个变更方法中添加和删除的行数以及每个方法的相关测试用例数量。在没有Easy- Mock的情况下将任何测试用例转换为JUnit测试用例之后,我们为每个单元测试用例添加ContiPerf工具,通过增加执行单元测试用例的用户数量来增加工作量。我们使用JProfiler来测量每个修改方法的执行时间,通过其单元测试用例,在两个系统版本中具有不同的工作负载。为了检测导致性能下降的方法变更,我们获得了两个版本中不同工作负载(用户数)下每个变更的相关测试用例一般来说,vi中具有较长总执行时间的一个更改更有可能触发性能下降,并导致两个版本中执行时间之间的差异更大。图5显示了两个不同版本中每个已更改方法两次释放的毫秒数。如结果所示,只有那些带有红色文本的是性能回归的嫌疑人(1,4,5,13)。在两个版本的平均执行时间上,这些改变的方法图中绿色文本的其他变更方法。 5接近于零,这表明vi-1的执行时间接近vi-1,因此这些方法被认为不太像方法(1,4,5,13)那样导致性能回归。本图中提到的所有变更方法的方差均为正值表1和表2中的方法(2,3,6,8,15)的方差具有负值,这表明执行时间vi小于vi-1的执行时间,因此这些方法具有从vi到1到vi的性能改进。5.2. 在Apache Commons Math中检测性能回归Apache Commons Math是我们用来评估我们的方法的第二个应用程序。在本节中,我们分析了通过两个版本(v2.1和v2.2)检测性能回归问题的结果。2010年,Commons Math开发人员提交了一个新的代码版本(v2.2),其中隐藏了导致性能下降的代码部分。这个问题在2011年被发现并报告了9次。这个问题花了很长的时间,大约一年的时间(2012年),直到开发人员可以检测到导致性能回归的代码部分,并解决它。我们在本文中提出的方法的目标是帮助开发人员更快,更早地检测性能回归。我们这里的设置是不同的;除了增加工作负载之外,我们还增加了每个测试单元测试用例中使用的数据集的大小假设性能感知单元测试可用,并且数据集大小很大,我们将我们的方法应用于公共数学代码存储库,每个新代码部分都提交到存储库。我们的方法比较了上一个版本2.2和上一个版本2.1,检测到25种方法,包括9种添加的方法和16种改变的方法,如表3和表4所示。这两个表表示在2.2版中已更改的方法的列表,并指示添加和删除的行数工作量。x轴表示不同的工作负载(数量y轴表示执行时间的方差9https://issues.apache.org/jira/browse/MATH-578网站。S. Eid et al./Egyptian Informatics Journal 21(2020)219225图五.通过x轴表示的不同工作负载(用户数量),在y轴表示的具有正值的变更方法中执行时间的差异报告的两个版本v3.2和v3.3的执行时间表3更改了Commons Math.中具有相关测试用例的方法方法添加的行联系我们测试用例1 src/main/org/apache/commons/math/stat/descriptive/rank/Percentile/evaluate(double[],int,int,double)1683表4更改了Commons Math.中具有间接相关测试用例的方法。方法添加的行联系我们测试用例1 src/main/org/apache/commons/math/stat/descriptive/moment/FirstMoment/copy1022 src/main/org/apache/commons/math/stat/descriptive/moment/GeometricMean/copy1033 src/main/org/apache/commons/math/stat/descriptive/moment/Kurtosis/copy1024 src/main/org/apache/commons/math/stat/descriptive/moment/Mean/copy1035 src/main/org/apache/commons/math/stat/descriptive/moment/SemiVariance/copy1026 src/main/org/apache/commons/math/stat/descriptive/moment/Skewness/copy1027 src/main/org/apache/commons/math/stat/descriptive/moment/StandardDeviation/copy1028 src/main/org/apache/commons/math/stat/descriptive/moment/Variance/copy5039 src/main/org/apache/commons/math/stat/descriptive/rank/Max/copy10310 src/main/org/apache/commons/math/stat/descriptive/rank/Min/copy10311 src/main/org/apache/commons/math/stat/descriptive/rank/Percentile/copy40212 src/main/org/apache/commons/math/stat/descriptive/summary/Product/copy10213 src/main/org/apache/commons/math/stat/descriptive/summary/Sum/copy10314 src/main/org/apache/commons/math/stat/descriptive/summary/SumOfTime/copy10315 src/main/org/apache/commons/math/stat/descriptive/summary/SumOfSquares/copy10316 src/main/org/apache/commons/math/stat/descriptive/moment/FirstMoment/copy102在每个变更的方法中,以及每个方法的相关测试用例的数量表3显示只有一个被改变的方法,有3个相关的测试用例直接调用它(直接相关的测试用例)。表4显示了15个改变的方法,每个方法都没有相关的测试用例直接调用它,但是有一个测试用例通过另一个方法调用它(间接相关的测试用例)。我们的方法观察到,以下称为Per- centile/evaluate(double[],int,int,double)的方法是v2.2中更改的方法之一,删除了9行,添加了17 有3个直接的测试用例调用这个方法,其中一个在图中。第6(a)段。 在执行测试用例后,我们观察到两个版本在不同工作负载上的执行时间差异非常小,接近于0,如图所示。 7(a). 我们注意到数据集值很小,如图中红色标记的线。 6(a),当我们用大数据集值修改输入测试用例时,如图4中的第4行(绿线)。 6(b),执行时间的差异增加,如图所示。 7(b). 执行时间的这种较大差异表明性能回归具有较大的数据集。这些结果表明,数据集的大小和对源代码的分析在检测性能回归方面是有效的5.3. 在Apache Commons IOApache Commons IO是我们用来评估我们的方法的第三个应用程序在本节中,我们分析了两个版本(v2.0和v2.1)的性能比较结果版之前2.1特别是从版本v1.1开始,Commons IO的开发人员在类FileUtils中创建了一个名为readFileToByteArray()的新方法,该方法在类IOUtils中被称为另一个名为toByteArra
下载后可阅读完整内容,剩余1页未读,立即下载
![pptx](https://img-home.csdnimg.cn/images/20210720083543.png)
![](https://img-home.csdnimg.cn/images/20210720083646.png)
![application/msword](https://img-home.csdnimg.cn/images/20210720083327.png)
![-](https://csdnimg.cn/download_wenku/file_type_column_c1.png)
![-](https://csdnimg.cn/download_wenku/file_type_lunwen.png)
![-](https://csdnimg.cn/download_wenku/file_type_lunwen.png)
![-](https://csdnimg.cn/download_wenku/file_type_column_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://profile-avatar.csdnimg.cn/default.jpg!1)
cpongm
- 粉丝: 4
- 资源: 2万+
上传资源 快速赚钱
我的内容管理 收起
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助
![](https://csdnimg.cn/release/wenkucmsfe/public/img/voice.245cc511.png)
会员权益专享
最新资源
- BSC关键绩效财务与客户指标详解
- 绘制企业战略地图:从财务到客户价值的六步法
- BSC关键绩效指标详解:财务与运营效率评估
- 手持移动数据终端:常见问题与WIFI设置指南
- 平衡计分卡(BSC):绩效管理与战略实施工具
- ESP8266智能家居控制系统设计与实现
- ESP8266在智能家居中的应用——网络家电控制系统
- BSC:平衡计分卡在绩效管理与信息技术中的应用
- 手持移动数据终端:常见问题与解决办法
- BSC模板:四大领域关键绩效指标详解(财务、客户、运营与成长)
- BSC:从绩效考核到计算机网络的关键概念
- BSC模板:四大维度关键绩效指标详解与预算达成分析
- 平衡计分卡(BSC):绩效考核与战略实施工具
- K-means聚类算法详解及其优缺点
- 平衡计分卡(BSC):从绩效考核到战略实施
- BSC:平衡计分卡与计算机网络中的应用
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035111.png)
安全验证
文档复制为VIP权益,开通VIP直接复制
![](https://csdnimg.cn/release/wenkucmsfe/public/img/green-success.6a4acb44.png)