軟件測試的目標：失敗等于成功 軟件測試
最近，我的一個(gè)同事在走廊里攔住我，非常驕傲和熱情地給我描述了她為一套自動(dòng)測試程序進(jìn)行的設計和采用的技術(shù)。她說(shuō)：“最妙的是他們都能夠非常順利、漂亮的運行”。在我走開(kāi)的時(shí)候我在想怎樣采取最溫和的方式告訴她，她已經(jīng)“迷失了方向”。雖然她盡了很大的努力去建立一套成功的測試，但是她沒(méi)有認清軟件測試的真正目的。
軟件測試的真正目標是什么?為了研究這個(gè)問(wèn)題，我隨機問(wèn)了一些軟件開(kāi)發(fā)和測試工程師、管理人員。其中一些說(shuō)目標是驗證軟件是否滿(mǎn)足用戶(hù)和產(chǎn)品的需求。其他的人給出了更簡(jiǎn)單的回答，例如：“確認軟件沒(méi)有Bugs”以及“為了驗證軟件能夠正常運轉”。 就我看來(lái)，這些說(shuō)法都不準確。簡(jiǎn)單來(lái)說(shuō)，軟件測試的真正目的是找到以前沒(méi)有發(fā)現的bug。 下面我將從我對軟件測試目標的看法出發(fā)，剖析我同事關(guān)于軟件測試的主要目標的誤解，并給測試人員一些建議。
誤解1：軟件測試的目的是為了確保沒(méi)有Bug
這種看法反映了一種對于軟件本質(zhì)的樂(lè )觀(guān)但從根本上錯誤的觀(guān)點(diǎn)。一個(gè)簡(jiǎn)單的事實(shí)就是不存在“bug-free”的軟件。
為什么是這樣呢?首先，在等式的開(kāi)發(fā)一邊，你必須面對時(shí)刻在變化的技術(shù)，一個(gè)復雜的而且經(jīng)常有缺陷的應用設計，集成新的已存在的系統帶來(lái)的困難，等等。人本身的錯誤也是一個(gè)很大的因素。雖然現代思維應用開(kāi)發(fā)工具可以自動(dòng)生成代碼，但是在有些地方人必須參與到開(kāi)發(fā)過(guò)程中，而人是會(huì )犯錯誤的。
而在等式的測試這一邊，不可能讓你的產(chǎn)品在送到你的用戶(hù)以前運行所有可能的測試來(lái)檢測出每一個(gè)可能的bug。讓我們來(lái)看一個(gè)簡(jiǎn)單的假定的例子。比如說(shuō)你要測試一個(gè)這樣的程序：
接受3個(gè)整型的數值作為輸入，每一個(gè)數值的范圍在0到9之間。在種操作系統下運行�？梢栽L(fǎng)問(wèn)存儲在3個(gè)不同廠(chǎng)商中任何一個(gè)提供的數據庫中的數據。我們計算一下，我們有1,000種可能的排列作為測試輸入。為了測試在每個(gè)操作系統上的每種排列，我們需要2,000個(gè)測試用例，另外再考慮到每種輸入在每個(gè)支持的數據庫運行一遍，我們需要6,000個(gè)測試用例。這個(gè)數字還沒(méi)有考慮到其他的測試情況，例如網(wǎng)絡(luò )故障，磁盤(pán)空間不足以及內存耗盡等等。所以實(shí)際上我們需要測試用例的數目要更大一些。
無(wú)疑，我們不得不接受這樣一個(gè)事實(shí)：我們只能生活在一個(gè)所有的軟件都有bug的世界當中。然而，我們沒(méi)有必要絕望。經(jīng)過(guò)精心的計劃，我們可以選擇性地找出產(chǎn)品中最多出現危險以及對我們的用戶(hù)最重要的部分中的bug。下面是我發(fā)現的有效的一些步驟。
在你的計劃當中加入風(fēng)險分析
正確理解你的客戶(hù)需求文檔本身就是一門(mén)科學(xué)(后面將會(huì )詳細講到)。如果你不能直接接觸到你的用戶(hù)--例如，通過(guò)客戶(hù)焦點(diǎn)小組，那么你就應該和你的客戶(hù)支持部門(mén)一起商討你的測試計劃，因為他們直接接觸到最終用戶(hù)。
要明白你的產(chǎn)品哪些部分處于危險當中同樣需要分析。變更是危險的主要來(lái)源;如果你引入了一個(gè)變更，你可能不注意地引入了一個(gè)新的bug或者發(fā)現一個(gè)已經(jīng)存在的bug。因此，支持新功能的代碼一直是一個(gè)尋找危險的好地方。為了修正一個(gè)bug而修改的代碼也是這樣。而且，如果你在某個(gè)地方發(fā)現了bug，那么在附近潛藏著(zhù)其他bug的可能性就很大。雖然你可能認為經(jīng)過(guò)多年修正了很多bug的地方最后“清除干凈了”，這種想法只是在修正時(shí)發(fā)現了bug的根源的情況下才是正確的。如果bug的根源是糟糕的設計，而進(jìn)行的修正只是一個(gè)簡(jiǎn)單的補丁而不是從根本上解決這個(gè)問(wèn)題，那么這個(gè)修正實(shí)際上可能引入了新的bug。另外，記�。杭词故腔凇案驹颉钡男拚灿锌赡軙�(huì )引發(fā)基礎性變更，暴露其他嚴重bug。
理解產(chǎn)品是如何工作的--和為何可能出故障
對一些測試者來(lái)說(shuō)，第一個(gè)想做的就是看產(chǎn)品外在的可見(jiàn)的“行為”--將精力集中在他們的產(chǎn)品客戶(hù)將看到的部分。這樣做效力有限，因為他們沒(méi)有清楚的理解產(chǎn)品程序的邏輯，數據流等等，這些是用戶(hù)不可見(jiàn)的。為了能夠理解產(chǎn)品是如何工作的，以及怎樣會(huì )出故障，你必須看“罩子下面”并且在你的測試中用到你看到的東西。
例如，如果你只看一個(gè)GUI，你可能看到程序通過(guò)一個(gè)格式化的HTML表格顯示一個(gè)特定的數據庫查詢(xún)的結果。然而，除非你知道這個(gè)表格的表示是一個(gè)Java數組對象，從服務(wù)器傳到客戶(hù)端，然后轉化為一個(gè)HTML表格，否則你就不會(huì )知道這里存在一個(gè)潛在的一個(gè)客戶(hù)端性能瓶頸的危險。如果一個(gè)用戶(hù)運行一個(gè)查詢(xún)，返回的記錄太多，就會(huì )導致客戶(hù)端在處理表格的時(shí)候像死機一樣。(我在幾年前是通過(guò)這樣的方法解決這個(gè)問(wèn)題的：每次讓客戶(hù)端只接收一部分結果數據，并且明確地告訴用戶(hù)還有其他的數據未傳過(guò)來(lái)。)
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
