沃爾夫岡·普拉茨最近受邀在SKILUp Day:持續測試這是我們的朋友在DevOps研究所．在這次非正式的討論中，Wolfgang探討了持續測試的關鍵元素，以及持續測試的角色/實踐是如何演變的。
這個事件已經過去了，但你可以在這裏看到沃爾夫岡的演講:
注意:你現在可以訪問沃爾夫岡的書，企業持續測試在Tricentis網站或亞馬遜上。
以下是從他的演講中得到的一些關鍵信息:
為了提高測試的效率，擁有正確的測試用例比優化自動化更重要。
進行測試主要有兩個原因:1)查找錯誤2)確保應用程序是正確的。探索性測試是發現錯誤的最佳方法。基於規範的測試是確保應用程序正確的最佳方法。
在指定的內容和開發人員實際實現的內容之間通常存在差距。探索性測試是隻有在已實現但未指定的功能中發現問題的方法。基於規範的測試是隻有在指定但未實現的功能中發現問題的方法。探索性測試通常是在指定和實現的功能中發現錯誤的最佳方法。
大多數測試報告(報告通過的、失敗的、未執行的測試的數量)不能給您足夠的信息來做出明智的發布決策。僅僅知道10%的測試失敗並沒有幫助。測試失敗可能是微不足道的，也可能是令人掃興的。還需要進一步調查。
為了快速、準確地評估與發布相關的風險，我們在測試中需要一種新的貨幣:業務風險覆蓋。如果您真正了解您的最大風險所在，並且您有策略地創建測試來覆蓋這些風險，那麼您實際上可以用大約20%的努力覆蓋大約80%的風險。
根據直覺，大多數測試人員達到的風險覆蓋率不超過~50%。測試用例設計幫助您創建測試，以達到您組織的業務風險覆蓋率的目標級別(例如，90-95%)。此外，變更影響分析告訴您需要運行哪些測試，以便有信心地測試每個變更和發布。
在企業開始測試自動化之旅之前，他們通常有一些單元測試、一些集成測試和係統集成測試，以及大量的端到端測試。端到端測試通常是手動執行的，成本非常高(執行速度慢以及發現和修複錯誤的延遲)。這需要被扭轉。
敏捷測試金字塔完全顛倒了。它應該有一個堅實的單元測試基礎，一些集成和係統集成測試，以及非常小的端到端測試集。您希望在這裏盡可能地實現自動化，但是許多端到端測試、一些係統集成測試和一小部分集成測試仍然應該是手動的。
除了單元測試之外，一定要考慮兩種自動化:UI和API。如果您需要測試的功能是通過API公開的，那麼盡量在該級別進行大部分測試。API測試可以在sprint的早期開始，因為您不必等待UI的實現。另外，API測試在各個方麵都更快:創建更快、運行更快、維護/更新更快……
AI/ML的最新發展消除了許多傳統上困擾UI測試自動化的挑戰(特別是自動化UI測試太遲、太脆弱)。使用Tricentis Vision AI等技術，您甚至可以在UI存在之前就開始構建UI測試自動化。應用程序背後是什麼技術並不重要。如果您能看到它，您就可以用高彈性測試自動化它。有了這個變化，UI測試自動化將會得到擴展——切割成手動測試和API測試。它甚至可能成為我們看到的未來自動化的主要形式。