持續測試定義:14個關鍵點
1.持續測試的主要目標是評估業務風險範圍
2.持續測試提供了對發布候選版本進行交付管道是否風險太大的即時洞察
3.持續測試建立了一個安全網，幫助團隊在加速開發過程中保護用戶體驗，並避免出現軟件故障
4.持續測試希望測試嵌入到開發過程中，而不是附加到最後
5.持續測試無縫地集成到軟件交付管道中DevOps工具鏈
6.持續測試期望一個穩定的測試環境，其中有效的測試數據對於每個測試運行都是可用的
7.持續測試包含了從“左移”(單元、組件、覆蓋…)到“右移”(監控/ APM，生產中的測試)的所有內容。
8.持續測試包括在交付管道的正確階段執行正確的測試集——而不會造成瓶頸
9.持續測試提供適合於交付管道的每個階段的可操作的反饋
10.持續測試在交付管道的適當階段評估現代架構的每一層
11.連續測試包括端到端測試在所有相關的技術(前端和後端)上實際地評估最終用戶體驗
12.持續測試的測試必須足夠廣泛，以檢測應用程序更改何時會不經意地影響用戶已經開始依賴的功能
13.持續測試通過將健壯、靈活的現代測試框架置於脆弱的腳本之上來減少誤報
14.持續測試包括持續地審查和優化測試套件，以消除冗餘並最大化業務風險覆蓋範圍
持續測試就是改變
每個人都承認敏捷和DevOps都是關於改變開發人員/運維人員、過程和技術，以盡可能快地交付創新軟件。盡管有這些變化，有一件事還是保持不變:軟件測試過程。一個最近的研究報告稱70%的組織采用了敏捷，但隻有30%的組織采用了自動化測試。一個獨立研究發現雖然現在敏捷的采用率接近88%，但隻有26%的敏捷組織廣泛采用了測試自動化。
換句話說，測試過程仍然停留在過去，即使組織投入了大量的時間和精力來轉換他們的開發過程，以滿足今天和明天的業務需求。大多數遺留軟件測試工具和過程都不適合敏捷和DevOps所要求的持續測試類型，原因如下:
無法“左移”
測試通常要到每個sprint的後期才能實現——當UI和相關組件(如後端api)最終完成並可用於測試時。
緩慢的執行時間
執行測試是耗時的，所以在每個構建上運行完整的回歸測試套件是不現實的。這意味著團隊缺乏關於他們的更改是否會影響現有用戶體驗的即時反饋。
高維護
UI測試需要大量的返工，以跟上加速發布過程的頻繁變化。這導致了緩慢的、繁重的測試維護和/或導致測試自動化工作被放棄。
測試環境不穩定
測試環境不穩定(不可訪問的依賴關係、測試數據問題等)通常會導致超時、不完整的測試、假陽性和/或不準確的結果——阻止你交付敏捷和DevOps所要求的快速質量反饋。
企業持續測試:敏捷和DevOps的轉換測試
即使使用最極端的測試自動化，“測試一切”的方法也不是可行的——或者是必要的。如果您重新考慮您的自動化軟件測試方法，您可以通過比您今天可能執行的更少的測試來獲得發布候選版本的業務風險的全麵評估。
企業持續測試:敏捷和DevOps的轉換測試引入了一個持續測試策略，幫助企業加速和優先測試，以滿足快節奏的敏捷和DevOps計劃的需求。軟件測試一直以來都是速度和創新的敵人——這是一個緩慢而昂貴的過程，在交付有問題的商業價值的同時還會延遲發布。這種新策略幫助您更聰明地進行測試，因此測試提供了對業務最重要的內容的快速洞察
要了解如何做到這一點，可以閱讀Tricentis創始人沃爾夫岡·普拉茨(Wolfgang Platz)寫的這本132頁的書。
持續測試和測試自動化
行業研究表明，平均測試自動化水平多年來一直在20%左右徘徊。今天，整個行業的變化對測試的要求越來越高，同時他們使得測試自動化更難實現:
應用程序架構越來越分布式和複雜，包括雲、api、微服務等，並在單個業務事務中結合了幾乎無窮無盡的不同協議和技術組合。
由於敏捷、DevOps和持續交付，許多應用程序現在每兩周發布一次，每天發布數千次。因此，用於測試設計、維護，特別是執行的時間大大減少。
既然軟件是業務的主要接口，那麼應用程序失敗就是業務失敗——如果它影響到用戶體驗，即使是一個看似很小的故障也會產生嚴重的影響。因此，與應用程序相關的風險已經成為非技術業務領導人的主要關注點。
持續測試，持續集成，持續交付和開發
隨著軟件成為在所有市場中創造競爭優勢的關鍵，企業在交付軟件時不再享受選擇“速度”或“質量”的奢侈。都是至關重要的。現在，敏捷實踐已經成熟，DevOps計劃已經進入公司議程，持續集成(CI)、持續測試和持續交付(CD)已經成為實現快速質量的關鍵催化劑。在這三者中，持續測試是目前為止最具挑戰性的。
持續集成主要是一個工具驅動的活動，而持續交付是一個工具和團隊驅動的活動，持續測試涉及工具、團隊、個人和服務。
構建和集成代碼更改當然很重要。然而，如果自動化交付過程不能識別變更是如何影響業務風險或破壞最終用戶體驗的，那麼持續集成和持續交付的頻率和速度的增加可能會成為一種負債而不是資產。
如果執行正確，持續測試作為敏捷下遊流程的核心——執行自動化測試作為軟件交付管道的一部分，以盡可能快地提供基於風險的反饋。由於現代應用程序交付的複雜性和速度的增加，掌握持續測試對於控製業務風險是至關重要的。
超越人工智能的連續測試
我們已經經曆了相當長的旅程到達持續測試。然而，當我們展望未來時，很明顯，即使是持續測試也不夠。我們正在快速地接近這樣一個時刻:持續測試將無法跟上縮短的交付周期時間、增加的技術複雜性和加速的變更速度。
在這個軟件將實時處理數量難以想象的數據點的時代，為了確保質量，我們需要所有我們能得到的幫助——例如，象征性地駕駛物聯網和真正地駕駛“自動駕駛”汽車。除了持續測試之外，我們還需要“數字測試”來實現進一步的加速，並滿足由物聯網、機器人和量子計算驅動的未來的質量需求。人工智能，模仿智能人類行為的機器學習和預測分析，可以幫助我們實現這一目標。
連續測試資源
Wolfgang Platz談企業持續測試
持續測試成熟度評估
區分成功和落後DevOps的5個核心測試實踐
播客:Wolfgang Platz關於企業持續測試
持續測試，左移，以及測試自動化
博客:Wolfgang Platz關於企業持續測試
戰勝企業持續測試的3個挑戰
持續性能測試的實用指南
Forrester Research: DevOps +敏捷領導者與落後者的區別是什麼?
下一個什麼?
獲取Tricentis如何通過基於風險的測試、基於模型的測試自動化、服務虛擬化、測試數據管理等方式幫助軟件測試人員采用和推進持續測試的詳細信息。
使用Tricentis進行持續測試
