CN105630656B - 基于日志模型的***健壮性分析方法及装置 - Google Patents

Abstract

本申请提供一种基于日志模型的***健壮性分析方法及装置，包括：调取日志模型库，所述日志模型库包括与***日志的文本样式相对应的日志模型；获取本次健壮性测试中生成的***日志，并与所述日志模型库进行匹配；根据匹配于每个日志模型的***日志条数，确定***的健壮性。通过本申请的技术方案，可以降低***健壮性测试的运算量，提升测试效率和准确度。

Description

基于日志模型的***健壮性分析方法及装置

技术领域

本申请涉及数据处理技术领域，尤其涉及基于日志模型的***健壮性分析方法及装置。

背景技术

在软件***开发过程中，都需要对***进行健壮性测试(Robustness Testing)，又称为容错性测试(Fault Tolerance Testing)，用于模拟***故障的测试环境，以检验***能否自动恢复或忽略故障地运行。

在健壮性测试的过程中，会生成数量巨大的***日志，而如何通过对海量的***日志进行快速、有效分析，以确定***的健壮性状况，成为目前亟待的解决的技术问题。

发明内容

有鉴于此，本申请提供一种基于日志模型的***健壮性分析方法及装置，可以降低***健壮性测试的运算量，提升测试效率和准确度。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种基于日志模型的***健壮性分析方法，包括：

调取日志模型库，所述日志模型库包括与***日志的文本样式相对应的日志模型；

获取本次健壮性测试中生成的***日志，并与所述日志模型库进行匹配；

根据匹配于每个日志模型的***日志条数，确定***的健壮性。

根据本申请的第二方面，提出了一种基于日志模型的***健壮性分析装置，包括：

调取单元，调取日志模型库，所述日志模型库包括与***日志的文本样式相对应的日志模型；

匹配单元，获取本次健壮性测试中生成的***日志，并与所述日志模型库进行匹配；

确定单元，根据匹配于每个日志模型的***日志条数，确定***的健壮性。

由以上技术方案可见，本申请通过分析***日志的文本样式，抽取日志模型并建立日志模型库，可以对海量的***日志进行分类，并对每类***日志进行总体分析，无需逐一分析每条***日志，极大地降低了***日志的分析量，有助于提升测试效率和准确度。

附图说明

图1是本申请一示例性实施例的一种基于日志模型的***健壮性分析方法的流程图；

图2是本申请一示例性实施例的一种基于日志模型的分析***健壮性的示意图；

图3是本申请一示例性实施例的一种生成日志模型的流程图；

图4是本申请一示例性实施例的一种电子设备的结构示意图；

图5是本申请一示例性实施例的一种基于日志模型的***健壮性分析装置的框图。

具体实施方式

为对本申请进行进一步说明，提供下列实施例：

请参考图1，图1是本申请一示例性实施例的一种基于日志模型的***健壮性分析方法的流程图，该方法可以包括下述步骤：

步骤102，调取日志模型库，所述日志模型库包括与***日志的文本样式相对应的日志模型。

在本实施例中，由于***日志的文本样式具有一定的格式，比如仅由常量构成，或者由常量和变量构成，则通过对***日志的文本样式进行统计分析，即可提取其中的公共部分，即日志模型。其中，当***日志的类型增加时，通过对新增***日志的分析，抽取新的日志模型。

在本实施例中，日志模型可以来自管理通道，也可以通过对***日志的分析和统计进行自动抽取。

步骤104，获取本次健壮性测试中生成的***日志，并与所述日志模型库进行匹配。

在本实施例中，每次健壮性测试可能涉及同一应用功能的一个或多个***，每个***都会生成对应的***日志。通过将生成的***日志与日志模型库进行匹配，可以识别出***日志所属的日志模型，相当于通过日志模型实现对***日志的分类，其中同一个日志模型可以对应于来自一个或多个***的***日志。

步骤106，根据匹配于每个日志模型的***日志条数，确定***的健壮性。

在本实施例中，作为一示例性实施例，同一***在相同的应用场景下，若正常运行，则每个日志模型的***日志条数应当不会发生较大波动，则可以根据本次健壮性测试采用的应用场景，确定每个日志模型对应的正常***日志条数的数值范围，并与本次实际生成的***日志条数进行比对，即可确定***的健壮性是否正常。

作为另一示例性实施例，通过分别获取在相同类型、不同程度的模拟故障环境下，匹配于同一日志模型的***日志条数，如果***的健壮性正常，则分别获取的***日志条数应当不会存在较大波动，即可确定***的健壮性状况。

由上述实施例可知，本申请通过建立日志模型库，可以将海量的***日志进行基于日志模型的分类处理，从而极大地降低了数据处理量，有助于提升健壮性分析效率；同时，由于同一***在相同应用场景下，正常运行时产生的***日志数量具有一致性，因而本申请通过统计每个日志模型对应的***日志数量，即可确定***是否正常运行，从而准确获得***的健壮性状况。

请参考图2，图2是本申请一示例性实施例的一种基于日志模型的分析***健壮性的示意图，描述了本申请对***健壮性进行测试的过程：

1、建立日志模型库

日志模型库的建立，实际上是对每个日志模型的抽取和存储。其中，每个日志模型是通过对一类***日志的文本样式的统一和抽象，得到的“公式性”的模型语句。

其中，基于***日志的文本样式，可以包括下述两种形式：

(1)仅包含常量(constants only)

对于该种形式的***日志，语句中仅包含常量，而没有变量，比如下述节选的日志语句：

●“SystemA-CLIENT-查询***参数为空，无法提供客户端查询，关闭客户端配置开关”

因此，对于仅包含常量的***日志，可以直接将其定义为日志模型。

(2)包含常量和变量(constants+variables)

对于该种形式的***日志，语句中同时包含常量和变量，比如下述节选的日志语句：

●“SystemB-biz-decision-process-

userId[2088102002768374],securityId[web|SystemC_payment_3|161247a4-48a7-43fd-ac1f-d96b16da4985]执行规则失败”

●“SystemB-biz-decision-process-

userId[2088102002768253],securityId[web|SystemC_payment_3|00194db2-3503-4032-8028-2a259b088369]执行规则失败”

在上述日志语句中，“SystemB-biz-decision-process-userId[]”、“securityId[]执行规则失败”为常量，而“2088102002768374”、“2088102002768253”、“web|SystemC_payment_3|161247a4-48a7-43fd-ac1f-d96b16da4985”和“web|SystemC_payment_3|00194db2-3503-4032-8028-2a259b088369”为变量；其中，“2088102002768374”和“2088102002768253”相对应，“web|SystemC_payment_3|161247a4-48a7-43fd-ac1f-d96b16da4985”和“web|SystemC_payment_3|00194db2-3503-4032-8028-2a259b088369”相对应。

因此，对于同时包含常量和变量的***日志，可以通过提取公共的常量部分，生成对应的日志模型。

可见，通过对多条***日志的公共常量部分进行提取，并对变量部分进行抽象，则获得的对该多条***日志进行统一描述的语句，即日志模型。在图2所示的分析***健壮性的过程中，具体由“日志模型抽取模块”(或其他用于实现相同功能的模块或设备)对历史日志进行分析后，抽取日志模型并构成日志模型库。其中，图3是本申请一示例性实施例的一种生成日志模型的流程图，该流程可以包括下述步骤：

步骤302，获取历史日志。

在本实施例中，“历史日志”可以为历史上执行***健壮性测试时生成的***日志，通过对海量的历史日志进行分析，有助于丰富日志模型的类型，并提升日志模型的准确性。

步骤304，对历史日志进行分组。

在本实施例中，可以使得分组得到的每个组别中包含预设数量的历史日志，则通过对每个组别的历史日志进行比较和分析，即可提取对应的公共部分，以供得到日志模型。

举例而言，比如历史日志中包括下述4条语句：

a)2014-08-2012:30:00,231SystemB-biz-decision-process-userId[2088102002768374],securityId[web|SystemC_payment_3|161247a4-48a7-43fd-ac1f-d96b16da4985]执行规则失败

b)2014-08-2012:40:20,131SystemB-biz-decision-process-userId[2088102002768253],securityId[web|SystemC_payment_3|00194db2-3503-4032-8028-2a259b088369]执行规则失败

c)2014-08-2012:42:20,622SystemA-CLIENT-查询***参数为空，无法提供客户端查询，关闭客户端配置开关

d)2014-08-2012:42:22,523SystemA-CLIENT-查询***参数为空，无法提供客户端查询，关闭客户端配置开关

作为一示例性实施例，可以根据***名、日志名和时间戳为维度，将上述4条历史日志分为6个组别，分别为：(a，b)、(a，c)、(a，d)、(b，c)、(b，d)和(c，d)。

步骤306，对历史日志进行预处理。

在本实施例中，通过对历史日志的预处理，使得处理结果有助于计算机执行更为准确的数据分析。

在本实施例中，对历史日志的预处理可以包括：过滤时间戳、切分序列化、过滤变量等过程。

i.过滤时间戳

针对上述4条历史日志，时间戳位于各条日志语句的最前方，如日志a中的“2014-08-2012:30:00,231”、日志b中的“2014-08-2012:40:20,131”等。

ii.切分序列化

针对每个组别的历史日志，可以分别进行处理。其中，对于每条历史日志，可以按照预先定义的切割符号(比如逗号、空格等)对历史日志中的字符进行切分，从而将相应的历史日志切分为一个字符序列(即token序列)。

比如对于上述的组别(a，b)中，当对历史日志a进行切分序列化时，可以得到下述字符序列：

[SystemB-biz-decision-process，userId，2088102002768374，securityId，web|SystemC_payment_3|161247a4-48a7-43fd-ac1f-d96b16da4985，执行规则失败]

iii.过滤变量

可选的，由于切分得到的字符序列可能比较长，则为了简化字符序列而降低后续计算量，提升历史日志的分析效率，可以对变量进行简化，比如将所有的变量统一简化为“(*.？)”或其他标识符，则可以将上述对应于历史日志a的字符序列简化为：

[SystemB-biz-decision-process，userId，(*.？)，securityId，(*.？)，执行规则失败]

步骤308，针对每个组别内的历史日志，计算对应的最长公共子序列。

在本实施例中，当一个组别内的历史日志均完成了预处理，得到相应的字符序列后，即可通过对该组别内所有历史日志对应的字符序列进行比较，确定公共部分。

作为一示例性实施例，可以采用LCS(longest common subsequence，最长公共子序列))算法执行上述的比较操作，得到的公共部分即最长公共子序列。具体而言，比如对于任一组别(m，n)，假定日志m、n分别对应的字符序列为Xi＝[x1,x2,…,xi]和Yi＝[y1,y2,…,yj]，则对应的最长公共子序列可以定义为：

对应于上述的组别(a，b)，则基于上述公式可以得到相应的最长公共子序列为：

[SystemB-biz-decision-process，userId，*，securityId，*，执行规则失败]

而对应于上述的组别(a，c)，则基于上述公式可以得到相应的最长公共子序列为：(空集)，表明两条历史日志没有公共部分。

步骤310，根据计算出的最长公共子序列，抽取日志模型。

在本实施例中，作为一示例性实施方式，可以直接将得到的最长公共子序列作为日志模型；作为另一示例性实施方式，虽然在上述a、b、c和d对应的实施例中，a(或b)与c(或d)之间的最长公共子序列为空集，但在其他情况下，也可能存在非空集的最长公共子序列，比如其中的一个或两个字段相同，但该最长公共子序列显然并没有意义，因而可以通过对所有历史日志的分析过程中，每个最长公共子序列出现的次数进行统计，并当该统计次数大于或等于预设次数阈值时，才将该最长公共子序列抽取为日志模型。

在本实施例中，在将日志模型存储至日志模型库时，还可以记录日志模型对应的元数据信息，比如对应的***名、日志名、日志级别(如DEBUG，INFO，WARN，ERROR等)、抽取时间等。

在本实施例中，作为一示例性实施例，基于对历史日志进行预处理，然后生成最长公共子序列的处理过程的特点，可以在MapReduce框架下执行对日志模型的抽取，以提升处理效率。

2、检测健壮性

在每次执行健壮性测试时，获取生成的***日志，并基于已经建立的日志模型库，对生成的***日志进行识别和分类处理。比如图2所示，可以通过日志模型识别模块(或其他用于实现相同功能的模块或设备)将新日志(即本次健壮性测试得到的***日志，区别于“历史日志”)的日志数据与日志模型库进行匹配，并根据匹配结果进行统计，确定所有被匹配到的日志模型，以及每个日志模型对应的新日志条数，比如表1示出了一示例性实施例的统计结果。

表1

在表1中，执行测试的应用功能包含多个***，如“SystemB”和“SystemC”等，而每个***均匹配到一个或多个日志模型，比如***“SystemB”匹配于日志模型“SystemB.pattern0”和日志模型“SystemB.pattern1”等，而***“SystemC”匹配于日志模型“SystemC.pattern0”和日志模型“SystemC.pattern1”等。

可选的，如果存在不匹配于日志模型库的新日志，则可以根据将该新日志来抽取新的日志模型，以扩充日志模型库。

(1)基于健壮性基准的数值比较

作为一示例性实施方式，在基于统计得到的每个日志模型匹配的日志统计数量，确定***健壮性时，可以采用下述处理方式：

根据当前应用场景，确定每个被匹配的日志模型对应的预设基准条数，并根据本次健壮性测试中的***日志条数与对应的所述预设基准条数之间的比较结果，从而确定***的健壮性。

在本实施例中，基于每次健壮性测试时的应用场景的变化，同一***针对相同的日志模型可能匹配到不同的日志条数，因而需要确定对应于当前应用场景的预设基准条数；其中，预设基准条数可以为首次成功执行相应的健壮性测试时，匹配于每个日志模型的***日志条数，或者最近一次成功执行相应的健壮性测试时，匹配于每个日志模型的***日志条数等。

表2

举例而言，比如表2对表1相应的应用场景和预设基准条数进行了补充：当前应用场景为“淘宝交易创建”时，每个被匹配的日志模型对应的日志条数的比较情况，比如日志模型“SystemB.pattern0”匹配的日志条数的波动比为1.20％，而日志模型“SystemC.pattern0”匹配的日志条数的波动比为101.17％；而通过预先设置可接受的波动比，比如5％，则可以认为上述的日志模型“SystemB.pattern0”的波动比正常，即***“SystemB”具有较好的健壮性，而日志模型“SystemC.pattern0”的波动比异常，即***“SystemC”的健壮性存在问题。

当然，表2仅为一示例性实施例，还可以对***日志(即上述的新日志)和日志模型进行更多维度的信息统计和分析，比如日志模型的信息、***日志的级别等。

(2)基于故障的注入程度变化

作为一示例性实施方式，在基于统计得到的每个日志模型匹配的日志统计数量，确定***健壮性时，可以采用下述处理方式：

分别获取在相同类型、不同程度的模拟故障环境下，匹配于同一日志模型的***日志条数；当任一模拟故障环境对应的***日志条数与其他模拟故障环境对应的***日志条数的差异度大于或等于预设差异度时，将所述任一模拟故障环境作为***的健壮性拐点。***的健壮性拐点应该理解为：某种测试条件(比如模拟故障环境)，且该***在该测试条件下的健壮性不足。

表3

如表3所示，针对应用场景“收银台渲染”下的模拟故障“SystemD.consult接口延迟”，分别实施不同程度的故障环境，比如延迟时间为100ms、200ms……500ms等。以***“SystemC”为例，在不同程度的模拟故障环境下，匹配于日志模型“SystemC.pattern0”和日志模型“SystemC.pattern1”的日志条数可能存在一定的变化，但对于健壮性良好的***而言，变化程度应当有限，否则说明该***必然出现了非正常运行的情况。

因此，通过比较各种程度的故障环境下，分别对应于日志模型“SystemC.pattern0”和日志模型“SystemC.pattern1”的日志条数可知：当延迟时间为500ms时，日志模型“SystemC.pattern0”对应的日志条数为0，与延迟时间为100ms时的512条、延迟时间为200ms时的409条相比，日志条数发生了剧烈变化；同时，当延迟时间为500ms时，日志模型“SystemC.pattern1”对应的日志条数为14，与延迟时间为100ms时的1234条、延迟时间为200ms时的1013条相比，日志条数发生了剧烈变化。可见，“SystemD.consult接口延迟500ms”为相应的***“SystemC”的健壮性拐点。

图4示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图4，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成基于日志模型的***健壮性分析装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图5，在软件实施方式中，该基于日志模型的***健壮性分析装置可以包括调取单元、匹配单元和确定单元。其中：

调取单元，调取日志模型库，所述日志模型库包括与***日志的文本样式相对应的日志模型；

匹配单元，获取本次健壮性测试中生成的***日志，并与所述日志模型库进行匹配；

确定单元，根据匹配于每个日志模型的***日志条数，确定***的健壮性。

可选的，所述日志模型由最长公共子序列LCS算法对历史***日志进行处理得到。

可选的，所述历史***日志被分为多个组别，每个组别包含预设数量的***日志，且每个组别的***日志均由所述LCS算法处理得到相应的最长公共子序列，则出现频率大于或等于预设频率的最长公共子序列被记录为所述日志模型。

可选的，每个组别内的每条***日志被按照该***日志包含的预设切割符号进行切分为一个字符序列，并由所述LCS算法对每个组别的所有字符序列进行处理得到相应的最长公共子序列。

可选的，还包括：

生成单元，根据不匹配于所述日志模型库的***日志，生成新的日志模型；

添加单元，将所述新的日志模型添加至所述日志模型库中。

可选的，所述确定单元用于：

根据当前应用场景，确定每个被匹配的日志模型对应的预设基准条数；

根据本次健壮性测试中的***日志条数与对应的所述预设基准条数之间的比较结果，确定***的健壮性。

可选的，所述预设基准条数包括：

首次成功执行所述健壮性测试时，匹配于每个日志模型的***日志条数；

或者，最近一次成功执行所述健壮性测试时，匹配于每个日志模型的***日志条数。

可选的，所述确定单元用于：

分别获取在相同类型、不同程度的模拟故障环境下，匹配于同一日志模型的***日志条数；

当任一模拟故障环境对应的***日志条数与其他模拟故障环境对应的***日志条数的差异度大于或等于预设差异度时，将所述任一模拟故障环境作为***的健壮性拐点。

因此，本申请通过分析***日志的文本样式，抽取日志模型并建立日志模型库，可以对海量的***日志进行分类，并对每类***日志进行总体分析，无需逐一分析每条***日志，极大地降低了***日志的分析量，有助于提升测试效率和准确度。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (14)

1.一种基于日志模型的***健壮性分析方法，其特征在于，包括：

调取日志模型库，所述日志模型库包括与***日志的文本样式相对应的日志模型；其中，所述文本样式为***日志的语句样式，所述日志模型由历史***日志的公共部分构成；

获取本次健壮性测试中生成的***日志，并与所述日志模型库进行匹配；

根据匹配于每个日志模型的***日志条数，确定***的健壮性：包括分别获取在相同类型、不同程度的模拟故障环境下，匹配于同一日志模型的***日志条数；当任一模拟故障环境对应的***日志条数与其他模拟故障环境对应的***日志条数的差异度大于或等于预设差异度时，将所述任一模拟故障环境作为***的健壮性拐点；其中，***在所述健壮性拐点下的健壮性不足。

2.根据权利要求1所述的方法，其特征在于，所述日志模型由最长公共子序列LCS算法对历史***日志进行处理得到。

3.根据权利要求2所述的方法，其特征在于，所述历史***日志被分为多个组别，每个组别包含预设数量的***日志，且每个组别的***日志均由所述LCS算法处理得到相应的最长公共子序列，则出现频率大于或等于预设频率的最长公共子序列被记录为所述日志模型。

4.根据权利要求3所述的方法，其特征在于，每个组别内的每条***日志被按照该***日志包含的预设切割符号进行切分为一个字符序列，并由所述LCS算法对每个组别的所有字符序列进行处理得到相应的最长公共子序列。

5.根据权利要求1所述的方法，其特征在于，还包括：

根据不匹配于所述日志模型库的***日志，生成新的日志模型；

将所述新的日志模型添加至所述日志模型库中。

6.根据权利要求1所述的方法，其特征在于，所述根据匹配于每个日志模型的***日志条数，确定***的健壮性，包括：

根据当前应用场景，确定每个被匹配的日志模型对应的预设基准条数；

根据本次健壮性测试中的***日志条数与对应的所述预设基准条数之间的比较结果，确定***的健壮性。

7.根据权利要求6所述的方法，其特征在于，所述预设基准条数包括：

首次成功执行所述健壮性测试时，匹配于每个日志模型的***日志条数；

或者，最近一次成功执行所述健壮性测试时，匹配于每个日志模型的***日志条数。

8.一种基于日志模型的***健壮性分析装置，其特征在于，包括：

调取单元，调取日志模型库，所述日志模型库包括与***日志的文本样式相对应的日志模型；其中，所述文本样式为***日志的语句样式，所述日志模型由历史***日志的公共部分构成；

匹配单元，获取本次健壮性测试中生成的***日志，并与所述日志模型库进行匹配；

确定单元，根据匹配于每个日志模型的***日志条数，确定***的健壮性：包括分别获取在相同类型、不同程度的模拟故障环境下，匹配于同一日志模型的***日志条数；当任一模拟故障环境对应的***日志条数与其他模拟故障环境对应的***日志条数的差异度大于或等于预设差异度时，将所述任一模拟故障环境作为***的健壮性拐点；其中，***在所述健壮性拐点下的健壮性不足。

9.根据权利要求8所述的装置，其特征在于，所述日志模型由最长公共子序列LCS算法对历史***日志进行处理得到。

10.根据权利要求9所述的装置，其特征在于，所述历史***日志被分为多个组别，每个组别包含预设数量的***日志，且每个组别的***日志均由所述LCS算法处理得到相应的最长公共子序列，则出现频率大于或等于预设频率的最长公共子序列被记录为所述日志模型。

11.根据权利要求10所述的装置，其特征在于，每个组别内的每条***日志被按照该***日志包含的预设切割符号进行切分为一个字符序列，并由所述LCS算法对每个组别的所有字符序列进行处理得到相应的最长公共子序列。

12.根据权利要求8所述的装置，其特征在于，还包括：

生成单元，根据不匹配于所述日志模型库的***日志，生成新的日志模型；

添加单元，将所述新的日志模型添加至所述日志模型库中。

13.根据权利要求8所述的装置，其特征在于，所述确定单元用于：

根据当前应用场景，确定每个被匹配的日志模型对应的预设基准条数；

根据本次健壮性测试中的***日志条数与对应的所述预设基准条数之间的比较结果，确定***的健壮性。

14.根据权利要求13所述的装置，其特征在于，所述预设基准条数包括：

首次成功执行所述健壮性测试时，匹配于每个日志模型的***日志条数；

或者，最近一次成功执行所述健壮性测试时，匹配于每个日志模型的***日志条数。