歡迎您訪問八維職業學校-創新教育 引領未來
隨著信息技術的迅猛發展，不少人將目光轉向IT行業，而軟件測試行業更是憑借其人才缺口大、薪資待遇好、發展方向廣、無性別歧視、學習門檻低、技術上手快等優勢吸引了許多人的目光，甚至吸引了很多零基礎的人員通過軟件測試課程培訓入行，今天八維職業學校和大家一起來看看軟件測試工程師如何進行性能測試，希望有助于大家學習。
普通BS架構的系統，一般都采用測試工具(如LR)直接錄制手工操作的方式進行測試。這種方式簡單有效，對測試人員要求不高。但在一些情況下，這種基于錄制的方法可能無法完成，比如頁面上有特殊控件、系統是CS架構、或者通訊的協議無法捕獲等。這時就需要更復雜的測試方法，如手動編寫模擬客戶端的JAVA代碼，而把測試工具當作一個調度控制臺，去調度大量的虛擬用戶線程執行編寫好的代碼。
現在假設有一個簡易版的12306網站，JAVA實現，中間件為TOMCAT，數據庫為SYBASE，沒有集群處理(一切從簡，只有查詢和訂票功能)。如何對它進行性能測試呢？
按照上面的幾個步驟來想一想吧，這里只簡單寫幾點。
第一步，測試確認。海量并發，數據也應該是海量的，但基本都是簡單查詢，沒有復雜的統計，所以主要困難還是在海量并發事務的處理上。中間件、數據庫上都會承受巨大壓力。此類高并發系統還需要對一些功能特別注意，比如一個車次有10張票，5個人同時購票，如何處理？如果是12個人同時點購票，又是如何處理？
第二步，通過標準。無非是系統能夠滿足多少人同時在線，一分鐘內能處理多少訂單，用戶最大等待時間是幾分鐘。注意這個標準一定要是經過各方面確認過實際可行的啊，定一個訂單響應時間不超過5秒有意義么？確認了以后，就要按這個目標來設計測試和執行。
另一個需要注意的問題，按照預期的壓力測試通過了以后，是不是就高枕無憂了？答案是否定的，因為很可能這個預期或者標準是不合理的，這個是非?？赡艿?，只有長期的數據積累，才會一點點走向精確。想想奧運訂票系統，開通后短短五分鐘，網站就癱瘓了，你們以為這種系統沒有經過專業的性能測試么？據我所知，奧運訂票系統性能測試時制定的標準是每分鐘處理四百萬訪問(具體數據記不住了，就假設是這個數吧)，出事后的檢查發現，每分鐘的訪問量超過了八百萬。這種事故責任在誰呢？測試機構敢拍胸脯保證，每分鐘處理四百萬就是沒問題的。而奧組委自己設定的每分鐘四百萬目標，和實際出現偏差也是正常的，畢竟這種系統是第一次上線。最后的處理方法就是，壓力達到了預期最大值以后，再后來的訪問就被排隊了。好好體會這個案例吧，會有收獲的。
第三步，測試設計。設計用戶模型，設計測試場景，設計測試用例。一個典型的用戶是如何使用系統的？登錄、查詢車次余票、訂票、付款，這是理想化的情況。實際更可能是這樣的，登錄(一次登不進去，重復多次)、查詢A車次(未到放票時間、不斷重試，時間到無票)、查詢B車次(無票)、查詢C車次(有票)、訂票、付款、查詢訂單。兩種交互方式對系統產生的壓力，差別是很大的。將多個用戶行動整合到一起，也就是用戶模型，或者叫系統使用模型，是壓力場景設計的依據。假設系統一天的訪問量是一萬個用戶，這一萬訪問量是在24小時內平均分布的，還是分布在8小時內，還是在某一時間點上集中訪問？這些具體到用例中也就是虛擬用戶的加載策略，直接決定了壓力的大小。
除了這個壓力場景，針對此系統還需要進行絕對并發測試，參考第一步的分析。
第四、五步就不細說了，準備環境、數據，針對大量用戶的并發進行一些預調優。按照第三步設計好的各個測試用例準備腳本、執行測試。
第六步，發現問題了怎么辦？比如1000人的壓力下，系統響應就比較慢了，查詢車次需要1分鐘，下訂單需要2分鐘，接下來要做什么？能把這些作為一個性能缺陷提起么？顯然是不可以的，這只是通過你的壓力測試場景產生的一個現象，可能是測試腳本有問題、也可能是測試環境有問題。作為一個性能測試人員，需要盡量深入的定位到問題產生的原因。就像這個響應慢，只是一個表面現象，慢在哪？是中間件還是數據庫？一些簡單的測試方法就可以進行判斷，如在頁面上進行一些數據庫無關的操作，如果依然比較慢，說明在中間件上壓力就已經比較大了。還可以部署另一套中間件測試環境，連接之前相同的數據庫，在壓力測試出現問題的同時，手動訪問新部署的應用(只有一個用戶)，如果同樣很慢，那說明慢在了數據庫端的處理上。還可以通過日志的方式更準確的進行判斷，如應用日志和數據庫SQL執行日志?？傊椒ㄊ嵌喾N多樣的，但目的只有一個，就是不斷的排除無關部分、縮小問題范圍。
定位到了中間件和數據庫之一，然后又該怎么辦？此時恐怕就需要一些相關方面的專業知識了，但其實最常見的還是那些。中間件相關的一般是線程池、JVM、數據庫連接池等，數據庫相關的有鎖、緩存、IO(一般就是SQL語句的問題)等。要進行全面的監控和分析，再做一些合理的調優并重復測試。
問題定位到什么程度才行？我認為是要讓人看了知道改哪就可以了。比如提一個"這個SQL語句進行了大量的物理IO，性能不好"，這就不是個好問題，物理IO是什么？怎么改？如果這么說就好多了"這個SQL語句沒有使用索引，導致了全表掃描，進行了大量的物理IO，性能不好。如果要避免全表掃描，需要調整SQL語句或者添加XX索引"，這才是定位問題。
當然了，上面只是一個非常簡陋的舉例，真實的性能測試要比這復雜的多。
總的來說，我認為，性能測試的難度主要不在技術手段上，互聯網時代技術都是共享的，要善于去搜索利用他人的成果。即使自己搞不定，團隊內一定還有專業的開發工程師、數據庫管理員、系統管理員可以幫你搞定。真正的難點在于，你要想出來如何去測是有效的、有保障的，這才是軟件測試工程師最重要的能力。
下一篇：軟件測試工程師自動化測試有哪些？
學制學費
學習時間
近期活動
開班信息
課程內容
就業情況
津公網安備12011302141430
如何成為IT行業中有競爭力的人工智能工程師？
在當今數字化浪潮洶涌澎湃的時代，人工智能作為 IT 行業最具爆發力的領域之一，正重塑著世界的方方面面，從醫療保健到金融服務，從智能交通到娛樂產業，其影響力無處不在。若想成為這一充滿魅力與挑戰領域中的佼佼者 —— 極具競爭力的人工智能工程師，需要在多個維度精心打磨自己。