測試的目的是什么呢?這是一個看起來很簡單、不太值得討論的問題,但往往這樣的問題其實是很難回答的,比如人生的意義是什么?好,現在我們就來,列舉一下我們經常聽到的對這個問題的回答:
“軟件測試的目的是盡可能發(fā)現并改正被測試軟件中的錯誤,提高軟件的可靠性?!保@個定義聽起來很正確,但用它來指導測試會帶來很多問題。比如有的組織用發(fā)現的bug數來衡量測試人員的業(yè)績,其實這就是這種測試目的論在后面作祟,其結果如何呢:其一,有一些不夠敬業(yè)的測試人員會找來一些無關痛癢的bug來充數,結果許多時間會被浪費在這些無關痛癢的bug上(其實應該修復,何時修復,嚴重程度是什么,優(yōu)先級是什么,等等);其二,測試人員會花很大力氣設計一些復雜的測試用例去發(fā)現一些迄今尚未發(fā)現的缺陷,而不關心這些缺陷是否在實際用戶的使用過程當中是否會發(fā)生,從而浪費了大量的寶貴時間。究其根源,就是因為對測試目的的這種錯誤理解造成的,為什么這么說呢?因為軟件里bug的數量是無從估計的,那么如果測試的目的是為了找bug,那么測試工作將變成一項無法完成也無法衡量進度而且部分無效的工作(因為有些bug在實際的運行過程當中根本不會發(fā)生)。
“測試的目的就是為了保證軟件質量”,這個定義也是看似正確,但實際上,混淆了測試和質量保證工作的邊界。軟件質量要素有很多,包括:Understandability、Conciseness、Portability、Consistency、Maintainability、 Testability、Usability、Structures、Efficiency、Security等等,所以,軟件質量保證和測試其實關注的方向是不同的。
那么測試的目的應該是什么呢?IEEE在1983年提出了軟件測試的定義:
“使用人工或自動手段來運行或測定某個系統(tǒng)的過程,其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預期結果與實際結果之間的差別?!?BR> 所以,簡言之,測試的目的應該是驗證需求,bug(預期結果與實際結果之間的差別)是這個過程中的產品而非目標。測試人員應該象工兵一樣,在大部隊(客戶)預期前進的方向上探雷、掃雷(bug),而不需要去關心那些根本沒有人會去碰的地雷。衡量一個測試人員應該去衡量他/她測試了多少需求(測試工作量),漏過了多少bug(測試有效性)。(在后面的博文里我們會進一步談測試后評估的重要性)
因此,我們可以看到有好的需求文檔/體系對測試工作的必要性,我們看到許多測試團隊在業(yè)務需求/軟件需求不完備的情況下,往往或重新編寫測試需求。在未來的博文里,我們會在介紹為什么用例(Use Case)技術會有助于開發(fā)人員和測試人員的溝通。
“軟件測試的目的是盡可能發(fā)現并改正被測試軟件中的錯誤,提高軟件的可靠性?!保@個定義聽起來很正確,但用它來指導測試會帶來很多問題。比如有的組織用發(fā)現的bug數來衡量測試人員的業(yè)績,其實這就是這種測試目的論在后面作祟,其結果如何呢:其一,有一些不夠敬業(yè)的測試人員會找來一些無關痛癢的bug來充數,結果許多時間會被浪費在這些無關痛癢的bug上(其實應該修復,何時修復,嚴重程度是什么,優(yōu)先級是什么,等等);其二,測試人員會花很大力氣設計一些復雜的測試用例去發(fā)現一些迄今尚未發(fā)現的缺陷,而不關心這些缺陷是否在實際用戶的使用過程當中是否會發(fā)生,從而浪費了大量的寶貴時間。究其根源,就是因為對測試目的的這種錯誤理解造成的,為什么這么說呢?因為軟件里bug的數量是無從估計的,那么如果測試的目的是為了找bug,那么測試工作將變成一項無法完成也無法衡量進度而且部分無效的工作(因為有些bug在實際的運行過程當中根本不會發(fā)生)。
“測試的目的就是為了保證軟件質量”,這個定義也是看似正確,但實際上,混淆了測試和質量保證工作的邊界。軟件質量要素有很多,包括:Understandability、Conciseness、Portability、Consistency、Maintainability、 Testability、Usability、Structures、Efficiency、Security等等,所以,軟件質量保證和測試其實關注的方向是不同的。
那么測試的目的應該是什么呢?IEEE在1983年提出了軟件測試的定義:
“使用人工或自動手段來運行或測定某個系統(tǒng)的過程,其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預期結果與實際結果之間的差別?!?BR> 所以,簡言之,測試的目的應該是驗證需求,bug(預期結果與實際結果之間的差別)是這個過程中的產品而非目標。測試人員應該象工兵一樣,在大部隊(客戶)預期前進的方向上探雷、掃雷(bug),而不需要去關心那些根本沒有人會去碰的地雷。衡量一個測試人員應該去衡量他/她測試了多少需求(測試工作量),漏過了多少bug(測試有效性)。(在后面的博文里我們會進一步談測試后評估的重要性)
因此,我們可以看到有好的需求文檔/體系對測試工作的必要性,我們看到許多測試團隊在業(yè)務需求/軟件需求不完備的情況下,往往或重新編寫測試需求。在未來的博文里,我們會在介紹為什么用例(Use Case)技術會有助于開發(fā)人員和測試人員的溝通。