菜鳥學軟件測試的知識匯總(2)

　　單元測試的另一個比較重要的特點是能并行進行，這通常是由于構件或者模塊之間的非相關性造成的。這點在測試中很重要，通常會大大縮短測試時間。

　　為了更好的進行單元測試，軟件需要設計的高內聚，也就是設計之初就要采用好的設計模式。這點毫無疑問。

　　集成測試：

　　以前，我一直想這樣一個問題：如果每個模塊都是正確的，為什么要擔心將它們集成在一起后的結果呢?后來在多次參與團隊合作項目之后，終于意識到集成檢測(即使這樣還是沒意識到集成測試，而僅僅是集成檢測)的重要性。關鍵還是“接口”一詞。數據在模塊之間流動時可能部分丟失甚至更改;在一些設計不好的軟件中，或者說不可避免的在所有軟件中，模塊之間會有影響;全局數據結構等等。而這些問題在多個模塊之間很可能會迭代擴大到無法承受的地步。

　　一個不是很恰當的例子，在TCP/IP協議中，網絡層的IP協議與傳輸層的TCP協議都是設計良好的協議，單獨工作都很好，但是集成起來以后必須增加像ICMP這樣的輔助協議才能協調工作。

　　一個更加危險的傾向是，集成的錯誤常常是非增量式的。也就是說，系統在第一次集成時會報一大堆的錯誤，這是因為，錯誤會在構件之間進行傳遞。而且，一旦改正了某個錯誤，反而會出現一系列的新的錯誤，以此類推。

　　由此可見，集成測試是比單元測試更重要也更復雜的測試過程。為了解決這個問題，計算機界的先輩們(PS：大多數是國外的人，哎)提出了許多富有成效的繼承測試策略，比如自頂向下集成測試、自底向下集成測試、回歸測試、冒煙測試等等。太麻煩了，我就不浪費版面的(其實是我也講不太清，囧)。有興趣的朋友可以google之。

　　確認測試：

　　確認測試在前面已經提到過了，是為軟件滿足完備的功能，行為以及性能，交互需求等提供最后的保證。

　　系統測試：

　　這最后的一步實際上已經超出了一半編程人員或者說是測試人員的工程范圍。我們知道，軟件的運行并不只是軟件本身的結構，而是與硬件、數據庫、操作人員、市場環境共同參與的結果。軟件的系統測試必須考慮所有的這些因素，這也是為什么我們說你永遠不能完成測試，這個任務只會從軟件開發人員轉移到客戶身上的原因。

　　1.4 軟件測試成功的標準

　　我想，這是許多關注這篇文章的人最關心的問題之一：測試工作要做到什么時候?

　　關于這個問題我當初也是很感興趣，我遍查了很多書籍，也在網上搜了很多牛人對這個問題的回答，可惜，一直沒找到一個大眾的回答。許多回答都只是經驗之談。

　　一個比較大眾的回答是：測試工作不可能完成，最多是這個工作由程序員轉移到客戶身上。這和峰哥經常強調的“程序沒有完成的一天(咆哮語氣)!!”觀點類似。

　　另一種回答稍顯無聊，但又是非常準確的：一直測試，知道你時間或是資金不能支持為止。

原文轉自：http://www.kjueaiud.com