eg1.接口性能
測試需求
測試以下接口的性能
應用服務器：192.168.10.111 linux
接口名稱：login
訪問路徑：/login
通訊協議：http
請求數據格式：json
請求報文體個構成：
username：“字符串”
password：“字符串”
sign：“字符串”
響應數據格式：json
響應報文體構成：
RespondCode：int
RespondMsg：“文本”
OK，首先這是一個接口的性能測試，沒有具體的業務需求，只有接口的一些定義，那么這種情況下一般是在測試環境看看接口的業務處理能力，并且這里只有應用服務器的地址，沒有后臺數據庫等其他相關服務器的地址，故表面上好像只能監控應用服務器的資源。我們下面來進行逐步的分析，制定一個測試方案和測試案例。
測試目的：沒有明確的目的要求，就是隨機測試一下現有環境下的接口處理性能
業務需求：登錄接口，沒有說大概的用戶需求以及服務器響應時間時延等，從測試目的來看是可以一直加壓知道服務器不能處理，分析進行適當的優化，即可。
系統結構：沒有說明系統的具體部署結構，那么我們有兩種方式來確定系統結構，誰下達的任務可以讓誰向上追溯詢問被測系統的部署結構，是否與中間件？中間件用的什么？部署位置？是否有數據庫？數據庫是什么？部署位置？是否有外部接口調用？（不要以為一個簡單的接口后面運行沒有外部接口，這也是有可能的）最好是有一個部署結構圖？
需要監控所有的部署節點；拿到部署結構比如說有tomcat，有數據庫mysql等等部署位置也都拿到了。開始按照自己理解的系統關系畫系統數據流向圖，并和相關人員確認。得到最終的系統結構關系圖。
一般性能指標確認：響應時間（2（較好）-5（一般）-8（較差，不理想）原則），CPU/IO-Wait/MEN占用（均值70%/10%/70%）等等是否可以達成一致認識。最終要達成一個一致認可的值。
系統環境確認:應用服務器硬件設備（CPU/MEN/DISK），數據庫硬件設備（CPU/MEN/DISK），操作系統的配置（最大打開文件句柄數，TCP連接數），應用服務器tomcat參數配置（內存/連接數等），數據庫配置（內存/連接數/存儲模式等）
分析可能瓶頸：硬件設備的內存是多少？DISK的IO限制是多少？（后面的tomcat以及數據庫的參數配置是否已經優化過？數據庫是否支持異步存儲？數據存儲是否支持批量讀寫？等等，新手測試對這些不了解可以暫時不用管它，后面發現是這方面的問題再優化也可以）這一步也可以在后續的測試優化中再考慮。
測試方案：
(1) 測試內容/目的/系統結構 設備軟硬件環境等已經可以列出來了；
(2) 測試工具選擇---選擇一個自己比較熟悉，有較簡單的工具；（比如像這種已知輸入輸出的接口，選擇JMETER做性能測試比較容易點。）
(3) 測試監控---選擇一個自己比較熟悉，能夠快速使用起來的工具（比如NMON，JMETER Server-Agent插件）
(4) 測試案例設計：
一般業性能測試案例：
操作步驟：
（1） 在數據庫構造和預置3000萬用戶數據；
（2） 測試之前5分鐘，在應用服務器和數據庫服務器開啟系統資源監控；
（3） 使用測試工具模擬用戶發送登錄請求，施壓用戶1000萬，其中正確登錄用戶（用戶密碼匹配）占比90%，錯誤登錄用戶（用戶密碼不匹配）占比10%，（結合接口返回的錯誤信息和錯誤碼考慮各種返回的情況，合理安排比例）；
（4） 持續對服務器進行施壓測試30分鐘以上
（5） 停止施壓，5分鐘后停止監控服務器的監控，后去監控數據
預期結果：
(1) 測試過程中服務器資源占用CPU（均值小于70%），內存（均值小于80%，或者使用期間沒有內存泄漏和錯誤產生），IO-Wait（均值小于10%）（資源占用可根據需要進行調整，或者沒有預期，只是測試一個結果，如果測試結果較好就繼續加壓，測試結果不好就考慮進行優化）
(2) 業務成功率目標100%（成功90%，失敗10%，各種返回比例滿足事先的預期設計比例值）
(3) …其他業務需求
OK,還需要一些測試安排計劃和測試風險的評估，補充到測試方案里面。一個基本的測試方案基本就可以算是完成了。
測試腳本開發：
這個跟你選擇的工具而定，本文就不在此詳說，后面會繼續分享到部分用常用工具進行測試腳本的開發。
------本篇就簡單介紹一下簡單接口的性能測試，下一篇再找一個復雜一點的需求來做一下測試方案制定的實例分析------
------aceaoh
