巧婦難為無米之炊 走出軟件測試的困境

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

軟件測試并非萬能藥

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

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

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

因此，軟件測試是提高軟件質量與可靠性的重要一環，但并不意味著有了軟件測試，軟件就不存在問題了。如果僅僅是模擬用戶進行一下簡單的試用，則對于軟件質量的驗證效用就更差了。

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

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

軟件測試要分層

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

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

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

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

我個人認為，進行驗收測試要完成如下工作:功能遍歷、鏈接測試、界面測試、穩定性測試、數據接口測試、安全性測試、性能測試、負載測試、壓力測試、平臺測試、瀏覽器測試、強壯性測試等等。

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

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

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

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

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