性能測試從需求分析開始

自從年後轉崗專職自動化測試崗位後，性能測試基本被我丟一邊了，很久沒更新性能測試相關的博客了。。。

今晚和朋友討論完自動化測試框架的優化以後，有認識的同行問我一個性能相關的問題，就和他聊了下個人一些建議。。。

這篇博客，就以今晚的性能話題爲主，聊聊性能測試中，從需求分析開始，要作哪些事情吧。。。

 

1、產品需求 

一、業務場景：

一個問卷調查的功能，而後產品和業務會不定時經過前端界面去根據篩選條件查詢相關問卷問題的答案明細，可是以爲很慢，讓測試這邊給出一個指標。

二、系統架構：

MySQL數據庫，全部問卷問題相關的數據都存儲在同一張表，單臺服務器，無緩存，經過一個查詢接口去查詢返回數據。

三、數據量：

天天大概新增3000張問卷調查，每張問卷30個問題，每一個問題下面還有具體的答案，答案的數據類型、大小不清楚。

PS：從我我的的瞭解來看，對大部分測試人員來講，遇到的性能需求大致都是這種範圍不明確，指標不清楚的性能需求，那麼如何作好測試工做，在體現本身價值的同時，還能學習提高呢？

 

2、具體問題具體分析

一、場景建模

和產品業務溝通，明確他們的操做場景，好比查詢的條件（時間範圍、問卷類型、分數範圍、用戶類型等），操做時間（具體到天天哪一個時間段有多少人進行這些操做）。

二、肯定指標

明確了業務場景後，確認不一樣的操做下，用戶（這裏是產品和業務人員）的可接受值（好比天天早晨9:00-9:10，100我的進行查詢操做，查詢條件是最近一週A類型用戶的B類型問卷，分數在80分以上），

可接受的最大響應時間不超過5S。

 

3、測試進行中

確認測試範圍和具體的性能指標後，接下來就須要進行測試方案設計、測試用例設計等一系列的計劃了，這個階段是最耗費時間也是最麻煩的。

一、環境確認

首先須要確認測試的執行環境，是生產、UAT仍是獨立的測試環境。測試環境對測試結果的影響是很大的，大致以下：

生產：在執行測試的過程不能對其餘用戶訪問形成影響（時間選擇很重要），測試數據污染要解決（數據隔離：線程標記、用戶白名單、擋板、mock對象、測試數據落入影子庫）；

UAT：做爲驗收環境，通常來講數據的準確性和系統版本都是最新和相對穩定的，但要考慮對其餘業務的影響，理由同上；

測試：數據預埋、基礎數據準備、測試數據準備、每次執行迭代後的數據初始化、服務器配置和生產是否能夠等量代換等；

二、團隊合做

性能測試不是一我的就能夠搞定的，通常都須要運維、DBA、開發、測試配合來進行，所以作好溝通和協做很重要。

三、測試要作什麼

上面的工做作完以後，你須要考慮測試執行工具和腳本開發的工做。須要作的事情以下：

①、和開發溝通，獲取業務功能對應的接口文檔（若是沒有，想辦法），參數字段的含義，對應的數據庫表字段，形成的影響；

②、和運維溝通，確確認服務器的部署，配置（這裏可能須要進行基準測試和配置測試）；

③、和DBA溝通，確認測試數據預埋、基礎數據準備、迭代後的數據初始化工做；

④、測試人員自己，須要準備測試數據，開發測試腳本，進行腳本調試，執行和監控分析等工做；

 

4、體現測試的價值

如何在性能測試中體現測試的價值？

我相信不少測試童鞋都經歷過那種不被看中的階段，但也要努力去改變現狀，不斷體現本身的價值。如何體現，請看下面：

一、作好溝通協調

①、和業務產品溝通，確認需求和場景；

②、和技術團隊溝通，儘可能多溝通，達成一致（測試方案、測試用例、測試數據、測試環境）；

二、本職工做要作好

①、測試方案、測試用例設計；

②、測試工具選型、測試腳本開發和調試；

③、測試數據的準備；

④、測試執行、監控和分析定位；

三、創造價值才能贏得尊重

職場，一切到頭來還要從自身創造的價值來贏得尊重，那麼如何從測試的角度創造價值？

①、提升交付的產品質量（覆蓋率、風險分析、容錯方案、容災方案）；

②、提升交付速率（解決問題的過程拋出問題，流程不規範、開發不規範、管理不規範等，拋出問題，而後推進解決問題）

③、打鐵也要自身硬！所以不斷學習提升本身的技術能力，不斷總結溝通，才能更好和同事交流，從解決問題的角度出發，去解決問題，創造價值！

 

5、迴歸問題自己

上面說的有點跑題了，回到問題自己，說說我對這個性能需求的一些優化建議吧，僅供參考：

一、數據庫優化

問題點：從上面描述的狀況來看，天天產生的數據大概有10W+條，且只有一張表存儲；

解決方案：分庫分表，表能夠拆分爲問卷主表、問卷對應的問題表、問題對應的答案明細表等，長期來講數據量不小，能夠考慮分庫，主從分離等，查詢添加索引等方法。

二、處理邏輯優化

問題點：一次性查詢的數據過多，致使前端展現較慢；

解決方案：查詢結果分批次展現（好比有100W條數據，分爲100個批次，每一個批次10000條數據）。

三、存儲優化

問題點：沒有緩存，直接從DB單表讀取，容易形成超時和表鎖；

解決方案：將數據放入緩存服務器（好比Redis），設定查詢次數或者有效時間，多級緩存，提升緩存命中，防止緩存穿透和同時失效帶來的瞬間DB壓力。

四、業務優化

問題點：多人短期內查詢大量數據，對服務形成巨大壓力；

解決方案：和產品業務溝通，讓查詢操做時間在業務平緩期，拉長查詢操做的時間線等。

五、服務優化

問題點：單臺服務器；

解決方案：作服務集羣和負載均衡，增長監控，設定閾值，超過閾值則臨時增長新的服務器，分流。

 

原本問題自己只是想說需求分析的，不知不覺扯了不少相關的內容，固然其中有些內容也值得拆開詳細討論，性能測試，水太深啊。。。

僅供參考，但願看到的童鞋能從中獲取一些性能測試相關的思路，若是有其餘建議但願你們提出來，不勝感激。。。