以前做過一些「山寨版」的效能測試，我都說了，是山寨麼，當然不正規，不過，現在有多少企業的測試流程是正規的能，何況效能測試的流程呢。這是現狀，也是機遇。這次因為專案需要，要做乙個比較正規的，而且有一定難度的效能測試了。b/s, c/s,介面效能，都涉及到，對自己也是個挑戰和提高。
這乙個星期主要做需求理解和效能需求分析，然後寫效能測試計畫和測試用例。發現了很多問題，總結如下：
需求分析問題：
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，主要的是對系統的理解和掌控，一種大局觀。
軟體效能測試要點
軟體效能測試的目標 1 測試系統的最佳使用者數 隨著使用者數量的增多系統的響應時間並沒有受到影響，直到某個數量的使用者數響應時間開始明顯增長 2 測試系統的最大使用者數 隨著使用者數量的增多，系統的響應時間開始延遲，直到某個數量的使用者數時，系統開始響應失敗或崩潰 3 a 找到目前系統的效能瓶頸 依...
效能測試軟體PerfDog
手機的心電監護儀 測試用例 1.反覆開啟關閉ui 為了判斷ui建立與銷毀是否存在記憶體洩露 2.靜止在某一ui頁面 為了與其他場景作區分 3.靜置採集資料 為了判斷是否是由影象資源引起的記憶體洩露還是 資源引起的洩露 fps 幀率 1秒內應用介面的平均重新整理次數，目前主流裝置的重新整理幀率是60f...
軟體測試策略和效能測試
整合策略有自頂向下，自底向上兩種。軟體測試策略 在一定的軟體測試標準 測試規範的指導下，依據測試專案的特定環境約束而規定的軟體測試的原則 方式 方法的集合。軟體測試策略是為了以最低的成本最大程度降低產品的質量風險或盡早地完成測試所選擇或制定的最合理的方式 方法 過程等。自頂向下測試 從主控模組開始，...