• 項目背景
• 項目特點
• 性能測試過程
  • 測試前期準備
  • 測試工具引入
  • 測試計劃
  • 測試設計與開發(fā)
  • 測試執(zhí)行與管理
  • 測試分析
• 案例小結

一、項目背景

該案例是某省電信公司的業(yè)務系統(tǒng)的性能測試。該業(yè)務系統(tǒng)用于管理省電信公司的所有電信交換機設備，業(yè)務系統(tǒng)的重點在于4個方面：從交換機定期獲取并處理話務報告；接收交換機發(fā)出的告警消息；允許用戶通過應用界面對交換機進行操作（發(fā)送命令）；允許其他業(yè)務系統(tǒng)發(fā)送的交換機操作要求通過網(wǎng)關的處理后轉(zhuǎn)換成相應的交換機命令并下發(fā)。

由于該業(yè)務系統(tǒng)是電信運營商的核心支撐業(yè)務系統(tǒng)，因此用戶對該系統(tǒng)的穩(wěn)定性非常關注，要求系統(tǒng)能夠7×24小時不間斷運行，在最終決定的系統(tǒng)方案中，也為該系統(tǒng)的采集服務器進行了N+1的冗余配置，為應用服務器和數(shù)據(jù)庫服務器進行了1+1的冗余配置。

對業(yè)務系統(tǒng)的性能測試是在開發(fā)接近完成時進行的，主要目的包括幾個方面：驗證系統(tǒng)是否達到了預期的性能指標；驗證系統(tǒng)是否能穩(wěn)定運行；驗證系統(tǒng)的失效恢復方案是否有效；在測試過程中有針對性的進行部分調(diào)優(yōu)工作，以保證系統(tǒng)能夠達到預期的性能要求。

二、項目特點

該項目的最大特點是選用的架構復雜，使用的協(xié)議基本上都是基于TCP/IP的自定義協(xié)議。該業(yè)務系統(tǒng)需要使用多種中間平臺，所以架構設計為一個復雜的分層結構。另一方面，應用各模塊之間的通信方式也比較復雜，考慮到與其他系統(tǒng)的接口，該業(yè)務系統(tǒng)采用了多種基于TCP/IP的自定義協(xié)議。

對性能測試來說，本系統(tǒng)的一個重要特點是系統(tǒng)涉及較多的外部設備（交換機等），而這些設備由于是用戶的實際生產(chǎn)設備，不可能按照測試的要求對其進行設置和操作，必須通過一定的手段來模擬這些外部設備。

該系統(tǒng)的另一個特點是性能測試關注的內(nèi)容中交互界面很少，除了用戶下發(fā)命令外，其他的性能測試關注內(nèi)容都沒有人工交互的干預，因此，測試中對系統(tǒng)性能的體現(xiàn)主要是業(yè)務處理能力，只在用戶下發(fā)命令這一個方面用響應時間來描述系統(tǒng)性能表現(xiàn)。

圖1簡單描述了該業(yè)務系統(tǒng)。

圖1

從圖1中可以看到，該業(yè)務系統(tǒng)是一個全省集中的處理系統(tǒng)，系統(tǒng)管理的話務交換機設備通過MOXA設備(1)轉(zhuǎn)接或是直接通過省電信公司的網(wǎng)絡傳輸?shù)脑拕战粨Q機設備通過MOXA到省電信中心的中心機房，所有服務器都放置在中心機房，通過網(wǎng)絡交換設備進入電信公司的網(wǎng)絡。為了保證系統(tǒng)的穩(wěn)定運行，將服務器進行了分組管理，每組都設置了一臺設備進行熱備份。

由于這里給出的話務交換機設備都是實際在網(wǎng)運行的設備，因此，在實際的測試中，不可能利用這些實際的話務交換機設備進行測試。本業(yè)務系統(tǒng)管理的話務交換機數(shù)量較多，在全省規(guī)模下，有600臺左右的實際設備。

此外，該性能測試的部分性能目標在需求和設計中進行了明確的定義，性能測試目標的確定可以通過對需求和設計的分析獲取，這也是本案例的重要特點之一。

三、性能測試過程

本節(jié)描述性能測試的全過程，根據(jù)本書第5章的性能測試過程描述，按照PTGM模型分別對性能測試的各階段進行闡述。

測試前期準備

在了解該項目的基本狀況之后，首先開始測試前期準備工作。

1、系統(tǒng)基礎功能驗證

本案例中描述的性能測試安排在功能驗收測試之后，因此在性能測試中不需要額外安排基礎功能驗證。

2、組建測試團隊

根據(jù)該項目的具體情況，建立一個7人的團隊負責本次測試工作。團隊的7個成員中，1名是數(shù)據(jù)庫工程師，1名是系統(tǒng)工程師，3名是性能測試設計和分析人員，2名是性能測試開發(fā)和實施人員。

在測試開始之前，已經(jīng)預計到該系統(tǒng)的性能測試可能需要投入較大力量進行測試方案設計，其次還需要自行實現(xiàn)部分測試工具，因此，安排了3名性能測試設計和分析人員與2名性能測試開發(fā)和實施人員。

3、測試工具需求確認

考慮到系統(tǒng)測試的要求，該系統(tǒng)面臨的最大問題在于需要模擬現(xiàn)有設備和系統(tǒng)使用的協(xié)議多，因此，綜合項目的狀況，最終確定的測試工具需求如下：

• 支持TCP/IP協(xié)議層上的測試。
• 能夠方便地模擬現(xiàn)有設備，由于我們關注的是現(xiàn)有設備的定時發(fā)送報告、不定時發(fā)送告警和接受下發(fā)命令（包括用戶和其他業(yè)務系統(tǒng)下發(fā)命令），因此對設備的模擬至少需要包括能定期發(fā)送指定數(shù)據(jù)、能隨機發(fā)送指定數(shù)據(jù)并滿足一定的頻度要求、能接受命令并給出響應。
• 能夠記錄每個操作消耗的時間，便于進行性能分析。
• 考慮到用戶的穩(wěn)定性要求，工具要求能夠監(jiān)控系統(tǒng)是否穩(wěn)定。

4、性能預備測試

性能預備測試用于對系統(tǒng)建立直觀的認識，我們安排接入少量設備，并對少量設備接入后的系統(tǒng)運行進行體驗，體驗結果表明，在少量設備接入的情況下，系統(tǒng)能夠順利地完成話務報告數(shù)據(jù)處理，能夠在3秒之之內(nèi)將設備產(chǎn)生的告警呈現(xiàn)在系統(tǒng)界面上。

測試工具引入

測試工具的引入對本案例來說是一個比較重要的過程。

根據(jù)測試前期準備確定的測試工具需求可以發(fā)現(xiàn)，在目前市面上的商業(yè)工具中幾乎沒有工具可以完全滿足這些需求，因此經(jīng)過討論，最終將測試工具的引入方式定位在“創(chuàng)建”上，即完全自行開發(fā)需要的測試工具。

對測試工具的需求再次進行分析和分解，從模擬設備程序、記錄程序和壓力工具3個方面來考慮，形成了本案例需要的工具列表，如表1、2所示。

表1

表2

細心的讀者應該能注意到，上表的測試工具中，前兩個工具都要求能夠在Windows和UNIX平臺上運行，之所以這樣要求，是因為我們希望能夠充分利用設備資源。

表中的“模擬設備”的前兩個測試工具最終用Perl實現(xiàn)，這樣可以方便實現(xiàn)跨平臺；后一個測試工具用C語言實現(xiàn)，因為該工具對程序效率要求較高。

測試計劃

測試計劃階段需要分析用戶活動，確定系統(tǒng)的性能目標。

1、性能測試領域分析

根據(jù)對項目背景的了解，本性能測試要解決的主要問題問題包括：驗證系統(tǒng)是否達到了預期的性能指標、驗證系統(tǒng)是否能穩(wěn)定運行、驗證系統(tǒng)的失效恢復方案是否有效以及在測試過程中有針對性的進行部分調(diào)優(yōu)工作，以保證系統(tǒng)能夠達到預期的性能要求。

這些內(nèi)容涵蓋了第2章中給出的能力驗證、性能調(diào)優(yōu)兩個應用領域。進一步根據(jù)第2章的內(nèi)容，本測試可用的性能測試方法為除ConcurrencyTesting外的其他性能測試方法。

2、用戶活動剖析與業(yè)務建模

在本案例中，用戶活動主要通過話務交換機的行為來體現(xiàn)，因此，本活動的主要內(nèi)容集中在為應用建模上。

通過對話務交換機的行為進行抽象，可以得到一個簡化的話務交換機模型。就本案例關注的交換機功能，簡化后的話務交換機模型如圖2所示。

圖2

對本案例的業(yè)務系統(tǒng)來說，交換機可以簡化成具有3個端口的設備，這3個端口分別是話務口、告警口和操作口。

(1)話務口

話務口可被看作一個TCP/IP端口，該端口等待連接，在給定的話務周期到達時，向所有連接在該端口上的連接發(fā)送話務報告，話務報告以二進制數(shù)據(jù)流方式發(fā)送，不同交換機的話務報告格式和數(shù)據(jù)量均不不同。

(2)告警口

告警口可被看作一個TCP/IP端口，該端口等待連接，在交換機內(nèi)部發(fā)生故障或錯誤時，向所有連接在該端口上的連接發(fā)送告警報告，告警報告以二進制數(shù)據(jù)流方式發(fā)送，不同交換機的告警報告格式和數(shù)量均不同。

(3)操作口

操作口可被看作一個向其發(fā)送具有一定格TCP/IP端口，該端口等待連接，連接上該端口的連接可以式的命令，當命令格式正確時，交換機執(zhí)行命令請求的操作并以二進制數(shù)據(jù)流方式返回結果。

因為這3個端口之間沒有直接的關聯(lián)，因此，采用表1描述的測試工具可以完全模擬圖2給出的話務交換機簡化模型。

對本案例而言，需要進行性能測試的業(yè)務系統(tǒng)需要連接這3種不同的端口，并對下發(fā)和接收到的數(shù)據(jù)進行處理，業(yè)務系統(tǒng)的處理方式有以下4種。

（1）話務報告處理

話務報告處理過程從系統(tǒng)接收到話務數(shù)據(jù)流開始，接收到數(shù)據(jù)后先進行初步分析（分離報告），將報告形成文本文件保存在本地，同時向消息隊列中發(fā)送一個消息。

分析進程阻塞消息隊列，當在消息隊列中發(fā)現(xiàn)消息后就取出該消息并按照消息指示對本地文件進行處理。對本地文件的處理是從文件中分析出數(shù)據(jù)并寫入數(shù)據(jù)表的相應字段。

該業(yè)務系統(tǒng)的話務報告處理過程如圖3所示。

圖3

（2）告警報告處理

告警報告的處理過程從系統(tǒng)接收到告警數(shù)據(jù)流開始，在該業(yè)務系統(tǒng)中，告警數(shù)據(jù)直接由HP的Temip平臺進行處理，告警數(shù)據(jù)流直接發(fā)送給Temip平臺。通過一個入庫進程，告警數(shù)據(jù)在處理后進入數(shù)據(jù)庫。告警報告的處理過程如圖4所示。

圖4

（3）用戶操作處理

用戶操作的處理過程從用戶下發(fā)交換機命令開始，用戶通過一個被稱為“仿真終端”的應用向交換機發(fā)送命令，通過一個連接交換機代理程序?qū)⒚钆抨犔幚砗蟀l(fā)送給交換機。用戶操作的處理過程如圖5所示。

圖5

（4）其他業(yè)務系統(tǒng)操作處理

其他業(yè)務系統(tǒng)的操作處理從其他業(yè)務系統(tǒng)發(fā)送消息開始，通過一個業(yè)務接口程序，將其他業(yè)務系統(tǒng)發(fā)送的消息分析形成交換機命令，通過連接交換機的代理程序?qū)⒚钆湃朊铌犃羞M行處理，如圖6所示。

圖6

3.確定性能目標

本性能測試的應用領域已被確定為能力驗證和性能調(diào)優(yōu)，因此在確定性能目標時，應該圍繞這兩個方面進行。

本項目是一個開發(fā)項目，需求和設計中已經(jīng)對部分性能目標進行了定義。在本案例中，從需求和設計中得到的與性能相關的描述包括。

（1）系統(tǒng)能夠及時處理完全省交換機的話務數(shù)據(jù)。

（2）系統(tǒng)能夠處理平均值為300次/秒的告警，能夠承受峰值為600次/秒的告警。

（3）系統(tǒng)能夠快速響應用戶下發(fā)的命令。

（4）系統(tǒng)能夠及時處理其他業(yè)務系統(tǒng)發(fā)送的交換機操作消息。

（5）系統(tǒng)能夠穩(wěn)定運行。

（6）系統(tǒng)能夠在一臺采集服務器、一臺應用服務器和一臺數(shù)據(jù)庫服務器由于特殊原因崩潰時不間斷運行。

在這些描述中，除了第（1）、（2）、（6）條是比較清晰的性能需求描述外，其他3條都是非明確的性能需求。而且，即使是第（1）、（2）條，也同樣需要進一步的確認。為此，在該活動中，性能測試組通過與項目經(jīng)理和客戶的多次溝通，對性能測試需求進行了更加明確的確認。

（1）系統(tǒng)能夠及時處理完全省交換機的話務數(shù)據(jù)：該業(yè)務系統(tǒng)接入的全省話務交換機數(shù)量為600臺，其中約20%的交換機話務周期設置為15分鐘，這部分交換機的話務報告平均大小約為4KB；約有30%的交換機話務周期設置為30分鐘，這部分交換機的話務報告平均大小約為6KB；約50%的交換機話務周期設置為1小時，這部分交換機的話務報告平均大小為7KB。

（2）系統(tǒng)能夠處理平均值為300次/秒的告警，能夠承受峰值為600次/秒的告警：該業(yè)務系統(tǒng)接入的交換機數(shù)量為600臺，300次/秒的告警發(fā)生頻率相當于每臺交換機每秒發(fā)生0.5次告警，考慮到各交換機具有不同的告警發(fā)生頻率，經(jīng)過對現(xiàn)網(wǎng)運行系統(tǒng)一周數(shù)據(jù)的分析表明，發(fā)生告警最多的設備大約每秒發(fā)生2次，發(fā)生告警最少的設備大約每小時發(fā)生2次，差別巨大。并且，用戶實際還有一個并未在需求文檔中給出的隱含要求：告警從產(chǎn)生到呈現(xiàn)的時間延遲小于5秒。

（3）系統(tǒng)能夠快速響應用戶下發(fā)的命令：經(jīng)過與用戶的確定，“快速”被重新定義為用戶下發(fā)命令與在沒有命令排隊的情況下，交換機接收到命令的延時不得大于2秒，交換機反饋信息與用戶接收到反饋信息的延時不得大于2秒。而且，明確的并發(fā)用戶數(shù)量為100名。

（4）系統(tǒng)能夠及時處理其他業(yè)務系統(tǒng)發(fā)送的交換機操作消息：經(jīng)過與用戶的溝通，用戶對該業(yè)務系統(tǒng)的要求實際上是系統(tǒng)不能丟失其他業(yè)務系統(tǒng)發(fā)送的交換機操作消息，因此該需求實際描述的是系統(tǒng)的命令緩存能力，最終該需求被描述為：系統(tǒng)能夠緩存1000條其他業(yè)務系統(tǒng)發(fā)送的消息不再接受新的消息并返回給發(fā)送消息的業(yè)務系統(tǒng)一個錯誤信息，當緩存區(qū)滿時，。經(jīng)過這樣的分析，該需求變成了一個功能的需求，不再需要在功能測試中體現(xiàn)。

（5）系統(tǒng)能夠穩(wěn)定運行：該需求最終被表述成系統(tǒng)在壓力下的性能表現(xiàn)，根據(jù)其他可參考的系統(tǒng)穩(wěn)定性依據(jù)，該需求被描述為系統(tǒng)能夠在比穩(wěn)定運行時大2倍的壓力條件下持續(xù)運行14天，期間各應用進程占用的內(nèi)存及應用響應速度都不會發(fā)生明顯變化。

（6）系統(tǒng)能夠在一臺采集服務器、一臺應用服務器和一臺數(shù)據(jù)庫服務器由于特殊原因崩潰時不間斷運行：對該需求的一個補充是，由服務器失效引發(fā)的切換必然會使正在進行的業(yè)務收到影響，因此，允許切換過程中產(chǎn)生不完整的數(shù)據(jù)。另外，應用的切換必然存在一個切換時間，商定的允許切換時間為5分鐘。

表3給出了分析整理后的性能需求描述。

表3

對能力驗證應用領域來說，本測試需要重點關注的是業(yè)務的響應時間、各服務器的資源使用狀況，結合性能測試需求，性能目標可以定義如下：

• 在滿足全省話務數(shù)據(jù)規(guī)模的情況下，服務器CPU平均使用率不高于75%，內(nèi)存使用率不高于75%。
• 在平均告警規(guī)模下，服務器CPU平均使用率不高于75%，內(nèi)存使用率不高于75%；峰值情況下，服務器CPU平均使用率不高于90%，內(nèi)存使用率不高于85%。
• 沒有命令排隊情況下，交換機接收到命令的延時小于2秒，用戶接收到反饋信息的延時小于2秒。
• 各組單臺設備故障時，系統(tǒng)切換時間不大于5分鐘，切換后業(yè)務如常進行。

對性能調(diào)優(yōu)應用領域來說，本測試關注的重點是通過各種設置和部署的調(diào)整（原則是：除非確定是應用問題，否則優(yōu)先考慮調(diào)整設置和部署方法），使系統(tǒng)性能表現(xiàn)能夠達到預期的要求。

4.制定測試時間計劃

本案例的特點之一在于測試中使用的大部分測試工具都是自行開發(fā)的，因此必須留出較多的時間進行工具的設計和開發(fā)。另外，由于系統(tǒng)本身的復雜性，測試環(huán)境構建也需要一定的時間。本案例的測試時間計劃安排如表4、5所示。

表4

表5

測試設計與開發(fā)

測試設計與開發(fā)包括測試環(huán)境設計、測試場景設計、測試用例設計和測試輔助工具開發(fā)多個活動。對類似本案例的業(yè)務系統(tǒng)而言，測試場景關注的主要內(nèi)容不是用戶感受，而是系統(tǒng)的業(yè)務處理能力，因此在測試場景設計上，注重的是通過何種方式獲取和性能相關的數(shù)據(jù)及如何對獲取的數(shù)據(jù)進行解釋。

1.測試環(huán)境設計

本性能測試需要驗證系統(tǒng)在實際生產(chǎn)部署環(huán)境上的性能，因此，盡可能選擇接近實際生產(chǎn)環(huán)境的環(huán)境來進行測試。

該項目測試的一個特點是需要通過模擬手段來模擬實際的話務交換機設備，結合前文中建立的話務交換測試模型，和圖1給出的系統(tǒng)示意圖，最終確定的測試環(huán)境包括預計用于實際運行的全部服務器條件，通過工具模擬的話務交換機運行于中心機房的PC機和非測試用服務器上。

這個測試環(huán)境與實際環(huán)境之間唯一的差異在于：系統(tǒng)接入的話務交換機不是真正的設備。對本系統(tǒng)來說，可能存在以下風險：

（1）因為報告?zhèn)鬏斔俣炔煌?，可能導致測試結果上出現(xiàn)不同。

（2）實際設備可能發(fā)出不完整報告，而模擬的設備不會，兩者之間存在的差異可能導致性能測試的結果不正確。

當然，這兩個風險在一定條件下可以解決，在本案例中，通過約束和分析解決了這兩個風險：對第1個風險，根據(jù)對各不同地市的不同機型交換機傳輸速度的調(diào)查，最慢的交換機（通過MOXA轉(zhuǎn)接方式）也可以在2分鐘內(nèi)完成所有報告的傳輸，而且這些慢速傳輸?shù)慕粨Q機的話務報告周期都設置為1小時；對第2個風險，實際設備發(fā)出的不完整報告會被接入進程丟棄，在性能測試過程中只要能驗證不完整報告不會對接入進行的性能造成顯著影響即可。

表6

表7

本案例中的測試數(shù)據(jù)環(huán)境設計根據(jù)系統(tǒng)的運行預期來確定。該系統(tǒng)的數(shù)據(jù)備份清除原則是：系統(tǒng)數(shù)據(jù)每3個月進行一次備份和清除操作，每次清除操作將數(shù)據(jù)庫中兩個月以前的業(yè)務數(shù)據(jù)全部清除。

從以上的描述可以看出，系統(tǒng)在穩(wěn)定運行后，數(shù)據(jù)庫中的業(yè)務數(shù)據(jù)至多保留3個月，最少兩個月，為了考察性能表現(xiàn)，我們以3個月的業(yè)務數(shù)據(jù)作為數(shù)據(jù)庫中數(shù)據(jù)的基準。

采用類似第一個案例的計算方法，計算得出的數(shù)據(jù)庫中歷史數(shù)據(jù)環(huán)境如下：

話務數(shù)據(jù)表：19440000條記錄。

告警數(shù)據(jù)表：2120000條記錄。

為了保證數(shù)據(jù)環(huán)境在每次測試中保持一致，首次生成數(shù)據(jù)記錄后，將數(shù)據(jù)庫輸入（export）為本地文件并保存，在每次測試開始前，都通過輸入（import）方法將數(shù)據(jù)直接導入到數(shù)據(jù)庫，保證數(shù)據(jù)環(huán)境的一致。

另一方面，由于本性能測試使用的測試工具多且分散，在實際測試中將工具的啟動形成shell腳本或是bat文件，以具有意義的名稱進行管理。

另一個需要設計的是時間同步方案。本案例中需要記錄的測試結果數(shù)據(jù)很多，部分數(shù)據(jù)的處理需要根據(jù)記錄時的時間進行，而根據(jù)測試環(huán)境，應用部署較為分散，因此有必要為整個測試環(huán)境設計一個時間同步方案，以使整個測試環(huán)境中的各臺設備具有精確一致的時間。

本案例涉及的是一個UNIX和Windows的混合環(huán)境，因此采用ntp協(xié)議進行各設備之間的時間同步。

2.測試場景設計

根據(jù)表2、3，可以很容易地為該案例給出需要的測試場景，如表8、9所示，其中每個場景對應一個測試需求。

表8

表9

由表8、9看出，只要按照場景名稱、場景業(yè)務及比例分配、測試指標、性能計數(shù)器的描述方式，就可以非常清晰地對場景進行描述。

3.測試用例設計

確定測試場景之后，在原有的業(yè)務操作描述上，可以更進一步完善為可映射為腳本的測試用例描述。如果測試過程中需要較多的輔助工具進行協(xié)作，在用例設計中可能還需要描述工具部署情況。

在本案例中，用例設計的主要考慮內(nèi)容是如何獲得與系統(tǒng)性能相關的數(shù)據(jù)，因此在本案例的測試用例設計描述過程中，我們設計了6個對應測試場景的方案。方案采用測試模型、測試說明、測試用例概述的方式進行描述。

（1）方案1——對應場景。測試系統(tǒng)能否及時處理完全省交換機的話務數(shù)據(jù)，測試模型如圖7所示。

圖7

①測試過程中采用600個模擬交換機設備發(fā)送話務數(shù)據(jù)，120個模擬的5ESS設備，話務周期為15分鐘，話務報告為4KB；180個模擬的Siemens設備，話務周期為30分鐘，話務報告為6KB；300個模擬的Ericsson設備，話務周期為1小時，話務報告為8KB；600個模擬設備的進程分布在15臺測試機上，每臺測試機運行40個模擬設備的進程。

②測試過程中，采用3臺采集機，每臺采集機上運行一個接入進程和6個處理入庫進程。之所以用6個處理入庫進程，是因為采集服務器設備有6個CPU，6個進程可以最大限度地提高處理效率。

③為了記錄話務數(shù)據(jù)處理過程中的各個時間點（模型中的T1、T2、T3標識），約定如下：

• 在模擬設備程序目錄下的sendlog.log文件記錄發(fā)送出話務數(shù)據(jù)的時間戳和局號。
• 接入程序的日志記錄該程序發(fā)送的消息等內(nèi)容，文件存放在采集服務器的/opt/mytest/data/目錄下。
• 分析入庫程序的日志位于采集服務器的/opt/mytest/log/plog目錄下。該程序的日志內(nèi)容包含接收消息的時間、處理的時間以及數(shù)據(jù)入庫時間。

【驗證方法】

以最后一個報告已入庫的時間作為全部報告的入庫結束時間，該時間提前于下一話務周期。

（2）方案2—對應場景：測試系統(tǒng)能否處理平均值為300次/秒的告警，測試模型如圖8所示。

圖8

①每個模擬設備進程等待1～20秒的隨機時間，發(fā)送5條告警，總的告警頻度為600×5/10=300次/秒，告警持續(xù)發(fā)送8小時。之所以采用隨機等待的方式，是為了更好地模擬真實的生產(chǎn)環(huán)境，使測試結果具有更大的可信度。

②模擬設備進程發(fā)送的告警附帶的告警發(fā)生時間是運行模擬設備進程的機器當前時間，檢查告警是否在5秒內(nèi)呈現(xiàn)的方法是在告警呈現(xiàn)應用（PC應用）上直接查看告警的發(fā)送時間和實際呈現(xiàn)的時間，比較時間差。

【驗證方法】

通過對比已發(fā)送告警和界面上呈現(xiàn)告警、數(shù)據(jù)庫中的數(shù)據(jù)來核對數(shù)據(jù)的準確性，包括：界面呈現(xiàn)告警和實際發(fā)送告警的數(shù)量、類型是否一致；數(shù)據(jù)庫中入庫的告警數(shù)據(jù)與界面呈現(xiàn)告警是否一致。

（3）方案3——對應場景：測試系統(tǒng)能否處理峰值為600次/秒的告警，其測試模型與方案2相同。

①600個模擬設備進程中，200個進程每秒發(fā)送2條告警，400個進程隨機等待0～4秒，發(fā)送1條告警，總的告警頻度為200×2＋0.5×400=600次/秒，告警持續(xù)發(fā)送1小時。

②模擬設備進程發(fā)送的告警附帶的告警發(fā)生時間是運行模擬設備進程的機器當前時間，檢查告警是否在8秒內(nèi)呈現(xiàn)的方法是在告警呈現(xiàn)應用（PC應用）上直接查看告警的發(fā)送時間和實際呈現(xiàn)的時間，比較時間差。

【驗證方法】

通過對比已發(fā)送告警和界面上呈現(xiàn)告警、數(shù)據(jù)庫中的數(shù)據(jù)來核對數(shù)據(jù)的準確性，包括：界面呈現(xiàn)告警和實際發(fā)送告警的數(shù)量、類型是否一致；數(shù)據(jù)庫中入庫的告警數(shù)據(jù)與界面呈現(xiàn)告警是否一致。

（4）方案4——對應場景：測試系統(tǒng)能否快速響應用戶下發(fā)的命令，測試模型如圖8.9所示，其邏輯簡化圖如圖9、10所示。

圖9

圖10

該模型用于測試命令下發(fā)和命令結果回顯，根據(jù)測試用例的描述，在測試中需要記錄時間點T1、T2、T3、T4。

①模擬200個話務交換機設備，模擬程序能接收用戶下發(fā)的交換機命令perftest、lgi并發(fā)送回應。

②用模擬程序SimTerm模擬200個終端連接設備，充當負載。該模擬程序以每分鐘一條命令的頻率發(fā)送perftest命令。

③實際運行一個命令終端應用，在該應用進程中由用戶手工輸入命令，程序記錄下用戶輸入命令時間等關鍵時間點。

④為了記錄時間T1、T2、T3、T4，有以下約定：

• SimTerm發(fā)送的命令附帶發(fā)送時的時間戳，一個典型的命令格式為：perftest：2004-09-2015:23:00。
• 終端應用程序在發(fā)送命令時，附帶一個用戶輸入命令結束的時間戳，一個典型的命令格式為：igi:2004-09-2015:23:00，這個時間就是我們定義的時間T3。
• 交換機設備模擬程序記錄接收到命令的時間T1，并從接收到的命令中分離出時間T3，記錄T1、T3和T3-T1；交換機設備模擬模擬程序在發(fā)送回應的時候在回應的報文中附帶發(fā)送時的時間戳（T2）。
• 命令終端程序接收交換機設備模擬程序發(fā)送的回應報文，分離并記錄出其中的時間T2、記錄報文回顯完成的時間T4，并計算T4-T2。

⑤持續(xù)測試1小時，在1小時中通過命令終端發(fā)送命令。

【驗證方法】

T3-T1小于2秒，T4-T2小于2秒。

（5）方案5——對應場景：測試系統(tǒng)能否穩(wěn)定運行。

該方案測試系統(tǒng)能否穩(wěn)定運行，其測試模型是一個綜合模型，采用壓力測試的方法，重點檢查運行過程中系統(tǒng)的各性能計數(shù)器值和應用進程的內(nèi)存使用狀況。

【驗證方法】

各服務器的CPU使用率小于90%，內(nèi)存使用率小于85%，各應用進程所占用的內(nèi)存在測試期間沒有明顯變化。

（6）方案6——對應場景：測試系統(tǒng)能否順利實現(xiàn)故障切換，其測試模型是方案1和方案2的測試模型綜合。

①采用模擬程序和應用程序部署整個測試環(huán)境，測試環(huán)境包括600個模擬的話務交換機設備，以方案1和方案2的條件部署整個環(huán)境。

②采用拔網(wǎng)線的方式模擬設備故障，記錄設備故障時間。

③檢查系統(tǒng)能否在5分鐘內(nèi)完成切換。

【驗證方法】

系統(tǒng)完成切換的標志是告警能重新呈現(xiàn)，話務數(shù)據(jù)能繼續(xù)采集和處理。

4.腳本和輔助工具的開發(fā)

腳本和輔助工具的開發(fā)需求在上文中進行了詳細的描述。

測試執(zhí)行與管理

在測試執(zhí)行與管理之前的過程和活動中，已經(jīng)明確規(guī)劃了本性能測試的環(huán)境、場景和腳本，在本過程中，只需要按照前面階段的要求，將測試場景和腳本進行部署，然后執(zhí)行測試并記錄結果即可。

1.建立測試環(huán)境

建立測試環(huán)境就是按照測試設計中設計的環(huán)境設計內(nèi)容部署測試環(huán)境，本測試需要進行性能調(diào)優(yōu)測試，因此必須在保證測試基準環(huán)境上下工夫。本測試過程中使用了CheckList來檢查具體的數(shù)據(jù)庫設置和應用服務器設置，并由系統(tǒng)工程師對其進行仔細的調(diào)整。

時鐘同步是本案例環(huán)境設置的重要內(nèi)容之一，設置方法的描述如下:

（1）首先選定一臺UNIX服務器作為時鐘源服務器。

（2）在其他的UNIX平臺上，修改//etc/ntp.conf文件，將其時間源服務器設置為選定的源服務器。

（3）在Windows平臺上安裝NetTime工具（//nettime.sourceforge.net），然后運行NetTime程序，按照圖10的描述進行設置（其中的HostnameorIPAddress設置為時鐘源服務器的IP地址）。

進行設置（其中的HostnameorIPAddress設置為時鐘源服務器的IP地址）。

2.部署測試腳本和測試場景

在本案例中，部署測試腳本和測試場景的過程就是在測試環(huán)境中部署測試輔助工具和腳本。輔助工具和腳本部署的內(nèi)容在測試方案中均已經(jīng)描述，在此不再贅述。

圖11

這里給出一種本案例中采用的部署表描述，讀者可以在自己的工作中使用。為了簡便，此處只給出場景1的場景部署內(nèi)容，如表10所示。

表10

3.執(zhí)行測試和記錄結果

在本性能測試中，采用UNIX平臺上的性能計數(shù)器數(shù)值采集腳本獲取并記錄UNIX服務器上的CPU使用率、Memory使用率等數(shù)據(jù)，獲取的數(shù)據(jù)以文本文件方式存在服務器上，對這些文本文件的處理通過Excel工具實現(xiàn)，具體操作在第12章中進行描述。

測試分析

給定的方案執(zhí)行完成后，需要對獲得的測試結果和數(shù)據(jù)進行分析，本節(jié)展示對該性能測試進行分析的方法和手段。

1.測試系統(tǒng)能否及時處理完全省交換機的話務數(shù)據(jù)

模擬設備發(fā)送話務報告的部分日志（sendlog.log文件）如下：

圖12

從該日志可以看到，模擬設備按照預期的方式發(fā)送話務報告。

在一個話務周期完成后，通過檢查數(shù)據(jù)是否入庫完整判斷處理和入庫時間的結束，經(jīng)過檢查，在整個測試期間，最長的入庫時間為41秒，這個結果完全可以滿足預期的性能要求。

關注此時的服務器性能計數(shù)器數(shù)值，考慮到本業(yè)務需要生成大量的本地文件和對本地文件進行讀寫，DiskI/O是一個可能的性能瓶頸，因此首先關注Disk1/O相關的性能計數(shù)器值。

以下是采集服務器的部分DiskI/O數(shù)據(jù)，給出的數(shù)據(jù)中包含了rps和wps最大的幾組數(shù)據(jù)（粗體標識的數(shù)據(jù)）：

圖13

按照本書第3章的內(nèi)容介紹，計算每磁盤的I/O數(shù)（采集服務器使用RAID10方式，共4個磁盤），則計算如下：

最大的每磁盤I/O數(shù)＝（112＋2×10.2）/2=66.2

而磁盤標識的I/O處理能力為85，可見磁盤不是采集服務器的性能瓶頸。

再看看采集服務器的CPU和內(nèi)存使用情況，如圖14和圖15所示。

圖14

圖15

從圖中可以看到，采集服務器的CPU使用率較高，在話務周期到達的一段時間內(nèi)一直忙于進行話務報告的處理，從獲取的原始數(shù)據(jù)看，阻塞進程數(shù)量僅為1～2個，由此說明CPU使用率高的主要因素是程序自身確實在進行復雜的運算操作，CPU為系統(tǒng)的性能瓶頸之一，可以考慮通過優(yōu)化算法等改善應用的CPU使用狀況。

內(nèi)存的使用率很低，稍大于50%。這說明當前的內(nèi)存配置對應用而言是足夠的，不構成性能瓶頸。

對應用服務器進行了類似的分析，結果表明應用服務器的CPU和內(nèi)存使用率都在60%以下，因此應用服務器本身也不構成該測試項目的性能瓶頸。

對數(shù)據(jù)庫的分析稍微復雜一些，在本測試方案中，主要選取了數(shù)據(jù)庫服務器的CPUUsage、MemUsage、SGAMemUsage和IndexedQuery等性能指標進行監(jiān)控，如圖16所示。

圖16

從圖16中可以看到，這些值都處在可以接受的水平上，數(shù)據(jù)庫服務器本身的狀態(tài)比較正常。當然，由于系統(tǒng)性能表現(xiàn)比較好，在測試中就沒有深入對使用的SQL語句等進行分析。

2.測試系統(tǒng)能否處理平均值為300次/秒的告警

通過告警呈現(xiàn)應用上顯示的告警時間與實際的告警發(fā)出時間進行對比，由于采用了Probe技術，因此只需要統(tǒng)計少數(shù)告警消息即可。經(jīng)過統(tǒng)計，告警從報告發(fā)出到呈現(xiàn)的平均時間為3.4秒。該數(shù)據(jù)說明，系統(tǒng)完全能夠滿足預期的告警性能要求。

除了計算這些特殊設計告警的呈現(xiàn)時間外，還需要驗證測試過程中，是否所有負載告警均己經(jīng)被正常處理了。因此在驗證該結果時，還需比對Temip實際接收到的告警數(shù)量和發(fā)出的告警數(shù)量是否一致。經(jīng)過比較，結果完全一致。

隨后是對各服務器的性能計數(shù)器數(shù)據(jù)的分析。表11是用vmstat獲取的應用服務器的部分性能指標。

表11

從表11中可以看到，內(nèi)存和CPU的使用率都非常低，可見，應用服務器不構成告警業(yè)務的性能瓶頸。

3.測試系統(tǒng)能否處理峰值為600次/秒的告警

該項目的測試結果分析與上一方案的測試結果分析類似，在此不再贅述。

對結果的分析表明，系統(tǒng)能夠達到預期的性能要求，且應用服務器不構成性能瓶頸。

4.測試系統(tǒng)能否快速響應用戶下發(fā)的命令

通過分析工具對日志進行分析后的結果（部分）如下：

圖17

從分析結果可以看到，T3-T1和T4-T2的時間延遲都非常小，其值接近0。因此，系統(tǒng)完全可以滿足用戶對命令下發(fā)時間響應的性能要求。

使用和上幾個方案結果分析類似的方法，對涉及的服務器進行性能分析，結果發(fā)現(xiàn)在該測試過程中，相關服務器的性能計數(shù)器值都接近低水平。

5.測試系統(tǒng)能否穩(wěn)定運行

測試系統(tǒng)能否穩(wěn)定運行，主要方法是：檢查在壓力條件下，系統(tǒng)長期運行是否會出現(xiàn)異常。造成系統(tǒng)不穩(wěn)定的主要原因在于內(nèi)存使用、資源不合理使用等，這些都可以從進程占用的內(nèi)存量、系統(tǒng)運行速度等看出端倪。

在本方案的測試中，設定好運行條件后，系統(tǒng)在壓力條件下運行，此時用腳本監(jiān)測服務器可用內(nèi)存以及所有應用的內(nèi)存使用，如圖18所示是測試過程中發(fā)現(xiàn)的采集服務器的可用內(nèi)存曲線。

圖18給出了一個令人吃驚的結果：采集服務器的可用內(nèi)存曲線呈現(xiàn)鋸齒狀。剛看到該圖形時，很有些覺得莫名其妙，但在查看其他應用的內(nèi)存使用狀況時，馬上就恍然大悟了。原來，報告入庫分析程序的開發(fā)人員出于習慣，為該進程準備了一個防止進程意外退出的機制——Watchdog，他用一個后臺進程對多個報告入庫分析程序進行管理，一旦發(fā)現(xiàn)某個報告入庫分析程序進程退出，該后臺進程就立刻重新裝載一個報告入庫分析程序進程。而剛巧報告入庫分析程序本身存在內(nèi)存泄漏，在大壓力、長時間的運行條件下，進程的占用內(nèi)存一直增長，直到系統(tǒng)內(nèi)存不能再支撐為止，此時進程會被操作系統(tǒng)關閉；但由于Watchdog的存在，進程被關閉后又會立即被重新裝載進來，如此反復，最終造成了采集服務器的可用內(nèi)存曲線呈現(xiàn)鋸齒狀。

圖18

此外，在壓力測試中出現(xiàn)問題的應用還包括交換機的代理進程，如圖19所示是該進程在測試過程中的內(nèi)存使用情況。

圖19

從圖19中可以看到，該進程在測試過程中的內(nèi)存使用占用呈現(xiàn)持續(xù)增長的趨勢，這明顯是該進程的內(nèi)存泄漏所致。后經(jīng)過對代碼進行分析，該進程確實存在內(nèi)存泄漏問題，每次建立和釋放一個連接會產(chǎn)生2KB左右的內(nèi)存泄漏，由于內(nèi)存泄漏量非常小，如果不通過這種長時間、大壓力的測試，很難發(fā)現(xiàn)。

另一個在穩(wěn)定性測試中發(fā)現(xiàn)的問題與資源使用相關。測試完成后檢查各應用的日志時，發(fā)現(xiàn)在接入進程的日志中出現(xiàn)了許多“無法打開文件”的錯誤信息，且這些錯誤信息發(fā)生在測試開始2天后。由于整個測試過程都采用同樣的壓力條件，因此該問題不太可能由環(huán)境引起。后來經(jīng)過開發(fā)人員的定位，該問題產(chǎn)生的原因是接入進程在某種情況下打開文件后沒有及時關閉文件句柄（handle），從而導致在一段時間后無法再打開新的文件。

判斷系統(tǒng)是否能夠穩(wěn)定運行的另一個指標是測試過程中應用的響應時間或效率是否發(fā)生明顯變化，在本測試中，采用方案1和方案2的檢查方法對其進行檢查。當然，在存在內(nèi)存泄漏的情況下，隨著持續(xù)運行時間的增加，系統(tǒng)的業(yè)務處理能力明顯變小。

在修正了內(nèi)存泄漏的問題后，經(jīng)過再一次測試，發(fā)現(xiàn)各服務器的可用內(nèi)存曲線在整個測試期間沒有明顯變化，各進程占用的內(nèi)存在整個測試期間也沒有明顯變化，系統(tǒng)的業(yè)務處理能力亦沒有發(fā)生明顯變化。綜合以上，可以說明，應用在測試的初期存在內(nèi)存泄漏導致的不穩(wěn)定隱患，經(jīng)過修正，系統(tǒng)已經(jīng)可以滿足預期的穩(wěn)定性要求。

6.測試系統(tǒng)能否順利實現(xiàn)故障切換

根據(jù)測試方案的描述，測試系統(tǒng)能否順利實現(xiàn)故障切換的方法比較簡單。由于性能需求中允許部分數(shù)據(jù)不完整，因此，測試過程只需要關注在指定時間達到后系統(tǒng)能夠正常運行業(yè)務即可。

測試結果表明，在5分鐘內(nèi)業(yè)務順利恢復，因此，系統(tǒng)在故障恢復方面能夠滿足預期的性能要求。

四、案例小結

該項目是一個較大型的性能測試項目，大量采用自定義通信協(xié)議，因此沒有采用商業(yè)的性能測試工具，而是在整個項目中采用自行構建性能測試工具的方法。本案例描述的項目具有一定的代表性，可作為對此類項目性能測試的參考。

在本案例的性能測試實現(xiàn)中，采用了探針和時間戳的技術，這兩種技術是性能測試過程中常用的技術，讀者可以自行體會。

本案例涉及的項目的很多模塊都是以后臺進程的方式工作，對其測試往往只能通過日志、時間戳等技術來了解模塊的工作狀態(tài)。由于設計的問題，有些開發(fā)人員會制造出“既不輸出信息，也不打印日志”的后臺應用，在性能測試過程中，對測試結果進行分析時，涉及到該模塊的結果分析只能是“摸黑”，如果遇到這樣的問題，直接且唯一的方法就是要求開發(fā)人員根據(jù)測試要求在模塊中加入日志或是其他手段，本案例的性能測試過程就相當?shù)靡嬗趹猛暾鸵?guī)整的信息輸出。

當然，要注意的是，為應用模塊添加日志可能會導致應用的性能表現(xiàn)發(fā)生變化，對這一副作用一定要認識到。時間戳技術就是對日志的一種替代方法。

本案例的描述進一步明確說明了一個事實：性能測試過程最重要的是分析過程，只要分析工作做得充分，執(zhí)行工作基本是水到渠成的事情，而分析也很大程度基于設計的完備性。