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

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

  　錯誤4：自動(dòng)測試達到75%的覆蓋率——任務(wù)完成

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

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

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

　　錯誤5：?jiǎn)卧獪y試不值得費工夫

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

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

　　那么，是什么讓單元測試的價(jià)值超過(guò)為此付出的努力呢?單元測試的一個(gè)很大優(yōu)勢在于，發(fā)現問(wèn)題的時(shí)間越早，在后期遇到的深層錯誤就越少。這里說(shuō)的深層錯誤是指那些并沒(méi)有形成真正破壞，但它們在A(yíng)PI里隱藏得越來(lái)越深，直到最后誘發(fā)真正問(wèn)題的錯誤。這種情況發(fā)生的時(shí)候，通常很難發(fā)現問(wèn)題的源頭。即使你找到源頭，也會(huì )發(fā)現已經(jīng)有太多的代碼層依賴(lài)于這個(gè)API。

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

　　從我的經(jīng)驗來(lái)看，那些真正采用單元測試的開(kāi)發(fā)人員最終都能寫(xiě)出更為優(yōu)秀的代碼，工作效率自然也更高。而原因則在于他們不會(huì )被各種缺陷繞得團團轉，無(wú)須一次又一次地重寫(xiě)同一段代碼。任何接受了單元測試，并將其作為所有開(kāi)發(fā)項目標準來(lái)實(shí)踐的企業(yè)都能顯著(zhù)地提高質(zhì)量，減少軟件開(kāi)發(fā)過(guò)程中的缺陷，并最終獲得巨大的競爭優(yōu)勢。

原文轉自：http://kjueaiud.com