Tricentis客戶工程總監Paul Bruce
我們想要什麼？性能反饋！我們什麼時候要？這取決於。
反饋循環變得越來越關鍵，您交付軟件的速度越快。有效地實施自動化方法以進行反饋循環是關於右擬合WHO/WHAT/WHER/sher WHER/WHERES方麵的。通常，自動反饋循環生活在管道和CI中。但是性能測試呢？適合DevOps和自動化環境不是太複雜了嗎？
簡短的答案當然不是。但這需要一些工程思考，並首先設定正確的目標。績效工程師為什麼需要以管道為導向的性能反饋？一些可靠的原因：
- 在產品早期和功能生命周期的早期解決明顯的故障通常是便宜的。
- 長周期引入延遲和上下文切換，這增加了故障的可能性。
- 自動反饋要求我們將不必要的差異從流程中推出。
- 有反饋有助於我們逐步做出更明智的決策。
- 經常生成性能數據使我們能夠隨著時間的推移了解趨勢，而不僅僅是“大爆炸”點樣本。
傳統的負載測試和性能測試集中在完全烘焙預發行係統的大型，複雜的端到端測試上。大多數自動化的構建和包裝周期需要幾分鍾，而不是數小時，因此從時間的角度來看，傳統的性能測試周期不太適合交付周期。端到端測試仍然需要嗎？是的。這個過程是否有必要繼承我們可以先前解決的缺陷，錯誤，反訴訟和不良假設？絕對不。
一種智能方法需要“右貼合”負載和性能測試到自動化管道中，以便我們獲得可操作的早期信號（即反饋循環）。從工程師的角度來看，為了避免端到端的晚期驗證一團糟，我們需要將性能驗證過程分解為有意義的較小的反饋循環，以適合較短的工作周期。這樣，開發人員和團隊就可以收到有關他們更早的變化的性能反饋，因此到我們測試端到端時，它不是垃圾箱的火災。
3個現代化負載和性能測試的挑戰
- 並非所有的係統和組件都是平等創建的，因此，沒有一種方法全麵采用。早期與晚期測試的適應性和候選資格需要討論；選擇正確的目標並采用漸進測試策略。
- 您做某事的頻率越多，“棘手的”總和到一定數量的勞動（除非自動化）。具體而言，用於負載測試，基礎架構的手動預配置，數據和環境通常需要很多時間。
- 如果我們隻做一些不經常做的事情，那比定期做更多的努力。片狀環境，脆弱的測試腳本，離同步數據。。。因為我們不連續行使它們，所以我們解決這類問題的能力並沒有改善。
適當的性能測試工具帶包括許多繼承這些挑戰的實踐：負載測試（即模擬現實條件），監視，模擬/虛擬化，測試數據管理/消毒，經驗抽樣等。我與之合作的大多數企業都在借助Delphix，Mockiato，Mockiato，Mockiato，Mockiato，Off Apply自動化這些組件中進行了部分或完全自動化。Tricentis Neoload，Grafana和Selenium。好消息是，在自動化它們時，任何一種方法都沒有任何無法克服的。具有紮實的願景和一種方法可以保持一致並組織我們的努力。
自動連續性能和負載測試
可以很容易地說，測試自動化的目標是“更快”或“加速交付”。當它可靠地工作並產生可行的結果時，這適用於其，但是“可靠”和“可行”不僅需要負載測試工具。就像DevOps“人，過程，技術” Venn圖。如果您僅解決問題的這些方麵之一，那麼您並不能真正解決整個問題。那麼，我們如何為持續負載和性能測試涉及的“人”和“流程”元素解決？
輸入自動化。使我們的流程自動化使我們麵臨挑戰，以使機器可以代表我們執行的方式表達我們的目標，需求和活動。它闡明了我們的過程，技術和技能中的空白。。。但這是一件好事。我們需要了解我們的空白，以正確解決它們。
為了自動化產生有意義的可行成果的績效測試，人們需要就目標和結果進行交流。討論SLA，SLO和SLIS的前麵是“左轉”性能實踐的重要組成部分。應該有某種性能標準的進氣過程。這可能是一種簡單的東西，例如對性能測試應針對的係統和時間表的調查表和問卷。目的是幫助生產基線自動化工件，例如SLA定義和API測試細節。
當您將這些工件合並到管道中（即我們的“流程”）時，您還必須自動化負載基礎架構提供/剝奪過程，以便您可以與正在測試的係統（SUTS）合適地運行與已正確隔離的負載測試。如今，集裝箱和Kubernetes為提供基於標準的基礎架構的方法已經有了很大的幫助，但是總會有其他一百萬個其他方法來管理這些資源。無論您采用哪種供應策略，團隊進行測試都不是複雜的。必要時獲得反饋的自治是加速交付的關鍵組成部分。
如果您的表現慣例沒有自動化，您將進行縮放。
最後，自動化不僅應該為一個團隊服務。當它隻是本地效率時（對於表演COE團隊），在大型組織中沒有力量 - 殺手。相反，許多團隊都可以使用的自動化，即使不是設置它的專家，也可以幫助組織更快地進行。
在DevOps中，性能和可靠性工程的工作不僅是運行測試或分析/合並結果；它為產品團隊提供了一種自行完成這些事情的方式，同時還提供了圍繞這些過程的安全護欄和“良好實踐”，以便團隊可以隨著時間的推移提高自己的績效能力。
我看到許多成熟的大規模性能實踐已經從“績效團隊作為孤立的服務”心態轉變為“自助服務的績效過程”。原因之一是，通過添加更多的全職機構，無法將“人”績效專業知識擴展到數百個團隊。但主要是因為我們現在可以將我們的性能測試實踐（即自動化）正式化到工作中，以幫助機器幫助繁重。
在許多方麵，使您的負載測試實踐適當地自動化“帶來痛苦的前進”，並使組織願望加速加速交付。我們需要重新考慮它們，繼承其有用的智慧，並適應當今的限製和挑戰，而不是反身方法，而是要重新考慮它們，繼承了它們的有用智慧。
我們從這裏去哪裏？
盡早進行性能測試，並且通常在較小的卷中是建立“右擬合”自動性能反饋循環到管道中的關鍵。開始針對API的小規模，以建立信心和能力。
實用的操作方法指南，為成功過渡到自動連續測試方法的基礎，包括優先考慮自動化功能的策略，開發專用績效管道的最佳實踐，克服測試基礎架構障礙以及確保值得信賴的GO/No-GO Discisions- 在此詳細介紹連續性能測試的實用指南。