mirror of
https://github.com/gopl-zh/gopl-zh.github.com.git
synced 2026-01-15 11:47:14 +08:00
fix typo and optimize.
Change-Id: I7b6938936231fd722814984678ffa30402539fd9
This commit is contained in:
fuyc
@@ -1,4 +1,4 @@
|
||||
### 11.2.4. 扩展测试包
|
||||
### 11.2.4. 外部测试包
|
||||
|
||||
考虑下这两个包：net/url包，提供了URL解析的功能；net/http包，提供了web服务和HTTP客户端的功能。如我们所料，上层的net/http包依赖下层的net/url包。然后，net/url包中的一个测试是演示不同URL和HTTP客户端的交互行为。也就是说，一个下层包的测试代码导入了上层的包。
|
||||
|
||||
@@ -6,15 +6,15 @@
|
||||
|
||||
这样的行为在net/url包的测试代码中会导致包的循环依赖，正如图11.1中向上箭头所示，同时正如我们在10.1节所讲的，Go语言规范是禁止包的循环依赖的。
|
||||
|
||||
不过我们可以通过测试扩展包的方式解决循环依赖的问题，也就是在net/url包所在的目录声明一个独立的url_test测试扩展包。其中测试扩展包名的`_test`后缀告诉go test工具它应该建立一个额外的包来运行测试。我们将这个扩展测试包的导入路径视作是net/url_test会更容易理解，但实际上它并不能被其他任何包导入。
|
||||
不过我们可以通过外部测试包的方式解决循环依赖的问题，也就是在net/url包所在的目录声明一个独立的url_test测试包。其中包名的`_test`后缀告诉go test工具它应该建立一个额外的包来运行测试。我们将这个外部测试包的导入路径视作是net/url_test会更容易理解，但实际上它并不能被其他任何包导入。
|
||||
|
||||
因为测试扩展包是一个独立的包，所以可以导入测试代码依赖的其他的辅助包；包内的测试代码可能无法做到。在设计层面，测试扩展包是在所以它依赖的包的上层，正如图11.2所示。
|
||||
因为外部测试包是一个独立的包，所以能够导入那些`依赖待测代码本身`的其他辅助包；包内的测试代码就无法做到这点。在设计层面，外部测试包是在所有它依赖的包的上层，正如图11.2所示。
|
||||
|
||||
|
||||
|
||||
通过回避循环导入依赖，扩展测试包可以更灵活的编写测试，特别是集成测试（需要测试多个组件之间的交互），可以像普通应用程序那样自由地导入其他包。
|
||||
通过避免循环的导入依赖，外部测试包可以更灵活地编写测试，特别是集成测试（需要测试多个组件之间的交互），可以像普通应用程序那样自由地导入其他包。
|
||||
|
||||
我们可以用go list命令查看包对应目录中哪些Go源文件是产品代码，哪些是包内测试，还哪些测试扩展包。我们以fmt包作为一个例子：GoFiles表示产品代码对应的Go源文件列表；也就是go build命令要编译的部分。
|
||||
我们可以用go list命令查看包对应目录中哪些Go源文件是产品代码，哪些是包内测试，还有哪些是外部测试包。我们以fmt包作为一个例子：GoFiles表示产品代码对应的Go源文件列表；也就是go build命令要编译的部分。
|
||||
|
||||
{% raw %}
|
||||
|
||||
@@ -38,7 +38,7 @@ $ go list -f={{.TestGoFiles}} fmt
|
||||
|
||||
包的测试代码通常都在这些文件中，不过fmt包并非如此；稍后我们再解释export_test.go文件的作用。
|
||||
|
||||
XTestGoFiles表示的是属于测试扩展包的测试代码，也就是fmt_test包，因此它们必须先导入fmt包。同样，这些文件也只是在测试时被构建运行：
|
||||
XTestGoFiles表示的是属于外部测试包的测试代码，也就是fmt_test包，因此它们必须先导入fmt包。同样，这些文件也只是在测试时被构建运行：
|
||||
|
||||
{% raw %}
|
||||
|
||||
@@ -49,11 +49,11 @@ $ go list -f={{.XTestGoFiles}} fmt
|
||||
|
||||
{% endraw %}
|
||||
|
||||
有时候测试扩展包也需要访问被测试包内部的代码，例如在一个为了避免循环导入而被独立到外部测试扩展包的白盒测试。在这种情况下，我们可以通过一些技巧解决：我们在包内的一个_test.go文件中导出一个内部的实现给测试扩展包。因为这些代码只有在测试时才需要，因此一般会放在export_test.go文件中。
|
||||
有时候外部测试包也需要访问被测试包内部的代码，例如在一个为了避免循环导入而被独立到外部测试包的白盒测试。在这种情况下，我们可以通过一些技巧解决：我们在包内的一个_test.go文件中导出一个内部的实现给外部测试包。因为这些代码只有在测试时才需要，因此一般会放在export_test.go文件中。
|
||||
|
||||
例如，fmt包的fmt.Scanf函数需要unicode.IsSpace函数提供的功能。但是为了避免太多的依赖，fmt包并没有导入包含巨大表格数据的unicode包；相反fmt包有一个叫isSpace内部的简易实现。
|
||||
|
||||
为了确保fmt.isSpace和unicode.IsSpace函数的行为一致，fmt包谨慎地包含了一个测试。是一个在测试扩展包内的白盒测试，是无法直接访问到isSpace内部函数的，因此fmt通过一个秘密出口导出了isSpace函数。export_test.go文件就是专门用于测试扩展包的秘密出口。
|
||||
为了确保fmt.isSpace和unicode.IsSpace函数的行为保持一致，fmt包谨慎地包含了一个测试。是一个在外部测试包内的白盒测试，是无法直接访问到isSpace内部函数的，因此fmt通过一个后门导出了isSpace函数。export_test.go文件就是专门用于外部测试包的后门。
|
||||
|
||||
```Go
|
||||
package fmt
|
||||
@@ -61,5 +61,5 @@ package fmt
|
||||
var IsSpace = isSpace
|
||||
```
|
||||
|
||||
这个测试文件并没有定义测试代码；它只是通过fmt.IsSpace简单导出了内部的isSpace函数，提供给测试扩展包使用。这个技巧可以广泛用于位于测试扩展包的白盒测试。
|
||||
这个测试文件并没有定义测试代码；它只是通过fmt.IsSpace简单导出了内部的isSpace函数，提供给外部测试包使用。这个技巧可以广泛用于位于外部测试包的白盒测试。
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
### 11.2.5. 编写有效的测试
|
||||
|
||||
许多Go语言新人会惊异于它的极简的测试框架。很多其它语言的测试框架都提供了识别测试函数的机制（通常使用反射或元数据），通过设置一些“setup”和“teardown”的钩子函数来执行测试用例运行的初始化和之后的清理操作，同时测试工具箱还提供了很多类似assert断言，值比较函数，格式化输出错误信息和停止一个识别的测试等辅助函数（通常使用异常机制）。虽然这些机制可以使得测试非常简洁，但是测试输出的日志却会像火星文一般难以理解。此外，虽然测试最终也会输出PASS或FAIL的报告，但是它们提供的信息格式却非常不利于代码维护者快速定位问题，因为失败的信息的具体含义是非常隐晦的，比如“assert: 0 == 1”或成页的海量跟踪日志。
|
||||
许多Go语言新人会惊异于Go语言极简的测试框架。很多其它语言的测试框架都提供了识别测试函数的机制（通常使用反射或元数据），通过设置一些“setup”和“teardown”的钩子函数来执行测试用例运行的初始化和之后的清理操作，同时测试工具箱还提供了很多类似assert断言、值比较函数、格式化输出错误信息和停止一个失败的测试等辅助函数（通常使用异常机制）。虽然这些机制可以使得测试非常简洁，但是测试输出的日志却会像火星文一般难以理解。此外，虽然测试最终也会输出PASS或FAIL的报告，但是它们提供的信息格式却非常不利于代码维护者快速定位问题，因为失败信息的具体含义非常隐晦，比如“assert: 0 == 1”或成页的海量跟踪日志。
|
||||
|
||||
Go语言的测试风格则形成鲜明对比。它期望测试者自己完成大部分的工作，定义函数避免重复，就像普通编程那样。编写测试并不是一个机械的填空过程；一个测试也有自己的接口，尽管它的维护者也是测试仅有的一个用户。一个好的测试不应该引发其他无关的错误信息，它只要清晰简洁地描述问题的症状即可，有时候可能还需要一些上下文信息。在理想情况下，维护者可以在不看代码的情况下就能根据错误信息定位错误产生的原因。一个好的测试不应该在遇到一点小错误时就立刻退出测试，它应该尝试报告更多的相关的错误信息，因为我们可能从多个失败测试的模式中发现错误产生的规律。
|
||||
|
||||
下面的断言函数比较两个值，然后生成一个通用的错误信息，并停止程序。它很方便使用也确实有效果，但是当测试失败的时候，打印的错误信息却几乎是没有价值的。它并没有为快速解决问题提供一个很好的入口。
|
||||
下面的断言函数比较两个值，然后生成一个通用的错误信息，并停止程序。它很好用也确实有效，但是当测试失败的时候，打印的错误信息却几乎是没有价值的。它并没有为快速解决问题提供一个很好的入口。
|
||||
|
||||
```Go
|
||||
import (
|
||||
@@ -25,7 +25,7 @@ func TestSplit(t *testing.T) {
|
||||
}
|
||||
```
|
||||
|
||||
从这个意义上说，断言函数犯了过早抽象的错误：仅仅测试两个整数是否相同，而放弃了根据上下文提供更有意义的错误信息的做法。我们可以根据具体的错误打印一个更有价值的错误信息，就像下面例子那样。测试在只有一次重复的模式出现时引入抽象。
|
||||
从这个意义上说，断言函数犯了过早抽象的错误：仅仅测试两个整数是否相同，而没能根据上下文提供更有意义的错误信息。我们可以根据具体的错误打印一个更有价值的错误信息，就像下面例子那样。只有在测试中出现重复模式是才采用抽象。
|
||||
|
||||
```Go
|
||||
func TestSplit(t *testing.T) {
|
||||
@@ -41,7 +41,7 @@ func TestSplit(t *testing.T) {
|
||||
|
||||
现在的测试不仅报告了调用的具体函数、它的输入和结果的意义；并且打印的真实返回的值和期望返回的值；并且即使断言失败依然会继续尝试运行更多的测试。一旦我们写了这样结构的测试，下一步自然不是用更多的if语句来扩展测试用例，我们可以用像IsPalindrome的表驱动测试那样来准备更多的s和sep测试用例。
|
||||
|
||||
前面的例子并不需要额外的辅助函数，如果有可以使测试代码更简单的方法我们也乐意接受。（我们将在13.3节看到一个类似reflect.DeepEqual辅助函数。）开始一个好的测试的关键是通过实现你真正想要的具体行为，然后才是考虑然后简化测试代码。最好的接口是直接从库的抽象接口开始，针对公共接口编写一些测试函数。
|
||||
前面的例子并不需要额外的辅助函数，如果有可以使测试代码更简单的方法我们也乐意接受。（我们将在13.3节看到一个类似reflect.DeepEqual辅助函数。）一个好的测试的关键是首先实现你期望的具体行为，然后才是考虑简化测试代码、避免重复。如果直接从抽象、通用的测试库着手，很难取得良好结果。
|
||||
|
||||
**练习11.5:** 用表格驱动的技术扩展TestSplit测试，并打印期望的输出结果。
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
### 11.2.6. 避免的不稳定的测试
|
||||
### 11.2.6. 避免脆弱的测试
|
||||
|
||||
如果一个应用程序对于新出现的但有效的输入经常失败说明程序不够稳健；同样如果一个测试仅仅因为声音变化就会导致失败也是不合逻辑的。就像一个不够稳健的程序会挫败它的用户一样，一个脆弱性测试同样会激怒它的维护者。最脆弱的测试代码会在程序没有任何变化的时候产生不同的结果，时好时坏，处理它们会耗费大量的时间但是并不会得到任何好处。
|
||||
如果一个应用程序对于新出现的但有效的输入经常失败说明程序容易出bug（不够稳健）；同样，如果一个测试仅仅对程序做了微小变化就失败则称为脆弱。就像一个不够稳健的程序会挫败它的用户一样，一个脆弱的测试同样会激怒它的维护者。最脆弱的测试代码会在程序没有任何变化的时候产生不同的结果，时好时坏，处理它们会耗费大量的时间但是并不会得到任何好处。
|
||||
|
||||
当一个测试函数产生一个复杂的输出如一个很长的字符串，或一个精心设计的数据结构或一个文件，它可以用于和预设的“golden”结果数据对比，用这种简单方式写测试是诱人的。但是随着项目的发展，输出的某些部分很可能会发生变化，尽管很可能是一个改进的实现导致的。而且不仅仅是输出部分，函数复杂复制的输入部分可能也跟着变化了，因此测试使用的输入也就不在有效了。
|
||||
当一个测试函数会产生一个复杂的输出如一个很长的字符串、一个精心设计的数据结构或一个文件时，人很容易想预先写下一系列固定的用于对比的标杆数据。但是随着项目的发展，有些输出可能会发生变化，尽管很可能是一个改进的实现导致的。而且不仅仅是输出部分，函数复杂的输入部分可能也跟着变化了，因此测试使用的输入也就不再有效了。
|
||||
|
||||
避免脆弱测试代码的方法是只检测你真正关心的属性。保持测试代码的简洁和内部结构的稳定。特别是对断言部分要有所选择。不要检查字符串的全匹配，但是寻找相关的子字符串，因为某些子字符串在项目的发展中是比较稳定不变的。通常编写一个重复杂的输出中提取必要精华信息以用于断言是值得的，虽然这可能会带来很多前期的工作，但是它可以帮助迅速及时修复因为项目演化而导致的不合逻辑的失败测试。
|
||||
避免脆弱测试代码的方法是只检测你真正关心的属性。保持测试代码的简洁和内部结构的稳定。特别是对断言部分要有所选择。不要对字符串进行全字匹配，而是针对那些在项目的发展中是比较稳定不变的子串。很多时候值得花力气来编写一个从复杂输出中提取用于断言的必要信息的函数，虽然这可能会带来很多前期的工作，但是它可以帮助迅速及时修复因为项目演化而导致的不合逻辑的失败测试。
|
||||
|
||||
|
||||
@@ -209,7 +209,7 @@ ok gopl.io/ch11/word2 0.015s
|
||||
|
||||
如果我们真的需要停止测试，或许是因为初始化失败或可能是早先的错误导致了后续错误等原因，我们可以使用t.Fatal或t.Fatalf停止当前测试函数。它们必须在和测试函数同一个goroutine内调用。
|
||||
|
||||
测试失败的信息一般的形式是“f(x) = y, want z”，其中f(x)解释了失败的操作和对应的输出，y是实际的运行结果，z是期望的正确的结果。就像前面检查回文字符串的例子，实际的函数用于f(x)部分。如果显示x是表格驱动型测试中比较重要的部分，因为同一个断言可能对应不同的表格项执行多次。要避免无用和冗余的信息。在测试类似IsPalindrome返回布尔类型的函数时，可以忽略并没有额外信息的z部分。如果x、y或z是y的长度，输出一个相关部分的简明总结即可。测试的作者应该要努力帮助程序员诊断测试失败的原因。
|
||||
测试失败的信息一般的形式是“f(x) = y, want z”，其中f(x)解释了失败的操作和对应的输出，y是实际的运行结果，z是期望的正确的结果。就像前面检查回文字符串的例子，实际的函数用于f(x)部分。显示x是表格驱动型测试中比较重要的部分，因为同一个断言可能对应不同的表格项执行多次。要避免无用和冗余的信息。在测试类似IsPalindrome返回布尔类型的函数时，可以忽略并没有额外信息的z部分。如果x、y或z是y的长度，输出一个相关部分的简明总结即可。测试的作者应该要努力帮助程序员诊断测试失败的原因。
|
||||
|
||||
**练习 11.1:** 为4.3节中的charcount程序编写测试。
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
## 11.3. 测试覆盖率
|
||||
|
||||
就其性质而言，测试不可能是完整的。计算机科学家Edsger Dijkstra曾说过：“测试可以显示存在缺陷，但是并不是说没有BUG。”再多的测试也不能证明一个程序没有BUG。在最好的情况下，测试可以增强我们的信心：代码在我们测试的环境是可以正常工作的。
|
||||
就其性质而言，测试不可能是完整的。计算机科学家Edsger Dijkstra曾说过：“测试能证明缺陷存在，而无法证明没有缺陷。”再多的测试也不能证明一个程序没有BUG。在最好的情况下，测试可以增强我们的信心：代码在很多重要场景下是可以正常工作的。
|
||||
|
||||
由测试驱动触发运行到的被测试函数的代码数目称为测试的覆盖率。测试覆盖率并不能量化——甚至连最简单的动态程序也难以精确测量——但是可以启发并帮助我们编写的有效的测试代码。
|
||||
对待测程序执行的测试的程度称为测试的覆盖率。测试覆盖率并不能量化——即使最简单的程序的动态也是难以精确测量的——但是有启发式方法来帮助我们编写的有效的测试代码。
|
||||
|
||||
这些帮助信息中语句的覆盖率是最简单和最广泛使用的。语句的覆盖率是指在测试中至少被运行一次的代码占总代码数的比例。在本节中，我们使用`go test`命令中集成的测试覆盖率工具，来度量下面代码的测试覆盖率，帮助我们识别测试和我们期望间的差距。
|
||||
这些启发式方法中，语句的覆盖率是最简单和最广泛使用的。语句的覆盖率是指在测试中至少被运行一次的代码占总代码数的比例。在本节中，我们使用`go test`命令中集成的测试覆盖率工具，来度量下面代码的测试覆盖率，帮助我们识别测试和我们期望间的差距。
|
||||
|
||||
下面的代码是一个表格驱动的测试，用于测试第七章的表达式求值程序：
|
||||
|
||||
@@ -77,7 +77,7 @@ $ go test -run=Coverage -coverprofile=c.out gopl.io/ch7/eval
|
||||
ok gopl.io/ch7/eval 0.032s coverage: 68.5% of statements
|
||||
```
|
||||
|
||||
这个标志参数通过在测试代码中插入生成钩子来统计覆盖率数据。也就是说，在运行每个测试前，它会修改要测试代码的副本，在每个词法块都会设置一个布尔标志变量。当被修改后的被测试代码运行退出时，将统计日志数据写入c.out文件，并打印一部分执行的语句的一个总结。（如果你需要的是摘要，使用`go test -cover`。）
|
||||
这个标志参数通过在测试代码中插入生成钩子来统计覆盖率数据。也就是说，在运行每个测试前，它将待测代码拷贝一份并做修改，在每个词法块都会设置一个布尔标志变量。当被修改后的被测试代码运行退出时，将统计日志数据写入c.out文件，并打印一部分执行的语句的一个总结。（如果你需要的是摘要，使用`go test -cover`。）
|
||||
|
||||
如果使用了`-covermode=count`标志参数，那么将在每个代码块插入一个计数器而不是布尔标志量。在统计结果中记录了每个块的执行次数，这可以用于衡量哪些是被频繁执行的热点代码。
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ func BenchmarkIsPalindrome(b *testing.B) {
|
||||
}
|
||||
```
|
||||
|
||||
我们用下面的命令运行基准测试。和普通测试不同的是，默认情况下不运行任何基准测试。我们需要通过`-bench`命令行标志参数手工指定要运行的基准测试函数。该参数是一个正则表达式，用于匹配要执行的基准测试函数的名字，默认值是空的。其中“.”模式将可以匹配所有基准测试函数，但是这里总共只有一个基准测试函数，因此和`-bench=IsPalindrome`参数是等价的效果。
|
||||
我们用下面的命令运行基准测试。和普通测试不同的是，默认情况下不运行任何基准测试。我们需要通过`-bench`命令行标志参数手工指定要运行的基准测试函数。该参数是一个正则表达式，用于匹配要执行的基准测试函数的名字，默认值是空的。其中“.”模式将可以匹配所有基准测试函数，但因为这里只有一个基准测试函数，因此和`-bench=IsPalindrome`参数是等价的效果。
|
||||
|
||||
```
|
||||
$ cd $GOPATH/src/gopl.io/ch11/word2
|
||||
@@ -24,13 +24,13 @@ BenchmarkIsPalindrome-8 1000000 1035 ns/op
|
||||
ok gopl.io/ch11/word2 2.179s
|
||||
```
|
||||
|
||||
结果中基准测试名的数字后缀部分，这里是8，表示运行时对应的GOMAXPROCS的值，这对于一些和并发相关的基准测试是重要的信息。
|
||||
结果中基准测试名的数字后缀部分，这里是8，表示运行时对应的GOMAXPROCS的值，这对于一些与并发相关的基准测试是重要的信息。
|
||||
|
||||
报告显示每次调用IsPalindrome函数花费1.035微秒，是执行1,000,000次的平均时间。因为基准测试驱动器开始时并不知道每个基准测试函数运行所花的时间，它会尝试在真正运行基准测试前先尝试用较小的N运行测试来估算基准测试函数所需要的时间，然后推断一个较大的时间保证稳定的测量结果。
|
||||
|
||||
循环在基准测试函数内实现，而不是放在基准测试框架内实现，这样可以让每个基准测试函数有机会在循环启动前执行初始化代码，这样并不会显著影响每次迭代的平均运行时间。如果还是担心初始化代码部分对测量时间带来干扰，那么可以通过testing.B参数提供的方法来临时关闭或重置计时器，不过这些一般很少会用到。
|
||||
|
||||
现在我们有了一个基准测试和普通测试，我们可以很容易测试新的让程序运行更快的想法。也许最明显的优化是在IsPalindrome函数中第二个循环的停止检查，这样可以避免每个比较都做两次：
|
||||
现在我们有了一个基准测试和普通测试，我们可以很容易测试改进程序运行速度的想法。也许最明显的优化是在IsPalindrome函数中第二个循环的停止检查，这样可以避免每个比较都做两次：
|
||||
|
||||
```Go
|
||||
n := len(letters)/2
|
||||
@@ -42,7 +42,7 @@ for i := 0; i < n; i++ {
|
||||
return true
|
||||
```
|
||||
|
||||
不过很多情况下，一个明显的优化并不一定就能代码预期的效果。这个改进在基准测试中只带来了4%的性能提升。
|
||||
不过很多情况下，一个显而易见的优化未必能带来预期的效果。这个改进在基准测试中只带来了4%的性能提升。
|
||||
|
||||
```
|
||||
$ go test -bench=.
|
||||
@@ -89,9 +89,9 @@ BenchmarkIsPalindrome 2000000 807 ns/op 128 B/op 1 allocs/op
|
||||
|
||||
用一次内存分配代替多次的内存分配节省了75%的分配调用次数和减少近一半的内存需求。
|
||||
|
||||
这个基准测试告诉我们所需的绝对时间依赖给定的具体操作，两个不同的操作所需时间的差异也是和不同环境相关的。例如，如果一个函数需要1ms处理1,000个元素，那么处理10000或1百万将需要多少时间呢？这样的比较揭示了渐近增长函数的运行时间。另一个例子：I/O缓存该设置为多大呢？基准测试可以帮助我们选择较小的缓存但能带来满意的性能。第三个例子：对于一个确定的工作那种算法更好？基准测试可以评估两种不同算法对于相同的输入在不同的场景和负载下的优缺点。
|
||||
这个基准测试告诉了我们某个具体操作所需的绝对时间，但我们往往想知道的是两个不同的操作的时间对比。例如，如果一个函数需要1ms处理1,000个元素，那么处理10000或1百万将需要多少时间呢？这样的比较揭示了渐近增长函数的运行时间。另一个例子：I/O缓存该设置为多大呢？基准测试可以帮助我们选择在性能达标情况下所需的最小内存。第三个例子：对于一个确定的工作哪种算法更好？基准测试可以评估两种不同算法对于相同的输入在不同的场景和负载下的优缺点。
|
||||
|
||||
一般比较基准测试都是结构类似的代码。它们通常是采用一个参数的函数，从几个标志的基准测试函数入口调用，就像这样：
|
||||
比较型的基准测试就是普通程序代码。它们通常是单参数的函数，由几个不同数量级的基准测试函数调用，就像这样：
|
||||
|
||||
```Go
|
||||
func benchmark(b *testing.B, size int) { /* ... */ }
|
||||
@@ -102,7 +102,7 @@ func Benchmark1000(b *testing.B) { benchmark(b, 1000) }
|
||||
|
||||
通过函数参数来指定输入的大小，但是参数变量对于每个具体的基准测试都是固定的。要避免直接修改b.N来控制输入的大小。除非你将它作为一个固定大小的迭代计算输入，否则基准测试的结果将毫无意义。
|
||||
|
||||
基准测试对于编写代码是很有帮助的，但是即使工作完成了也应当保存基准测试代码。因为随着项目的发展，或者是输入的增加，或者是部署到新的操作系统或不同的处理器，我们可以再次用基准测试来帮助我们改进设计。
|
||||
比较型的基准测试反映出的模式在程序设计阶段是很有帮助的，但是即使程序完工了也应当保留基准测试代码。因为随着项目的发展，或者是输入的增加，或者是部署到新的操作系统或不同的处理器，我们可以再次用基准测试来帮助我们改进设计。
|
||||
|
||||
**练习 11.6:** 为2.6.2节的练习2.4和练习2.5的PopCount函数编写基准测试。看看基于表格算法在不同情况下对提升性能会有多大帮助。
|
||||
|
||||
|
||||
@@ -2,21 +2,21 @@
|
||||
|
||||
测量基准(Benchmark)对于衡量特定操作的性能是有帮助的，但是当我们试图让程序跑的更快的时候，我们通常并不知道从哪里开始优化。每个码农都应该知道Donald Knuth在1974年的“Structured Programming with go to Statements”上所说的格言。虽然经常被解读为不重视性能的意思，但是从原文我们可以看到不同的含义：
|
||||
|
||||
> 毫无疑问，效率会导致各种滥用。程序员需要浪费大量的时间思考或者担心，被部分程序的速度所干扰，实际上这些尝试提升效率的行为可能产生强烈的负面影响，特别是当调试和维护的时候。我们不应该过度纠结于细节的优化，应该说约97%的场景：过早的优化是万恶之源。
|
||||
> 毫无疑问，对效率的片面追求会导致各种滥用。程序员会浪费大量的时间在非关键程序的速度上，实际上这些尝试提升效率的行为反倒可能产生很大的负面影响，特别是当调试和维护的时候。我们不应该过度纠结于细节的优化，应该说约97%的场景：过早的优化是万恶之源。
|
||||
>
|
||||
> 我们当然不应该放弃那关键的3%的机会。一个好的程序员不会因为这个理由而满足，他们会明智地观察和识别哪些是关键的代码；但是只有在关键代码已经被确认的前提下才会进行优化。对于很多程序员来说，判断哪部分是关键的性能瓶颈，是很容易犯经验上的错误的，因此这种情况下一般都会借助于工具去实现。
|
||||
> 当然我们也不应该放弃对那关键3%的优化。一个好的程序员不会因为这个比例小就裹足不前，他们会明智地观察和识别哪些是关键的代码；但是仅当关键代码已经被确认的前提下才会进行优化。对于很多程序员来说，判断哪部分是关键的性能瓶颈，是很容易犯经验上的错误的，因此一般应该借助测量工具来证明。
|
||||
|
||||
当我们想仔细观察我们程序的运行速度的时候，最好的技术是如何识别关键代码。自动化的剖析技术是基于程序执行期间一些抽样数据，然后推断后面的执行状态；最终产生一个运行时间的统计数据文件。
|
||||
当我们想仔细观察我们程序的运行速度的时候，最好的方法是性能剖析。剖析技术是基于程序执行期间一些自动抽样，然后在收尾时进行推断；最后产生的统计结果就称为剖析数据。
|
||||
|
||||
Go语言支持多种类型的剖析性能分析，每一种关注不同的方面，但它们都涉及到每个采样记录的感兴趣的一系列事件消息，每个事件都包含函数调用时函数调用堆栈的信息。内建的`go test`工具对几种分析方式都提供了支持。
|
||||
|
||||
CPU分析文件标识了函数执行时所需要的CPU时间。当前运行的系统线程在每隔几毫秒都会遇到操作系统的中断事件，每次中断时都会记录一个分析文件然后恢复正常的运行。
|
||||
CPU剖析数据标识了最耗CPU时间的函数。在每个CPU上运行的线程在每隔几毫秒都会遇到操作系统的中断事件，每次中断时都会记录一个剖析数据然后恢复正常的运行。
|
||||
|
||||
堆分析则记录了程序的内存使用情况。每个内存分配操作都会触发内部平均内存分配例程，每个512KB的内存申请都会触发一个事件。
|
||||
堆剖析则标识了最耗内存的语句。剖析库会记录调用内部内存分配的操作，平均每512KB的内存申请会触发一个剖析数据。
|
||||
|
||||
阻塞分析则记录了goroutine最大的阻塞操作，例如系统调用、管道发送和接收，还有获取锁等。分析库会记录每个goroutine被阻塞时的相关操作。
|
||||
阻塞剖析则记录阻塞goroutine最久的操作，例如系统调用、管道发送和接收，还有获取锁等。每当goroutine被这些操作阻塞时，剖析库都会记录相应的事件。
|
||||
|
||||
在测试环境下只需要一个标志参数就可以生成各种分析文件。当一次使用多个标志参数时需要当心，因为分析操作本身也可能会影像程序的运行。
|
||||
只需要开启下面其中一个标志参数就可以生成各种分析文件。当同时使用多个标志参数时需要当心，因为一项分析操作可能会影响其他项的分析结果。
|
||||
|
||||
```
|
||||
$ go test -cpuprofile=cpu.out
|
||||
@@ -24,13 +24,13 @@ $ go test -blockprofile=block.out
|
||||
$ go test -memprofile=mem.out
|
||||
```
|
||||
|
||||
对于一些非测试程序也很容易支持分析的特性，具体的实现方式和程序是短时间运行的小工具还是长时间运行的服务会有很大不同，因此Go的runtime运行时包提供了程序运行时控制分析特性的接口。
|
||||
对于一些非测试程序也很容易进行剖析，具体的实现方式，与程序是短时间运行的小工具还是长时间运行的服务会有很大不同。剖析对于长期运行的程序尤其有用，因此可以通过调用Go的runtime API来启用运行时剖析。
|
||||
|
||||
一旦我们已经收集到了用于分析的采样数据，我们就可以使用pprof来分析这些数据。这是Go工具箱自带的一个工具，但并不是一个日常工具，它对应`go tool pprof`命令。该命令有许多特性和选项，但是最重要的有两个，就是生成这个概要文件的可执行程序和对于的分析日志文件。
|
||||
一旦我们已经收集到了用于分析的采样数据，我们就可以使用pprof来分析这些数据。这是Go工具箱自带的一个工具，但并不是一个日常工具，它对应`go tool pprof`命令。该命令有许多特性和选项，但是最基本的是两个参数：生成这个概要文件的可执行程序和对应的剖析数据。
|
||||
|
||||
为了提高分析效率和减少空间，分析日志本身并不包含函数的名字；它只包含函数对应的地址。也就是说pprof需要和分析日志对于的可执行程序。虽然`go test`命令通常会丢弃临时用的测试程序，但是在启用分析的时候会将测试程序保存为foo.test文件，其中foo部分对于测试包的名字。
|
||||
为了提高分析效率和减少空间，分析日志本身并不包含函数的名字；它只包含函数对应的地址。也就是说pprof需要对应的可执行程序来解读剖析数据。虽然`go test`通常在测试完成后就丢弃临时用的测试程序，但是在启用分析的时候会将测试程序保存为foo.test文件，其中foo部分对应待测包的名字。
|
||||
|
||||
下面的命令演示了如何生成一个CPU分析文件。我们选择`net/http`包的一个基准测试为例。通常是基于一个已经确定了是关键代码的部分进行基准测试。基准测试会默认包含单元测试，这里我们用-run=NONE参数禁止单元测试。
|
||||
下面的命令演示了如何收集并展示一个CPU分析文件。我们选择`net/http`包的一个基准测试为例。通常最好是对业务关键代码的部分设计专门的基准测试。因为简单的基准测试几乎没法代表业务场景，因此我们用-run=NONE参数禁止那些简单测试。
|
||||
|
||||
```
|
||||
$ go test -run=NONE -bench=ClientServerParallelTLS64 \
|
||||
@@ -57,10 +57,10 @@ Showing top 10 nodes out of 166 (cum >= 60ms)
|
||||
50ms 1.39% 71.59% 60ms 1.67% crypto/elliptic.p256Sum
|
||||
```
|
||||
|
||||
参数`-text`用于指定输出格式，在这里每行是一个函数，根据使用CPU的时间长短来排序。其中`-nodecount=10`标志参数限制了只输出前10行的结果。对于严重的性能问题，这个文本格式基本可以帮助查明原因了。
|
||||
参数`-text`用于指定输出格式，在这里每行是一个函数，根据使用CPU的时间长短来排序。其中`-nodecount=10`参数限制了只输出前10行的结果。对于严重的性能问题，这个文本格式基本可以帮助查明原因了。
|
||||
|
||||
这个概要文件告诉我们，HTTPS基准测试中`crypto/elliptic.p256ReduceDegree`函数占用了将近一半的CPU资源。相比之下，如果一个概要文件中主要是runtime包的内存分配的函数，那么减少内存消耗可能是一个值得尝试的优化策略。
|
||||
这个概要文件告诉我们，HTTPS基准测试中`crypto/elliptic.p256ReduceDegree`函数占用了将近一半的CPU资源，对性能占很大比重。相比之下，如果一个概要文件中主要是runtime包的内存分配的函数，那么减少内存消耗可能是一个值得尝试的优化策略。
|
||||
|
||||
对于一些更微妙的问题，你可能需要使用pprof的图形显示功能。这个需要安装GraphViz工具，可以从 http://www.graphviz.org 下载。参数`-web`用于生成一个有向图文件，包含了CPU的使用和最热点的函数等信息。
|
||||
对于一些更微妙的问题，你可能需要使用pprof的图形显示功能。这个需要安装GraphViz工具，可以从 http://www.graphviz.org 下载。参数`-web`用于生成函数的有向图，标注有CPU的使用和最热点的函数等信息。
|
||||
|
||||
这一节我们只是简单看了下Go语言的分析据工具。如果想了解更多，可以阅读Go官方博客的“Profiling Go Programs”一文。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## 11.6. 示例函数
|
||||
|
||||
第三种`go test`特别处理的函数是示例函数，以Example为函数名开头。示例函数没有函数参数和返回值。下面是IsPalindrome函数对应的示例函数：
|
||||
第三种被`go test`特别对待的函数是示例函数，以Example为函数名开头。示例函数没有函数参数和返回值。下面是IsPalindrome函数对应的示例函数：
|
||||
|
||||
```Go
|
||||
func ExampleIsPalindrome() {
|
||||
@@ -12,14 +12,15 @@ func ExampleIsPalindrome() {
|
||||
}
|
||||
```
|
||||
|
||||
示例函数有三个用处。最主要的一个是作为文档：一个包的例子可以更简洁直观的方式来演示函数的用法，比文字描述更直接易懂，特别是作为一个提醒或快速参考时。一个示例函数也可以方便展示属于同一个接口的几种类型或函数直接的关系，所有的文档都必须关联到一个地方，就像一个类型或函数声明都统一到包一样。同时，示例函数和注释并不一样，示例函数是完整真实的Go代码，需要接受编译器的编译时检查，这样可以保证示例代码不会腐烂成不能使用的旧代码。
|
||||
示例函数有三个用处。最主要的一个是作为文档：一个包的例子可以更简洁直观的方式来演示函数的用法，比文字描述更直接易懂，特别是作为一个提醒或快速参考时。一个示例函数也可以方便展示属于同一个接口的几种类型或函数之间的关系，所有的文档都必须关联到一个地方，就像一个类型或函数声明都统一到包一样。同时，示例函数和注释并不一样，示例函数是真实的Go代码，需要接受编译器的编译时检查，这样可以保证源代码更新时，示例代码不会脱节。
|
||||
|
||||
根据示例函数的后缀名部分，godoc的web文档会将一个示例函数关联到某个具体函数或包本身，因此ExampleIsPalindrome示例函数将是IsPalindrome函数文档的一部分，Example示例函数将是包文档的一部分。
|
||||
根据示例函数的后缀名部分，godoc这个web文档服务器会将示例函数关联到某个具体函数或包本身，因此ExampleIsPalindrome示例函数将是IsPalindrome函数文档的一部分，Example示例函数将是包文档的一部分。
|
||||
|
||||
示例文档的第二个用处是在`go test`执行测试的时候也运行示例函数测试。如果示例函数内含有类似上面例子中的`// Output:`格式的注释，那么测试工具会执行这个示例函数，然后检测这个示例函数的标准输出和注释是否匹配。
|
||||
示例文档的第二个用处是，在`go test`执行测试的时候也会运行示例函数测试。如果示例函数内含有类似上面例子中的`// Output:`格式的注释，那么测试工具会执行这个示例函数，然后检查示例函数的标准输出与注释是否匹配。
|
||||
|
||||
示例函数的第三个目的提供一个真实的演练场。 http://golang.org 就是由godoc提供的文档服务，它使用了Go Playground让用户可以在浏览器中在线编辑和运行每个示例函数，就像图11.4所示的那样。这通常是学习函数使用或Go语言特性最快捷的方式。
|
||||
|
||||
|
||||
|
||||
本书最后的两章是讨论reflect和unsafe包，一般的Go用户很少直接使用它们。因此，如果你还没有写过任何真实的Go程序的话，现在可以忽略剩余部分而直接编码了。
|
||||
本书最后的两章是讨论reflect和unsafe包，一般的Go程序员很少使用它们，事实上也很少需要用到。因此，如果你还没有写过任何真实的Go程序的话，现在可以先去写些代码了。
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# 第十一章 测试
|
||||
|
||||
Maurice Wilkes，第一个存储程序计算机EDSAC的设计者，1949年他在实验室爬楼梯时有一个顿悟。在《计算机先驱回忆录》（Memoirs of a Computer Pioneer）里，他回忆到：“忽然间有一种醍醐灌顶的感觉，我整个后半生的美好时光都将在寻找程序BUG中度过了”。肯定从那之后的大部分正常的码农都会同情Wilkes过分悲观的想法，虽然也许不是没有人困惑于他对软件开发的难度的天真看法。
|
||||
Maurice Wilkes，第一个存储程序计算机EDSAC的设计者，1949年他在实验室爬楼梯时有一个顿悟。在《计算机先驱回忆录》（Memoirs of a Computer Pioneer）里，他回忆到：“忽然间有一种醍醐灌顶的感觉，我整个后半生的美好时光都将在寻找程序BUG中度过了”。肯定从那之后的大部分正常的码农都会同情Wilkes过分悲观的想法，虽然也许会有人困惑于他对软件开发的难度的天真看法。
|
||||
|
||||
现在的程序已经远比Wilkes时代的更大也更复杂，也有许多技术可以让软件的复杂性可得到控制。其中有两种技术在实践中证明是比较有效的。第一种是代码在被正式部署前需要进行代码评审。第二种则是测试，也就是本章的讨论主题。
|
||||
|
||||
我们说测试的时候一般是指自动化测试，也就是写一些小的程序用来检测被测试代码（产品代码）的行为和预期的一样，这些通常都是精心设计的执行某些特定的功能或者是通过随机性的输入要验证边界的处理。
|
||||
我们说测试的时候一般是指自动化测试，也就是写一些小的程序用来检测被测试代码（产品代码）的行为和预期的一样，这些通常都是精心设计的执行某些特定的功能或者是通过随机性的输入待验证边界的处理。
|
||||
|
||||
软件测试是一个巨大的领域。测试的任务可能已经占据了一些程序员的部分时间和另一些程序员的全部时间。和软件测试技术相关的图书或博客文章有成千上万之多。对于每一种主流的编程语言，都会有一打的用于测试的软件包，同时也有大量的测试相关的理论，而且每种都吸引了大量技术先驱和追随者。这些都足以说服那些想要编写有效测试的程序员重新学习一套全新的技能。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user