軟件測試人員對單元測試的五個錯誤認識[2]

       軟件測試人員對單元測試的五個錯誤認識[2]   軟件測試　

  　錯誤4：自動測試達到75%的覆蓋率——任務完成

　　許多人認為，如果自動測試工具能夠生成近75%覆蓋率的測試，他就能跟老板說自動測試已經完成了。這絕對是個錯誤的想法。雖然這是一個非常好的開始，但你不能僅僅因為這一點就認為已經做完單元測試。實際上你只是剛剛開始而已，你還需要驗證軟件的具體功能。

　　自動測試很有用，但必須讓這些測試與需求掛鉤。為了實現這一點，你可以檢驗并了解這些工具給你生成的測試，然后利用這些免費“禮物”去實現更多的價值。

　　大多數自動測試工具都會提供一些工具集，使你能夠擴展這些自動生成的測試。比如Parasoft Jtest里就有對象庫、樁、測試用例參數化和追蹤工具Tracer(一個只需在應用程序中運行用例便可以生成功能測試用例的工具)。

　　錯誤5：單元測試不值得費工夫

　　每個了解單元測試的人都知道，這絕不是一份簡單的工作，但這并不意味著不值得在這方面花費工夫。

　　單元測試確實有很高的門檻：測試團隊必須了解什么是單元測試、怎樣進行單元測試、用它測試什么，以及如何使用工具簡化單元測試。如果測試團隊真的對單元測試不感興趣、不了解，甚至根本沒有時間開始嘗試它，那么他們可能就不會感覺到單元測試的緊迫性。有些團隊可能認識到單元測試的重要性，但他們只是被問題纏得團團轉，而沒有花時間在真正的方向上邁出第一步。歸根到底，這需要對單元測試的價值、對質量方面的責任，以及它將為項目爭取到的額外時間有一個清楚的認識。

　　那么，是什么讓單元測試的價值超過為此付出的努力呢?單元測試的一個很大優勢在于，發現問題的時間越早，在后期遇到的深層錯誤就越少。這里說的深層錯誤是指那些并沒有形成真正破壞，但它們在API里隱藏得越來越深，直到最后誘發真正問題的錯誤。這種情況發生的時候，通常很難發現問題的源頭。即使你找到源頭，也會發現已經有太多的代碼層依賴于這個API。

　　如果正確地進行單元測試，驗證代碼能夠準確地實現功能，就能更早、更有效地發現問題。如果能及早發現問題，缺陷就不會被帶入源代碼庫中，也就是說以后也無需再對它進行修改——通常這時再修改的困難度、成本與時間都會指數疊加。

　　從我的經驗來看，那些真正采用單元測試的開發人員最終都能寫出更為優秀的代碼，工作效率自然也更高。而原因則在于他們不會被各種缺陷繞得團團轉，無須一次又一次地重寫同一段代碼。任何接受了單元測試，并將其作為所有開發項目標準來實踐的企業都能顯著地提高質量，減少軟件開發過程中的缺陷，并最終獲得巨大的競爭優勢。

原文轉自：http://www.anti-gravitydesign.com