回到简体

ch11/ch11-01.md

@@ -1,7 +1,7 @@
 ## 11.1. go test
 
-go test命令是一個按照一定的約定和組織的測試代碼的驅動程序。在包目録內，所有以_test.go爲後綴名的源文件併不是go build構建包的一部分，它們是go test測試的一部分。
+go test命令是一个按照一定的约定和组织的测试代码的驱动程序。在包目录内，所有以_test.go为后缀名的源文件并不是go build构建包的一部分，它们是go test测试的一部分。
 
-在\*_test.go文件中，有三種類型的函數：測試函數、基準測試函數、示例函數。一個測試函數是以Test爲函數名前綴的函數，用於測試程序的一些邏輯行爲是否正確；go test命令會調用這些測試函數併報告測試結果是PASS或FAIL。基準測試函數是以Benchmark爲函數名前綴的函數，它們用於衡量一些函數的性能；go test命令會多次運行基準函數以計算一個平均的執行時間。示例函數是以Example爲函數名前綴的函數，提供一個由編譯器保證正確性的示例文檔。我們將在11.2節討論測試函數的所有細節，病在11.4節討論基準測試函數的細節，然後在11.6節討論示例函數的細節。
+在\*_test.go文件中，有三种类型的函数：测试函数、基准测试函数、示例函数。一个测试函数是以Test为函数名前缀的函数，用于测试程序的一些逻辑行为是否正确；go test命令会调用这些测试函数并报告测试结果是PASS或FAIL。基准测试函数是以Benchmark为函数名前缀的函数，它们用于衡量一些函数的性能；go test命令会多次运行基准函数以计算一个平均的执行时间。示例函数是以Example为函数名前缀的函数，提供一个由编译器保证正确性的示例文档。我们将在11.2节讨论测试函数的所有细节，病在11.4节讨论基准测试函数的细节，然后在11.6节讨论示例函数的细节。
 
-go test命令會遍歷所有的\*_test.go文件中符合上述命名規則的函數，然後生成一個臨時的main包用於調用相應的測試函數，然後構建併運行、報告測試結果，最後清理測試中生成的臨時文件。
+go test命令会遍历所有的\*_test.go文件中符合上述命名规则的函数，然后生成一个临时的main包用于调用相应的测试函数，然后构建并运行、报告测试结果，最后清理测试中生成的临时文件。

ch11/ch11-02-1.md

@@ -1,10 +1,10 @@
-### 11.2.1. 隨機測試
+### 11.2.1. 随机测试
 
-表格驅動的測試便於構造基於精心挑選的測試數據的測試用例。另一種測試思路是隨機測試，也就是通過構造更廣泛的隨機輸入來測試探索函數的行爲。
+表格驱动的测试便于构造基于精心挑选的测试数据的测试用例。另一种测试思路是随机测试，也就是通过构造更广泛的随机输入来测试探索函数的行为。
 
-那麽對於一個隨機的輸入，我們如何能知道希望的輸出結果呢？這里有兩種處理策略。第一個是編寫另一個對照函數，使用簡單和清晰的算法，雖然效率較低但是行爲和要測試的函數是一致的，然後針對相同的隨機輸入檢査兩者的輸出結果。第二種是生成的隨機輸入的數據遵循特定的模式，這樣我們就可以知道期望的輸出的模式。
+那么对于一个随机的输入，我们如何能知道希望的输出结果呢？这里有两种处理策略。第一个是编写另一个对照函数，使用简单和清晰的算法，虽然效率较低但是行为和要测试的函数是一致的，然后针对相同的随机输入检查两者的输出结果。第二种是生成的随机输入的数据遵循特定的模式，这样我们就可以知道期望的输出的模式。
 
-下面的例子使用的是第二種方法：randomPalindrome函數用於隨機生成迴文字符串。
+下面的例子使用的是第二种方法：randomPalindrome函数用于随机生成回文字符串。
 
 ```Go
 import "math/rand"
@@ -37,13 +37,13 @@ func TestRandomPalindromes(t *testing.T) {
 }
 ```
 
-雖然隨機測試會有不確定因素，但是它也是至關重要的，我們可以從失敗測試的日誌獲取足夠的信息。在我們的例子中，輸入IsPalindrome的p參數將告訴我們眞實的數據，但是對於函數將接受更複雜的輸入，不需要保存所有的輸入，隻要日誌中簡單地記録隨機數種子卽可（像上面的方式）。有了這些隨機數初始化種子，我們可以很容易脩改測試代碼以重現失敗的隨機測試。
+虽然随机测试会有不确定因素，但是它也是至关重要的，我们可以从失败测试的日志获取足够的信息。在我们的例子中，输入IsPalindrome的p参数将告诉我们真实的数据，但是对于函数将接受更复杂的输入，不需要保存所有的输入，只要日志中简单地记录随机数种子即可（像上面的方式）。有了这些随机数初始化种子，我们可以很容易修改测试代码以重现失败的随机测试。
 
-通過使用當前時間作爲隨機種子，在整個過程中的每次運行測試命令時都將探索新的隨機數據。如果你使用的是定期運行的自動化測試集成繫統，隨機測試將特别有價值。
+通过使用当前时间作为随机种子，在整个过程中的每次运行测试命令时都将探索新的随机数据。如果你使用的是定期运行的自动化测试集成系统，随机测试将特别有价值。
 
-**練習 11.3:** TestRandomPalindromes測試函數隻測試了迴文字符串。編寫新的隨機測試生成器，用於測試隨機生成的非迴文字符串。
+**练习 11.3:** TestRandomPalindromes测试函数只测试了回文字符串。编写新的随机测试生成器，用于测试随机生成的非回文字符串。
 
-**練習 11.4:** 脩改randomPalindrome函數，以探索IsPalindrome是否對標點和空格做了正確處理。
+**练习 11.4:** 修改randomPalindrome函数，以探索IsPalindrome是否对标点和空格做了正确处理。
 
 
 

ch11/ch11-02-2.md

@@ -1,8 +1,8 @@
-### 11.2.2. 測試一個命令
+### 11.2.2. 测试一个命令
 
-對於測試包`go test`是一個的有用的工具，但是稍加努力我們也可以用它來測試可執行程序。如果一個包的名字是 main，那麽在構建時會生成一個可執行程序，不過main包可以作爲一個包被測試器代碼導入。
+对于测试包`go test`是一个的有用的工具，但是稍加努力我们也可以用它来测试可执行程序。如果一个包的名字是 main，那么在构建时会生成一个可执行程序，不过main包可以作为一个包被测试器代码导入。
 
-讓我們爲2.3.2節的echo程序編寫一個測試。我們先將程序拆分爲兩個函數：echo函數完成眞正的工作，main函數用於處理命令行輸入參數和echo可能返迴的錯誤。
+让我们为2.3.2节的echo程序编写一个测试。我们先将程序拆分为两个函数：echo函数完成真正的工作，main函数用于处理命令行输入参数和echo可能返回的错误。
 
 <u><i>gopl.io/ch11/echo</i></u>
 ```Go
@@ -41,7 +41,7 @@ func echo(newline bool, sep string, args []string) error {
 }
 ```
 
-在測試中我們可以用各種參數和標標誌調用echo函數，然後檢測它的輸出是否正確, 我們通過增加參數來減少echo函數對全局變量的依賴。我們還增加了一個全局名爲out的變量來替代直接使用os.Stdout，這樣測試代碼可以根據需要將out脩改爲不同的對象以便於檢査。下面就是echo_test.go文件中的測試代碼：
+在测试中我们可以用各种参数和标标志调用echo函数，然后检测它的输出是否正确, 我们通过增加参数来减少echo函数对全局变量的依赖。我们还增加了一个全局名为out的变量来替代直接使用os.Stdout，这样测试代码可以根据需要将out修改为不同的对象以便于检查。下面就是echo_test.go文件中的测试代码：
 
 ```Go
 package main
@@ -82,15 +82,15 @@ func TestEcho(t *testing.T) {
 }
 ```
 
-要註意的是測試代碼和産品代碼在同一個包。雖然是main包，也有對應的main入口函數，但是在測試的時候main包隻是TestEcho測試函數導入的一個普通包，里面main函數併沒有被導出，而是被忽略的。
+要注意的是测试代码和产品代码在同一个包。虽然是main包，也有对应的main入口函数，但是在测试的时候main包只是TestEcho测试函数导入的一个普通包，里面main函数并没有被导出，而是被忽略的。
 
-通過將測試放到表格中，我們很容易添加新的測試用例。讓我通過增加下面的測試用例來看看失敗的情況是怎麽樣的：
+通过将测试放到表格中，我们很容易添加新的测试用例。让我通过增加下面的测试用例来看看失败的情况是怎么样的：
 
 ```Go
 {true, ",", []string{"a", "b", "c"}, "a b c\n"}, // NOTE: wrong expectation!
 ```
 
-`go test`輸出如下：
+`go test`输出如下：
 
 ```
 $ go test gopl.io/ch11/echo
@@ -100,6 +100,6 @@ FAIL
 FAIL        gopl.io/ch11/echo         0.006s
 ```
 
-錯誤信息描述了嚐試的操作（使用Go類似語法），實際的結果和期望的結果。通過這樣的錯誤信息，你可以在檢視代碼之前就很容易定位錯誤的原因。
+错误信息描述了尝试的操作（使用Go类似语法），实际的结果和期望的结果。通过这样的错误信息，你可以在检视代码之前就很容易定位错误的原因。
 
-要註意的是在測試代碼中併沒有調用log.Fatal或os.Exit，因爲調用這類函數會導致程序提前退出；調用這些函數的特權應該放在main函數中。如果眞的有意外的事情導致函數發生panic異常，測試驅動應該嚐試用recover捕獲異常，然後將當前測試當作失敗處理。如果是可預期的錯誤，例如非法的用戶輸入、找不到文件或配置文件不當等應該通過返迴一個非空的error的方式處理。幸運的是（上面的意外隻是一個插麴），我們的echo示例是比較簡單的也沒有需要返迴非空error的情況。
+要注意的是在测试代码中并没有调用log.Fatal或os.Exit，因为调用这类函数会导致程序提前退出；调用这些函数的特权应该放在main函数中。如果真的有意外的事情导致函数发生panic异常，测试驱动应该尝试用recover捕获异常，然后将当前测试当作失败处理。如果是可预期的错误，例如非法的用户输入、找不到文件或配置文件不当等应该通过返回一个非空的error的方式处理。幸运的是（上面的意外只是一个插曲），我们的echo示例是比较简单的也没有需要返回非空error的情况。

ch11/ch11-02-3.md

@@ -1,14 +1,14 @@
-### 11.2.3. 白盒測試
+### 11.2.3. 白盒测试
 
-一種測試分類的方法是基於測試者是否需要了解被測試對象的內部工作原理。黑盒測試隻需要測試包公開的文檔和API行爲，內部實現對測試代碼是透明的。相反，白盒測試有訪問包內部函數和數據結構的權限，因此可以做到一下普通客戶端無法實現的測試。例如，一個白盒測試可以在每個操作之後檢測不變量的數據類型。（白盒測試隻是一個傳統的名稱，其實稱爲clear box測試會更準確。）
+一种测试分类的方法是基于测试者是否需要了解被测试对象的内部工作原理。黑盒测试只需要测试包公开的文档和API行为，内部实现对测试代码是透明的。相反，白盒测试有访问包内部函数和数据结构的权限，因此可以做到一下普通客户端无法实现的测试。例如，一个白盒测试可以在每个操作之后检测不变量的数据类型。（白盒测试只是一个传统的名称，其实称为clear box测试会更准确。）
 
-黑盒和白盒這兩種測試方法是互補的。黑盒測試一般更健壯，隨着軟件實現的完善測試代碼很少需要更新。它們可以幫助測試者了解眞是客戶的需求，也可以幫助發現API設計的一些不足之處。相反，白盒測試則可以對內部一些棘手的實現提供更多的測試覆蓋。
+黑盒和白盒这两种测试方法是互补的。黑盒测试一般更健壮，随着软件实现的完善测试代码很少需要更新。它们可以帮助测试者了解真是客户的需求，也可以帮助发现API设计的一些不足之处。相反，白盒测试则可以对内部一些棘手的实现提供更多的测试覆盖。
 
-我們已經看到兩種測試的例子。TestIsPalindrome測試僅僅使用導出的IsPalindrome函數，因此這是一個黑盒測試。TestEcho測試則調用了內部的echo函數，併且更新了內部的out包級變量，這兩個都是未導出的，因此這是白盒測試。
+我们已经看到两种测试的例子。TestIsPalindrome测试仅仅使用导出的IsPalindrome函数，因此这是一个黑盒测试。TestEcho测试则调用了内部的echo函数，并且更新了内部的out包级变量，这两个都是未导出的，因此这是白盒测试。
 
-當我們準備TestEcho測試的時候，我們脩改了echo函數使用包級的out變量作爲輸出對象，因此測試代碼可以用另一個實現代替標準輸出，這樣可以方便對比echo輸出的數據。使用類似的技術，我們可以將産品代碼的其他部分也替換爲一個容易測試的僞對象。使用僞對象的好處是我們可以方便配置，容易預測，更可靠，也更容易觀察。同時也可以避免一些不良的副作用，例如更新生産數據庫或信用卡消費行爲。
+当我们准备TestEcho测试的时候，我们修改了echo函数使用包级的out变量作为输出对象，因此测试代码可以用另一个实现代替标准输出，这样可以方便对比echo输出的数据。使用类似的技术，我们可以将产品代码的其他部分也替换为一个容易测试的伪对象。使用伪对象的好处是我们可以方便配置，容易预测，更可靠，也更容易观察。同时也可以避免一些不良的副作用，例如更新生产数据库或信用卡消费行为。
 
-下面的代碼演示了爲用戶提供網絡存儲的web服務中的配額檢測邏輯。當用戶使用了超過90%的存儲配額之後將發送提醒郵件。
+下面的代码演示了为用户提供网络存储的web服务中的配额检测逻辑。当用户使用了超过90%的存储配额之后将发送提醒邮件。
 
 <u><i>gopl.io/ch11/storage1</i></u>
 ```Go
@@ -48,7 +48,7 @@ func CheckQuota(username string) {
 }
 ```
 
-我們想測試這個代碼，但是我們併不希望發送眞實的郵件。因此我們將郵件處理邏輯放到一個私有的notifyUser函數中。
+我们想测试这个代码，但是我们并不希望发送真实的邮件。因此我们将邮件处理逻辑放到一个私有的notifyUser函数中。
 
 <u><i>gopl.io/ch11/storage2</i></u>
 ```Go
@@ -73,7 +73,7 @@ func CheckQuota(username string) {
 }
 ```
 
-現在我們可以在測試中用僞郵件發送函數替代眞實的郵件發送函數。它隻是簡單記録要通知的用戶和郵件的內容。
+现在我们可以在测试中用伪邮件发送函数替代真实的邮件发送函数。它只是简单记录要通知的用户和邮件的内容。
 
 ```Go
 package storage
@@ -107,7 +107,7 @@ func TestCheckQuotaNotifiesUser(t *testing.T) {
 }
 ```
 
-這里有一個問題：當測試函數返迴後，CheckQuota將不能正常工作，因爲notifyUsers依然使用的是測試函數的僞發送郵件函數（當更新全局對象的時候總會有這種風險）。 我們必須脩改測試代碼恢複notifyUsers原先的狀態以便後續其他的測試沒有影響，要確保所有的執行路徑後都能恢複，包括測試失敗或panic異常的情形。在這種情況下，我們建議使用defer語句來延後執行處理恢複的代碼。
+这里有一个问题：当测试函数返回后，CheckQuota将不能正常工作，因为notifyUsers依然使用的是测试函数的伪发送邮件函数（当更新全局对象的时候总会有这种风险）。 我们必须修改测试代码恢复notifyUsers原先的状态以便后续其他的测试没有影响，要确保所有的执行路径后都能恢复，包括测试失败或panic异常的情形。在这种情况下，我们建议使用defer语句来延后执行处理恢复的代码。
 
 ```Go
 func TestCheckQuotaNotifiesUser(t *testing.T) {
@@ -124,6 +124,6 @@ func TestCheckQuotaNotifiesUser(t *testing.T) {
 }
 ```
 
-這種處理模式可以用來暫時保存和恢複所有的全局變量，包括命令行標誌參數、調試選項和優化參數；安裝和移除導致生産代碼産生一些調試信息的鉤子函數；還有有些誘導生産代碼進入某些重要狀態的改變，比如超時、錯誤，甚至是一些刻意製造的併發行爲等因素。
+这种处理模式可以用来暂时保存和恢复所有的全局变量，包括命令行标志参数、调试选项和优化参数；安装和移除导致生产代码产生一些调试信息的钩子函数；还有有些诱导生产代码进入某些重要状态的改变，比如超时、错误，甚至是一些刻意制造的并发行为等因素。
 
-以這種方式使用全局變量是安全的，因爲go test命令併不會同時併發地執行多個測試。
+以这种方式使用全局变量是安全的，因为go test命令并不会同时并发地执行多个测试。

ch11/ch11-02-4.md

@@ -1,20 +1,20 @@
-### 11.2.4. 擴展測試包
+### 11.2.4. 扩展测试包
 
-考慮下這兩個包：net/url包，提供了URL解析的功能；net/http包，提供了web服務和HTTP客戶端的功能。如我們所料，上層的net/http包依賴下層的net/url包。然後，net/url包中的一個測試是演示不同URL和HTTP客戶端的交互行爲。也就是説，一個下層包的測試代碼導入了上層的包。
+考虑下这两个包：net/url包，提供了URL解析的功能；net/http包，提供了web服务和HTTP客户端的功能。如我们所料，上层的net/http包依赖下层的net/url包。然后，net/url包中的一个测试是演示不同URL和HTTP客户端的交互行为。也就是说，一个下层包的测试代码导入了上层的包。
 
 ![](../images/ch11-01.png)
 
-這樣的行爲在net/url包的測試代碼中會導致包的循環依賴，正如圖11.1中向上箭頭所示，同時正如我們在10.1節所講的，Go語言規范是禁止包的循環依賴的。
+这样的行为在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所示。
 
 ![](../images/ch11-02.png)
 
-通過迴避循環導入依賴，擴展測試包可以更靈活的編寫測試，特别是集成測試（需要測試多個組件之間的交互），可以像普通應用程序那樣自由地導入其他包。
+通过回避循环导入依赖，扩展测试包可以更灵活的编写测试，特别是集成测试（需要测试多个组件之间的交互），可以像普通应用程序那样自由地导入其他包。
 
-我們可以用go list命令査看包對應目録中哪些Go源文件是産品代碼，哪些是包內測試，還哪些測試擴展包。我們以fmt包作爲一個例子：GoFiles表示産品代碼對應的Go源文件列表；也就是go build命令要編譯的部分。
+我们可以用go list命令查看包对应目录中哪些Go源文件是产品代码，哪些是包内测试，还哪些测试扩展包。我们以fmt包作为一个例子：GoFiles表示产品代码对应的Go源文件列表；也就是go build命令要编译的部分。
 
 {% raw %}
 
@@ -25,7 +25,7 @@ $ go list -f={{.GoFiles}} fmt
 
 {% endraw %}
 
-TestGoFiles表示的是fmt包內部測試測試代碼，以_test.go爲後綴文件名，不過隻在測試時被構建：
+TestGoFiles表示的是fmt包内部测试测试代码，以_test.go为后缀文件名，不过只在测试时被构建：
 
 {% raw %}
 
@@ -36,9 +36,9 @@ $ go list -f={{.TestGoFiles}} fmt
 
 {% endraw %}
 
-包的測試代碼通常都在這些文件中，不過fmt包併非如此；稍後我們再解釋export_test.go文件的作用。
+包的测试代码通常都在这些文件中，不过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包的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函数，提供给测试扩展包使用。这个技巧可以广泛用于位于测试扩展包的白盒测试。
 

ch11/ch11-02-5.md

@@ -1,10 +1,10 @@
-### 11.2.5. 編寫有效的測試
+### 11.2.5. 编写有效的测试
 
-許多Go語言新人會驚異於它的極簡的測試框架。很多其它語言的測試框架都提供了識别測試函數的機製（通常使用反射或元數據），通過設置一些“setup”和“teardown”的鉤子函數來執行測試用例運行的初始化和之後的清理操作，同時測試工具箱還提供了很多類似assert斷言，值比較函數，格式化輸出錯誤信息和停止一個識别的測試等輔助函數（通常使用異常機製）。雖然這些機製可以使得測試非常簡潔，但是測試輸出的日誌卻會像火星文一般難以理解。此外，雖然測試最終也會輸出PASS或FAIL的報告，但是它們提供的信息格式卻非常不利於代碼維護者快速定位問題，因爲失敗的信息的具體含義是非常隱晦的，比如“assert: 0 == 1”或成頁的海量跟蹤日誌。
+许多Go语言新人会惊异于它的极简的测试框架。很多其它语言的测试框架都提供了识别测试函数的机制（通常使用反射或元数据），通过设置一些“setup”和“teardown”的钩子函数来执行测试用例运行的初始化和之后的清理操作，同时测试工具箱还提供了很多类似assert断言，值比较函数，格式化输出错误信息和停止一个识别的测试等辅助函数（通常使用异常机制）。虽然这些机制可以使得测试非常简洁，但是测试输出的日志却会像火星文一般难以理解。此外，虽然测试最终也会输出PASS或FAIL的报告，但是它们提供的信息格式却非常不利于代码维护者快速定位问题，因为失败的信息的具体含义是非常隐晦的，比如“assert: 0 == 1”或成页的海量跟踪日志。
 
-Go語言的測試風格則形成鮮明對比。它期望測試者自己完成大部分的工作，定義函數避免重複，就像普通編程那樣。編寫測試併不是一個機械的填空過程；一個測試也有自己的接口，盡管它的維護者也是測試僅有的一個用戶。一個好的測試不應該引發其他無關的錯誤信息，它隻要清晰簡潔地描述問題的癥狀卽可，有時候可能還需要一些上下文信息。在理想情況下，維護者可以在不看代碼的情況下就能根據錯誤信息定位錯誤産生的原因。一個好的測試不應該在遇到一點小錯誤時就立刻退出測試，它應該嚐試報告更多的相關的錯誤信息，因爲我們可能從多個失敗測試的模式中發現錯誤産生的規律。
+Go语言的测试风格则形成鲜明对比。它期望测试者自己完成大部分的工作，定义函数避免重复，就像普通编程那样。编写测试并不是一个机械的填空过程；一个测试也有自己的接口，尽管它的维护者也是测试仅有的一个用户。一个好的测试不应该引发其他无关的错误信息，它只要清晰简洁地描述问题的症状即可，有时候可能还需要一些上下文信息。在理想情况下，维护者可以在不看代码的情况下就能根据错误信息定位错误产生的原因。一个好的测试不应该在遇到一点小错误时就立刻退出测试，它应该尝试报告更多的相关的错误信息，因为我们可能从多个失败测试的模式中发现错误产生的规律。
 
-下面的斷言函數比較兩個值，然後生成一個通用的錯誤信息，併停止程序。它很方便使用也確實有效果，但是當測試失敗的時候，打印的錯誤信息卻幾乎是沒有價值的。它併沒有爲快速解決問題提供一個很好的入口。
+下面的断言函数比较两个值，然后生成一个通用的错误信息，并停止程序。它很方便使用也确实有效果，但是当测试失败的时候，打印的错误信息却几乎是没有价值的。它并没有为快速解决问题提供一个很好的入口。
 
 ```Go
 import (
@@ -25,7 +25,7 @@ func TestSplit(t *testing.T) {
 }
 ```
 
-從這個意義上説，斷言函數犯了過早抽象的錯誤：僅僅測試兩個整數是否相同，而放棄了根據上下文提供更有意義的錯誤信息的做法。我們可以根據具體的錯誤打印一個更有價值的錯誤信息，就像下面例子那樣。測試在隻有一次重複的模式出現時引入抽象。
+从这个意义上说，断言函数犯了过早抽象的错误：仅仅测试两个整数是否相同，而放弃了根据上下文提供更有意义的错误信息的做法。我们可以根据具体的错误打印一个更有价值的错误信息，就像下面例子那样。测试在只有一次重复的模式出现时引入抽象。
 
 ```Go
 func TestSplit(t *testing.T) {
@@ -39,10 +39,10 @@ func TestSplit(t *testing.T) {
 }
 ```
 
-現在的測試不僅報告了調用的具體函數、它的輸入和結果的意義；併且打印的眞實返迴的值和期望返迴的值；併且卽使斷言失敗依然會繼續嚐試運行更多的測試。一旦我們寫了這樣結構的測試，下一步自然不是用更多的if語句來擴展測試用例，我們可以用像IsPalindrome的表驅動測試那樣來準備更多的s和sep測試用例。
+现在的测试不仅报告了调用的具体函数、它的输入和结果的意义；并且打印的真实返回的值和期望返回的值；并且即使断言失败依然会继续尝试运行更多的测试。一旦我们写了这样结构的测试，下一步自然不是用更多的if语句来扩展测试用例，我们可以用像IsPalindrome的表驱动测试那样来准备更多的s和sep测试用例。
 
-前面的例子併不需要額外的輔助函數，如果有可以使測試代碼更簡單的方法我們也樂意接受。（我們將在13.3節看到一個類似reflect.DeepEqual輔助函數。）開始一個好的測試的關鍵是通過實現你眞正想要的具體行爲，然後才是考慮然後簡化測試代碼。最好的接口是直接從庫的抽象接口開始，針對公共接口編寫一些測試函數。
+前面的例子并不需要额外的辅助函数，如果有可以使测试代码更简单的方法我们也乐意接受。（我们将在13.3节看到一个类似reflect.DeepEqual辅助函数。）开始一个好的测试的关键是通过实现你真正想要的具体行为，然后才是考虑然后简化测试代码。最好的接口是直接从库的抽象接口开始，针对公共接口编写一些测试函数。
 
-**練習11.5:** 用表格驅動的技術擴展TestSplit測試，併打印期望的輸出結果。
+**练习11.5:** 用表格驱动的技术扩展TestSplit测试，并打印期望的输出结果。
 
 

ch11/ch11-02-6.md

@@ -1,8 +1,8 @@
-### 11.2.6. 避免的不穩定的測試
+### 11.2.6. 避免的不稳定的测试
 
-如果一個應用程序對於新出現的但有效的輸入經常失敗説明程序不夠穩健；同樣如果一個測試僅僅因爲聲音變化就會導致失敗也是不合邏輯的。就像一個不夠穩健的程序會挫敗它的用戶一樣，一個脆弱性測試同樣會激怒它的維護者。最脆弱的測試代碼會在程序沒有任何變化的時候産生不同的結果，時好時壞，處理它們會耗費大量的時間但是併不會得到任何好處。
+如果一个应用程序对于新出现的但有效的输入经常失败说明程序不够稳健；同样如果一个测试仅仅因为声音变化就会导致失败也是不合逻辑的。就像一个不够稳健的程序会挫败它的用户一样，一个脆弱性测试同样会激怒它的维护者。最脆弱的测试代码会在程序没有任何变化的时候产生不同的结果，时好时坏，处理它们会耗费大量的时间但是并不会得到任何好处。
 
-當一個測試函數産生一個複雜的輸出如一個很長的字符串，或一個精心設計的數據結構或一個文件，它可以用於和預設的“golden”結果數據對比，用這種簡單方式寫測試是誘人的。但是隨着項目的發展，輸出的某些部分很可能會發生變化，盡管很可能是一個改進的實現導致的。而且不僅僅是輸出部分，函數複雜複製的輸入部分可能也跟着變化了，因此測試使用的輸入也就不在有效了。
+当一个测试函数产生一个复杂的输出如一个很长的字符串，或一个精心设计的数据结构或一个文件，它可以用于和预设的“golden”结果数据对比，用这种简单方式写测试是诱人的。但是随着项目的发展，输出的某些部分很可能会发生变化，尽管很可能是一个改进的实现导致的。而且不仅仅是输出部分，函数复杂复制的输入部分可能也跟着变化了，因此测试使用的输入也就不在有效了。
 
-避免脆弱測試代碼的方法是隻檢測你眞正關心的屬性。保持測試代碼的簡潔和內部結構的穩定。特别是對斷言部分要有所選擇。不要檢査字符串的全匹配，但是尋找相關的子字符串，因爲某些子字符串在項目的發展中是比較穩定不變的。通常編寫一個重複雜的輸出中提取必要精華信息以用於斷言是值得的，雖然這可能會帶來很多前期的工作，但是它可以幫助迅速及時脩複因爲項目演化而導致的不合邏輯的失敗測試。
+避免脆弱测试代码的方法是只检测你真正关心的属性。保持测试代码的简洁和内部结构的稳定。特别是对断言部分要有所选择。不要检查字符串的全匹配，但是寻找相关的子字符串，因为某些子字符串在项目的发展中是比较稳定不变的。通常编写一个重复杂的输出中提取必要精华信息以用于断言是值得的，虽然这可能会带来很多前期的工作，但是它可以帮助迅速及时修复因为项目演化而导致的不合逻辑的失败测试。
 

ch11/ch11-02.md

@@ -1,6 +1,6 @@
-## 11.2. 測試函數
+## 11.2. 测试函数
 
-每個測試函數必須導入testing包。測試函數有如下的籤名：
+每个测试函数必须导入testing包。测试函数有如下的签名：
 
 ```Go
 func TestName(t *testing.T) {
@@ -8,7 +8,7 @@ func TestName(t *testing.T) {
 }
 ```
 
-測試函數的名字必須以Test開頭，可選的後綴名必須以大寫字母開頭：
+测试函数的名字必须以Test开头，可选的后缀名必须以大写字母开头：
 
 ```Go
 func TestSin(t *testing.T) { /* ... */ }
@@ -16,7 +16,7 @@ func TestCos(t *testing.T) { /* ... */ }
 func TestLog(t *testing.T) { /* ... */ }
 ```
 
-其中t參數用於報告測試失敗和附加的日誌信息。讓我們定義一個實例包gopl.io/ch11/word1，其中隻有一個函數IsPalindrome用於檢査一個字符串是否從前向後和從後向前讀都是一樣的。（下面這個實現對於一個字符串是否是迴文字符串前後重複測試了兩次；我們稍後會再討論這個問題。）
+其中t参数用于报告测试失败和附加的日志信息。让我们定义一个实例包gopl.io/ch11/word1，其中只有一个函数IsPalindrome用于检查一个字符串是否从前向后和从后向前读都是一样的。（下面这个实现对于一个字符串是否是回文字符串前后重复测试了两次；我们稍后会再讨论这个问题。）
 
 <u><i>gopl.io/ch11/word1</i></u>
 ```Go
@@ -35,7 +35,7 @@ func IsPalindrome(s string) bool {
 }
 ```
 
-在相同的目録下，word_test.go測試文件中包含了TestPalindrome和TestNonPalindrome兩個測試函數。每一個都是測試IsPalindrome是否給出正確的結果，併使用t.Error報告失敗信息：
+在相同的目录下，word_test.go测试文件中包含了TestPalindrome和TestNonPalindrome两个测试函数。每一个都是测试IsPalindrome是否给出正确的结果，并使用t.Error报告失败信息：
 
 ```Go
 package word
@@ -58,7 +58,7 @@ func TestNonPalindrome(t *testing.T) {
 }
 ```
 
-`go test`命令如果沒有參數指定包那麽將默認采用當前目録對應的包（和`go build`命令一樣）。我們可以用下面的命令構建和運行測試。
+`go test`命令如果没有参数指定包那么将默认采用当前目录对应的包（和`go build`命令一样）。我们可以用下面的命令构建和运行测试。
 
 ```
 $ cd $GOPATH/src/gopl.io/ch11/word1
@@ -66,7 +66,7 @@ $ go test
 ok   gopl.io/ch11/word1  0.008s
 ```
 
-結果還比較滿意，我們運行了這個程序， 不過沒有提前退出是因爲還沒有遇到BUG報告。不過一個法国名爲“Noelle Eve Elleon”的用戶會抱怨IsPalindrome函數不能識别“été”。另外一個來自美国中部用戶的抱怨則是不能識别“A man, a plan, a canal: Panama.”。執行特殊和小的BUG報告爲我們提供了新的更自然的測試用例。
+结果还比较满意，我们运行了这个程序， 不过没有提前退出是因为还没有遇到BUG报告。不过一个法国名为“Noelle Eve Elleon”的用户会抱怨IsPalindrome函数不能识别“été”。另外一个来自美国中部用户的抱怨则是不能识别“A man, a plan, a canal: Panama.”。执行特殊和小的BUG报告为我们提供了新的更自然的测试用例。
 
 ```Go
 func TestFrenchPalindrome(t *testing.T) {
@@ -83,9 +83,9 @@ func TestCanalPalindrome(t *testing.T) {
 }
 ```
 
-爲了避免兩次輸入較長的字符串，我們使用了提供了有類似Printf格式化功能的 Errorf函數來滙報錯誤結果。
+为了避免两次输入较长的字符串，我们使用了提供了有类似Printf格式化功能的 Errorf函数来汇报错误结果。
 
-當添加了這兩個測試用例之後，`go test`返迴了測試失敗的信息。
+当添加了这两个测试用例之后，`go test`返回了测试失败的信息。
 
 ```
 $ go test
@@ -97,11 +97,11 @@ FAIL
 FAIL    gopl.io/ch11/word1  0.014s
 ```
 
-先編寫測試用例併觀察到測試用例觸發了和用戶報告的錯誤相同的描述是一個好的測試習慣。隻有這樣，我們才能定位我們要眞正解決的問題。
+先编写测试用例并观察到测试用例触发了和用户报告的错误相同的描述是一个好的测试习惯。只有这样，我们才能定位我们要真正解决的问题。
 
-先寫測試用例的另外的好處是，運行測試通常會比手工描述報告的處理更快，這讓我們可以進行快速地迭代。如果測試集有很多運行緩慢的測試，我們可以通過隻選擇運行某些特定的測試來加快測試速度。
+先写测试用例的另外的好处是，运行测试通常会比手工描述报告的处理更快，这让我们可以进行快速地迭代。如果测试集有很多运行缓慢的测试，我们可以通过只选择运行某些特定的测试来加快测试速度。
 
-參數`-v`可用於打印每個測試函數的名字和運行時間：
+参数`-v`可用于打印每个测试函数的名字和运行时间：
 
 ```
 $ go test -v
@@ -120,7 +120,7 @@ exit status 1
 FAIL    gopl.io/ch11/word1  0.017s
 ```
 
-參數`-run`對應一個正則表達式，隻有測試函數名被它正確匹配的測試函數才會被`go test`測試命令運行：
+参数`-run`对应一个正则表达式，只有测试函数名被它正确匹配的测试函数才会被`go test`测试命令运行：
 
 ```
 $ go test -v -run="French|Canal"
@@ -135,11 +135,11 @@ exit status 1
 FAIL    gopl.io/ch11/word1  0.014s
 ```
 
-當然，一旦我們已經脩複了失敗的測試用例，在我們提交代碼更新之前，我們應該以不帶參數的`go test`命令運行全部的測試用例，以確保脩複失敗測試的同時沒有引入新的問題。
+当然，一旦我们已经修复了失败的测试用例，在我们提交代码更新之前，我们应该以不带参数的`go test`命令运行全部的测试用例，以确保修复失败测试的同时没有引入新的问题。
 
-我們現在的任務就是脩複這些錯誤。簡要分析後發現第一個BUG的原因是我們采用了 byte而不是rune序列，所以像“été”中的é等非ASCII字符不能正確處理。第二個BUG是因爲沒有忽略空格和字母的大小寫導致的。
+我们现在的任务就是修复这些错误。简要分析后发现第一个BUG的原因是我们采用了 byte而不是rune序列，所以像“été”中的é等非ASCII字符不能正确处理。第二个BUG是因为没有忽略空格和字母的大小写导致的。
 
-針對上述兩個BUG，我們仔細重寫了函數：
+针对上述两个BUG，我们仔细重写了函数：
 
 <u><i>gopl.io/ch11/word2</i></u>
 ```Go
@@ -166,7 +166,7 @@ func IsPalindrome(s string) bool {
 }
 ```
 
-同時我們也將之前的所有測試數據合併到了一個測試中的表格中。
+同时我们也将之前的所有测试数据合并到了一个测试中的表格中。
 
 ```Go
 func TestIsPalindrome(t *testing.T) {
@@ -196,24 +196,24 @@ func TestIsPalindrome(t *testing.T) {
 }
 ```
 
-現在我們的新測試阿都通過了：
+现在我们的新测试阿都通过了：
 
 ```
 $ go test gopl.io/ch11/word2
 ok      gopl.io/ch11/word2      0.015s
 ```
 
-這種表格驅動的測試在Go語言中很常見的。我們很容易向表格添加新的測試數據，併且後面的測試邏輯也沒有冗餘，這樣我們可以有更多的精力地完善錯誤信息。
+这种表格驱动的测试在Go语言中很常见的。我们很容易向表格添加新的测试数据，并且后面的测试逻辑也没有冗余，这样我们可以有更多的精力地完善错误信息。
 
-失敗測試的輸出併不包括調用t.Errorf時刻的堆棧調用信息。和其他編程語言或測試框架的assert斷言不同，t.Errorf調用也沒有引起panic異常或停止測試的執行。卽使表格中前面的數據導致了測試的失敗，表格後面的測試數據依然會運行測試，因此在一個測試中我們可能了解多個失敗的信息。
+失败测试的输出并不包括调用t.Errorf时刻的堆栈调用信息。和其他编程语言或测试框架的assert断言不同，t.Errorf调用也没有引起panic异常或停止测试的执行。即使表格中前面的数据导致了测试的失败，表格后面的测试数据依然会运行测试，因此在一个测试中我们可能了解多个失败的信息。
 
-如果我們眞的需要停止測試，或許是因爲初始化失敗或可能是早先的錯誤導致了後續錯誤等原因，我們可以使用t.Fatal或t.Fatalf停止當前測試函數。它們必須在和測試函數同一個goroutine內調用。
+如果我们真的需要停止测试，或许是因为初始化失败或可能是早先的错误导致了后续错误等原因，我们可以使用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程序編寫測試。
+**练习 11.1:** 为4.3节中的charcount程序编写测试。
 
-**練習 11.2:** 爲（§6.5）的IntSet編寫一組測試，用於檢査每個操作後的行爲和基於內置map的集合等價，後面練習11.7將會用到。
+**练习 11.2:** 为（§6.5）的IntSet编写一组测试，用于检查每个操作后的行为和基于内置map的集合等价，后面练习11.7将会用到。
 
 
 {% include "./ch11-02-1.md" %}

ch11/ch11-03.md

@@ -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语句则永远都不会被执行到。另外，还有一些隐晦的错误在现实中很少遇到也很难编写对应的测试代码。测试从本质上来说是一个比较务实的工作，编写测试代码和编写应用代码的成本对比是需要考虑的。测试覆盖率工具可以帮助我们快速识别测试薄弱的地方，但是设计好的测试用例和编写应用代码一样需要严密的思考。

ch11/ch11-04.md

@@ -1,8 +1,8 @@
-## 11.4. 基準測試
+## 11.4. 基准测试
 
-基準測試是測量一個程序在固定工作負載下的性能。在Go語言中，基準測試函數和普通測試函數寫法類似，但是以Benchmark爲前綴名，併且帶有一個`*testing.B`類型的參數；`*testing.B`參數除了提供和`*testing.T`類似的方法，還有額外一些和性能測量相關的方法。它還提供了一個整數N，用於指定操作執行的循環次數。
+基准测试是测量一个程序在固定工作负载下的性能。在Go语言中，基准测试函数和普通测试函数写法类似，但是以Benchmark为前缀名，并且带有一个`*testing.B`类型的参数；`*testing.B`参数除了提供和`*testing.T`类似的方法，还有额外一些和性能测量相关的方法。它还提供了一个整数N，用于指定操作执行的循环次数。
 
-下面是IsPalindrome函數的基準測試，其中循環將執行N次。
+下面是IsPalindrome函数的基准测试，其中循环将执行N次。
 
 ```Go
 import "testing"
@@ -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運行測試來估算基準測試函數所需要的時間，然後推斷一個較大的時間保證穩定的測量結果。
+报告显示每次调用IsPalindrome函数花费1.035微秒，是执行1,000,000次的平均时间。因为基准测试驱动器开始时并不知道每个基准测试函数运行所花的时间，它会尝试在真正运行基准测试前先尝试用较小的N运行测试来估算基准测试函数所需要的时间，然后推断一个较大的时间保证稳定的测量结果。
 
-循環在基準測試函數內實現，而不是放在基準測試框架內實現，這樣可以讓每個基準測試函數有機會在循環啟動前執行初始化代碼，這樣併不會顯著影響每次迭代的平均運行時間。如果還是擔心初始化代碼部分對測量時間帶來榦擾，那麽可以通過testing.B參數提供的方法來臨時關閉或重置計時器，不過這些一般很少會用到。
+循环在基准测试函数内实现，而不是放在基准测试框架内实现，这样可以让每个基准测试函数有机会在循环启动前执行初始化代码，这样并不会显著影响每次迭代的平均运行时间。如果还是担心初始化代码部分对测量时间带来干扰，那么可以通过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=.
@@ -51,7 +51,7 @@ BenchmarkIsPalindrome-8 1000000              992 ns/op
 ok      gopl.io/ch11/word2      2.093s
 ```
 
-另一個改進想法是在開始爲每個字符預先分配一個足夠大的數組，這樣就可以避免在append調用時可能會導致內存的多次重新分配。聲明一個letters數組變量，併指定合適的大小，像下面這樣，
+另一个改进想法是在开始为每个字符预先分配一个足够大的数组，这样就可以避免在append调用时可能会导致内存的多次重新分配。声明一个letters数组变量，并指定合适的大小，像下面这样，
 
 ```Go
 letters := make([]rune, 0, len(s))
@@ -62,7 +62,7 @@ for _, r := range s {
 }
 ```
 
-這個改進提陞性能約35%，報告結果是基於2,000,000次迭代的平均運行時間統計。
+这个改进提升性能约35%，报告结果是基于2,000,000次迭代的平均运行时间统计。
 
 ```
 $ go test -bench=.
@@ -71,7 +71,7 @@ BenchmarkIsPalindrome-8 2000000                      697 ns/op
 ok      gopl.io/ch11/word2      1.468s
 ```
 
-如這個例子所示，快的程序往往是伴隨着較少的內存分配。`-benchmem`命令行標誌參數將在報告中包含內存的分配數據統計。我們可以比較優化前後內存的分配情況：
+如这个例子所示，快的程序往往是伴随着较少的内存分配。`-benchmem`命令行标志参数将在报告中包含内存的分配数据统计。我们可以比较优化前后内存的分配情况：
 
 ```
 $ go test -bench=. -benchmem
@@ -79,7 +79,7 @@ PASS
 BenchmarkIsPalindrome    1000000   1026 ns/op    304 B/op  4 allocs/op
 ```
 
-這是優化之後的結果：
+这是优化之后的结果：
 
 ```
 $ go test -bench=. -benchmem
@@ -87,11 +87,11 @@ PASS
 BenchmarkIsPalindrome    2000000    807 ns/op    128 B/op  1 allocs/op
 ```
 
-用一次內存分配代替多次的內存分配節省了75%的分配調用次數和減少近一半的內存需求。
+用一次内存分配代替多次的内存分配节省了75%的分配调用次数和减少近一半的内存需求。
 
-這個基準測試告訴我們所需的絶對時間依賴給定的具體操作，兩個不同的操作所需時間的差異也是和不同環境相關的。例如，如果一個函數需要1ms處理1,000個元素，那麽處理10000或1百萬將需要多少時間呢？這樣的比較揭示了漸近增長函數的運行時間。另一個例子：I/O緩存該設置爲多大呢？基準測試可以幫助我們選擇較小的緩存但能帶來滿意的性能。第三個例子：對於一個確定的工作那種算法更好？基準測試可以評估兩種不同算法對於相同的輸入在不同的場景和負載下的優缺點。
+这个基准测试告诉我们所需的绝对时间依赖给定的具体操作，两个不同的操作所需时间的差异也是和不同环境相关的。例如，如果一个函数需要1ms处理1,000个元素，那么处理10000或1百万将需要多少时间呢？这样的比较揭示了渐近增长函数的运行时间。另一个例子：I/O缓存该设置为多大呢？基准测试可以帮助我们选择较小的缓存但能带来满意的性能。第三个例子：对于一个确定的工作那种算法更好？基准测试可以评估两种不同算法对于相同的输入在不同的场景和负载下的优缺点。
 
-一般比較基準測試都是結構類似的代碼。它們通常是采用一個參數的函數，從幾個標誌的基準測試函數入口調用，就像這樣：
+一般比较基准测试都是结构类似的代码。它们通常是采用一个参数的函数，从几个标志的基准测试函数入口调用，就像这样：
 
 ```Go
 func benchmark(b *testing.B, size int) { /* ... */ }
@@ -100,13 +100,13 @@ func Benchmark100(b *testing.B)        { benchmark(b, 100) }
 func Benchmark1000(b *testing.B)       { benchmark(b, 1000) }
 ```
 
-通過函數參數來指定輸入的大小，但是參數變量對於每個具體的基準測試都是固定的。要避免直接脩改b.N來控製輸入的大小。除非你將它作爲一個固定大小的迭代計算輸入，否則基準測試的結果將毫無意義。
+通过函数参数来指定输入的大小，但是参数变量对于每个具体的基准测试都是固定的。要避免直接修改b.N来控制输入的大小。除非你将它作为一个固定大小的迭代计算输入，否则基准测试的结果将毫无意义。
 
-基準測試對於編寫代碼是很有幫助的，但是卽使工作完成了也應當保存基準測試代碼。因爲隨着項目的發展，或者是輸入的增加，或者是部署到新的操作繫統或不同的處理器，我們可以再次用基準測試來幫助我們改進設計。
+基准测试对于编写代码是很有帮助的，但是即使工作完成了也应当保存基准测试代码。因为随着项目的发展，或者是输入的增加，或者是部署到新的操作系统或不同的处理器，我们可以再次用基准测试来帮助我们改进设计。
 
-**練習 11.6:** 爲2.6.2節的練習2.4和練習2.5的PopCount函數編寫基準測試。看看基於表格算法在不同情況下對提陞性能會有多大幫助。
+**练习 11.6:** 为2.6.2节的练习2.4和练习2.5的PopCount函数编写基准测试。看看基于表格算法在不同情况下对提升性能会有多大帮助。
 
-**練習 11.7:** 爲\*IntSet（§6.5）的Add、UnionWith和其他方法編寫基準測試，使用大量隨機輸入。你可以讓這些方法跑多快？選擇字的大小對於性能的影響如何？IntSet和基於內建map的實現相比有多快？
+**练习 11.7:** 为\*IntSet（§6.5）的Add、UnionWith和其他方法编写基准测试，使用大量随机输入。你可以让这些方法跑多快？选择字的大小对于性能的影响如何？IntSet和基于内建map的实现相比有多快？
 
 
 

ch11/ch11-05.md

@@ -1,22 +1,22 @@
 ## 11.5. 剖析
 
-測量基準對於衡量特定操作的性能是有幫助的，但是當我們視圖讓程序跑的更快的時候，我們通常併不知道從哪里開始優化。每個碼農都應該知道Donald Knuth在1974年的“Structured Programming with go to Statements”上所説的格言。雖然經常被解讀爲不重視性能的意思，但是從原文我們可以看到不同的含義：
+测量基准对于衡量特定操作的性能是有帮助的，但是当我们视图让程序跑的更快的时候，我们通常并不知道从哪里开始优化。每个码农都应该知道Donald Knuth在1974年的“Structured Programming with go to Statements”上所说的格言。虽然经常被解读为不重视性能的意思，但是从原文我们可以看到不同的含义：
 
-> 毫無疑問，效率會導致各種濫用。程序員需要浪費大量的時間思考或者擔心，被部分程序的速度所榦擾，實際上這些嚐試提陞效率的行爲可能産生強烈的負面影響，特别是當調試和維護的時候。我們不應該過度糾結於細節的優化，應該説約97%的場景：過早的優化是萬惡之源。
+> 毫无疑问，效率会导致各种滥用。程序员需要浪费大量的时间思考或者担心，被部分程序的速度所干扰，实际上这些尝试提升效率的行为可能产生强烈的负面影响，特别是当调试和维护的时候。我们不应该过度纠结于细节的优化，应该说约97%的场景：过早的优化是万恶之源。
 >
-> 我們當然不應該放棄那關鍵的3%的機會。一個好的程序員不會因爲這個理由而滿足，他們會明智地觀察和識别哪些是關鍵的代碼；但是隻有在關鍵代碼已經被確認的前提下才會進行優化。對於判斷哪些部分是關鍵代碼是經常容易犯經驗性錯誤的地方，因此程序員普通使用的測量工具，使得他們的直覺很不靠譜。
+> 我们当然不应该放弃那关键的3%的机会。一个好的程序员不会因为这个理由而满足，他们会明智地观察和识别哪些是关键的代码；但是只有在关键代码已经被确认的前提下才会进行优化。对于判断哪些部分是关键代码是经常容易犯经验性错误的地方，因此程序员普通使用的测量工具，使得他们的直觉很不靠谱。
 
-當我們想仔細觀察我們程序的運行速度的時候，最好的技術是如何識别關鍵代碼。自動化的剖析技術是基於程序執行期間一些抽樣數據，然後推斷後面的執行狀態；最終産生一個運行時間的統計數據文件。
+当我们想仔细观察我们程序的运行速度的时候，最好的技术是如何识别关键代码。自动化的剖析技术是基于程序执行期间一些抽样数据，然后推断后面的执行状态；最终产生一个运行时间的统计数据文件。
 
-Go語言支持多種類型的剖析性能分析，每一種關註不同的方面，但它們都涉及到每個采樣記録的感興趣的一繫列事件消息，每個事件都包含函數調用時函數調用堆棧的信息。內建的`go test`工具對幾種分析方式都提供了支持。
+Go语言支持多种类型的剖析性能分析，每一种关注不同的方面，但它们都涉及到每个采样记录的感兴趣的一系列事件消息，每个事件都包含函数调用时函数调用堆栈的信息。内建的`go test`工具对几种分析方式都提供了支持。
 
-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运行时包提供了程序运行时控制分析特性的接口。
 
-一旦我們已經收集到了用於分析的采樣數據，我們就可以使用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”一文。
+这一节我们只是简单看了下Go语言的分析据工具。如果想了解更多，可以阅读Go官方博客的“Profiling Go Programs”一文。

ch11/ch11-06.md

@@ -1,6 +1,6 @@
-## 11.6. 示例函數
+## 11.6. 示例函数
 
-第三種`go test`特别處理的函數是示例函數，以Example爲函數名開頭。示例函數沒有函數參數和返迴值。下面是IsPalindrome函數對應的示例函數：
+第三种`go test`特别处理的函数是示例函数，以Example为函数名开头。示例函数没有函数参数和返回值。下面是IsPalindrome函数对应的示例函数：
 
 ```Go
 func ExampleIsPalindrome() {
@@ -12,14 +12,14 @@ 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語言特性最快捷的方式。
+示例函数的第三个目的提供一个真实的演练场。 http://golang.org 就是由godoc提供的文档服务，它使用了Go Playground提高的技术让用户可以在浏览器中在线编辑和运行每个示例函数，就像图11.4所示的那样。这通常是学习函数使用或Go语言特性最快捷的方式。
 
 ![](../images/ch11-04.png)
 
-本書最後的兩掌是討論reflect和unsafe包，一般的Go用戶很少直接使用它們。因此，如果你還沒有寫過任何眞實的Go程序的話，現在可以忽略剩餘部分而直接編碼了。
+本书最后的两掌是讨论reflect和unsafe包，一般的Go用户很少直接使用它们。因此，如果你还没有写过任何真实的Go程序的话，现在可以忽略剩余部分而直接编码了。

ch11/ch11.md

@@ -1,13 +1,13 @@
-# 第十一章 測試
+# 第十一章 测试
 
-Maurice Wilkes，第一個存儲程序計算機EDSAC的設計者，1949年他在實驗室爬樓梯時有一個頓悟。在《計算機先驅迴憶録》（Memoirs of a Computer Pioneer）里，他迴憶到：“忽然間有一種醍醐灌頂的感覺，我整個後半生的美好時光都將在尋找程序BUG中度過了”。肯定從那之後的大部分正常的碼農都會同情Wilkes過份悲觀的想法，雖然也許不是沒有人睏惑於他對軟件開發的難度的天眞看法。
+Maurice Wilkes，第一个存储程序计算机EDSAC的设计者，1949年他在实验室爬楼梯时有一个顿悟。在《计算机先驱回忆录》（Memoirs of a Computer Pioneer）里，他回忆到：“忽然间有一种醍醐灌顶的感觉，我整个后半生的美好时光都将在寻找程序BUG中度过了”。肯定从那之后的大部分正常的码农都会同情Wilkes过份悲观的想法，虽然也许不是没有人困惑于他对软件开发的难度的天真看法。
 
-現在的程序已經遠比Wilkes時代的更大也更複雜，也有許多技術可以讓軟件的複雜性可得到控製。其中有兩種技術在實踐中證明是比較有效的。第一種是代碼在被正式部署前需要進行代碼評審。第二種則是測試，也就是本章的討論主題。
+现在的程序已经远比Wilkes时代的更大也更复杂，也有许多技术可以让软件的复杂性可得到控制。其中有两种技术在实践中证明是比较有效的。第一种是代码在被正式部署前需要进行代码评审。第二种则是测试，也就是本章的讨论主题。
 
-我們説測試的時候一般是指自動化測試，也就是寫一些小的程序用來檢測被測試代碼（産品代碼）的行爲和預期的一樣，這些通常都是精心設計的執行某些特定的功能或者是通過隨機性的輸入要驗證邊界的處理。
+我们说测试的时候一般是指自动化测试，也就是写一些小的程序用来检测被测试代码（产品代码）的行为和预期的一样，这些通常都是精心设计的执行某些特定的功能或者是通过随机性的输入要验证边界的处理。
 
-軟件測試是一個鉅大的領域。測試的任務可能已經占據了一些程序員的部分時間和另一些程序員的全部時間。和軟件測試技術相關的圖書或博客文章有成韆上萬之多。對於每一種主流的編程語言，都會有一打的用於測試的軟件包，同時也有大量的測試相關的理論，而且每種都吸引了大量技術先驅和追隨者。這些都足以説服那些想要編寫有效測試的程序員重新學習一套全新的技能。
+软件测试是一个巨大的领域。测试的任务可能已经占据了一些程序员的部分时间和另一些程序员的全部时间。和软件测试技术相关的图书或博客文章有成千上万之多。对于每一种主流的编程语言，都会有一打的用于测试的软件包，同时也有大量的测试相关的理论，而且每种都吸引了大量技术先驱和追随者。这些都足以说服那些想要编写有效测试的程序员重新学习一套全新的技能。
 
-Go語言的測試技術是相對低級的。它依賴一個go test測試命令和一組按照約定方式編寫的測試函數，測試命令可以運行這些測試函數。編寫相對輕量級的純測試代碼是有效的，而且它很容易延伸到基準測試和示例文檔。
+Go语言的测试技术是相对低级的。它依赖一个go test测试命令和一组按照约定方式编写的测试函数，测试命令可以运行这些测试函数。编写相对轻量级的纯测试代码是有效的，而且它很容易延伸到基准测试和示例文档。
 
-在實踐中，編寫測試代碼和編寫程序本身併沒有多大區别。我們編寫的每一個函數也是針對每個具體的任務。我們必須小心處理邊界條件，思考合適的數據結構，推斷合適的輸入應該産生什麽樣的結果輸出。編程測試代碼和編寫普通的Go代碼過程是類似的；它併不需要學習新的符號、規則和工具。
+在实践中，编写测试代码和编写程序本身并没有多大区别。我们编写的每一个函数也是针对每个具体的任务。我们必须小心处理边界条件，思考合适的数据结构，推断合适的输入应该产生什么样的结果输出。编程测试代码和编写普通的Go代码过程是类似的；它并不需要学习新的符号、规则和工具。