自動化測試的分層結構(3)

　　這如何能解決問題?

　　1. 問題：'測試邏輯難以理解和修改'?，F在我們有了一個單獨的層表示測試邏輯。這層構建在領域層之上，因此測試可以 很用簡潔、緊湊的自然語言形式表述，因此閱讀、理解、推理和修改測試用例的難度，更取決于編碼人員的語言能力，而非編碼水平。

　　2. 問題：'測試很脆弱'。因為我們有一個單獨的層把測試用例和待測系統隔離開，若待測系統有任何變化，只有此層 會受到影響。只要在此層做相應修改，構建于此層之上的測試用例仍然可以執行。

　　3. 問題: '維護開銷大'。因為有了領域層的封裝，各個測試用例中不會再有重復代碼。要做修改，也只需修改一處。此外， 因為領域模型直接針對待測系統建模，代碼也跟容易理解和修改。

　　常見問題解答

　　問題：這個方法看起來有些復雜，必須要這么做嗎?

　　回答：這主要取決于待測系統的規模和復雜程度。如果系統規模較小、業務邏輯相對簡單，這個方法就過于笨重了。在這種情況下，甚至連測試自動化都可能是浪費時間。如果只花幾分鐘時間就能手動測試整個系統，那還自動化干什么呢?若系統較為復雜，把測試邏輯和支持代碼混合在一起問題應該不大。而對業務邏輯復雜、規模龐大的系統(也就是說，大部分企業級應用) 我偏好這種方式。

　　問題：若采用這種結構，那么在開始‘真正’的測試前，需要投入一定時間搭建整個結構，會不會很浪費時間?

　　回答：這只是另外一種組織代碼的方式。即使代碼不按照這種方式組織，還是要寫代碼拼裝URL、解析XML / HTML、驗證測試結果。采用這種結構，只需要把代碼拆分到不同的類及方法中。此外，沒有必要一次完成整個結構?？梢愿鶕斍暗臏y試需要，逐步完成整個結構。

　　問題：完成這個結構需要相當的面向對象知識，并不是所有QA都可以做。

　　回答：實際上測試自動化并不只是QA的職責。項目中其他成員，包括開發人員，也可以參與。

　　開發人員有很強的編程功底，編寫出的代碼質量也相對較高，因此可以負責領域層。而QA擅長設計測試用例、找出各種邊界測試條件，因此可以負責測試用例層。

原文轉自：http://www.uml.org.cn/Test/200911196.asp