測驗人員多年來一直在與自動化測驗進行斗爭，但大多數團隊對他們當前的自動化測驗水平或維護它所需的開銷不滿，此外，在過去幾年中，軟體的架構，開發和使用方式也發生了翻天覆地的變化 - 增加了測驗的復雜性和軟體故障的業務影響，
鑒于軟體交付的復雜性和速度的增加，軟體測驗專業人??員如何幫助控制業務風險呢？
你需要的是 持續測驗，
什么是持續測驗？
持續測驗是一個程序，它將自動化測驗作為軟體交付通道中內嵌的一部分，以盡快獲得軟體發布后業務風險的反饋，
自動化測驗旨在生成一組與用戶故事或應用程式要求相關的通過/失敗的資料點，另一方面，持續測驗側重于業務風險，并提供有關軟體是否可以發布的判斷，要實作這一轉變，我們需要停止詢問“我們是否已完成測驗？”而是集中精力在“發布版本是否具有可接受的業務風險級別？”
為什么我們需要持續測驗？
今天，整個行業的變化要求測驗更多，同時使自動化測驗更難實作（至少使用傳統工具和方法）：
應用程式體系結構越來越分散和復雜，包含云，API，微服務等，并在單個業務事務中創建幾乎無限的不同協議和技術組合，
由于Agile，DevOps和持續交付，許多應用程式現在每兩周發布一次，每天發布數千次，因此，可用于測驗設計，維護和特別是執行的時間大大減少，
既然軟體是業務的主要介面，那么應用程式故障就是業務失敗 - 如果它影響用戶體驗，即使是看似微不足道的小故障也會產生嚴重后果，因此，與應用相關的風險已成為即使是非技術性商業領袖的主要關注點，
持續測驗與自動化測驗有何不同？
持續測驗和自動化測驗之間的主要區別可分為三大類：風險，廣度和時間，
風險
今天的企業不僅向最終用戶展示了他們的許多內部應用程式，他們還開發了大量額外的軟體，可以擴展和補充這些應用程式，例如，航空公司遠遠超出了飛機預訂系統，他們現在讓客戶計劃和預訂完整的假期，包括酒店，租車和游玩活動，向用戶展示越來越多的創新功能現在是競爭優勢 - 但它也增加了潛在故障點的數量，種類和復雜性，
大規模的“軟體失敗”產生了如此嚴重的業務影響，以至于與應用相關的風險現在成為企業公共財務報告的重要組成部分，鑒于[值得注意的軟體故障導致股票價格平均下跌-4.06％]（相當于平均25.5億美元的市值損失），企業領匯入正在注意并期望IT領導者采取行動并不奇怪，
如果您的測驗用例沒有考慮到業務風險，那么您的測驗結果將無法提供評估風險所需的洞察力，大多數測驗旨在提供有關用戶故事是否正確實作要求的低級詳細資訊，而不是高級別評估發布版本是否風險太高而無法發布，你會根據測驗結果立即停止發布嗎？如果沒有，您的測驗與業務風險不一致，
需要明確的是：我們并不是說低粒度測驗沒有價值; 我們要說的是，需要更多的措施來阻止高風險的版本失去控制，
廣度
即使一家企業設法避開大型軟體失敗成為頭條新聞，即使是看似微不足道的故障仍然可能會造成麻煩，如果用戶體驗的任何部分未能滿足他的期望，您不僅有可能將該客戶丟失給競爭對手 - 如果該用戶決定將他的問題帶到社交媒體上，您還可能面臨品牌損害風險，
只知道單元測驗失敗或通過UI測驗并不能告訴您最近的軟體更改是否會影響整體用戶體驗，為了保護最終用戶體驗，您需要足夠廣泛的測驗來檢測軟體更改何時無意中影響用戶所依賴的功能，
時間
現在，組織運送軟體的速度已成為競爭優勢，絕大多陣列織正在轉向敏捷和DevOps以加速其交付流程，
當自動化測驗出現時，它專注于測驗根據瀑布式開發程序構建和更新的內部系統，系統都在組織的控制之下，在測驗階段準備好開始之前，一切都已完成并準備好進行測驗，既然敏捷流程正在成為常態，那么測驗必須與開發并行開始; 否則，用戶故事不太可能在極度壓縮的迭代時間范圍內（通常是兩周）進行測驗并被視為“完成”，
如果您的組織已采用DevOps并且正在執行持續交付，則可能每小時或甚至更頻繁地發布軟體，在這種情況下，程序每個階段的反饋不能只是“快速”; 它必須幾乎是瞬間完成的，如果質量不是您軟體開發的首要考慮因素（例如，如果在生產中發現缺陷時進行回滾的影響很小），則在每個版本上運行一些快速單元測驗和冒煙測驗可能就足夠了，但是，如果企業希望最大限度地降低故障軟體到達最終用戶的風險，則需要一些方法來實作必要的風險覆寫水平和快速測驗，
對于測驗，有幾個重大影響：
測驗必須成為開發程序的一部分（而不是在開發完成時加上“保健”任務）
實作完相關功能后測驗必須馬上準備好運行
組織必須有辦法確定在交付管道的不同階段執行的正確測驗（簽入時的冒煙測驗，集成后的API /訊息層測驗，系統級別的端到端測驗，…）
每組測驗必須足夠快地執行，以免在軟體交付管道的相關階段產生瓶頸
需要一種穩定測驗環境的方法來防止頻繁更改導致大量誤報
持續測驗>測驗自動化
如果您只從本文中提出一個想法，我們希望它是這樣的：
自動化測驗≠連續測驗
持續測驗>自動化測驗
即使是使用傳統測驗自動化工具取得了相當成功的團隊，當他們的組織采用現代架構和交付方法時，也會遇到嚴重的障礙：
- 他們不能足夠快或足夠頻繁地創建和執行真實的測驗
- 持續的軟體更改會導致大量的誤報，并且需要看似永無止境的測驗維護量
- 他們無法提供關于發布版本是否風險太大而無法通過交付渠道的即時洞察
重要的是要認識到沒有任何工具或技術可以立即給你持續測驗，與Agile和DevOps一樣，持續測驗需要在整個人員，流程和技術方面進行變革，然而，當你的技術無法完成任務時，嘗試啟動人員和流程的相關變化，從一開始就是一場艱苦的戰斗…最侄訓失敗，
如果您的組織正在開始或擴展您的持續測驗自動化作業，我們建議您查看Forrester和Gartner的兩項新研究，這兩份報告都提供了對持續測驗和測驗自動化趨勢的深入了解，以及頂級持續測驗工具的比較，
CC先生說，持續**的名詞模式已經成為現在企業轉型的一個熱度詞匯，
不管是精益中提倡的 持續改善，還是Devops里提倡的CI（持續集成）- CD(持續部署) - CT（持續測驗）- CD（持續交付）
持續進化終歸是演進的一個大前提，
文末分享：這下面有我學習整理出來的自動化測驗資料、大廠面試…待你來領取~ 見公眾號：【傷心的辣條】愿你我都有所獲…
合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
我的測驗學習交流群：902061117 群里有技術大牛一起交流分享~
原文不易呀，眼睛都留眼淚了！麻煩伸出發財小手點個贊，感謝您的支持，你的點贊是我持續更新的動力，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/276153.html
標籤：其他