容易做的事情更容易讓人們接受並成為他們過程的一部分。顯然. . . .但是在所有DevOps工具和技術的背景下思考一下這個問題。如果你讓做正確的事情變得容易(例如，提供模板，良好的實踐指導，以及有信息的過程護欄，就像許多SREs為產品團隊所做的那樣)，而讓做錯誤的事情變得困難，那麼你很可能會比期望那些已經太忙而不能一夜之間成為性能專家的人更好地提高軟件質量。
尤其是像這樣的話題性能測試，“越簡單越好”不僅適用於測試腳本，也適用於自動化過程和基礎設施需求，以及使用測試結果。許多Tricentis NeoLoad客戶現在為他們的產品團隊提供“自助服務”資源和培訓，以便將性能思維模式擴展到一小群主題專家(sme)之外。然後，這些中小企業能夠將他們的專業知識應用到PI規劃、過程自動化和比其他人需要更多幫助的DevOps團隊中。
現代格言是:早、常、和容易
績效反饋循環是現代持續交付實踐的關鍵步驟。簡而言之，後期的性能修複成本太高，對任何人都沒有好處，需要在開發周期的早期準備好一些元素，以便獲得性能反饋。自動化是關鍵，但確定架構的哪些領域需要“左移”性能測試也是關鍵。
優先級是“早而勤”這句話經常忽略的核心。這就是為什麼我傾向於在列表中加入“容易”來提醒我們，如果我們選擇了一條包含高阻力的道路，我們很可能會失敗。這裏的“簡單”並不一定是指最不複雜的路徑;我指的是項目管理意義上的容易，即唾手可得的果實或對企業主來說顯而易見的東西——換句話說，“容易達成一致，容易看到其重要性。”在關鍵路徑上的性能測試係統比那些遠離別人認為重要的服務要容易得多。
優先考慮,然後係統化
每一個注重性能的工程師都應該讀的一本書是係統性能:企業和雲在這本書中，他提供了有用的心智模型，例如Utilization-Saturation——錯誤(使用)進行係統分析。如果我們采用這種方法來幫助我們優先考慮被測試的係統(SuT)，為其自動化性能反饋循環，它將看起來像這樣:
- 利用哪些核心api或微服務位於許多其他業務流程的連接處，從而將它們作為共享的企業架構組件使用?
- 飽和哪些服務經曆過“溢出”——需要額外的虛擬機/成本來橫向擴展——或不斷引發SEV-n事件，需要“所有人都參與進來”才能恢複到合理的運行狀態?
- 錯誤從“流程錯誤”的角度來看，有多少次特定的服務更新或補丁被長周期的性能審查所耽擱?我們需要快速部署哪些係統，或者緩慢的反饋周期會導致產品團隊推遲交付期限(即時的或計劃的)?
通常，在一個或多個這些向量中排名靠前的例子包括用戶/消費者身份驗證、購物車結帳、索賠處理等。
查看係統性能的其他方法，例如rate-error-duration(紅色)在分析平台中發出信號並觀察業務指標，確保關鍵路徑和產生收益的用戶體驗如預期的那樣運行。
高效地對性能工作進行優先級排序的組織會從生產前和生產中係統中查看這些和其他信號，以確定在哪裏應用更多的努力。現在每個人都有某種形式的微服務體係結構與傳統的單片和共享係統一起使用，但不是每個人都意識到以優先級和係統化的方式獨立測試和監視子係統和分布式組件的好處。
簡單的腳本:為什麼api“更簡單”……比什麼更簡單?
現代api通常使用HTTP和JSON等標準來發送和接收數據。通常，API團隊也有一個由API規範描述的REST API清單，例如OpenAPI、Swagger或WSDL文檔。此外，測試數據通常更容易注入，因為有效負載通常是自描述的(例如，示例中的字段名和數據匹配格式)。最後，擁有api的組織通常有功能測試資產，例如Postman或REST Assured測試套件，它們為構建性能測試腳本提供了參考點。
處理API端點和有效負載通常比處理端到端web應用程序的完整流量捕獲要簡單得多，後者通常包括動態腳本、靜態內容、“前端”API調用和其他客戶端標記化語義。規範文檔中描述的API端點使得編寫腳本和回放測試比以往任何時候都要簡單得多，使它們成為早期測試的“容易”目標。服務描述符還使模擬api比整個web服務器更容易進行端到端應用程序測試……隻要看看Mockiato您可以舉出一些例子，說明如何不需要天才或富人就可以進行服務虛擬化。
在NeoLoad中，可以導入OpenAPI和WSDL描述符來快速創建負載測試路徑，可以使用動態數據、文本驗證和sla進一步定製負載測試路徑。NeoLoad還支持yaml定義的測試細節，這進一步簡化了“容易”的負載測試套件生成。一旦定義了測試，就可以作為CI編排或管道的一部分執行測試，在早期開發周期中產生作為“反饋”信息的測試結果和SLA指標。
簡單的管道:超越測試腳本，進入“編碼過程”
現在一切都是代碼。應用程序和服務都是代碼。測試代碼。基礎設施就是代碼(IaC)。網絡代碼。安全代碼。甚至遵從性也是代碼。而且，是的，大部分(如果不是全部的話)這些過程也可以表示為代碼。為什麼會發生這種情況?
代碼可由機器執行。它代表了你想要發生的事情，不管你是否按下按鈕去做。它可以被安排、觸發和重放。存儲庫中的代碼代表透明度，不管是開源還是閉源。那些能夠閱讀代碼的人可以理解它在做什麼，當它不工作時，可能會看到原因。代碼可以版本化、前滾、審計和修改。
測試資產、測試基礎設施和測試過程，當表示為代碼時，繼承所有這些關聯。大多數編碼領域已經統一了Git(以一種或另一種形式)，作為所有代碼資產的默認版本管理協議。這使得性能測試工具(如NeoLoad、Keptn)和其他成千上萬的技術能夠在一個被認可和理解的控製係統中維護它們的工件。
許多Tricentis客戶不僅將他們的測試套件存儲在Git中，而且還將他們的“性能管道”腳本存儲在與他們的負載測試項目相同的回購中。為什麼?因為對測試腳本、測試語義和測試數據源的更改通常都斷言將其作為代碼(又稱管道腳本)合並到其流程的語義中。這些更改可以在一個獨立於團隊已經批準和使用的主/主分支的分支中完成，然後該分支可以作為管道運行，並被證明是有效的，以便提升回主/主幹。就像測試用例的提升一樣，測試過程的提升對於保持交付過程的平穩和按時運行是至關重要的。
“性能管道”通常也是與更廣泛的交付管道分離的、可觸發的過程。為什麼?當運行性能測試失敗時，不必重新運行構建、打包和部署斷言步驟;相反，操作配置和部署調整通常足以實現最優性能。在完成這些更改之後，簡單地重新運行性能測試管道是一項簡單的任務。
簡單的設施
對於那些需要可靠的、統計上顯著的係統或組件性能反饋的人來說，負載測試是一個“大石頭”。它是您正在測試的基礎設施，即被測試的係統(SuT)，必須與用於向SuT施加壓力的基礎設施分離。對於短而微小的本地性能檢查，使用單個計算資源是很好的。
對於更大更長的測試，您必須跨多個計算資源分解工作。這就是我們所說的“負載生成器”。當您有多個計算資源時，您需要一個測試協調器，這就是我們所說的“控製器”。這與CI係統及其構建節點的概念相同，隻是為了在壓力下提供不受SuT計算資源影響的性能數據。
在管道中，將構建節點的角色與加載生成軟件的角色合並在一起是一個非常糟糕的想法，特別是因為如果該資源因加載而受到壓力，它將停止向CI主程序可靠地報告構建狀態。大多數構建節點隻是用於Maven、Python、Sonar和各種cli等工具。一個不可靠的代理是一個糟糕的參與者，特別是在大量運行這些彼此獨立的測試時。沒有人喜歡不可靠或失敗的構建。
另一種方法是將管道的工作節點留給執行語義，而從獨立的係統動態地請求加載基礎設施。早期的行業嚐試為管道代碼提供“側車”構建容器，但最終在容器網絡編排和資源爭用的複雜性下失敗了。盡管如此，一些NeoLoad客戶早在Jenkins 2中就在管道中采用了性能測試。x將使用AWS或GCP等雲CLI工具來進行配置調用，等待獲取，使用資源運行負載測試，然後將它們旋轉。這需要大量的工作，最終會使您的管道代碼變得龐大。
特別是當許多組織現在為他們的CI流程使用雲提供商時，NeoLoad Web Runtime支持通過OpenShift和Kubernetes提供商自動提供這些資源。通過將這些始終在線的資源附加到NeoLoad Web Resource“區域”，仍然可以支持傳統的靜態基礎設施，但如果可能的話，大多數客戶更喜歡通過彈性計算(如AWS EKS Fargate)和其他與kubernetes兼容的容器配置平台提供按需測試基礎設施。如果您不想考慮基礎設施，那麼總有用於基於saas的負載生成器的NeoLoad雲平台。
從性能管道語義抽象負載基礎設施極大地提高了我們的客戶為跨大型組織的許多產品團隊提供自服務性能反饋模型的能力。此外，它使您的管道更加簡潔，易於理解，並在必要時快速調整。
容易去/不方便
我們使所有這些事情變得容易……那又怎樣?如果測試不能快速地為開發人員和運維工程師提供有用的反饋，從而幫助他們改進係統的性能，那麼測試還有什麼意義呢?
除了通常的(但仍然是必要的)原始負載測試結果之外，團隊經常設置閾值或sla，以便在性能超出可接受範圍時發出警告。sre傾向於使用服務水平目標(sls)來建立這些閾值，並使用服務水平指標(SLIs)來度量它們，因此很容易知道性能何時下降。
您不應該等很長時間才知道在性能管道期間，係統是否還沒有準備好，是否達到了性能閾值。回到USE和RED的概念，這些服務“影響”指標也應該是閾值和性能測試失敗策略的關鍵部分。在負載測試期間，RED和USE測量的結合允許性能管道在壓力/負載和影響/服務觀察中“快速失效”。如果沒有這兩種類型的度量，您就無法了解性能是否可以接受。
出於這個目的，我們客戶的性能管道中使用的NeoLoad CLI支持容易實現的“fastfail”語法。同樣的,我們YAML-based“代碼”規範不僅支持SLA閾值(每個環境可能不同，很容易在每個環境中定義不同)，而且還指導Dynatrace支持在NeoLoad Web結果和儀表板中捕獲和發送RED和USE指標的全光譜。
最後，在管道的上下文中比較當前測試與基線並訪問基於趨勢的數據應該很容易。通過REST API實時使用這些數據是NeoLoad Web API的一個關鍵目標，這樣，無論您的特定設計和分析需求是什麼，您都有一種可靠的、麵向未來的方法將這些數據構建到性能管道過程中。
把它們放在一起
在Tricentis，我們每天都幫助客戶完成這些工作，而且已經有很多配置和技術可供選擇。參考例子可以在GitHub上找到，就像我們的負載測試容器組件一樣，但更廣泛的性能測試學習是:
- 開始通過api編寫性能測試過程。
- 將這些模式和經驗擴展到其他類型的應用測試中。
- 不要期望在CI構建節點中使用沉重的工具會產生良好的結果。
- 確保有適合環境的閾值/ sla。
- 將RED和USE指標公開到您的管道中，以簡化可以/不可以的結果。
- 將結果報告的方式標準化，放到一個可以聚合數據的中心位置。
要深入討論這些性能測試主題，請查看我們的白皮書持續性能測試的實用指南．