錯誤1：我們已經(jīng)在做單元測試
每個(gè)人對“單元測試”都有不同的認識，不過(guò)大多數業(yè)界專(zhuān)家普遍認為，單元測試應該是測試應用程序的基礎組成部分，即代碼單元。換句話(huà)說(shuō)，這是API層次上的測試。一些團隊聲稱(chēng)他們在做單元測試，而實(shí)際上他們做的是系統測試，或者是所謂的“開(kāi)發(fā)測試（dev test）”。還有一些團隊做了部分API層次的測試，但他們并沒(méi)有把單元測試作為開(kāi)發(fā)過(guò)程中的必要組成部分。
除非團隊把持續進(jìn)行API層次的單元測試作為開(kāi)發(fā)過(guò)程中不可缺少的組成部分，否則單元測試必然會(huì )隨著(zhù)日程與預算帶來(lái)壓力的提升、政策與項目的發(fā)展，以及人員的流動(dòng)而滅亡。
那些極少數長(cháng)期保持傲人業(yè)績(jì)的企業(yè)正是把單元測試安排為例行任務(wù)的企業(yè)。因此，不但要利用自動(dòng)化測試來(lái)保證單元測試盡量全面、順暢、高效地執行，還要為保證這一質(zhì)量過(guò)程能夠長(cháng)期執行并根據需求而調整來(lái)確定基本的工作規范，比如把各個(gè)報告中的問(wèn)題直接指向負責的開(kāi)發(fā)人員，以及讓管理人員能夠及時(shí)方便地看到各開(kāi)發(fā)人員的測試任務(wù)分配情況等。
錯誤2：自動(dòng)測試并沒(méi)多大用處
許多開(kāi)發(fā)人員認為，除非是親自編寫(xiě)單元測試，否則其一點(diǎn)利用價(jià)值都沒(méi)有。這就大錯特錯了。由于生成測試的方式與算法的發(fā)展，測試工具也變得越來(lái)越有效。即使是最基本的自動(dòng)化方法，也可以在很短時(shí)間里生成幾千個(gè)原來(lái)根本無(wú)法完成的測試。這可是毫不費力就可以得到的好處。
除了可以給你生成測試，甚至“免費”幫你找到一些缺陷，自動(dòng)測試還能讓你集中精力進(jìn)行那些更重要、更復雜、更全面的測試，那些真正需要專(zhuān)業(yè)技術(shù)的測試。
當前工具所能提供的高層次的自動(dòng)測試能夠顯著(zhù)減少開(kāi)發(fā)團隊在這些方面的工作，從而節省大量的時(shí)間與精力。如果沒(méi)有這些工具的幫助，單元測試可能會(huì )消耗團隊的大量資源，而這正是讓許多團隊認為單元測試是一種理論上有用但實(shí)際卻很難實(shí)行的測試方法的原因所在。
錯誤3：要做的只是購買(mǎi)一個(gè)優(yōu)秀的單元測試工具
我見(jiàn)過(guò)許多團隊在購買(mǎi)測試工具時(shí)把它當做實(shí)現目標或完成任務(wù)的萬(wàn)能藥。他們不想在其上花費任何精力，不對其進(jìn)行任何設置，也不將其作為工作日程的一部分。到最后，他們自然也無(wú)法得到理想的結果。他們以為單元測試沒(méi)有給他們帶來(lái)任何好處，而實(shí)際上他們并沒(méi)有執行真正意義上的單元測試——而只是在空談。
單元測試工具并不是可以解決所有問(wèn)題的王牌。事實(shí)上，它只是一個(gè)開(kāi)始。開(kāi)發(fā)人員需要的不僅僅是工具，他們還需要適當的指導、訓練、支持設施和工作流程。如果真的希望這個(gè)工具能夠成為開(kāi)發(fā)過(guò)程的一部分，你就得積極主動(dòng)地學(xué)習和使用它，尋找讓它能在既定工作環(huán)境下發(fā)揮作用的辦法，并保證這些使用方法都簡(jiǎn)單易行。目前有許多可以使用的工具，但是除非測試團隊真正去使用它——部署、擴展并根據情況進(jìn)行調整，否則你買(mǎi)到的只是“閑置工具”而已。
錯誤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)勢。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
