持續測試跟自動化測試的這些區別你知道嗎？

測試人員多年來一直在與自動化測試進行鬥爭，但大多數團隊對他們當前的自動化測試水平或維護它所需的開銷不滿。此外，在過去幾年中，軟體的架構，開發和使用方式也發生了翻天覆地的變化 - 增加了測試的複雜性和軟體故障的業務影響。

鑑於軟體交付的複雜性和速度的增加，軟體測試專業人員如何幫助控制業務風險呢？你需要的是 持續測試 。

什麼是持續測試？

持續測試是一個過程，它將自動化測試作為軟體交付通道中內嵌的一部分，以儘快獲得軟體釋出後業務風險的反饋。

自動化測試旨在生成一組與使用者故事或應用程式要求相關的透過/失敗的資料點。另一方面，持續測試側重於業務風險，並提供有關軟體是否可以釋出的判斷。要實現這一轉變，我們需要停止詢問“我們是否已完成測試？”而是集中精力在“釋出版本是否具有可接受的業務風險級別？”

為什麼我們需要持續測試？

今天，整個行業的變化要求測試更多，同時使自動化測試更難實現（至少使用傳統工具和方法）：

• 應用程式體系結構越來越分散和複雜，包含雲，API，微服務等，並在單個業務事務中建立幾乎無限的不同協議和技術組合。

• 由於Agile，DevOps和持續交付，許多應用程式現在每兩週釋出一次，每天釋出數千次。因此，可用於測試設計，維護和特別是執行的時間大大減少。

• 既然軟體是業務的主要介面，那麼應用程式故障就是業務失敗 - 如果它影響使用者體驗，即使是看似微不足道的小故障也會產生嚴重後果。因此，與應用相關的風險已成為即使是非技術性商業領袖的主要關注點。

持續測試與自動化測試有何不同？

持續測試和自動化測試之間的主要區別可分為三大類：風險，廣度和時間。

風險

今天的企業不僅向終端使用者展示了他們的許多內部應用程式，他們還開發了大量額外的軟體，可以擴充套件和補充這些應用程式。例如，航空公司遠遠超出了飛機預訂系統。他們現在讓客戶計劃和預訂完整的假期，包括酒店，租車和遊玩活動。向使用者展示越來越多的創新功能現在是競爭優勢 - 但它也增加了潛在故障點的數量，種類和複雜性。

大規模的“軟體失敗”產生了如此嚴重的業務影響，以至於與應用相關的風險現在成為企業公共財務報告的重要組成部分。鑑於[值得注意的軟體故障導致股票價格平均下跌-4.06％]（相當於平均25.5億美元的市值損失），企業領導人正在注意並期望IT領導者採取行動並不奇怪。

如果您的測試用例沒有考慮到業務風險，那麼您的測試結果將無法提供評估風險所需的洞察力。大多數測試旨在提供有關使用者故事是否正確實現要求的低階詳細資訊，而不是高階別評估釋出版本是否風險太高而無法釋出。你會根據測試結果立即停止釋出嗎？如果沒有，您的測試與業務風險不一致。

需要明確的是：我們並不是說低粒度測試沒有價值; 我們要說的是，需要更多的措施來阻止高風險的版本失去控制。

跟大家推薦一個學習資料分享群：903217991，裡面大牛已經為我們整理好了許多的學習資料，有自動化，介面，效能等等的學習資料！人生是一個逆水行舟的過程，不進則退，我們們一起加油吧！

廣度

即使一家企業設法避開大型軟體失敗成為頭條新聞，即使是看似微不足道的故障仍然可能會造成麻煩。如果使用者體驗的任何部分未能滿足他的期望，您不僅有可能將該客戶丟失給競爭對手 - 如果該使用者決定將他的問題帶到社交媒體上，您還可能面臨品牌損害風險。

只知道單元測試失敗或透過UI測試並不能告訴您最近的軟體更改是否會影響整體使用者體驗。為了保護終端使用者體驗，您需要足夠廣泛的測試來檢測軟體更改何時無意中影響使用者所依賴的功能。

時間

現在，組織運送軟體的速度已成為競爭優勢，絕大多陣列織正在轉向敏捷和DevOps以加速其交付流程。

當自動化測試出現時，它專注於測試根據瀑布式開發過程構建和更新的內部系統。系統都在組織的控制之下，在測試階段準備好開始之前，一切都已完成並準備好進行測試。既然敏捷流程正在成為常態，那麼測試必須與開發並行開始; 否則，使用者故事不太可能在極度壓縮的迭代時間範圍內（通常是兩週）進行測試並被視為“完成”。

如果您的組織已採用DevOps並且正在執行持續交付，則可能每小時或甚至更頻繁地釋出軟體。在這種情況下，過程每個階段的反饋不能只是“快速”; 它必須幾乎是瞬間完成的。如果質量不是您軟體開發的首要考慮因素（例如，如果在生產中發現缺陷時進行回滾的影響很小），則在每個版本上執行一些快速單元測試和冒煙測試可能就足夠了。但是，如果企業希望最大限度地降低故障軟體到達終端使用者的風險，則需要一些方法來實現必要的風險覆蓋水平和快速測試。

對於測試，有幾個重大影響：

• 測試必須成為開發過程的一部分（而不是在開發完成時加上“保健”任務）

• 實現完相關功能後測試必須馬上準備好執行

• 組織必須有辦法確定在交付管道的不同階段執行的正確測試（簽入時的冒煙測試，整合後的API /訊息層測試，系統級別的端到端測試，......）

• 每組測試必須足夠快地執行，以免在軟體交付管道的相關階段產生瓶頸

• 需要一種穩定測試環境的方法來防止頻繁更改導致大量誤報

持續測試>測試自動化

如果您只從本文中提出一個想法，我們希望它是這樣的：

自動化測試≠連續測試

持續測試>自動化測試

即使是使用傳統測試自動化工具取得了相當成功的團隊，當他們的組織採用現代架構和交付方法時，也會遇到嚴重的障礙：

• 他們不能足夠快或足夠頻繁地建立和執行真實的測試

• 持續的軟體更改會導致大量的誤報，並且需要看似永無止境的測試維護量

• 他們無法提供關於釋出版本是否風險太大而無法透過交付渠道的即時洞察

重要的是要認識到沒有任何工具或技術可以立即給你持續測試。與Agile和DevOps一樣，持續測試需要在整個人員，流程和技術方面進行變革。然而，當你的技術無法完成任務時，嘗試啟動人員和流程的相關變化，從一開始就是一場艱苦的戰鬥......最終會失敗。

如果您的組織正在開始或擴充套件您的持續測試自動化工作，我們建議您檢視 和 兩項新研究。這兩份報告都提供了對持續測試和測試自動化趨勢的深入瞭解，以及頂級持續測試工具的比較。

CC先生說，持續**的名詞模式已經成為現在企業轉型的一個熱度詞彙。

不管是精益中提倡的 持續改善，還是Devops裡提倡的CI（持續整合）-CD(持續部署) -CT（持續測試）-CD（持續交付）

持續進化終歸是演進的一個大前提。