從奧運訂票網站的癱瘓漫談效能測試-Zee

聲明：這裡只是拿奧運訂票網站的癱瘓做一個引子。並無其他商業目的。   效能測試如何對效能的保證  我們知道效能測試是對整個架構來說的。而架構包括兩個方面，即：軟體和硬體。硬體又包括很多內容，列舉如：主板、硬碟、記憶體、CPU、路由器、交換器、防火牆等等。軟體也包括很多方面，列舉如：OS、application server、application、database、middleware，etc。做效能測試，這些方面都是要考慮到的。才能對整體有很好的把握。效能測試做的才最有實質意義（此實質意義從技術角度來說）。奧運訂票網站的癱瘓，顯然是大資料量的提交造成的。我們不用懷疑它功能上的實現。如果功能不能實現肯定不會上線的了。在上線之前他們肯定也是做了效能測試的。我們也不用懷疑他們的效能測試的有效性。提交使用者的多少對效能的影響並不是二元一次的直線方程上升的。我想在這一效能測試的過程中，任何一個環節的疏忽都有可能引起此結果。 第一，效能測試工程師的素質，必須嚴格要求。 所以我們在做效能測試的過程中，一定要充分把握這些環節。同時引入另一個問題：誰能把握得了這麼多環節？縱然一個擁有十幾年工作經驗的人來說，也不能保證在效能測試中可以把握每一個具體的細節。更何況人的知識體系都是有限的。所以，在做效能測試時，我們盡量把每個問題都細化。然後找相關的技術人員，即使做效能測試的人，對網路、資料庫等都非常瞭解。也盡量把大家召到一起，共商效能問題。這樣可以減少一些一個人容易疏忽的問題。經常聽到有些公司讓一些沒有很長時間工作經驗的人去做效能測試，還有些初學者去做。這些都無非是做做幌子給客戶看看，說明我們公司有這樣的職位存在。但是他們的作用何在？如何體現出來？怎麼衡量？這是個很重要的問題。這些應該屬於效能測試度量範疇。我為這種形同虛設的職位感覺很不值。同時也為某些公司對效能測試這一職位的態度，很痛心。如果希望在這一職位的人把這一職責做好，就應該去找有相應技能的人。而不應該把它當成拿給客戶看的幌子。當然，這裡還要肯定一些效能測試工程師存在的不容忽視的價值。為一些項目的潛在問題做出了很重要的效能測試，從而避免了龐大的損失。我必須強調，效能測試工程師的技術深度，對效能測試的效果起著非常非常重要的作用。 第二，團隊的重要性也不容忽視。 在社會中生存無疑要接觸人，在一個項目中，我們也在接觸著自己的同事。團隊的氛圍我覺得可以直接影響工作的效率和效果。針對一些公司中開發與測試扯皮的事實，我覺得完全沒有必要。從目標上來說，一個團隊的目標只有一個：做出最好的產品。但是，存在責任推卸的最大問題，我覺得在於：崗位職責不明確。這一問題導致很多效能測試人員，感覺自己一直在打雜。可能很多其他測試人員也有此感覺。這一點，可能是由於測試行業是近幾年才飛速發展起來的原因。其實這是一個應該切忌浮躁的行業。技術行業，應該是踏實而沉穩的。並不像一些廣告中吹噓的那麼高深和前途無量。接著說團隊，職責劃分明確是非常重要的。接著還有計劃的合理性，很多公司的計劃都存在著嚴重的問題。有時是因為項目時間不夠，有時是因為工作量的判斷不足，等等。有時聽人說存在這樣的事情：測試人員需要測試當天開發人員寫出來的代碼。這樣的話，上班時間，測試人員，沒什麼事做。而下班了就一直需要加班。這隻是時間的不合理。其他的資源安排不合理的事件，也不一一例舉了。這裡強調的是：團隊氛圍良好、職責明確和資源的合理安排。 第三，軟體應用系統的架構。 這一問題直接影響整個系統的效能，如果系統架構先天不良，系統根本用不著測試。這一點在前期的需求中肯定有明確描述。並於這一問題，並不是效能測試人員能夠解決的。但是，是效能測試人員必須關注的。一個成熟的架構，是我們應該考慮的。但是效能問題，也有可能出在架構上。做效能測試時需要注意。 其他技術因素不再一一列舉，以上是技術角度來說明效能測試。   其他因素對效能測試的影響  第一，   使用者需求。 我覺得使用者需求對效能測試的影響很大。因為做效能測試就是為了給使用者看。有時客戶會要求流程應該如何去走。這樣的流程可能對客戶來說是最好的。功能的實現也絲毫沒有問題。但是效能就會完全不一樣了。當所有使用者都蜂擁而至，我們最應該考慮的是什嗎？系統不要癱瘓。寧願慢，也不要癱瘓。但是流程影響著效能，如果按客戶所要求的流程達不到客戶的效能需求，應該採用其他手段來平衡效能問題的時候，不要猶豫。效能測試工程師們大膽的提出自己的建議。當然，需要足夠的論證。 第二，領導們。 我覺得很多時候領導一句話的決策就影響著最終的結局。類似於：大領導拍腦袋，中領導拍胸脯，幹活的拍屁股。也是沒有辦法呀。我在外做過一個項目，那個項目的領導就很理智。他讓我來做效能測試。他會和開發與測試一起商量如果制定策略。如果出了效能問題，責任劃分也很明確。立即就改。但是，有些領導的要求也確實無理了點。這樣的現象導致下面的測試沒有辦法做。這一點是我們沒有辦法的，只能提建議上去了。 其他外界因素，這裡不再描述。 早上聽到有人說奧運訂票網站癱瘓，從一個技術人員的角度來想，還是比較驚訝的。難道是效能測試沒有做好？沒有重視效能測試的原因？或者是做了，並沒有類比出實際的那麼多使用者量的資料量？在我平時做的效能測試中，如果我對某模組做了效能測試，達到了多少使用者。我會充分分析效能測試的有效性。從而在寫報告的時候，更深入的分析問題。如果奧運訂票網站任一環節都在可控的範圍內，出現這樣的問題，就可以說是純意外了。只是我覺得並不是純意外。 希望做效能測試的人，不要捨本逐末。