關于性能測試及相關問題的探討 軟件測試
一、性能測試概念
性能測試是一個較大的范疇，包括負載測試、壓力測試和容量測試。其中負載測試是為了檢驗系統在給定負載下是否能達到預期性能指標；壓力測試是通過不斷向被測系統施加“壓力”，測試系統在壓力情況下的性能表現；容量測試針對數據庫而言，是在數據庫中有較大數量的數據記錄情況下對系統進行的測試。
二、性能測試前的環境檢查
PETE（PErformance TEst的前2個字母的縮寫，即性能測試）前的檢查工作看似簡單，然而其必要性和重要性都值得關注，避免在調試那很久軟件參數，抓落那n把頭發的時候，結果卻發現硬件條件早就不能支撐,白白耽誤時間，而Software Developer自己做PETE的時候(至少我是)，最容易忽視的就是硬件。
[硬件檢查]
1.Check CPU,MEM of all the test objects
2.Check Storage efficiency : multipath -ll; hdparm -Tt /dev....
3.Check Network using tools like iperf
[軟件設置]
1. 線程不是越多越好，線程切換，資源鎖等因素的影響使得性能的提升和線程的數目之間不會是一個正相關，特別是線程的數目達到一定的值以后，更多的線程可能反而幫那倒忙。
最好是先根據系統整體輸入，各個模塊的輸入，模塊內部線程對輸入消息的處理模型：阻塞，非阻塞，同步異步等等，對線程數目做一個預估計，然后在這個值的基礎上進行調整，不然在多進程，多線程的架構下面，單單靠試錯的方法，很可能按下葫蘆浮起瓢，如此多的調整參數，非把人搞瘋不可。
2. 理清楚系統內部的一個性能瓶頸所在之處，完全靠PETE的結果來反映是不現實的，一是需要比較長時間PETE的結果來梳理出結果，耗時；二是很可能系統的設計讓消息在各個模塊里的處理時間完全不可見，缺少像transaction(Glance arm)的runtime統計支持，當然也可以不使用工具，自己造輪子比如對于每個消息用唯一的ID號標記，同時在模塊的輸入和輸出的時候對消息做事務日志(event log)，支持這種log的開關可配置，既方便調試，也可以在部署到客戶關閉。有的同學說那，也可以使用宏開關，對于實驗室版本和發布版本分別打開或者關閉，那就是具體問題具體分析那嘛。
3.當你在使出渾身解數，把所有可調的東西全調那n次以后，還是對PETE測試結果非常不滿意，性能提升完全毫無希望，哎，還是重新考慮架構是否合理吧，選擇的庫性能是否經過測試，雖然這些一開始的時候就應該考慮到，怎么說呢，一開始就能考慮到的估計已經是走出軟件作坊的吧。
三、性能測試的關鍵因素
自動化測試系統存在三個關鍵因素：語言、驅動程序和測試工具。您編寫測試用例及擴展測試系統時都需用用到語言，所以編程語言曾一度令我著迷，如 Perl、Python 和 Ruby。而且我還發現測試人員往往更能將各種編程語言運用得得心應手。盡管我有充分的理由偏愛 Ruby，但是其他一些較好的自動化測試系統卻使用的是其他的編程語言。事實上在過去的幾年里，我用過 Perl、Python 和 VB 建立測試框架，因為這些通常是客戶端已使用的語言。另外，相比商用測試工具套件常使用的私有語言，我更側重使用全功能的編程語言，可能因為我對私有語言已失去了耐心。
選擇語言的范圍很廣，但是尋找一個合適的驅動程序就相對困難很多。驅動程序是用于您應用程序驅動的，就像 Watir 是一款瀏覽器的驅動程序，適用于網絡應用程序的驅動。驅動程序可以對語言的選擇起到決定性作用。幾年前，我針對命令行應用程序使用的驅動是 Expert，其相對應的語言是 TCL，所以對應的工具套用的也是 TCL 語言。我開發 Watir，是因為我想用 Ruby 的瀏覽器驅動程序。使用 Ruby 的 Watir 是我們針對網絡應用程序測試的解決方案。
測試系統的第三個關鍵因素即測試工具，它主要負責執行測試用例，以及收集、報告結果。在我們開發初期，我們都是用 Test::Unit，這是一個基于 Ruby 的測試工具，可用于單元測試，同時也可用于功能測試。近期，也有些 Watir 用戶開始使用 Rspec 或 Cucumber，但是也有些人不喜歡使用現有的測試工具，而更喜歡自己構建。
我是在開發商用測試工具套件（如 SilkTest 和 WinRunner）時有的這些認識。盡管這些套件包經常被認定為工具，但我發現他們實際上是壓縮了一系列的集成工具。它們的使用預期往往不能滿足測試人員的實際需求。就像數據驅動測試期間，我們需要打散原有的套件，然后按一種更加合理的配置重新組裝。所以我需要測試人員對測試系統內每個單獨的工具都能清楚地了解。
許多新的 Watir 使用者在區分 Watir（驅動程序）結點和 Ruby（語言）起點時會有困難，這是因為他們對這兩者的功能未能清楚地理解。我得知一些教 Java 的老師不喜歡學生去使用 IDE（如 Eclipse 或 Netbeans），而更希望他們能學習使用一些需要的工具，如編輯工具和壓縮工具，以了解它們的功能。同樣的，我也希望測試人員能更清楚地了解測試系統內不同工具和部件的功能。
一些新的 Watir 使用者經常會來問一些問題，而這些問題的答案很明顯是我們已經獲知的。Watir 是否可以讀 CSV 文件？Watir 是否可以進行日期運算？Watir 是否可以從數據庫讀取數據？對于這些問題的答案都是否定的，Watir 不能做到這些，但是 Ruby 卻能做到。任何瀏覽器驅動程序都不能完成這些操作（就像您的壓縮軟件不支持搜索和替換），但是任何全功能的編程語言卻能做到。因為測試人員習慣使用的是商用工具套件，這些套件所包含的系統是封閉的，所以他們在使用 Watir 初期可能會提出這樣的問題。但實際上您無需擔心 Watir 是否缺少某些功能，您只需具備的使用這些功能的能力，一旦供應商將這些功能加入套件包內，即能馬上熟練運用。Watir 是一個開發式系統的一部分，經常會有非 Watir 社區的人員對現有的庫進行完善，他們可以說是屬于一個更大的 Ruby 社區的人員。
四、性能測試工具--LoadRunner的結構和原理
LoadRunner是 Mercury Interactive的一款 性能測試 工具，也是目前應用最為廣泛的性能測試工具之一。該工具通過模擬上千萬用戶實施并發負載，實時性能監控的系統行為和性能方式來確認和查找問題。
（一）、 LoadRunner 工具組成
1、虛擬用戶腳本生成器：捕獲最終用戶業務流程和創建自動性能測試腳本，即我們在以后說的產生測試腳本；
2、壓力產生器：通過運行虛擬用戶產生實際的負載；
3、用戶代理：協調不同負載機上虛擬用戶，產生步調一致的虛擬用戶；
4、壓力調度：根據用戶對場景的設置，設置不同腳本的虛擬用戶數量；
5、監視系統：監控主要的性能計數器；
6、壓力結果分析工具：本身不能代替分析人員，但是可以輔助測試結果的分析。
（二）、LoadRunner工作原理
代理（Proxy）是客戶端和服務器端之間的中介人，LoadRunner就是通過代理方式截獲客戶端和服務器之間交互的數據流。
1）虛擬用戶腳本生成器通過代理方式接收客戶端發送的數據包，記錄并將其轉發給服務器端；接收到從服務器端返回的數據流，記錄并返回給客戶端。
這樣服務器端和客戶端都以為在一個真實運行環境中，虛擬腳本生成器能通過這種方式截獲數據流；虛擬用戶腳本生成器在截獲數據流后對其進行了協議層上的處理，最終用腳本函數將數據流交互過程體現為我們容易看懂的腳本語句。
2）壓力生成器則是根據腳本內容，產生實際的負載，扮演產生負載的角色。
3）用戶代理是運行在負載機上的進程，該進程與產生負載壓力的進程或是線程協作，接受調度系統的命令，調度產生負載壓力的進程或線程。
4）壓力調度是根據用戶的場景要求，設置各種不同腳本的虛擬用戶數量，設置同步點等。
5）監控系統則可以對 數據庫 、應用服務器、服務器的主要性能計數器進行監控。
6）壓力結果分析工具是輔助測試結果分析。
第一步：從分析Summary的事務執行情況入手
Summary主要是判定事務的響應時間與執行情況是否合理。如果發現問題，則需要做進一步分析。通常情況下，如果事務執行情況失敗或響應時間過長等，都需要做深入分析。
下面是查看分析概要時的一些原則：
�。�1）：用戶是否全部運行，最大運行并發用戶數（Maximum Running Vusers）是否與場景設計的最大運行并發用戶數一致。如果沒有，則需要打開與虛擬用戶相關的分析圖，進一步分析虛擬用戶不能正常運行的詳細原因；
�。�2）：事務的平均響應時間、90%事務最大響應時間用戶是否可以接受。如果事務響應時間過長，則要打開與事務相關的各類分析圖，深入地分析事務的執行情況；
�。�3）：查看事務是否全部通過。如果有事務失敗，則需要深入分析原因。很多時候，事務不能正常執行意味著系統出現了瓶頸；
�。�4）：如果一切正常，則本次測試沒有必要進行深入分析，可以進行加大壓力測試；
�。�5）：如果事務失敗過多，則應該降低壓力繼續進行測試，使結果分析更容易進行；
......
上面這些原則都是分析Summary的一些常見方法，大家應該靈活使用并不斷地進行總結與完善，尤其要主要結合實際情況，不能墨守成規。
第二步：查看負載生成器和服務器的系統資源情況。
查看分析概要后，接下來要查看負載生成器和待測服務器的系統資源使用情況：查看CPU的利用率和內存使用情況，尤其要注意查看是否存在內存泄露問題。這樣做是由于很多時候系統出現瓶頸的直接表現是CPU利用率過高或內存不足。應保證負載生成器在整個測試過程中其CPU、內存、帶寬沒有出現瓶頸，否則測試結果無效。而待測試服務器，則重點分析測試過程中CPU和內存是否出現了瓶頸：CPU需要查看其利用率是否經常達到100%或平均利用率一直高居95%以上；內存需要查看是否夠用以及測試過程是否存在溢出現象（對于一些中間件服務器要查看其分配的內存是否夠用）。
第三步：查看虛擬用戶與事務的詳細執行情況。
在前兩步確定了測試場景的執行情況基本正常后，接下來就要查看虛擬用戶與事務的執行情況。對于虛擬用戶，主要查看在整個測試過程中是否運行正常，如果有較多用戶不能正常運行，則需要重新設計場景或調整用戶加載與退出方式再次進行測試。對于事務，重點關注整個過程的事務響應時間是否逐漸變長以及是否存在不能正常執行的事務�？傊�，對每個用戶或事務的執行細節都應該認真分析不可輕易忽略；
example1：一個性能逐步下降的服務器，需要進一步分析其性能下降的原因【可以查找是否存在內存泄露問題】；
example2：一個性能相對穩定的服務器，但是響應時間偏大，這時需要分析程序算法是否存在缺陷或服務器參數的配置是否合理。
第四步：查看錯誤發生情況。
整個測試過程中錯誤的發生情況也應該是分析的重點。下面是查看錯誤發生情況的常用準則：
�。�1）查看錯誤發生曲線在整個測試過程中是否是有規律變化的，如果有規律通常意味著程序在并發處理方面存在一定的缺陷。
�。�2）查看錯誤分類統計，作為優化系統的參考。例如對于Web性能測試，當出現瓶頸時往往需要查看服務器的錯誤統計信息結果：如果“超時錯誤”占到90％以上，可能需要提高硬件配置；如果較多的“內部服務器錯誤”，則可能是程序方面存在問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
