申请/专利权人：华为技术有限公司

申请日：2017-05-02

公开（公告）日：2020-11-27

公开（公告）号：CN109416653B

主分类号：G06F11/07(20060101)

分类号：G06F11/07(20060101)

优先权：

专利状态码：有效-专利权的转移

法律状态：2022.02.25#专利权的转移;2020.11.27#授权;2019.03.26#实质审查的生效;2019.03.01#公开

摘要：本发明提供了一种对包括多个物理实体的系统进行分析的过程，所述多个物理实体执行交互软件应用以提供多种服务。所述过程包括：为所述软件应用确定单元测试，其中，至少部分所述软件应用已被分配不止一个单元测试，若某个应用不可用，则分配给所述应用的单元测试失败。将所述确定的单元测试映射到所述多个服务以建立数据结构，其中，所述数据结构指示在某项服务不可用时，哪些单元测试失败。然后，执行所述映射的单元测试的子集以分析所述系统中的服务的可用性，其中，所述子集的成员在执行过程中基于所述子集中的在前单元测试是失败还是通过而动态确定。

主权项：1.一种计算机可读介质，其特征在于，存储用于对具有多个物理实体的系统进行分析的计算机可读指令，所述多个物理实体执行一个或多个交互软件应用以提供多种服务，执行所述计算机可读指令会使所述系统进行以下操作：关闭第一服务，并执行选择的单元测试以确定由于所述第一服务不可用而导致失败的第一单元测试；启动所述第一服务；关闭第二服务，并执行所述选择的单元测试以确定由于所述第二服务不可用而导致失败的第二单元测试；以及启动所述第二服务，并执行所述第一和第二单元测试的子集以分析所述系统，其中，所述子集的成员在执行过程中基于所述子集中的在前单元测试是失败还是通过而动态确定。

全文数据：选择单元测试进行系统分析技术领域本发明涉及对具有多个物理实体的系统进行分析，所述多个物理实体执行交互软件应用以提供多种服务。本发明尤其涉及选择单元测试以进行分析。背景技术具有执行交互软件应用的多个物理实体的系统，例如云平台，可通过包括多个联网计算机来实施。每台计算机也可称为“服务器”均向用户控制的客户端提供具有各种功能的服务。随着处理能力、网络以及存储技术的提升，这些系统变得越来越强大，也变得越来越复杂。由于复杂性的增加，对有效地诊断系统故障的要求也越来越高。可使用包括多个单元测试的测试套件来验证软件应用，这些单元测试作为软件开发过程的一部分进行开发，其目的在于，结合关联控制数据，有针对性地独立测试软件应用的最小可测试部件，也称为单元。执行单元测试能够非常有效地检验软件开发过程中代码的集成情况，并且，执行单元测试可验证开发人员对代码所做的修改，从而确保代码质量。发明内容具有多个物理实体的系统中的单元测试通常不会提供任何有关无响应或故障服务的信息，其中，所述多个物理实体执行提供多种服务的交互软件应用。相反，执行单元测试后会生成一个通过的以及失败的测试的清单。该清单能够帮助定位软件故障或者发现各代码模块的问题，然而，该清单本身无法用于诊断故障服务。另外，可能存在大量可用单元测试，随着代码库的不断增加，单元测试的数量可能进一步增加。因此，若要执行所有可用单元测试，耗时可能很长。因此，系统操作员通常会定制测试来诊断故障服务。但是，如果系统不断发展，频繁地更新和修改，那么定制化的测试常常会过时。因此，如每次发行新的软件版本时，这些测试也需随之不断进行修改更新。这种方法对于操作员来说成本很高，因为操作员需耗费大量资源来保持服务诊断的详尽和及时。因此，需要另一种成本较低的方法来诊断具有执行交互软件应用的多个物理实体的系统中的故障服务。根据本发明的第一方面，提供了一种计算机可读介质，所述计算机可读介质存储有计算机可读指令，用于对具有多个物理实体的系统进行分析，所述多个物理实体执行一个或多个交互软件应用以提供多种服务，执行所述计算机可读指令会使所述系统进行以下操作：关闭第一服务，并执行选择的单元测试以确定由于所述第一服务不可用而导致失败的第一单元测试；关闭第二服务，并执行所述选择的单元测试以确定由于所述第二服务不可用而导致失败的第二单元测试；以及启动所述服务，并执行所述第一和第二单元测试的子集以分析所述系统，其中，所述子集的成员在执行过程中基于所述子集中的在前单元测试是失败还是通过而动态确定。在此需要说明的是，本说明书和权利要求中所使用的术语“物理实体”尤其是指联网计算机，其中，计算机可包括处理器、存储器以及网络接口。另外，需要说明的是，本说明书和权利要求中所使用的术语“交互软件应用”尤其是指使用对方来执行某一操作的软件应用。例如，一个软件应用指示另一软件应用来执行某一操作，并等待所述操作被执行。此外，需要说明的是，本说明书和权利要求中所使用的术语“服务”尤其是指流程，客户端可自发地调用所述流程，并且所述流程例如向所述客户端或第三方提供数据，其中，所述数据基于所述客户端的请求。另外，需要说明的是，本说明书和权利要求中所使用的术语“失败”和“通过”尤其是指单元测试确定的失败或通过。即，若某项服务关闭，而单元测试通过，则所述单元测试无法用于确定所述服务是否可用。另一方面，若某项服务关闭且单元测试失败，则所述单元测试能够用于确定所述服务是否可用。因此，可用单元测试即，软件开发过程中开发的单元测试可以用于诊断不可用服务。在所述第一方面的第一种可能实现形式中，所述执行的单元测试对应于决策树中的路径上的节点，所述决策树中的叶子指示所述系统中的不可用服务。在此需要说明的是，本说明书和权利要求中所使用的术语“决策树”尤其是指类似于树的决策图表或模型以及所述决策的可能结果，其中，所述决策与单元测试失败还是通过有关，所述结果与服务被假定为可用还是不可用有关。因此，只需执行相关的单元测试，即，必须执行才能确定服务是否可用的单元测试。在所述第一方面的第二种可能实现形式中，所述路径上的节点根据所述对应的单元测试能够检测到的不可用服务的数量与执行所述单元测试所需的资源量的比值来进行排序。在此需要说明的是，本说明书和权利要求中所使用的术语“执行所述单元测试所需的资源量”尤其是指一个单元测试所需要的处理资源量或者处理时间。由于优先执行产生较多信息耗费较少资源的单元测试，因此，能够提升整体性能。在所述第一方面的第三种可能实现形式中，所述计算机可读介质存储有计算机可读指令，执行所述计算机可读指令会使所述系统进行以下操作：对可用单元测试调用的函数指派相关度得分；以及去选以下情况中的可用单元测试：仅调用相关度得分低于阈值的被忽略函数；或者仅调用相关度得分大于或等于所述阈值的函数，所述函数同时也被所述选择的单元测试中的其它单元测试所调用。在此需要说明的是，本说明书和权利要求中所使用的术语“函数”尤其是指一种用于执行单元测试的支持方法。因此，可对单元测试进行筛选以避免执行不相关的或冗余的单元测试。在所述第一方面的第四种可能实现形式中，所述相关度得分基于单元测试集合中的所述单元测试所进行编码的文件中调用所述函数的次数。因此，函数的相关度可基于所述函数的使用唯一性来进行判断。在所述第一方面的第五种可能实现形式中，所述单元测试集合中的所述单元测试所进行编码的文件中调用所述函数的次数越多，所述相关度得分越低。因此，可假定频繁调用的函数的重要性小于不常调用的函数。在所述第一方面的第六种可能实现形式中，所述计算机可读介质存储有计算机可读指令，执行所述计算机可读指令会使所述系统去选可用单元测试，其中，所述可用单元测试仅调用还被所述选择的单元测试中的其它单元测试调用的函数。因此，可以避免选择冗余单元测试。在所述第一方面的第七种可能实现形式中，所述计算机可读介质存储有计算机可读指令，执行所述计算机可读指令会使所述系统去选性能得分低于其它单元测试的可用单元测试。因此，由于调用同一相关函数的一组单元测试被归结为所需资源最少的单元测试，所以能够提升整体性能。在所述第一方面的第八种可能实现形式中，所述计算机可读介质存储有计算机可读指令，执行所述计算机可读指令会使所述系统进行以下操作：基于指派给冗余单元测试的性能得分，从所述第一和第二单元测试中的所述冗余单元测试中确定所述子集的成员，其中，所述冗余单元测试针对不可用服务的失败模式相同。因此，由于在执行时产生相同的服务可用性信息的一组冗余单元测试被归结为所需资源最少的单元测试，所以能够进一步提升整体性能。在所述第一方面的第九种可能实现形式中，所述性能得分基于所述冗余单元测试的执行时间。因此，能够减少整体的系统分析执行时间。在所述第一方面的第十种可能实现形式中，所述计算机可读介质包括在计算设备中，所述计算设备还包括处理器，并且，所述计算设备位于通信网络中。根据本发明的第二方面，提供了一种对具有多个物理实体的系统进行分析的方法，所述多个物理实体执行交互软件应用以提供多种服务。所述方法包括：为所述软件应用确定单元测试，其中，至少部分所述软件应用已被分配不止一个单元测试，若某个应用不可用，则分配给所述应用的单元测试失败；将所述确定的单元测试映射到所述多种服务以建立数据结构，所述数据结构指示在某项服务不可用时，哪些单元测试失败；以及执行所述映射的单元测试的子集以分析所述系统中的服务的可用性，其中，所述子集的成员在执行过程中基于所述子集中的在前单元测试是失败还是通过而动态确定。因此，如上所述，可用单元测试即，软件开发过程中开发的单元测试可以用于诊断不可用服务。在所述第二方面的第一种可能实现形式中，所述执行的单元测试对应于决策树中的路径上的节点，所述决策树中的叶子指示所述系统中的不可用服务。因此，如上所述，只需执行相关的单元测试，即，必须执行才能确定服务是否可用的单元测试。在所述第二方面的第二种可能实现形式中，所述路径上的节点根据所述对应的单元测试能够检测到的不可用服务的数量与执行所述单元测试所需的资源量的比值来进行排序。因此，如上所述，由于优先执行产生较多信息或耗费较少资源的单元测试，所以能够提升整体性能。在所述第二方面的第三种可能实现形式中，为所述软件应用确定单元测试还包括：确定待由可用单元测试执行的函数调用；对所述函数指派相关度得分；忽略仅调用相关度得分低于阈值的函数的单元测试；以及忽视仅调用相关度得分大于或等于所述阈值的函数的单元测试，且所述函数同时也被所述确定的单元测试中的其它单元测试调用。因此，如上所述，可对单元测试进行筛选以避免执行不相关的或冗余的单元测试。在所述第二方面的第四种可能实现形式中，所述相关度得分基于所述可用单元测试中调用所述函数的次数。因此，如上所述，函数的相关度可基于所述函数的使用唯一性来进行判断。在所述第二方面的第五种可能实现形式中，为所述软件应用确定单元测试包括：确定待由可用单元测试执行的函数调用；以及忽略仅调用还被所述确定的单元测试中的其它单元测试调用的函数的可用单元测试。因此，如上所述，可以避免选择冗余单元测试。在所述第二方面的第六种可能实现形式中，对于调用相同函数的单元测试，忽略性能得分低于其它单元测试的单元测试以进行去重。因此，如上所述，由于调用同一相关函数的一组单元测试被归结为所需资源最少的单元测试，所以能够提升整体性能。在所述第二方面的第七种可能实现形式中，基于指派给多个映射的单元测试的性能得分，从所述多个映射的单元测试中选择所述子集的成员，其中，所述多个映射的单元测试针对不可用服务的失败模式相同。因此，如上所述，由于在执行时产生相同的服务可用性信息的一组冗余单元测试被归结为所需资源最少的单元测试，所以能够进一步提升整体性能。附图说明图1示出了过程执行时涉及的示例性系统的方框图；图2示出了该过程第一阶段的流程图；图3为根据一示例的将在第一阶段中使用的抽象语法树；图4a至图4c示出了图3所示的抽象语法树针对不同目标参数的使用方法；图5示出了去选冗余单元测试的示例；图6示出了该过程第二阶段的流程图；图7示出了第二阶段得到的单元测试和服务之间的示例性映射；图8示出了几组冗余同构单元测试；图9示出了基于第二阶段建立的关系的决策树。具体实施方式以下示例性过程可由软件、硬件或二者结合的方式来实现，目的在于通过重用软件开发阶段用于测试软件应用的单元测试来有效地诊断具有多个物理实体的系统，例如云平台，其中，这多个物理实体执行一个或多个交互软件应用以提供多种服务。该过程可包括三个阶段，下文将在描述时更详细地说明。在第一阶段，通过去选冗余单元测试，可减少可用单元测试的数量。在此需要说明的是，去除冗余单元测试时，可确定并忽略不相关的支持方法。在第二阶段，可确定剩余单元测试与系统运行所需的所有服务之间的关系，其中，剩余单元测试可基于确定的关系进行筛选。在第三阶段，可生成决策树来诊断系统故障。测试结果表明，在一些情况中，只需执行4％至5％的可用单元测试就足以测试所有服务的可用性。图1示出了该过程执行时涉及的示例性系统10。系统10包括执行交互软件software，SW应用application，APP14的多个物理实体12。SWAPP14之间可使用超文本传输协议HypertextTransferProtocol，HTTP、远程过程调用RemoteProcedureCall，RPC、令牌、消息队列等来进行通信。交互SWAPP14可提供服务16，这些服务16对系统10的运行至关重要。例如，若其中一个服务16无法正常运行，则系统10可能无法处理客户端18的一个或多个甚至任何一个请求。系统10也包括软件开发基础设施20。软件开发基础设施20可包括人类软件开发人员可用来实现、更新以及维护交互SWAPP14的一个或多个计算机和软件。例如，软件开发基础设施20可包括版本控制数据库22。版本控制数据库22可存储于计算机中，并且可包括软件代码以及SWAPP14的修改记录。特别地，版本控制数据库22可存储与SWAPP14当前在物理实体12的实施有关的所有代码。另外，软件开发基础设施20可包括代码评审模块24。代码评审模块24可提供评审SWAPP14的代码的平台。例如，开发人员或操作员可使用代码评审模块24来接受或拒绝代码修改并提供反馈。代码评审模块24可提供基于网页的图形用户界面graphicaluserinterface，GUI，开发人员或操作员可通过该GUI来评审代码。代码形式可为一种或多种人类可读的编程语言，例如，Java、C#、HTML5、JavaScript、R、Swift、C++、PHP、Ruby、Python，等等。此外，软件开发基础设施20可包括代码集成模块26。代码集成模块26可用于控制代码到版本控制数据库database，DB22中的集成。例如，集成前，可执行所有可用单元测试28以验证代码的完整性。单元测试28可用于结合关联的控制数据来测试SWAPP14的最小可测试部件，也称为单元。例如，单元测试28可发送HTTP请求至物理实体12，并从物理实体12接收HTTP响应。其可基于响应判断单元测试28是通过还是失败。若单元测试28失败，则可能不集成相应的代码以及与其相关的代码，同时，软件开发人员对其进行标记以作进一步检查。这可帮助在早期阶段检测问题，使得SWAPP14无错运行。系统10还可包括故障诊断单元30，用于确定服务16是否正常运行。这种诊断可基于操作员确定的时间帧周期性地执行，并可对软件开发基础设施20执行的测试进行补充，以便发现软件开发基础设施20执行单元测试28时未发现的问题。故障诊断单元30可包括单元测试管理器32。单元测试管理器32可用于去选不相关的和或冗余的单元测试28以从整体上诊断服务16。故障诊断单元30还可包括测试服务映射器34。测试服务映射器34可确定数据，该数据指示某一服务16不可用时，哪个单元测试失败。在此之前，测试服务映射器34可向一个或多个物理实体12发送信号，例如Unix信号，使得这一个或多个物理实体12禁用停止关闭服务16。一旦服务16不可用，测试服务映射器34可向一个或多个软件应用14发送请求，例如HTTP请求。这可针对所有选择的单元测试2重复执行。由于每个请求都要求一个或多个特定服务16正在运行，因此，当某个服务16不可用时，可以确定所选择的单元测试28中的哪个单元测试失败。特别地，可通过检查一个或多个物理实体12的HTTP响应来确定某一单元测试28是通过还是失败。通过的单元测试28可归类为无法测试服务16的可用性，而失败的单元测试28则归类为能够测试服务16的可用性。在确定选择的单元测试28中的哪些单元测试能够并且能够用于测试特定服务16不可用之后，可向一个或多个物理实体12发送信号，例如Unix信号，使得该一个或多个物理实体12重新启用启动服务16。这可针对所有或一部分服务16重复执行。另外，可将选择的单元测试28与服务16之间的依赖关系存储至数据结构中，例如矩阵或者阵列中。这些依赖关系可指示单元测试28确定特定服务16是否正常运行的能力。故障诊断单元30还可包括故障检测器36。故障检测器36可使用数据结构并构建决策树来选择最相关的单元测试28，以诊断系统10中的服务16。但是，决策树可能只在需要的时候才会重建，即，若选择的单元测试28的集合发生变化，则可多次使用相同的决策树来诊断系统服务16。例如，操作员可在一天中选定的时段系统负载较低的时段，例如，夜间时段、系统10的设定休眠时段，或者要集成新代码时中定义安排好的诊断。例如，故障检测器36可向SWAPP14发送HTTP请求，并接收HTTP响应。对HTTP消息的交换进行分析后，可生成指示不可用服务16若有的故障报告。若系统服务16不可用，则可对其采取维护操作，例如，取消代码的最近变更。另外，在代码集成时，可将该报告发送至代码集成模块26，代码集成模块26可确定是接受还是拒绝代码变更。图2示出了上述过程38的第一阶段的流程图，其可通过单元测试管理器32来执行。单元测试管理器32可接收在开发阶段写入的一系列现有单元测试28作为输入，并向测试服务映射器34输出数量有所减少的单元测试28，其中测试服务映射器34可执行第二阶段的操作。如图2所示，在40处，单元测试管理器32可通过以下操作来开始第一阶段：确定包括与可用单元测试28相关的代码的源文件模块。在42处，可对包括与可用单元测试28相关的代码的源文件模块进行代码分析，并构建抽象语法树AbstractSyntaxTree，AST。例如，代码可包括可调用其它方法的单元测试方法，在下文中，这些其它方法可称为支持方法。支持方法可调用SWAPP14的各种函数。为确定单元测试方法及其支持方法，可构建AST参见Kuhn、Thomas和OlivierThomann在EclipseCornerArticles202006中的“抽象语法树”。AST可为源代码模块以树的形式而存在的表征，其中，AST中的节点可表示在源代码模块中执行的构建类、单元测试方法或支持方法。可遍历AST来确定单元测试方法及其支持方法。针对每一个单元测试方法，可创建其支持方法的集合。AST可通过编译器按照如以下一系列步骤来构建：●扫描源代码读取字符流的位置；●对字符进行分组以形成令牌；以及●进行解析，其中，将令牌转换为语法结构，该语法结构可称为解析树。然后将解析树转换为AST。在此需要说明的是，至少一部分编程语言已支持构建AST。例如，在使用Python时，Python库ast.py可用于构建AST。在44处，对构建的AST进行筛选。可根据确定的支持方法的相关度对这些支持方法进行打分。例如，若某种方法只适用于特定语言，且在系统10的服务16的测试中可能并不发挥直接作用，则可去选该支持方法。可基于倒文档率InverseDocumentFrequency，IDF将支持方法标记为“相关”或“不相关”。因此，IDF较低的支持方法，即，存在于多个源文件模块中的支持方法，可视为不相关。例如，可根据以下等式计算支持方法x的IDF：IDFx＝log#源文件模块包括支持方法x的#源文件模块1因此，如下文结合图3所示的示例更详细地说明的所述，存在于多个源文件模块中的支持方法可能具有较低的IDF。图3示出了四个模块。模块1包含单元测试方法U1、U2以及U3的定义。模块2包含单元测试方法U4、U5以及U6的定义。模块3包含单元测试方法U7、U8以及U9的定义。模块4包含单元测试方法U10、U11以及U12的定义。根据公式1可确定以下IDF：IDFAssert＝log44＝0IDFS1＝log41＝log4IDFS2＝log42＝log2IDFS3＝log41＝log4因此，S1、S2以及S3可标记为相关，而“Assert”则可标记为不相关并被去选。在此需要强调的是，不同框架下的阈值可能也不相同。因此，为获取最佳结果，可尝试使用不同的IDF阈值并可从中选择一个阈值，用于去除大部分或者所有只针对特定语言的支持方法，但不会去除或只去除几个通常相关的用户定义方法。继续参考图2，在46处，可对被标记为“相关”的支持方法进行去重。例如，若单元测试方法的子集调用了同样的支持方法，则表示存在可以去选的冗余单元测试方法。去选操作可基于修改后的集合覆盖算法进行。修改后的集合覆盖算法可选择最少数量的单元测试方法，使得选择的单元测试方法调用源文件模块中的任何单元测试方法所调用的所有支持方法。例如，在图3中，模块3中的子集{U7，U8}和{U7，U9}调用该模块中的所有支持方法{S6，S7，S8}。因此，可以选择任何一个子集来调用所有支持方法。另外，集合覆盖算法可选择执行时间最短的子集。修改后的集合覆盖算法可能涉及以下参数：●时间：执行子集中的单元测试所需的时间。这与集合覆盖算法中的“成本cost”有关，可帮助选择最有效的单元测试方法子集。例如，若有不止一个单元测试方法子集调用一个源文件模块中的所有支持方法，则可选择执行时间最短的子集。●覆盖率：支持方法需实现的最小覆盖率单位：％。这是指操作员可以基于所需支持方法的百分比来选择单元测试方法。例如，在图3中，模块3中有三种支持方法{S6，S7，S8}。若要达到100％的覆盖率，则需选择子集{U7，U8}或{U7，U9}，以便覆盖所有支持方法。若要达到30％的覆盖率，只需选择{U7}即可，因为只需调用三分之一的支持方法。修改后的集合覆盖算法的数学定义可为：输入：●支持方法的集合：S＝{s1，s2，…，sn}●m个单元测试集合中的一个集合：U＝{U1，U2，…，Um}，使得：●●期望的覆盖率，c∈[0，1]●执行每个单元测试所需时间的集合：T＝{t1，t2，…，tm}，使得ti为Ui的执行时间。修改后的集合覆盖算法可用于确定集合使得：●∑tj最小●●j∈J另外，修改后的集合覆盖算法可通过以下伪代码示意性地表示：1.Umin←{}2.a.for所有的单元测试方法Udo找到这样一个单元测试方法：针对每新增的支持方法，成本α最低：b.Umin←Umin∪U3.输出Umin。以伪代码表示的算法的工作方式如下：1.Umin表示单元测试的集合。初始值为空集。2.当不满足覆盖率条件即，集合中的支持方法的数量小于期望值时：a.找到这样一个单元测试方法U：U的每个支持方法，成本α最低，其中，α为单元测试方法的执行时间与新增支持方法的数量之间的比值。b.把单元测试方法U添加到Umin中。3.输出Umin。对此，图4a示出了去除不相关支持方法Assert后的模块3的AST。该AST包括三种单元测试方法：U7、U8以及U9。下文中，假设U7的执行时间为15秒，U8的执行时间为8秒，U9的执行时间为9秒。若把修改后的集合覆盖算法应用到图4a中的AST，以去除冗余单元测试方法并达到100％的期望覆盖率，则所有支持方法都必须出现。这种情况下，如图4b所示，选择U7和U8，因为U7和U8覆盖所有不同的支持方法并且成本最低。因此，修改后的集合覆盖算法去除了U9。若把修改后的集合覆盖算法应用到图4a中的AST，以去除冗余单元测试方法并达到50％的期望覆盖率，则只需执行三种支持方法中的任意两种即可因为2350％。U8和U9均包括两种不同的支持方法。由于U8成本最低，因此选择U8，去选U7和U9。在此需要说明的是，上文所选的百分比值仅为示例性的，操作员可根据实际需要设置覆盖率。仍然参考图2，在48处，可去除源文件模块中的冗余单元测试28。例如，如图5所示，当涉及图3中的模块2和模块4时，模块2中的单元测试方法U5调用支持方法{S4，S5}。类似地，模块4包括单元测试方法U10、U11以及U12，分别调用支持方法集合{S4}、{S10，S4}以及{S12，S5}。支持方法去重子系统确保模块4中的单元测试方法的子集调用支持方法{S4，S5，S10，S12}。这意味着模块4已经覆盖了U5调用的所有支持方法即，{S4，S5}。因此，U5是冗余的，可以去选。该方法可以应用于所有单元测试方法，以去除整个源文件模块中的冗余单元测试方法。上述过程的第二阶段的流程图可由测试服务映射器34完成，如图6所示。测试服务映射器34可从单元测试管理器32接收关于相关的以及去重后的单元测试28的数据。在52处，测试服务映射器34可确定接收到的单元测试28与服务16之间的关系。该关系可基于单元测试检测特定服务16是否正常运行的能力来确定。可针对所有服务16重复执行以下步骤：●禁用停止关闭服务s。这可模拟服务16发生故障的情况。●运行数量有所减少的单元测试28的集合。依赖于服务s的单元测试28将会失败。不依赖于服务s的单元测试28将会通过。可记录这一结果。●重新启用启动服务s。一次可能只能禁用一个服务16。若一次禁用不止一个服务16且一个单元测试失败，则无法判断是哪个服务16导致单元测试28失败。因此，可针对所有对系统10的运行起关键作用的服务16重复执行上述步骤。可基于测试运行的结果，建立单元测试28与服务16之间的关系，并以矩阵表示，如图7所示。在图7中，每个方格表示一个单元测试28与一个服务16之间的关系。该关系可通过表达式RUi，服务j来表示，其中Ui表示单元测试28，服务j表示服务16。RUi，服务j＝0表示当服务j不可用时，Ui失败。若在系统10中执行Ui，并成功通过，则可以认为服务j正常运行。这意味着Ui依赖于服务j。但是，若Ui失败，则服务j可能不可用，虽然并不能百分之百地确定服务j在这种情况下不可用。RUi，服务j＝1表示当服务j禁用后，Ui通过。因此，Ui并不依赖于服务j。换言之，无法使用Ui来测试服务j是否可用。因此，执行该单元测试28无法明确地判断服务j是否可用。例如，如图7的矩阵所示，若U5失败，则服务2、服务3、服务4或者服务5可能不可用，但无法判断服务1是否可用。但是，若U5通过，则表示服务2、服务3、服务4以及服务5可用。这些关系可用于在第三阶段中构建决策树。在此之前，在图6的54中，可通过筛选来进一步减少单元测试28的数量。如图7所示，每个单元测试28可以用一种二进制字符串模式来表示，该二进制字符串模式由表示服务16的各行表示执行时间的行除外派生而来。例如，U1用01010表示，U2用11101表示，等等。二进制字符串相同的单元测试28可称为同构测试。即，同构测试与服务16之间的关系相同，因此可检测相同的服务16的可用性。因此，同构测试为冗余测试。为了去除这些冗余测试，可将同构单元测试28归为一组，并从中选择一个单元测试28例如，选择执行时间最少的单元测试28，如图8所示。例如，单元测试U1的执行时间可为10秒，单元测试U2的执行时间可为9秒，单元测试U3的执行时间可为13秒，单元测试U4的执行时间可为19秒，单元测试U5的执行时间可为3秒。因此，可选择单元测试U1、U5以及U2。只有第二阶段中被选中的单元测试才可用于在第三阶段中构建决策树。在前两个阶段，单元测试28的数量减少，并建立了单元测试28与待诊断的系统10提供的服务16之间的关系。在第三阶段，这些关系可用于构建决策树。可使用决策树来检测系统10在正常运行中的故障服务16，即，与客户端18的服务请求并发的故障服务16。决策树的树结构可为，其每个内部节点测试一个属性，每个分枝对应一个属性值，每个叶节点分配一个类别或标签。从根节点到叶节点的路径可表示分类规则。在这种情况下，每个内部节点可表示第二阶段中选择的一个单元测试28。每个分枝可表示一个单元测试28的结果，每片叶可表示一个或多个不可用服务16。可通过顺序故障诊断来构建决策树。这可基于属性信息增益生成决策树。每个单元测试的信息增益可通过以下公式计算：信息增益＝单元测试的可测试性单元测试的执行时间2单元测试的可测试性＝单元测试能够测试出的未检测服务的数量给定图9所示的关系，可使用公式2计算信息增益，如下所示：信息增益：U1＝18；信息增益：U2＝27；信息增益：U3＝25；信息增益：U4＝24。可选择信息增益最高的单元测试28，并可将节点添加到单元测试28此处为U4所在的决策树中。然后，可将与该单元测试28的结果对应的节点添加到决策树中。如第二阶段的相关描述，单元测试Ui的关系为RUi，服务j＝0，若Ui通过，则认为服务j正常运行。该关系用于构建决策树。选择该单元测试后，可在决策树中新建两个分枝。U4的通过分枝可表示服务1和服务2正常运行。因此，针对下一节点，服务3被视为未检测的服务。针对U4上的通过分枝，U1、U2以及U3的信息增益分别为18、17以及15。由于U3的信息增益最高，所以可选择U3作为下一节点。基于上述关系，若U3通过，则可认为服务1和服务3可用。前一个节点已确定服务1和服务2正常运行。因此，该节点的通过分枝确定所有服务均正常运行。但是，若该测试失败，则可表示服务16中的任何一个服务都有可能不可用。由于前一个节点已确定服务1和服务2正常，所以该节点的失败分枝表示服务3处于故障状态。可重复执行该过程以构建图9所示决策树中的其它部分。该决策树包括四种属性，这四种属性代表了示为内部节点的四个单元测试28。从根节点到叶节点的路径表示测试顺序，其中，叶节点表示故障服务16。为诊断运行系统10，可基于单元测试28的结果遍历决策树，直至到达叶节点。例如，图9中的决策树从U4开始。若执行单元测试U4并通过，则移到包括U3的下一个节点，执行单元测试U3。若此时U3失败，则可表示服务3处于故障状态；若单元测试U3通过，则可表示所有服务16都正常运行。然而，如前所述，某些情况中，也许不止一个可能服务16处于故障状态。例如，若U4失败，则包括U3的节点可能故障。U3故障则可能导致包括U2的节点故障。类似地，U2故障可能导致U1故障。若U1通过，则可表示服务1或服务2不可用或者服务1和服务2都不可用。在图9所示的示例中，一般情况下，只需要运行logn约数个单元测试即可检测故障服务，而无需运行n个单元测试，n是去除同构单元测试后的单元测试总数。因此，决策树使用户能够检测不可用服务16而无需执行所有可用单元测试28。

权利要求：1.一种计算机可读介质，其特征在于，存储用于对具有多个物理实体的系统进行分析的计算机可读指令，所述多个物理实体执行一个或多个交互软件应用以提供多种服务，执行所述计算机可读指令会使所述系统进行以下操作：关闭第一服务，并执行选择的单元测试以确定由于所述第一服务不可用而导致失败的第一单元测试；关闭第二服务，并执行所述选择的单元测试以确定由于所述第二服务不可用而导致失败的第二单元测试；以及启动所述服务，并执行所述第一和第二单元测试的子集以分析所述系统，其中，所述子集的成员在执行过程中基于所述子集中的在前单元测试是失败还是通过而动态确定。2.根据权利要求1所述的计算机可读介质，其特征在于，所述执行的单元测试对应于决策树中的路径上的节点，所述决策树中的叶子指示所述系统中的不可用服务。3.根据权利要求2所述的计算机可读介质，其特征在于，所述路径上的节点根据所述对应的单元测试能够检测到的不可用服务的数量与执行所述单元测试所需的资源量的比值来进行排序。4.根据权利要求1至3中任意一项所述的计算机可读介质，其特征在于，存储有计算机可读指令，执行所述计算机可读指令会使所述系统进行以下操作：对可用单元测试调用的函数指派相关度得分；以及去选以下情况中的可用单元测试：仅调用相关度得分低于阈值的被忽略函数；或者仅调用相关度得分大于或等于所述阈值的函数，所述函数同时也被所述选择的单元测试中的其它单元测试所调用。5.根据权利要求4所述的计算机可读介质，其特征在于，所述相关度得分基于单元测试集合中的所述单元测试所进行编码的文件中调用所述函数的次数。6.根据权利要求5所述的计算机可读介质，其特征在于，所述单元测试集合中的所述单元测试所进行编码的文件中调用所述函数的次数越多，所述相关度得分越低。7.根据权利要求1至6中任意一项所述的计算机可读介质，其特征在于，存储有计算机可读指令，执行所述计算机可读指令会使所述系统进行以下操作：去选可用单元测试，其中，所述可用单元测试仅调用还被所述选择的单元测试中的其它单元测试调用的函数。8.根据权利要求4至7中任意一项所述的计算机可读介质，其特征在于，存储有计算机可读指令，其中，执行所述计算机可读指令会使所述系统进行以下操作：去选性能得分低于其它单元测试的可用单元测试。9.根据权利要求1至8中任意一项所述的计算机可读介质，其特征在于，存储有计算机可读指令，其中，执行所述计算机可读指令会使所述系统进行以下操作：基于指派给冗余单元测试的性能得分，从所述第一和第二单元测试中的冗余单元测试中确定所述子集的成员，其中，所述冗余单元测试针对不可用服务的失败模式相同。10.根据权利要求9所述的计算机可读介质，其特征在于，所述性能得分基于所述冗余单元测试的执行时间。11.一种通信网络，其特征在于，包括计算设备，所述计算设备包括处理器以及根据权利要求1至10中任意一项所述的计算机可读介质。12.一种对具有多个物理实体的系统进行分析的方法，其中，所述多个物理实体执行交互软件应用以提供多种服务，其特征在于，所述方法包括：为所述软件应用确定单元测试，其中，至少部分所述软件应用已被分配不止一个单元测试，若某个应用不可用，则分配给所述应用的单元测试失败；将所述确定的单元测试映射到所述多种服务以建立数据结构，其中，所述数据结构指示在某项服务不可用时，哪些单元测试失败；以及执行所述映射的单元测试的子集以分析所述系统中的服务的可用性，其中，所述子集的成员在执行过程中基于所述子集中的在前单元测试是失败还是通过而动态确定。13.根据权利要求12所述的方法，其特征在于，所述执行的单元测试对应于决策树中的路径上的节点，所述决策树中的叶子指示所述系统中的不可用服务。14.根据权利要求13所述的方法，其特征在于，所述路径上的节点根据所述对应的单元测试能够检测到的不可用服务的数量与执行所述单元测试所需的资源量的比值来进行排序。15.根据权利要求12至14中任意一项所述的方法，其特征在于，为所述软件应用确定单元测试还包括：确定待由可用单元测试执行的函数调用；对所述函数指派相关度得分；忽视仅调用相关度得分低于阈值的函数的单元测试；以及忽略仅调用相关度得分大于或等于所述阈值的函数的单元测试，且所述函数同时也被所述确定的单元测试中的其它单元测试调用。16.根据权利要求15所述的方法，其特征在于，所述相关度得分基于所述可用单元测试中调用所述函数的次数。17.根据权利要求12至16中任意一项所述的方法，其特征在于，为所述软件应用确定单元测试包括：确定待由可用单元测试执行的函数调用；以及忽略仅调用还被所述确定的单元测试中的其它单元测试调用的函数的可用单元测试。18.根据权利要求15至17中任意一项所述的方法，其特征在于，对于调用相同函数的单元测试，忽略性能得分低于其它单元测试的单元测试以进行去重。19.根据权利要求12至18中任意一项所述的方法，其特征在于，基于指派给多个映射的单元测试的性能得分，从所述多个映射的单元测试中选择所述子集的成员，其中，所述多个映射的单元测试针对不可用服务的失败模式相同。

百度查询： 华为技术有限公司 选择单元测试进行系统分析

免责声明
1、本报告根据公开、合法渠道获得相关数据和信息，力求客观、公正，但并不保证数据的最终完整性和准确性。
2、报告中的分析和结论仅反映本公司于发布本报告当日的职业理解，仅供参考使用，不能作为本公司承担任何法律责任的依据或者凭证。

阅读全文 双屏查看 官方信息 专利公告 收藏专利 下载PDF 下载WORD