我的軟件測試生活感悟 軟件測試
以下是我的軟件測試工作感悟，僅供參考：
1. 真的是萬事開頭難，但我覺得更難的是，每天都堅持做同一件事情。在不被強迫的情況下(如：上班、吃飯、睡覺...)，在可自由支配的時間里，現在我每天堅持做的貌似只有GoogleReader。希望我的測試感悟系列也能堅持下來。
2. 在做模塊的接口測試過程中，發現開發所犯的錯誤大多是一些低級的，深刻領悟到：復制粘貼是代碼最大的隱患!
3. 最近發現一個BUG，是開發解析xml錯了，導致有的節點內容未讀上來。就這樣一個BUG描述，根本看不出它對產品有多大的影響，也許最了解的人，就是開發自己了。
4. 寫的模塊接口測試案例多了，漸漸發現了一些自己的代碼風格，也許以后可以開專題來講解一下。測試代碼和產品代碼是有很大區別的，測試代碼其實是有通用的一些模式的，不然就不會出現XUnit之類的東西�？梢哉fXUnit也是一種風格約束。我總結出來的自己的測試代碼都會分成以下幾個部分：
* Caller
對開發接口函數調用的包裝，使得案例有一個統一的入口調用開發的函數。開發接口函數變動，只需要變動我們的Caller。(封裝變化)
* Checker
對接口函數調用的驗證方式的封裝。對被測函數的返回值檢查是最基本的，更多的時候，返回值并不能告訴你一切，返回值告訴你它做了什么，但它沒有證明給你看它確實做到了
* DataDefine
測試數據是必不可缺的，我將測試數據單獨抽離出來，方便管理和組織。
* TestFixtureBases
TestFixture的基類，這是我喜歡使用的方式，定義某一類案例的基類，它們做同樣的SetUp和TearDown，共享同樣的函數調用。
* TestCases
最終到了測試案例這一分類，如果我們把上面的四個分類都做好了，就會發現，測試案例都可以使用一種非常簡潔的方式來表達。在我看來，一個測試案例代碼，五行左右代碼是最優美的。
* (附加)CommonSpec
有時候，為了讓測試案例更加容易理解，我還喜歡使用BDD的方式表述測試案例。因此，我個人可能還會有一個分類叫CommonSpec，定義的一些自然語言相關的函數�？赡苓@個并不一定適合每個人。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
