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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圓形可視化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

點擊圖片放大

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

點擊圖片放大

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

桑基圖

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

下圖的創(chuàng)建使用了來自 的桑基圖實例和從HPLoadRunnerAnalysis工具中提取的網(wǎng)絡段延遲數(shù)據(jù)。

生成該圖像的步驟如下：

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

網(wǎng)絡可視化

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

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

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

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

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

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

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

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

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

點擊圖像放大

該總結圖表可以如下蜘蛛網(wǎng)圖來顯示。

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

現(xiàn)在我們所擁有的關鍵調(diào)查結果包括：

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

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

現(xiàn)在我們要做的是回答以下這些問題：

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

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

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