《LoadRunner性能測試巧匠訓練營》——第1章 與性能測試的親密觸碰1.1 性能測試的作用以及重要性

本節書摘來自華章計算機《loadrunner性能測試巧匠訓練營》一書中的第1章，第1.1節,作者：趙　強　鄒偉偉　任健勇 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

性能測試的挑戰性和趣味性小白早有耳聞，也會經常聽到各個公司因為系統性能而引發的一系列嚴重問題，是以性能測試會越來越受到重視，隻是時間的問題。下面就讓我們和小白先來了解下性能測試的趣事，再一同學習性能測試的基本知識。

随着社會的發展，使用者對産品的要求也越來越高，以前可能看重功能方面，現在正在逐漸轉變為性能方面，同時各大公司也加強了産品的性能測試，因為從這幾年發生的事件來看，性能帶來的嚴重問題以及損失不容忽視，而性能測試的重要性也不言而喻。

1.1.1　由性能引發的嚴重問題

小白印象中由性能引發的嚴重問題曆曆在目，大部分都是由于沒有做性能測試、性能測試做得不充足或者對并發以及流量的預估不正确導緻。

【案例1】2008年的奧運會票務系統，由于龐大的訂票人數超出預期，奧運票務系統“開工”後不久便陷入“癱瘓”狀态，當時對外公布的是奧運票務系統每小時能處理15萬張門票的銷售，以及承擔每小時100萬次以上的網上浏覽量，但10月30日系統當機前每小時的網上浏覽量達到800萬，1小時售出的票也達到了20萬張。由于預估工作的缺陷，導緻很多人無法通過網絡訂到自己想要的票，影響了很多人的熱情，也損害了國家形象。

【案例2】作為電商的代表，2009年11月22日，ebay網站出現當機，導緻賣家至少損失了當日銷售額的80%，原因是那年聖誕臨近時，ebay網站上有超過2億件待售商品，這個數字比上一年同期多出33%，正是這激增的33%的待售商品導緻ebay網站不堪重負而當機，80%的銷售額對于ebay來說不可謂不嚴重。

【案例3】魔獸世界在中國的代理商由九城變更為網易，與九城伺服器經常當機不無關系，但是換作網易後，伺服器也經常當機。2010年10月11日，魔獸世界伺服器故障時，官網論壇上的遊戲玩家紛紛發“賀詞”表示不滿，從這可以看出網易公司對魔獸世界的性能預估存在不足。也正是因為對性能嚴重忽視間接導緻了九城在失去魔獸世界之後，從一家土豪公司成了一家幾乎被人遺忘的公司。

【案例4】視訊網站優酷網也在2010年發生當機事件，超過3小時無法通路。優酷對外宣稱的原因是：此次當機事件起源于“地球一小時”活動，優酷網為響應這次活動，全站采用關燈模式，意在借此提醒網民注重環保與節約。但此舉令網友一時無法适應，大量網友頻繁重新整理頁面導緻優酷網伺服器崩潰。

【案例5】2010年，中國最大的微網誌平台新浪微網誌當機4小時，新浪官方解釋說：之是以掉線幾小時，是因為使用者增長超出預期，伺服器備感壓力。自上午10點起，使用者無法登入，新浪的報錯頁面幾次更改，最初的“微網誌正在更新，将于11:30恢複”，然後改為“12:00恢複”，過了一段時間，幹脆改為“稍後恢複”，然而，估計是看不到恢複希望，提示資訊又改為“微網誌系統壓力過大正在搶修，我們深表歉意”。悲劇的是“歉意”竟然寫成了“謙意”，這件事遭到網友的大量惡搞，小白也是參與者之一。

1.1.2　性能測試的重要性以及必要性

根據2008年aberdeen group的研究報告表明，web網站1s的頁面加載延遲相當于少了11%的pv，相當于降低了16%的顧客滿意度。如果從金錢的角度計算，就意味着：如果一個網站每天掙10萬元，那麼一年下來，由于頁面加載速度比競争對手慢1s，可能導緻總共損失25萬元的銷售額。

compuware公司分析了超過150個網站和150萬個浏覽頁面，發現頁面響應時間從2s增長到10s，會導緻38%的頁面浏覽放棄率。

radware也曾釋出一份題為“行業現狀：2013年春季電商頁面速度與web性能”的調查報告。報告指出，僅一年時間内，美國前2000家領先的線上零售商網站的加載時間較去年同期減慢了22%，網站性能急劇下降，使用者體驗品質大幅下降。對網站回訪率、跳出率、客戶滿意度及線上收入等多個關鍵業務名額的影響越來越大，對線上零售商而言，網站加載速度已經成為制約其發展的重要因素，提升web性能已經刻不容緩。

2014年中國電子商務研究中心釋出對電商網站的調查報告，報告中指出使用者對網站響應時間的要求很嚴苛，期望立刻做出響應的占90%，期望5min内做出響應的占10%。

從上面的研究分析再結合小白印象中列舉的例子可以看出，性能測試非常重要也非常必要，因為性能問題不僅僅會損害公司的形象，也會造成公司資金方面的損失。

1.1.3　什麼系統需要做性能測試

小白剛接觸到“什麼系統需要做性能測試”這個問題的時候，心裡在想應該是大型的系統、軟體才需要做性能測試，如果隻是幾個人用就沒有必要了。可仔細想想，小白覺得應該是所有系統、軟體都應該做性能測試，關鍵是要思考應該做到什麼程度，而不是做不做的問題。因為就算是一個人在使用某個系統，但該系統的查詢性能極差，一次查詢需要50多秒鐘，這絕對是任何人都難以接受的。

接着小白對現有的系統進行了分類，大緻分為單機系統、c/s、b/s。這3類系統都應該進行性能測試，隻是每個分類有各自特點，在實際測試中應該有不同政策進行應對。

一般c/s架構的應用程式更關注于系統資源使用情況、資料庫性能以及運作的配置要求等。例如，記憶體、使用者連接配接數、資料庫死鎖、資料庫cache命中率、運作的最低配置等。

而對于b/s架構的應用程式，會關注web伺服器的相關名額，如每秒點選數、吞吐量、嘗試連接配接數、事務成功率等。

如下幾個案例分别針對典型的系統進行了說明。

【案例1】假設使用word來編輯一個1 000多頁的文檔，該文檔包含了豐富的圖表、圖檔，需要等待系統花多少秒的時間進行處理。這時需要關注性能響應。

【案例2】某業務系統屬于二次開發，之前沒有做過性能測試，當并發100個使用者時就會造成資料庫伺服器崩潰。這是很明顯的性能問題。

【案例3】某企業内部資訊系統，使用人比較少，但并發時會出現重複的相同記錄。這種場景很難在功能測試時出現，是以有時候性能測試并不是隻能發現性能問題。

【案例4】面向廣大網際網路人群的網站，每天都需要接受大量的通路請求，伺服器壓力大，對這樣的系統進行性能測試是十分必要的。

其中b/s架構的系統會比較複雜，小白接到的正好是b/s的項目，看來這下需要學習一番了。

1.1.4　性能測試的目的

很多第一次接觸性能測試的人都會把功能測試的思想帶入，造成思維的局限。其實性能測試還是與功能測試有所不同的。性能測試更加關注系統的性能表現，也就是how fast和how much。而做性能測試就是排除系統瓶頸，使得它表現得更好、更霸氣。可以從以下幾個方面來了解。

1）評估目前系統。系統未做過任何性能測試，對系統的目前性能情況不了解，就好像沒有體檢過就不知道自己的身體狀況一樣。而此前說到的一系列性能引發的嚴重問題也正是由于缺少了必要的性能評估而導緻。

2）尋找瓶頸，優化性能。常見的現象為，某業務操作響應時間很長、某系統上線一段時間後運作越來越慢，這些都需要逐漸分析定位并調優。

3）預測未來性能。當使用者數和業務量增加時能否及時應對？如何調整？是增加應用伺服器，還是資料庫伺服器？還是要優化代碼邏輯？這一系列問題都值得我們深思，這也是性能測試的目的所在。回想1.1.1節中的ebay不就是最好的例子嗎。