from:
最近在給新員工做培訓的時候，將效能測試進行的步驟進行了一次總結和梳理，放在這裡供大家拍磚。。。
效能測試需求收集：這一步叫萬丈高樓平地起，從無到有的過程，收集產品需求中的效能指標，我們從效能測試的目的出發，一般可以嘗試從軟體所依賴的硬體環境，軟體架構方面入手去考慮，如果遇到專業的產品人員，自然要省心一些，如果遇到非專業的產品人員，那麼就辛苦一些。這個階段的工作決定後期設計的成敗，非常關鍵，具體的方法等我總結完成之後再另外寫篇拍磚文。
訪問模型建模：不同的產品使用者數量和使用習慣不一樣，有的產品屬於上班時候用，有的產品屬於休息時間用，比如乙個電商**，那麼使用者大部分都會在中午休息，下午下班前，晚上八點到十點這段時間訪問密集，比如這個**一天要接客100萬，你可不要給平均到一天24小時去，否則壓根就沒有壓力。訪問模型的建立決定了場景設計的正確性，非常關鍵，資料可以找公司的資料支撐部門提供，以保準確。
環境搭建：重中之重啊，我經常面試工程師的時候都會忽略這個環節，看看他們是否會自動提起這個，如果能提起這個環節的那麼說明這個工程師對測試的認知已經有一定的程度了。效能測試環境和功能測試環境是兩碼事，效能測試環境要求模擬現實環境，這裡怎麼模擬，那就根據軟體架構涉及到元素：網路頻寬，伺服器硬體指標，資料庫環境，資料庫的內容環境，這些都需要和線上環境盡力保持一致，所以部署乙個近似度高的效能環境是非常重要的。
工具選擇：工具很多，沒有最好只有最合適的。所以選什麼都不如選合適的。這個相對來說要求就是合適，沒有別的指標。
場景設計：這個簡單分為兩個辦法，一是探測式，先對被測試系統全面施壓，查詢瓶頸點，很多人喜歡用這個辦法，優點是簡單易操作，缺點是方向不明，累人。二是高屋建瓴式，需要一定的軟體架構分析經驗，先從架構入手，分析產品可能存在瓶頸的環節，然後設計針對性的場景，最後在統一探測。設計好之後，請人評審是乙個不錯的辦法。
指令碼設計：根據場景設計出正確有效的指令碼，前面做好了，這步就不難了。
測試執行：接上步，乙個場景乙個場景過。記錄好測試中監控的各種指標，指標的理解代表著效能測試工程師的功力，如果不能理解好那些系統指標，所謂的效能測試也只是泛泛而談，沒有什麼實質意義。
結果分析：根據上面的測試資料進行分析，這個分析能力不是一朝一夕練起來的，需要慢慢積累，首先我們要熟悉常用的系統指標，以及這些指標變化的意義，如記憶體的page/sec，這個如果比較頻繁，那麼就要考慮記憶體是否設定的不夠等待。
調優方案： 根據分析結果，給出合理的調優方案，我們可以從三個方面入手去設計：**級調優，資料庫調優，架構調優。**級的調優相對成本較低，架構調優成本比較高，說到這裡話又回頭了，在架構設計的時候測試要是能提出一定的優化建議，那還真就節約成本了。所以測試盡早介入是非常合算的，當然，前提是測試人員比較厲害的情況下。
這次就寫這麼多了，大家看了可以拍磚，你拍一我拍一，拍到最後都有戲。
效能測試 效能測試步驟
針對此次庫內作業效能測試，梳理一下期間的工作流程 梳理已有的介面指令碼，確認需要做效能測試的幾個介面，即使用率高，對效能有要求的幾個主要介面。結合頁面的操作，和確認的介面，梳理具體的業務邏輯 同時，請開發人員部署了測試環境。測試環境的伺服器指標，盡量和生產環境一致。部署的時候，負載均衡等情況也盡量和...
效能測試步驟和方法
效能測試可以發現專案中很多隱藏的問題，比如 sql查詢慢的語句優化 記憶體洩漏 記憶體溢位 執行緒安全 執行緒死鎖等問題，為上線後專案併發和長時間執行去除隱患。效能測試的步驟 step1 從研發那裡得到介面清單 實際場景中的併發數量 tps 以及相應時間 rt step2 測試人員根據介面清單除錯指...
效能測試系列八 梳理業務場景 搭建環境
效能測試的業務場景是需要梳理的，梳理好業務場景，梳理好業務鏈路，如何梳理業務場景，如何搭建測試環境，業務鏈路梳理清楚，測試環境搭建完畢，才完成了壓測的準備工作。如何做呢，給了幾點思路參考。1.找個熟悉業務的測試，梳理業務相關鏈路介面 2.找開發對介面，並且弄清楚牽涉的服務，快取 3.和運維，開發一起...