【正文】 正是他們默默的支持使我能夠全力的投入到學習和工作中。我要特別感謝實訓三個月一直無私的關懷和幫助我的同學讓我學到了很多做人的道理。本文中開發(fā)和測試環(huán)境能夠建立是他們大力配合的結果。在這一年他來對項目的許多具體工作給予了詳細的指導，思想上給了我很多鼓勵，理論方面也提供了很多有益的指導。首先，要感謝李超建老師提供給我這樣一個寶貴的實踐機會，使我能夠參與到這樣一個有意義的項目中。也許當這個項目結束的時候，對我最重要的不是項目的結果，而是整個合作的過程?；厥状髮W生活，我最大的收獲是和其他人的合作。（3）跨平臺由于使用Java語言開發(fā)，客戶端源代碼只需使用不同平臺下的打包工具打包后就能跨平臺運行，完全符合企業(yè)轉平臺實施的要求。（2）功能完善客戶端軟件涵蓋了當前即時通信軟件的基本功能，包括文件傳輸狀態(tài)通知、多用戶群組聊天、對方輸入通知、拼寫檢查等功能特性。鑒于開源代碼開放式訪問的特色，企業(yè)可以輕松并快速地按照自己的需要來定制解決方案，免去了外包定制的昂貴成本和必要性。它不僅更易于定制，而且也加強了企業(yè)在所有權環(huán)境下的獨立性。它減少了企業(yè)級即時通信費用，提高了企業(yè)整體的工作效率，促進了企業(yè)跨平臺軟件的正版化。在接下來的二次開發(fā)和調優(yōu)中，就要針對客戶端的功能模塊，特別是消息模塊和插件體系進行修改。因為需要關注的是實際運行系統(tǒng)的性能，所以客戶端軟件在其中扮演的角色非常重要。在7小時25分系統(tǒng)的業(yè)務處理能力開始明顯變小，基本上達到預期運行8小時的穩(wěn)定性要求。 建議和結論查看整個測試過程的每秒點擊數以及吞吐量的曲線。（2）Vuser為50是該系統(tǒng)性能表現的拐點。根據“性能下降曲線分析法”可以知道，50個用戶為“最佳狀態(tài)下的最大用戶并發(fā)數”。從該關聯圖可以看出，隨著運行用戶數量的階梯式地增長，應用系統(tǒng)性能的變化趨勢也很明顯。 典型測試場景 Typical Test Scenario場景名稱場景業(yè)務及比例分配測試指標性能計數器系統(tǒng)應用典型場景用戶分配：80用戶增長模式：每15秒增加4個迭代時間間隔：15分鐘運行時間：8小時消息響應時間小于5秒應用服務器的CPU使用率、內存使用率響應時間穩(wěn)定性測試場景用戶分配：典型應用場景用戶數的2倍測試持續(xù)時間：8小時測試過程中，各應用進程的內存使用沒有明顯變化測試過程中，響應時間和業(yè)務處理能力沒有明顯變化應用服務器的CPU使用率、內存使用率響應時間 即時通信系統(tǒng)性能測試評估測試執(zhí)行完成后，通過LoadRunner的Analysis模塊，可以對測試過程中得到的性能數據進行分析。 測試場景設計，可以很容易地為本次測試給出需要的場景。 測試環(huán)境設計本性能測試需要驗證即時通信系統(tǒng)在實際應用部署環(huán)境上的性能，因此，盡可能選擇接近實際生產的環(huán)境來進行測試。 性能需求描述 Performance Demand Description需求內容需求詳細描述系統(tǒng)能夠穩(wěn)定運行系統(tǒng)壓力條件：高于實際系統(tǒng)運行壓力1倍系統(tǒng)穩(wěn)定的判定條件：測試過程中，各應用進程的內存使用沒有明顯變化，響應時間和消息處理能力沒有明顯變化測試持續(xù)時間：8小時在消息響應時間要求5秒的情況下，找出系統(tǒng)能夠承受的最大用戶數量方法：以“響應時間大于5秒”作為負載測試的結束條件，獲得系統(tǒng)能夠承受的最大用戶數量對“能力驗證”應用領域來說，本測試需要關注的是消息的響應時間、各服務器的資源使用狀況，結合性能測試需求，性能目標可以定義如下：（1）在典型用戶數量要求的情況下，服務器CPU平均使用率不高于75%，內存使用率不高于75%；（2）在穩(wěn)定性測試的壓力情況下，服務器CPU平均使用率不高于95%，內存使用率不高于90%。（2）在發(fā)送消息響應時間要求5秒的情況下，找到系統(tǒng)能夠承受的最大用戶數量：該要求可以給用戶提供一個針對該即時通信系統(tǒng)可擴展性的參考。于是在確定性能目標時，主要圍繞這個方面來討論。根據以上數據，用公式（）對并發(fā)用戶數進行計算：1604/8=80（人）有了這個參考數據就可以進行測試場景的設計。在對用戶活動進行建模的過程中，得到了以下數據：（1）平均每天使用該系統(tǒng)的總用戶數約為這些內容對應于“能力驗證”應用領域，可用壓力測試的方法對其進行性能測試。 測試計劃測試計劃階段需要分析用戶活動，確定系統(tǒng)的性能目標。 性能預備測試性能預備測試用于對系統(tǒng)建立直觀的認識，即在正式開始測試之前體驗性地使用SPGEcq客戶端的主要功能。（2）能監(jiān)控Linux服務器的主要性能計數器值，例如服務器的內存使用狀況、CPU使用狀況、磁盤I/O情況等。 系統(tǒng)基本功能的驗證該系統(tǒng)進行性能測試時已經進行了客戶端各功能的驗收測試，因此在性能測試中不需要額外安排基礎功能驗證。 性能測試過程通用模型 Performance Testing General Model根據PTGM模型對性能測試過程的描述，下面分別對即時通信系統(tǒng)性能測試的各個階段進行闡述。PTGM模型是一個結構化的過程模型。 PTGM模型隨著被測試系統(tǒng)的日趨復雜，參考文獻[8]提出了一種對性能測試進行管理的方法，該方法基于自動化測試生命周期方法（Automated Test LiftCycle Methodology, ATLM）和被廣泛采用的TMap模型。因此，對性能下降曲線分析法來說，主要關注的是性能下降曲線上的各個區(qū)間和對應的拐點。在性能測試中此處的負載已成為系統(tǒng)的關鍵瓶頸并值得去研究其細節(jié)，還要盡可能地對系統(tǒng)進行調優(yōu)。此處稱之為性能拐點。系統(tǒng)已不再能很好地處理負載了，接著很可能出現運行不正常甚至不穩(wěn)定。當應用軟件進行了全面調整之后，即使在壓力區(qū)域加上最大的建議用戶負載，系統(tǒng)仍然能夠在高于此負載的情況下相對較好地運行一段時間。這里就是所謂系統(tǒng)性能“輕微下降”的地方。從技術上說曲線下降的地方系統(tǒng)正處于壓力之下，但基本上還是能夠處理負載的。根據參考文獻[7]提出的觀點，應該以性能拐點之前最大用戶負載的15%為基準。在測試模型正確的前提下，系統(tǒng)能夠在這個區(qū)域達到期望的最佳性能而不需要對其進行更多的性能調優(yōu)。所以一般情況下不應使用單用戶負載作為后續(xù)負載測試的參照基準。僅是單用戶接入頁面的這種情況可以比喻為在冰天雪地中駕駛汽車。這是正常的。典型的響應時間性能下降曲線可以劃分為以下幾個部分：（1）單用戶區(qū)域此時段是對系統(tǒng)單用戶的響應時間。（3）測試的系統(tǒng)無法處理多用戶。如果出現較大的偏差，主要原因應從以下幾點考慮：（1）用戶群體模型不準確。圖中數據所生成的是最普遍的響應時間性能曲線形狀。這張?zhí)厥獾膱D中還包含了數據表。 一條基本的響應時間性能下降曲線圖 A Basic Response Time Degradation Curve Chart這張圖描繪了用戶訪問的時間與系統(tǒng)用戶負載之間的對比。而這里所說的“性能”一般是指響應時間，但也可以指吞吐量等其他數據。下面給出本次即時通信系統(tǒng)性能測試過程中使用到的方法。 即時通信系統(tǒng)性能測試方法論對性能測試來說，如果沒有正確科學的方法論指導，性能測試很容易成為一種隨意的測試行為。例如，一個內部系統(tǒng)一般在上班后30分鐘至1個小時內會集中地出現用戶登錄；一個財務系統(tǒng)在每月中旬結賬日的前幾天會比較繁忙；一個公司門戶網站在重要消息發(fā)布的前后會有訪問高峰；一個視頻點播系統(tǒng)會在休息時段有大量的用戶訪問等等。對該即時通信系統(tǒng)，將一天的上班時間劃分為8個區(qū)間，這樣就可以解決前面提到業(yè)務操作存在的時間集中性問題。首先應該以更細的時間粒度進行考察。另外，還要考慮到用戶的業(yè)務操作存在一定的時間集中性，即相對集中地分布在某個時間段內而不是平均分布在整個考察的時間段內。參考文獻[6]給出的計算公式如下： CP≈ （）（3）使用建議參考文獻[6]提供的是一種可行但非最精確的方法。一般的，從0到任意時刻T的時間間隔上，并發(fā)用戶的平均數C可表示為：C=所有登錄會話時間長度的總和247。 某一時間片上的并發(fā)用戶數 The Number of Concurrent Users at A Particular Time Instant每個水平線段表示一個的登錄會話。每個由登錄會話創(chuàng)建的用戶會話都會消耗系統(tǒng)內存，而且它們從開始到結束的時間長度都不同。在這段時間內保留有一個或多個系統(tǒng)資源。根據參考文獻[6]中提出的用于估算平均并發(fā)用戶數的方法，首先對登錄會話（login session）進行定義。（2）估算公式在實際的性能測試工作中比較關心的是業(yè)務并發(fā)用戶數，也就是從業(yè)務角度設置比較合理的并發(fā)數。不從業(yè)務角度出發(fā)，而是從服務器端承受的壓力出發(fā)，它描述的是同時向服務器發(fā)出請求的客戶。而且，此時很可能出現由于用戶的同時訪問而導致的資源爭用等問題。如果拋開業(yè)務的層面，僅從服務器端所能承受的壓力來考慮，那么對C/S結構的應用來說，毫無疑問系統(tǒng)的性能表現主要由服務器端決定。這里提到的在同一個時間段內訪問系統(tǒng)的用戶數量，也就是并發(fā)用戶數的其中一個概念。 并發(fā)用戶數（1）并發(fā)用戶數的概念如果性能測試時的目標是驗證當前系統(tǒng)能否支持現有用戶的訪問，最好的辦法就是獲得在同一時間段內訪問被測系統(tǒng)的用戶數量。從圖中可以看到，消息的響應時間可被分解為“網絡傳輸時間”（T1+T2+T3+T4）和“應用延遲時間”（A1+A2+A3），而“應用延遲時間”又可以分解為“數據庫延遲時間”（A2）和“即時通信服務器延遲時間”（A1+A3）。 即時通信系統(tǒng)的響應 Response of IM System“呈現時間”和“系統(tǒng)響應時間”兩個部分，其中“呈現時間”取決于數據在客戶端收到響應數據后被處理并呈現頁面所消耗的時間；而“系統(tǒng)響應時間”指即時通信系統(tǒng)從請求發(fā)出開始到即時通信客戶端接收到數據所消耗的時間。具體來說，當用戶單擊一個按鈕、發(fā)出一條消息，從用戶單擊開始到應用系統(tǒng)把本次操作的結果以用戶能察覺的方式展示出來，這個過程所消耗的時間就是用戶對軟件性能的直觀印象。 響應時間響應時間的定義為：對請求做出響應所需要的時間。因為軟件系統(tǒng)的性能表現與非常多的因素相關，要求測試時的硬件設備、軟件環(huán)境、網絡條件和基礎數據等必須都已經確定。性能測試方法是通過模擬生產運行的業(yè)務壓力和所使用的場景組合，測試系統(tǒng)的性能是否滿足生產性能要求。沒有打包文件時，該方法什么也不做。 * 參數：SPGEcq初始的實例轉變的變量args */private void start(String[] args){…}/** * 轉換在目錄里的任何打包文件為標準的JAR文件。 * 使用JiveClassLoader建立classpath。}/** * 通過加載和實例化自舉容器啟動服務器。/** * main()方法調用Startup對象的start方法獲得參數。public class Startup {/** * 如果沒有指定位置時使用默認值。 * 參數：父組件ponent，標題title。 * 參數：默認目錄directory。 */public void add