一次數據倉庫報表測試（2）

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的。這就須要產品人員深挖其緣由，是否是產品缺陷致使的。