該案例是某省電信公司的業務系統的性能測試。該業務系統用于管理省電信公司的所有電信交換機設備，業務系統的重點在于4個方面：從交換機定期獲取并處理話務報告；接收交換機發出的告警消息；允許用戶通過應用界面對交換機進行操作（發送命令）；允許其他業務系統發送的交換機操作要求通過網關的處理后轉換成相應的交換機命令并下發。
由于該業務系統是電信運營商的核心支撐業務系統，因此用戶對該系統的穩定性非常關注，要求系統能夠7×24小時不間斷運行，在最終決定的系統方案中，也為該系統的采集服務器進行了N+1的冗余配置，為應用服務器和數據庫服務器進行了1+1的冗余配置。
對業務系統的性能測試是在開發接近完成時進行的，主要目的包括幾個方面：驗證系統是否達到了預期的性能指標；驗證系統是否能穩定運行；驗證系統的失效恢復方案是否有效；在測試過程中有針對性的進行部分調優工作，以保證系統能夠達到預期的性能要求。
該項目的最大特點是選用的架構復雜，使用的協議基本上都是基于TCP/IP的自定義協議。該業務系統需要使用多種中間平臺，所以架構設計為一個復雜的分層結構。另一方面，應用各模塊之間的通信方式也比較復雜，考慮到與其他系統的接口，該業務系統采用了多種基于TCP/IP的自定義協議。
對性能測試來說，本系統的一個重要特點是系統涉及較多的外部設備（交換機等），而這些設備由于是用戶的實際生產設備，不可能按照測試的要求對其進行設置和操作，必須通過一定的手段來模擬這些外部設備。
該系統的另一個特點是性能測試關注的內容中交互界面很少，除了用戶下發命令外，其他的性能測試關注內容都沒有人工交互的干預，因此，測試中對系統性能的體現主要是業務處理能力，只在用戶下發命令這一個方面用響應時間來描述系統性能表現。
圖1簡單描述了該業務系統。
圖1
從圖1中可以看到，該業務系統是一個全省集中的處理系統，系統管理的話務交換機設備通過MOXA設備(1)轉接或是直接通過省電信公司的網絡傳輸的話務交換機設備通過MOXA到省電信中心的中心機房，所有服務器都放置在中心機房，通過網絡交換設備進入電信公司的網絡。為了保證系統的穩定運行，將服務器進行了分組管理，每組都設置了一臺設備進行熱備份。
由于這里給出的話務交換機設備都是實際在網運行的設備，因此，在實際的測試中，不可能利用這些實際的話務交換機設備進行測試。本業務系統管理的話務交換機數量較多，在全省規模下，有600臺左右的實際設備。
此外，該性能測試的部分性能目標在需求和設計中進行了明確的定義，性能測試目標的確定可以通過對需求和設計的分析獲取，這也是本案例的重要特點之一。
本節描述性能測試的全過程，根據本書第5章的性能測試過程描述，按照PTGM模型分別對性能測試的各階段進行闡述。
在了解該項目的基本狀況之后，首先開始測試前期準備工作。
1、系統基礎功能驗證
本案例中描述的性能測試安排在功能驗收測試之后，因此在性能測試中不需要額外安排基礎功能驗證。
2、組建測試團隊
根據該項目的具體情況，建立一個7人的團隊負責本次測試工作。團隊的7個成員中，1名是數據庫工程師，1名是系統工程師，3名是性能測試設計和分析人員，2名是性能測試開發和實施人員。
在測試開始之前，已經預計到該系統的性能測試可能需要投入較大力量進行測試方案設計，其次還需要自行實現部分測試工具，因此，安排了3名性能測試設計和分析人員與2名性能測試開發和實施人員。
3、測試工具需求確認
考慮到系統測試的要求，該系統面臨的最大問題在于需要模擬現有設備和系統使用的協議多，因此，綜合項目的狀況，最終確定的測試工具需求如下：
- 支持TCP/IP協議層上的測試。
- 能夠方便地模擬現有設備，由于我們關注的是現有設備的定時發送報告、不定時發送告警和接受下發命令（包括用戶和其他業務系統下發命令），因此對設備的模擬至少需要包括能定期發送指定數據、能隨機發送指定數據并滿足一定的頻度要求、能接受命令并給出響應。
- 能夠記錄每個操作消耗的時間，便于進行性能分析。
- 考慮到用戶的穩定性要求，工具要求能夠監控系統是否穩定。
4、性能預備測試
性能預備測試用于對系統建立直觀的認識，我們安排接入少量設備，并對少量設備接入后的系統運行進行體驗，體驗結果表明，在少量設備接入的情況下，系統能夠順利地完成話務報告數據處理，能夠在3秒之之內將設備產生的告警呈現在系統界面上。
測試工具的引入對本案例來說是一個比較重要的過程。
根據測試前期準備確定的測試工具需求可以發現，在目前市面上的商業工具中幾乎沒有工具可以完全滿足這些需求，因此經過討論，最終將測試工具的引入方式定位在“創建”上，即完全自行開發需要的測試工具。
對測試工具的需求再次進行分析和分解，從模擬設備程序、記錄程序和壓力工具3個方面來考慮，形成了本案例需要的工具列表，如表1、2所示。
表1
表2
多學兩招：
從表1、2中可以看到，為了完成本案例的性能測試，在測試工具上的投入就需要花費33人天。實際上，測試結束后的統計表明，花費在工具設計和開發上的工作量遠遠高于這個數值，原因是該工具也需要進行反復的設計修改和開發修改，并需要通過測試驗證工具的功能正確性。
與測試工具相關活動的資源投入，從測試結束后的統計數據中得到的數據是51人天，如果按照工作日22天/月來計算，相當于是2.3個人1月的投入。
細心的讀者應該能注意到，上表的測試工具中，前兩個工具都要求能夠在Windows和UNIX平臺上運行，之所以這樣要求，是因為我們希望能夠充分利用設備資源。
表中的“模擬設備”的前兩個測試工具最終用Perl實現，這樣可以方便實現跨平臺；后一個測試工具用C語言實現，因為該工具對程序效率要求較高。
測試計劃階段需要分析用戶活動，確定系統的性能目標。
1、性能測試領域分析
根據對項目背景的了解，本性能測試要解決的主要問題問題包括：驗證系統是否達到了預期的性能指標、驗證系統是否能穩定運行、驗證系統的失效恢復方案是否有效以及在測試過程中有針對性的進行部分調優工作，以保證系統能夠達到預期的性能要求。
這些內容涵蓋了第2章中給出的能力驗證、性能調優兩個應用領域。進一步根據第2章的內容，本測試可用的性能測試方法為除ConcurrencyTesting外的其他性能測試方法。
2、用戶活動剖析與業務建模
在本案例中，用戶活動主要通過話務交換機的行為來體現，因此，本活動的主要內容集中在為應用建模上。
通過對話務交換機的行為進行抽象，可以得到一個簡化的話務交換機模型。就本案例關注的交換機功能，簡化后的話務交換機模型如圖2所示。
圖2
對本案例的業務系統來說，交換機可以簡化成具有3個端口的設備，這3個端口分別是話務口、告警口和操作口。
(1)話務口
話務口可被看作一個TCP/IP端口，該端口等待連接，在給定的話務周期到達時，向所有連接在該端口上的連接發送話務報告，話務報告以二進制數據流方式發送，不同交換機的話務報告格式和數據量均不不同。
(2)告警口
告警口可被看作一個TCP/IP端口，該端口等待連接，在交換機內部發生故障或錯誤時，向所有連接在該端口上的連接發送告警報告，告警報告以二進制數據流方式發送，不同交換機的告警報告格式和數量均不同。
(3)操作口
操作口可被看作一個向其發送具有一定格TCP/IP端口，該端口等待連接，連接上該端口的連接可以式的命令，當命令格式正確時，交換機執行命令請求的操作并以二進制數據流方式返回結果。
因為這3個端口之間沒有直接的關聯，因此，采用表1描述的測試工具可以完全模擬圖2給出的話務交換機簡化模型。
對本案例而言，需要進行性能測試的業務系統需要連接這3種不同的端口，并對下發和接收到的數據進行處理，業務系統的處理方式有以下4種。
（1）話務報告處理
話務報告處理過程從系統接收到話務數據流開始，接收到數據后先進行初步分析（分離報告），將報告形成文本文件保存在本地，同時向消息隊列中發送一個消息。
分析進程阻塞消息隊列，當在消息隊列中發現消息后就取出該消息并按照消息指示對本地文件進行處理。對本地文件的處理是從文件中分析出數據并寫入數據表的相應字段。
該業務系統的話務報告處理過程如圖3所示。
圖3
（2）告警報告處理
告警報告的處理過程從系統接收到告警數據流開始，在該業務系統中，告警數據直接由HP的Temip平臺進行處理，告警數據流直接發送給Temip平臺。通過一個入庫進程，告警數據在處理后進入數據庫。告警報告的處理過程如圖4所示。
圖4
（3）用戶操作處理
用戶操作的處理過程從用戶下發交換機命令開始，用戶通過一個被稱為“仿真終端”的應用向交換機發送命令，通過一個連接交換機代理程序將命令排隊處理后發送給交換機。用戶操作的處理過程如圖5所示。
圖5
（4）其他業務系統操作處理
其他業務系統的操作處理從其他業務系統發送消息開始，通過一個業務接口程序，將其他業務系統發送的消息分析形成交換機命令，通過連接交換機的代理程序將命令排入命令隊列進行處理，如圖6所示。
圖6
多學兩招：
分析應用的行為對于這種類型的應用非常重要，不深入了解應用系統的實現方式，就不可能明確知道性能測試時究竟應該關注哪些內容。對于大部分屬于用戶交互的應用來說（如OA系統），往往只需要考慮用戶的感覺（也就是用戶感受到的響應時間），對性能測試條件的分析也集中在對用戶行為的分析上；而對于本案例描述的這些應用（銀行的某些業務系統也是典型的此類應用），對性能測試條件的分析就需要明確知道應用的工作方式，這樣才能明確在性能測試中需要關注哪些內容。
分析應用行為的最好方法是用流程圖的形式描繪出業務系統中涉及的各進程和數據交互過程，由此可以清晰地得到性能測試中需要關注的內容。
3.確定性能目標
本性能測試的應用領域已被確定為能力驗證和性能調優，因此在確定性能目標時，應該圍繞這兩個方面進行。
本項目是一個開發項目，需求和設計中已經對部分性能目標進行了定義。在本案例中，從需求和設計中得到的與性能相關的描述包括。
（1）系統能夠及時處理完全省交換機的話務數據。
（2）系統能夠處理平均值為300次/秒的告警，能夠承受峰值為600次/秒的告警。
（3）系統能夠快速響應用戶下發的命令。
（4）系統能夠及時處理其他業務系統發送的交換機操作消息。
（5）系統能夠穩定運行。
（6）系統能夠在一臺采集服務器、一臺應用服務器和一臺數據庫服務器由于特殊原因崩潰時不間斷運行。
在這些描述中，除了第（1）、（2）、（6）條是比較清晰的性能需求描述外，其他3條都是非明確的性能需求。而且，即使是第（1）、（2）條，也同樣需要進一步的確認。為此，在該活動中，性能測試組通過與項目經理和客戶的多次溝通，對性能測試需求進行了更加明確的確認。
（1）系統能夠及時處理完全省交換機的話務數據：該業務系統接入的全省話務交換機數量為600臺，其中約20%的交換機話務周期設置為15分鐘，這部分交換機的話務報告平均大小約為4KB；約有30%的交換機話務周期設置為30分鐘，這部分交換機的話務報告平均大小約為6KB；約50%的交換機話務周期設置為1小時，這部分交換機的話務報告平均大小為7KB。
（2）系統能夠處理平均值為300次/秒的告警，能夠承受峰值為600次/秒的告警：該業務系統接入的交換機數量為600臺，300次/秒的告警發生頻率相當于每臺交換機每秒發生0.5次告警，考慮到各交換機具有不同的告警發生頻率，經過對現網運行系統一周數據的分析表明，發生告警最多的設備大約每秒發生2次，發生告警最少的設備大約每小時發生2次，差別巨大。并且，用戶實際還有一個并未在需求文檔中給出的隱含要求：告警從產生到呈現的時間延遲小于5秒。
（3）系統能夠快速響應用戶下發的命令：經過與用戶的確定，“快速”被重新定義為用戶下發命令與在沒有命令排隊的情況下，交換機接收到命令的延時不得大于2秒，交換機反饋信息與用戶接收到反饋信息的延時不得大于2秒。而且，明確的并發用戶數量為100名。
（4）系統能夠及時處理其他業務系統發送的交換機操作消息：經過與用戶的溝通，用戶對該業務系統的要求實際上是系統不能丟失其他業務系統發送的交換機操作消息，因此該需求實際描述的是系統的命令緩存能力，最終該需求被描述為：系統能夠緩存1000條其他業務系統發送的消息不再接受新的消息并返回給發送消息的業務系統一個錯誤信息，當緩存區滿時，。經過這樣的分析，該需求變成了一個功能的需求，不再需要在功能測試中體現。
（5）系統能夠穩定運行：該需求最終被表述成系統在壓力下的性能表現，根據其他可參考的系統穩定性依據，該需求被描述為系統能夠在比穩定運行時大2倍的壓力條件下持續運行14天，期間各應用進程占用的內存及應用響應速度都不會發生明顯變化。
（6）系統能夠在一臺采集服務器、一臺應用服務器和一臺數據庫服務器由于特殊原因崩潰時不間斷運行：對該需求的一個補充是，由服務器失效引發的切換必然會使正在進行的業務收到影響，因此，允許切換過程中產生不完整的數據。另外，應用的切換必然存在一個切換時間，商定的允許切換時間為5分鐘。
指點迷津：
需求文檔、設計文檔以及其他相關文檔中給出的性能需求通常都會存在含混不清的地方，在設計性能測試之前，必須將這些地方徹底理清。甚至在某些情況下，不同來源的文檔之間會存在沖突，這時應該向項目經理說明此事，并由客戶代表進行最終的決定，決定后的結果需要明確記錄下來。
表3給出了分析整理后的性能需求描述。
表3
對能力驗證應用領域來說，本測試需要重點關注的是業務的響應時間、各服務器的資源使用狀況，結合性能測試需求，性能目標可以定義如下：
- 在滿足全省話務數據規模的情況下，服務器CPU平均使用率不高于75%，內存使用率不高于75%。
- 在平均告警規模下，服務器CPU平均使用率不高于75%，內存使用率不高于75%；峰值情況下，服務器CPU平均使用率不高于90%，內存使用率不高于85%。
- 沒有命令排隊情況下，交換機接收到命令的延時小于2秒，用戶接收到反饋信息的延時小于2秒。
- 各組單臺設備故障時，系統切換時間不大于5分鐘，切換后業務如常進行。
對性能調優應用領域來說，本測試關注的重點是通過各種設置和部署的調整（原則是：除非確定是應用問題，否則優先考慮調整設置和部署方法），使系統性能表現能夠達到預期的要求。
指點迷津：
對上線的應用系統來說，影響其性能表現的因素很多，我們建議的調優順序是優先考慮系統級的調優，例如對應用服務器設置的調優、數據庫設置的調優和應用部署方式的調優。只有在確認是應用的問題，或是其他調優方法都不能奏效時，才考慮對應用代碼進行調優。
根據筆者的性能測試項目經歷，將近60%的應用系統性能問題都可以通過調整應用服務器設置、調整部署或調整數據庫設置獲得良好的性能提升，只有少數情況不得不對代碼進行調優。
4.制定測試時間計劃
本案例的特點之一在于測試中使用的大部分測試工具都是自行開發的，因此必須留出較多的時間進行工具的設計和開發。另外，由于系統本身的復雜性，測試環境構建也需要一定的時間。本案例的測試時間計劃安排如表4、5所示。
表4
表5
注：①在本案例的前期己經對工具開發的工作量進行了估算，估算得到的數值是33人天，此處的時間安排即是按照該估算進行的。
②這里用了一些虛擬的人名表示測試組成員。特別要提醒的是，在FailoverTesting過程中，一定要系統工程師和數據庫工程師的參與并準備好應急方案，一旦測試過程中發生意外，要按照預先制定好的應急方案對系統進行恢復。
測試設計與開發包括測試環境設計、測試場景設計、測試用例設計和測試輔助工具開發多個活動。對類似本案例的業務系統而言，測試場景關注的主要內容不是用戶感受，而是系統的業務處理能力，因此在測試場景設計上，注重的是通過何種方式獲取和性能相關的數據及如何對獲取的數據進行解釋。
1.測試環境設計
本性能測試需要驗證系統在實際生產部署環境上的性能，因此，盡可能選擇接近實際生產環境的環境來進行測試。
該項目測試的一個特點是需要通過模擬手段來模擬實際的話務交換機設備，結合前文中建立的話務交換測試模型，和圖1給出的系統示意圖，最終確定的測試環境包括預計用于實際運行的全部服務器條件，通過工具模擬的話務交換機運行于中心機房的PC機和非測試用服務器上。
這個測試環境與實際環境之間唯一的差異在于：系統接入的話務交換機不是真正的設備。對本系統來說，可能存在以下風險：
（1）因為報告傳輸速度不同，可能導致測試結果上出現不同。
（2）實際設備可能發出不完整報告，而模擬的設備不會，兩者之間存在的差異可能導致性能測試的結果不正確。
當然，這兩個風險在一定條件下可以解決，在本案例中，通過約束和分析解決了這兩個風險：對第1個風險，根據對各不同地市的不同機型交換機傳輸速度的調查，最慢的交換機（通過MOXA轉接方式）也可以在2分鐘內完成所有報告的傳輸，而且這些慢速傳輸的交換機的話務報告周期都設置為1小時；對第2個風險，實際設備發出的不完整報告會被接入進程丟棄，在性能測試過程中只要能驗證不完整報告不會對接入進行的性能造成顯著影響即可。
指點迷津：
使用非生產環境作為測試環境進行性能測試時，最好對環境之間的差異進行詳細分析并評估由此帶來的風險，在測試計劃中需要明確說明風險的解決方法或相應的對策。
該性能測試的另一個應用領域是性能調優，因此在性能測試過程中，需要合理且合適的測試環境維護方法，保證在調優的測試過程中測試環境能夠保持可信的基準。最終確定了5個測試環境，如6、7所示。
表6
表7
本案例中的測試數據環境設計根據系統的運行預期來確定。該系統的數據備份清除原則是：系統數據每3個月進行一次備份和清除操作，每次清除操作將數據庫中兩個月以前的業務數據全部清除。
從以上的描述可以看出，系統在穩定運行后，數據庫中的業務數據至多保留3個月，最少兩個月，為了考察性能表現，我們以3個月的業務數據作為數據庫中數據的基準。
采用類似第一個案例的計算方法，計算得出的數據庫中歷史數據環境如下：
話務數據表：19440000條記錄。
告警數據表：2120000條記錄。
為了保證數據環境在每次測試中保持一致，首次生成數據記錄后，將數據庫輸入（export）為本地文件并保存，在每次測試開始前，都通過輸入（import）方法將數據直接導入到數據庫，保證數據環境的一致。
另一方面，由于本性能測試使用的測試工具多且分散，在實際測試中將工具的啟動形成shell腳本或是bat文件，以具有意義的名稱進行管理。
另一個需要設計的是時間同步方案。本案例中需要記錄的測試結果數據很多，部分數據的處理需要根據記錄時的時間進行，而根據測試環境，應用部署較為分散，因此有必要為整個測試環境設計一個時間同步方案，以使整個測試環境中的各臺設備具有精確一致的時間。
本案例涉及的是一個UNIX和Windows的混合環境，因此采用ntp協議進行各設備之間的時間同步。
2.測試場景設計
根據表2、3，可以很容易地為該案例給出需要的測試場景，如表8、9所示，其中每個場景對應一個測試需求。
表8
表9
由表8、9看出，只要按照場景名稱、場景業務及比例分配、測試指標、性能計數器的描述方式，就可以非常清晰地對場景進行描述。
3.測試用例設計
確定測試場景之后，在原有的業務操作描述上，可以更進一步完善為可映射為腳本的測試用例描述。如果測試過程中需要較多的輔助工具進行協作，在用例設計中可能還需要描述工具部署情況。
在本案例中，用例設計的主要考慮內容是如何獲得與系統性能相關的數據，因此在本案例的測試用例設計描述過程中，我們設計了6個對應測試場景的方案。方案采用測試模型、測試說明、測試用例概述的方式進行描述。
（1）方案1——對應場景。測試系統能否及時處理完全省交換機的話務數據，測試模型如圖7所示。
圖7
①測試過程中采用600個模擬交換機設備發送話務數據，120個模擬的5ESS設備，話務周期為15分鐘，話務報告為4KB；180個模擬的Siemens設備，話務周期為30分鐘，話務報告為6KB；300個模擬的Ericsson設備，話務周期為1小時，話務報告為8KB；600個模擬設備的進程分布在15臺測試機上，每臺測試機運行40個模擬設備的進程。
②測試過程中，采用3臺采集機，每臺采集機上運行一個接入進程和6個處理入庫進程。之所以用6個處理入庫進程，是因為采集服務器設備有6個CPU，6個進程可以最大限度地提高處理效率。
③為了記錄話務數據處理過程中的各個時間點（模型中的T1、T2、T3標識），約定如下：
- 在模擬設備程序目錄下的sendlog.log文件記錄發送出話務數據的時間戳和局號。
- 接入程序的日志記錄該程序發送的消息等內容，文件存放在采集服務器的/opt/mytest/data/目錄下。
- 分析入庫程序的日志位于采集服務器的/opt/mytest/log/plog目錄下。該程序的日志內容包含接收消息的時間、處理的時間以及數據入庫時間。
【驗證方法】
以最后一個報告已入庫的時間作為全部報告的入庫結束時間，該時間提前于下一話務周期。
（2）方案2—對應場景：測試系統能否處理平均值為300次/秒的告警，測試模型如圖8所示。
圖8
①每個模擬設備進程等待1～20秒的隨機時間，發送5條告警，總的告警頻度為600×5/10=300次/秒，告警持續發送8小時。之所以采用隨機等待的方式，是為了更好地模擬真實的生產環境，使測試結果具有更大的可信度。
②模擬設備進程發送的告警附帶的告警發生時間是運行模擬設備進程的機器當前時間，檢查告警是否在5秒內呈現的方法是在告警呈現應用（PC應用）上直接查看告警的發送時間和實際呈現的時間，比較時間差。
【驗證方法】
通過對比已發送告警和界面上呈現告警、數據庫中的數據來核對數據的準確性，包括：界面呈現告警和實際發送告警的數量、類型是否一致；數據庫中入庫的告警數據與界面呈現告警是否一致。
（3）方案3——對應場景：測試系統能否處理峰值為600次/秒的告警，其測試模型與方案2相同。
①600個模擬設備進程中，200個進程每秒發送2條告警，400個進程隨機等待0～4秒，發送1條告警，總的告警頻度為200×2＋0.5×400=600次/秒，告警持續發送1小時。
②模擬設備進程發送的告警附帶的告警發生時間是運行模擬設備進程的機器當前時間，檢查告警是否在8秒內呈現的方法是在告警呈現應用（PC應用）上直接查看告警的發送時間和實際呈現的時間，比較時間差。
【驗證方法】
通過對比已發送告警和界面上呈現告警、數據庫中的數據來核對數據的準確性，包括：界面呈現告警和實際發送告警的數量、類型是否一致；數據庫中入庫的告警數據與界面呈現告警是否一致。
指點迷津：
在方案2和方案3中，檢查告警是否在規定時間內呈現的方法是在告警呈現應用（PC應用）上直接查看告警的發送時間和實際呈現的時間，比較時間差。但設想一下，在實際操作中，當用戶界面上以每秒300或600次的頻率呈現告警時，要計算出每條告警的實際呈現時間幾乎不可能。
此時可以采用一種被稱為“探針”（Probe）的技術，其原理是：將負載和實際觀察數據分開，選用特殊的便于識別的數據作觀察用。具體在本案例中，可視方案中設定的告警產生為負載，為了知道告警是否在指定時間內得到呈現，在負載之外用一個特殊的模擬設備進程發出特殊的告警，在告警呈現應用中僅計算該特殊告警的呈現時間。
（4）方案4——對應場景：測試系統能否快速響應用戶下發的命令，測試模型如圖8.9所示，其邏輯簡化圖如圖9、10所示。
圖9
圖10
該模型用于測試命令下發和命令結果回顯，根據測試用例的描述，在測試中需要記錄時間點T1、T2、T3、T4。
①模擬200個話務交換機設備，模擬程序能接收用戶下發的交換機命令perftest、lgi并發送回應。
②用模擬程序SimTerm模擬200個終端連接設備，充當負載。該模擬程序以每分鐘一條命令的頻率發送perftest命令。
③實際運行一個命令終端應用，在該應用進程中由用戶手工輸入命令，程序記錄下用戶輸入命令時間等關鍵時間點。
④為了記錄時間T1、T2、T3、T4，有以下約定：
- SimTerm發送的命令附帶發送時的時間戳，一個典型的命令格式為：perftest：2004-09-2015:23:00。
- 終端應用程序在發送命令時，附帶一個用戶輸入命令結束的時間戳，一個典型的命令格式為：igi:2004-09-2015:23:00，這個時間就是我們定義的時間T3。
- 交換機設備模擬程序記錄接收到命令的時間T1，并從接收到的命令中分離出時間T3，記錄T1、T3和T3-T1；交換機設備模擬模擬程序在發送回應的時候在回應的報文中附帶發送時的時間戳（T2）。
- 命令終端程序接收交換機設備模擬程序發送的回應報文，分離并記錄出其中的時間T2、記錄報文回顯完成的時間T4，并計算T4-T2。
⑤持續測試1小時，在1小時中通過命令終端發送命令。
【驗證方法】
T3-T1小于2秒，T4-T2小于2秒。
指點迷津：
方案4中除了應用到上文介紹的探針技術外（方案4同樣將負載和實際觀察響應時間的應用分開），還使用了一種被稱為“時間戳”的技術。時間戳技術一般在需要記錄大量與時間相關的數據時使用，例如在本方案中，需要記錄每條命令的下發時間（T1）、被設備接收到的時間（T3）、設備返回命令的時間（T2）、返回命令被應用呈現的時間（T4）。其中的時間當然可以由各個相關應用寫入本地日志中，但如果采用這種方式，每個應用寫入日志的資源開銷都會非常大，導致性能測試結果出現偏差。時間戳技術則避免每個應用單獨用日志方式記錄時間，而是采用在發送的消息報文中附帶當時的時間的方法，這樣一個經過完整處理的數據報中就帶有每個節點處理時的時間，只需要在其中任意一個應用進行記錄和處理即可（甚至是經最終得到的消息再次轉發，由一個額外的應用記錄和處理時間信息）。相比寫日志的開銷，這種時間戳技術的額外開銷顯然要小得多。
當然，在應用時間戳技術時不得不指出，采用這種方式必然要求各個應用在設計時都考慮這種方法。
（5）方案5——對應場景：測試系統能否穩定運行。
該方案測試系統能否穩定運行，其測試模型是一個綜合模型，采用壓力測試的方法，重點檢查運行過程中系統的各性能計數器值和應用進程的內存使用狀況。
【驗證方法】
各服務器的CPU使用率小于90%，內存使用率小于85%，各應用進程所占用的內存在測試期間沒有明顯變化。
（6）方案6——對應場景：測試系統能否順利實現故障切換，其測試模型是方案1和方案2的測試模型綜合。
①采用模擬程序和應用程序部署整個測試環境，測試環境包括600個模擬的話務交換機設備，以方案1和方案2的條件部署整個環境。
②采用拔網線的方式模擬設備故障，記錄設備故障時間。
③檢查系統能否在5分鐘內完成切換。
【驗證方法】
系統完成切換的標志是告警能重新呈現，話務數據能繼續采集和處理。
4.腳本和輔助工具的開發
腳本和輔助工具的開發需求在上文中進行了詳細的描述。
在測試執行與管理之前的過程和活動中，已經明確規劃了本性能測試的環境、場景和腳本，在本過程中，只需要按照前面階段的要求，將測試場景和腳本進行部署，然后執行測試并記錄結果即可。
1.建立測試環境
建立測試環境就是按照測試設計中設計的環境設計內容部署測試環境，本測試需要進行性能調優測試，因此必須在保證測試基準環境上下工夫。本測試過程中使用了CheckList來檢查具體的數據庫設置和應用服務器設置，并由系統工程師對其進行仔細的調整。
時鐘同步是本案例環境設置的重要內容之一，設置方法的描述如下:
（1）首先選定一臺UNIX服務器作為時鐘源服務器。
（2）在其他的UNIX平臺上，修改//etc/ntp.conf文件，將其時間源服務器設置為選定的源服務器。
（3）在Windows平臺上安裝NetTime工具（//nettime.sourceforge.net），然后運行NetTime程序，按照圖10的描述進行設置（其中的HostnameorIPAddress設置為時鐘源服務器的IP地址）。
進行設置（其中的HostnameorIPAddress設置為時鐘源服務器的IP地址）。
2.部署測試腳本和測試場景
在本案例中，部署測試腳本和測試場景的過程就是在測試環境中部署測試輔助工具和腳本。輔助工具和腳本部署的內容在測試方案中均已經描述，在此不再贅述。
圖11
這里給出一種本案例中采用的部署表描述，讀者可以在自己的工作中使用。為了簡便，此處只給出場景1的場景部署內容，如表10所示。
表10
3.執行測試和記錄結果
在本性能測試中，采用UNIX平臺上的性能計數器數值采集腳本獲取并記錄UNIX服務器上的CPU使用率、Memory使用率等數據，獲取的數據以文本文件方式存在服務器上，對這些文本文件的處理通過Excel工具實現，具體操作在第12章中進行描述。
給定的方案執行完成后，需要對獲得的測試結果和數據進行分析，本節展示對該性能測試進行分析的方法和手段。
1.測試系統能否及時處理完全省交換機的話務數據
模擬設備發送話務報告的部分日志（sendlog.log文件）如下：
圖12
從該日志可以看到，模擬設備按照預期的方式發送話務報告。
在一個話務周期完成后，通過檢查數據是否入庫完整判斷處理和入庫時間的結束，經過檢查，在整個測試期間，最長的入庫時間為41秒，這個結果完全可以滿足預期的性能要求。
關注此時的服務器性能計數器數值，考慮到本業務需要生成大量的本地文件和對本地文件進行讀寫，DiskI/O是一個可能的性能瓶頸，因此首先關注Disk1/O相關的性能計數器值。
以下是采集服務器的部分DiskI/O數據，給出的數據中包含了rps和wps最大的幾組數據（粗體標識的數據）：
圖13
按照本書第3章的內容介紹，計算每磁盤的I/O數（采集服務器使用RAID10方式，共4個磁盤），則計算如下：
最大的每磁盤I/O數＝（112＋2×10.2）/2=66.2
而磁盤標識的I/O處理能力為85，可見磁盤不是采集服務器的性能瓶頸。
再看看采集服務器的CPU和內存使用情況，如圖14和圖15所示。
圖14
圖15
從圖中可以看到，采集服務器的CPU使用率較高，在話務周期到達的一段時間內一直忙于進行話務報告的處理，從獲取的原始數據看，阻塞進程數量僅為1～2個，由此說明CPU使用率高的主要因素是程序自身確實在進行復雜的運算操作，CPU為系統的性能瓶頸之一，可以考慮通過優化算法等改善應用的CPU使用狀況。
內存的使用率很低，稍大于50%。這說明當前的內存配置對應用而言是足夠的，不構成性能瓶頸。
對應用服務器進行了類似的分析，結果表明應用服務器的CPU和內存使用率都在60%以下，因此應用服務器本身也不構成該測試項目的性能瓶頸。
對數據庫的分析稍微復雜一些，在本測試方案中，主要選取了數據庫服務器的CPUUsage、MemUsage、SGAMemUsage和IndexedQuery等性能指標進行監控，如圖16所示。
圖16
從圖16中可以看到，這些值都處在可以接受的水平上，數據庫服務器本身的狀態比較正常。當然，由于系統性能表現比較好，在測試中就沒有深入對使用的SQL語句等進行分析。
2.測試系統能否處理平均值為300次/秒的告警
通過告警呈現應用上顯示的告警時間與實際的告警發出時間進行對比，由于采用了Probe技術，因此只需要統計少數告警消息即可。經過統計，告警從報告發出到呈現的平均時間為3.4秒。該數據說明，系統完全能夠滿足預期的告警性能要求。
除了計算這些特殊設計告警的呈現時間外，還需要驗證測試過程中，是否所有負載告警均己經被正常處理了。因此在驗證該結果時，還需比對Temip實際接收到的告警數量和發出的告警數量是否一致。經過比較，結果完全一致。
隨后是對各服務器的性能計數器數據的分析。表11是用vmstat獲取的應用服務器的部分性能指標。
表11
從表11中可以看到，內存和CPU的使用率都非常低，可見，應用服務器不構成告警業務的性能瓶頸。
3.測試系統能否處理峰值為600次/秒的告警
該項目的測試結果分析與上一方案的測試結果分析類似，在此不再贅述。
對結果的分析表明，系統能夠達到預期的性能要求，且應用服務器不構成性能瓶頸。
4.測試系統能否快速響應用戶下發的命令
通過分析工具對日志進行分析后的結果（部分）如下：
圖17
從分析結果可以看到，T3-T1和T4-T2的時間延遲都非常小，其值接近0。因此，系統完全可以滿足用戶對命令下發時間響應的性能要求。
使用和上幾個方案結果分析類似的方法，對涉及的服務器進行性能分析，結果發現在該測試過程中，相關服務器的性能計數器值都接近低水平。
5.測試系統能否穩定運行
測試系統能否穩定運行，主要方法是：檢查在壓力條件下，系統長期運行是否會出現異常。造成系統不穩定的主要原因在于內存使用、資源不合理使用等，這些都可以從進程占用的內存量、系統運行速度等看出端倪。
在本方案的測試中，設定好運行條件后，系統在壓力條件下運行，此時用腳本監測服務器可用內存以及所有應用的內存使用，如圖18所示是測試過程中發現的采集服務器的可用內存曲線。
圖18給出了一個令人吃驚的結果：采集服務器的可用內存曲線呈現鋸齒狀。剛看到該圖形時，很有些覺得莫名其妙，但在查看其他應用的內存使用狀況時，馬上就恍然大悟了。原來，報告入庫分析程序的開發人員出于習慣，為該進程準備了一個防止進程意外退出的機制——Watchdog，他用一個后臺進程對多個報告入庫分析程序進行管理，一旦發現某個報告入庫分析程序進程退出，該后臺進程就立刻重新裝載一個報告入庫分析程序進程。而剛巧報告入庫分析程序本身存在內存泄漏，在大壓力、長時間的運行條件下，進程的占用內存一直增長，直到系統內存不能再支撐為止，此時進程會被操作系統關閉；但由于Watchdog的存在，進程被關閉后又會立即被重新裝載進來，如此反復，最終造成了采集服務器的可用內存曲線呈現鋸齒狀。
圖18
此外，在壓力測試中出現問題的應用還包括交換機的代理進程，如圖19所示是該進程在測試過程中的內存使用情況。
圖19
從圖19中可以看到，該進程在測試過程中的內存使用占用呈現持續增長的趨勢，這明顯是該進程的內存泄漏所致。后經過對代碼進行分析，該進程確實存在內存泄漏問題，每次建立和釋放一個連接會產生2KB左右的內存泄漏，由于內存泄漏量非常小，如果不通過這種長時間、大壓力的測試，很難發現。
另一個在穩定性測試中發現的問題與資源使用相關。測試完成后檢查各應用的日志時，發現在接入進程的日志中出現了許多“無法打開文件”的錯誤信息，且這些錯誤信息發生在測試開始2天后。由于整個測試過程都采用同樣的壓力條件，因此該問題不太可能由環境引起。后來經過開發人員的定位，該問題產生的原因是接入進程在某種情況下打開文件后沒有及時關閉文件句柄（handle），從而導致在一段時間后無法再打開新的文件。
判斷系統是否能夠穩定運行的另一個指標是測試過程中應用的響應時間或效率是否發生明顯變化，在本測試中，采用方案1和方案2的檢查方法對其進行檢查。當然，在存在內存泄漏的情況下，隨著持續運行時間的增加，系統的業務處理能力明顯變小。
在修正了內存泄漏的問題后，經過再一次測試，發現各服務器的可用內存曲線在整個測試期間沒有明顯變化，各進程占用的內存在整個測試期間也沒有明顯變化，系統的業務處理能力亦沒有發生明顯變化。綜合以上，可以說明，應用在測試的初期存在內存泄漏導致的不穩定隱患，經過修正，系統已經可以滿足預期的穩定性要求。
指點迷津：
對于大型的應用系統來說，穩定性測試一般都是必不可少的。最容易出現的穩定性方面的問題是內存、資源使用方面的問題，前者會導致內存不足或是系統性能表現不穩定（存在GC機制的情況），后者會導致出現一些異常（如應用沒有及時釋放句柄導致無法打開文件等）。
6.測試系統能否順利實現故障切換
根據測試方案的描述，測試系統能否順利實現故障切換的方法比較簡單。由于性能需求中允許部分數據不完整，因此，測試過程只需要關注在指定時間達到后系統能夠正常運行業務即可。
測試結果表明，在5分鐘內業務順利恢復，因此，系統在故障恢復方面能夠滿足預期的性能要求。
該項目是一個較大型的性能測試項目，大量采用自定義通信協議，因此沒有采用商業的性能測試工具，而是在整個項目中采用自行構建性能測試工具的方法。本案例描述的項目具有一定的代表性，可作為對此類項目性能測試的參考。
在本案例的性能測試實現中，采用了探針和時間戳的技術，這兩種技術是性能測試過程中常用的技術，讀者可以自行體會。
本案例涉及的項目的很多模塊都是以后臺進程的方式工作，對其測試往往只能通過日志、時間戳等技術來了解模塊的工作狀態。由于設計的問題，有些開發人員會制造出“既不輸出信息，也不打印日志”的后臺應用，在性能測試過程中，對測試結果進行分析時，涉及到該模塊的結果分析只能是“摸黑”，如果遇到這樣的問題，直接且唯一的方法就是要求開發人員根據測試要求在模塊中加入日志或是其他手段，本案例的性能測試過程就相當得益于應用完整和規整的信息輸出。
當然，要注意的是，為應用模塊添加日志可能會導致應用的性能表現發生變化，對這一副作用一定要認識到。時間戳技術就是對日志的一種替代方法。
本案例的描述進一步明確說明了一個事實：性能測試過程最重要的是分析過程，只要分析工作做得充分，執行工作基本是水到渠成的事情，而分析也很大程度基于設計的完備性。
【注釋】
(1)MOXA設備可以使原本不具備以太網口并分散各地的串行設備通過MOXA設備的轉換，以TCP/IP方式連接到網絡。
(2)為了使圖形更清晰，此圖僅大致給出了可用內存的曲線趨勢，并不完全是實際的數據。
(3)為了使圖形更清晰，此圖僅大致給出了進程內存使用的曲線趨勢，并不完全是實際的數據。
標簽：
性能測試軟件測試技術軟件測試
本站文章除注明轉載外，均為本站原創或翻譯。歡迎任何形式的轉載，但請務必注明出處、不得修改原文相關鏈接，如果存在內容上的異議請郵件反饋至chenjj@ke049m.cn
半島外圍網上直營 
16次
相關產品
正式授權
最新文章 
半島外圍網上直營相關的文章 
微信
在線咨詢
渝公網安備
50010702500608號
客服熱線