CN111078538B

CN111078538B - 基于jmh的规则自动化测试的方法

Info

Publication number: CN111078538B
Application number: CN201911199384.3A
Authority: CN
Inventors: 魏燕子; 范渊
Original assignee: DBAPPSecurity Co Ltd
Current assignee: DBAPPSecurity Co Ltd
Priority date: 2019-11-29
Filing date: 2019-11-29
Publication date: 2023-06-20
Anticipated expiration: 2039-11-29
Also published as: CN111078538A

Abstract

本发明提供了一种基于JMH的规则自动化测试的方法，包括以下步骤：1)、规则匹配；2)、测试规则的score。1.1)、将原始日志中的原始样例解析成json格式的数据发送到kafka的topic中，然后对kafka中的topic进行消费并将消费后的数据保存到文件中；1.2)、将步骤1.1得到的文件存放在规则测试的服务器上；1.3)、读取文件中的消费后的数据，根据其rawEvent字段将提取对应的值进行分词，将分词后的结果存放在HashSet中，并对分词后的结果进行hash，得到对应的hash值；1.4)、将分词之后的结果存放在在HashSet中；1.5)、测试规则是否出发告警；1.6)、结果文件的输出。本发明在规则匹配时不需要在服务器上运行就可以测试该条规则对应的数据样例是否可以出发该条规则的问题。

Description

基于JMH的规则自动化测试的方法

技术领域

本发明涉及一种自动化测试系统，具体涉及一种基于JMH的规则自动化测试的方法。

背景技术

JMH是由openjdk公司的开发java编译器的开发者们所开发的一个微基准测试框架，简而言之就是在method层面上的benchmark，精度可以精确到纳秒级别，JMH主要使用在当你已经找出了热点函数，而需要对热点函数进行进一步的优化时，就可以使用JMH对优化的效果进行定量的分析，目前用于比较多的是对于代码的微基准测试，实现的原理简单，测试的方式通过注解的形式进行测试，Mode表示JMH进行Benchmark时所使用的模式。通常是测量的维度不同，或是测量的方式不同。目前JMH共有四种模式。

由于现在的规则都是运行在job里面，测试规则的运行耗时以及规则匹配不是很方便，在这个测试工具中提供一个比较快捷的测试方式。

比较典型的使用场景：

1、一个函数有两种不同实现，不知道哪种实现性能更好。

2、想准确的知道某个方法需要执行多长时间，以及执行时间和输入参数之间的相关性；

3、对比接口不同实现在给定条件下的吞吐量；查看多少百分比的请求在多长时间内完成。

针对于目前的分析规则来说，规则生成工具只能验证这条规则写的是否正确，并不能测试这条规则的性能是多少，分析人员不能够去判断自己写的规则还有没有优化的空间。

因此，需要对现有技术进行改进。

发明内容

本发明要解决的技术问题是提供一种高效的基于JMH的规则自动化测试的方法。

为解决上述技术问题，本发明提供了一种基于JMH的规则自动化测试的方法，包括以下步骤：

1)、规则匹配；

2)、测试规则的score。

作为对本发明基于JMH的规则自动化测试的方法的改进：步骤1包括：

1.1)、将原始日志中的原始样例解析成json格式的数据发送到kafka的topic中，然后对kafka中的topic进行消费并将消费后的数据保存到文件中；

1.2)、将步骤1.1得到的文件存放在规则测试的服务器上；

1.3)、读取文件中的消费后的数据，根据其中的rawEvent字段将提取对应的值进行分词，将分词后的结果存放在HashSet中，并对分词后的结果进行hash，得到对应的hash值；

1.4)、将提取的字段进行分词，将分词之后的结果存放在在HashSet中；然后并对其进行hash；最后得到对应的hash值；使用分词器将原始样例的文件中的数据与提取的rawEvent字段分别进行hash；

1.5)、测试规则是否出发告警；

1.6)、结果文件的输出。

作为对本发明基于JMH的规则自动化测试的方法的进一步改进：步骤2包括：

2.1)、将原始数据解析为json格式的数据，放在一个数据集里面，提供测试规则的score；

2.2)、进行JMH测试；

2.3)、经过测试之后生成分数文件；

2.4)、处理生成的分数文件，输出报告；

2.5)、最终报告的输出。

作为对本发明基于JMH的规则自动化测试的方法的进一步改进：

在步骤1.2中：将文件存放在规则测试的服务器上的/root/data目录下。

步骤1.4包括：

1.4.1)、先读取原始样例的文件，获取对应的modelName对应的文件的内容；读取对应的文件里面的内容，对内容进行hash，然后保存在attachments.csv这个文件中；

1.4.2)、读取提取的解析之后的数据样例中的rawEvent字段，对该字段的value进行分词后进行计算分词后的hash值保存在输出的report.csv文件中。

步骤1.5包括：

1.5.1)、根据分析人员的规则tag以及规则生成工具的结合，将规则生成json格式的文件；本发明是去实现的是去读取生成之后的json格式文件，拿到规则的modelName以及规则的表达式将其存成一个实例对象，然后调用aviator的规则引擎去编译规则，最后得到数据和规则是否匹配的结果文件；

1.5.2)、检验规则是否写的正确，若正确，可以测试这条规则是否匹配；不正确，则报错输出。

步骤2.2包括：

2.2.1)、测试规则的平均耗时；

2.2.2)、测试规则的吞吐量；

2.2.3)、测试自定义的规则；

2.2.4)、测试四种模式的所有规则的性能；

2.2.5)、测试每一个分片的规则的平均耗时；

2.2.6)、测试全量规则的平均耗时。

该工具的使用方式：主要结合规则的生成工具和分析人员提供的规则来进行测试，下面是这个工具的使用方法。

1.需要选的参数的说明

type:这里选择的参数主要有7个，选择不同的type运行的mode，下面是各个参数的描述：

参数包括开启的规则平均的score、开启的规则吞吐量、自定义规则平均的score、规则的benchmark的四种模式、规则匹配、每一个分片的规则的平均score、所有规则的分数(包括开启和关闭的)；如图6所示；

2.写需要跑的规则的modelname，逗号分隔；如图7所示

规则的score的文件：测试规则的分区的时候需要上传的分数文件。如图8所示；

选择规则的tag和规则的打包分支。

规则的tag；如图9所示；

规则生成工具的分支；如图10所示；

规则自动化测试的分支；如图11所示。

本发明基于JMH的规则自动化测试的方法的技术优势为：

1、在规则匹配时不需要在服务器上运行就可以测试该条规则对应的数据样例是否可以出发该条规则的问题。

2、可以快速知道比较耗时的规则对其进行优化从而提高性能。

3、能够测试出在一个数据集中触发改该条规则的数据有哪些的问题，由于有些数据可以触发多条规则。

4、可以测试新增的规则的平均耗时，可以根据测试结果去查看新写的表达式是否还有优化的空间，去优化它，提升规则性能。

附图说明

下面结合附图对本发明的具体实施方式作进一步详细说明。

图1为本发明基于JMH的规则自动化测试的方法的流程图；

图2为运行规则score时的流程图

图3为实施例1中匹配结果的报告示例图；

图4为实施例1中数据样例的报告示例图；

图5为实施例1中运行score的报告示例图。

图6为各个参数的描述示意图；

图7为写需要跑的规则的modelname示意图；

图8为上传的分数文件示意图；

图9为规则的tag示意图；

图10为规则生成工具的分支示意图；

图11为规则自动化测试的分支示意图。

具体实施方式

下面结合具体实施例对本发明进行进一步描述，但本发明的保护范围并不仅限于此。

实施例1、基于JMH的规则自动化测试的方法，如图1-11所示，包括以下步骤：

A.规则匹配：

A1.原始样例：将原始日志发送到数据解析引擎--综合日志审计系统进行解析，然后将原始日志中的原始样例解析成json格式的数据发送到kafka的topic中，然后对kafka中的topic进行消费并将消费后的数据保存在文件中，存储的格式为一条json格式的数据(消费后的数据)为一行，直到所有的数据消费完为止形成最终的文件，方便后续的规则测试。

原始样例的格式：

"SecurityEye","DbAppSecurity","entryname","deviceName","172.16.100.58","0","0","/Dpi","kafka","1","1803071640260000615","1803071640260600536","2018-03-07 16:40:26","192.168.58.105","47276","00-0C-29-33-62-D1","202.101.172.35","53","10-05-CA-C0-16-42","UDP","DNS","13fag23gewrgagfwerg.onion.rip","AAAA","IN","0","","onion.rip SOA INf1g1ns1.onion.rip","","0","局域网","局域网","","中国","浙江","杭州"

综合日志审计系统指的是：对客户网络设备、安全设备、主机和应用系统日志进行全面的标准化处理，支持解析的数据有以下几种协议采集的日志：Syslog、SNMP、OPSec、XML、FTP及本地文件。

解析之后的数据格式如下：

{"destGeoRegion":"未知","srcGeoAddress":"局域网","srcPort":"0","securityTypeName":"设备异常","deviceAssetSubTypeId":"38","severityType":"高","eventType":"1","mapperIdentifier":"6a0bf262-556e-4aeb-930e-4dc313d2f3f2","endTime":"2011-03-30 15:09:30","destGeoCity":"未知","startTime":"2011-03-30 15:09:30","collectorReceiptTime":"2019-01-08 10:21:12","customerId":"2","eventId":"5035329670170549249","deviceName":"Karry","deviceCat":"/Audit/Database","name":"规则所产生的告警数超过设定门限","deviceAssetType":"应用类","rawEvent":"dbapp本主机～1～2011-03-3015:09:30～192.168.58.105:0～127.0.0.1:0～系统告警～高～1103301509303341570～规则[什么为什么不为什么]所产生的告警数超过设定门限[123456789条],将不再继续产生告警,请检查该规则是否存在问题\r\n"}

A2.将步骤A1得到的最终的文件存放在规则测试的该台服务器上的指定的目录下，为后续测试做准备。

A3.程序实现读取文件中每一行数据，一行数据也是发送到Kafka中消费后的一条数据，消费后的数据是json格式的数据；

A4.根据消费后的数据(json格式)中的rawEvent字段将提取对应的值进行分词，将分词之后的结果存放在在HashSet中。然后并对其进行hash，得到对应的hash值。即是使用分词器将原始样例的文件中的数据和解析后的数据中提取的rawEvent字段分别进行hash。

提取的rawEvent字段格式如下：

"rawEvent":"dbapp本主机～1～2011-03-3015:09:30～192.168.58.105:0～127.0.0.1:0～系统告警～高～1103301509303341570～规则[什么为什么不为什么]所产生的告警数超过设定门限[123456789条],将不再继续产生告警,请检查该规则是否存在问题\r\n"。

分词是指：使用lucene的分词器StandardAnalyzer进行对原始日志和rawEvent字段的值进行分词，然后分词后的结果进行hash。

使用lucene的分词器StandardAnalyzer进行对原始日志和rawEvent字段的值进行分词计算hash值，然后进行对比，如果hash值相同，证明这个两个是同一条数据。

例如，分词之前字符串为：

我喜欢你，我的祖国！china中国,I love you！中华人民共和国。

分词之后变成：

[我],[喜],[欢],[你],[我],[的],[祖],[国],[china],[中],[国],[i],[love],[you],[中],[华],[人],[民],[共],[和],[国]。

下面是该工具中需要被分词的内容的详细描述。

A4.1、先读取原始样例的文件，获取对应的modelName对应的文件的内容。读取对应的文件里面的内容，对内容进行hash，然后保存在attachments.csv这个文件中。这里的modelName是指规则英文名称。

由于原始样例是预先整理好的，每一个规则模型的样例数据对应一个文本文件，并且每个文本文件的命名是以规则的modelName来命名的，在读取文件的同时，可以得到每个规则模型的样例数据以及model Name。

A4.2、读取步骤A3得到Kafka中消费后的数据中的rawEvent字段，这个rawEvent字段是综合日志审计系统中解析的数据(原始日志中的原始样例)都会带有该字段，该字段是存放原始样例的，对该字段的value进行分词后进行计算分词后的hash值保存在输出的report.csv文件中。

A5.测试规则是否出发告警；

A5.1、根据分析人员的规则tag以及规则生成工具的结合，将规则生成json格式的文件。去读取生成之后的json格式的规则文件，得到规则(json格式的规则文件)的modelName以及规则的表达式(expression的字段对应的值)将其存成一个实例对象，然后调用aviator的规则引擎去编译规则，最后得到数据和规则是否匹配的结果文件。

编译没有通过是expression这个字段写的有问题，会报表达式编译错误的信息。

A5.1.1、json格式的文件是指结合规则生成工具生成的规则文件，生成规则json格式的文件的方法主要是使用规则生成工具，读取分析人员提供的cdps_rules.csv文件，最后将cdps_rules..csv文件处理成json格式的规则文件，这个json格式的文件名称是cdps_rules.json；

A5.1.2、从cdps_rules.json格式的规则文件中获取expression字段的值，调用函数ELExpression evaluator的evaluator.evaluate(map,tr.getExp())，这个函数传递的参数是map和一个字符串tr.getExp()，map存储样例数据，这个样例数据map是步骤A2中存放的数据(最终的文件中的数据)，通过写代码实现读取A2中的文件的数据，存放在map中，tr.getExp()指的是从cdps_rules.json文件中获取expression字段的值，调用规则引擎中的函数ELExpression evaluator的evaluator.evaluate(map,tr.getExp())对解析之后的样例数据和expression字段的值进行编译，如果匹配成功，返回true，即匹配成功。反之返回false。

匹配的方式是根据expression这个字段对应的值去匹配，这个字段的值可能是正则或者是一个表达式，调用规则引擎去匹配的原理是使用expression这个字段的值去和map中的所有数据进行匹配，遍历完所有的数据，如果expression这个字段的值与在这个map中存储的数据进行匹配，只要有满足条件的数据，即匹配成功。反之匹配失败。

匹配成功输出报告中匹配的数据栏(即为步骤A6中的report.csv这个文件中的是否有样例匹配这一栏)具体的匹配数据。若匹配失败，输出报告中匹配的数据栏(即为步骤A6中的report.csv这个文件中的是否有样例匹配这一栏)为空，编译失败，会把具体错误信息也一起输出到报告中。

json格式的文件内容如下所示:

A5.2检验规则是否写的正确。若正确，可以测试这条规则是否匹配。不正确，则报错输出。检验规则是否正确是在A5.1中，调用规则引擎的函数去编译ELExpressionevaluator的evaluator.compile(tr.getExp()),如果编译失败，就会报错，然后就规则不走匹配数据的过程，直接把这条规则保存，即是规则错误，反之为规则正确。如果匹配成功则就是正确的规则。匹配失败的话规则可能是没有满足条件的数据，可能是规则错误，但是在报告文件中，错误的规则会在最后输出。

A6.结果文件的输出：

原始样例的文件：attachments.csv

该文件存放的是数据样例经过处理之后的文件，方便分析员根据hash值查找对应的原始样例。该文件包含三列：分别是提供数据样例的规则的modelName、原始日志的hash(该值可以在步骤A4.1中得到的hash值)、原始的数据样例。

匹配结果的文件：report.csv

该文件保存的是规则匹配结果，文件中包含5列，分别是规则model Name，提供的样例的hash值(该值为步骤A4.2得到的分词后的hash值)、是否有样例匹配、是否满足提供的样例的匹配、备注。

B.测试规则的score

B1.原始数据：将原始样例解析为json格式的数据，放在一个数据集里面，提供测试规则的score。

如下所示的数据格式：{"destGeoRegion":"未知","srcGeoAddress":"局域网","srcPort":"0","securityTypeName":"设备异常","deviceAssetSubTypeId":"38","severityType":"高","eventType":"1","mapperIdentifier":"6a0bf262-556e-4aeb-930e-4dc313d2f3f2","endTime":"2011-03-30 15:09:30","destGeoCity":"未知","startTime":"2011-03-3015:09:30","collectorReceiptTime":"2019-01-08 10:21:12","customerId":"2","eventId":"5035329670170549249","deviceName":"Karry","deviceCat":"/Audit/Database","name":"规则所产生的告警数超过设定门限","deviceAssetType":"应用类","rawEvent":"dbapp本主机～1～2011-03-3015:09:30～192.168.58.105:0～127.0.0.1:0～系统告警～高～1103301509303341570～规则[什么为什么不为什么]所产生的告警数超过设定门限[123456789条],将不再继续产生告警,请检查该规则是否存在问题\r\n"}

B2.JMH测试

B2.1测试规则的平均耗时：该功能主要是使用JMH的Mode的average模式，测试的是enable为true的规则平均耗时，测试时间是毫秒。

B2.2测试规则的吞吐量：要是使用JMH的Mode的ThroughPut模式，测试的是enable为true的规则吞吐量，测试时间是秒。

B2.3测试自定义的规则：用户自己选择想要测试的规则，只需要写测试的modelName即可，主要是测试某一条规则平均耗时。

B2.4测试四种模式的所有规则的性能：主要是使用JMH的mode的all模式，测试全量规则的各种模式下的规则耗时，主要是average、ThroughPut、SampleTime、SingleShotTime。

B2.5测试每一个分片的规则的平均耗时。由于规则生成工具会将规则生成不同的分区，每个分区的规则数量不同，所以该工具可以测试每个分区的规则的平均耗时，一般在10毫秒内为最佳。

B2.6测试全量规则的平均耗时：该模式主要测试的规则是包括开启和未开启的规则的平均耗时。

B3.生成分数文件：经过测试之后，生成一个bench.txt的文件。该文件的包含了运行的日志，需要对其进行处理之后才能输出。

该文件的格式如下：

#VM options:-javaagent:E:\idea\IntelliJ IDEA 2017.2.5\lib\idea_rt.jar＝63152:E:\idea\IntelliJ IDEA 2017.2.5\bin-Dfile.encoding＝UTF-8

#Warmup:1iterations,10s each

#Measurement:5iterations,10s each

#Timeout:10min per iteration

#Threads:1thread,will synchronize iterations

#Benchmark mode:Average time,time/op

#Benchmark:com.dbapp.cdps.benchmark.EnableRuleBenchmark.baseline

#Parameters:(mark＝bruteforce)

#Run progress:0.00％complete,ETA 04:58:00

#Fork:1of 1

#Warmup Iteration 1:0.177ms/op

Iteration 1:0.149ms/op

Iteration 2:0.149ms/op

Iteration 3:

B4.处理生成的分数文件bench.txt文件，将bench.txt文件输出报告，如图5所示。

bench.txt文件还可以处理成特定格式：由于bench.txt这个文件的内容不符合所需的内容，写程序提取需要的字段，然后存储报告文件，主要提取方式如下所示：

B5.最终报告的输出；

输出步骤A6和B4的报告。

最后，还需要注意的是，以上列举的仅是本发明的若干个具体实施例。显然，本发明不限于以上实施例，还可以有许多变形。本领域的普通技术人员能从本发明公开的内容直接导出或联想到的所有变形，均应认为是本发明的保护范围。

Claims

1.基于JMH的规则自动化测试的方法，其特征在于：包括以下步骤：

1）、规则匹配；

步骤1）包括：

1.1）、将原始日志发送到数据解析引擎--综合日志审计系统进行解析，将原始日志中的原始样例解析成json格式的数据发送到kafka的topic中，然后对kafka中的topic进行消费并将消费后的数据保存到文件中；

综合日志审计系统指的是：对客户网络设备、安全设备、主机和应用系统日志进行全面的标准化处理，支持解析的数据有以下几种协议采集的日志：Syslog、SNMP、OPSec、XML、FTP及本地文件；

1.2）、将步骤1.1）得到的文件存放在规则测试的服务器上；

1.3）、读取文件中的消费后的数据，根据其中的rawEvent字段将提取对应的值进行分词，将分词后的结果存放在HashSet中，并对分词后的结果进行hash，得到对应的hash值；

1.4）、将提取的字段进行分词，将分词之后的结果存放在在HashSet中；然后并对其进行hash；最后得到对应的hash值；使用分词器将原始样例的文件中的数据与提取的rawEvent字段分别进行hash；

步骤1.4）包括：

1.4.1）、先读取原始样例的文件，获取对应的modelName对应的文件的内容；读取对应的文件里面的内容，对内容进行hash，然后保存在attachments.csv这个文件中；

1.4.2）、读取提取的解析之后的数据样例中的rawEvent字段，对该字段的value进行分词后进行计算分词后的hash值保存在输出的report.csv文件中；

1.5）、测试规则是否触发告警；

步骤1.5）包括：

1.5.1）、根据分析人员的规则tag以及规则生成工具的结合，将规则生成json格式的文件；去读取生成之后的json格式文件，拿到规则的modelName以及规则的表达式将其存成一个实例对象，然后调用aviator的规则引擎去编译规则，最后得到数据和规则是否匹配的结果文件；

1.5.2）、检验规则是否写的正确，若正确，可以测试这条规则是否匹配；不正确，则报错输出；

1.6）、结果文件的输出；

2）、测试规则的score；

步骤2）包括：

2.1）、将原始数据解析为json格式的数据，放在一个数据集里面，提供测试规则的score；

2.2）、进行JMH测试；

2.3）、经过测试之后生成分数文件；

2.4）、处理生成的分数文件，输出报告；

2.5）、最终报告的输出。

2.根据权利要求1所述的基于JMH的规则自动化测试的方法，其特征在于：

在步骤1.2）中：将文件存放在规则测试的服务器上的/root/data目录下。

3.根据权利要求2所述的基于JMH的规则自动化测试的方法，其特征在于：

步骤2.2）包括：

2.2.1）、测试规则的平均耗时；

2.2.2）、测试规则的吞吐量；

2.2.3）、测试自定义的规则；

2.2.4）、测试四种模式的所有规则的性能；

2.2.5）、测试每一个分片的规则的平均耗时；

2.2.6）、测试全量规则的平均耗时。