性能測試--三、性能測試過程

概念驗證(Proof of Concept:POC)

維基百科數據庫

概念驗證(Proof of concept,簡稱POC) 是對某些想法的一個較短而不完整的實現,以證實其可行性,示範其原理,其目的是爲了驗證一些概念或理論。概念驗證一般被認爲是一個有里程碑意義的實做的原型 。瀏覽器

網絡解釋緩存

概念性驗證(Proof of Concept;POC) 正如其字面意義通常,是1種架構師(Architect)爲了「驗證」概念是否能確實執行,所擷取出最精要、核心的解決方案(Solution),以做爲解釋架構的概念依據。POC能夠協助架構師在驗證概念時,以更宏觀的角度看待複雜系統,並讓全部關聯的人更容易提供意見,修改架構,避免落入計較細節,本末倒置的狀況發生。 POC除了能夠協助架構師更瞭解系統的概念全貌外,也有助於幫助瞭解系統內部的結構分析與設計呈現。
POC通常來講,會包含如下幾個部分:一、爲了驗證概念所需的技術架構,如Framework、Pattern;二、利用UML語法所建構的概念模型; 三、模擬解決方案; 四、可被實際執行的解決方案原型(Prototype)。
解決方案的原型,必需要是1個可被驗證的框架,強調的是對系統的總體觀與結構觀,而非單純的圖形介面。這個原型的功用在肯定系統架構的大方向,而後纔是校訂細節。安全

在銷售環節中,POC提供以下信息:服務器

  • POC提供了一個在技術上評估針對目標程序的性能測試工具的機會 (從技術角度驗證性能測試工具的可行性;在被測應用程序上對測試工具進行試驗。);
  • 識別腳本數據需求 (針對少數的事務,組建性能測試的基本部分,是一次針對腳本測試階段的「彩排」,能識別出執行成功所必需的輸入數據和運行中的數據需求。);
  • 評估腳本 (估算出編寫腳本所須要的時間,爲之後的測試提供決策基準);
  • 在目標應用程序上演示性能測試解決方案的能力(POC象形的展現了自動化測試工具的優越性,爲你的計劃和方案提供決策支持)。

POC一覽表

前提

  1. 與客戶共同制定一套成功或者退出標準,並以書面的形式肯定;
  2. 配備一個標準的可以知足性能測試工具及其解決方案的最低規格的軟件和硬件環境;
  3. 應用環境安裝必要的監控軟件,如服務器和網絡監控器;
  4. 理想的狀況下,有一個獨立的權限去訪問POC過程當中的程序;
  5. 業務人員或者熟悉軟件的用戶,當出現易用性的問題時,提供諮詢和建議;
  6. 提供技術支持人員(瞭解程序的構架以及中間環節的工做原理並能解決技術性問題);
  7. 應用環境和被測程序的權限帳號(至少準備兩套權限用戶,多用戶操做);
  8. 要至少有兩個樣本事務組成的POC的基礎(一個是簡單的只讀,另外一個應該是對目標數據進行更新的復瑣事務)。

流程

  1. 爲每個樣本事務錄製兩個事件,而後對比二者的不一樣,肯定須要什麼樣的「運行時數據」(對比工具:Windiff、ExamDiff Pro from prestoSoft、WinMerge);
  2. 完成針對輸入和運行時數據需求的識別,以及全部對腳本必需的修改後,還要肯定事務可以在單用戶和多用戶的條件下正確的回放(數據庫更新、預期結果、事務回放日誌沒有報錯)。

可交付

  1. 測試工具成功的運行腳本,回放應用程序的事務,是評價POC經過的標準;
  2. POC經過後,能夠確認範例事務的輸入和運行時數據的要求,而且可以大體瞭解性能測試項目的數據需求;
  3. 肯定爲了保證腳本準確回放作全部修改,以及評估錄製一個應用程序事務腳本所需的大體時間;
  4. 在銷售方面,能夠給客戶提供一個良好的印象,知足全部已承諾的成功標準。

性能測試具體過程(從需求到完成)

過程時間指南

在性能測試項目中大部分的時間花費在獲取需求、驗證需求以及實現需求上,只有這樣才能爲性能測試打下堅實的基礎。其他的時間則用於錄製事務腳本、執行性能測試和分析測試結果。網絡

關鍵任務的時間尺度指導:架構

  1. 錄製性能測試腳本:每一個事務須要半天的時間;
  2. 建立驗證測試階段或者測試場景:通常須要一到兩天;
  3. 執行性能測試時間:須要至少五天時間(驗證問題的測試是未知數;數據庫重建也會耗時不少);
  4. 數據收集:須要一天的時間(收集測試結果和(關鍵性能指標)KPI監控數據)。

第一步:需求分析

從全部利益相關者那裏收集或諮詢各類性能需求(詳細說明)。框架

其餘注意點:工具

  1. 爲性能測試設定一個截止日期,包括已經計劃好的時間安排;
  2. 決定是外部資源測試仍是用內部資源來執行測試(取決於時間進度和自身資源);
  3. 制定測試環境設計方案(儘可能接近真實環境,建立的時間要充分考慮);
  4. 確保測試周期匯中,都會把代碼凍結應用於測試環境;
  5. 確保性能測試中,不會受到其餘用戶的影響(防止對性能測試執行和結果形成影響);
  6. 肯定全部性能測試的目標,並徵求各利益方(整個測試團隊和相關人員)的贊成,在性能測試目標上達成一致;
  7. 確認軟件的關鍵失誤,並記錄在案,以備錄製(很重要的過程,可能致使性能測試面臨失效的風險);
  8. 肯定事務的檢查點,特別是一些特殊的監視要求(好比登錄、搜索);
  9. 檢查您所選擇的事務的輸入、目標、運行時數據的需求(數據對於性能測試十分重要;要保證性能測試項目的時間框架內獲取足夠的準確的數據;同時考慮數據的安全和保密);
  10. 驗證性能測試的數目、類型、事務內容以及虛擬用戶的配置;思考時間、步進以及負載生成策略;
  11. 驗證並記錄服務器,應用服務器以及KPI(關鍵性能指標);儘量全面的監視軟件環境,以保證有可用的信息來驗證並解決發生的問題;
  12. 驗證性能測試結果,並生成性能測試結果與測試目標對比的報告;
  13. 制定性能測試中發現缺陷的提交步驟規範。

內部性能測試額外關注的點:性能

  1. 團隊成員以及彙報制度(創建專門的性能測試團隊或有內部測試專家組成的核心團隊(大型公司);最起碼要確保您有一位項目經理和足夠的性能測試工程師);
  2. 準備好性能測試中須要用到的測試工具和資源(知足團隊進行有效性能測試的全部需求);
  3. 確保全部成員都接收了關於全部測試工具的相關培訓。

知足一手要求,繼續一下活動:

  1. 制定一個包含資源、時間點以及基於需求的里程碑的整體規劃;
  2. 制定詳細的性能測試計劃,包括全部相關的時間點、測試場景和測試用例、負載量,以及環境信息等;
  3. 確保計劃中包含風險評估,例如時間進度誤差、性能目標未實現等,以防止實際測試與計劃的偏離。

技巧(常被忽略的問題):
若是在性能測試執行過程當中發現了軟件的問題,您要確保計劃中爲額外測試環境和缺陷解決方案預備了意外事件處理機制。

第二步:搭建測試環境

儘早爲測試環境準備好硬件、軟件、網絡設備,它耗費的時間可能比預期要長的多;測試環境儘可能和真實環境類似;

搭建測試環境須要考慮的步驟:

  1. 提早搜索相關設備和配置,爲搭建環境準備足夠的時間;
  2. 考慮全部的配置模型(局域網,廣域網);
  3. 把外部系統的連接考慮進去;外部連接多是性能瓶頸的主要所在;
  4. 爲目前的測試模型準備足夠的負載生成能力;(負載生成的位置:本地、遠程);
  5. 確保被測應用程序在測試環境中進行正確的配置;
  6. 爲被測應用程序和支持應用程序的軟件準備足夠的軟件許可協議;
  7. 配置調試性能測試工具;
  8. 配置(關鍵業務指標)KPI監控工具。

第三步:錄製事務腳本

事務錄製以前,須要作的幾點:

  1. 驗證事務的運行時數據需求;
  2. 肯定並運用事務輸入數據需求;
  3. 決定如何爲事務須要特別監控的部分添加檢查點(Checkpoint),以評估特定事務的響應時間;
  4. 識別並執行應用所錄製的腳本之間的不一樣,這些是事務成功回放所必需的(LR中的關聯技術);
  5. 建立性能測試場景以前,確保事務不管從單用戶或者多用戶的角度都能回放成功。

第四步:建立性能測試場景

考慮以下幾點:

  1. 你所作的性能測試屬於哪一種類型的性能測試:基準測試、負載測試、滲透測試(疲勞測試)、壓力測試(峯值測試)、非性能測試;
  2. 設置思考時間和步進時間(壓力測試除外),真實反映用戶狀況;
  3. 負載生成器配置策略;
  4. 爲每一個負載生成器設置負載生成策略:爆炸式(Big-Bang)、漸進(ramp-up)、漸進(ramp-up)/漸退(ramp-down);
  5. 測試數據準備充分;
  6. 考慮是否使用IP欺騙技術;若是用,提早準備合法的IP清單;
  7. 考慮帶寬的不一樣狀況;
  8. 根據服務器和網絡KPI指標,肯定性能監控軟件;
  9. 基於網絡的性能測試,考慮瀏覽器緩存(新用戶、舊用戶、以及訪問過的用戶),取決於軟件的解決方案;
  10. 考慮應用技術對您的性能測試設計的全部影響。

第五步:執行性能測試

執行性能測試僅僅是驗證軟件的性能目標。

注意點:

  1. 證明測試以前,進行預演測試;檢查負載生成器是否達標;肯定測試環境配置正確;
  2. 執行基準測試爲性能測試創建一個響應時間的理想值;(每一個事務單用戶運行必定時間或者屢次重複一個事務得到的響應時間);
  3. 執行負載測試時,下一次負載測試前,執行重置數據庫(保證性能基線);
  4. 負載測試中發現的問題,須要單獨進行測試(考慮計劃時,須要安排額外的時間);
  5. 滲透測試(疲勞測試)發現內存泄露或者發現與高數據交互事務執行相關的問題;
  6. 壓力測試(容量測試或峯值測試),對系統容量的設置具備參考價值;另外,爲之後測試中增加的事務容量和最終系統用戶提供數據的參考,還能夠利用壓力測試爲處於特定應用級別的服務器設定水平擴展性限制;
  7. 執行其餘與性能無關的測試(配置不一樣的負載平衡性、容錯災備等)。

第六步(後測試階段):分析測試結果、撰寫測試報告和環境恢復

  1. 數據收集(收集並備份全部在性能測試項目中生成的數據);
  2. 對比項目需求設定的性能目標和測試結果,肯定性能測試是否達標(提早肯定性能指標的「一致性」);
  3. 根據報告模板將測試結果整理成文檔;
  4. 將最終結果做爲基線數據並用於跟蹤最終用戶體驗。

參考文檔

  • 《應用程序性能測試的藝術》
相關文章
相關標籤/搜索