0
0

【Go高性能】测试（单元测试、基准测试）

Go测试

介绍如何使用 Go 语言的标准库 testing 进行测试。

参考：①https://cloud.tencent.com/developer/article/2211864
②https://geektutu.com/post/quick-go-test.html#7-Benchmark-%E5%9F%BA%E5%87%86%E6%B5%8B%E8%AF%95

一、分类

在Go语言的世界里，testing包是进行单元测试和基准测试的核心组件。它不仅简化了测试流程，还通过简洁明了的API鼓励开发者编写高质量的测试代码。

Go 语言推荐测试文件和源代码文件放在一块，测试文件以 _test.go 结尾。

1. 单元测试

  • 功能: 测试单个函数/方法，报告测试失败、记录日志、设置测试状态等。
  • 示例: 在 func TestXxx(t *testing.T) 中使用，适用于验证代码的正确性。

2. 基准测试

  • 功能：用于基准测试（性能测试），记录执行时间和内存分配等性能指标。
  • 示例: 在 func BenchmarkXxx(b *testing.B) 中使用，适用于测量代码的性能。

二、基准测试

1. 介绍

要想改进程序的性能，首先要知道程序的当前性能。
benchmark 是 go 语言中用于测试基准性能的工具。该工具用于测试被测试函数的平均运行耗时、内存分配次数。主要适用于在已知性能瓶颈在哪里时的场景。通过对相同功能函数的不同实现的性能指标（平均运行耗时、平均内存分配次数）进行比较，以判断性能的优劣。

2. 基准测试基本原则

为了保证基准测试结果的相对稳定性，需要保持硬件环境的稳定。即：

  • 机器处于空闲状态
  • 机器关闭了节能模式
  • 避免使用虚拟机和云主机

不过如果单纯测试某个函数的性能，精准性要求也不高的话，没必要这么细致啦~

3. 使用testing包构建基准测试

Go的tesing包中内置了基准测试功能。在编写基准测试时基本和编写单元测试的原则相似：

  • 文件名必须以 _test.go 为后缀
  • 函数名必须以 BenchmarkXxxx开头
  • 基准测试函数的参数类型是 *Testing.B，而非 *Testing.T

需要测试函数：

funcsingleFunc(){
    time.Sleep(100* time.Millisecond)}

基准测试代码：

funcBenchmark_singleFunc(b *testing.B){for n :=0; n < b.N; n++{singleFunc()}}

3.1 执行基准测试

  1. 方法一：直接点击方法左侧运行在这里插入图片描述
  2. 方法二：使用 go test -bench=要测的方法名 ./方法所在包的相对路径 例如：go test -bench=singleFunc（已在函数所在包的路径下）
  • -bench 标记使用正则表达式来匹配要运行的基准测试函数名称。所以，最常用的方式是通过-bench . 标记来执行该包下的所有的基准函数。
  • 默认情况下，执行go test命令时 只会执行单元测试，而基准测试会被排除在外。所以，需要在 go test 命令中添加 -bench 标记，以执行基准测试。

基准测试报告每一列值对应的含义如下：

type BenchmarkResult struct{
    N         int// 迭代次数
    T         time.Duration // 基准测试花费的时间
    Bytes     int64// 一次迭代处理的字节数
    MemAllocs uint64// 总的分配内存的次数
    MemBytes  uint64// 总的分配内存的字节数}

测试结果：

1. goos: windows
2. goarch: amd64
3. pkg: method/f
4. Benchmark_singleFunc
5. Benchmark_singleFunc-610101990650 ns/op
5. PASS

关注指标：

  1. 第5行：Benchmark_singleFunc-6 10 101990650 ns/op
  • Benchmark_singleFunc: 这是基准测试的名称，表示测试的函数名。
  • -6: 这是运行基准测试的 goroutine 数量（并发数）。和运行该测试用例时的GOMAXPROCS值有关系，默认为启动时 Go 进程可见的 CPU 数。在这个例子中，6表示使用了 6 个 goroutine 来并行执行基准测试。
  • 10：是基准测试在测试期间执行的总次数（b.N 的值）。
  • 101990650 ns/op：是每次操作的平均耗时，单位是纳秒（ns）。

3.2 基准测试工作原理

每个基准函数被执行时都有一个b.N值，该值是由go运行时自动生成的， 代表基准函数应该执行的次数。

b.N 从 1 开始，基准函数默认要运行 1 秒，如果该函数的执行时间在 1 秒内就运行完了，那么就递增 b.N 的值，再重新再执行一次。

3.3 改进基准测试的准确性

3.3.1 -benchtime

基准测试运行的时间越长，迭代次数越多，最终的平均值结果越准确。

如果你的基准测试只执行了 100 次或 10 次迭代，那么最终得出的平均值可能会偏高。如果你的基准测试执行了上百万或十亿次迭代，那么得出的平均耗时将会非常准确。

可以使用 

-benchtime

标识指定基准测试执行的时间以调整迭代次数（即b.N的值），以便得到更准确的结果。例如：

PS E:\Program Data\GoProject\basic\method\f>go test -bench=singleFunc -benchtime=10s
goos: windows
goarch: amd64
pkg: method/f
Benchmark_singleFunc-6100103430246 ns/op
PASS
ok      method/f        13.644s

执行以上命令，直到其达到 b.N 的值需要花费超过 10 秒的时间才能返回。由于我们的运行时间增加了 10 倍，因此迭代的总次数也增加了 10 倍。结果（每次操作耗时 103430246ns/op) 没有太大的变化，说明我们的数据相对比较稳定，是我们所期望的。
如果你有一个基准测试运行了数百万次或数十亿次迭代，你可能会发现基准值不稳定，因为你的机器硬件的散热性能、内存局部性、后台进程、gc 等因素都会影响函数执行的时间。

3.3.2 -count

**通过 

-count

标志，可以指定基准测试跑多次，以消除上述的不稳定因素：**

go test -bench .-benchtime 2s -count 5 
goos: windows
goarch: amd64
pkg: method/f
Benchmark_singleFunc-622103056855 ns/op
Benchmark_singleFunc-621102299486 ns/op
Benchmark_singleFunc-622104436250 ns/op
Benchmark_singleFunc-621102005167 ns/op
Benchmark_singleFunc-621102501433 ns/op
PASS
ok      method/f        14.764s
3.3.3 -cpu
go test -bench .-cpu 1,2,4            
goos: windows
goarch: amd64
pkg: method/f
Benchmark_singleFunc                  10102037000 ns/op
Benchmark_singleFunc-210101757150 ns/op
Benchmark_singleFunc-410102318930 ns/op
PASS
ok      method/f        6.607s

该示例展示了分别用 CPU 为 1 核、2 核、4 核时运行基准测试的结果。

4. 使用benchstat工具比较基准测试(可跳过）

由于基准测试受电源管理、后台进程、散热的影响，所以对于任何一个基准测试来说，运行多次来求平均值是一个非常好的建议。

下面介绍一个由 Russ Cox 编写的工具：benchstat

% go get golang.org/x/perf/cmd/benchstat

benchstat 可以对一组基准测试的结果求平均值，并显示出对应的稳定性。这是函数在使用电池的电脑上执行的基准示例：

% go test -bench .-benchtime 2s -count 5| tee old.txt
goos: windows
goarch: amd64
pkg: method/f
Benchmark_singleFunc-622103056855 ns/op
Benchmark_singleFunc-621102299486 ns/op
Benchmark_singleFunc-622104436250 ns/op
Benchmark_singleFunc-621102005167 ns/op
Benchmark_singleFunc-621102501433 ns/op
PASS
ok      method/f        14.764s

% benchstat old.txt
name     time/op
singleFunc-6102.5ms ± 2%

平均操作耗时是102.5毫秒，并且误差在 +/-2%。

4.1 对比标准 benchmarks 和 benchstat

确定两组基准测试结果之间的差异可能是单调乏味且容易出错的。 Benchstat 可以帮助我们解决这个问题。

提示 : 保存基准运行的输出很有用，但你也可以保存生成它的二进制文件。 为此，请使用-c标志来保存测试二进制文件；我经常将这个二进制文件从.test重命名为.golden。

%go test -c
% mv fib.test fib.golden

为了比较新版本，我们编译了一个新的测试二进制文件并对它们都进行了基准测试，并使用benchstat对输出进行比较。

%go test -c
%./fib.golden -test.bench=.-test.count=10> old.txt
%./fib.test -test.bench=.-test.count=10>new.txt
% benchstat old.txt new.txt
name     old time/op  new time/op  delta
Fib20-844.3µs ± 6%25.6µs ± 2%-42.31%(p=0.000 n=10+10)

比较基准测试时需要检查三件事

  • 新老两次的方差。1-2% 是不错的， 3-5% 也还行，但是大于5%的话，可能不太可靠。 在比较一方具有高差异的基准时要小心，您可能看不到改进。
  • p值。p值低于0.05是比较好的情况，大于0.05则意味着基准测试结果可能没有统计学意义。
  • 样本不足。benchstat将报告它认为有效的新旧样本的数量，有时你可能只发现9个报告，即使你设置了-count=10。拒绝率小于10%一般是没问题的，而高于10%可能表明你的设置是不稳定的，也可能是比较的样本太少了。

5. 避免基准测试的启动耗时

有时候基准测试每次执行的时候会有一次启动配置耗时。b.ResetTimer() 函数可以用于忽略启动的累积耗时。如下

funcBenchmarkExpensive(b *testing.B){boringAndExpensiveSetup()//启动配置。默认这里的执行时间是被计算在内的
    b.ResetTimer()for n :=0; n < b.N; n++{//function under test}}

在上例代码中，使用 b.ResetTimer() 函数重置了基准测试的计时器

如果在每次循环迭代中，你有一些费时的配置逻辑，要使用 

b.StopTimer()

和 

b.StartTimer()

函数来暂定基准测试计时器。

funcBenchmarkComplicated(b *testing.B){for n :=0; n < b.N;n++{
        b.StopTimer()complicatedSetup()
        b.StartTimer()//function under test}}

6. 基准测试的内存分配

内存分配的次数和分配的大小跟基准测试的执行时间相关。在基准测试中有两种方式可以记录并输出内存分配：

  • 在代码中增加 b.ReportAllocs() 函数来告诉 testing 框架记录内存分配的数据。
  • 在go test命令中添加 -benchmem 标识来强制 testing 框架打印出所有基准测试的内存分配次数

方式一：代码中添加 b.ReportAllocs()

funcBenchmarkRead(b *testing.B){
    b.ReportAllocs()for n :=0; n < b.N; n++{//function under test}}

方式二：go test命令中添加 -benchmem标识

%go test -run=^$ -bench=.-benchmem bufio
goos: darwin
goarch: amd64
pkg: bufio
BenchmarkReaderCopyOptimal-81386054382.8 ns/op            16 B/op          1 allocs/op
BenchmarkReaderCopyUnoptimal-88511162137 ns/op              32 B/op          2 allocs/op
BenchmarkReaderCopyNoWriteTo-83790412850 ns/op           32800 B/op          3 allocs/op
BenchmarkReaderWriteToOptimal-84013404280 ns/op              16 B/op          1 allocs/op
BenchmarkWriterCopyOptimal-81413290482.7 ns/op            16 B/op          1 allocs/op
BenchmarkWriterCopyUnoptimal-810487898113 ns/op              32 B/op          2 allocs/op
BenchmarkWriterCopyNoReadFrom-83626762816 ns/op           32800 B/op          3 allocs/op
BenchmarkReaderEmpty-81857391639 ns/op            4224 B/op          3 allocs/op
BenchmarkWriterEmpty-82041264577 ns/op            4096 B/op          1 allocs/op
BenchmarkWriterFlush-88764351312.5 ns/op             0 B/op          0 allocs/op
PASS
ok      bufio   13.430s

第四列是每次操作的平均内存分配大小，单位是字节（B）。
第五列是每次操作的平均内存分配次数（allocations）。

三、单元测试

单元测试通常放置在与被测试文件同目录下的

_test.go

文件中。测试函数必须以

Test

开头，后接被测试函数名，接受一个

t *testing.T

参数。

1. Goland自动生成

  1. 把鼠标定在要测试的方法上面，右击选Generate，在这里插入图片描述在这里插入图片描述
  2. 生成测试文件在这里插入图片描述
  3. 增加测试数据在这里插入图片描述
  4. 运行测试 可以直接运行全部的测试方案，也可以自己选择想要运行的测试方案。

2. 常用断言方法

  • t.Error和t.Fatal：报告错误，后者还会终止测试。
  • t.Logf：记录日志信息。
  • t.Errorf：当条件不满足时，记录错误并继续执行后续测试。
标签： golang 单元测试 log4j
本文转载自: https://blog.csdn.net/peaceLT/article/details/141645127
版权归原作者 小哎呀 所有， 如有侵权，请联系我们删除。
登录后发布评论

“【Go高性能】测试（单元测试、基准测试）”的评论:

还没有评论
关于作者
...
overfit同步小助手
文章同步
相关阅读

信息安全工程师（83）Windows操作系统安全分析与防护

Linux下open函数详解

米思奇安装——Mac版本

MySQL 创建数据库

Ubuntu 解决Oh no Something has gone wrong 方法

深入了解 Jenkins、GitLab 和 SSH 密钥的配置与管理

鸿蒙HarmonyOS应用开发 | 仓颉开发语言Linux 版本工具链的支持与安装

文章导航