自從年後轉崗專職自動化測試崗位後，效能測試基本被我丟一邊了，好久沒更新效能測試相關的部落格了。。。
今晚和朋友討論完自動化測試框架的優化之後，有認識的同行問我乙個效能相關的問題，就和他聊了下我的一些建議。。。
這篇部落格，就以今晚的效能話題為主，聊聊效能測試中，從需求分析開始，要做哪些事情吧。。。
一、產品需求
1、業務場景：
乙個問卷調查的功能，然後產品和業務會不定時通過前端介面去根據篩選條件查詢相關問卷問題的答案明細，但是覺得很慢，讓測試這邊給出乙個指標。
2、系統架構：
mysql資料庫，所有問卷問題相關的資料都儲存在同一張表，單台伺服器，無快取，通過乙個查詢介面去查詢返回資料。
3、資料量：
每天大概新增3000張問卷調查，每張問卷30個問題，每個問題下面還有具體的答案，答案的資料型別、大小不清楚。
ps：從我個人的了解來看，對大部分測試人員來說，遇到的效能需求大體都是這種範圍不明確，指標不清楚的效能需求，那麼如何做好測試工作，在體現自己價值的同時，還能學習提公升呢？
二、具體問題具體分析
1、場景建模
和產品業務溝通，明確他們的操作場景，比如查詢的條件（時間範圍、問卷型別、分數範圍、使用者型別等），操作時間（具體到每天哪個時間段有多少人進行這些操作）。
2、確定指標
明確了業務場景後，確認不同的操作下，使用者（這裡是產品和業務人員）的可接受值（比如每天早晨9:00-9:10，100個人進行查詢操作，查詢條件是最近一周a型別使用者的b型別問卷，分數在80分以上），
可接受的最大響應時間不超過5s。
三、測試進行中
確認測試範圍和具體的效能指標後，接下來就需要進行測試方案設計、測試用例設計等一系列的計畫了，這個階段是最耗費時間也是最麻煩的。
1、環境確認
首先需要確認測試的執行環境，是生產、uat還是獨立的測試環境。測試環境對測試結果的影響是很大的，大體如下：
生產：在執行測試的過程不能對其他使用者訪問造成影響（時間選擇很重要），測試資料汙染要解決（資料隔離：執行緒標記、使用者白名單、擋板、mock物件、測試資料落入影子庫）；
uat：作為驗收環境，一般來說資料的準確性和系統版本都是最新和相對穩定的，但要考慮對其他業務的影響，理由同上；
測試：資料預埋、基礎資料準備、測試資料準備、每次執行迭代後的資料初始化、伺服器配置和生產是否可以等量代換等；
2、團隊合作
效能測試不是乙個人就可以搞定的，一般都需要運維、dba、開發、測試配合來進行，因此做好溝通和協作很重要。
3、測試要做什麼
上面的工作做完之後，你需要考慮測試執行工具和指令碼開發的工作。需要做的事情如下：
①、和開發溝通，獲取業務功能對應的介面文件（如果沒有，想辦法），引數欄位的含義，對應的資料庫表字段，造成的影響；
②、和運維溝通，確確認伺服器的部署，配置（這裡可能需要進行基準測試和配置測試）；
③、和dba溝通，確認測試資料預埋、基礎資料準備、迭代後的資料初始化工作；
④、測試人員本身，需要準備測試資料，開發測試指令碼，進行指令碼除錯，執行和監控分析等工作；
四、體現測試的價值
如何在效能測試中體現測試的價值？
我相信很多測試童鞋都經歷過那種不被看中的階段，但也要努力去改變現狀，不斷體現自己的價值。如何體現，請看下面：
1、做好溝通協調
①、和業務產品溝通，確認需求和場景；
②、和技術團隊溝通，盡量多溝通，達成一致（測試方案、測試用例、測試資料、測試環境）；
2、本職工作要做好
①、測試方案、測試用例設計；
②、測試工具選型、測試指令碼開發和除錯；
③、測試資料的準備；
④、測試執行、監控和分析定位；
3、創造價值才能贏得尊重
職場，一切到頭來還要從自身創造的價值來贏得尊重，那麼如何從測試的角度創造價值？
①、提高交付的產品質量（覆蓋率、風險分析、容錯方案、容災方案）；
②、提高交付速率（解決問題的過程丟擲問題，流程不規範、開發不規範、管理不規範等，丟擲問題，然後推動解決問題）
③、打鐵也要自身硬！因此不斷學習提高自己的技術能力，不斷總結溝通，才能更好和同事交流，從解決問題的角度出發，去解決問題，創造價值！
五、回歸問題本身
上面說的有點跑題了，回到問題本身，說說我對這個效能需求的一些優化建議吧，僅供參考：
1、資料庫優化
問題點：從上面描述的情況來看，每天產生的資料大概有10w+條，且只有一張表儲存；
解決方案：分庫分表，表可以拆分為問卷主表、問卷對應的問題表、問題對應的答案明細表等，長期來說資料量不小，可以考慮分庫，主從分離等，查詢新增索引等方法。
2、處理邏輯優化
問題點：一次性查詢的資料過多，導致前端展示較慢；
解決方案：查詢結果分批次展示（比如有100w條資料，分為100個批次，每個批次10000條資料）。
3、儲存優化
問題點：沒有快取，直接從db單錶讀取，容易造成超時和表鎖；
解決方案：將資料放入快取伺服器（比如redis），設定查詢次數或者有效時間，多級快取，提高快取命中，防止快取穿透和同時失效帶來的瞬間db壓力。
4、業務優化
問題點：多人短時間內查詢大量資料，對服務造成巨大壓力；
解決方案：和產品業務溝通，讓查詢操作時間在業務平緩期，拉長查詢操作的時間線等。
5、服務優化
問題點：單台伺服器；
解決方案：做服務集群和負載均衡，增加監控，設定閾值，超過閾值則臨時增加新的伺服器，分流。
本來問題本身只是想說需求分析的，不知不覺扯了很多相關的內容，當然其中有些內容也值得拆開詳細討論，效能測試，水太深啊。。。
僅供參考，希望看到的童鞋能從中獲取一些效能測試相關的思路，如果有其他建議希望大家提出來，不勝感激。。。
效能測試需求分析
需求分析問題 1 剛開始最好不要上來就跟客戶談，某個效能點需要什麼樣的指標，比如支援多少人同時登陸，等等。一上來最主要的事情是了解整個系統的作用，使用者，部署的方式，約束，上線時間，等等，目的是讓自己能慢慢的站在客戶角度來看待這個系統，通過自己的知識，想客戶所想，憂客戶所憂，因為我們的目的就是要讓客...
效能測試需求分析
需求分析問題 1 剛開始最好不要上來就跟客戶談，某個效能點需要什麼樣的指標，比如支援多少人同時登陸，等等。一上來最主要的事情是了解整個系統的作用，使用者，部署的方式，約束，上線時間，等等，目的是讓自己能慢慢的站在客戶角度來看待這個系統，通過自己的知識，想客戶所想，憂客戶所憂，因為我們的目的就是要讓客...
效能測試需求分析
原文 效能測試需求分析與傳統的功能測試需求有所不同，功能測試需求分析重點在於從使用者層面分析被測物件的功能性 易用性等質量特性，效能測試則需要從終端使用者應用 系統架構設計 硬體配置等多個緯度分析系統可能存在效能瓶頸的業務。效能測試必要性評估 任何專案在開展效能測試活動前都需要進行必要性評估。通過必...