1.堅持測試驅動設計(測試先行)的方法。
優先編寫測試代碼,這是標準的XP方法。不是說應該一次性編寫全部測試代碼后,再一次性全部實現。先寫驗收測試,再寫單元測試,編寫一些測試代碼,實現它們,再編寫一些測試代碼,再實現它們等等是個更好的辦法。設計以這種方式得以進展;在實現階段捕捉錯誤并在下一組測試中改正它,以這種方式編寫測試也更少會使人畏縮。
2.盡量做到每個操作對應一個函數,使函數小型化。
使用小型函數說明和重載帶缺省參數的函數將使在測試中調用這些函數變的愉快的多。否則,在測試這些函數時將不得不構造額外參數,如果參數很大,那么將很快導致代碼膨脹。更糟的是,它會誘使你編寫比在其它情況下更少的測試。
3. 數據的顯示與控制分離
把代碼移到 GUI 視圖的外面。然后各種 GUI 動作就能成了模型上的簡單方法調用。這樣,對GUI測試者來說,通過方法調用測試功能比間接地測試功能容易的多。另一個好處是它使修改程序功能而不影響視圖變的更容易。
4.可控制性設計
1)全局變量的可控制性設計
I.在外界使用適當的手段能夠直接或間接控制該變量,包括獲取、修改變量值等;
II. 可以將全局類型的變量進行分類并封裝到一個個接口中操作。
2)接口的可控制性設計
各接口在外界使用適當的手段能夠直接調用對該接口進行操作,這里所謂的適當的手段主要包括使用測試工具和增加額外代碼. 對于向外提供的接口的接洽處能夠人為的對接,比如構造測試環境模擬接口對接,這里所指的開放接口主要是指相對于整個被測系統,即為被測系統以外提供的接口。接口接洽處人為對接時各接口所要求的條件和所需的參數人為的能夠輕易達到和提供。
3)模塊的可控制性設計
對于每個相對獨立的模塊設計好所需要的驅動和樁都能單獨設計用例進行測試對應的功能,在測試運行期間模塊異常時能夠將其隔離而不影響測試。
4)業務流程的可控制性設計
在測試環境滿足的情況下能夠控制任一單獨業務流程,各業務流程具有流通性。
5)場景的可測試性設計
將一場景所涉及到的業務和接口整合到一個統一的接口使其能夠單獨操作該場景。
5.可分解性設計
1)業務流程的可分解性設計
對于復雜的業務流程需合理設定分解點,在測試時能夠對其進行分解。
2)場景的可分解性設計
對于復雜的場景需合理設定分解點,在測試時能夠對其進行分解。
6.穩定性設計
測試模塊發布合理,不能在后期追加的模塊為前期所測模塊引入新的不必要的測試活動。
7.易理解性設計
1)設計文檔的易理解性
I.設計參考標準
II.內容描述主次要分清
III.依賴關系描述明確
2)接口的易理解性
I.接口功能明確
II.參數有意義
3)業務的易理解性
4)場景的易理解性
8.可觀察性設計
1)業務執行狀態和過程可觀察性設計
2)異常情況可觀察性設計
9.測試驅動和樁的設置
為單個測試接口、測試業務、測試場景預留測試驅動和樁的接入點。
10.適合增量式開發的可測試性設計
在增量式開發過程中必須優先考慮測試樁和測試驅動實現的難易程度和真實性。
11.可查詢設計
1)對系統級別的全局變量或者狀態設置查詢接口;
2)某一業務或場景調用接口設置接口路徑查詢
12.自愈合功能
在某一場景中的局部出現故障時設置多路選擇或者其他干涉進行跳轉執行氣候的具有正常邏輯的功能。
13. 輸出結果
對于任何一項操作都要能產生預期的輸出,不管是正確的還是錯誤的甚至是異常的.測試結果的表現形式可以是數據、現象等,不管是以什么方式表現,都要有依可尋,在設計文檔中要有說明。對于測試結果易于判斷,具有可分析性、可獲得性.在設置的各個控制點或觀察點的結果易于查詢、修改等。
14.提供統一的操作執行面板
操作面板元素主要由輸入和輸出元素組成,如所執行的操作和對應的輸出,但可能被測系統是一個比較復雜的系統,由多個可以獨立的模塊組成,涉及到的操作和輸出比較多,各操作之間的關聯也比較復雜。在設計時統一的做一個操作面板,該操作面板成為一個可以操作整個被測系統的獨立模塊,一種是以命令的形式執行操作,直接以printf語句的形式輸出查看,另一種是以GUI的形式,輸入(執行的操作)輸出均在界面上執行和體現,這樣比較直觀。如下圖所示:
原文轉自:http://www.uml.org.cn/zjjs/201004222.asp