有不少同學一聽說要做效能專案，馬上就熟練的開啟了loadrunner開始錄起了指令碼，然後做的過程中遇到各種問題，在網上各種問，指令碼要不要做關聯呢？測試的時候需不需要加集合點？引數化資料選擇多少條呢。。。講真，這些問題別人也沒辦法回答啊，這些問題都取決於具體業務和需求，需要從需求中挖掘，並沒有乙個固定的答案。
那麼效能測試首先要做什麼事情呢？都有什麼注意事項呢？
其實呢，效能測試是乙個非常複雜，專業性很強的工作，為了保證我們整個測試過程中更有目的性，思路更清晰，不走彎路，所以在做效能測試前，我們必須先做需求調研，這個環節也是效能測試整個流程中的第乙個環節，也是最重要的乙個環節。需求調研是否真實詳細，決定了我們這次效能測試是否成功。
需求調研呢，免不了也去找研發和產品做溝通，所以最好是提前約乙個會，把大家集中起來，為了提公升效率呢，建議提前把需要調研的事項都寫下來，這樣有什麼問題呢，都在會上問清楚了，否則你開始做效能測試時，尤其是新手，突然發現有某些事項遺漏了，然後你一次又一次的去找開發問，然後接下來發生的事情呢，***。。。
做任何乙個專案，無論開發還是測試，都需要了解這個專案是做什麼的，目前的現狀是什麼，可以解決什麼問題。這些問題可以讓我們知道我們做這件事的意義。我們有好多研發或產品人員呢，總是提一些不合實際的需求，這個時候我們可以幫他們評估一下，到底這個專案需不需要做效能測試。因為並不是每個專案都要做效能測試的。
一般情況下，可以通過以下維度來評估是否需要做效能測試：
開發提測的可能是乙個大專案，但是這個專案裡哪些模組、介面要做壓測，哪些不做呢。這個要提前和開發確定好，並郵件確認，明確我們本次壓測的乙個範圍，這樣以後本專案其他模組出現了效能問題，我們就可以有有理有據了。
如果我們做乙個功能測試，那麼我們不需要了解專案的架構。只能把業務流程搞清楚就行。但是效能不一樣，你必須對整個專案的部署架構非常熟悉，比如專案的中介軟體用的是nginx呢還是apache呢；快取系統用的是單節點還是集群；資料庫有沒有使用讀寫分離和分庫分表等等。把這些問題都搞清楚後，方便我們後續的環境部署。如果將來壓測過程中，如果出現效能問題，我們也知道都去排查哪些環節。如果是乙個經驗豐富的效能測試工程師，在搞清楚架構後，也能大概的評估系統架構中可能存在的瓶頸點。
了解完整體系統架構後，需要把每個模組/介面的資料流向搞清楚，比如我前端發起乙個http請求，那麼這個請求可能先達到nginx，通過nginx的負載均衡策略分配到某個tomcat節點，tomcat會根據不同的url匹配到程式中不同的方法，**內部可能先去快取做一次查詢，然後再去資料庫中做一些操作，可能還會跟外部系統做一些資料互動，以及邏輯處理，最後把資料返回給前端使用者。了解這些東西幹什麼呢，一是為了造測試資料，二是為了將來排查效能問題，因為凡是資料流轉過的地方，都有可能出效能問題。我們可以根據整個資料鏈路，配合一些監控資料，從前到後，逐步的排查和分析，最終就能找到效能瓶頸點。所以資料的流向也是非常重要的。
這裡的配置分為硬體配置和軟體配置。我們做線下壓測時，配置的基本原則是盡量跟線上保持一致。
從硬體配置角度來講，線下最好有單獨的效能環境，單台機器配置盡量和線上差不多（實際情況下，大部分公司做不到這點），如果線下單機的硬體配置和線上差距比較大，那麼線下測出來的資料只能做個參考了。而且現在效能測試的趨勢就是線下是為了排查問題的，真正想評估容量，那就做線上壓測。
從軟體配置角度來講，需求調研時要從開發或運維那裡獲取到線上各元件、中介軟體的引數配置資訊，比如記憶體配置、連線數配置等等，這樣才能更真實的模擬線上的環境。
一般企業內部的系統，大部分都是有外部依賴關係的，比如你要測試a系統，可能a系統會依賴b系統。b系統又依賴c系統
我們在做需求調研時，需要提前確定好乙個依賴系統部署方案。
一般情況下，有這麼幾種處理方式
外部依賴級聯關係比較少，可能就只有一兩個依賴關係，那就把依賴系統也部署上
外部依賴關係比較多，同時依賴系統部署起來比較複雜，同時呢，我只想測試下我系統自身的效能情況，那麼這種情況下，需要對外部依賴做mock（也叫擋板），最簡單的方式是，讓開發在**中去掉呼叫外部介面，直接返回乙個正常的資料，同時再新增一些sleep延時，模擬正常呼叫外部系統所消耗的時間
外部依賴關係比較多，部署起來還挺複雜，同時，我還想帶著依賴做壓測，那沒辦法了，硬著頭皮部署吧，或者放棄，去線上壓測。
在效能需求調研會上，乙個重要的內容是獲取到本次測試的效能指標和各業務的比例關係
有些情況下，開發團隊會明確指定乙個目標，比如介面tps得達到2000，響應時間不能超過100ms等等。但是更多時候，並沒有一些明確的指標，那這個時候就需要我們通過一些手段去獲取這個指標。
對於線上已經執行的專案，優先選擇的是本公司的業務監控系統，現在基本上稍微正經一點的公司，都會有相關的業務監控系統，可以監控到每個介面每天的呼叫量，監控的粒度一般是分鐘級別的，我們可以找一下介面在最近一段時間內（如果**前的壓測，最好找上一次**時的資料），每天呼叫量的峰值，換算成每秒呼叫量，最後再計算每台機器大概多少呼叫量，這個過程中，還得考慮乙個效能損耗量，比如單台機器tps為100，那麼10臺機器肯定到不了1000，中間會有乙個冗餘值，這個值可能每個公司不一樣，需要做專案的過程中不斷積累這個資料，一般情況下，會有30%-40%的效能損耗。
舉個例子，a介面最近兩周呼叫量峰值為30000次/分鐘，線上部署了5臺機器，那麼我們可以算出，每台機器峰值時大概每秒的呼叫量：30000/60/30%/5=333。也就是單台機器的tps必須達到333才能達標。
有的公司可能沒有這種業務監控系統，那麼有沒有辦法獲取到線上介面的呼叫量呢，也是可以的，比如說通過分析nginx或者tomcat的訪問日誌，nginx的access.log裡記錄了每個介面的每一次呼叫，包括呼叫時間，介面路徑，返回狀態碼等等，可以自己編寫乙個shell指令碼，把你要測試的介面過濾出來，然後按照時間進行彙總，也能統計出乙個介面按照小時或者分鐘的呼叫量分布，找到峰值後按照上面的方法進行分析，這種方法也可以找到tps的預期值。另外對於寫資料的介面，還可以通過資料庫裡的記錄進行分析，比如下單業務，最終訂單會寫到資料庫中，可以對資料庫裡的資料進行分析，也能知道每天的乙個業務量情況。
對於全新的未上線的系統，可能並沒有任何的監控資料和訪問資料，這種情況下，肯定是得不到乙個確切的資料的，可以考慮根據其關聯系統的資料，比如你們系統的上游系統，他們之間都有一些依賴關係，可以參考上游系統的資料；或者找業務方了解下是否本系統有一些推廣計畫；如果什麼都沒有的話，那就不設定預期指標，可以在壓測結束後，和相關團隊對結果做乙個評估，主要依據是根據其他系統或公司的一些實際情況，評估下本系統的tps和響應時間是否在乙個合理的範圍內。比如類似於響應時間的指標，大部分公司的介面都要求是在500ms以內的。
孫子兵法講：「謀定而後動，知止而有得」 意思就是不打無準備之仗，方能立於不敗之地。我們做效能測試也是這樣的，前期的需求調研做的越充分，後期專案才會越順利，測試的結果才是可靠的，有依據的。
效能測試第一步 效能需求分析
測試 根據業務提出效能測試來規避風險 開發 覺得某些頁面載入慢 運維 對某個系統的服務能力提出效能評估 產品 線上效能問題反饋 使用者 提出某些硬性的效能要求 關鍵性評估 有以下一項就要進行效能測試 涉及財產 生命 安全的系統。如 支付系統 電商系統 金融業務系統 醫療健康評估系統 首次投產的大型系...
軟體測試的第一步
先簡單介紹一下自己，16年本科畢業，到現在已經從事軟體測試已經三年多了 實習期間就像玩鬧一樣，就不算在內吧 我想對我之前的工作進行乙個總結，以後也會不定期的更新，希望對想加入軟體測試或者已經處於軟體測試的朋友們有所幫助，如有有什麼寫的不對的，也歡迎指正，謝謝。對於軟體測試的分類這塊我了解不深，根據客...
一步一步打造WebIM 3 效能測試
webim系列文章 在一步一步打造webim 1 和 2 中，已經討論了如何開發乙個webim，並且使用快取來提高webim的效能，本文將編寫乙個程式模擬大量使用者登入來對webim進行效能測試。測試一將模擬200個使用者同時登入的聊天室，每個使用者以1條訊息 秒的速度傳送訊息 由於網路和伺服器處理...