24/7 全天候執行測試

隨時開始測試以在雲中執行 - 無論您位於世界何處。當蘋果和谷歌釋出新的瀏覽器版本時，升級雲伺服器並無縫啟動測試。不再讓測試人員消失在會議室裡，然後在三四天內出來，宣稱“可能沒問題”。

可重用性

一旦測試指令碼存在，只需按一下按鈕，就可以在不同的外形和裝置上重新執行它。就此而言，如果您將測試組裝為元件或構建塊，則可以在其他測試中重用這些元件。這意味著只寫登入一次，然後重複使用它。當您的應用程式為“客戶型別”（個人或企業）新增新的下拉選單時，您可以在一個地方更改登入功能，然後突然所有測試再次通過。人工測試指令碼越詳細，它們要麼過時，要麼需要昂貴的維護工作才能保持最新狀態。

獲取視訊

過去，通過自動化執行意味著軟體可以執行至少一個特定場景。計算機在意識到更改使螢幕“看起來很有趣”或造成可用性問題方面非常糟糕。在最壞的情況下，整個表單域可能會被隱藏或鎖定以防止接收擊鍵，但自動化仍然可以找到一種輸入方式。在這些情況下，通過測試甚至不能保證可以通過場景！

現代測試自動化工具不僅可以播放失敗的視訊，甚至可以播放通過的測試執行。以 2 倍或更快的速度檢視這些逐個遊戲，可以結合人的力量來發現問題與計算機一遍又一遍地做完全相同的事情的能力。擁有故障視訊可以將除錯時間從幾小時縮短到幾秒鐘。

體積和規模

一旦您建立了一個可以在 iOS 平臺上執行的測試，您就可以從數千種裝置、作業系統和瀏覽器的組合中擴充套件它。

同時性

雲，加上測試的可重複性，意味著您可以同時在多個平臺上執行完全相同的測試，尋找細微的差異。這可以提供對程式設計實踐甚至效能的洞察。考慮一下與最新版本相比，在舊 iPhone 上測試執行的已知時間以及平均頁面響應的差異。

儘早發現錯誤

很有可能同時工作的兩個開發人員引入破壞軟體的更改——或者引入破壞軟體的合併問題。這嚴重壞了；“無法登入”壞了。人類測試人員在引入問題幾個小時後發現問題，並被告知“不應該發生”，或者等待新的構建。下一個工作日，測試人員就失敗與開發人員聯絡，他們說它“在開發環境中有效”，或者可能會拖累操作。終於在第四天，問題解決了。

如果你的經歷比這更好，那麼你比大多數人更幸運。或者，也許，中斷登入很少見，但在測試中發現問題很常見，或者至少是更改的意外後果。

在每個構建上執行迴歸測試套件可以及早發現問題，確定導致問題的更改，並將問題直接指向建立它的開發人員。這可以防止浪費、延遲、相互指責，並大大減少除錯和修復所花費的時間。

隱藏的儲蓄

大多數領導人類測試的團隊都有一個“迴歸測試”，或“釋出前的最終檢查”測試周期。這個週期很貴；可能需要一週時間。測試周期長，很難經常出貨。多年來，我曾兩次與團隊合作，將月度釋出轉變為季度釋出，以此作為“流程改進”的一種形式。

轉向不那麼頻繁的釋出允許團隊花費更少的時間來編寫新程式碼。但是，迴歸時間的變化量會更大，這將需要更多的迴歸測試周期來發布。這些更多的週期使測試看起來更昂貴，從而導致減少發貨的壓力。從經濟角度來說，這是一個惡性迴圈。

工具可以徹底改變這些數字。結合軟體工程中的現代策略，例如多個部署點、彈性和快速恢復時間，團隊可以建立一個良性迴圈，其中更頻繁的部署會導致部署的更改更少，所需的測試更少，並更快地為客戶創造價值。

生產監控

一旦存在“只讀”測試指令碼，您就可以翻轉它並使用它來監控生產。新增更改，您可以找出功能何時出現故障，或者是否在幾秒鐘內錯誤地應用了配置標誌。新增時間以獲得生產的效能監控——真正的、端到端的、實際客戶體驗的效能監控——大約是一個繁忙的午餐時間的成本。同樣，當頁面載入超過合理閾值時新增警報以立即查詢和修復問題。

隨著應用程式的老化，它往往會增加邏輯和資料庫大小，並且效能會隨著時間的推移而下降。新增時間以注意到效能差異並不需要太多。這意味著您甚至可以在客戶出現問題之前識別出趨向於出現問題效能的功能！

將應用程式置於負載之下

同樣，從模擬使用者的獨立測試的測試套件開始。然後大規模同時執行它們以深入瞭解效能。這裡的見解有兩個方面。首先，您可以檢視您為上面的生產監控編寫的效能計數器。或者，讓人類在類似負載下的生產環境中探索功能。

投資回報

如果團隊在每個 sprint 中新增新程式碼，那麼每個 sprint 中測試“覆蓋”的“空間”都會增加。使用自動化工具，這項工作相對簡單：編寫一個故事，編寫一些測試。通過人工測試，覆蓋的空間量呈線性增長。在第一個衝刺中，測試 10 個故事，在第二個衝刺中，測試 20 個，在第三個衝刺中，測試 30 個。測試要麼需要變得更加先進，隨機抽樣，否則測試時間需要增加。

做得好，測試工具會隨著時間的推移降低測試成本。

[作者注：是的，這是一個需要大量細微差別的複雜討論，但沒關係，我確實編輯了有關該主題的書。]

可悲的是，任何事情通常都有缺點，包括測試風格。

自動化測試的侷限性

最好的工具採用使用者可能做的一些小子集——最頻繁或最重要的操作——並將它們制度化，一遍又一遍地執行，完全相同。試圖涵蓋所有可能的用途和組合是愚蠢的差事。這為小錯誤留下了足夠的空間，也為讓客戶感到煩惱的事情留下了空間。請記住，計算機正在測試是否符合規範；規範總是有可能是錯誤的，或者是過時的。大多數公司使用自動化測試來發現簡單、頻繁、核心操作中的錯誤，例如登入應用程式、建立新帳戶或在忘記密碼時傳送電子郵件。這就是自動化測試所做的。

特定場景下的 App 崩潰仍需手動測試。眾所周知，機器非常先進，但“真正的”人工智慧的應用有限且昂貴，至少目前如此。

自動化測試不會做的另一件事是測試設計的有效可用性，例如按鈕的位置，以及實際使用應用程式的難易程度。這仍然必須通過手動使用者友好測試來完成。

總之，自動化和手動測試各有利弊。有些人會爭辯說這種區分是有幫助的，因為大量的手工工作是由計算機輔助的。澤眾軟體認為，由計算機進行的獨立測試執行和評估與人類坐在駕駛座時不同，應該區別對待。這篇文章的目的是為了展示。

為了獲得最佳結果，您需要結合使用這兩種型別：針對重複、簡單用例的自動化測試；以及用於重現特定錯誤、複雜用例並確保最佳使用者體驗的手動測試。