自動化測試的最佳實踐

banq發表於2019-03-21

無論您是否已決定轉向自動化測試,或者您仍在考慮進行自動化測試,瞭解實現轉換的最佳實踐以及哪種策略最適合您的組織非常重要。任何複雜性的每個應用程式都可能有自己的測試要求組合,沒有兩個開發團隊完全相同。
在本文中,我們將討論規劃測試自動化策略的最佳實踐,並提出確定哪種策略最適合您的應用程式和團隊的方法。

讓我們從最基本的問題開始:什麼是自動化測試,什麼使它變得重要?

管理重複
手動軟體測試是重複的。事實上,它是與軟體開發或使用相關的最重複且最耗時的任務型別之一。對於大多數型別的軟體,只有手動資料輸入需要更多時間或更多重複 - 大規模,大容量資料輸入通常是首先要實現自動化的任務之一。
當然,自動化測試並不像自動化資料輸入那麼簡單,但基本原理是相同的:識別重複操作,建立一個框架,允許以高效率執行這些操作,然後自動化兩者重複和低重複動作,以便手動干預完全消除或減少到最低限度。

一切指令碼化
對於測試,大部分重複包括在不同平臺(作業系統,瀏覽器,移動裝置等)和不同條件(壓力,負載,資源可用性等)上執行相同的基本測試操作。測試也可以重複多次,以捕獲逐漸發展或暫時的問題。
自動化測試系統由指令碼驅動,具有自動測試資料輸入和自動記錄結果。指令碼可用於控制每個測試的重複次數,並應用測試過程和資料收集的變體以適應不同的平臺和條件。

虛擬化
在大多數情況下,自動化測試也是虛擬化測試。通常,除非您需要專門測試應用程式與硬體平臺的互動,否則您可以在虛擬機器上執行大部分或全部測試。
在虛擬機器上進行測試可以更加輕鬆地自動化測試系統設定以及輸入和輸出,並且可以節省等待基於硬體的測試系統可用的時間。它還加快了測試過程,通常是一到兩個數量級。這樣可以縮短整體測試時間,並允許您包含難以適應手動測試計劃的測試型別。

要求和基礎設施
在對自動化測試設計和基礎設施做出任何基本選擇之前,瞭解可用的內容以及一流自動化測試機制所需的內容非常重要。

指令碼和框架
不用說,自動化測試是指令碼驅動的。測試指令碼可以用通用程式語言編寫,也可以用域特定的測試指令碼語言編寫。測試指令碼語言通常是自動化測試框架的一部分(例如Appium或Selenium,兩者都是開源的)。此類框架通常包括測試基礎結構的主要元素以及它們自己的API。它們還可以允許您記錄測試步驟,然後使用內建指令碼語言對其進行編輯,從而簡化構建測試指令碼庫的過程。

基於雲的測試
使用虛擬機器進行測試時,它們通常不需要在本地(除非特定的安全性或配置要求使內部部署測試成為必需)。基於雲的虛擬測試系統也可以完成這項工作,透過在雲中進行測試,您可以避免有限的本地資源所帶來的限制。

測試平臺
一個好的基於雲的測試平臺通常會提供全面的服務基礎架構,用於在雲中部署和測試虛擬機器,以及分析,儀表板,安全性以及將這些服務與現有專案管理基礎架構整合所需的所有API。
此外,基於雲的測試服務(如Sauce Labs)實際上可以讓您更輕鬆地自動化關鍵移動平臺或其他裝置的硬體測試。透過實際裝置雲測試,您可以使用基於雲的測試基礎架構在由測試服務維護的一組真實裝置上執行自動化測試。

最終,您整合的測試自動化策略應該是最適合您的組織和產品線的策略。為此,您的計劃流程應包括以下要素:

包括正確的人
讓關鍵的利益相關者參與進來,至少達到他們有發言權的程度,即使不是最終的決策權。對於測試,這將包括您的測試人員,開發人員,設計人員以及服務檯人員。開發人員和測試人員需要積極參與流程,所有利益相關方都應提供意見(例如,未滿足的測試需求),並保持最新狀態。
問問自己和關鍵利益相關者以下問題:

你想測試什麼?
如果您沒有遇到基於物理或計劃的約束,您會測試什麼?您的測試優先順序是什麼?您希望測試哪些功能區域,以及您希望測試哪些潛在的效能問題?您希望在測試製度中包含哪些平臺和哪些條件組合?您預留哪些型別的測試是不切實際的,因為沒有足夠的時間或裝置來包含它們?
此時,不要擔心在自動測試環境中哪些測試可能或可能不實用。現在,您需要做的就是根據機會編譯您想要測試的事項列表。

你有什麼可測試?
您目前的測試製度實際上包含哪些內容?您正在測試什麼,以及您設計了哪些測試,但是由於缺乏資源而推遲,或者在“有時間”的情況下進行“執行”列表?你收集什麼測試結果,你用它們做什麼?
然後,再問兩個問題:鑑於您的手動測試製度的限制,您是否普遍滿意它以正確的方式測試正確的東西?您是否對當前測試的設計 - 各個步驟和整個測試過程感到滿意?

考慮設計
如果這兩個問題的答案是“是”,那麼您可能能夠使用當前測試製度的核心要素(測試要求和個別步驟,如果不是整體程式)作為設計大部分的基礎。你的自動化制度。如果您對目前的大多數或所有測試方案都不滿意,那麼最好從頭開始設計自動化測試方案。
然而,在任何一種情況下,您的自動化制度設計可能(並且在許多方面應該)至少基於您在當前測試實踐中編譯的“願望清單”的關鍵元素。
內部還是外部?您希望在內部處理自動化測試製度的哪些元素,以及您希望使用哪些元素來處理外部服務或資源?

  • 您的開發人員應該編寫測試指令碼嗎?或者相反,您的QA團隊能否處理指令碼和自動化工程?如果您使用有限域測試指令碼語言並從記錄測試開始,這些任務可能會更容易學習。
  • 在本地或雲中管理虛擬機器和自動化測試框架會更容易,更實用嗎?在許多方面,這個問題的答案取決於規模。如果合適,您可以從一個小的本地自動化測試機制開始,可以選擇稍後遷移到雲。
  • 您想使用基於雲的測試平臺嗎?這將減輕您的內部員工管理測試自動化基礎架構的任務。如上所述,這種型別的服務對於管理大量測試以及在虛擬和真實裝置上進行自動測試也非常有用。
  • 將所有測試外包給第三方測試服務更好嗎?這樣做可以釋放內部員工和資源,用於非測試任務。然而,它可能涉及顯著的前期成本,並且對測試過程提供較少的控制。

這些問題都涉及測試需求,可用人員和資源,預算和時間之間的權衡。您團隊的最佳答案取決於組織內的條件。
在規劃測試自動化策略時,這可能是最重要的。最基本的最佳實踐是清楚地瞭解您的測試需求,資源和約束,以及可用的資源和服務,並根據這種理解採取行動。

相關文章