什么是單元測(cè)試？

單元測(cè)試是測(cè)試應(yīng)用程序的各個(gè)單元或組件的實(shí)踐，以驗(yàn)證每個(gè)單元是否正常工作。通常，unit（單元）應(yīng)該是應(yīng)用程序的一小部分 - 在Java中，它通常是單個(gè)類。請(qǐng)注意，并不是嚴(yán)格定義“unit”，開發(fā)人員需要決定每個(gè)測(cè)試的測(cè)試代碼范圍。

人們有時(shí)將“單元測(cè)試”一詞與“集成測(cè)試”或“端到端測(cè)試”進(jìn)行對(duì)比。不同之處在于，通常，單元測(cè)試是用于驗(yàn)證單個(gè)可測(cè)試單元的行為，而集成測(cè)試則驗(yàn)證多個(gè)組件的行為或整個(gè)應(yīng)用程序的行為。就像我所說，構(gòu)成“單元”的定義并沒有嚴(yán)格定義，由你來決定每個(gè)測(cè)試的范圍。

為什么選擇單元測(cè)試？

單元測(cè)試是一種經(jīng)過驗(yàn)證的技術(shù)，可確保軟件質(zhì)量，并帶來很多好處。以下是選擇單元測(cè)試的一些重要原因：

• 單元測(cè)試驗(yàn)證了您的每個(gè)軟件不僅在今天可以正常運(yùn)行，而且在將來也繼續(xù)工作，為未來的發(fā)展奠定了堅(jiān)實(shí)的基礎(chǔ)。
• 單元測(cè)試在生產(chǎn)過程的早期階段識(shí)別了缺陷，這減少了在開發(fā)周期的后期階段修復(fù)它們的成本。
• 經(jīng)過單元測(cè)試的代碼通常更容易重構(gòu)，因?yàn)榭梢钥焖僦匦逻\(yùn)行測(cè)試以驗(yàn)證行為沒有改變。
• 編寫單元測(cè)試迫使開發(fā)人員考慮生產(chǎn)代碼的設(shè)計(jì)如何使其適合于單元測(cè)試，并使開發(fā)人員從不同的角度看待他們的代碼，鼓勵(lì)他們?cè)趯?shí)現(xiàn)中考慮極端情況和錯(cuò)誤條件。
• 在代碼審查過程中包括單元測(cè)試可以揭示修改后的代碼或新代碼應(yīng)該如何工作。此外，審核人員可以確認(rèn)測(cè)試是否良好。

不幸的是，經(jīng)常開發(fā)人員要么根本不編寫單元測(cè)試，要么沒有編寫足夠的測(cè)試，要么不維護(hù)它們。可以理解，畢竟單元測(cè)試有時(shí)候?qū)懫饋砗芗郑蛘呔S護(hù)起來很費(fèi)時(shí)。有時(shí)會(huì)遇到最后期限，感覺編寫測(cè)試會(huì)讓我們錯(cuò)過截止日期。但是，沒有編寫足夠的單元測(cè)試或沒有編寫好的單元測(cè)試容易跳入一個(gè)陷入風(fēng)險(xiǎn)的陷阱。

因此，請(qǐng)考慮以下最佳實(shí)踐建議，了解如何編寫干凈，可維護(hù)，自動(dòng)化的測(cè)試，以最少的時(shí)間和精力為您提供單元測(cè)試的所有好處。

單元測(cè)試最佳實(shí)踐

讓我們看一下構(gòu)建，運(yùn)行和維護(hù)單元測(cè)試的一些最佳實(shí)踐，以獲得最佳結(jié)果。

單元測(cè)試應(yīng)該值得信賴

如果代碼被破壞，并且只有代碼被破壞，測(cè)試才會(huì)失敗。如果沒有，我們無法相信測(cè)試結(jié)果告訴我們的是什么。

單元測(cè)試應(yīng)該是可維護(hù)和可讀的

當(dāng)生產(chǎn)代碼發(fā)生變化時(shí)，通常需要更新測(cè)試，并且可能還需要調(diào)試。所以它必須易于閱讀和理解測(cè)試，不僅適用于編寫它的人，也適用于其他開發(fā)人員。始終組織和命名您的測(cè)試，以提高清晰度和可讀性。

單元測(cè)試應(yīng)驗(yàn)證單個(gè)用例

好的測(cè)試驗(yàn)證一件事或者只驗(yàn)證一件事，這意味著他們通常會(huì)驗(yàn)證一個(gè)用例。遵循此最佳實(shí)踐的測(cè)試更簡單，更易理解，這有利于可維護(hù)性和調(diào)試。驗(yàn)證多個(gè)事物的測(cè)試很容易變得復(fù)雜且耗時(shí)。不要讓這種情況發(fā)生。

另一個(gè)最佳實(shí)踐是使用最少數(shù)量的斷言。有些人建議每次測(cè)試只有一個(gè)斷言（這可能有點(diǎn)過于嚴(yán)格限制了）; 我們的想法是專注于僅驗(yàn)證您正在測(cè)試的用例所需的內(nèi)容。

單元測(cè)試應(yīng)該是隔離的

測(cè)試應(yīng)該可以在任何機(jī)器上以任何順序運(yùn)行，而不會(huì)相互影響。如果可能，測(cè)試應(yīng)該不依賴于環(huán)境因素或全局/外部狀態(tài)。具有這些依賴性的測(cè)試更難以運(yùn)行并且通常不穩(wěn)定，使得它們更難以調(diào)試和修復(fù)，并且最終花費(fèi)的時(shí)間比它們節(jié)省的時(shí)間更多（參見上面的可靠信息）。

幾年前Martin Fowler撰寫了一篇關(guān)于代碼的文章，描述了應(yīng)用程序代碼中的依賴用法，以及如何相應(yīng)地設(shè)計(jì)測(cè)試。在他的文章中，“孤獨(dú)”代碼不依賴于其他單元（它更獨(dú)立），而“社交”代碼確實(shí)與其他組件交互。如果應(yīng)用程序代碼是單獨(dú)的，那么測(cè)試很簡單......但是對(duì)于正在測(cè)試的社交代碼，您可以構(gòu)建“單獨(dú)”或“社交”測(cè)試。“社交測(cè)試”將依賴于實(shí)際依賴性以驗(yàn)證行為，而“孤立測(cè)試”將測(cè)試中的代碼與依賴性隔離開來。您可以使用模擬來隔離測(cè)試中的代碼，并為“社交”構(gòu)建“單獨(dú)”測(cè)試 碼。我們將在下面看看如何做到這一點(diǎn)。

圖1：社交與孤獨(dú)測(cè)試。資料來源：Martin Fowler，2014年

一般來說，使用mock（模擬）作為依賴項(xiàng)使我們作為測(cè)試人員的生活更容易，因?yàn)槲覀兛梢詾樯鐣?huì)化代碼生成“單獨(dú)的測(cè)試”。對(duì)復(fù)雜代碼的社交測(cè)試可能需要大量設(shè)置，并且可能違反被隔離和可重復(fù)的原則。但是由于模擬是在測(cè)試中創(chuàng)建和配置的，因此它是自包含的，我們可以更好地控制依賴項(xiàng)的行為。另外，我們可以測(cè)試更多代碼路徑。例如，我可以返回自定義值或從模擬中拋出異常，以覆蓋邊界或錯(cuò)誤條件。

單元測(cè)試應(yīng)該是自動(dòng)化的

確保測(cè)試正在自動(dòng)化過程中運(yùn)行。這可以是每天，也可以是每小時(shí)，也可以是持續(xù)集成或交付流程。報(bào)告需要可供團(tuán)隊(duì)中的每個(gè)人訪問和審核。作為一個(gè)團(tuán)隊(duì)，請(qǐng)討論您關(guān)注的指標(biāo)：代碼覆蓋率，修改后的代碼覆蓋率，正在運(yùn)行的測(cè)試數(shù)量，性能等。

通過觀察這些數(shù)字可以學(xué)到很多東西，而這些數(shù)字的巨大變化往往表明可以立即解決的回歸問題。

使用良好的單元和集成測(cè)試混合

Michael Cohn的書“ 使用敏捷成功：使用Scrum進(jìn)行軟件開發(fā)”，  使用測(cè)試金字塔模型解決了這個(gè)問題（見下圖中的插圖）。這是描述測(cè)試資源理想分布的常用模型。這個(gè)想法是，當(dāng)你進(jìn)入金字塔時(shí)，測(cè)試通常構(gòu)建起來更復(fù)雜，更脆弱，運(yùn)行速度更慢，調(diào)試速度更慢。較低級(jí)別更加獨(dú)立，更集成，更快速，更易于構(gòu)建和調(diào)試。因此，自動(dòng)化單元測(cè)試應(yīng)該構(gòu)成您的大部分測(cè)試。

單元測(cè)試應(yīng)驗(yàn)證所有細(xì)節(jié)，邊角情況和邊界條件等。應(yīng)更謹(jǐn)慎地使用組件，集成，UI和功能測(cè)試，以驗(yàn)證API或應(yīng)用程序的整體行為。手動(dòng)測(cè)試應(yīng)該是整個(gè)金字塔結(jié)構(gòu)的最小百分比，但仍然可用于發(fā)布驗(yàn)收和探索性測(cè)試。該模型為組織提供了高水平的自動(dòng)化和測(cè)試覆蓋率，因此他們可以擴(kuò)展測(cè)試工作并將與構(gòu)建，運(yùn)行和維護(hù)測(cè)試相關(guān)的成本保持在最低水平。

單元測(cè)試應(yīng)在有組織的測(cè)試實(shí)踐中執(zhí)行

為了在各個(gè)層面推動(dòng)測(cè)試的成功，并使單元測(cè)試過程具有可擴(kuò)展性和可持續(xù)性，您將需要一些額外的實(shí)踐。首先，這意味著在編寫應(yīng)用程序代碼時(shí)編寫單元測(cè)試。一些組織在應(yīng)用程序代碼（測(cè)試驅(qū)動(dòng)或行為驅(qū)動(dòng)編程）之前編寫測(cè)試。重要的是測(cè)試與應(yīng)用程序代碼齊頭并進(jìn)。甚至應(yīng)該在代碼審查過程中一起審查測(cè)試和應(yīng)用程序代碼。評(píng)論可以幫助您理解正在編寫的代碼（因?yàn)樗麄兛梢钥吹筋A(yù)期的行為）并改進(jìn)測(cè)試！

編寫測(cè)試以及代碼不僅適用于新行為或計(jì)劃更改，它對(duì)于錯(cuò)誤修復(fù)也很重要。您修復(fù)的每個(gè)錯(cuò)誤都應(yīng)該有一個(gè)測(cè)試，以驗(yàn)證錯(cuò)誤是否已修復(fù)。這可以確保錯(cuò)誤在將來保持不變。

對(duì)失敗的測(cè)試采用零容忍策略。如果您的團(tuán)隊(duì)忽略了測(cè)試結(jié)果，那么為什么要進(jìn)行測(cè)試呢？測(cè)試失敗應(yīng)該表明真正的問題......所以在他們浪費(fèi)QA的時(shí)間之前立即解決這些問題，或者更糟糕的是，他們進(jìn)入已發(fā)布的產(chǎn)品。

解決故障所需的時(shí)間越長，這些故障最終會(huì)花費(fèi)您的組織的時(shí)間和金錢就越多。因此，在重構(gòu)期間運(yùn)行測(cè)試，在提交代碼之前運(yùn)行測(cè)試，并且在測(cè)試通過之前不要將任務(wù)視為“完成”。

最后，保持這些測(cè)試。正如我之前所說，如果你在應(yīng)用程序發(fā)生變化時(shí)沒有及時(shí)更新這些測(cè)試，那么它們就會(huì)失去價(jià)值。特別是如果他們失敗了，那么失敗的測(cè)試每次失敗都需要花費(fèi)時(shí)間和金錢來進(jìn)行調(diào)查。當(dāng)代碼更改時(shí)，根據(jù)需要重構(gòu)測(cè)試。

正如您所看到的，最大化您在單元測(cè)試中投入的金錢和時(shí)間的回報(bào)需要在應(yīng)用最佳實(shí)踐方面進(jìn)行一些投資。但最終，最后的獎(jiǎng)勵(lì)值得初步投資。

代碼覆蓋率如何？

通常，代碼覆蓋率是在自動(dòng)化測(cè)試運(yùn)行時(shí)執(zhí)行多少生產(chǎn)代碼的度量。通過運(yùn)行一系列測(cè)試并查看代碼覆蓋率數(shù)據(jù)，您可以大致了解正在測(cè)試的應(yīng)用程序的數(shù)量。

代碼覆蓋范圍很多 - 最常見的是線覆蓋和分支覆蓋。大多數(shù)工具都專注于線路覆蓋，它只是告訴您是否覆蓋了特定線路。分支更精細(xì)，因?yàn)樗嬖V您是否覆蓋了代碼中的每條路徑。

代碼覆蓋率是一個(gè)重要的指標(biāo)，但請(qǐng)記住，增加它是達(dá)到目的的手段。它非常適合在測(cè)試中找到差距，但這并不是唯一需要關(guān)注的問題。注意不要花費(fèi)太多精力來實(shí)現(xiàn)100％的覆蓋率 - 它甚至可能不可行或不可行，而且測(cè)試的質(zhì)量確實(shí)是重要的。話雖如此，為您的項(xiàng)目實(shí)現(xiàn)至少60％的覆蓋率是一個(gè)很好的起點(diǎn)，80％或更多是一個(gè)很好的目標(biāo)。顯然，由您來決定該目標(biāo)應(yīng)該是什么。

如果您擁有自動(dòng)化工具，不僅可以測(cè)量代碼覆蓋率，還可以跟蹤測(cè)試覆蓋的修改代碼量，這也很有價(jià)值，因?yàn)檫@可以提供對(duì)是否正在編寫足夠的測(cè)試以及生產(chǎn)代碼更改的可見性。

請(qǐng)參閱Parasoft報(bào)告和分析中心的示例代碼覆蓋率報(bào)告，如果您使用Parasoft Jtest進(jìn)行單元測(cè)試，則可以瀏覽：

另外要記住的是，在編寫新測(cè)試時(shí)，要注意單獨(dú)關(guān)注行覆蓋，因?yàn)閱涡写a可能導(dǎo)致多個(gè)代碼路徑，因此請(qǐng)確保測(cè)試驗(yàn)證這些代碼路徑。線路覆蓋是一個(gè)有用的快速指示器，但它不是唯一要尋找的東西。

增加覆蓋率的最明顯方法是為更多代碼路徑添加更多測(cè)試，以及測(cè)試方法的更多用例。增加覆蓋率的有效方法是使用參數(shù)化測(cè)試。對(duì)于Junit4，內(nèi)置了Junit4參數(shù)化功能和第三方庫，如JunitParams。Junit5具有內(nèi)置參數(shù)化功能。

最后，如果您還沒有跟蹤測(cè)試覆蓋率，我強(qiáng)烈建議您現(xiàn)在就開始。有很多工具可以提供幫助，比如Parasoft Jtest。首先測(cè)量您當(dāng)前的覆蓋率數(shù)字，然后設(shè)定應(yīng)該在哪里的目標(biāo)，首先解決重要的差距，然后從那里開始工作。

總結(jié)

盡管單元測(cè)試是一種用于確保軟件質(zhì)量的成熟技術(shù)，但它仍然被認(rèn)為是開發(fā)人員的負(fù)擔(dān)，許多團(tuán)隊(duì)仍然在努力解決這個(gè)問題。為了充分利用測(cè)試和自動(dòng)化測(cè)試工具，測(cè)試必須值得信賴，可維護(hù)，可讀，獨(dú)立，并用于驗(yàn)證單個(gè)用例。自動(dòng)化是使單元測(cè)試可行且可擴(kuò)展的關(guān)鍵。

此外，軟件團(tuán)隊(duì)需要練習(xí)良好的測(cè)試技術(shù)，例如編寫和審查測(cè)試以及應(yīng)用程序代碼，維護(hù)測(cè)試以及確保立即跟蹤和修復(fù)失敗的測(cè)試。采用這些單元測(cè)試最佳實(shí)踐可以快速提高單元測(cè)試結(jié)果。

想要了解Parasoft、Parasoft SOAtest、Parasoft Virtualize更多信息或資源的朋友，請(qǐng)