1.背景
最近終於將這個項目測試結束了，之前寫過一篇文章，寫的是測試過程中遇到的問題，感興趣的同學可有先去看看上一篇文章。
2.目的
項目結束後問題也沒有得到根本解決。寶路由此引發了一些列的思考，今天想跟大家聊聊。
3.引發的思考
前一篇文章寫了壓測報表系統時的問題，問題拋給某廠商後，廠商人員來了兩次做現場支持，然而效果並不理想。深問其產品底層原理，爲什麼內存回收後會導致，報表系統的“不可用現象”，然而。。。。。。
在這裏吐槽下，派來支持的人，遠程桌面怎麼最小化都TM的不清楚，我也是醉了。
思考1：腳本採用匿名登錄的方式來查詢報表。
先解釋下這裏所說的匿名登錄，其實就是個白名單，將執行腳本的機器的ip增加值白名單，然後可以通過指定的url來獲取token，再拿這個token來訪問指定報表。這樣就避免了登錄系統的步驟。（因爲他們自己都沒解決登錄系統的密碼加解密問題，當時也跟他們聊了爲不能提供登錄密碼的加密方式，然而回復卻是，目前他們自己測試也是採用匿名登陸方式）。
這樣的腳本就極其簡單，發送請求獲取token，再發一個請求（帶token)來查看報表，這種方式是否合理？試想真實環境中用戶是這種場景麼？顯然不是。。。。。試想下這樣的方式與真正用LR錄製出的腳本相比是不是會少了好些頁面請求？
思考2：忽略思考時間這種壓測方式到底有沒有問題
這又要說到，前篇文章測試中提到的壓測問題。採用忽略思考時間這種方式壓測，報表系統長時間壓測就會出現前篇文章中所說的問題。這裏又要說到OLTP，OLAP
什麼是OLAP：聯機分析處理
什麼是OLTP：聯機事務處理
我們常見的接口壓測（說的再範圍一些就平常的增、刪、改、查）都是屬於OLTP , 然而OLAP 一般就是數據倉庫系統的主要應用，用來分析大量OLTP形成的數據，說白就是對這些歷史數據進行加工分析，讀操作較多。
最後解決方案就是，增加pacing值，3s , 4s ,5s 分別進行了嘗試。其實就是對之前的腳本進行了弱化（從發起壓力角度來說），這樣更貼近真實的業務場景。本來在線用戶就少，其實遠未達到忽略思考時間的那種查詢密集度。現實中也不可能存在業務人員瘋狂在不停的查詢報表。
但最後還是要說下，忽略思考時間的這種方式本身沒有問題。確實不太合適當前的場景，假如真的就是存在這種場景，或者說我就要看你係統在高點擊率下的性能表現，那麼就要採用這種方式了。
問題又來了，在這種高點擊率下，長時間（大概20min）的壓測，系統卻出現了不可用的現象且短時間不可恢復，需要手動重啓產品的某個服務纔可以，這種現象我覺得是不ok的。這就需要產品人員深挖其原因，是不是產品缺陷導致的。