軟體測試是每一個軟體專案生命週期必不可少的一個部分，每個程式開發人員都要面對這個不可避免的事實。可是關於測試的一些觀點，也許不是每個人都能理解的。
針對公司的BUG數不斷修改，公司釋出了一道政令：“每個程式開發人員必須對自己開發的程式負責；若測試小組發現一個Bug，開發人員扣二十塊大洋；若客戶發現Bug，測試人員扣三十塊大洋。”政令一出，全體程式開發人員和測試人員反對。可是老闆的意志是不可改變的，政令還是照常執行。剛好一個從政令開始時開始運作，三個月後，專案結束順利上線，專案的一主要程式設計師發現自己的專案獎金全部用來換取Bug所扣的罰款。以後的幾個月時間內後，公司的軟體質量大幅提高，但專案進度遠遠、遠遠落後於以前的同等專案計劃。在第六個月的某一天，公司取消了這道政令，進度跟上，BUG數大幅提高。為什麼會出現這樣的情況呢？
這裡不得不提測試的幾個重要的觀點（個人觀點，僅供參考）。
一、軟體測試的定義和目的
軟體測試是根據軟體的規格說明書和實際應用，設計一批測試案例，查詢程式是否有存在錯誤（其中錯誤是泛稱，可以是功能性，也可以是指效能或者是說和使用者的互動性差等諸多方面）。那麼，軟體測試的目的是什麼呢，是用測試案例來發現程式的錯誤還是用測試案例驗證程式正確呢？其實，一個好的測試案例，就是可以重現程式中沒有發現過的錯誤；那麼測試就是發現程式有錯，而不是驗證正確。這一點對測試很重要，因為它會指導測試人員去設計測試案例的方向性原則。假若測試人員意識形態中是驗證程式正確，那麼他/她設計的測試用例帶有很多虛假的成份，考慮不全面或者說設計一些不容易暴露問題的測試案例。
軟體測試的目的是發現尚未找到的錯誤。
二、程式設計師要不要參於測試
測試人員要不要參加測試呢？可能各個人持有不同的看法。有人主張，有人反對。
現實生活中情形可能是這樣的，程式設計師，特別是經驗不是很豐富的年輕程式設計師，對自己設計的程式，測試了好多次，都沒有發現問題。程式打包提交給測試人員或使用者，操作時發現了有Bug，更嚴重的情況是程式執行不下去。程式設計師當然不服氣，氣沖沖地來進行操作演示，竟然沒有Bug，為什麼呢？是不是程式很怕他的主人（程式設計師）？那倒不是，分析一下，原因很簡單，程式開發人員已經習慣於自己的邏輯思維方法，下意識中避免了或繞開了其它邏輯判斷的條件，程式當然不會出錯。而使用者或測試人員可能有別於程式人員的邏輯思維，當兩者的邏輯思維不相同時，程式就可能出差啦，而且機率相當高。
所以，我個人認為，程式開發人員不應對自己的開發程式進行系統測試。
三、測試的原則
1）要把“儘早地不斷地測試”作為測試的座右銘；
2）測試只能證明錯誤存在，而不能證明問題不存在；
3）如果程式中查出的錯誤越多，則未查出的錯誤也越多。
4）測試應當運用實際資料進行測試，而不是測試人員進行想象中的資料；
5）測試要細心，更要有無情的心；
四、測試、質量、進度之間的關係
有人認為持久的測試和修改可以提高軟體的開發質理。其實未必然。假若有一個粗心的天才和一個細心的白痴做一份試卷，粗心的天才可以透過檢查（測試）來提高成績，而細心的白痴再如何細心，再如何檢查（測試），也不會做試題。
所以說軟體的質量是設計出來的，而不是測試出來的。
有人認為只要我的時間足夠多，軟體就會出現零錯誤。雖然多測試會發現並解決一些問題。但時間並不能解決全部的問題。一個稍微複雜一點的系統，無認透過什麼樣的手法，透過什麼先進的測試理論來指導測試，想徹底消來錯誤，那是不可能的。君不同微軟天天在釋出軟體升級包，是不是微軟的技術不行，設計的測試案例不夠多，還是測試的人數不多（全部上網的使用者全部在幫他測試），這樣算來微軟的測試時間並不短，為什麼還要天天升級，因為程式的錯誤是不可能預見式的消滅的。
那如何來平衡這測試和時間之間的關係呢，軟體開發的成本以及程式所應用的領域等多個方面來進行綜合考慮。對於一般的應用系統（對於上天下海有關人命的系統另當論處），界定一個相對的測試標準，告之程式開發人員和測試人員，讓他們進行遵循其遊戲規則，不要讓程式設計師老覺得沒有修改完錯誤，測試人員老是認為自己的測試進行得不夠。這個遊戲規則就是設計足夠好而多的測試用例，讓使用者可以將程式執行起來。畢竟，設計軟體最終的目的是程式在基本滿足要求的情況下，合法地獲取儘可能多的利潤。[@more@]

小議軟體測試（轉）

相關文章