建立測驗自動化策略【譯】

通過測驗自動化，可以學到了很多東西，并已在經驗豐富的敏捷教練的幫助下開始制定策略，測驗策略應針對該專案制定，讓我們逐步執定義下一個專案策略的步驟，

確定目標

當我開始我的職業生涯時，測驗自動化并沒有太多想象力，我們也面臨著許多您可能遇到的測驗自動化挑戰，如果今天問我同樣的問題，情況已經發生了巨大變化，這主要歸功于可靠工具的可用性，但是，這并不意味著我們會自動執行所有操作，成功的企業測驗自動化策略的第一步是定義我們的目標并確定要自動化的測驗，

任何測驗自動化的決定因素與特定測驗可以重復多少次有關，可以自動執行的測驗的最佳示例是經常運行的測驗，它是一項平凡的任務，非常耗時，并且需要大量資料才能執行規定的任務，這是可以自動化的潛在測驗用例的串列：

• 自動執行高度重復的任務，例如登錄，
• 具有高風隙訓失敗概率或高風險的任務
• 需要在多個瀏覽器/設備/作業系統/環境/硬體/配置上進行測驗的任務
• 測驗具有清晰的通過/失敗結果
• 自動化需要通過多個資料集進行操作的測驗
• 自動執行允許多個選項的練習，例如，接受不同組合的表單提交
• 如果手動完成，則需要大量時間進行測驗；例如，我們進行了一項測驗，每次運行新任務時都需要登錄，
• 最后，絕對應該自動執行需要檢查穩定功能的測驗，

ScienceSoft的軟體測驗總監Andrei Mikhailau和他的團隊應用測驗自動化來減少驗證新功能或修復，提高回歸測驗覆寫率并消除人為錯誤的時間，當手動測驗效率低下或無法進行手動測驗（例如為了測驗性能）時，他們還會應用自動測驗，

但是，他們在測驗自動化中的最大挑戰在于如何快速，頻繁地進行UI布局和功能更改，即使是最小的修改，也可能需要重寫大量測驗，減少這種不便的方法之一是確保最大程度地重用測驗代碼，建議在此處創建標準的高級特定于應用程式的庫，

測驗自動化的成功要求專案開始時的精心計劃，完成定義測驗自動化的目標和范圍后，下一步就是尋找不同的測驗方法，

確定測驗方法

我在測驗方面的總體經驗教會了我一件事：除了他們如何設想測驗自動化以及他們如何計劃在開發團隊之外進行協作之外，任何組織的總體測驗文化都受到現行測驗方法的極大影響，這意味著需要對當前流程進行回顧，最終確定新的測驗方法，并確定團隊成員的測驗級別，角色和職責，

但是首先，讓我們決定在自動化時可以提供最大價值的測驗方法，不同的測驗級別可以采用不同的測驗方法，

單元測驗

單元測驗是任何敏捷測驗自動化策略的基礎，該策略可以為團隊提供最高的ROI，該測驗使用了開發人員可以撰寫，執行和維護的一小段代碼（函式或方法），

同樣，每個單元都應單獨測驗，單元測驗將提供細粒度的可觀察性，這對開發人員來說很重要，但對產品所有者卻很有用，建議在本地和內部版本中運行這些測驗，

回歸測驗

回歸測驗被定義為一種軟體測驗型別，以確認最近的程式或代碼更改未對現有功能造成不利影響， 從這個定義來看，很明顯，這樣的測驗型別應該集中在通過預定義的計劃、觸發器或按需執行的全部或部分測驗場景中，

如果根據最佳實踐正確開發了回歸測驗并涵蓋了足夠的功能區域，則它們帶來的價值就很高，并且這種測驗模型能夠發現回歸錯誤，代碼更改的副作用或其他意外的問題，

集成測驗

集成測驗在軟體測驗型別中排名靠前，這是因為它對任何一支優秀的DevOps團隊而言至關重要，

通常，集成測驗是在單元測驗之后進行的，以確保所有單元相互協調運行，通常，一個單元將被視為具有獨立功能，但在與其他單元互動時可能會引起問題，這就是軟體測驗如此重要的原因，尤其是作為一個整體的測驗單元，同樣，大多數軟體專案都有多個開發人員為不同的模塊和單元撰寫代碼，因此，集成測驗確定不同開發人員正在撰寫的軟體是否能夠按照計劃的那樣作業，

端到端測驗

端到端的目標是驗證系統與功能流程的集成，因此在測驗任何應用程式時，必須注意用戶界面或表示層不是唯一要關注的領域，但應用程式行為背后的基礎資料、流程和邏輯也需要進行驗證，連接的系統和集成在前端、后端、功能和集成方面均同等重要，

此處省略888字介紹各種測驗方法，

選擇測驗自動化框架

測驗自動化框架是在撰寫和運行測驗時需要遵循的一組詳細準則，例如，編碼標準，程序，測驗資料報告等，這是六個測驗自動化框架的串列，您可以從中選擇：

線性腳本-記錄和播放

線性腳本是最方便的框架之一，錄制后，可以在其余時間重放它，它允許測驗人員按順序記錄步驟，例如，導航，輸入等，

優點：

• 不需要編碼專業知識
• 更快地生成測驗腳本
• 保持順序，因此任何人都易于理解

缺點：

• 無法使用多個資料集重新運行測驗用例
• 無法擴展專案范圍
• 返工將需要更改應用程式

圖書館架構測驗框架

圖書館架構的作業原理是確定和劃分，這意味著該框架可以輕松識別常見任務并將其相應地分組，該框架將這些相似的功能保存到庫中，并在測驗腳本需要時隨時使用，

優點：

• 保持高水平的模塊化
• 經濟高效且可擴展
• 易于運行多個測驗腳本

缺點：

• 由于資料是硬編碼的，因此需要更改腳本
• 需要技術門檻較高
• 模塊化的測驗框架

顧名思義，該框架將應用程式劃分為多個單獨的單元，并進行隔離的測驗，為每個零件創建一個單獨的測驗腳本，然后將其合并為合并的測驗，

優點：

• 模塊化更改不會影響整個應用程式
• 測驗腳本是可重用的
• 減少創建測驗腳本的作業量和時間

缺點：

• 不能使用多個資料集
• 設定需要技術門檻高

資料驅動的測驗框架

它克服了基于線性或模塊化框架的故障，它不對資料進行硬編碼，但允許從外部檔案（如Excel，CSV等）存盤和訪問它，它允許測驗人員使用不同的資料集測驗同一功能，

優點：

• 可以使用多個資料集進行測驗
• 更少的腳本
• 模塊中將來的更改將不會影響整個應用程式

缺點：

• 框架設定很耗時
  需要專家來設計實施框架
• • 資料格式不能太復雜

關鍵字驅動的測驗框架

關鍵字用于表示在GUI上執行的操作，例如，諸如“單擊鏈接以進行驗證”或“單擊登錄按鈕”之類的短語，它在外部存盤關鍵字，并用于測驗應用程式的GUI，這些關鍵字與測驗邏輯分開，并且通過遵循一組指令對操作進行無縫測驗，

優點：

• 可以使用獨立的AUT測驗腳本
• 使用一個關鍵字表示多個測驗腳本
• 代碼是可重用的

缺點：

• 設定成本高
• 耗時，因為需要設定物件存盤庫
• 需要具有出色自動化技能的質量檢查工程師

確認工具

選擇正確的自動化工具的第一步是了解應用程式所基于的技術以及被測應用程式（AUT）的測驗要求，選擇正確的自動化工具的主要方面之一是與AUT的技術堆疊的兼容性，很少有工具能夠同時滿足大多數測驗人員的需求和使用習慣，該工具必須支持測驗人員最喜歡的編程語言和測驗環境，對于移動應用程式，如果同時針對iOS和Android，則選擇同時支持Selenium和Appium的平臺，

第二步是檢查該工具在支持的平臺和易用性之間是否具有適當的平衡，越來越多的平臺要求測驗各種平臺上的應用程式部署，必須注意，即使在平臺的單個變體中，也需要支持各種版本，例如，如果桌面應用程式聲稱可以在Windows上運行，則它必須在Windows 7、10（32位和64位）上運行，等等，同樣，Android和iOS的不同版本也可以支持移動應用程式，一旦撰寫了測驗腳本，自動化工具就必須在所有平臺上對應用程式進行測驗，并且對組態檔的更改最少，測驗自動化工具必須具備的功能是，通過最大程度地使用測驗腳本來支持所有必需平臺的跨平臺測驗，

第三方面是找到一種基于流行度的工具，受歡迎程度證明該工具具有可用的支持，質量檔案和技術論壇，這可以幫助找到相關的測驗工程師來執行和維護測驗工具，例如，如果我們考慮進行Web應用程式自動化測驗，則與Sahi相比，Selenium受歡迎并且被廣泛使用，

要考慮的第四個方面是該工具的許可成本，但是，這并不像比較入圍產品的定價那樣簡單，需要選擇在成本和滿足測驗要求之間具有適當平衡的工具，首先，可以選擇兩種工具：開源和商業工具，開源工具是一個有吸引力的選擇，但是，商業工具提供了更好的支持和學習資源，但是，在選擇開放源代碼工具時，購買許可協議之前，需要仔細評估許可協議，因為它們都有各自的警告，以我的經驗，到目前為止，在免費的開源工具上構建自定義測驗自動化框架效果最好，最大的優勢是控制，可以靈活封裝以滿足團隊個性化自動化測驗需求，

創建并運行測驗

創建完測驗自動化策略并選擇了正確的工具后，就可以撰寫和執行腳本了，我們一次又一次地觀察到，使自動化測驗成為手動測驗人員的兼職作業會降低團隊士氣和生產率，

這是我們的建議：選擇專門的自動化測驗團隊，外包軟體測驗服務可能是一個不錯的選擇，

當開始撰寫測驗用例時，建議遵循最佳實踐，以下是我們在作業中中嚴格遵循的一些建議，

• 撰寫測驗用例模板，使它們可以在多個專案中重復使用，在撰寫任何新的測驗用例之前，我們確保檢查是否已經撰寫了類似的測驗用例，這有助于我們減少冗余，
• 通常，設計測驗用例的人不是執行它的人，這鼓勵我們以簡潔易懂的方式撰寫測驗用例，
• 隨著時間的流逝，我們已經學會了根據所涉及的功能或組件確定每個測驗用例的優先級，這樣做有助于我們確保首先執行高優先級案件，

維護腳本

維護測驗腳本涉及仔細檢查測驗引數，例如，當產品具有豐富的功能時，實施回歸測驗可能會花費更多時間，并且未充分利用測驗自動化的重要性，對于這種情況，維護測驗用例起著至關重要的作用，應該對測驗用例進行優化和分類，以評估測驗用例的子集并明確定義測驗自動化的目的，

根據與敏捷教練和QA專業人士合作的經驗，我始終被建議保持專注于保持回歸測驗的有效性，這可以通過定期清除較舊的測驗用例并對其進行分類來實作，您應該清楚自己的要求以及舊的測驗用例是否可以有效保留，測驗腳本應盡可能少，并且結果更多，如果您可以制作較小的測驗用例，則自動化將變得更加容易，

除非觸發自動化，否則自動化不會自動完成所有操作，必須通過根據需要設計測驗用例來使其適合真實的測驗場景，因為它與您的產品交付和ROI直接相關，請您的質量檢查分析師處理測驗用例的子集，以節省大量時間，

• 測驗用例越精簡，軟體就可以更快地投入生產，

撰寫測驗用例時，不要追求曲折的目標，保持簡潔，在自動化方面，請繼續縮小測驗用例的范圍，隨著時間的流逝，在實作測驗自動化的同時，我們已經意識到，要想成功，自動化就必須成為每個人的作業，我們努力改變業務分析師和測驗人員協作的方式以及創建和運行測驗的方式，

通過在測驗程序中實作自動化，我們可以花更多的時間進行計劃，更快地檢測更多缺陷并更好地滿足專案需求，

最后： 可以關注公眾號：傷心的辣條 ！ 進去有許多資料共享！資料都是面試時面試官必問的知識點，也包括了很多測驗行業常見知識，其中包括了有基礎知識、Linux必備、Shell、互聯網程式原理、Mysql資料庫、抓包工具專題、介面測驗工具、測驗進階-Python編程、Web自動化測驗、APP自動化測驗、介面自動化測驗、測驗高級持續集成、測驗架構開發測驗框架、性能測驗、安全測驗等，

如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連哦！推薦軟體測驗交流學習群：914172719 里面會分享一些資深架構師錄制的視頻錄像

好文推薦

轉行面試，跳槽面試，軟體測驗人員都必須知道的這幾種面試技巧！

面試經：一線城市搬磚！又面軟體測驗崗，5000就知足了…

面試官：作業三年，還來面初級測驗？恐怕你的軟體測驗工程師的頭銜要加雙引號…

什么樣的人適合從事軟體測驗作業？

那個準點下班的人，比我先升職了…

測驗崗反復跳槽，跳著跳著就跳沒了…