Lukasz Jasinski目前擔(dān)任波蘭弗羅茨瓦夫的BLStream質(zhì)量保證工程師。 Lukasz擁有弗羅茨瓦夫科技大學(xué)遠(yuǎn)程信息學(xué)碩士學(xué)位和兩個ISTQB高級證書。 他是一個測試自動化專家，對各種編程語言掌握的很好。 Lukasz也對連續(xù)傳遞過程及各類散熱器的可視化質(zhì)量方面有興趣。

　　介紹
　　每個實行持續(xù)交付的項目，都有生產(chǎn)流水線的元素，如持續(xù)集成和自動化測試。這些測試是在不同層面進(jìn)行的，從單元測試到冒煙測試再到功能測試。自動化功能測試的優(yōu)點之一是可重復(fù)性和可預(yù)測的執(zhí)行時間。出于這個原因，它應(yīng)該作為軟件質(zhì)量的每一個構(gòu)建之后的指標(biāo)。功能測試自動化往往會成為一個瓶頸，所以你應(yīng)該熟悉一下如何創(chuàng)建這樣的測試的基本原則。
　　
　　首先設(shè)計你的測試
　　測試集合可以比作盆景樹。
　　初的時候，我們照顧樹根和樹干。我們選擇會成長的主要分支，我們每天都細(xì)心照料這棵樹并等待它長出健康的葉子。
　　我們可以以類似的方式繼續(xù)測試。
　　我們建一個將負(fù)責(zé)應(yīng)用程序主要功能（例如：開啟）的基類。
　　根據(jù)說明，我們先明確將被測試覆蓋的應(yīng)用程序的主要功能，然后每天我們在執(zhí)行測試的時候都添加更多平行測試。
　　每一個支持測試（例如創(chuàng)建一個新的用戶）的方法都需要與測試分離——讓我們在單獨的類里面來實現(xiàn)。
　　你應(yīng)該在包括了應(yīng)用程序主要功能的目錄里保持類。
　　去建一個規(guī)定很多功能共有方法的抽象類是很好的做法。
　　如果你正在測試Web應(yīng)用程序，用頁面對象設(shè)計模式。該模式里，一個類及其方法對應(yīng)了單個頁面的功能或一個大型網(wǎng)頁里單個頁面上的一個元素。
　　
　　
　　無需事事自動化
　　自動化花費很多，所以你應(yīng)該主要測試應(yīng)用程序的主要功能。
　　某些測試可以快速輕松地手動完成，且潛在腳本可能難以實現(xiàn)。
　　值得用到自動化的是那些繁瑣的需要被重復(fù)很多次的，和那些需要大量數(shù)據(jù)驗證的測試工作。
　　
　　寫短測試
　　在一個或多個測試失敗的情況下，開發(fā)團(tuán)隊的任何成員都應(yīng)該能夠輕松地找到錯誤的原因。
　　出于這個原因，每個測試方法里應(yīng)該多有5個斷言，并且每個方法都必須提供的測試操作的完整記錄。
　　明智的做法是使用BDD（行為驅(qū)動開發(fā)）技術(shù)，但是當(dāng)你沒有用一個特定的測試框架時，你應(yīng)該把接下來的測試步驟放在comments //given //when //then下。
　　
　　創(chuàng)建獨立測試
　　在測試類中的每個方法應(yīng)該是一個獨立的實體，而不是依賴于其他測試。我們應(yīng)該能夠在任何時間運行單個測試。否則，這樣的測試用例集將來維護(hù)起來會很貴——必須定期跟蹤和更新測試之間的聯(lián)系。
　　很多時候，測試需要一定的前提條件來滿足。這些條件不應(yīng)該用外部方法，應(yīng)該在試驗開始時運行。如果這些條件和測試類的所有方法一樣，它們可以被放在一開始進(jìn)行的方法里（例如：在JUnit中被標(biāo)記為@ BeforeClass）。
　　　
　　關(guān)注可讀性
　　源代碼應(yīng)該是自我記錄的，而寫下以下幾行代碼的每個利益相關(guān)者應(yīng)該明白測試在做什么，為什么它被這么寫。盡量避免在源代碼注釋，因為它也必須被更新。這值得花比平常多一點的時間來命名方法，從而使你的代碼更易讀。
　　再看看行為驅(qū)動開發(fā)技術(shù)，每個測試方法都應(yīng)以單詞“應(yīng)該”開始，而不是“測試”。
　　根據(jù)這一慣例，我們馬上可以明白一個特定的方法測試什么內(nèi)容了，它在分析測試報告時特別有用。
　　
　　測試必須要快
　　正如在本文開頭所提到的，自動化功能測試應(yīng)該是應(yīng)用程序質(zhì)量的一個指標(biāo)。連續(xù)傳遞過程中的每一步都應(yīng)指明長持續(xù)時間；并且根據(jù)這個概念，開發(fā)團(tuán)隊?wèi)?yīng)該盡快獲得有關(guān)軟件質(zhì)量的反饋。自動化功能測試的持續(xù)時間應(yīng)不超過幾分鐘。
　　對一個非常全面的測試集來說，有必要并行運行測試（經(jīng)常在不同的機器上）。虛擬化在這里可能是非常有幫助的。
　　
　　創(chuàng)建抗變測試
　　常提及自動化功能測試的缺點是其對應(yīng)用程序中變化的低抵抗性，尤其是在GUI中。
　　在Web應(yīng)用程序中，測試應(yīng)該能抵抗網(wǎng)站的內(nèi)容的變化。測試應(yīng)該只驗證功能，這使得它可以在不同的位置運行測試。這并不意味著我們不應(yīng)該編寫自動化測試來檢查網(wǎng)頁的內(nèi)容。
　　 如果你已經(jīng)想創(chuàng)建這樣的測試，你應(yīng)該遵循DDT（數(shù)據(jù)驅(qū)動測試）技術(shù)。這意味著，檢查內(nèi)容是與源代碼分離開的。
　　Web應(yīng)用程序的頁面布局變化非常頻繁，這已經(jīng)影響到了用戶界面。
　　當(dāng)你設(shè)計一個界面時，每個區(qū)段和每個頁面你都應(yīng)該有一個你可以用來測試的標(biāo)識符，即使一個網(wǎng)站的層次結(jié)構(gòu)發(fā)生了變化。
　　
　　自動化測試無法取代人類
　　功能自動化測試可以是項目中的主要測試技術(shù)，但絕不是的一個。
　　自動化測試是可重復(fù)再生的，他們的覆蓋范圍總是相同的。
　　另一方面，雖然探索性測試是低再生的，但是它們能夠覆蓋自動化測試未觸及的區(qū)域。
　　你還應(yīng)該記住，自動化測試的“綠色”狀態(tài)并不意味著你的應(yīng)用程序是沒有錯誤的。
　　這種情況往往會讓測試員分心，而且有可能會影響測試的準(zhǔn)確性。

　　版權(quán)聲明：本文出自 SPASVO澤眾軟件測試網(wǎng)：http://hgh666.cn/news/html/201422093452.html