首先第最重要的問題便是我們系統從開發人員角度來看，從來沒有過進行單元測試的要求，也沒有人做過單元測試。整個系統的配置庫中也沒有對應的測試工程和後續的測試文件提供參考。大部分開發的模式都是編寫**，啟動服務，在前台進行事件觸發，然後在前台看一下事件觸發結果並在後台監控資料庫內資料資訊的準確性。往往在開發過後直接進行系統整合，並少有覆蓋較為廣的測試階段。對於短期開發來講這樣做其實顯現不出什麼問題，但是對於長遠角度來講，沒有留下測試用例和痕跡，在後期人員做維護和修改時會帶來很大的麻煩。後期人員不知道修改前程式或者方法在最初階段預期的結果，可能需要幾倍以上的時間去驗證本程式的準確性。尤其是對於我們這種對業務要求比較高，與各個業務環節關係緊密的系統來講，錯誤的業務理解、沒有參考測試文件的基礎進行的片面性修改等問題，往往錯誤一出現會導致毀滅性的資料問題。
再者我們再進行一下細緻的分析，由於我們系統主要是進行面向服務的程式設計，前台的請求通過交換系統（大廳）的**傳送到各個核心業務域去進行邏輯處理和資料交換。如果進行單元測試，我們會發現其實大部分以服務為前提的測試程式的覆蓋率都為
0%，只有公共**的覆蓋率可以做為參考。並且在分析程式時，大部分服務**的邏輯層和持久層都寫在了一起，程式設計師在邏輯**中想到需要從資料庫中獲取什麼，就直接把
sql語句插入**中間。這樣即使做，也很難做好單元測試的工作，沒法發現
bug到底是出現在邏輯層面還是資料庫層面。
其實就我個人來講，由於是面向服務的程式設計，所以我們的單元測試的最小單元可以放在乙個服務、介面上，而不是乙個程式的方法上。寫好服務測試介面和輸入輸出結果，將測試放在服務容器內進行呼叫，這樣可能效果比較明顯，也比較高效。然後把單元測試介面程式統一放到乙個測試工程內，在系統整合時統一進行單元測試的覆蓋驗證，也可能較為容易地發現
bug和查詢問題。不過這裡會有乙個問題，因為持久層元件沒有公開原始碼，進行服務測試後會直接產生結果資料，如果必要，可能還需要執行撤銷操作的測試服務做配套使用。
這樣想來，是不是系統的穩定性會提高很多，不用每次的修改花很多人力去做繁雜的測試了？當然，測試服務的編寫對既成的**是乙個很大的工程量。不過萬事開頭難，我們可以從以後新修改的**開始做起，日積月累慢慢也會成型。
最後，以上為核心系統單元測試的簡要分析和結果，僅為個人的一家之辭，暫不涉及前台測試的方面。可能後續有時間會再分析一下前台測試。其實我們對於前台測試的忽略程度往往比後台測試更加嚴重。因為後台的程式的最終結果會體現在資料庫層面，直觀而且較為容易發現。而前台則不然，很多操作較為隱晦難於發現，根據操作習慣會忽略很多問題。
與protected成員有關的單元測試方式
這是一篇簡單的文章，討論了單元測試中遇到protected成員的應對方案。此外，在文章最後也希望和大家討論一下某個特殊的情況下的處理方法。protected是乙個有趣而有用的修飾符，它把方法的訪問成員嚴格限制在自身或自己的子類身上。換句話說，在使用過程中，protected成員對外部是開放的 因為其...
單元測試 整合測試 系統測試的區別
單元測試 單元測試是對軟體基本組成單元 軟體設計的最小單位 進行正確性檢驗的測試工作，如函式 過程 function,procedure 或乙個類的方法 method 整合測試 整合測試是在單元測試的基礎上，將所有模組按照概要設計要求組裝成為子系統或系統，驗證組裝後功能以及模組間介面是否正確的測試工...
單元測試 整合測試和系統測試的不同之處
我來說一下單元 測試 整合測試和系統測試的不同之處吧 首先，他們的測試方法不同 單元測試屬於白盒測試 整合測試屬於灰盒測試的範疇 系統測試屬於黑盒測試。其次，他們的考察範圍不同，也就是他們測試的重點不同 單元測試主要測試單元內部的資料結構 邏輯控制 異常處理等等 整合測試主要測試模組之間的介面和介面...