開始在你的自動化性能測試之旅可以令人生畏的如果你不開始在正確的地方。你需要選擇正確的目標,導致很多人的情況Tricentis NeoLoad客戶從api開始。你可能有很多團隊,最終需要交付過程績效反饋回路,但開始小和建築在你成功是改變現狀的關鍵。
在許多情況下,企業級組織已經積壓了大量的api和microservices尚未覆蓋的性能(或功能)測試。api還代表一個小得多的“麵積”測試的複雜性和sla。一些api是獨立管理和部署,使它們更容易測試比,說,大公開的api、共享企業服務總線(ESB)。
幾乎總是有一個橫截麵的api在您組織的組合,簡單的目標還在關鍵業務路徑的收入或風險。與這些服務,你應該關注作為初始目標直接構建持續的反饋循環。
團隊已經部署和準備好測試的東西,在較低的環境中或在生產中,是一個偉大的地方開始。這些團隊也可能是那些性能工程師已經有關係。如果是這樣,獲取架構圖,獲得監控工具,建立適當的性能標準早在sprint工作已經預期,非常簡單。
如何早期對性能測試api還為時過早?
從前,一個測試人員會問一名開發人員,“我怎麼能測試你還沒有建造?“作為回應,開發者會聳聳肩,說,“現在我們的單元測試是足夠好;讓我們等著做所有,非功能性的東西,直到我們得到了一個臨時的環境。“不幸的現實是,工程團隊沒有奢侈的被告知瀑布流程了,更不用說推遲問題的可測試性和適當的需求收集“後”。
好消息是,它已經超過5年API描述符的戰爭最後導致了工業標準化OpenAPI規範的格式。如果API團隊背後你的係統沒有記錄和描述他們的API在這種格式中,羞愧他們(小)。在那之後,你還剩下腳本並運行測試的需要。但是這些天有大量的選項設置semi-representative目標係統,這樣您就可以提前做大多數的腳本工作。然後,當一個真正的係統部署到登台環境,你可以簡單的測試,新環境。
一個常見的實踐當left-shifting反饋循環是模擬依賴關係。在API的情況下,您可能想要編寫測試這麼早,實際的API還沒有部署。許多組織使用服務虛擬化對故障隔離(刪除特定第三方集成測試),但沒有意識到是多麼有用的API嘲笑之前創建測試套件的過程實際API部署。這種做法加速的過程包括性能反饋回路隻需提前準備好可自動化的測試資產實際的自動化測試過程之前需要他們。事實上,一些性能團隊甚至創建了自己的開源工具,如Mockiato,讓這部分日常敏捷測試實踐。
是很少過早考慮軟件測試,或期望的性能需求,在開發周期之前。但是你必須“在房間裏,”在這些早期的π和架構會議。不要指望別人會捕獲和文檔測試之前需要知道是什麼。
開發性能管道
創建幾個自動化專門管道運行性能檢查是另一個開始的好地方。而不是假設輸送管道是一個龐然大物,單獨工作或管道進行特定post-build執行長時間運行的測試流程,允許團隊決定何時觸發它們(例如,不是每一個提交/推動,但在將請求和重要的合並)。這樣的分離管道階段還允許您運行並重新運行負載測試過程如果一切正確編譯和部署但性能sla失敗由於錯誤配置或環境問題。
在NeoLoad,我們使用大量的財富500強企業,必須集成到許多不同的CI / CD管道係統。在大型組織中,它並不少見的混合多種技術來做到這一點。好消息是我們不需要專門的插件或行政進入管道運行性能測試。你隻是需要我們的命令行接口。你可以找到例子實現NeoLoad各種CI的平台在這裏。
我們的目標是提供與這些早期的裏程碑有用的,頻繁的反饋性能閾值團隊的同意是合理的校驗和代碼本身應該在小規模的表演。這是無幹擾信號質量,讓團隊和產品所有者了解哪些領域的架構,代碼,和環境他們可能需要分配時間地址,在離開之前交付周期的晚期。清晰的非功能性需求(nfr)從這個工作,團隊可以更自信地設置適當的生產環境中,監控和報警閾值,甚至開始構建服務水平目標(SLOs)與業務目標相一致。
增加你的成功組織範圍的方法
每一天,我們的客戶工程團隊幫助NeoLoad客戶從小型孤立成功廣泛可采用的方法是通過架構審查委員會(arb)在大型組織和實施由數以百計的團隊。在我們的經驗中,企業已經成功地采用了性能工程方法在整個組織分享這些元素:
- 明確的標準在各種類型的性能測試是必需的
- 提供的服務的描述表現主題專家(sme)
- 文檔為中小企業如何吸引和利用測試平台
- 性能需求攝入過程,最好是在線團隊提交
- 回購的樣品管道、性能測試套件和報告模板
- 邀請新員工培訓/培訓和regular-cadence圓桌會議,團隊和中小企業開會討論成功,差距,和未來的改進
- 部署和管理計劃測試平台和基礎設施
我們經常發現,自上而下的組織要求不太流行比提供一個首選的方法性能測試,同時也讓中小企業留住一些知識和技能獨立團隊可能采取的其他方法。盡管它給中小企業更多的短期壓力支持多個工具,流程,和培訓的需要,所有的組織都在不斷變化。批準一個首選的方法但也允許團隊與他們提供了靈活性,同時指導船朝著一個更加可伸縮,可支持的長期模式。
分層的最佳實踐和護欄
當團隊開始從事中小企業和定義性能需求,它也能幫助可伸縮的知識(特別是在深技術細節)存儲在某個地方像wiki。文章“如何配置Apache”或“調優JVM的最佳實踐”大有幫助,以確保開發和發布工程師不寫差優化工件,部署它們,並找出困難的方式,他們的特殊的雪花服務不是可伸縮的負載。
有很多性能部落知識可以簡化為這樣的文章。他們給產品團隊授權自主實現這些“好行為”沒有淹沒數量有限的中小企業在一個組織。一些其他的話題我們經常看到在成熟組織的知識的綱要:
- 如何配置負載平衡器和網絡入口控製器嗎
- 簡單的API如何編寫和運行負載測試和壓力測試
- 如何請求安全防火牆服務器和服務之間的異常
- 我該如何監控:
- 在我服務、操作係統和網絡
- 在我的控製層麵(例如,普羅米修斯Kubernetes集群)
- 在批處理和隊列的場景
- 在我數據平麵/商店
- 如何實現在CI管道性能測試
- 儀表板性能不同的團隊應該看在每日站立會議
一旦團隊開始執行樣品和適應他們的需求,中小企業集團往往會想無縫地注入sla和額外的監控過程的產品性能測試團隊使用。NeoLoad使這個荒謬的簡單,尤其是在CI管道,通過:
- 使用共享庫或框架簡化管道代碼
- 允許額外的測試工件分層共享功能
- 培訓和指導產品團隊在如何更好的分析結果
這給上升到護欄的概念——或中小企業最佳實踐——蒸餾成測試構件和模板,以便中小企業不需要重複相同的管道跨越數百團隊辛苦的任務和性能。這是現代的核心網站可靠性工程在成熟的組織中。“我怎麼能自動化這事有人老是問我做什麼?”
我們也看到了其他國產工具實現性能測試之前和之後管道運行,如公用事業自動化環境配置比較,混亂注入(如小精靈)證明負載平衡和pod Kubernetes是定義擴展,和自定義基準比較和趨勢報告每次運行負載測試。這些護欄幫助產品團隊,不需要他們是專家在性能測試流程細節,但仍提供他們需要的深刻見解提早行動,保持他們的產品交付周期晚期驚喜。
你NeoLoad加速性能的應用之旅如何
NeoLoad提供了多種方式開始API測試。通過我們的桌麵設計師或額外的命令行接口,您可以快速導入OpenAPI規格,郵差集合,或者編寫測試在我們的YAML格式。寫這些測試之後,您可以運行在NeoLoad Web或直接從命令行得到快速和簡單的績效反饋。
NeoLoad支持多個監控策略,無論是Dynatrace等集成工具,AppDynamics, NewRelic,和其他APM平台;特定服務器的直接監測和過程;或通過容器控製飛機像普羅米修斯監控解決方案。得到您的負載測試壓力指標的影響在負載測試係統是最小可行說話。
NeoLoad CLI(命令行接口)也支持所有主要的CI平台並提供崎嶇的向後兼容性,這樣您就可以嵌入到您的管道與信心,它將作為未來的設計工作。
此外,NeoLoad Web提供了一種統一的方法來管理性能測試結果數據,包括默認的報告,可定製的儀表板,test-over-test趨勢。還有一個完整的REST API,允許您下載性能測試結果總結和原始數據,這樣您就可以將這些結果集成到任何現有的過程或工具您目前使用分析性能數據。
發現更多關於開始使用自動化連續性能測試在我們的白皮書連續性能測試的實用指南。
查看我們所有的資源性能工程在這裏。