一直我為軟體的整合、測試深受其苦，幾十萬行的軟體尚且如此，乙個更加龐大的系統又該如何。即使我們增強了單元測試的力度，同樣不能解決有效整合的問題，換句話說就是，即使分系統測試通過，還是不能保證系統更好的整合。
以前我一直有個隱約的想法，軟體系統也應該提供模擬**的功能，在**容器中執行之後，基本就可以可靠的執行於正式系統。在系統整合前，通過**環境就可以模擬整合時的情況，降低系統整合的成本。不過如何**，卻是沒有思路，想想就算了。
上週與朋友吃飯，朋友是《機電系統測試與診斷理論》方面的專家，談起了飛船、衛星等系統的測試時間比較長，如果能夠在設計中引入可測試性的設計，就可以在整合測試中比較容易的定位問題，大大減少測試的時間。朋友做過艦艇的故障檢測，要是老一些的船沒有相應介面，做起來就比較麻煩，如果能在系統的設計過程中預留測試介面，就順利很多。
看來，可測試性的設計就是我想要的東西，平時我們也會做一些。例如乙個事件管理器，addlistener、removelistener、notify是對外介面，listenersize就是乙個測試性介面。對於軟體系統來說，log只是個記錄而已，是遠遠不夠的。假如我在在系統啟動時需要載入 5000 個資源，如果有乙個bug導致其中的乙個資源載入失敗，最好的方式就是在載入過程中提供若干測試介面，用來測試載入過程的狀態，根據狀態分析失敗的原因，如果僅僅根據log進行分析，會是乙個很痛苦的事情，如果故障的發生比較隨機，就更加困難了。
初步的軟體的可測試性設計和硬體、機械系統一樣，需要在設計過程中，建立測試規範，定義測試介面，這些介面和對外的api一樣，是系統的重要組成部分，有了可測試性的規範，**容器也就呼之欲出了，httpunit就是乙個測試容器。兩者結合，就可以認為經過測試的分系統很容易整合到上級系統中；整合的過程中也會很容易的檢測到分系統的故障狀態。
我想：如果有了可測試性的設計，系統即使在執行狀態中，也可以對這些情況進行監控，利用這些中間狀態資訊，軟體也能做到自我容錯的功能。對於乙個可靠性要求高的系統，容錯是提高可靠性必不可少的方法。
不過朋友說，我們機電系統成本太高，需要這個，你們軟體稍稍一改就好了，是不是真的需要呀？確實有道理，靈活是軟體的優勢，但是這種低成本的做法也多少傷害了軟體的質量，例如互動式設計這個重要但是成本比較高的過程，就很少在我們的軟體中體現
軟體測試 軟體測試的定義 軟體測試的目的
軟體測試的定義 軟體測試已有了行業標準 ieee ansi 1983年ieee提出的軟體工程術語中給軟體測試下的定義是 使用人工或自動的手段來執行或測定某個軟體系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。這個定義明確指出 軟體測試的目的是為了檢驗軟體系統是否滿足...
輕鬆構建可復用的軟體測試環境
軟體測試中最令測試人員頭疼的工作任務是什麼？最為繁瑣而沒有成就的工作任務是什麼？相信所有的測試人員都會首推軟體測試環境的搭建和維護。軟體測試環境是進行軟體測試所必需的工作平台和前提條件，其中軟體環境包括被測試軟體執行時的各種作業系統 資料庫和其他應用軟體等，搭建和維護軟體環境是測試工作中工作量最大 ...
微軟軟體測試的可借鑑之處
做測試很久了，一直為一些問題所困擾，也一直對微軟有一種頂禮膜拜的嚮往，終於有一天，近距離的接觸了微軟的測試，感覺不是以前想象中那麼遙不可及，卻又難以企及。於是把個人覺得微軟值得借鑑的地方整理了一下，希望能對大家有所幫助。1 測試流程 首先說說測試流程，微軟的測試流程也沒什麼新的東西，和大多數的測試流...