效能測試個人經驗小結_效能測試

       效能測試定義：
　　通過一定的工具結合相應的測試方法，對部署的系統應用進行測試，發現系統應用內部存在的代碼邏輯問題及應用部署的機器硬體資源瓶頸問題及應用部署架構存在架構錯誤問題，如：網路端、用戶端、服務端搭建的架構問題；
　　負載測試：是一個分析軟體應用程式和支撐架構、類比真實環境的使用，從而來確定能夠接收的效能過；
　　壓力測試（Stress Testing）：是通過確定一個系統的瓶頸或者不能接收的效能點，來獲得系統能提供的最大服務等級的測試；
　　效能測試的目的：
　　效能測試的目的主要體現在三個方面：以真實的業務為依據，選擇有代表性的、關鍵的業務操作設計測試案例，以評價系統的當前效能；當擴充應用程式的功能或者新的應用程式將要被部署時，負載測試會協助確定系統是否還能夠處理期望的使用者負載，以預測系統的未來效能；通過類比成百上千個使用者，重複執行和運行測試，可以確認效能瓶頸並最佳化和調整應用，目的在於尋找到瓶頸問題；
　　項目開發週期：初始時刻，項目更多關注的是功能實現，此時功能測試顯得尤為重要，測試的提前介入，可以提前預測風險，減少項目開發週期、節約開發成本；功能測試後的階段，個人認為應該是效能測試（試想，如果一個項目連功能都實現不了，更何談效能測試）；在功能完畢之後，引入效能測試，通過效能測試對開發項目潛在的問題進行排查（功能測試，僅僅是幾個人或者幾十個人簡單的對應用功能的一個測試，對於應用真正上線後的大量使用者使用，應用存在的潛在風險，並不能做很好的預估，尤其是當前空前的競爭壓力下，應用上線後的失敗，很可能導致整個項目的失敗；例如：12306訂票網站，使用量之大，可能全世界前所未有，調動全國人力去測試應用效能問題，肯定是不可能的。如果事先不經過效能測試，貿然上線，在如此之多的使用者使用方式下，系統崩潰將是怎樣的一種後果。）；
　　案例分享：編者曾經從事過一個項目，伴隨項目的始終。前期階段，由於測試提前介入，以及項目開發採用的敏捷開發方式，項目很快在不到半年的時間內，功能近乎完美完成。專案經理本著穩妥起見，引入效能測試，對項目潛在的風險進行評估，然後就搭建了一套類比環境，專用於效能測試，搭建的類比環境30使用者並發運行，項目一點問題沒有，進一步提升並發使用者數，各種問題接踵而來；經過系統調優後（發布的應用系統參數等），部分問題解決；為了進一步測試實際情況下存在問題，效能測試環境由類比環境切到了生產環境上，此時是大量使用者下的並發，部分業務是沒有問題的，但是更多的問題是集中在涉及到工作流程的一些業務情境上，後台日誌各種報錯；通過抓取後台日誌，對問題進行定位分析，很快排查解決了代碼開發中存在的一些邏輯問題；代碼修複後重新上線，問題已基本不存在了；項目也很快結束，大大的縮短了項目開發週期、節約了開發成功、更好的適用於使用者；
　　效能測試注意點：
　　錄製指令碼盡量類比實際使用者操作，在情境設計時，盡量與實際情境一致，對於使用者使用比較多的業務，應著重關注；
　　效能測試儘可能在實際生產環境上進行，普通類比環境並不能真正發現實際生產環境下，應用存在的問題，但是並非棄用類比環境；
　　效能測試，對於應用系統部署的環境上，可能需要部署一些系統效能監視軟體，在軟體的選取上，儘可能降低軟體自身運行對系統效能的影響；
　　效能測試，特別是應用與資料庫互動的業務操作上，需要提前預製符合效能測試業務需求的資料，在此基礎上，盡量讓環境測試環境可多次重複使用，這就要求資料、應用可還原；
.....
本文轉自 51Testing軟體測試網