我的測試生活感悟

　　1. 真的是萬事開頭難，但我覺得更難的是，每天都堅持做同一件事情。在不被強迫的情況下(如：上班、吃飯、睡覺...)，在可自由支配的時間里，現在我每天堅持做的貌似只有GoogleReader。希望我的測試感悟系列也能堅持下來。

　　2. 在做模塊的接口測試過程中，發現開發所犯的錯誤大多是一些低級的，深刻領悟到：復制粘貼是代碼最大的隱患!

　　3. 最近發現一個BUG，是開發解析xml錯了，導致有的節點內容未讀上來。就這樣一個BUG描述，根本看不出它對產品有多大的影響，也許最了解的人，就是開發自己了。

　　4. 寫的模塊接口測試案例多了，漸漸發現了一些自己的代碼風格，也許以后可以開專題來講解一下。測試代碼和產品代碼是有很大區別的，測試代碼其實是有通用的一些模式的，不然就不會出現XUnit之類的東西?？梢哉fXUnit也是一種風格約束。我總結出來的自己的測試代碼都會分成以下幾個部分：

　　* Caller

　　對開發接口函數調用的包裝，使得案例有一個統一的入口調用開發的函數。開發接口函數變動，只需要變動我們的Caller。(封裝變化)

　　* Checker

　　對接口函數調用的驗證方式的封裝。對被測函數的返回值檢查是最基本的，更多的時候，返回值并不能告訴你一切，返回值告訴你它做了什么，但它沒有證明給你看它確實做到了

　　* DataDefine

　　測試數據是必不可缺的，我將測試數據單獨抽離出來，方便管理和組織。

　　* TestFixtureBases

　　TestFixture的基類，這是我喜歡使用的方式，定義某一類案例的基類，它們做同樣的SetUp和TearDown，共享同樣的函數調用。

　　* TestCases

　　最終到了測試案例這一分類，如果我們把上面的四個分類都做好了，就會發現，測試案例都可以使用一種非常簡潔的方式來表達。在我看來，一個測試案例代碼，五行左右代碼是最優美的。

　　* (附加)CommonSpec

　　有時候，為了讓測試案例更加容易理解，我還喜歡使用BDD的方式表述測試案例。因此，我個人可能還會有一個分類叫CommonSpec，定義的一些自然語言相關的函數?？赡苓@個并不一定適合每個人。

　　5. 上周五去聽了一個關于軟件架構師的課程，總結一下大約有如下幾點收獲：

　　* 架構師首先要明白真正需要解決的問題是什么。例子：老太太買梨

　　* 一個優秀的架構師，必須有一套自己明確的方法論。

　　* 政治->經濟->技術，架構師容易只看到技術上的問題，其實有時技術問題并不是最大的問題。

　　* 架構師是參謀長，也是輔導員。有了自己的架構設計，還要將自己的架構設計描述清楚，并推動設計方案的實施。

　　* (概念部分)架構師的定義，分類，架構設計的過程等等。

　　Art Of Unit Testing

　　今天把《Art Of Unit Testing》的前四個章節讀完了，作者以自己的親身經歷，使用簡潔清晰的語言，為我們展現了單元測試的藝術。

　　1. 怎么定義一個好的測試案例呢?好的測試案例應該是在N年后還能運行良好并易于維護的。

　　2. TOOD - Testabled Object-Oriended Design。作者也提到了這個頗有爭議的問題，許多人認為，增加代碼的可測性的同時，會使得代碼變得更加丑陋。而作者不認為是這樣，作者認為這樣的修改 是另外一種面向對象，同樣的也是優美的，這就是TOOD。

　　3. 為了代碼的可測性增加的一些代碼，常常不希望編譯到最后的產品中?？梢杂泻芏噢k法，比如用宏判斷，如果使用的是.NE，還有一種辦法，就是在相應的函數或類上面使用這個Attribute：[Conditional("DEBUG")]

　　4. Action-Driven Testing 與 Result-Driven Testing，兩種不同的測試流派，一種檢測行為本身，一種檢查最后結果。不能說一定誰優誰劣，但作為單元測試，更多的應該是Action-Driven Testing，因為這樣可以隔離一些其他外部的不穩定因素，當你的案例失敗時，能夠更加準備的定位問題所在。(事實上，集成測試就是Result-Driven Testing，一個很大的困惑就是集成測試案例失敗了，通常是很難馬上定位到原因的。)

　　5. Stubs和Mocks的區別，這兩個東西看起來幾乎是一樣的，事實上也確實很相似。但是，他們的區別也同樣明顯：Stubs不會導致案例失敗，而Mocks會。換成我的理解就是，Stubs是一些假的東西，它能模擬一些我們想要的結果，而Mock呢，它就是一間諜(Test Spy)，告訴我們被測代碼做了些什么，于是，我們通過Mock對象來進行檢查。

　　6. One Mock Per Test，一個測試案例中，通常的模式是N個Stub對應1個Mock。如果一個測試案例有多于一個的Mock對象，說明你的案例感情不夠專一。而一個測試案例，是可以有多個Stub對象的，他們共同協作模擬一些特定的虛擬場景，然后通過Mock對象，驗證我們的被測對象是否對此做出了反應。

　　淘寶的接口測試白皮書

　　今天晚上回來后看到淘寶測試團隊發出來的《接口測試白皮書》，一口氣將它讀完，寫的還是相當不錯的，有非常多值得借鑒和學習的地方。

　　1. 在工作的流程上，各個測試角色是可以互補的，接口測試的設計、用例可以跟功能和性能測試共享，從而構建出整個產品各個環節的測試案例覆蓋程度。

　　這一點之前感觸并不深，現在看來，同一產品的不同測試團隊，像共享bug一樣，將所有人的案例都組織在一起，一起共享是一件非常值得去做的事情。

　　2. 我們的客戶是調用接口的人，不是開發接口的人。

　　說的好!之前一直以為是為開發服務，看來是上面的話總結的比較好，為調用接口的人服務。

　　3. 測試用例設計出來以后應該經過評審，并將評審結果以某種形式記錄下來，作為測試實施的最終方案。評審最好由以下這些人員共同參與：需求方、設計人員、開發人員、功能測試人員、接口測試人員以及這些人員的直接主管。

　　我們這邊的接口測試案例的設計評審還是空缺的，上周我還組織了一次功能測試人員和接口測試人員的接口測試案例評審，看來我要繼續推動這件事了。

　　4. 質量評估標準：

　　* 接口覆蓋率是否達到要求。內部接口90%，外部接口95%。

原文轉自：http://www.anti-gravitydesign.com