概念之一【壓力測試】來自Visual Studio 。NET 設計散布式應用順序牢靠性測試:是指模仿偉大的任務負荷以檢討應用順序在峰值應用狀況下如何履行操作。對每個獨自的組件進行壓力測試后,應對帶有其一切組件和支撐效勞的全部應用順序進行壓力測試。集中測試從最基本的功用測試開端。您須要曉得編碼途徑和用戶規劃、理解用戶試圖做什么以及肯定用戶應用您的應用順序的一切方法。測試腳本應依據預期的用法運行應用順序。例如,假如您的應用順序顯示 Web 頁,而且 99% 的客戶只是搜尋該站點,只要 1% 的客戶將真正購置,這使得供給對搜尋和其余閱讀功用進行壓力測試的測試腳本才有意義。當然,也應對購物車進行測試,然而預期的應用暗示搜尋測試應在測試中占很大比重。
概念之二【壓力測試】來自。net應用順序性能測試:壓力測試用來評價在逾越最大負載的狀況下體系將如何運行。壓力測試的宗旨就是發明在高負載的條件下應用順序的缺點(BUG)。包含:synchronization issues, race conditions, and memory leaks(內存走漏)。壓力測試能讓您辨認順序的弱點和在極限負載下順序將如何運行。
概念之三【壓力測試】壓力測試重要是為了發明在一(恣意)定條件下軟件體系的性能的變更狀況。通過改變應用順序的輸出以對應用順序施加越來越大的負載(并發,循環操作,多用戶)并測量在這些不同的輸出時性能的改變,也就是通常說的概念:壓力測試考核以后軟硬件環境下體系所能蒙受的最大負荷并贊助找出體系瓶頸所在。其實這種測試也可以稱為負載測試,然而負載測試通常描寫一種特定類型的壓力測試——增添用戶數量以對應用順序進行壓力測試。
網上可以還有多于以上三種所描寫的對壓力測試這個名詞的定義。
我對照贊成第一種概念,壓力測試應當是指模仿偉大的任務負荷以檢討應用順序在峰值應用狀況下如何履行操作。擴大開來說,其一壓力測試應當是較短時光的,其次是模仿偉大的任務負荷的,再次壓力測試是要使應用順序的應用到達峰值。對這三點繼承彌補,對第一點長時光的壓力測試就改變成了負載測試;對第二點,對應用順序施加的壓力是超負荷的,所以要一直地加壓;第三點,使應用順序的應用到達峰值,假如逾越這個界線則應用順序會瓦解或同伴率激增,這個峰值是針對某一時刻來說的,也是針對某個臨界的壓力來說的,改變為場景設置中的說法就是可以支撐的最大并發用戶數。
在最近的一次測試中定義了測試的目標是:須要理解AUT(被測應用順序)個別可以蒙受的壓力,同時可以蒙受的用戶走訪量(容量),最多支撐有多少用戶同時走訪某個功用。在AUT中抉擇了用戶最罕用的五個功用作為本次測試的內容,包含登錄。大約的需求就是這樣。
接下來我AUT的登錄說一說怎樣用LoadRunner和Jmeter來完成場景的設置到達測試的目標。(注:對效勞器的檢測不是本次測試的重點,本次測試重要搜集并發走訪用戶數和發作同伴用戶數)。
首先是對腳本的請求:
1、錄制腳本(注重一切的腳本都應錄制到Action中),自定義事務,事務從提交用戶名和口令的腳本之前開端;
2、在定義事務開端的腳本前參加聚攏點;
3、在腳本中參加檢討點,以登錄勝利的頁面涌現登錄用戶的ID即可;
4、參數化登錄用戶的身份;
其次是對場景設置的請求:
1、由于事前咱們不曉得將有多少用戶走訪是臨界點,所以在測試歷程中須要屢次改變用戶數來肯定;
2、倡議修正運行時設置,優化對效勞器的走訪;
3、規劃的設置,每x時光后加載10用戶(依據總用戶數設置),完整加載后連續運行不逾越5分鐘(依據須要設置);
4、聚攏戰略,當運行中的用戶數100%到達聚攏點時開釋;
5、注重事項,須要注重幾個時光:1)效勞器響應超時時光;2)登錄事務迭代一次所應用的時光;3)聚攏點期待超時時光;4)規劃中設置的距離時光。在我的測試中事務運行一次的時光不逾越30秒,通過修正腳本使它的運行時光到達一分鐘左右, 效勞器響應超時時光、聯合點期待超時時光、規劃中設置的距離時光都設置為了2分鐘。
這樣場景開端運行后運行用戶數呈階梯增添,另外在每個回升點新增的用戶都會隨本來已經運行的用戶并發走訪效勞器。
通過屢次的運行和對測試后果中正在運行用戶數與同伴用戶的對照,而后依據定義可接收同伴率就可得到該功用的最大并發走訪的用戶數。
以上測試中消除了對網絡、客戶端等的請求。在實踐測試中首先要保障這些資源是足夠的。
應用Jmeter也可以到達上述描寫的場景的測試,并且更加的便捷。
文章來源于領測軟件測試網 http://www.kjueaiud.com/