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的。這就需要產品人員深挖其原因，是不是產品缺陷導致