[TOC] **前言** 寫測試用例，是測試繞不開的工作內容，不管是功能、自動化，還是性能。先來回顧一下功能測試用例主要包含的要素：測試用例編號、測試標題、所屬模塊、測試需求項編號、案例狀態、預置條件、優先級、測試輸入、操作步驟、預期輸出、實際結果、案例設計者、設計日期、案例性質等。性能測試用例（有的稱為場景用例）的設計，有別于功能測試用例、自動化測試用例的設計，畢竟，考慮的點不一樣。對于性能測試來說，一般要考慮這4種場景：單場景、混合場景、穩定性場景、異常場景。 </br> **單場景的定義** 　　有的稱為接口基準（Benchmark）、或者單交易的容量，總之，這個不是真實的業務原型（可以簡單理解為不同業務的使用情況）。 </br> **單場景壓測的目的** 　　既然單場景不是真實的業務原型，為什么不直接做混合場景的壓測呢？其實，做單場景壓測的目的是測試出這個單業務的最大tps，方便判斷瓶頸，比如，業務部門給的混合場景的tps（假設這個tps值是合理有效的），根據業務原型比例計算后，業務A的目標tps都比你單場景的最大tps還要大，那是不是應該讓開發提前優化了？如果在混合場景壓測中，發現業務A的tps已經到達或者接近其單場景最大tps，但是混合場景還沒有達標，那說明瓶頸在業務A。 </br> </br> **單場景的來源** 　　有人可能要問，單場景從哪里來？如果你們業務部門或者其它部門能給，那最好，如果不能給，你作為性能測試人員，要引導相關人員給，總之，我覺得這個不能性能測試單獨定，否則后期出問題可能你獨自背鍋哦，要盡最大努力保證不出問題，哪怕出問題，也要一起背鍋。單場景是來自于業務原型，但是不是每個業務接口都需要做壓測，所以，我們這里說的業務原型，是混合場景的業務原型，混合場景里面，每個業務接口都需要做單場景壓測。至于業務原型如何獲取，這是一個大話題，本次分享暫不討論，如果想交流，歡迎微信留言。 </br> **項目架構及服務器清單** 我們用個簡單的架構來舉例：nginx + tomcat\*2 + mysql   </br> </br> **單場景用例** 除了基于壓測工具的設計（假設用的壓測工具是jmeter），還包含監控的設計、預期結果、實際結果  </br> 部分預期結果（根據項目實際情況寫）  部分實際結果  如果你的架構很復雜，寫重點即可，無需把過多的時間耗費在文檔上，況且后期你也可以慢慢完善。 **補充：jmeter腳本** 連續階梯加壓，看線程、tps、rt的趨勢