傳統的測試方法一般通過web頁面進行測試,這樣做的好處很多,例如:

1)      實現比較簡單,只要有測試用例任何人都可以操作

2)      測試的結果更直觀,如果測試質量足夠好,就能代表這個產品就可以發布了,是質量保證的一個非常重要的階段

當然,也有很多局限性,要不也沒有這么多人想破頭皮采用了其它的方法了,這里列舉3個問題:

1)      測試介入的時間延后,必須要等web頁面完全展現后才能測試,而從實際的項目中來看,java代碼和web頁面的集成是需要一段時間的,這也往往導致測試開始的時間要比計劃的時間延后

2)      發現問題的時間延后,一些關系到前后模塊的或影響到架構的方法要到手工測試的時候才能測試出來,這樣有可能導致返工很多

3)      測試的效率比較低，web頁面存在很多本次測試中并不關心的內容，這些內容的部暑，展現等都需要花很多的資源

正是由于以上的一些問題,常常導致項目的延期發布.那如何預防項目的延后發展呢,答案只有一個,盡早測試,不停地測試。

盡早測試：

Manager層主要關注業務邏輯的測試，但是在web頁面之前就可以測試了，Service層主要是為Manager層服務的一些基礎方法的實現，跟測試微軟發布的一些API差不多。這兩次測試的中心思想是保證上層應用可以正確使用，有了前面的這兩層測試必然是保證了整個產品的質量，也將必然縮短web層的測試時間。

不停地測試

       不停地測試必然用到自動化，在Service層測試，用戶中心項目已經得到了很好的應用，接下來可以在manager層的測試更加自動化。

Manager層和Service層測試的重點和難點：

Manager層的測試主要測試的重點是業務邏輯，但又關系到接口的定義，比如說要測試一個登錄這個業務，首先要編寫測試用例，測試用例的來源來自于業務UC,然后又要了解登錄的接口實現，這樣就要求開發人員在編寫代碼之前先定義好接口的實現，以便測試代碼和開發代碼同步實現，這樣必須要提高前期設計文檔的質量，一旦接口的設計變動，將影響測試代碼的實現。

Service層的代碼主要涉及到物理上的數據讀寫，業務邏輯相對簡單，前期的準備是接口的定義要準確，這一點跟manager層測試一樣。另外需要準備前期的各類測試數據，測試的重點主要集中在數據狀態的完整性。