東航B2B系統效能測試

標籤：style   blog   http   color   使用   sp   strong   on   資料   

起因：自9月4日上線後東航B2B系統前些日子連續發生宕機，原因未知。

測試介入：有幸被指派做B2B的效能測試，目標定位問題模組以及給出調優的方向。

 

本來想寫一套全的測試流程和過程中的總結，後來想了一下還是太費時間，將來看到那麼多字估計也抓不到重點，就記錄一下關鍵的不足之處吧。

 

 

不足之處的記載、解決方案，總結：

1 踩入溝通誤區

a 需求不明確（嚴重）

明確需求，這個聽上去其實蠻簡單的。但是實際的工作中真正的痛點在於與你交接的人自己都不清楚他到底想要什麼，想做什麼。所以一定需要謹慎對待，避免出現理解偏差。

1 拿本次的效能需求為例，他並不關注系統的效能指標，而是想過效能測試確認9月4日前後的包到底哪一個模組存在，從而進行調優。

如果說這個時候你直接上手把兩套代碼都測了一遍，給出了9月4日上線後的包的效能瓶頸在哪裡，指標怎麼樣。OK，你已經錯了。

如果說這個時候你進了一步，告訴他XXX模組存在嚴重性能問題，怎麼怎麼去調優。OK，你對了一半，錯了一半。

我當初剛開始的測試就是鑒於1和2一起做了，結果不滿意被要求重做。

原因在哪？主要是這樣的，這個系統到底有多少坑，誰也不知道，可能有N個模組都存在效能問題，而本次需要找出的並不是“效能問題模組”，而是會影響到本次系統宕機的模組。

那麼問題來了，什麼樣的效能模組會是影響到本次宕機的模組呢？

這個還真不好肯定，當初想的辦法是，一定得測試環境中先複現出與線上環境一樣的報錯與宕機前的狀態，然後再根據這個類比的情境逐個排查模組。

那麼其實本次的需求分析就是分兩步走了：

1 重現線上環境的報錯資訊與宕機狀態

2 根據step1中的情境從中找到問題模組

b 多點指揮（嚴重）

每個人都有自己的想法和看法，尤其是對於需求模糊的效能工作千萬得確定介面人。人多口雜，會影響到思路。

我當初犯了一個錯誤，因為出于謹慎我一般都會去核實一下我自己對“模糊需求”的看法，並告知對方我是怎麼分析的將會怎麼做。但是由於我

沒有堅持確定與介面人“對話”，導致了我面臨了一個開發小組的“建議”，造成了我之後一段時間裡需求的理解上存在偏差。

確認介面人，永遠是1對1的交流，這樣的溝通更效率。

c 分工不明確（中等）

說實話這點我覺得我們公司有些員工確實很官僚，喜歡推事情。我不知道他們是怎麼想的，不過確實這樣的話每天可以準點下班吧。

事由是測試環境資料不足，有了一項造資料的工作，那麼問題來了造資料的代碼誰來寫。那時候開發找我說要我寫，我覺得再怎麼造資料也不可能達到7天

達到千萬層級的資料吧，畢竟CPU是有限的，你並發打上不去的。另外所有的API都是開發的，我寫的話相當於外面套一層殼用Selenium自動化來寫，

真的是跑起來效率很低。結果他們經理打我電話讓我寫，OK我就寫了。說實話就是他們懶和不願意去翻自己寫過的代碼API而已。

後來就發生了更多不愉快的事情了，我寫完代碼大概1小時吧，我調通後送過去，結果他們各種問題弄不起來還說我不負責，搞了我一天。

這裡存在兩個問題，我不應該處於好心去接活，因為可能存在別人灑手全推的可能。另外是溝通，我應該婉轉的把對方部門領導的電話轉到我方部門領導那邊去。

d 沒有堅持自己的判斷，容易讓上層領導給影響

很多時候上層領導並不清楚技術細節，他們有時候會提出一些並不很有意義的工作。然後你說這個做了太費時間，效果不大。

其實我覺得沒有事情是真沒意義的，只是因為投入的時間比過於懸殊罷了。OK，我當時就說我來造資料效率太低了，時間而且很久。

對方馬上回了一句，那你評估時間先造起來,我立刻就沒有了立場.

之後還有一次事情一個系統要測效能，但是有位經理和我說要順便對叢集做一下效能測試，這不是扯淡嗎？系統的效能跟負載平衡有什麼關係，而且就給4天時間怎麼可能。

還是那一句話，你先評估。

確實那件事情最後連單台機器的效能測試都將將完成,根本沒有餘力去玩那東西。

以後我大概會這樣回答

1 我不做沒有意義的評估工作。

2 可以列一下，優先順序低、當正常工作完成後再考慮。

e 心態問題，時間緊迫

需求人員往往和你描述問題很緊迫，B2B宕機一定要1天搞定。OK，我急的跟什麼意義，結果有一次我去他那邊發現對方還在上網玩購物。

哦，原來他把寶全壓在我身上了，他一點也不急，真是淡定。

之後莫名其妙時間變長了，變成了7天。

呵呵，不加以評論了。事情按部就班吧，應該這樣，狼來了太多了之後，我已經看不到緊急的事情了。

 

2 踩入測試過程中的誤區

a 操作環節過於冗餘（中等）

這裡是我2B了，也跟流程有關吧，當要做效能測試的時候，啟動重啟伺服器是很平常的事情，但是牽涉到一個許可權問題，我是沒帳號去重啟伺服器的。

開始的時候效率極低，因為每次重啟，重布都要找配置人員。

後來我和配置人員提了申請，拿到了帳號和學了一下啟動方式就OK，效率提高了不少。

b 前期工具準備不足（輕度）

WAS的監控JCONSOLE居然不支援，我暈倒，當時沒考慮這一點，後來我自己去寫了一個工具才完成了監控，花費了意料之外的半天時間

墨菲定律吧，總會有點意外的。

不過我覺得我處理的還可以，之後找了一下確實找到了WAS專用監控工具。

c 計劃安排不規範（中等）

計劃寫的輕量級了，沒有考慮到領導層的觀看，因為他們要看到直觀的進度安排，和對於問題的直觀總結。

d 前期部署環境準備不足（中等）

效能測試的準備工作，被測機器、壓力機器、系統內容、資料量，

環境如果準備不足直接要求退回重來吧。

之前就說到了，資料量差距過大了，當時我是硬著頭皮去測了，效果不好，有點浪費時間的嫌疑了。

之後換了准生產環境的資料規模，立刻20分鐘內重現問題。

 ---------------------------------------------------------------------------------------------------------------------------------

1 最後本次效能測試還算圓滿的結束了，我算是挽救了B2B電商平台麼。得到了領導的認可，總體來說過程艱辛，結果還算不錯吧。

2 另外我這個人心態不好，不知道為何就是看不慣那些混子弄的自己身心疲憊，還需要加強鍛煉心智啊，

3 別人把生活立於工作至上也並沒有錯啊，也是一種對於生命的尊重。

4 無論說話還是做事，都要告訴自己，冷靜之後再開始。

-----------------------------------------------------------------------------------------------------------

附一下本次效能測試的問題吧。

使用者查詢模組中有一條查詢語句用了hibernate的關聯查詢特性，而這條查詢語句所查詢的表剛好存在很多內關聯欄位。導致很多冗餘的查詢操作被執行且佔據了大量的記憶體空間。

 

---------------------------------------------------------------------------------------------------------

這7天裡來來往往郵件實在太多了，附一下這個項目我發出的最後一封郵件吧。

各位好：效能需求已經完成：

本次效能測試一共完成了兩個階段的測試工作即排查問題階段與效能對比階段

1 在排查階段我們定位到9月18日上線時最佳化的按名字查詢訂單是存在效能問題的，解決方案是復原這一部分代碼並沿用以前的邏輯。

2 在效能對比階段的測試結果是調優包與生產的包效能差別在5%左右，區別不大，滿足之前約定的效能測試准出條件，測試通過。

系統效能評估：

雖然本次調優後的包的效能是滿足於需求的，但是還是延續了老生產包的效能問題，CPU佔用率高以及按名字查詢的SQL語句執行效率不高的特點，在大資料量的訂單查詢上，每秒交易處理數與回應時間的指標是很差的。

建議

1 B2B沒有限制使用者查詢的時間區間，如果使用者查詢的是1年的資料那麼對伺服器的壓力很大。（這個安全性漏洞我在8月份早已經提出，望能夠儘快修複。）

2 建議增加測試環境測試資料的規模，如果測試環境的測試資料規模足夠大是可以在功能測試階段發現本次效能問題的。

3 建議開發做一下單元測試，本次的效能問題很大程度是由於hibernate的一個特性的誤使用而造成的。

詳細資料資訊

由於相關的資料資料及較大目前已經上傳FTP 172.25.3.212/測試資料/效能測試/B2B唯讀模組效能測試/第二輪

或者查看這一周以來的效能測試日報

---------------------------------------------------------------------------------------------------------

計劃、分析、報告大致有6分文檔，這裡只貼一下時刻表吧

工作時刻表

 

東航B2B系統效能測試