概念之一[壓力測試]來自VisualStudio.NET設計分布式應用程序可靠性測試：是指模擬巨大的工作負荷以查看應用程序在峰值使用情況下如何執行操作。對每個單獨的組件進行壓力測試后，應對帶有其所有組件和支持服務的整個應用程序進行壓力測試。集中測試從最基礎的功能測試開始。您需要知道編碼路徑和用戶方案、了解用戶試圖做什么以及確定用戶運用您的應用程序的所有方式。測試腳本應根據預期的用法運行應用程序。例如，如果您的應用程序顯示Web頁，而且99%的客戶只是搜索該站點，只有1%的客戶將真正購買，這使得提供對搜索和其他瀏覽功能進行壓力測試的測試腳本才有意義。當然，也應對購物車進行測試，但是預期的使用暗示搜索測試應在測試中占很大比重。
概念之二[壓力測試]來自。NET應用程序性能測試：壓力測試用來評估在超越最大負載的情況下系統將如何運行。壓力測試的目標就是發現在高負載的條件下應用程序的缺陷(BUG)。包括：synchronizationissues，raceconditions，andmemoryleaks(內存泄漏)。壓力測試能讓您識別程序的弱點和在極限負載下程序將如何運行。
概念之三[壓力測試]壓力測試主要是為了發現在一(任意)定條件下軟件系統的性能的變化情況。通過改變應用程序的輸入以對應用程序施加越來越大的負載(并發，循環操作，多用戶)并測量在這些不同的輸入時性能的改變，也就是通常說的概念：壓力測試考察當前軟硬件環境下系統所能承受的最大負荷并幫助找出系統瓶頸所在。其實這種測試也可以稱為負載測試，但是負載測試通常描述一種特定類型的壓力測試——增加用戶數量以對應用程序進行壓力測試。
網上可能還有多于以上三種所描述的對壓力測試這個名詞的定義。
我比較贊同第一種概念，壓力測試應該是指模擬巨大的工作負荷以查看應用程序在峰值使用情況下如何執行操作。擴展開來說，其一壓力測試應該是較短時間的，其次是模擬巨大的工作負荷的，再次壓力測試是要使應用程序的使用達到峰值。對這三點繼續補充，對第一點長時間的壓力測試就轉變成了負載測試;對第二點，對應用程序施加的壓力是超負荷的，所以要不斷地加壓;第三點，使應用程序的使用達到峰值，如果超過這個界限則應用程序會崩潰或錯誤率激增，這個峰值是針對某一時刻來說的，也是針對某個臨界的壓力來說的，轉變為場景設置中的說法就是能夠支持的最大并發用戶數。
在最近的一次測試中定義了測試的目的是：需要了解AUT(被測應用程序)一般能夠承受的壓力，同時能夠承受的用戶訪問量(容量)，最多支持有多少用戶同時訪問某個功能。在AUT中選擇了用戶最常用的五個功能作為本次測試的內容，包括登錄。大概的需求就是這樣。
接下來我AUT的登錄說一說怎么用LoadRunner和Jmeter來實現場景的設置達到測試的目的。(注：對服務器的檢測不是本次測試的重點，本次測試主要收集并發訪問用戶數和發生錯誤用戶數)
首先是對腳本的要求：
1、錄制腳本(注意所有的腳本都應錄制到Action中)，自定義事務，事務從提交用戶名和口令的腳本之前開始;
2、在定義事務開始的腳本前加入集合點;
3、在腳本中加入檢查點，以登錄成功的頁面出現登錄用戶的ID即可;
4、參數化登錄用戶的身份;
其次是對場景設置的要求：
1、因為事先我們不知道將有多少用戶訪問是臨界點，所以在測試過程中需要多次改變用戶數來確定;
2、建議修改運行時設置，優化對服務器的訪問;[Page]
3、計劃的設置，每x時間后加載10用戶(根據總用戶數設置)，完全加載后持續運行不超過5分鐘(根據需要設置);
4、集合策略，當運行中的用戶數100%達到集合點時釋放;
5、注意事項，需要注意幾個時間：
1)服務器響應超時時間;
2)登錄事務迭代一次所使用的時間;
3)集合點等待超時時間;
4)計劃中設置的間隔時間。在我的測試中事務運行一次的時間不超過30秒，通過修改腳本使它的運行時間達到一分鐘左右，服務器響應超時時間、結合點等待超時時間、計劃中設置的間隔時間都設置為了2分鐘。
這樣場景開始運行后運行用戶數呈階梯增長，另外在每個上升點新增的用戶都會隨原來已經運行的用戶并發訪問服務器。
通過多次的運行和對測試結果中正在運行用戶數與錯誤用戶的對比，然后根據定義可接受錯誤率就可得到該功能的最大并發訪問的用戶數。
以上測試中排除了對網絡、客戶端等的要求。在實際測試中首先要保證這些資源是足夠的。
使用Jmeter也能夠達到上述描述的場景的測試，并且更加的便捷。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
