OpenText 首頁。
技術主題

什麼是效能工程?

以燈泡為焦點的 IT 項目說明

概述

以效能工程提升效率與可靠性

效能工程是主動、持續和端對端應用程式效能測試與監控。它允許團隊、工具和流程之間透過持續的回饋迴圈進行無縫協作。在這裡,負責品質保證的不只是測試人員,還有開發人員、效能工程師、產品擁有者和業務分析師。

透過利用適當大小的工具,從開發人員到效能工程師,效能工程可實現左移效能測試和右移應用程式效能監控。如果不瞭解何謂傳統效能測試,就很難理解效能工程與傳統效能測試的差異有多大。

性能工程

效能測試與效能工程有何差異?

傳統的效能測試實際上是效能工程的子集。這通常需要執行一輪負載測試,作為開發後的品質保證 (QA) 週期的一部分。效能測試包括檢查應用程式在預期工作負荷下的速度、可靠性、可擴充性、穩定性、回應時間和資源使用情況。在討論效能工程與效能測試之間的差異之前,我們先來看看單獨的效能測試,以及為什麼效能測試本身已無法持續下去。

  • 首先,測試被孤立地看待,視為功能測試結束後才開始的事後工作。
  • 其次,各自為政的工作方式會造成專案子團隊間溝通上的鴻溝,無法進行所需的協作以提供高品質的產品。
  • 第三,當性能測試開始時,組織已經在應用程式的設計、開發和推廣上投入了大量的時間、精力和金錢。
  • 第四,效能測試經常被視為事後的想法,並未包含在發行前的「完成」標準中。因此,在這個關頭,企業急需應用程式投入生產,並且不希望有任何延誤。在這種情況下,QA 的回饋發生得太遲,無法在發行前完全修正。無可避免地,大量的效能問題會不必要地出現在生產環境中,只為了讓版本能如期發行。在生產階段修復缺陷的成本和破壞性遠高於在開發初期修復缺陷。
  • 第五,傳統的效能測試可能非常適合瀑布模型,但在現今以 DevOps 為中心的世界裡已不合時宜。DevOps 縮短了變更提交到系統與變更投入生產之間的時間,從而降低了新版本的失敗率。 持續整合與持續交付 (CI/CD)可確保軟體在整個生命週期中始終處於可釋放的狀態。DevOps 也著重於重新調整組織,以支援利害關係人、功能和工具之間的端對端協作。為了滿足 DevOps 的快速交付需求,軟體開發需要更進化的效能測試方法。這種新方法就是軟體效能工程。

現在,讓我們深入瞭解效能工程與效能測試之間的主要差異。

  • 首先,效能測試是應用程式負載處理和反應能力的品質檢查。它可以確定系統承受生產負載的能力,並預測重負載時可能出現的問題。效能工程尋求從一開始就以效能指標來設計應用程式,並促進在開發初期發現問題。
  • 其次,效能測試是一種 QA 流程,通常會在一輪軟體開發完成後進行。效能工程是一個持續的過程,它崁入軟體開發週期的所有階段 - 從設計、開發到最終使用者體驗。
  • 第三,性能測試由 QA 團隊執行,而性能工程則涉及 RND 和 QA。

效能工程概念

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

端對端最佳化

效能工程透過持續的測試和監控流程,提供端對端的系統最佳化。這將效能與負載測試轉移到開發流程中。這與傳統的效能測試不同,傳統的效能測試是在功能測試穩定且程式碼發佈後才進行測試。

程式碼發佈後,效能工程會利用應用程式效能監控 (APM) 工具追蹤生產中的應用程式。

由績效相關人員組成的跨功能團隊

效能工程可讓專案利害關係人 (從業務分析師到開發人員) 進行協作。維持能提升客戶體驗的高效能水準、跟上業務的腳步,以及管理端對端的效能,讓每個人,不只是 QA/效能工程師,都成為產品效能的管理者。方法如下。

卓越測試中心

測試卓越中心 (CoE) 是值得信賴的測試顧問和最佳實務的保管人。CoE 支援不同的業務單位、不同的測試方法 (例如 DevOps 和Agile),並可視需要彈性推薦效能測試和測試工具。為了建立更好的測試模型並改善測試品質,CoE 擔任整合與重複使用測試資料的單點角色,這些資料是長期以來在多個業務單位中產生與收集的。

效能工程師

效能工程師提供開發中所有程式碼的整體觀點,以確保效能測試的標準是全面性的、涵蓋更廣泛的層面,並考慮到開發中所有不同的程式碼。效能工程師是效能測試工具的主要使用者,在撰寫腳本、設計、執行和分析測試結果方面擁有高度的專業知識。效能工程將效能工程師帶入開發的早期階段,在此階段他們可以提供程式碼所需的效能指標和情境,讓程式碼可以被視為已準備好發行。早期參與意味著效能工程師可以確保解決方案滿足開發之初設定的效能期望。他們也確認整個開發過程中的架構和設計是一致的。

軟體開發人員

開發人員是編碼專家,但在功能和效能測試方面往往都很淺薄。他們在自己的整合開發環境 (IDE) 中工作,傾向於使用自己偏好的工具,幾乎沒有學習新工具的傾向。效能工程將效能測試轉移到軟體開發人員的職責範圍內。在效能工程師的協助下,軟體開發人員可以在撰寫程式碼的同時執行效能測試。開發人員不會在程式碼通過效能測試標準之前就釋出程式碼。

開發測試

由於軟體開發人員與效能工程師之間有明顯的區別,因此在傳統效能測試中並不存在開發人員 (devtester)。透過效能工程,開發人員成為連接效能工程與開發人員團隊的利害關係人。儘管他們與開發人員和效能工程師的專業水準不盡相同,但他們擁有扎實的編碼和測試技能,因此可以彌補差距。他們可以快速執行測試,而且比開發人員擁有更大的彈性,可以根據需要使用不同的工具。

業務分析師和應用程式工程師

效能工程將測試的重心轉移,讓業務分析師和應用程式工程師加入。這可確保定義使用者體驗品質的業務和應用程式效能需求已納入效能標準中。這兩個角色會監控生產中的應用程式,以確保應用程式隨時都有一流的效能。


尋找合適的效能工程合作夥伴

效能工程正在改變軟體開發的面貌,也改變了所有從業人員的工作內容。由於涉及的角色越來越多,因此比以往更需要工具和技術來簡化流程。效能工程需要端對端的整合,以及從右到左和從左到右的協同合作,並提供即時的洞察力和分析。傳統的效能測試廠商沒有足夠的能力來應付這股混亂的變革浪潮。OpenText 擁有成熟的經驗和技術解決方案,可將混亂的測試轉換為工程化的秩序。

OpenText 效能工程解決方案的開放式架構支援在任何開發環境中測試任何通訊協定和應用程式類型。它允許從開發人員到業務分析師的利害關係人使用眾多供應商和開放原始碼工具,以便在規模上實現完整的CI/CD整合。OpenText 工具整合提供了快速消除開發等待時間以及減慢應用程式交付速度的測試的能力。這些整合透過快速建立 API、網路狀況和虛擬服務的真實模擬來達成這一目標。OpenText 效能工程解決方案以現有的內部部署或雲端基礎架構為基礎,並促進資產重用,以利用現有的投資。這有助於快速擴充,以滿足企業內多個應用程式的效能測試需求。

傳統的效能測試是在功能測試完成後才開始,直到效能測試結束後才開始找出缺陷和根本原因。OpenText 效能工程解決方案具備持續的端對端缺陷測量與分析功能,即使在效能測試結束前,也能即時找出根本原因。已完成 "的定義和要求中包含了性能標準。OpenText 即時分析功能可協助效能工程師快速向開發人員提供回饋,以便在開發過程中及早進行故障排除。生產中的合成監控和真實使用者監控可讓您深入瞭解逃過測試、必須在下一個版本中修復的效能問題。從效能的角度來擷取與分析終端使用者的情緒,可為開發人員提供更明確的回饋,以便優化應用程式以獲得更佳效能。

我們能如何幫助您?

註腳