軟體效能測試

以前做過一些“山寨版”的效能測試，我都說了，是山寨麼，當然不正規，不過，現在有多少企業的測試流程是正規的能，何況效能測試的流程呢。這是現狀，也是機遇。這次因為項目需要，要做一個比較正規的，而且有一定難度的效能測試了。B/S, C/S,介面效能，都涉及到，對自己也是個挑戰和提高。

這一個星期主要做需求理解和效能需求分析，然後寫效能測試計劃和測試案例。發現了很多問題，總結如下：

需求分析問題：

1.剛開始最好不要上來就跟客戶談，某個效能點需要什麼樣的指標，比如支援多少人同時登陸，等等。一上來最主要的事情是瞭解整個系統的作用，使用者，部署的方式，約束，上線時間，等等，目的是讓自己能慢慢的站在客戶角度來看待這個系統，通過自己的知識，想客戶所想，憂客戶所憂，因為我們的目的就是要讓客戶滿意麼。
注意效能測試情境選擇的原則：
a,重要的（業務上）,
b.重複的（最常用的模組）,
c.重量級的（消耗大量系統資源的）
具體效能指標分為幾類類：
a.系統容量（資料容量、使用者量、並發使用者量）,
b.系統並發度指標（註冊使用者、線上使用者、並發使用者），
c，響應度指標（正常壓力下響應能力、峰值壓力下的響應能力，以及異常壓力下的響應能力）

2.理解整個系統及其實現之後，再列出自己分析得到的效能需求點。

3.詢問客戶的具體效能需求，共同分析，是否測試，測試的優先順序。

4.寫出效能測試計劃和用例，並要得到客戶認可。

效能測試策略：

1.單一效能點，多使用者測試。測試過程可以隔離測試效能情境，先單獨測試加壓每種效能需求點，比如使用者登陸，可以單獨類比此需求，建立比如50人並發登陸的情境。但此種情境並非是使用者實際使用方式，不可能有個系統大家只是在拚命的登陸，而不作其他事情。但是，如果在做別的事情，那麼同時再有50人並發登陸的話，那這個登陸時間會大大的延長的。所以此情境的設計僅僅為了檢查這一個模組的效能水平。

2.隔離之後，再逐步建立混合的效能情境。比如登陸的同時有人在瀏覽、查詢、寫入系統。但是此時只載入20%的負載。這一步主要是一個整合測試，考慮各個功能模組之間是否有影響，是否有對某些資源的搶奪等問題。同時找出Top Time Transaction

3.如果上一步沒問題了，這次就加壓100%，看看在真正我們規定的要求下，系統各項效能指標如何，同時對本次測試結果作為Base Line，用來效能調優之後的比較。

4.壓力測試，看系統的最大負載能力。

效能測試能力問題

Loadrunner是效能測試一個非常好用，同時也比較複雜的工具。經過這麼一段時間的學習和使用發現其痛點在於：

1，指令碼錄製和開發，怎麼寫這個東東，比如怎麼樣讓日誌輸出合適的資訊，對於後期分析有很重要的意義，這些都會有些開發能力要求。

2，如何設計測試情境，最大程度的類比使用者需求，這個有挑戰，是對需求理解的挑戰，對整個系統設計和實現的理解，如果知道的東西很少，那理解起來就很費力，也不容易把握住重點，這個功夫也在LR之外。

3，效能測試出來之後，結果如何分析，呵呵，這個更是挑戰了，挑戰來自什麼的？我覺得這個也不是來自LR本身，而是來自對資料庫、作業系統、中介層和這個被測系統本身的理解。這個應該是最難的。調優，在哪個行業不是是最難的啊？單獨一個Oracle,  SQL Server調優那需要DBA多長時間的積累啊，何況我們需要懂的不僅僅是資料庫。當然這個階段可以找DBA來幫我們分析解決問題。這個要求也是在LR之外的。

所以，效能測試工具本身並不是最大痛點，學會使用工具也僅僅是個起點。能做好效能測試人的本事最主要也不是在如何熟練的使用LoadRunner,或者JMeter，主要的是對系統的理解和掌控，一種大局觀。

讀後感：最近公司的一個項目遇到了效能問題，所以讀了很多關於效能測試的文章，從這篇文章中學到了很多。