怎樣構(gòu)建測試自動化框架？你得記住以下三個編碼實踐！

Jason 發(fā)布于2021-09-04 16:45 / 935人閱讀

摘要：為了構(gòu)建可伸縮的測試自動化框架，需要記住以下三個最重要的干凈編碼實踐。因此，組織期望其或測試自動化架構(gòu)師設(shè)計和開發(fā)健壯，可維護的智能測試自動化框架。包括適當(dāng)?shù)奈臋n在測試自動化框架開發(fā)項目中工作的程序員不太可能獨自編寫代碼。

概要

許多組織都希望通過設(shè)計和開發(fā)測試自動化框架來擴展他們的自動化能力。然而，我們經(jīng)常放棄良好的編碼實踐，而傾向于盡可能快地工作。我們需要像對待其他應(yīng)用程序開發(fā)項目一樣對待這個項目。為了構(gòu)建可伸縮的測試自動化框架，需要記住以下三個最重要的干凈編碼實踐。

作為測試或SDET軟件開發(fā)工程師，我可以參與軟件及其測試的開發(fā)。看到當(dāng)今有多少軟件組織將測試自動化作為他們的敏捷和DevOps旅程的一部分，這讓我感到非常著迷和激動。

正如我所看到的，自動化測試不再只是一種探索的選擇，而是必不可少的。而且這種趨勢將繼續(xù)上升。在產(chǎn)品生命周期中進行自動化的早期測試并經(jīng)常進行自動化測試，不僅有助于我們更快地發(fā)現(xiàn)錯誤，而且在很大程度上節(jié)省了時間和成本。因此，組織期望其SDET或測試自動化架構(gòu)師設(shè)計和開發(fā)健壯，可維護的智能測試自動化框架。

但是，由于缺乏遠(yuǎn)見，許多自動化測試計劃都失敗了。 SDET需要自問，我正在開發(fā)的測試自動化框架是否可重用，可維護，可配置，可理解和可擴展？

通常，無論何時要求我們從頭開始實施框架或適應(yīng)現(xiàn)有框架中的新要求（有時在很短的時間范圍內(nèi)），為了快速實施更改，我們都會忘記考慮最佳方案編碼慣例或最簡潔的編碼方法。我們會在沒有任何適當(dāng)文檔的情況下盡快進行更改。

結(jié)果，更改被合并到主分支，隨著框架的增長，這在其他團隊成員中也成為一種常見的實踐。當(dāng)需要擴展自動化框架以覆蓋更多的項目，需要添加更多的功能，或者從框架中使用的工具遷移到新工具時，它將成為整個團隊的巨額技術(shù)債務(wù)。這導(dǎo)致團隊不得不花費更多的時間來理解和調(diào)試代碼，并由于糟糕的設(shè)計和持久的反模式而進行更多的返工。

在開發(fā)自動化框架時，我們需要像對待其他任何應(yīng)用程序開發(fā)項目一樣對待它，并將其代碼編寫為生產(chǎn)代碼。

為了構(gòu)建一個可伸縮的測試自動化框架，我們需要記住這三個最重要的干凈的編碼實踐。

包括適當(dāng)?shù)奈臋n

在測試自動化框架開發(fā)項目中工作的程序員不太可能獨自編寫代碼。在一個由多人添加和更新自動化代碼的環(huán)境中，包括適當(dāng)?shù)奈臋n不僅可以幫助您組織自己的代碼，還可以幫助您的同事理解您的代碼實際上想要表達(dá)的內(nèi)容。稍后，如果您離開團隊，或者有人想要使用您的代碼添加功能，那么他們可以很容易地調(diào)試、更新、執(zhí)行單元測試和分析結(jié)果。

在我之前的一個項目中，我的同事收到了一個要求，要求將一個新的測試管理工具集成到一個已經(jīng)有另一個測試管理工具的測試自動化框架中。盡管新實現(xiàn)簡單而直接，但他花了大量時間來調(diào)試和理解如何將現(xiàn)有工具集成到框架中，這都是因為缺少注釋、文檔和一致的命名約定。

避免代碼重復(fù)

假設(shè)一個項目團隊要求您使用您的框架添加一個新功能，該功能將允許他們測試web服務(wù)并生成報告。在web服務(wù)編碼部分完成之后，現(xiàn)在您正在考慮編寫代碼來生成報告。但在此之前，您是否考慮過框架當(dāng)前的報告功能將能夠處理此需求的可能性?如果沒有，那么您就設(shè)置了代碼復(fù)制的情況。

隨著框架的增長，不必要的代碼重復(fù)將導(dǎo)致更多的返工，維護成本將開始增加。在一個地方修復(fù)報告生成代碼中的錯誤要比遍歷整個框架、調(diào)試和修改代碼要容易得多。

保持代碼簡單

編碼時，盡量不要使事情復(fù)雜化。使其盡可能簡單（易讀）！

我已經(jīng)觀察到，許多經(jīng)驗豐富的新手都喜歡在類或函數(shù)級別添加代碼。如果您要在功能級別上編寫三百行代碼，那么您可能正在穿越危險區(qū)域，在該區(qū)域中，代碼的易懂性和質(zhì)量開始崩潰。同樣，如果您的類由三十個方法組成，則可能不是出于單一目的，而是需要細(xì)分為較小的類，并且，如果需要，這些類需要分組在不同的程序包中。

我注意到許多程序員，無論是有經(jīng)驗的還是新手，都不斷地在類或函數(shù)級別上添加代碼，而沒有完全理解類或函數(shù)最初應(yīng)該傳達(dá)的信息。如果您在功能級別上編寫了300行代碼，那么您可能正在穿越危險區(qū)域，在該區(qū)域中，代碼的易懂性和質(zhì)量開始崩潰。同樣，如果您的類由三十個方法組成，則可能不是出于單一目的，而是需要細(xì)分為較小的類，并且，如果需要，這些類需要分組在不同的程序包中。

您的代碼應(yīng)嚴(yán)格遵守“ 單一職責(zé)原則” ，該原則規(guī)定，每個模塊，功能或類都應(yīng)對軟件功能的單個部分負(fù)責(zé)。稍后，如果您有測試特定功能的新要求，則將預(yù)先了解將受到影響的程序包，類，模塊和功能。

當(dāng)我成長為熱愛自動化的SDET時，我意識到，當(dāng)您在框架團隊中工作時，不僅要取用不同團隊的需求并使它們工作。我們還需要從一開始就考慮干凈的編碼原則。

最好檢查彼此的代碼，并確保在批準(zhǔn)和合并代碼之前遵循了最佳編程實踐。這樣，我們將為可擴展和可維護的健壯框架奠定基礎(chǔ)。

以上筆者的經(jīng)歷更像一張橫向的知識網(wǎng)，創(chuàng)建了一個交流平臺 914172719 ，群內(nèi)有各種技術(shù)同行交流、學(xué)習(xí)資料、面試經(jīng)驗等。其中用到j(luò)enkins、docker、moutebank、python編程等，還需要花更多的精力去深入學(xué)習(xí)，當(dāng)每項技能都能掌握到一定深度，才能稱為一個完整的知識體系。

最后： 可以關(guān)注公眾號：傷心的辣條！進去有許多資料共享！資料都是面試時面試官必問的知識點，也包括了很多測試行業(yè)常見知識，其中包括了有基礎(chǔ)知識、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續(xù)集成、測試架構(gòu)開發(fā)測試框架、性能測試、安全測試等。

如果我的博客對你有幫助、如果你喜歡我的博客內(nèi)容，請 “點贊” “評論” “收藏” 一鍵三連哦！