軟體測試戰略_測試那些事

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

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

　　說到這裡，有很多同學都不樂意了。我怎麼沒測試了？！！我都是寫一段程式碼就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是軟體開發專案組的一部分。

　　......

本文轉載自51Testing軟體測試網，檢視全文：http://www.51testing.com/html/01/n-810301.html

[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1057794/，如需轉載，請註明出處，否則將追究法律責任。