軟件測試的目標(biāo)：失敗等于成功

第第頁軟件測試的目標(biāo)：失敗等于成功軟件測試的目標(biāo)：失敗等于成功

發(fā)表于：2023-10-08來源：：不詳點擊數(shù)：標(biāo)簽：軟件測試

最近，我的一個同事在走廊里攔住我，非常驕傲和熱情地給我描述了她為一套自動測試程序進(jìn)行的設(shè)計和采用的技術(shù)。她說：“最妙的是他們都能夠非常順利、漂亮的運行”。在我走開

最近，我的一個同事在走廊里攔住我，非常驕傲和熱情地給我描述了她為一套自動（測試）程序進(jìn)行的設(shè)計和采用的技術(shù)。她說："最妙的是他們都能夠非常順利、漂亮的運行'。在我走開的時候我在想怎樣采取最溫和的方式告訴她，她已經(jīng)"迷失了方向'。雖然她盡了很大的努力去建立一套成功的（測試），但是她沒有認(rèn)清（軟件測試）的真正目的。

軟件測試的真正目標(biāo)是什么?為了研究這個問題，我隨機(jī)問了一些軟件（開發(fā)）和測試（工程師）、管理人員。其中一些說目標(biāo)是驗證軟件是否滿足用戶和產(chǎn)品的（需求）。其他的人給出了更簡單的回答，例如："確認(rèn)軟件沒有Bugs'以及"為了驗證軟件能夠正常運轉(zhuǎn)'。就我看來，這些說法都不準(zhǔn)確。簡單來說，軟件測試的真正目的是找到以前沒有發(fā)現(xiàn)的（bug）。下面我將從我對軟件測試目標(biāo)的看法出發(fā)，剖析我同事關(guān)于軟件測試的主要目標(biāo)的誤解，并給（測試人員）一些建議。

誤解1：軟件測試的目的是為了確保沒有Bug

這種看法反映了一種對于軟件本質(zhì)的樂觀但從根本上錯誤的觀點。一個簡單的事實就是不存在"bug-free'的軟件。

為什么是這樣呢?首先，在等式的開發(fā)一邊，你必須面對時刻在變化的技術(shù)，一個復(fù)雜的而且經(jīng)常有（缺陷）的應(yīng)用設(shè)計，集成新的已存在的系統(tǒng)帶來的困難，等等。人本身的錯誤也是一個很大的因素。雖然現(xiàn)代思維應(yīng)用開發(fā)工具可以自動生成代碼，但是在有些地方人必須參與到開發(fā)過程中，而人是會犯錯誤的。

而在等式的測試這一邊，不可能讓你的產(chǎn)品在送到你的用戶以前運行所有可能的測試來檢測出每一個可能的bug。讓我們來看一個簡單的假定的例子。比如說你要測試一個這樣的程序：

接受3個整型的數(shù)值作為輸入，每一個數(shù)值的范圍在0到9之間。在種操作系統(tǒng)下運行?？梢栽L問存儲在3個不同廠商中任何一個提供的（數(shù)據(jù)庫）中的數(shù)據(jù)。我們計算一下，我們有1,000種可能的排列作為測試輸入。為了測試在每個操作系統(tǒng)上的每種排列，我們需要2,000個（測試（用例）），另外再考慮到每種輸入在每個支持的（數(shù)據(jù)庫）運行一遍，我們需要6,000個（測試（用例））。這個數(shù)字還沒有考慮到其他的測試情況，例如網(wǎng)絡(luò)故障，磁盤空間不足以及內(nèi)存耗盡等等。所以實際上我們需要測試用例的數(shù)目要更大一些。

無疑，我們不得不接受這樣一個事實：我們只能生活在一個所有的軟件都有bug的世界當(dāng)中。然而，我們沒有必要絕望。經(jīng)過精心的計劃，我們可以選擇性地找出產(chǎn)品中最多出現(xiàn)危險以及對我們的用戶最重要的部分中的bug。下面是我發(fā)現(xiàn)的有效的一些步驟。

在你的計劃當(dāng)中加入風(fēng)險分析

正確理解你的客戶需求文檔本身就是一門科學(xué)(后面將會詳細(xì)講到)。如果你不能直接接觸到你的用戶--例如，通過客戶焦點小組，那么你就應(yīng)該和你的客戶支持部門一起商討你的測試計劃，因為他們直接接觸到最終用戶。

要明白你的產(chǎn)品哪些部分處于危險當(dāng)中同樣需要分析。變更是危險的主要來源;如果你引入了一個變更，你可能不注意地引入了一個新的bug或者發(fā)現(xiàn)一個已經(jīng)存在的bug。因此，支持新功能的代碼一直是一個尋找危險的好地方。為了修正一個bug而修改的代碼也是這樣。而且，如果你在某個地方發(fā)現(xiàn)了bug，那么在附近潛藏著其他bug的可能性就很大。雖然你可能認(rèn)為經(jīng)過多年修正了很多bug的地方最后"清除干凈了'，這種想法只是在修正時發(fā)現(xiàn)了bug的根源的情況下才是正確的。如果bug的根源是糟糕的設(shè)計，而進(jìn)行的修正只是一個簡單的補丁而不是從根本上解決這個問題，那么這個修正實際上可能引入了新的bug。另外，記住：即使是基于"根本原因'的修正也有可能會引發(fā)基礎(chǔ)性變更，暴露其他嚴(yán)重bug。

理解產(chǎn)品是如何工作的--和為何可能出故障

對一些測試者來說，第一個想做的就是看產(chǎn)品外在的可見的"行為'--將精力集中在他們的產(chǎn)品客戶將看到的部分。這樣做效力有限，因為他們沒有清楚的理解產(chǎn)品程序的邏輯，數(shù)據(jù)流等等，這些是用戶不可見的。為了能夠理解產(chǎn)品是如何工作的，以及怎樣會出故障，你必須看"罩子下面'并且在你的測試中用到你看到的東西。

例如，如果你只看一個GUI，你可能看到程序通過一個格式化的HTML表格顯示一個特定的數(shù)據(jù)庫查詢的結(jié)果。然而，除非你知道這個表格的表示是一個（Java）數(shù)組對象，從（服務(wù)器）傳到客戶端，然后轉(zhuǎn)化為一個HTML表格，否則你就不會知道這里存在一個潛在的一個客戶端（性能）瓶頸的危險。如果一個用戶運