如何戰勝軟體測試的困境

隨著資訊技術在國內不同行業應用的開展，人們已經不再懷疑軟體對於社會運轉的巨大作用。但是，隨著人們對軟體作用期望值的提高，已經有越來越多人將關注點轉移到軟體的可靠性上，因此，國內軟體測試公司或測評中心如雨後春筍般出現。

軟體測試並非萬能藥

我們在進行軟體測試市場開發的過程中，發現了這樣的一個問題:不少企業認為軟體測試確實很重要，於是提出:我將執行程式(或者還有沒有寫完整的使用者手冊)給你，你給我測吧(“對不起，代碼不能給，因為涉及產權問題”);如果測完通過了，使用者就不應該再可能提出問題了。如果終端使用者提出了問題，企業就會找到軟體測試公司:“看，你是怎麼搞的，使用者提出了問題，你們為什麼不能通過測試找到問題？”。

我們也遇到這樣的情況，某地軟體開發商與使用者多次出現因軟體品質引發的糾紛。於是該公司找到我們說:“既然你們是軟體測試的行家，你們來做測試吧，只要測試費用一個軟體控制在2萬元以內，我們給你們介紹生意。”最終我們沒有敢承擔這樣的業務，因為我們擔心會陷入進退維穀的境地。因此也可以看到，人們對軟體測試的理解存在一些誤區。

對於航空工業之中最進階別的軟體，為了保障其可靠性，進行測試的工作內容包括文法規則檢查和程式分析、條件覆蓋、邊界覆蓋、語句分支覆蓋、需求覆蓋、強壯性、功能性及輸入輸出的測試，最終全部通過，也只能保證10-9的缺陷機率。

因此，軟體測試是提高軟體品質與可靠性的重要一環，但並不意味著有了軟體測試，軟體就不存在問題了。如果僅僅是類比使用者進行一下簡單的試用，則對於軟體品質的驗證效用就更差了。

不妨做一個類比，如果一個工程驗收時，外部裝修極為符合標準，給人的感覺十分良好，我們是不是可以斷定這個工作是品質優良的好工程呢？實際情況經常是，裡面豆腐渣外面金鋼玉。當然你開啟水龍頭、開啟燈泡不會有問題，如果出現了火災、大風，這個工程還行嗎？不知道。為什麼不知道？因為沒有看到施工過程是否符
合規範;施工過程即使合格，不知道材料是否合格。

因此，軟體測試並不是保障軟體可靠性的萬能藥。

軟體測試要分層

如果僅憑使用者手冊，做出來的使用者驗收測試僅僅是以偏概全的特例測試。有經驗的測試者不過是將測試案例設計得更科學些系統些，另外就是增加一些強壯性測試及壓力測試。對於一個安全性可靠性要求不是很高的軟體，這樣做也許就夠了。

但是，我們知道，目前我們國家在搞以“十二金”為代表的電子政務工程。這些工程中涉及財稅的部分以及電信、金融、保險、航空、航天等高科技領域或對軟體可靠性要求高的領域，他們的對軟體的測試僅僅如此是遠遠不行的。不妨簡單地想象一下，航空機載嵌入式軟體要求出現缺陷的機率是10-9，僅憑前面的測試能夠滿足要求嗎？

而進行如此嚴格要求的測試，投入的人力與財力將是十分巨大的。一般來講，至少是開發費用的3~5倍，而且要求開發過程十分規範。

總體來講，我們不贊成簡單地進行使用者類比測試的方式，因為這種做法欠系統和完整。

我個人認為，進行驗收測試要完成如下工作:功能遍曆、連結測試、介面測試、穩定性測試、資料介面測試、安全性測試、效能測試、負載測試、壓力測試、平台測試、瀏覽器測試、強壯性測試等等。

如果在測試過程中發現問題，則要根據相關的設計文檔，將問題隔離到組件進行組件測試。對於核心模組，如功能核心或主要的控制部分，則要進行模組一級的白盒測試。

測試應與開發過程式控制制相配套

許多開發商或使用者關注軟體品質也重視軟體測試，但是由於其開發過程尚不規範，往往導致測試，尤其是模組層級的黑盒與白盒測試難以正常開展。原因很簡單，就是缺少詳細的設計文檔以及對應於各模組代碼的流程圖與介面關係。其結果測試就如盲人摸象——僅靠讀程式是不能看出程式本身是否與設計思想一致、軟體的輸入輸出的正確性的。

因而，要進行軟體測試，特別是嚴格的軟體測試，軟體的開發過程不要僅符合一般的規範;不僅如此，文檔的完備、細緻化程度也應相當高才行。為保證測試效果及迴歸測試的順利開展，開發過程的組態管理也應該嚴格有效。

“巧婦難為無米之炊”。作為專業的軟體測試公司，我們希望通過我們的努力也通過開發商和使用者的共同努力，完善並改進開發流程的過程式控制制和開發文檔，使測試工作能更好地提高軟體的可靠性。

來源：http://abcd0755.spaces.live.com/Blog/cns!A9D8BD9D12D154C8!152.entry