覆盤內容：202007 VEH平臺資料庫優化-效能測試
一. 工作背景
VEH平臺在第二季度完成了平臺資料庫優化工作，為體現工作成效，公司安排對VEH平臺進行效能測試。
二.工作配置
時間：7個工作日
人數：1人
裝置：客戶端1
二.工作回顧
2.1 計劃通過介面壓測的方式對平臺效能進行測試，編寫介面資料指令碼 （4工日）
2.2 與開發溝通後，開發建議單純對資料庫進行壓力測試，通過直接向資料庫內插入資料的方式對資料庫效能進行驗證，編寫生成SQL並插入的指令碼 （1工日）
2.3 因需寫入大量資料（百萬級），在使用單執行緒執行指令碼時，耗時長，且不易對資料庫造成壓力， 引入threading模組，使用多執行緒的方式執行寫入sql指令碼 （週末對threading執行緒進行了淺顯的瞭解）
2.4 在被測伺服器搭建監控工具，開始測試，執行寫入sql指令碼，發現執行緒應用出現問題。因未能瞭解執行緒的原理，使用在生產環境中時，出現了各種問題。 處理執行緒問題（1工日）
2.5 在編寫報告的過程中發現，本報告為一份效能比較報告，因在本次測試以前，平臺效能沒有詳細的效能表現文件。故無法與本次測試結果進行對比而證明效能提升。所以現在編寫的報告是沒有意義的。
2.6 通過與專案層面及測試領導溝通後，跳轉了本次的測試目的，僅出具專案內當前版本的效能報告即可。【此時工作進度已經延誤】
2.7 使用粒度較小的方式，對每個介面單獨進行測試，每次測試記錄介面效能表現及伺服器表現，測試執行順利，但因粒度較小，執行進度慢。
2.8 因在做2.7 工作時，向測試伺服器內灌入了大量資料，導致測試環境的功能測試和聯調工作受阻。與專案經理溝通，確認效能測試優先順序較低，需向聯調工作讓路
2.9 在等待測試環境時，編寫效能測試報告框架並完成專案的基準效能測試
2.10 在下班後，開始進行測試。 初始環節執行順利，再執行業務中斷介面時，出現因業務資料不批導致資料無法正常接入的情況。需多次對資料和快取資訊進行操作，除錯測試指令碼。 但仍有部分介面因資料原因未進行測試。且在本次測試時 並未啟動伺服器監控服務，無法獲取伺服器表現。
2.11 測試報告編寫完成，傳送測試報告，併發起評審。
三.問題總結
凡事預則立，不預則廢
做任何事情，事前有準備就可以成功，沒有準備就會失敗。說話先有準備，就不會詞窮理屈站不住腳；行事前計劃先有定奪，就不會發生錯誤或後悔的事。
3.1 在測試工作啟動前
（1）沒有對測試背景和當前專案情況進行足夠的瞭解。
因為沒有對專案當前情況有足夠的瞭解，所以在心中形成了一個錯誤的測試方案（即分別通過介面壓測的方式對兩套相同配置不同專案版本的服務進行測試。），但實際上測試環境僅有當前一套測試環境且部署的為新版本服務。
3.2 在測試工作啟動初期
（1）沒有搞清測試目標
因為沒有搞清測試目標，所以沒有明確測試方向，不明確測試所需著重記錄的引數，就更不能有針對性的對其進行測試並獲取目標引數。
（2）沒有制定明確的測試計劃
因為沒有制定測試計劃，所以在測試工作執行在執行時時間分配錯亂，沒有明確測試操作的方案導致方案多次變動，延誤工期。
3.3 測試啟動中期
（1）將工作重心放在了指令碼編寫
將過多的精力投入在了指令碼編寫中，為給除錯和其他環節預留出時間。測試不只寫完指令碼即萬事大吉，這只是眾多環節中的一環，需環環相扣，每一環都順利完成才能完成一次測試。
（2）測試指令碼沒有進行真實除錯，對指令碼所使用的模組不求甚解
每次測試指令碼編寫完成後，僅對指令碼功能進行了驗證。也就是隻保證了功能可用，但忽略了應用在測試工作中的真實場景。類似於介面壓測指令碼沒有顧慮到各介面傳輸速率的問題，導致下游介面所需資料不足；資料庫sql寫入指令碼中的執行緒應用也不求甚解，只學會皮毛就照貓畫虎，沒能理解使用的邏輯方式，所以執行緒模組用的亂七八糟，直接導致指令碼執行失敗。因為沒有對指令碼進行真實場景除錯，所以在測試執行後 就會出現各種問題。則需要一邊修改 一邊除錯 一邊執行。大大影響工作進度。除錯工作應在非工作時間進行或再進度時間範圍進行。不應占用測試執行時間。
（3）多次調整測試方案
我的初始方案是針對服務進行介面效能壓測，後來開發建議直接對資料庫進行測試，則又開始對資料庫進行測試，再對資料庫的測試出現斷路後，又採取了小顆粒維度對介面進行效能測試，此測試方案可行但需要大量的時間。我再採取這種方案的時候並沒有預見到這種風險，顯然這種高耗時的方案並不適用於我當前已延誤工期的情況。最終仍迴歸最初的單一介面效能壓測方式，完成報告。
a、因為沒有計劃和方案，所以選取哪種方案自我並沒有一個堅定的認知很容易動搖；
b、其次因為對效能測試相關知識掌握的不足，所以在面對開發提供的各種方案都容易被動搖，認為他們說的更合理，但實際並沒有對這些方案進行認真的思考和評估。
（4）沒有提前做效能基準測試
因為沒有在壓力測試正式開始前對業務進行基準測試，所以對各個介面的基本表現沒有一個大致的瞭解，所以出現了指令碼執行中權重比例錯誤的低階錯誤。
（5）在最後一次測試時，沒有對伺服器進行監控
a.對linux系統操作不熟練，操作監控服務的時間成本較高
b.沒有設計好具體的監控方案，不知如何更高效的監控伺服器
c.對自己降低了要求
3.4 測試收尾工作：
（1）出現工作衝突
應在測試工作開始前，明確測試執行時間區間，專案組內溝通，保證測試環境可正常使用。
四.錯題改正
4.1 測試工作啟動前：
（1）明確是什麼人需要的效能測試報告，根據閱讀人群大致確定測試方向，制定測試目標
如 本次測試報告由總師辦提出，其目的為驗證工作成效，所以需要出具資料對比報告。對比引數應為介面處理速率 qps 資料量承載拐點和資料庫最大承載量。公司層級應會對專案的大體速率較為關注。對某介面的具體效能表現，更細粒度的效能表現內容則不會太過關注。
（2）明確當前專案狀態，與開發溝通確認可提用於測試的環境真實情況
如： 在本次測試前，與開發溝通確認可提用於測試的環境真實情況，提前瞭解到當前僅有一套優化後的測試環境可用於測試。瞭解到該情況後就需與測試提出方即總師辦進行溝通，協商可行的測試目標。
（3）制定測試計劃，明確測試工期
根據測試目標，制定測試計劃，預測測試工期，明確測試所需資源。
如：
（1）確定測試目標：與總師辦溝通後測試目標調整為僅對專案進行效能測試，那麼測試方向應為對專案內每個業務進行測試，出具一份專案的效能測試報告。
（2）確定測試內容：對每個業務進行輕負載基準測試，介面壓力測試、業務壓力測試 壓測時關注目標為資料處理介面速率，介面qps 記憶體使用率 cpu使用率 I/O速率等。（以後可能還有其他各種效能測試，如強度測試、極限負載測試、極限線上時間測試等等，根據專案特性和需求方的關注點進行組合測試。）
（3）明確測試目標：明確所需測試專案的伺服器地址，伺服器配置，所依賴工具版本等等。。是否有影響效能的中介軟體，是否採用叢集式部署等
（3）制定測試方案：然後確定每種測試的測試執行方式，也就是效能測試的測試用例，需像測試用例一樣寫清測試目標、前置條件、測試步驟、預期結果等用例內容。尤其是壓力測試各種工具間的配合方式，取樣頻率，執行緒設定等測試引數應在此處明確。各種引數的設定對效能測試的結果都會造成影響，所以引數的設定要合理或符合實際生產場景。還需要在執行壓力測試的時候，是否需要採用分散式方式 都需要納入考慮的範圍
（4）明確測試所需使用的工具：如 輕負載基準測試 需要瀏覽器開發者模組 壓測則需要各種壓測工具/指令碼的支援 業務場景壓測 也需要工具來完成。工具優先選擇自己熟練使用的，最好不要臨時學某一種工具使用，邊學邊用會學不好也用不好*（我是這樣感覺的）。如果自己熟練使用的工具少，就會在這個時候很窘迫，因為沒得選。有時不得不選擇並不使用的工具來使用
（5）預測測試所需時間和資源
根據計劃預估所需時間和所需外部配合的資源，確認必須資源到位時間。
包括測試環境可用時間，測試人員 或其他測試必須的條件等
（6）確定效能指標
可從專案組或需求方獲取指標
常見業務場景可以市場平均指標為驗證指標
罕見場景可專案內討論根據生產環境的需求預估出一個指標
（7）風險評估
對於測試計劃的內各個環節記憶體在的風險點進行記錄，並在評審會上進行評估。
隨記：
入行以來，這是我第二次接入真正的效能測試。
憑藉這公司對文件要求並不規範，多個已上線專案的效能測試報告，均只出具了輕負載的基準效能表現記錄，並沒有真正意義上的效能報告。
在這以前，甚至更多的是用一些效能測試工具，run出一些自己也讀不懂但看起來很高深的報表，拿來應付並不懂行的客戶。
第一次出具效能測試報告，是吉利VEH的專案，吉利真不愧是國內的車企大廠，他們是第一個拿出效能指標要求的廠商。
那是一年前了，當時我剛剛接觸python，沒有寫指令碼的能力，Jmeter也只能搞一些簡單的登入demo，完全搞不定業務所需的資料加解密傳輸的問題。
還是靠其他部門同事的支援，才搞出了幾個介面的Jmeter指令碼，我只要一鍵執行就行了。終於再開發和其他測試同事的幫助下，完成了這次效能測試。
雖說完成了，但毫無成就感可言，我做的最多的只有文案的工作而已。
這次是我第二次接觸效能測試了，測試的還是上次的系統平臺。
一年的時間過去了，我覺得自己有所進步，現在的我應該可以搞定了，所以我信心滿滿的準備完美的完成這次測試。
但結果卻不盡人意，總之我自己對這次測試工作的表現不是很滿意。雖然工作已經完成，但仍需對工作進行回顧。
通過上面的覆盤，我總結出了一個在網上爛大街的測試計劃大綱，以前這種東西我只知其然，現在自己總結出來 也算是知其所以然了。
在這次工作過程中還涉及到很多效能測試相關的專業知識，也讓我認識到自己的淺顯。道阻且長！
鳴謝一路上督促我成長的人~