1、性能測試、負載測試、壓力測試、穩定性測試
性能測試驗證系統表現是不是符合預期
負載測試驗證系統在超出預期的過程中，他的表現怎麼樣？
壓力測試重點是要找到系統在不斷加壓的過程中，什麼時間點（併發量時）崩潰
穩定性測試強調時間維度，重點是驗證系統持續提供服務的時間、穩定情況。
2、怎麼考慮性能測試的典型場景？
產品規格：
用戶模型：用戶喜歡什麼功能，時間段用，大概有多少用戶；
系統數據：基礎數據和業務數據
比如：比如雙11，用戶名、地址信息是基礎；買了什麼東西付了多少錢這樣的數據是業務數據。
原則：寧多勿少
系統架構：B ---Tomcat(Nginx) --Redis --Mysql
運維日誌：進一步確定真實用戶的數據和行爲；
市場計劃：未來幫助我們考慮性能的擴展性；
項目管理計劃：未來幫助我們明確測試的優先級；
--測試需求-->設計出壓測模型
3、性能測試流程（重點）
流程是什麼樣？
===》 需求分析 - 測試計劃 - 用例編寫 - 測試執行 - 輸出報告
-----------前期準備----------- ----------中期準備---------------- ---測試執行---- --完成--
===》 需求分析 -- 方案設計 -- 計劃 -- 腳本編寫（環境搭建、預熱、數據準備） -- 執行、監控、調優 --數據報告
爲什麼需要流程？
===》保證項目順利進行
1)需求分析：做什麼事情？見2；
2)我怎麼做這件事（宏觀）
3)計劃：什麼人、什麼時間、做什麼事
4)腳本編寫：先了解系統：接口、功能（模塊）、彼此間的依賴關係，再開始編寫；
錯誤做法：
a）腳本全放在一個Action；
b) 沒有註釋的
c) 寫完後沒在場景中跑，結果一壓測腳本就各種報錯；
……
5)環境搭建：搭建環境需要多少資源，這個環境要滿足什麼樣的需求（多少核多少G，帶寬多少，需要多少臺）
主要問題：線下環境如何模擬線上環境？
能在線做就在線做：沒上線，可以在線做（沒上線，沒用戶）；全鏈路（已上線，有用戶）的方式；
模擬搭建環境，測試機器的擴展係數 + 自動化擴容（或服務降級）構成一個方案；
差異過大，不要做；
PS搭建好之後要預熱
6)數據準備
主要是性能需求分析的結果：準備多少數據；
測試方案：怎麼準備（業務生成、SQL存儲過程、工具生成、導入線上數據（敏感數據要脫敏））
具體準備：測試準備
7）執行：設置好場景，跑數據出來
監控：爲了收集數據，爲後面分析和調優做準備；
調優：爲了軟件更好，更能服務預期；
過程：迭代反覆的；
4、負載測試時，有時服務器過大測試過程中沒有測試出他的極限，上市後出現癱瘓，怎麼解決？
測試環境建設：
1）儘可能在線測（全鏈路壓測）；
2）自己搭建環境測試
a)線上服務器很多，不可能搭建完全真實的環境，採用等比縮放，測試出擴散係數
b)能搭建出真實的環境測試，那就測吧
5、線網性能測試是在公網進行嗎？
看應用，具體情況具體分析
6、性能測試指標（重點）：
1）併發數、在線用戶數、註冊用戶數
併發用戶數 在線用戶數 註冊用戶數
12306同時買票的用戶 12306同時登上去的用戶 12306的註冊用戶數
PS：併發用戶數是用來壓測的；註冊用戶數會根據這值來造數據；
2）、響應時間
響應時間是和一定的用戶行爲聯繫在一起的。對外說的時候：TPS多少的時候，響應時間是多少？
響應時間一般越短越好，需要看具體測試對象的標準。
響應時間組成（Web）:
a)打開瀏覽器，在百度中輸入：新浪； ---忽略，不用考慮；
b)瀏覽器自身的處理；
c)DNS的解析時間：host --- 本地DNS --- 國內DNS --- 國際DNS
d)TCP建連時間：三次握手所需要花費的時間
e)請求在網絡上傳輸的時間
f)服務端接收時間
g)服務端解析時間：OSI網絡模型解封裝到找到具體的業務程序解析所花費的時間；
h)數據庫處理時間
i)數據發送給客戶端的時間
j)數據在網絡上傳輸的時間
k)客戶端收到數據並呈現出來所需要的時間
l)整個業務處理中經過的模塊花費的時間都要考慮進來
7、TPS
站在客戶端的角度來說的；
單位是個每秒：如200個/s
測試登陸的性能：一個事務裏面可能有很多的請求；
8、吞吐量：衡量網絡性能的實際指標（帶寬是理論指標）
bit/s
9、思考時間
10、CPU、內存、網絡、IO
1）CUP：物理CPU：主板上實際插入的cpu數量，可以數不重複的 physical id 有幾個
cat /proc/cpuinfo| grep "physical id" | sort | uniq | wc -l
邏輯CPU：一般情況下，邏輯cpu=物理CPU個數×每顆核數，如果不相等的話，則表示服務器的CPU支持超線程技術（HT：簡單來說，它可使處理器中的1 顆內核如2 顆內核那樣在操作系統中發揮作用。這樣一來，操作系統可使用的執行資源擴大了一倍，大幅提高了系統的整體性能，此時邏輯cpu=物理CPU個數×每顆核數x2）
cat /proc/cpuinfo| grep "processor" | wc -l
CPU的核心數：單塊CPU上面能處理數據的芯片組的數量，如雙核、四核等 （cpu cores）
cat /proc/cpuinfo| grep "cpu cores" | uniq
關注具體指標，看整體是否夠用，看具體要測試程序用掉多少CPU
2）內存
windows系統顯示用了多少就是多少；
Linux所有的內存都會被系統拿來用；
關注具體指標；
看整體是否夠用；
看具體要測試的程序用掉多少內存；
有沒有使用交換分區---如果使用了交換分區，也表明了系統的內存緊張；
3）網絡（連接客戶端和服務端）
關注：帶寬，吞吐量是多少，丟包率是多少；
4）IO
關注：當前使用了多少，是誰在讀在寫他們各自用了多少。
11、性能測試理論模型
拐點模型
1）隨着壓力增大，響應時間會逐漸變大
2）隨着壓力增大，吞吐量顯示逐漸增大，維持一個較高水平，之後吞吐量會下降；
3）隨着壓力增大，資源利用率先是逐漸增大，維持一個較高水平；
理髮師模型：http://blog.csdn.net/gzh0222/article/details/6792442
重點，理解隨着壓力增大，系統會照顧客人體驗（感受），他們會出來招呼客人，招呼的過程中，就會造成性能下降；
11、前端性能
前端性能測試是一個用戶的行爲，而服務端性能測試，是很多用戶併發起來的行爲。
前端性能測試工具：瀏覽器的開發工具（F12），httowatch,在線免費工具等；
12、識別性能瓶頸點：
TPS -- 響應時間 ---> 初步性能數據是否滿足預期，滿足呢，看四大件（有沒有潛在風險），有潛在風險呢，分析：
初步性能數據是否滿足預期，不滿足呢，分析，看瓶頸點在哪裏（看誰佔用過多的資源，再進一步確認他佔這麼多資源不合理），如果合理，OK；如果不合理，開發介入優化吧。
13、如何設計負載？標準是什麼？
測試出滿足產品需求的數據（假設是：50）
開始設計負載測試：以大於50的壓力，開始跑，比如：60,70,80......開始跑負載測試，直到系統掛掉（壓力測試壓掛掉系統時的壓力）；
實際上：
更關注性能測試，更關注系統的穩定性。
要知道系統能不能滿足應用；
要知道系統什麼時間點開始不滿足應用；
什麼情況下才會掛掉