后臺性能測試總結—測試準備篇(2)

　　(6)臨界資源：多進程處理模式中是否有加鎖不恰當的行為

　　(7)……

　　3、設計測試用例

　　了解了以上的基本情況，其實都是為這一步作準備的。在解決第一個情況的性能需求時顯得尤其省力，有經驗的性能測試人員在了解了以上的情況甚至可以不用設計測試就可以確定問題出在了哪里!(lisa大膽揣測一下，盡管還沒有達到那個水平)

　　性能測試的測試用例不比功能測試，可以考慮很多的異常測試，因為成本很小，而一次性能測試用例的執行常常需要消耗較大的資源和時間，所以精準的性能測試用例顯得尤為重要。

　　性能測試用例的設計，根據Lisa這段時間的積累與總結，感覺可以從以下幾個方面著手。

　　(1)選定最合適的邏輯分支進行測試

　　往往會有很多分支可以滿足你的測試要求，選擇的時候，可以從以下兩點入手：A.受周邊影響最小，B，消耗的資源最少。

　　A點可以幫助我們很快的定位出問題，也許整條邏輯分支設計的系統會有很多，我們可以選擇涉及周邊系統最小但是卻可以包含被測系統在內的分支進行，當然最簡單的做法就是可以直接壓測被測系統，但這樣做有些問題是暴露不出來的。

　　B點可以幫助我們節省資源，比如已經有現成的環境了，總之我所需要準備的東西減少了，自然就速度快效率高了，而對于新系統或者從未進行過性能測試的老系統，在時間有限的情況下，我們還需要結合實際情況，選擇用戶請求量最多的最重要的分支進行測試。

　　(2)根據前面的分析，設計最有針對性，最有效的測試用例

　　比如說我懷疑導致aqc系統性能下降的原因是本次迭代新增了大內存的排序。例如aqc系統有一條分支將用戶所有的cdkey查詢出來然后按照時間排序，并全部返回給用戶。那么我們怎么讓這個問題得到驗證呢?在設計的時候可以選擇兩種極端的情況極其組合進行測試，一種是所有用戶均沒有cdkey，另一種是所有用戶均含有500個cdkey，最后一種則是兩者的組合，比較一下則可以驗證出是否是因為偶爾的某些用戶的cdkey太多，導致整體的性能下降。

　　當然在測試的過程中，我們還需要根據現有的數據調整測試用例，幫助我們驗證猜想，更清晰的定位問題

　　(3)請教有經驗的性能測試人員往往會有驚喜

　　在經驗有限的情況下，著手處理前和前輩請教下，不僅可以提高工作效率，更可以增長見聞。但是這點恐怕也是很多人忽略的。任務來了，不要急著入手，先問問往往可以拓展思路。

　　4、測試環境的準備

　　測試環境的搭建往往要根據測試用例的設計而確定。對于初次進行性能測試的系統，我們的目標是盡可能的和現網一致?？梢灾饕獜囊韵聨讉€方面入手。

　　(1)數據：大數據量以及數據的多樣性往往是模擬的難點。大數據量需要自己寫腳本將數據庫填充到一定的程度，如果要求高的話，甚至可以采用從現網導數據的方法。多樣性往往比較難以實現，需要了解現網的數據多樣性以及比例，達到模擬的效果

　　(2)網絡時延：這個和公司的IDC機器管理很相關.我之前一直以為所有的測試機器都在一個IDC，后來發現其實不然，我們的測試機器也和運營機器一樣，分布在不同的IDC，而我們在挑選機器部署時，需要先了解一下現網運營機器之間的網絡時延。這在測試整個一條邏輯分支的性能時尤為重要。

　　(3)配置：日志級別的配置，線程或進程的個數，如果條件允許，配置可以升級到機器的硬件的配置，如果可以一致自然是最理想的效果。

　　這里有一個誤區，我之前一直以為最好每次測試的環境都盡量的去和現網靠攏，但是在聽了yuetangdeng的一堂課之后，發現IBM并不是這么做的，對于以前曾經做過性能測試的系統，往往那套環境還是存在的(不管這套環境是否之前和現網一致)，而測試我們更多的是想驗證系統是否存在性能問題，想想與上一次測試周邊環境都相同的情況下，新的迭代版本替換后系統性能明顯下降了，難道還不能說明問題么?

　　在一切都準備好了，接下來我們就可以開始準備測試工具來執行我們的測試用例啦~~~~

原文轉自：http://www.uml.org.cn/Test/201308025.asp