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

　　這幾天看了一些關于軟件工程里面軟件測試方面的書籍，感覺蠻有收獲，試與諸君共分享之。

　　軟件測試，對我這個才進入軟件領域兩年不到的菜鳥來說是一個既熟悉又陌生的詞匯。每個軟件行業的人不可能沒聽說過軟件測試，但是，我相信大多數和我一樣的菜鳥都沒有真正對自己寫的軟件程序做過系統的測試工作。

　　說到這里，有很多同學都不樂意了。我怎么沒測試了?!!我都是寫一段代碼就run一下，保證一段代碼成功了才寫后面的好不好。而且，我寫的程序都能正確運行好不好。OK，OK，先不談這個，當年我也是這么認為的，關于這點我們首先來界定下何為軟件測試再說。

　　官話：軟件測試的目的是為了發現軟件設計和實現過程中的疏忽說造成的錯誤。

　　我的理解：發現并修改軟件中不好的部分。這些不好的地方指錯誤、低效代碼、不合理或不方便的設計等等一切影響功能和最終客戶反饋的地方。

　　同學們，還堅持么?

　　一個很嚇人的事實是軟件界存在8020法則，即大多數好的軟件其測試所花費的工作量比其他所有的軟件工程加起來都多，比例為80:20。從這個角度來講，若大型系統的測試還像小游戲一樣無規則、無計劃的進行測試，結果可想而知...可想而知，好的測試思路與方法在正式的測試工作當中是絕對必要的了...

　　一、軟件測試的戰略方法與思想

　　1.1 驗證與確認(Verification and Validation，V&V)

　　在大的方向，軟件測試通常做兩件事：驗證--即保證軟件的功能正確實現，和確認--確保軟件合乎客戶真正的需求。

　　上面的話可能讓人頭痛----不是一樣的意思么?

　　好吧，換一種說法：驗證--我們在正確的構造產品么? 確認--我們在構造正確的產品么?

　　驗證不用說，正確性是軟件(其實遠不止軟件)最基本的要求，做計算器時你至少得保證1+1不等于3吧!!關于確認，很多編程人員都有一個誤區，就是我做客戶讓我做的東西。但一個很重要的問題是，客戶提出的需求真的與軟件的實際需求一致么?撇去客戶表達與需求分析之間的不一致性不談，在人機設計與界面交互這一塊我們能做的更好吧。這里借用MXR同學的成果(見圖1)：當我們在做webAPP時，對同樣的功能需求，不同的表現方式會達到不同的效果。這也就是說，軟件測試，不僅僅是測試錯誤，更要對軟件的可用性與適用性做出修正，即保證軟件的質量。同樣，測試還應該包括性能監控、可行性研究、數據庫評測、算法分析等等一切影響軟件質量的屬性。

　　圖1

　　1.2 軟件測試的組織

　　V&V實現解決了測試是干什么這個基本問題，現在要解決另一個基本問題：誰來做測試工作?

　　很多人會有這樣的思想，對同樣的東西(這里是指待測試的軟件模型)，不同的人在認識上肯定會有差異。那么，軟件開發人員對軟件進行測試是一個很好的選擇，誰能比開發者本人更了解程序呢!!!這也是為什么別人列出一長串代碼讓你找出某個錯誤時，你不耐煩的原因。

　　然而，一個顯而易見的事實是，開發人員本身總是急于展現他們所開發的程序的正確性，是成功的，是符合期望的，這是人之常情。令人遺憾的是，錯誤時客觀存在的。筆者也經常在向別人展示自己花了很大心思做成的程序時，試圖掩飾莫名出現的錯誤。有人說過，從心理學方面來看，軟件的分析和設計都是一類建設性的工作。從本文后面可以看到，軟件人員總是努力構造測試實例來“破壞”軟件。軟件工程師也會自豪與自己的“孩子”，這種仇視任何一個企圖傷害自己“孩子”的人這種心理是可以理解的。

　　那么是否可以得出結論：開發工作與測試工作應該分離開來?答案是否定的。雖然獨立測試組(Independent Test Group，ITG)在所有大公司都是存在的，但開發人員與測試人員在軟件開發初期就應該進行交流。一個原因前面已經說了，你能忍受從頭看別人給你的100000+行代碼，然后找出某個似乎存在的錯誤么?筆者在前一段時間試圖分析hadoop的源代碼，不到兩天腦袋就歇菜了。另一個可能的原因是，測試并不僅僅是“大家一起來找茬”，而是一個自我修正的過程，完全需要開發人員一起來參與。

　　從這個意義上來講，ITG是軟件開發項目組的一部分。

　　1.3 軟件測試的流程

　　如圖2所示，在軟件工程的螺旋開發模型當中，軟件開發呈螺旋方式(PS：可能沒畫出螺旋效果，見諒)。工作開始初期需

　　要在系統級別定義軟件的角色，接著進行需求分析活動，緊接著的是整體與單元設計，最后

　　則是編碼階段。一步一步降低抽象層次。

　　圖2

　　軟件的測試過程同樣可以以一種螺旋模型看待。與開發過程不同，測試過程是一種由內而外的過程，即首先進行單元測試，接著是集成測試，然后是確認測試，最后的活動室系統測試。一般而言，單元測試和集成測試的主要工作在開發期。

　　單元測試：

　　單元測試軟件設計的最小單元(軟件構件或模塊)的驗證過程。這個過程側重于構件中的內部處理邏輯與對外接口、局部數據結構、獨立路徑和錯誤處理路徑。測試內部邏輯與對外接口是為了測試對單元數據的正常流入與流出。這部分不關心數據在構件間的交互。檢查數據結構是為了保證數據信息在算法的執行過程中保證其完整性。筆者曾經寫了一個二叉決策樹，用于一個坦克大戰的小游戲程序中AI坦克方向判斷，但每次在坦克變換方向后都回到初始地方，后來發現是在算法結束后有一項數據被清零了，囧。獨立路徑和錯誤處理路徑會在后面介紹測試戰術中的白盒測試的文章中提到。

　　下面列出別人總結的一些計算中常見的錯誤：1)不正確的算術優先級 2)混合模式操作，貌似我也不理解這個 3)不正確的初始化，以前老犯，現在好了些 4)不精確的精度，暫時沒碰到過，估計一旦出問題，很難發現 5)表達式有不正確的符號表示 5)邊緣測試，這個特別重要，軟件在邊界出錯，通常出現在n維數組或者n次循環的第1個或者第n個元素，哎，這個錯誤筆者犯的數不勝數了，而且一直改不了

原文轉自：http://www.anti-gravitydesign.com