連續性能測試是完全有意義的。您無力擁有一項新功能，更新或錯誤修複，為您帶來了兩步，向前三步。新功能必須完美無缺，並且不會破壞用戶依賴的先前的功能。
不幸的是，當不同的團隊以不同的速度發展不同的組件（建立在許多不同的體係結構上）時，打破某些東西太容易了。但是用戶和利益相關者不在乎提供好的軟件很難。現在，軟件故障是業務失敗，任何類型的問題都會影響運營效率，客戶/員工滿意度，收入和競爭優勢。
連續測試…部分
大多數組織通過將基本測試集成到CI/CD管道中，在暴露最明顯的功能問題方麵做得非常好。他們依靠“煙霧測試”來檢查該應用程序是否會在交付管道中進行崩潰並燃燒。這包括單位測試，以及一組選定的功能測試，這些功能測試從最終用戶的角度逐步介紹了絕對關鍵的用例。煙霧測試通常是通過一係列更廣泛的測試來補充的，這使得核心功能仍然會產生預期結果。這些“理智測試”在每個構建中都不可用，但是通常可以在一夜之間運行。
通過連續煙霧測試和定期理智測試的組合，如果功能從根本上破裂，通常會得到足夠的警告。但是績效問題呢？為什麼不檢查它們呢？畢竟，如果用戶因延遲而感到沮喪並在完成過程之前離開申請，那麼該過程是否真的沒關係可能有最終產生了正確的結果。它沒有……因為用戶從來沒有走那麼遠。
但是，盡管功能測試已被廣泛接受為CI/CD工藝的核心部分，但性能測試往往會落後。這是一項後期的活動 - 自從瀑布發展周期以來已經過去了多年。從質量的角度來看，這沒有任何意義。功能正確性和性能特征（例如可伸縮性，響應性和可用性）都是生命體征。這就像不斷監視ICU醫院患者的脈搏，但每周僅檢查一次呼吸率。
為什麼我們在一個測試領域取得的進展不給另一個領域進行？
性能測試和功能測試根本不同
問題的根源是功能測試和性能測試根本不同。即使您想測試煙霧測試涵蓋的相同核心用例，也通常需要創建並維護完全不同的性能測試測試集。這些測試以完全不同的方式編寫，使用不同的工具（通常是由不同的人）以截然不同的方式訪問應用程序。
基於UI的煙霧測試像人類一樣鍛煉應用程序，模擬與屏幕上的控件的相互作用。從用戶角度來看，這是100％。可以使用UI測試工具創建這些測試，從而可以非常直觀地創建測試自動化。但是，通常通過通過網絡層訪問應用程序來執行性能測試。該過程不太直觀。此外，網絡層極為波動，這種波動性意味著性能測試幾乎需要對每次測試進行的注意和調整。
僅開發專門用於性能測試的單獨測試並不容易。但是，使它們與不斷發展的應用保持同步是無休止的瑣事。大多數團隊都在努力尋找保持一係列功能測試所需的時間和資源。保持績效測試最新甚至更困難。它們比UI測試更加不穩定，UI測試對於不穩定性而言是臭名昭著的。由於您在技術協議層而不是直觀的UI層“在引擎蓋下工作”，因此它們也更加繁瑣。這就是為什麼績效測試通常是專門的績效測試工程師的領域，他們經常用作共享服務。大多數坐在跨職能的敏捷團隊之外，並且不容易用於常規性能測試維護。
在每個衝刺結束時，對核心性能測試腳本進行了更新，對於絕大多數團隊來說，已經是一個伸展運動。實際上使它們更新印刷品執行？那很少發生。
一個測試定義，無限的可能性
但請想象一下，如果您的績效測試可以實現什麼沒有落後於遠。
開發人員檢查增量更改，然後運行功能測試。如果該測試成功，您可以假設兩件事。第一，相應的應用程序功能適用於單個用戶的預期。第二，該功能測試已得到適當維護。這意味著它可以在負載下進行性能測試，如果隻能將功能測試重複用於性能測試。
然後執行相應的性能測試。團隊立即知道最新變化是否對功能方麵的用戶體驗產生負麵影響或者表現。他們不需要等待數周甚至數月才能使績效測試工程師提醒他們，其中數百或數千個變化引起了績效問題。他們不必浪費各種時間來追捕問題的根源，並試圖揭開引入問題的幾天，幾周甚至幾個月的時間。而且，他們可以立即阻止該構建沿交付管道進行。
好吧，好消息。對於Neoload的產品，這是完全可行的。Neoload是由Neolys創建的，我很高興歡迎產品以及公司加入Tricentis家族。Neoload隻需單擊即可進行功能測試，並將其“翻轉”為性能測試。其中包括使用硒，Tricentis Tosca和其他功能測試工具構建的測試。這意味著您不需要維護兩套單獨的測試來進行性能測試和功能測試。隻需保持最新功能測試，您就可以完全需要。無需其他測試或維護。而且，隨著所有時間和精力的節省，CI/CD中的性能測試突然變得可行。
通過這種方法，績效專家可以免除創建基本的績效測試。取而代之的是，他們可以專注於檢查發現的任何問題並完成更先進的性能工程，以創建複雜的工作量模型，對應用程序進行調整，等等。
從現有的功能測試中進行性能測試是相當多的增值。就像一個親密的朋友訪問他的祖國時，這很像是標記。您不必擔心額外的計劃和準備。您甚至不需要學習新語言。您可以從騎車中受益。