ehlxr/gopl-zh.github.com
1
0
Fork 0
mirror of https://github.com/gopl-zh/gopl-zh.github.com.git synced 2025-08-06 15:32:19 +00:00
Code Issues Projects Releases Wiki Activity

回到简体

Browse Source
This commit is contained in:
chai2010
2016-02-15 11:06:34 +08:00
parent 9e878f9944
commit 2b37b23285
177 changed files with 2354 additions and 2354 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
ch11/ch11-03.md
View File

@@ -1,12 +1,12 @@
## 11.3. 測試覆蓋率
## 11.3. 测试覆盖率
就其性質而言，測試不可能是完整的。計算機科學家Edsger Dijkstra曾説過：“測試可以顯示存在缺陷，但是併不是説沒有BUG。”再多的測試也不能證明一個程序沒有BUG。在最好的情況下，測試可以增強我們的信心：代碼在我們測試的環境是可以正常工作的。
就其性质而言，测试不可能是完整的。计算机科学家Edsger Dijkstra曾说过：“测试可以显示存在缺陷，但是并不是说没有BUG。”再多的测试也不能证明一个程序没有BUG。在最好的情况下，测试可以增强我们的信心：代码在我们测试的环境是可以正常工作的。
由測試驅動觸發運行到的被測試函數的代碼數目稱爲測試的覆蓋率。測試覆蓋率併不能量化——甚至連最簡單的動態程序也難以精確測量——但是可以啟發併幫助我們編寫的有效的測試代碼。
由测试驱动触发运行到的被测试函数的代码数目称为测试的覆盖率。测试覆盖率并不能量化——甚至连最简单的动态程序也难以精确测量——但是可以启发并帮助我们编写的有效的测试代码。
這些幫助信息中語句的覆蓋率是最簡單和最廣泛使用的。語句的覆蓋率是指在測試中至少被運行一次的代碼占總代碼數的比例。在本節中，我們使用`go test`命令中集成的測試覆蓋率工具，來度量下面代碼的測試覆蓋率，幫助我們識别測試和我們期望間的差距。
这些帮助信息中语句的覆盖率是最简单和最广泛使用的。语句的覆盖率是指在测试中至少被运行一次的代码占总代码数的比例。在本节中，我们使用`go test`命令中集成的测试覆盖率工具，来度量下面代码的测试覆盖率，帮助我们识别测试和我们期望间的差距。
下面的代碼是一個表格驅動的測試，用於測試第七章的表達式求值程序：
下面的代码是一个表格驱动的测试，用于测试第七章的表达式求值程序：
<u><i>gopl.io/ch7/eval</i></u>
```Go
@@ -45,7 +45,7 @@ func TestCoverage(t *testing.T) {
}
```
首先，我們要確保所有的測試都正常通過：
首先，我们要确保所有的测试都正常通过：
```
$ go test -v -run=Coverage gopl.io/ch7/eval
@@ -55,7 +55,7 @@ PASS
ok gopl.io/ch7/eval 0.011s
```
下面這個命令可以顯示測試覆蓋率工具的使用用法：
下面这个命令可以显示测试覆盖率工具的使用用法：
```
$ go tool cover
@@ -68,20 +68,20 @@ Open a web browser displaying annotated source code:
...
```
`go tool`命令運行Go工具鏈的底層可執行程序。這些底層可執行程序放在$GOROOT/pkg/tool/${GOOS}_${GOARCH}目録。因爲有`go build`命令的原因，我們很少直接調用這些底層工具。
`go tool`命令运行Go工具链的底层可执行程序。这些底层可执行程序放在$GOROOT/pkg/tool/${GOOS}_${GOARCH}目录。因为有`go build`命令的原因，我们很少直接调用这些底层工具。
現在我們可以用`-coverprofile`標誌參數重新運行測試：
现在我们可以用`-coverprofile`标志参数重新运行测试：
```
$ 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`標誌參數，那麽將在每個代碼塊插入一個計數器而不是布爾標誌量。在統計結果中記録了每個塊的執行次數，這可以用於衡量哪些是被頻繁執行的熱點代碼。
如果使用了`-covermode=count`标志参数，那么将在每个代码块插入一个计数器而不是布尔标志量。在统计结果中记录了每个块的执行次数，这可以用于衡量哪些是被频繁执行的热点代码。
爲了收集數據，我們運行了測試覆蓋率工具，打印了測試日誌，生成一個HTML報告，然後在瀏覽器中打開（圖11.3）。
为了收集数据，我们运行了测试覆盖率工具，打印了测试日志，生成一个HTML报告，然后在浏览器中打开（图11.3）。
```
$ go tool cover -html=c.out
@@ -89,12 +89,12 @@ $ go tool cover -html=c.out
![](../images/ch11-03.png)
緑色的代碼塊被測試覆蓋到了，紅色的則表示沒有被覆蓋到。爲了清晰起見，我們將的背景紅色文本的背景設置成了陰影效果。我們可以馬上發現unary操作的Eval方法併沒有被執行到。如果我們針對這部分未被覆蓋的代碼添加下面的測試用例，然後重新運行上面的命令，那麽我們將會看到那個紅色部分的代碼也變成緑色了：
绿色的代码块被测试覆盖到了，红色的则表示没有被覆盖到。为了清晰起见，我们将的背景红色文本的背景设置成了阴影效果。我们可以马上发现unary操作的Eval方法并没有被执行到。如果我们针对这部分未被覆盖的代码添加下面的测试用例，然后重新运行上面的命令，那么我们将会看到那个红色部分的代码也变成绿色了：
```
{"-x * -x", eval.Env{"x": 2}, "4"}
```
不過兩個panic語句依然是紅色的。這是沒有問題的，因爲這兩個語句併不會被執行到。
不过两个panic语句依然是红色的。这是没有问题的，因为这两个语句并不会被执行到。
實現100%的測試覆蓋率聽起來很美，但是在具體實踐中通常是不可行的，也不是值得推薦的做法。因爲那隻能説明代碼被執行過而已，併不意味着代碼就是沒有BUG的；因爲對於邏輯複雜的語句需要針對不同的輸入執行多次。有一些語句，例如上面的panic語句則永遠都不會被執行到。另外，還有一些隱晦的錯誤在現實中很少遇到也很難編寫對應的測試代碼。測試從本質上來説是一個比較務實的工作，編寫測試代碼和編寫應用代碼的成本對比是需要考慮的。測試覆蓋率工具可以幫助我們快速識别測試薄弱的地方，但是設計好的測試用例和編寫應用代碼一樣需要嚴密的思考。
实现100%的测试覆盖率听起来很美，但是在具体实践中通常是不可行的，也不是值得推荐的做法。因为那只能说明代码被执行过而已，并不意味着代码就是没有BUG的；因为对于逻辑复杂的语句需要针对不同的输入执行多次。有一些语句，例如上面的panic语句则永远都不会被执行到。另外，还有一些隐晦的错误在现实中很少遇到也很难编写对应的测试代码。测试从本质上来说是一个比较务实的工作，编写测试代码和编写应用代码的成本对比是需要考虑的。测试覆盖率工具可以帮助我们快速识别测试薄弱的地方，但是设计好的测试用例和编写应用代码一样需要严密的思考。