理想中的性能測試
用一句歌詞形容理想中的性能測試，我站在草原望北京，一望無際國泰安寧。。。
產品經理提供性能測試場景，并發數，以及期望的業務處理能力和響應時間。
研發同學提供詳盡的接口文檔，配合測試同學生成測試數據。
測試同學很順利的完成性能測試工作提供測試報告。
研發同學按照測試報告完善產品性能。
真是一片和諧安寧的幸福景象。。。
現實中的性能測試
現實中的很多公司其實都是這樣搞性能測試滴。。。
產品經理說，需要對產品進行性能測試，測試人員自己定吧，然后。。。然后就沒有然后了！
測試向研發同學要接口文檔，其實大多數情況下是沒有接口文檔的，聽到最多的回復是，編碼任務太重了，沒時間寫接口文檔；部分幸運的測試同學要到了接口文檔，但是按照文檔里面的內容，是根本調不通接口的！
這怎么做性能測試呢？
這怎么做性能測試呢？
這怎么做性能測試呢？
很不湊巧的是，老板發現產品很慢，不分青紅皂白，對著性能測試同學一頓噴！
tmd，不干了! 不干了? 可是現在工作太難找了，沒有收入怎么活？
自救，改變思路
分析產品經理無法提供性能測試的場景，并發數，以及期望的業務處理能力和響應時間的本質原因是什么？很簡單！是他真的不知道！！！我們手機里裝的應用，那都是app中的翹楚，百分之八十普通小廠的應用（就是你我公司的產品）其實是很少有人問津的，通常打點監控做的也不完善，產品也自然很難獲取到用戶的真實使用數據信息。
至于研發同學不提供詳盡接口文檔的原因也很簡單，主要有兩點：
1.確實忙，沒時間寫
2.接口變得太快了，維護不過來！
怎么破？
怎么破？
怎么破？
核心就是我們測試人員盡可能少地來打擾研發和產品，我們測試自己干！
簡單的說就是，直接從產品頁面使用入手，抓住用戶體驗這個key，從兩方面入手：
1.單用戶做頁面的性能測試，發現頁面的資源（如圖片、腳本、樣式表的加載）以及頁面請求的響應時間等性能問題；
2.對某頁面中所有的接口進行壓力測試。
具體方法如下：
前端性能測試
可以使用google的工具lighthouse，直接發現頁面中的資源，如圖片、腳本、樣式表的加載問題，大家可以參考文章：
https://blog.csdn.net/liwenxiang629/article/details/133271065
頁面抓包壓測所有接口
實現也非常簡單粗暴，通過fiddler等抓包工具，獲取產品頁面中的所有請求，然后進行壓測！
這里有幾點注意：
1.不要再生產環境中測試，因為你真的不知道會產生什么影響
2.測試前一定要跟研發打招呼，告訴他們我們要壓測了，把抓取的接口發給研發讓他們確認（給定反饋時間，不反饋，直接壓，出問題了，研發的鍋）看看是否會影響生產數據，把有風險的接口屏蔽
3.沒有指標的性能測試，在測試報告也沒必要明確寫哪個接口就是慢，我們可以采取同頁面中接口比較的方法，例如一個頁面中，我們用10個用戶壓測時發現，頁面的整體響應時間就已經超過5秒了，然后這個頁面中有10個接口（1-10），其中，接口5 和接口6 響應時間都在3s 以上，而其他接口都在200ms左右，那么很顯然接口5和6是需要被進一步分析的！
4.最后把所有測試接口的處理能力和響應時間進行統計，然后發到業務群里，我們也沒必要說接口是否不達標，只表達我們已經進行了測試并展示了結果，至于是否需要優化那就產品經理和研發自行判斷把。從我的實踐經驗來看，還是有一定效果的，因為我們并沒有單獨對哪個接口進行測試，而是選擇了頁面中的所有接口，頁面響應的快慢是用戶直接能夠感受到的，而影響頁面性能的接口研發是需要處理的（這個無鍋可甩），大家也可以在自己的項目中嘗試一下
我的每一篇文章都希望幫助讀者解決實際工作中遇到的問題！如果文章幫到了您，勞煩點贊、收藏、轉發！您的鼓勵是我不斷更新文章最大的動力
