需求分析問題：
1.剛開始最好不要上來就跟客戶談，某個性能點需要什么樣的指標，比如支持多少人同時登陸，等等。一上來最主要的事情是了解整個系統的作用，用戶，部署的方式，約束，上線時間，等等，目的是讓自己能慢慢的站在客戶角度來看待這個系統，通過自己的知識，想客戶所想，憂客戶所憂，因為我們的目的就是要讓客戶滿意么。
注意性能測試場景選擇的原則：
a.重要的（業務上）,
b.重復的（最常用的模塊）,
c.重量級的（消耗大量系統資源的）
具體性能指標分為幾類類：
a.系統容量（數據容量、用戶量、并發用戶量）,
b.系統并發度指標（注冊用戶、在線用戶、并發用戶），
c.響應度指標（正常壓力下響應能力、峰值壓力下的響應能力，以及異常壓力下的響應能力）
2.理解整個系統及其實現之后，再列出自己分析得到的性能需求點。
3.詢問客戶的具體性能需求，共同分析，是否測試，測試的優先級。
性能測試策略：
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，主要的是對系統的理解和掌控，一種大局觀。我自己感覺，自從這幾個月比較深入的學習Oracle、Linux之后，對性能的理解越來越深刻了，測試過程會有計劃有目標的選取某些數據，執行某個過程，不像以前僅僅是個表面的照葫蘆畫瓢，盡管測試完了，但卻總是感覺心里不安。
發現這個世界，道理都是相同的，你越是想搞錢，越是難搞到錢，即使有，也都不會是大錢。為什么呢？因為能賺多少錢，這個東西，不在錢本身，而在錢之外。我想當年Bill、李嘉誠也沒想自己一定要賺多少多少錢吧，他想的是怎么把這個事情做大、做好、做強吧，要不然他們也不會有錢之后，又投入這么大把的錢到慈善事業上的了，李嘉誠可是放棄了1/3��！不像國內的某些企業家僅僅做個樣子而已。扯遠了……性能測試似乎也是這樣，能力在性能測試之外。所以說吧，做什么都要放大視野，這樣道路才會更寬！
文章來源于領測軟件測試網 http://www.k11sc111.com/
