準備實踐自動化測試的朋友可以看看這本書：
xunit test patterns
——refactoring test code
，及其**
。估計國內還沒有譯本。書的內容不錯，只是傾向於單元測試，還糅合了其它諸如「反測試模式」（文中稱為
bad smells
，大概如同
code complete
裡面描述的
bad smells
差不多，只是這裡從自動化測試**的角度而言）的內容。我對測試模式比較感興趣，就採摘一些與大家共享。
任何自動化測試用例都免不了先執行一段**用來做準備（原文是
fixture
，天曉得怎麼直譯，就叫準備吧）：初始化環境，準備資料，初始化需要測試的物件狀態等等。當然也有最簡單的那種什麼都不用準備的——最簡單的就犯不著討論了，是吧——上來就用不同引數呼叫要測試的函式。如果是為了實現高覆蓋率和良好的可重用性、可維護性的話，準備環境就不是一件輕鬆的活。
有多不輕鬆？比如說我準備了上百組引數，這樣覆蓋率足夠了。每組呼叫要測試的函式一次，於是我就用個迴圈，執行一次，全對了。過兩天發現還漏了幾組引數，加上以後發現，喔，原先對的現在不對了。原來有些呼叫改變了重要的狀態，後加的引數暴露了這個問題。那怎麼辦呢，看來每次呼叫之前都要重新設定狀態了。
於是簡單的迴圈不夠，得加入一段重置**。這樣問題消失了。
過幾天要測試的函式多了幾個，內部狀態變複雜了。於是我發現用一些引數呼叫函式時需要這種狀態為前提，用另一些引數呼叫函式時又需要那種狀態為前提。所以，重置狀態的**就不能用了，每個函式呼叫都需要指定設定為什麼狀態了。
你或許覺得你不會遇到這麼複雜的問題。那看看這樣乙個專案，後台資料庫的資料以各種形式的圖表表達在前台介面上，要測試的函式的功能是把資料畫在介面上，不同的引數反映了不同的畫法。過幾天為了提高效能，經常用到的圖表會快取在某個地方。於是內部狀態就跟測試用例及其順序有關係了。
困難還可以演變的更大。更多的測試用例是為了檢驗資料庫裡面不同的資料組合在圖表上有無問題，自從有了它們，原來的測試用例就不得不修改了，因為它們依賴於資料庫裡面不一樣的資料。這樣我還得清除掉資料庫裡面不用的資料並寫入我需要的資料。因為資料庫操作是如此的慢，所以原先兩分鐘就能跑完的上百組測試，現在需要兩個鐘頭。因為要花那麼多的時間來執行，開發人員沒辦法在提交**之前跑完，於是要麼他們不再執行，爆出一大堆
bug，要麼為了等測試跑完浪費了很多時間，沒辦法按時發布產品，大夥兒一塊完蛋。
解決方案就是各種準備環境的測試模式。與設計模式一樣，不同的模式解決不同的問題。 l
最小化準備
n為所有測試用例都需要的準備工作實現乙個函式，這個函式可以利用各種程式語言的能力來實現「一處指定，到處呼叫」，也就是乙個地方標明需要呼叫這個函式，所有測試用例都能預先呼叫這個函式。
l共享準備
n總有若干測試用例需要共同的準備工作，它們可以通過實現乙個函式共享這些邏輯。
n風險在於難以抵抗這樣的**：為了支援更多的測試用例從而讓共享準備越變越大越複雜。
l即時準備
n每個測試用例都把要準備的東西重新建立出來。
n絕大多數解決方案都傾向於這種方法，這是因為，程式設計師總是愛寫**的，呵呵。
n風險在於，如果準備的**比測試用例**還大還複雜怎麼辦？
l永久準備
n狀態用檔案的方式表達，在準備**的指引下合適的裝入記憶體、磁碟或者資料庫。
n如果檔案表達的方式更簡單，人們就傾向於使用資料驅動（
data driven
）的方式；如果檔案已經存在，人們就傾向於把它們放到合適的地方而不是用**生成；如果資料操作費時，人們就傾向於把大部分的資料用資料庫匯入的方式來準備——這就是為什麼有人願意用這種做法。
n風險在於，如果準備檔案的工作量也很大，人們就會陷入兩難：**執行慢，準備檔案也慢。
l生成器準備
n很複雜的資料需要使用**來生成，這樣可以很快的產生大量測試資料。
n比如說為了測試解碼器，需要乙個產生各種編碼的編碼器
n盡量多用現成的，少開發新的吧：你怎麼確保這個生成器是沒有
bug的呢？
l延遲準備
n乙個測試用例可能在中途步驟就因為產品的
bug驗證失敗，如果有些準備工作是後邊步驟才需要的，那就沒有必要一開始就做。
n這是解決測試執行效能問題的乙個小技巧。
l洋蔥頭準備
n原文叫做
decorator
，跟設計模式裡面的
decorator
乙個意思。準備工作也是存在繼承關係的，某一組測試用例
a要用到準備工作a，
b則用到
b，如果
b包含了
a，那麼
b直接呼叫
a好了。
n舉個例子，測試用例
a用到資料庫但不關心裡面的資料，
b則要求裡面至少有某一條記錄，那麼
b的準備工作就是乙個洋蔥，最裡面是建立資料庫，外層則是插入需要的記錄，甚至
c需要在具備這個記錄的同時資料庫還有乙個備份，那就再包一層好了。
l分組準備
n依賴同一種準備工作的測試用例都放在乙個分組裡面。
n這就是最終的解決方案，同類的放在一起處理就不會因為切換而花時間，除錯的時候也容易分離症狀。
所以就前面提到的例子來說，解決方案就是：
l準備乙個最基本的資料庫，匯出成為檔案（最小準備，永久準備）
l根據準備工作的不同對測試用例分類（分組準備）
l提取可以共享的準備工作實現相應的**，如果發現有繼承關係可以用繼承的方式組織這些類（共享準備，洋蔥頭準備）
l確保匯入資料庫檔案的**是洋蔥頭的最裡面，除非某些測試用例需要延遲匯入（延遲準備）
有準備就有清理，下次我們談談清理環境（原文是
fixture teardown
）。
測試模式點滴 準備環境
準備實踐自動化測試的朋友可以看看這本書 xunit test patterns refactoring test code 及其 估計國內還沒有譯本。書的內容不錯，只是傾向於單元測試，還糅合了其它諸如 反測試模式 文中稱為bad smells 大概如同code complete 裡面描述的bad s...
測試模式點滴 驗證模式
準備實踐自動化測試的朋友可以看看這本書 xunit test patterns refactoring test code 及其 估計國內還沒有譯本。書的內容不錯，只是傾向於單元測試，還糅合了其它諸如 反測試模式 文中稱為bad smells 大概如同code complete 裡面描述的bad s...
自動化測試環境準備
如下針對python2.7版本的自動化環境準備 此處選擇最新的2.7.11版本 看到這個介面，把上面的滾動條拉到最下面，有乙個add python.exe to path，預設左邊的圖示是紅色的叉，也就是不會在安裝時執行。以前都是讓大家手動新增，很多人容易漏加scripts目錄，這裡安裝的時候會自動...