技術主題

什麼是性能工程?

以燈泡為重點的 IT 項目圖示

概述

性能工程是主動、持續和端到端的應用程式性能測試和監控。它允許團隊、工具和流程之間通過持續的反饋迴圈進行無縫協作。在這裡,不僅測試人員負責品質保證,開發人員、性能工程師、產品負責人和業務分析師也負責。

通過利用從開發人員到性能工程師的合適規模的工具,性能工程可實現左移性能測試和右移應用程式性能監控。如果不了解經典性能測試,就很難理解性能工程與傳統性能測試的差異有多大。

性能工程

性能測試和性能工程有什麼區別?

經典性能測試實際上是性能工程的一個子集。它通常需要運行一輪 負載測試,作為開發後質量保證 (QA) 週期的一部分。性能測試涉及在預期工作負載下檢查應用程式的速度、可靠性、可伸縮性、穩定性、回應時間和資源使用方式。在我們討論性能工程和性能測試之間的區別之前,我們首先要孤立地看一下性能測試,以及為什麼它本身不再可持續。

  • 首先,測試被孤立地看待,並被視為事後的想法,僅在功能測試結束時才開始。
  • 其次,孤島式工作會導致專案子團隊之間出現巨大的溝通鴻溝,並阻礙交付高品質產品所需的協作。
  • 第三,當性能測試開始時,組織已經投入了大量的時間、精力和資金來設計、開發和推廣應用程式。
  • 第四,性能測試通常被視為事後的想法,不包括在發佈前的“完成”標準中。因此,在這個關頭,企業迫切需要將應用程式投入生產,並且預計不會出現延遲。在這種情況下,QA 的反饋發生得太晚,無法在發佈之前完全修復。不可避免地,大量的性能問題會不必要地進入生產環境,以便發佈保持在計劃範圍內。修復生產中的缺陷比在開發早期修復要昂貴得多,而且具有破壞性。
  • 第五,傳統的性能測試可能非常適合瀑布模型,但在當今以DevOps為中心的世界中已經格格不入。DevOps 透過縮短將更改提交到系統和將更改放入生產環境之間的時間來降低新版本的失敗率。持續集成和持續交付 (CI/CD) 可確保軟體在其整個生命週期中始終處於可發佈狀態。DevOps 還專注於重新調整組織,以支援利益相關者、職能和工具之間的端到端協作。為了滿足DevOps的快速交付需求,軟體開發需要一種更先進的性能測試方法。這種新方法就是軟體性能工程。

現在,讓我們深入探討性能工程與性能測試之間的主要區別。

  • 首先,性能測試是對應用程式負載處理和回應能力的質量檢查。它確定了系統承受生產負載的能力,並預測了在重負載條件下可能出現的問題。性能工程旨在從一開始就考慮性能指標來設計應用程式,並促進在開發早期發現問題。
  • 其次,性能測試是一個 QA 過程,通常在一輪軟體開發完成後進行。性能工程是一個持續的過程,它嵌入到軟體開發週期的所有階段——從設計到開發,再到最終用戶體驗。
  • 第三,性能測試由QA團隊進行,而性能工程涉及 RND 和QA。

性能工程概念

通過以下概念,DevOps和性能工程提供一致的生產性能結果,使客戶能夠更有信心地高效部署應用程式,並推出滿足使用者期望的高性能、穩定的軟體。

端到端優化

性能工程通過持續的測試和監控過程提供端到端的系統優化。這會將性能和負載測試轉移到開發過程中。這與傳統的性能測試不同,在傳統的性能測試中,測試是在功能測試穩定併發佈代碼之後進行的。

代碼發佈后,性能工程通過利用應用程式性能監控 (APM) 工具在生產中跟蹤應用程式。

績效利益相關者的跨職能團隊

性能工程支持專案利益相關者之間的協作,從業務分析師到開發人員。保持高績效水準以增強客戶體驗,跟上業務步伐,並管理端到端性能,使每個人(而不僅僅是 QA/性能工程師)都成為產品性能的管家。方法如下。

卓越測試中心

卓越測試中心 (CoE) 是值得信賴的測試顧問和最佳實踐的保管人。CoE 支援不同的營業單位、不同的測試方法(如 DevOps 和敏捷),並可以根據需要靈活地推薦性能測試和測試工具。為了構建更好的測試模型並提高測試品質,CoE 充當整合和重用測試數據的單點,這些測試數據是隨著時間的推移在多個營業單位中生成和收集的。

性能工程師

性能工程師提供開發中所有代碼的整體視圖,以確保性能測試標準全面,涵蓋大局,並考慮開發中所有不同的代碼片段。性能工程師是性能測試工具的主要使用者,在編寫腳本、設計、運行和分析測試結果方面具有高度的專業知識。性能工程將性能工程師帶到開發的早期階段,他們可以提供代碼所需的性能指標和方案,以便將代碼視為已準備好發佈。早期參與意味著性能工程師可以確保解決方案滿足開發之初設定的性能預期。它們還確認了架構和設計在整個開發過程中是一致的。

程式師

開發人員是編碼方面的專家,但在功能和性能測試方面往往很輕鬆。他們在集成開發環境 (IDE) 中工作,傾向於使用自己喜歡的工具,而很少學習新工具。性能工程將性能測試轉移到左側,將其帶入軟體開發人員的職責範圍。借助性能工程師的輸入,軟體開發人員可以在編寫代碼時運行性能測試。開發人員在通過性能測試標準之前不會發佈其代碼。

開發測試人員

開發測試人員在經典性能測試中不存在,因為軟體開發人員和性能工程師之間有明顯的區別。在性能工程中,開發測試人員成為連接性能工程和開發人員團隊的利益相關者。他們通過紮實的編碼和測試技能來彌合差距,儘管與開發人員和性能工程師的專業知識水準不完全相同。他們可以快速運行測試,並且在根據需要使用不同的工具時比開發人員具有更大的靈活性。

業務分析師和應用工程師

通過向右移動測試,性能工程引入了業務分析師和應用工程師。這保證了定義用戶體驗品質的業務和應用程式性能要求被納入性能標準。這兩個角色在生產環境中監視應用,以確保始終具有一流的應用程式性能。


找到合適的性能工程合作夥伴

性能工程正在改變軟體開發格局以及所有參與其中的人員的工作描述。現在涉及的角色越來越多,對簡化流程的工具和技術的需求比以往任何時候都更大。性能工程需要從右到左和從左到右的端到端整合和協作以及即時洞察和分析。傳統的性能測試供應商沒有足夠的能力來應對這一波混亂的變革。 OpenText 儘管擁有經過驗證的經驗和技術解決方案,可以將測試混亂轉化為工程秩序。

OpenText 效能工程開放架構支援在任何開發環境中跨任何協定和應用程式類型進行測試。它允許利益相關者(從開發人員到業務分析師)使用眾多供應商和開源工具,以實現大規模的完整 CI/CD 整合。 OpenText 工具整合能夠快速消除減慢應用程式交付速度的開發和測試等待時間。這些整合透過快速創建 API、網路條件和虛擬服務的真實模擬來實現這一點。 OpenText 性能工程解決方案建立在現有的本地或雲端基礎設施之上,並促進資產重用以利用現有投資。這有助於快速擴展,以滿足整個企業多個應用程式效能測試的需求。

傳統的效能測試直到功能測試完成才開始,直到效能測試結束才開始識別缺陷和根本原因。 OpenText 效能工程需要持續的端到端測量和缺陷分析,以便在效能測試結束之前即時找出根本原因。績效標準包含在「完成」的定義和要求中。 OpenText 即時分析可協助效能工程師快速向開發人員提供回饋,以便在開發過程的早期啟動故障排除。生產中的綜合監控和真實用戶監控可以深入了解未經過測試且必須在下一版本中修復的效能問題。 Capture 從效能角度分析最終用戶情緒,為開發人員提供更具體的回饋,從而優化應用程式以獲得更好的效能。

我們能提供什麼協助?

腳注