为什么需要测试
完善的测试体系，能够提高开发的效率，当项目足够复杂的时候，想要保证尽可能的减少 bug，有两种有效的方式分别是代码审核和测试，Go语言中提供了 testing 包来实现单元测试功能。
测试规则
要开始一个单元测试，需要准备一个 go 源码文件，在命名文件时文件名必须以_test.go结尾，单元测试源码文件可以由多个测试用例(可以理解为函数)组成，每个测试用例的名称需要以 Test 为前缀，例如：
func TestXxx( t *testing.T ){
//......
}
语料库文件以特殊格式编码。这是种子语料库和生成语料库的相同格式。
下面是一个语料库文件的例子：
第一行用于通知模糊引擎文件的编码版本。虽然目前没有计划未来版本的编码格式，但设计必须支持这种可能性。
下面的每一行都是构成语料库条目的值，如果需要，可以直接复制到 Go 代码中。
在上面的示例中，我们在 a []byte后跟一个int64。这些类型必须按顺序与模糊测试参数完全匹配。这些类型的模糊目标如下所示：
指定您自己的种子语料库值的最简单方法是使用该 (*testing.F).Add方法。在上面的示例中，它看起来像这样：
但是，您可能有较大的二进制文件，您不希望将其作为代码复制到您的测试中，而是作为单独的种子语料库条目保留在 testdata/fuzz/{FuzzTestName} 目录中。golang.org/x/tools/cmd/file2fuzz 上的file2fuzz工具可用于将这些二进制文件转换为为[]byte.
要使用此工具：
语料库条目：语料库 中的一个输入，可以在模糊测试时使用。这可以是特殊格式的文件，也可以是对 (*testing.F).Add。
覆盖指导： 一种模糊测试方法，它使用代码覆盖范围的扩展来确定哪些语料库条目值得保留以备将来使用。
失败的输入：失败的输入是一个语料库条目，当针对 模糊目标运行时会导致错误或恐慌。
fuzz target： 模糊测试的目标功能，在模糊测试时对语料库条目和生成的值执行。它通过将函数传递给 (*testing.F).Fuzz实现。
fuzz test： 测试文件中的一个被命名为func FuzzXxx(*testing.F)的函数，可用于模糊测试。
fuzzing： 一种自动化测试，它不断地操纵程序的输入，以发现代码可能容易受到的错误或漏洞等问题。
fuzzing arguments： 将传递给 模糊测试目标的参数，并由mutator进行变异。
fuzzing engine： 一个管理fuzzing的工具，包括维护语料库、调用mutator、识别新的覆盖率和报告失败。
生成的语料库： 由模糊引擎随时间维护的语料库，同时模糊测试以跟踪进度。它存储在$GOCACHE/fuzz 中。这些条目仅在模糊测试时使用。
mutator： 一种在模糊测试时使用的工具，它在将语料库条目传递给模糊目标之前随机操作它们。
package： 同一目录下编译在一起的源文件的集合。
种子语料库： 用户提供的用于模糊测试的语料库，可用于指导模糊引擎。它由 f.Add 在模糊测试中调用提供的语料库条目以及包内 testdata/fuzz/{FuzzTestName} 目录中的文件组成。这些条目默认使用go test运行，无论是否进行模糊测试。
测试文件： 格式为 xxx_test.go 的文件，可能包含测试、基准、示例和模糊测试。
漏洞： 代码中的安全敏感漏洞，可以被攻击者利用。
是Go语言吗?Go 编译过程 九个步骤
第一步. all.bash
% cd $GOROOT/src
% ./all.bash
第一步 all.bash 只是调用了另外两个 shell 脚本：make.bash 和run.bash。若使用 Windows 或 Plan9，其过程也基本类似，只是脚本分别以 .bat 或 .rc 结尾。在文章的其他部分，请用适当的操作系统对应的扩展来补全命令。
第二步. make.bash
. ./make.bash --no-banner
make.bash 作为 all.bash 内容的一部分，如果它退出也会中断构建过程
第三步. cmd/dist
gcc -O2 -Wall -Werror -ggdb -o cmd/dist/dist -Icmd/dist cmd/dist/*.c
当健全检查完成后，make.bash 开始编译 cmd/dist。
第四步. go_bootstrap
现在 go_bootstrap 已经构建完成，make.bash 的最后一步是使用 go_bootstrap 编译完整的 Go 标准库，包括一个完整的 go 工具用以替换。
echo "# Building packages and commands for $GOOS/$GOARCH."
"$GOTOOLDIR"/go_bootstrap install -gcflags "$GO_GCFLAGS" \
-ldflags "$GO_LDFLAGS" -v std
第五步. run.bash
现在 make.bash 已经完成，回到 all.bash 的执行，这会调用 run.bash。run.bash 的任务是编译和测试标准库、运行时以及语言测试集。
bash run.bash --no-rebuild
由于 make.bash 和 run.bash 都会调用 go install -a std，因此需要使用 –no-rebuild 标志来避免重复前面的步骤，–no-rebuild 跳过了第二个 go install。
# allow all.bash to avoid double-build of everythingrebuild=trueif [ "$1" = "--no-rebuild" ]then shiftelse echo '# Building packages and commands.' time go install -a -v std echofi
第六步. go test -a std
echo '# Testing packages.'
time go test std -short -timeout=$(expr 120 \* $timeout_scale)s
echo
接下来 run.bash 会在标准库里所有的包上来运行用 testing 包编写的单元测试。由于 $GOPATH 和 $GOROOT 中有着相同的命名空间，所以不能直接使用 go test … 否则 $GOPATH 中的每个包也会被逐一测试，因此创建了一个用于标准库中的包的别名：std。由于一些测试需要比较长的时间，且会消耗大量内存，因此用 -short 标志对一些测试进行了过滤。
第七步. runtime 和 cgo 测试
run.bash 接下来的部分会运行平台对 cgo 支持的测试，执行一些性能测试，并且编译一些伴随 Go 发行版一起的杂项程序。随着时间的流逝，这些杂项程序的清单会越来越长，那么它们也就会不可避免的被从编译过程中悄悄剥离出去。
第八步. go run test
(xcd ../test
unset GOMAXPROCS
time go run run.go
) || exit $?
run.bash 的倒数第二步会调用在 $GOROOT 下的 test 目录里的编译器和运行时的测试。他们是对于编译器和运行时自身的，较为低级细节的测试。会执行语言规格测试，test/bugs 和 test/fixedbugs 子目录保存有那些已经被发现并被修复的问题的独立的测试。驱动测试的是一个小 Go 程序 $GOROOT/test/run.go，会执行 test 目录里的每个 .go 文件。一些 .go 文件的首行包含了指导 run.go 对结果作出判断的指令，例如，程序将会失败，或提供一个确定的输出队列。
第九步. go tool api
echo '# Checking API compatibility.'
go tool api -c $GOROOT/api/go1.txt,$GOROOT/api/go1.1.txt \
-next $GOROOT/api/next.txt -except $GOROOT/api/except.txt
run.bash 的最后一步调用了 api 工具。
