對於手動測試專案，成本消耗因素為：

• 人

• 工具–測試/缺陷管理

• 基礎設施–環境

• 時間

• 訓練

對於自動化專案，除上述專案外，還需要支出以下費用：

• 自動化工具

• 用於測試管理工具整合的載入項

• 支援AUT的載入項（如SAP，Oracle等）

• 框架設定

• 特定於工具的培訓

在這種情況下，自動化專案的成功與否取決於編寫程式碼的程度，編寫的可重用元件的數量或達到預期結果的程式碼行數？

沒有。

決定成功的因素是一個，也是唯一的一個問題：“與手動方式相比，您是否能夠產生更好的ROI（投資回報率）”？–如果不是立即，最終。

如果該問題的答案為“否”，則說明您對自動化專案的計劃不正確。

通常，測試計劃包含以下部分。我們將討論其中每一個，重點關注自動化的特定方面：

自動化測試測試計劃部分

第1節：範圍

• 選擇要在多個週期之間逐步迴歸的測試用例/場景。

• 有時，最簡單的測試用例需要大量複雜的解決方案才能自動化。如果這些只是一次使用，顯然是沒有意義的。可重用性應該是您的重點。

• 自動化測試不會/不能執行探索性測試。

第2部分：測試策略

• 本部分在自動化世界中稱為“框架”。有些框架建立起來非常具有挑戰性，而且也很有效，但是它們要求時間，精力和能力。始終尋找中間立場，並在不損害資源過度利用的情況下盡力而為。

• 確定要使用的最佳實踐編碼，命名約定，要儲存的測試資產的位置，測試結果的格式等，以保持一致性並提高生產率。

第3節：資源/角色和職責

• 朝這個方向邁出的第一步是瞭解團隊的能力，並提前預測圖中所展示的自動化範圍。這將有助於選擇適合自動化和手動測試需求的團隊。另外，請選擇態度正確的人-那些認為手動測試不在其地位之下的人。

• 選擇一個精通AUT，測試管理，缺陷管理和其他SDLC活動的團隊

• 第1節：範圍

第4節：工具

根據以下規則選擇自動化工具：

• 公司是否已經擁有某種工具的許可證，請嘗試看看是否可以使用它

• 尋找開源（但可靠）的工具

• 團隊成員是否已經知道該工具，或者我們需要引進新人嗎？還是訓練現有的？

第5節：時間

• 包括時間進行程式碼演練和檢查自動化指令碼

• 及時維護指令碼。如果建立的程式碼段在接下來的6個月左右將不使用，請確保定期維護該程式碼段，以減少失敗的機會。

第6節：環境

• AUT將要執行的目標環境和要使用的自動化工具應該相容。這是應考慮對該工具進行預許可的因素之一。

• 此外，分析其他可用的管理工具和您嘗試引入的自動化工具是否可以相互連線以獲得額外的好處。

第7節：可交付成果

• 您的測試指令碼就是您的可交付成果。但是，並不是每個人都精通自動化/程式語言。因此，計劃建立一個“操作方法”文件，該文件將幫助當前使用者和將來的團隊成員即使您不在時也能夠理解此指令碼。

• 在指令碼中也包含註釋。

第8節：風險

如果要提出自動化解決方案，請確保選擇具有成本效益的工具和解決方案，以確保自動化工作不會給專案造成負擔。

重要的是要設定一個期望，即自動化專案的ROI不能立即為正，而是可以長期清晰地看到。

因此，如果您建議自動化系統，請選擇

• 穩定且不需要太多維護

• 具有龐大的迴歸套件的範圍

• 沒有太多的手動干預或不依賴於人類的直覺

第9節：測試資料

• 考慮資料的安全性

• 不要將任何測試資料硬編碼到指令碼中。這隻會導致指令碼維護過多，並可能在修改過程中引發錯誤。

• 要非常具體。對於手動測試步驟-“輸入名字”，您可以說輸入任意5個字元的名稱。在測試期間，測試人員可以鍵入“ Swati”或“ Seela”或其他任何內容。但是對於工具而言，它不能做這樣的假設。因此，提供準確的值。

第10節：報告/結果

• 指令碼執行結果也是技術性的，其他團隊可能不容易理解。計劃將詳細結果寫到記事本或Excel工作表中，以作為其他措施。

• 還需要詳細的框架文件，審查結果，缺陷報告，執行狀態報告。

作為自動化愛好者，我們可能會認為客戶/管理人員不容易購買自動化建議。

但是，當我們的最終目標是通過自動化最大化投資回報率時，我們也與管理層/客戶的目標完全一致。這將確保我們不僅能夠使我們的專案自動化，而且能夠在很多人的同意，合作與興奮下做到這一點。

歡迎將文章分享到朋友圈
如需轉載，請在後臺回覆“轉載”獲取授權

你點的每個贊，我都認真當成了喜歡