開始著手全球性IT轉型項目對于任何組織來說都是一件即興奮又富有挑戰的事情。當然，降低失敗風險是整個項目的主要目標之一。而測試是能明顯幫助降低失敗幾率的活動之一。

本文介紹了與傳統多用戶性能測試所不同的測試方法；盡管所使用的工具相同，但該方法結合了現代數據可視化技術，從而早早就能對那些可能存在有“沉睡著的”性能問題的特定位置及應用程序區域有所洞察。

大多數項目會首先專注于功能，然后才是其它。使用類似HP LoadRunner或Neotys Neoload這類測試工具的多用戶性能測試往往屬于測試循環后期才會發生的活動。很多時候會與UAT并行發生，而這時新系統已經暴露給終端用戶了。因此在性能測試時發現性能問題的幾率很高，修復的幾率卻很低。因為這種情況下，通常距離上線時間已所剩無幾。

多用戶性能測試通常發生于項目后期的原因有多種，根據項目的不同而不同。以下兩個原因最為常見：

• 多用戶性能測試要求工具和自動化。自動化性能測試腳本所需的資源只有在性能測試即將開始時才有望存在，即應用程序達到“穩定”的開發狀態時。假如自動化一個性能測試腳本需要2天的話，那么擁有多個測試腳本（比如：10至20個）就要花費大量的時間或人力。為了不破壞當前在性能測試腳本開發上所花費的資源，該階段不允許修改應用程序。所造成的結果就是：開發階段的任何延遲或需要對代碼進行大量的修改都將進一步延誤性能測試，這給執行帶來了風險，也不能及時提供相應價值。
• 多用戶性能測試需要一個類產品環境。尤其是處于IT轉型的項目，這樣的環境不一定在項目初期就存在，需要時間、精力和金錢去構建。但與之競爭的是早期測試周期中所有其它必需的對測試環境的配置和那些“真正辦事的”功能。對項目而言，絕對需要類產品環境的最早一刻是測試部署時（即彩排時刻）。而這時要想讓性能測試對項目成果產生正面影響已為時過晚。

作為降低風險的活動，性能測試是絕對必要的。真正的挑戰在于如何以不同方式進行，這樣可以在有更多時間和預算時就能解決與性能相關的問題。性能測試應在測試生命周期內更頻繁地被執行，同時與主要發布周期相互協調，從而提供更好的投資回報，并不斷地幫助降低項目風險。

以下這些目標很可能與大部分IT轉型項目的目標類似：

• 現代化 全球IT通過更新ERP和CRM應用程序到最新版本，為未來創新鋪平了道路。
• 合理化 優化應用程序以降低成本和復雜性
• 集中化 集中化IT基礎架構以降低成本和提高靈活性

本文所要說明的方法曾被一個處于IT轉型的項目采用，該項目運行于一個中等規模企業，該企業在全球范圍內運營，世界各地的辦事處數量也在不斷擴大。其通過標準的客戶關系管理系統（CRM）和企業資源規劃（ERP）應用程序, 在本地辦公室內面對面地處理與客戶的業務。

這兩個應用程序的共同關鍵屬性是顯示大量數據給用戶的同時，執行關鍵業務流程。此外，這些面向客戶的業務流程還需要輸入大量數據集（數百個記錄/業務流程），然后在彼此上層處理。在以前使用大量數據集的測試業務流程往往只計劃發生于用戶驗收測試（UAT）。其主要原因是：想在允許時間內覆蓋所有必需測試集而手動輸入數據的話，太費時間。數據遷移工作流被指定來為UAT傳輸這些數據，但是由于延遲，我們往往要等到UAT開始時才能期望用得上這些數據。

之前版本的CRM解決方案已經報告存在性能問題。當時該CRM已經集中化，并應用于世界各地的多個辦公室。這些性能問題因地點而異，分布于不同的功能塊；而且是由終端客戶報告出來的，沒有具體的測試或時間可供參考。

相反，之前的ERP解決方案是獨立安裝于各個地區或國家的，目前還沒報告有性能問題。但是集中運行這兩個應用程序的話，不由得讓人擔憂其性能，尤其在處理數據輸入、掃描和打印等活動時。

可拓展性測試雖然是多用戶性能測試的一個關鍵點，但卻算不上該項目的關注點。以市場為導向的標準軟件在實施時盡量地減少定制，并在產品環境中配置大小正好的基礎設施服務器。

非功能性需求被定義為該項目的一部分，卻需要被驗證。該組織多年前曾購買過HP LoadRunner作為性能測試的首選工具。但由于預算的限制，后來并未在測試工具上做進一步的投資。

綜合考慮各方面的限制和需求，該項目將以下這些定義為性能測試的主要目標：

1. 度量 度量來自不同辦公地點的應用程序的性能。
2. 對比 與非功能需求的性能結果進行對比。
3. 改進 為潛在的改進提供建議。

該解決方案從單一用戶角度出發進行性能測試。對關鍵業務流程的測試將在數個月內以真實的、自動化的形式在世界各主要地點進行，同時還覆蓋了各主要發布周期。現代可視化技術將顯著地減少分析及詮釋測試結果，還有呈現到項目管理團隊的時間。該單一用戶性能測試方法相比于“傳統的”多用戶性能測試有以下眾多優點：

• 不需要類似產品一樣的環境，可以使用任一現有測試環境。
• 其迭代方法允許性能測試腳本隨著應用程序的發展而不斷成熟，頻繁的使用帶來了良好的投資回報。與其冒著無法及時交付測試結果的極大風險而在短期內將大量預算花費在聘請眾多性能測試腳本編寫者上，這些費用大可以用于長期聘請一兩位性能測試腳本編寫者。
• 并非所有性能測試腳本都要同時準備好，并運行。
• 無需工作負載配置文件。
• 一旦類產品環境可用，自動化腳本可重用于多用戶性能測試。
• 相比于手動測試，由于數據創建是自動的，單一用戶性能測試可以在業務流程中使用更多更真實的數據量。

單一用戶性能測試解決方案在執行時用到以下工具和方法：

1. 資源上的限制決定了客戶端的執行性能（比如：渲染時間）將不被考慮在內。這將通過在客戶機上使用Profilers來完成(谷歌開發者工具)，或將功能測試自動化工具結合類似WireShark等網絡協議分析器。測試最初只專注于包括網絡時間在內的服務器響應時間。
2. 每個辦公地點都會有兩個用戶配有已識別好的臺式機，機器上裝有HP的Load Generator軟件。來自同一地點的兩組測量數據保證了所收集數據的正確率。如果在任何時候兩臺機器針對相同活動所收集的數據都相差很多，我們就可以認為是本地用戶設置出了問題。這不需要額外的硬件投資，也能從真實用戶地點收集到響應時間測量值，因此特別真實。在該測試中所用到的腳本也能在多用戶性能測試中復用，為性能測量提供統一、可重復的方法。不需要支付其它附加的測試工具許可證費用。
3. 每個辦公地點和數據中心的HP Load Generator分別以每15/1分鐘頻率執行性能測試腳本，確保我們不會稀里糊涂地陷入到執行多用戶性能測試的陷阱中。其主要目的是將測試系統中的并發降到最低。從數據中心獲取的測量數據扮演著“基準值”的角色，換句話說就是所謂的參考點。因此不同辦公地點間的響應時間與“基準值”的不同可被假定為終端用戶總體響應時間中與地點相關的那一部分，具體包括影響終端用戶性能體驗的網絡延遲、路由、繁瑣性及大小等等。“基準值”代表了服務器時間的具體值。根據測試環境的配置，從該測量數據中獲取的結論可以用來判斷是否存在與測試環境設置相關的問題。總體上的建議是測試環境應只水平地與產品環境版本進行縮放，而CPU速度、每個并發用戶的內存及硬盤等輸入輸出速度應當與產品環境相當。這樣我們就就可以很容易的假設”基準值”就是服務器的實際性能.
4. 監測網絡延遲（ICMP）和路由（tracert），并將其作為標準HPLoadRunner客戶端吞吐量的一部分。這三個測量值的組合允許我們評估網絡、路由和帶寬限制的質量。
5. 通過使用較低層的HP LoadRunner Web/HTML協議，應用程序的繁瑣性將自動被記錄，其影響也可評估出。而使用類似Ajax True Client協議這樣較高層的HP LoadRunner協議，在檢測繁瑣度時則需要額外的精力和工具（比如：Wireshark或Google 開發者工具集）。

該整體SUPT方法可以通過使用其他性能測試或類似HP Business Availability Centre(HP BAC)這樣的性能監控工具以類似的方法來執行。

為了收集有價值且有效的數據，我們在所有辦公地點將所有性能測試腳本執行上一段足夠長的時間。每個地點都使用兩個Load Generator的策略讓我們對測試結果更有自信，也幫助我們定位及解決用戶在配置上的不同。

“基準值”允許我們在不同環境上執行測試，比如：系統集成、用戶驗收或預產品等環境，通過對比不同地點的響應時間及相應數據中心的響應時間，我們可以區分出特定性能問題來自應用程序，還是環境或地點。

但要想使之成為可能的先決條件是在數據中心每隔一分鐘執行一遍性能測試腳本的循環。而其他所有地點則會每15分鐘循環一遍（每個地點間交錯開1分鐘的間隔）。目的在于觀察服務器和遠程地點在執行相同流程時響應時間的不同，而不是讓服務器超載。

一旦結果出來，我們要面對的挑戰是如何盡快有效地分析這些數據并為以下內容提供信息和分析數據：

1. 性能最差的地點。
2. 性能最差的測試腳本（業務流程）。
3. 針對非功能需求的性能（SLAs）。
4. 可被網絡管理團隊定位的路由和網絡延遲信息。
5. 針對如何改進性能所提出的建議。

SUPT的結果是由每個地點每一個事務響應時間而組成的大數據表。我們選擇第90百分位作為響應時間的代表值。

圓形可視化

我們所面臨的挑戰是找到能快速分析這些數據的工具。查看過各種各樣可視化工具及技術之后，我遇到了Mike Bostoks的“D3”項目，從那找到了圓形可視化及Circos，從而發現完成這一工作的最佳工具。

“是將數據和信息可視化的軟件包。它以圓形布局可視化數據，這使得Circos成為研究事務或地點間關系的理想工具，也是展示圖表的理想工具。圓形布局除了美觀外，還有其它的有利因素。”

有不少工具可讓Circos更易于使用，Table Viewer tool就是其中一個，在網上就可以找到。

建議在Linux上下載并配置Circos。第一次分析時，最簡單的方式是使用的Table Viewer tool的在線版本。

性能測試結果需導入到數據表中，其內容應與下圖相似。數據表還需符合以下要求：

• 無重復事務名。對于所有業務流程中相同的業務，推薦使用“S01_xx”作為慣例（比如：S01_Login）。
• 事務或地點名中無空格。
• 將地點作為列（“A1”，“A2”等）
• 將HP LoadRunner事務名作為行（“da”，“db”等）。
• 將第一列重命名為“Label”。
• 盡量保持名字短小。
• 將文件分割符選為“Tab”。

單單使用Table Viewer默認在線配置就能生成令人驚喜的結果。用于在線生成圖形的配置文件可以下載下來與本地安裝一起使用。

所得到的結果是類似下圖。理解該圖像的關鍵是從12點鐘開始，然后順時針查看HP LoadRunner響應時間測量值；或者參考事務（小寫字母），然后逆時針查看地點（大寫字母）。地點所對應的厚度是該地點所有響應時間的總和。同時生成的柱狀圖對進一步分析也非常有用。僅通過視覺比較，我們一眼就可以看出哪些地點受到低性能的影響，以及相對應的特定流程和步驟。

由于事務的數量可以相當大，該圖像在分析事務時信息量可能會有所減少。下一步我們需要過濾掉那些沒有問題的響應時間。比如那些響應時間少于最低SLA（以5秒為例）的事務就可以被排除出去。使用Table Viewer工具的話，有兩種方式可以達到這一目的。其中一種是過濾掉這些事務，但將其保留在總體計算中。

該圖像確實突出了性能最差的事務，以及它們在總體業務流程性能上所占的百分比，同時它還為理解潛在的性能改進提供了基礎。

要想在更緊湊且縮放的視圖中查看相同信息的話，我們還可以將那些通過SLA的事務從總體計算中排除。

我們現在可以清楚地識別出“fa”、“ea”、“dz”和“da”事務的性能是最差的，而“A1”、“A2”和“A8”地點的性能最好，“A1”地點則是數據中心。

現在的目標是生成網絡延遲和路由的相似視圖。第一步我們需要用LoadGenerator將HP LoadRunner Analysis中的從源到目的地的路由所對應的總網絡延遲信息分組（Analysis工具的一個功能）。然后將這些信息導出到電子表格中。

我們的目的在于驗證網絡延遲是否在預期的SLA范圍之內。下圖比較了網絡延遲測量值和已知的從源到目的地的SLA臨界值。為了了解是否有已知地點超出SLA，需要添加主機地點的信息。舉個例子：如果HOST11位于歐洲，那么SLA就通過了，如果位于其它地方，則失敗。

點擊圖片放大

同樣每個地點的吞吐量也要與參考點進行對比，與地點的假定可用帶寬及用于數據中心的實際帶寬進行對比。數據中心地點的測量值將決定達到假定的接近無限帶寬的可能最大值（比如：千兆以太網）。

點擊圖片放大

下一步目標是為網絡管理團隊獲取更多的細節，我們嘗試獲取更多關于路由和網絡延遲的詳盡分解信息。該分析的基礎是HP LoadRunner分析工具中的網絡段延遲圖（Network Segment Delay Graph）。

桑基圖

桑基圖是有向圖，其箭頭線的大小代表了流量大小。桑基圖被用于各種流程的可視化，不限于能源和材料，是任何“從”源“到”目的地的流程定義（實際或虛擬）。桑基圖將我們的注意力帶到了流量最大的流程上的同時，也顯示了各個流程間的流量比例，指示了“從 - 到”的流動方向。桑基圖是以愛爾蘭工程師Captain Matthew Henry Phineas Riall Sankey（1853-1925）的名字命名的。（， en.wikipedia.org/wiki/Sankey_diagram， ;）

下圖的創建使用了來自 的桑基圖實例和從HPLoadRunnerAnalysis工具中提取的網絡段延遲數據。

生成該圖像的步驟如下：

• 下載D3noob實例文件到目錄。
• 將從HP LoadRunner Analysis工具中導出的網絡段延遲數據導入到電子表格中，然后將其拷貝到“data”子目錄中的“Sankey.xls”。
• 確保網絡延遲無零值，可以將0值設置為0.01或其它。
• 確保電子表格中的標題如下所示，并將其保存為“.csv”文件。
• 刷新本地URL就能看到如上圖顯示的圖像。

網絡可視化

桑基圖用于理解單個網絡路徑和延遲時特別有效。但當試圖顯示整個網絡時，d3noob實例的局限性就暴露出來了。而我們的需求是采用一個易于使用的工具將復雜的網絡圖可視化。可用的工具很多，尤其在社交網絡分析這方面，NodeXL是最適合這一目的的工具。

“NodeXL是Microsoft® Excel® 2007、2010 和（可能）2013免費的開源模板，它使得網絡圖像探索變得輕松。有了NodeXL，我們可以在工作表中輸入網絡邊緣列表，然后點擊按鈕查看圖像，所有的內容都呈現在熟悉的Excel窗口里。”（）

我們將所有網絡延遲段信息輸入到同一工具里，并期望它能幫助我們確定任意特定路由問題。NodeXL所帶來的視圖效果還有很多，在這里我們并沒有全部采用（像節點圖片等）。

性能良好的網絡段通過基于標簽的“動態過濾器（Dynamic Filter）” 可以簡單地過濾掉。這種情況下，該標簽是網絡延遲的數值表征。我們還未探索的可能性是創建源到目的地網絡延遲計算的交互總值。盡管它會是個有趣的功能，但并非是必須的。從之前的分析中，我們已經有了總的源到目的地的測量值。

為了調查正確的路由方向，可以將圖像屬性從未定向改成定向。

在該實例中，圖中間的“diamond”看起來比較可疑。該工具有簡單的縮放功能。

上圖顯示了部分通信從“E”跳轉到“J”的兩種路徑，分別是“HH”和“II”。“II”路由的延遲要比“HH”路由高。該信息可以很容易地傳遞到網絡管理團隊，并用于項目內的溝通。我們期望網絡團隊能調查“diamond”存在的原因，并提供合適的解決方案。

通過上述步驟，我們對應用程序和地點性能的理解不再是個謎團，是時候開始專注關鍵的性能改進了。想要理解哪個改進是關鍵的，性能測試結果需要與非功能需求進行對比。這可以使用帶有過濾功能的Circos或帶有圖像和表格的Excel可視化功能來完成。

下表顯示了每個地點響應時間的分析總結。SLA列值是從表中檢索出來的，用來確保SLA的簡單管理，以防止任何變化。

點擊圖像放大

該總結圖表可以如下蜘蛛網圖來顯示。

同樣的方法也需要應用到網絡延遲和吞吐量SLA的測量及比較。

現在我們所擁有的關鍵調查結果包括：

• 我們知道業務流程中哪些步驟有性能問題。
• 我們知道哪個地點有性能問題。
• 我們知道網絡延遲和帶寬測量值。

下一個步驟我們需要進一步深入獲取有性能問題的業務流程詳情。之前的步驟允許我們非常有效地走到這一步。

現在我們要做的是回答以下這些問題：

1. 應用程序是否要下載多個靜態對象？如果是，那么這些對象能否緩存到本地，從而避免網絡下載？能否降低數量或將對象組合起來？
2. 應用程序是否繁重，其繁重性是否隨著數據處理量的增加而增加？在該示例中，應用程序可以按順序針對每個事項在服務器中調用一個更新。如果只是手動測試中的10個事項則完全沒有問題，但如果是在SUPT時使用的真實數據量達到500至1000個事項的話，對性能將會有顯著的影響。
3. 應用程序是否要下載或上傳大型對象，比如：文檔、圖像等？掃描儀的設置會極大地增加掃描文件的大小，卻不會顯著地提高其質量。檢測掃描文件的大小會明顯地影響上傳和下載時間。另外，帶寬也會隨之大幅度地增加。

總的說來，該單用戶性能測試方法的目的在于通過在全球不同內部地點內對真實數據量的使用，從而讓我們對應用程序性能能有個早期的概念。使用適當的現代可視化工具能幫助我們快速地分析與性能相關的數據，并定位性能問題。對上述方法和工具的使用也確保了其結果能在項目中傳遞的同時，被技術或非技術人員理解。

本文轉載自，原作者：，譯者：