自動化測試為項目帶來了非凡的價值。并行測試執行更進一步。

功能測試是確保向客戶交付高質量系統的關鍵步驟。功能測試側重于業務價值與技術正確性，確保系統解決基本的客戶問題。不幸的是，它通常被視為過于耗時和痛苦。就其本質而言，功能測試是一項比大多數開發人員級別的測試（例如單元、集成或系統/API 測試）更復雜的任務。

自動化功能測試可以為項目帶來非凡的價值。通過使團隊能夠持續測試其軟件中關鍵、有價值的方面，轉向并行執行使該價值更進一步。

什么是功能測試？

功能測試確保系統解決客戶在各種對話和文檔中提出的需求。功能測試，也稱為驗收測試，從其他類型的測試中脫穎而出，因為它更多地關注業務問題而不是技術方面。

溝通

從根本上說，所有測試都是關于有效的溝通。功能測試尤其如此，因為它的性質是檢查系統的形式并滿足客戶/用戶的需求。而且，功能測試的基礎更多地在于業務領域而不是技術領域。這使得有效溝通的需求變得更加重要。

盡早明確預期至關重要，這意味著功能測試需要盡早開始——如果可能的話，好在產品/系統構思階段進行。盡早開始功能測試可確保明確的期望，并且還可以調整系統開發以好地滿足客戶和用戶的真正需求。

準備功能測試

如上所述，良好的功能測試幾乎在項目的初始階段就開始了。

明確你在測試什么

首先，團隊需要明確的系統功能驗收標準。對于大多數場景，這些需要表達為用戶任務，而不是深入的技術陳述。少考慮“訂單摘要頁面應在預期系統負載下在不到兩秒內返回”，多考慮“缺貨的訂單將在庫存管理消息隊列中創建一個摘要通知消息。該摘要消息將包括該商品的庫存編號以及無法完成的客戶訂單鏈接?！?/span>

有所有正確的依賴項

功能測試將需要一個盡可能接近生產的環境：與完整數據、外部系統等的集成。測試顯然應該在系統開發過程中進行，但最終的功能測試將需要訪問所有適用的依賴項. 然而，“盡可能接近生產”并不意味著完整的硬件。請記住，功能測試（通常?。┡c性能測試不同。因此，團隊應該更關注集成而不是硬件。

謹慎管理您的數據

良好的功能測試數據至關重要，這也是在您的階段早期開始功能測試的另一個原因。您的系統可能依賴上游系統為您創建或轉換數據。在復雜環境中確定數據是一個耗時且高度迭代的過程。您不想在計劃進行功能測試之前幾天就開始這樣做！

準備好您的測試工具

大多數團隊至少會尋求自動化高價值、高風險的功能測試場景。這意味著您需要讓您的團隊準備好使用 Selenium、API 框架、部署工具集、數據管理工具等。您是否擁有合適的基礎設施，不僅可以運行您的系統，還可以運行測試反對那個制度？如果您正在運行并行測試，您將需要某種形式的網格或群來運行您的測試代理。您還需要所有相關的管理基礎設施來處理這些測試的執行，更不用說報告要求了。

設定成功方向

不幸的是，測試自動化一直是一個被嚴重誤解的領域。它經常被視為減少回歸和發布測試所需時間的靈丹妙藥。更糟糕的是，太多組織不了解自動化功能測試是一項軟件工程工作，需要與開發系統軟件所用的許多相同的技能和學科。成功的自動化意味著從一開始就進行規劃，并了解如何處理自動化測試。

什么自動化

永遠不應該從“我們將自動化所有手動測試！”的心態來處理功能自動化。這是對時間的不良利用，并且幾乎沒有實際價值。

相反，良好的功能自動化側重于高風險、高價值的業務用例。顯然，自動化應該只關注重復的場景。檢查網頁上第三方控件的成功集成對于自動化通常沒有意義——快速的探索性測試可以確認控件已正確連接、正確接收和顯示數據等。自動化該測試沒有意義，因為第三方控件不在團隊的開發之下，也沒有任何關于它在頁面上的綁定更改的內容。

測試自動化代碼是生產代碼

對測試代碼給予與生產代碼同樣的關注和關注非常重要——因為它是生產代碼。

創建精心設計、可維護的自動化測試腳本對于任何項目的長期成功都至關重要。這意味著您的團隊中至少需要一些了解軟件工藝原則并可以幫助指導和指導其他人編寫自動化的人。您的團隊將需要了解頁面對象模式、抽象、不要重復自己 (DRY) 和其他工藝原則等概念。

編寫好的自動化測試

一旦你明確了哪些測試需要自動化，就花點時間清楚地說明你將如何編寫這些測試。良好的測試結構將有助于在項目的整個生命周期中保持這些測試的準確性、可維護性和高價值。

一次測試一件事

好的測試只執行一項功能，它們不會將多個功能或工作流程混為一談。一個特定的功能/工作流程可能是一個復雜的測試，需要對多個項目進行多次檢查；但是，您仍在評估一項特定操作的結果。

例如，讓我們看一個工資系統，該系統根據員工的時薪和工作小時數計算其每周工資。（為簡單起見，我們將不考慮稅收、福利、預扣稅等的復雜性。）需要考慮加班時間，以及有關工時和費率的業務規則。還需要檢查無效的輸入。測試值和預期結果表可能如下所示：

標準時間

隨著時間的推移

業務規則限制

無效輸入

人們可以輕松地編寫一個測試來檢查所有這些輸入；然而，這最終會變得過于復雜，并且在出現故障時更難以理解發生了什么。

保持測試相互獨立

很容易看出在測試之間共享狀態（數據、環境等）的吸引力：設置一次，然后使用相同的數據輕松運行一堆測試。不幸的是，歷史表明這實際上是一種可怕的做法。

由于時間原因，在測試之間共享狀態會定期注入細微的錯誤，尤其是在并行運行測試時。一個測試可能正在編輯另一個正在執行的測試所依賴的數據集中的值——而第二個測試由于意外的、不清楚的原因而失敗。當一個測試刪除另一個測試的先決條件時，經常會出現更明顯的問題……

請注意，基線數據集是一個獨立的問題。創建諸如零件目錄之類的東西以用作背景數據非常有意義。將新零件添加到目錄中的測試應該為該新零件隨機創建數據，而不是重新使用模板。

設置處理數據設置和供應的定制框架要好得多。通過這種方式，可以輕松快速創建一個測試，該測試可以快速清晰地創建特定于該測試的復雜環境。例如，檢查汽車零件訂單的測試可以使用類似于以下偽代碼的設置步驟。

` // 使用自定義框架/API 測試設置客戶 ID =框架。CreateRandomTestCustomer ( ) ;FirstPartId =框架。CreateRandomTestPart ( ) ;SecondPartId =框架。CreateRandomTestPart ( ) ;

這種設置風格讓您在系統中創建先決條件，并留下您可以在 UI 中使用的數據，例如作為測試客戶登錄并通過他們的 ID 向訂單添加部件。