準備實踐自動化測試的朋友可以看看這本書：xunit test patterns
——refactoring test code
，及其**
。估計國內還沒有譯本。書的內容不錯，只是傾向於單元測試，還糅合了其它諸如「反測試模式」（文中稱為bad smells
，大概如同code complete
裡面描述的bad smells
差不多，只是這裡從自動化測試**的角度而言）的內容。我對測試模式比較感興趣，就採摘一些與大家共享。
前面談論了各種準備和清理的模式，實際上還沒接觸到測試的根本目的，也就是，軟體功能到底有沒有bug
。一般的測試用例分別從兩個角度實現這個目的，要麼是找錯，要麼是確認沒有錯，可以統稱為驗證。這裡我們來看看各種驗證的測試模式。 l
狀態驗證
需要測試的**在接受一系列輸入之後，內部狀態會處於某一種組合。狀態驗證的出發點就是檢查這些狀態是不是符合預期。這個方法假定檢查到的狀態能反映軟體功能實現與否。有時候這個假定不見得可靠。比如說，乙個用html
表示的**，可能每個**裡面的值都是正確的，但是顯示出來不見得就是預期效果，例如
標籤的屬性可能不對，或者頁面其它部分把**覆蓋了也有可能。這種模式的好處是狀態在很多情況下是比較容易獲取，壞處是它不見得能證明軟體功能沒有問題。當然了，如果狀態都不對，軟體功能肯定有問題，所以它可以用來找錯。 l
行為驗證
軟體總是表現一定的行為，例如都需要產生輸出。行為驗證的出發點就是檢查預期的行為有沒有出現。與狀態驗證不一樣的是，它並不在乎內部狀態是怎麼樣，轉而關注外部表現，例如介面，與其它系統的通訊，與作業系統的互動，等等。如果用乙個前台是web
，後台是資料庫的軟體系統為例，後台適用於狀態驗證，前台適用於行為驗證。
l後門驗證
乙個軟體的內部狀態不見得是能被測試程式訪問的。如果在內部留有後門那就不一樣。有一些測試軟體就實現了這些目的。比如visual studio
的工具集裡面有個spy++
，能夠得到指定windows
視窗上處理過的訊息，這就是乙個利用windows
訊息鉤子的後門驗證模式例子；又比如從internet explorer 8
開始**的乙個工具f12
開發人員工具，能夠獲取ie
所顯示的頁面的html
結構，css
內容和ie
與web
伺服器通訊的內容，這也是利用ie
留出的mshtml com
介面的後門驗證模式例子。在後門驗證模式的幫助下，狀態驗證模式可以比較方便的實現。 l
門衛斷言驗證
斷言（assertion
）的目的是在某個狀態不如預期的時候立即引起注意。如同狀態驗證模式的特點，驗證過了不代表沒有問題，不過則代表一定有問題。所以門衛斷言驗證就是一種找錯的模式。舉個例子，電子地圖的行車路線功能可以從眾多內部狀態上分別驗證，但是可以用比較簡單的方法：兩地之間的行車路線總長應該落在乙個合理範圍以內，例如從直線距離到橫向和縱向距離之和之間。這個斷言不通過且功能沒問題的概率太低了。 l
差別斷言驗證
軟體在不同或者先後輸入的條件下的輸入往往是有關聯的，如果某一情況下各個狀態準確驗證有困難，使得狀態驗證不容易實現的話，檢驗這些關聯，簡稱為差別斷言驗證，也是一種辦法。還是以電子地圖的行車路線為例，如果甲地到乙地的路線為a
，乙地道甲地的路線為b
，那麼兩條路線可能因為單行路的關係有差別，但是總長的差別也不應該相差太遠，或者各段路線也不應相差太多。這個斷言不通過且功能沒問題的概率也是很低的。
測試模式點滴 準備環境
準備實踐自動化測試的朋友可以看看這本書 xunit test patterns refactoring test code 及其 估計國內還沒有譯本。書的內容不錯，只是傾向於單元測試，還糅合了其它諸如 反測試模式 文中稱為 bad smells 大概如同 code complete 裡面描述的 ba...
測試模式點滴 準備環境
準備實踐自動化測試的朋友可以看看這本書 xunit test patterns refactoring test code 及其 估計國內還沒有譯本。書的內容不錯，只是傾向於單元測試，還糅合了其它諸如 反測試模式 文中稱為bad smells 大概如同code complete 裡面描述的bad s...
設計模式點滴
1 變更才顯真功夫。業務需求變更永無休止，技術前進就永無止境。在發生變更時才能發覺我們的設計或程式是否是松耦合。2 穩定性較高的設計，在周圍環境頻繁變化的時候，也能做到 我自巋然不動 3 介面負責定義pubilc屬性和方法，並且宣告與其他物件的依賴關係，抽象類負責公共構造部分的實現，實現類準確的實現...