每個實(shí)行持續(xù)交付的項(xiàng)目，都有生產(chǎn)流水線的元素，如持續(xù)集成和自動化測試。這些測試是在不同層面進(jìn)行的，從單元測試到冒煙測試再到功能測試。自動化功能測試的優(yōu)點(diǎn)之一是可重復(fù)性和可預(yù)測的執(zhí)行時間。出于這個原因，它應(yīng)該作為軟件質(zhì)量的每一個構(gòu)建之后的指標(biāo)。功能測試自動化往往會成為一個瓶頸，所以你應(yīng)該熟悉一下如何創(chuàng)建這樣的測試的基本原則。

首先設(shè)計(jì)你的測試測試集合可以比作盆景樹。最初的時候，我們照顧樹根和樹干。我們選擇會成長的主要分支，我們每天都細(xì)心照料這棵樹并等待它長出健康的葉子。我們可以以類似的方式繼續(xù)測試。我們建一個將負(fù)責(zé)應(yīng)用程序主要功能(例如：開啟)的基類。根據(jù)說明，我們先明確將被測試覆蓋的應(yīng)用程序的主要功能，然后每天我們在執(zhí)行測試的時候都添加更多平行測試。每一個支持測試(例如創(chuàng)建一個新的用戶)的方法都需要與測試分離——讓我們在單獨(dú)的類里面來實(shí)現(xiàn)。你應(yīng)該在包括了應(yīng)用程序主要功能的目錄里保持類。去建一個規(guī)定很多功能共有方法的抽象類是很好的做法。如果你正在測試Web應(yīng)用程序，就用頁面對象設(shè)計(jì)模式。該模式里，一個類及其方法對應(yīng)了單個頁面的功能或一個大型網(wǎng)頁里單個頁面上的一個元素。無需事事自動化自動化花費(fèi)很多，所以你應(yīng)該主要測試應(yīng)用程序的主要功能。某些測試可以快速輕松地手動完成，且潛在腳本可能難以實(shí)現(xiàn)。值得用到自動化的是那些繁瑣的需要被重復(fù)很多次的，和那些需要大量數(shù)據(jù)驗(yàn)證的測試工作。寫短測試在一個或多個測試失敗的情況下，開發(fā)團(tuán)隊(duì)的任何成員都應(yīng)該能夠輕松地找到錯誤的原因。出于這個原因，每個測試方法里應(yīng)該最多有5個斷言，并且每個方法都必須提供的測試操作的完整記錄。明智的做法是使用BDD(行為驅(qū)動開發(fā))技術(shù)，但是當(dāng)你沒有用一個特定的測試框架時，你應(yīng)該把接下來的測試步驟放詍ents

//given//when

//then下。創(chuàng)建獨(dú)立測試在測試類中的每個方法應(yīng)該是一個獨(dú)立的實(shí)體，而不是依賴于其他測試。我們應(yīng)該能夠在任何時間運(yùn)行單個測試。否則，這樣的測試用例集將來維護(hù)起來就會很貴——必須定期跟蹤和更新測試之間的聯(lián)系。很多時候，測試需要一定的前提條件來滿足。這些條件不應(yīng)該用外部方法，應(yīng)該在試驗(yàn)開始時運(yùn)行。如果這些條件和測試類的所有方法一樣，它們就可以被放在一開始進(jìn)行的方法里(例如：在JUnit中被標(biāo)記為@

BeforeClass)。關(guān)注可讀性源代碼應(yīng)該是自我記錄的，而寫下以下幾行代碼的每個利益相關(guān)者應(yīng)該明白測試在做什么，為什么它被這么寫。盡量避免在源代碼注釋，因?yàn)樗脖仨毐桓?。這值得花比平常多一點(diǎn)的時間來命名方法，從而使你的代碼更易讀。再看看行為驅(qū)動開發(fā)技術(shù)，每個測試方法都應(yīng)以單詞“應(yīng)該”開始，而不是“測試”。根據(jù)這一慣例，我們馬上就可以明白一個特定的方法測試什么內(nèi)容了，它在分析測試報(bào)告時特別有用。

請聯(lián)系網(wǎng)站客服，了解詳細(xì)的課程信息~

優(yōu)質(zhì)、便捷、省心