一个测试工程师走进一家酒吧，要了一杯啤酒；
一个测试工程师走进一家酒吧，要了一杯咖啡；
一个测试工程师走进一家酒吧，要了 0.7 杯啤酒；
一个测试工程师走进一家酒吧，要了-1 杯啤酒；
一个测试工程师走进一家酒吧，要了 2^32 杯啤酒；
一个测试工程师走进一家酒吧，要了一杯洗脚水；
一个测试工程师走进一家酒吧，要了一杯蜥蜴；
一个测试工程师走进一家酒吧，要了一份 asdfQwer@24dg!&*(@；
一个测试工程师走进一家酒吧，什么也没要；
一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来；
一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿；
一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷；
一个测试工程师走进一家酒吧，要了 NaN 杯 Null；
一个测试工程师冲进一家酒吧，要了 500T 啤酒咖啡洗脚水野猫狼牙棒奶茶；
一个测试工程师把酒吧拆了；
一个测试工程师化装成老板走进一家酒吧，要了 500 杯啤酒并且不付钱；
一万个测试工程师在酒吧门外呼啸而过；
一个测试工程师走进一家酒吧，要了一杯啤酒';DROP TABLE 酒吧；
测试工程师们满意地离开了酒吧。
然后一名顾客点了一份炒饭，酒吧炸了。
上面是网上流行的一个关于测试的笑话，其主要核心思想是——你永远无法把所有问题都充分测试。
在软件工程中，测试是极其重要的一环，比重通常可以与编码相同，甚至大大超过。那么在 Golang 里，怎么样把测试写好，写正确？本文将对这个问题做一些简单的介绍。 当前文章将主要分两个部分：
Golang 测试的一些基本写法和工具
如何写“正确”的测试，这个部分虽然代码是用 golang 编写，但是其核心思想不限语言
由于篇幅问题，本文将不涉及性能测试，之后会另起一篇来谈。
为什么要写测试
我们举个不太恰当的例子，测试也是代码，我们假定写代码时出现 bug 的概率是 p（0<p<1），那么我们同时写测试的话，两边同时出现 bug 的概率就是（我们认为两个事件相互独立）
P(代码出现 bug) * P(测试出现 Bug) = p^2 < p
例如 p 是 1%的话，那么同时写出现 bug 的概率就只有 0.01%了。
测试同样也是代码，有可能也写出 bug，那么怎么保证测试的正确性呢？给测试也写测试？给测试的测试继续写测试？
我们定义 t(0)为原始的代码，任意的 i，i > 0，t(i+1)为对于 t(i)的测试，t(i+1)正确为 t(i)正确的必要条件，那么对所有的 i，i>0，t(i)正确都是 t(0)正确的必要条件。。。
测试的种类
测试的种类有非常多，我们这里只挑几个对一般开发者来说比较重要的测试，做简略的说明。
白盒测试、黑盒测试
首先是从测试方法上可以分为白盒测试和黑盒测试（当然还存在所谓的灰盒测试，这里不讨论）
白盒测试 (White-box testing)：白盒测试又称透明盒测试、结构测试等，软件测试的主要方法之一，也称结构测试、逻辑驱动测试或基于程序本身的测试。测试应用程序的内部结构或运作，而不是测试应用程序的功能。在白盒测试时，以编程语言的角度来设计测试案例。测试者输入数据验证数据流在程序中的流动路径，并确定适当的输出，类似测试电路中的节点。
黑盒测试 (Black-box testing)：黑盒测试，软件测试的主要方法之一，也可以称为功能测试、数据驱动测试或基于规格说明的测试。测试者不了解程序的内部情况，不需具备应用程序的代码、内部结构和编程语言的专门知识。只知道程序的输入、输出和系统的功能，这是从用户的角度针对软件界面、功能及外部结构进行测试，而不考虑程序内部逻辑结构。
我们写的单元测试一般属于白盒测试，因为我们对测试对象的内部逻辑有着充分了解。
单元测试、集成测试
从测试的维度上，又可以分为单元测试和集成测试：
在计算机编程中，单元测试又称为模块测试，是针对程序模块来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类、抽象类、或者派生类中的方法。
整合测试又称组装测试，即对程序模块采用一次性或增值方式组装起来，对系统的接口进行正确性检验的测试工作。整合测试一般在单元测试之后、系统测试之前进行。实践表明，有时模块虽然可以单独工作，但是并不能保证组装起来也可以同时工作。
单元测试可以是黑盒测试，集成测试亦可以是白盒测试
回归测试
回归测试是软件测试的一种，旨在检验软件原有功能在修改后是否保持完整。
回归测试主要是希望维持软件的不变性，我们举一个例子来说明。例如我们发现软件在运行的过程中出现了问题，在 gitlab 上开启了一个 issue。之后我们并且定位到了问题，我们可以先写一个测试（测试的名称可以带上 issue 的 ID）来复现问题（该版本代码运行此测试结果失败）。之后我们修复问题后，再次运行测试，测试的结果应当成功。那么我们之后每次运行测试的时候，通过运行这个测试，可以保证同样的问题不会复现。
一个基本的测试
我们先来看一个 Golang 的代码：
// add.go
package add
func Add(a, b int) int {
return a + b
}
一个测试用例可以写成：
// add_test.go
package add
import (
"testing"
)
func TestAdd(t *testing.T) {
res := Add(1, 2)
if res != 3 {
t.Errorf("the result is %d instead of 3", res)
}
}
在命令行我们使用 go test
go test
这个时候 go 会执行该目录下所有的以_test.go 为后缀中的测试，测试成功的话会有如下输出：
% go test
PASS
ok code.byted.org/ek/demo_test/t01_basic/correct 0.015s
假设这个时候我们把 Add 函数修改成错误的实现
// add.go
package add
func Add(a, b int) int {
return a - b
}
再次执行测试命令
% go test
--- FAIL: TestAddWrong (0.00s)
add_test.go:11: the result is -1 instead of 3
FAIL
exit status 1
FAIL code.byted.org/ek/demo_test/t01_basic/wrong 0.006s
会发现测试失败。
只执行一个测试文件
那么如果我们想只测试这一个文件，输入
go test add_test.go
会发现命令行输出
% go test add_test.go
# command-line-arguments [command-line-arguments.test]
./add_test.go:9:9: undefined: Add
FAIL command-line-arguments [build failed]
FAIL
这是因为我们没有附带测试对象的代码，修改测试后可以获得正确的输出：
% go test add_test.go add.go
ok command-line-arguments 0.007s
测试的几种书写方式
子测试
通常来说我们测试某个函数和方法，可能需要测试很多不同的 case 或者边际条件，例如我们为上面的 Add 函数写两个测试，可以写成：
// add_test.go
package add
import (
"testing"
)
func TestAdd(t *testing.T) {
res := Add(1, 0)
if res != 1 {
t.Errorf("the result is %d instead of 1", res)
}
}
func TestAdd2(t *testing.T) {
res := Add(0, 1)
if res != 1 {
t.Errorf("the result is %d instead of 1", res)
}
}
测试的结果：（使用-v 可以获得更多输出）
% go test -v
=== RUN TestAdd
--- PASS: TestAdd (0.00s)
=== RUN TestAdd2
--- PASS: TestAdd2 (0.00s)
PASS
ok code.byted.org/ek/demo_test/t02_subtest/non_subtest 0.007s
另一种写法是写成子测试的形式
// add_test.go
package add
import (
"testing"
)
func TestAdd(t *testing.T) {
t.Run("test1", func(t *testing.T) {
res := Add(1, 0)
if res != 1 {
t.Errorf("the result is %d instead of 1", res)
}
})
t.Run("", func(t *testing.T) {
res := Add(0, 1)
if res != 1 {
t.Errorf("the result is %d in
2万+
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
