效能測試 效能測試

{

\"code\": 200,

\"title\": \"\",

\"content\": \"效能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對係統的各項效能指標進行測試。負載測試和壓力測試都屬於效能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下係統的效能，目標是測試當負載逐漸增加時，係統各項效能指標的變化情況。壓力測試是通過確定一個係統的瓶頸或者不能接收的效能點，來獲得係統能提供的最大服務級彆的測試。\\n\\n效能測試在軟件的質量保證中起著重要的作用，它包括的測試內容豐富多樣。中國軟件評測中心將效能測試概括為三個方麵：應用在客戶端效能的測試、應用在網絡上效能的測試和應用在服務器端效能的測試。通常情況下，三方麵有效、合理的結合，可以達到對係統效能全麵的分析和瓶頸的預測。\\n\\n應用在客戶端效能的測試\\n\\n應用在客戶端效能測試的目的是考察客戶端應用的效能，測試的入口是客戶端。它主要包括併發效能測試、\\n\\n效能測試圖像\\n\\n疲勞強度測試、大數據量測試和速度測試等，其中併發效能\\n\\n效能測試圖像測試是重點。\\n\\n併發效能測試是重點\\n\\n併發效能測試的過程是一個負載測試和壓力測試的過程，即逐漸增加負載，直到係統的瓶頸或者不能接收的效能點，通過綜合分析交易執行指標和資源監控指標來確定係統併發效能的過程。負載測試（LoadTesting）是確定在各種工作負載下係統的效能，目標是測試當負載逐漸增加時，係統組成部分的相應輸出項，例如通過量、響應時間、CPU負載、內存使用等來決定係統的效能。負載測試是一個分析軟件應用程式和支撐架構、模擬真實環境的使用，從而來確定能夠接收的效能過程。壓力測試（StressTesting）是通過確定一個係統的瓶頸或者不能接收的效能點，來獲得係統能提供的最大服務級彆的測試。\\n\\n併發效能測試的目的主要體現在三個方麵：以真實的業務為依據，選擇有代表性的、關鍵的業務操作設計測試案例，以評價係統的當前效能；當擴展應用程式的功能或者新的應用程式將要被部署時，負載測試會幫助確定係統是否還能夠處理期望的用戶負載，以預測係統的未來效能；通過模擬成百上千個用戶，重複執行和運行測試，可以確認效能瓶頸並優化和調整應用，目的在於尋找到瓶頸問題。\\n\\n當一家企業自己組織力量或委托軟件公司代為開發一套應用係統的時候,尤其是以後在生產環境中實際使用起來,用戶往往會產生疑問,這套係統能不能承受大量的併發用戶同時訪問?這類問題最常見於采用聯機事務處理(OLTP)方式數據庫應用、Web瀏覽和視頻點播等係統。這種問題的解決要藉助於科學的軟件測試手段和先進的測試工具。\\n\\n舉例說明：電信計費軟件\\n\\n眾所周知,每月20日左右是市話交費的高峰期，全市幾千個收費網點同時啟動。收費過程一般分為兩步,首先要根據用戶提出的電話號碼來查詢出其當月產生費用,然後收取現金並將此用戶修改為已交費狀態。一個用戶看起來簡單的兩個步驟,但當成百上千的終端，同時執行這樣的操作時，情況就大不一樣了,如此眾多的交易同時發生,對應用程式本身、操作係統、中心數據庫服務器、中間件服務器、網絡設備的承受力都是一個嚴峻的考驗。決策者不可能在發生問題後才考慮係統的承受力,預見軟件的併發承受力,這是在軟件測試階段就應該解決的問題。\\n\\n效能測試圖像\\n\\n目前，大多數公司企業需要支援成百上千名用戶，各類應用環境以及由不同供\\n\\n效能測試圖像應商提供的元件組裝起來的複\\n\\n雜產品，難以預知的用戶負載和愈來愈複雜的應用程式，使公司擔憂會發生投放效能差、用戶遭受反應慢、係統失靈等問題。其結果就是導致公司收益的損失。\\n\\n如何模擬實際情況呢?找若乾颱電腦和同樣數目的操作人員在同一時刻進行操作,然後拿秒錶記錄下反應時間？這樣的手工作坊式的測試方法不切實際，且無法捕捉程式內部變化情況,這樣就需要壓力測試工具的輔助。\\n\\n測試的基本策略是自動負載測試，通過在一台或幾台PC機上模擬成百或上千的虛擬用戶同時執行業務的情景，對應用程式進行測試，同時記錄下每一事務處理的時間、中間件服務器峰值數據、數據庫狀態等。通過可重複的、真實的測試能夠徹底地度量應用的可擴展性和效能，確定問題所在以及優化係統效能。預先知道了係統的承受力,就為最終用戶規劃整個運行環境的配置提供了有力的依據。\\n\\n併發效能測試前的準備工作\\n\\n測試環境：配置測試環境是測試實施的一個重要階段，測試環境的適合與否會嚴重影響測試結果的真實性和正確性。測試環境包括硬體環境和軟件環境，硬體環境指測試必需的服務器、客戶端、網絡連接設備以及列印機\\/掃描儀等輔助硬體設備所構成的環境；軟件環境指被測軟件運行時的操作係統、數據庫及其他應用軟件構成的環境。\\n\\n一個充分準備好的測試環境有三個優點：一個穩定、可重複的測試環境，能夠保證測試結果的正確；保證達到測試執行的技術需求；保證得到正確的、可重複的以及易理解的測試結果。\\n\\n測試工具：併發效能測試是在客戶端執行的黑盒測試，一般不采用手工方式，而是利用工具采用自動化方式進行。目前，成熟的併發效能測試工具有很多，選擇的依據主要是測試需求和效能價格比。著名的併發效能測試工具有QALoad、LoadRunner、BenchmarkFactory和Webstress等。這些測試工具都是自動化負載測試工具，通過可重複的、真實的測試，能夠徹底地度量應用的可擴展性和效能，可以在整個開發生命週期、跨越多種平台、自動執行測試任務，可以模擬成百上千的用戶併發執行關鍵業務而完成對應用程式的測試。\\n\\n測試數據：在初始的測試環境中需要輸入一些適當的測試數據，目的是識彆數據狀態並且驗證用於測試的測試案例，在正式的測試開始以前對測試案例進行調試，將正式測試開始時的錯誤降到最低。在測試進行到關鍵過程環節時，非常有必要進行數據狀態的備份。製造初始數據意味著將合適的數據存儲下來，需要的時候恢複它，初始數據提供了一個基線用來評估測試執行的結果。\\n\\n在測試正式執行時，還需要準備業務測試數據，比如測試併發查詢業務，那麼要求對應的數據庫和表中有相當的數據量以及數據的種類應能覆蓋全部業務。\\n\\n模擬真實環境測試，有些軟件，特彆是麵向大眾的商品化軟件，在測試時常常需要考察在真實環境中的表現。如測試殺毒軟件的掃描速度時，硬盤上佈置的不同類型檔案的比例要儘量接近真實環境，這樣測試出來的數據纔有實際意義。\\n\\n併發效能測試的種類與指標\\n\\n併發效能測試的種類取決於併發效能測試工具監控的對象，以QALoad自動化負載測試工具為例。軟件針對各種測試目標提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、JavaScript等不同的監控對象，支援Windows和UNIX測試環境。\\n\\n最關鍵的仍然是測試過程中對監控對象的靈活應用，例如目前三層結構的運行模式廣泛使用，對中間件的併發效能測試作為問題被提到議事日程上來，許多係統都采用了國產中間件，選擇JavaScript監控對象，手工編寫腳本，可以達到測試目的。\\n\\n采用自動化負載測試工具執行的併發效能測試，基本遵循的測試過程有：測試需求與測試內容，測試案例製\\n\\n效能測試圖像\\n\\n定，測試環境準備，測試腳本錄製、編寫與調試，腳本分配、回放配置\\n\\n效能測試圖像與加\\n\\n載策略，測試執行跟蹤，結果分析與定位問題所在，測試報告與測試評估。\\n\\n併發效能測試監控的對象不同，測試的主要指標也不相同，主要的測試指標包括交易處理效能指標和UNIX資源監控。其中，交易處理效能指標包括交易結果、每分鐘交易數、交易響應時間（Min：最小服務器響應時間；Mean：平均服務器響應時間；Max：最大服務器響應時間；StdDev：事務處理服務器響應的偏差，值越大，偏差越大；Median：中值響應時間；90%：90%事務處理的服務器響應時間）、虛擬併發用戶數。\\n\\n應用實例：“新華社多媒體數據庫V1.0”效能測試\\n\\n中國軟件評測中心（CSTC）根據新華社技術局提出的《多媒體數據庫（一期）效能測試需求》和GB\\/T17544《軟件包質量要求和測試》的國家標準，使用工業標準級負載測試工具對新華社使用的“新華社多媒體數據庫V1.0”進行了效能測試。\\n\\n效能測試的目的是模擬多用戶併發訪問新華社多媒體數據庫，執行關鍵檢索業務，分析係統效能。\\n\\n效能測試的重點是針對係統併發壓力負載較大的主要檢索業務，進行併發測試和疲勞測試，係統采用B\\/S運行模式。併發測試設計了特定時間段內分彆在中文庫、英文庫、圖片庫中進行單檢索詞、多檢索詞以及變檢索式、混合檢索業務等併發測試案例。疲勞測試案例為在中文庫中併發用戶數200，進行測試週期約8小時的單檢索詞檢索。在進行併發和疲勞測試的同時，監測的測試指標包括交易處理效能以及UNIX（Linux）、Oracle、Apache資源等。\\n\\n測試結論：在新華社機房測試環境和內網測試環境中，100M帶寬情況下，針對規定的各併發測試案例，係統能夠承受併發用戶數為200的負載壓力，最大交易數\\/分鐘達到78.73，運行基本穩定，但隨著負載壓力增大，係統效能有所衰減。\\n\\n係統能夠承受200併發用戶數持續週期約8小時的疲勞壓力，基本能夠穩定運行。\\n\\n通過對係統UNIX（Linux）、Oracle和Apache資源的監控，係統資源能夠滿足上述併發和疲勞效能需求，且係統硬體資源尚有較大利用餘地。\\n\\n當併發用戶數超過200時，監控到HTTP500、connect和超時錯誤，且Web服務器報內存溢位錯誤，係統應進一步提高效能，以支援更大併發用戶數。\\n\\n建議進一步優化軟件係統，充分利用硬體資源，縮短交易響應時間。\\n\\n疲勞強度與大數據量測試\\n\\n疲勞測試是采用係統穩定運行情況下能夠支援的最大併發用戶數，持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來確定係統處理最大工作量強度效能的過程。\\n\\n效能測試圖像\\n\\n疲勞強度測試可以采用工具自動化的方式進行測試，也可以手\\n\\n效能測試圖像工編寫程\\n\\n序測試，其中後者占的比例較大。\\n\\n一般情況下以服務器能夠正常穩定響應請求的最大併發用戶數進行一定時間的疲勞測試，獲取交易執行指標數據和係統資源監控數據。如出現錯誤導致測試不能成功執行，則及時調整測試指標，例如降低用戶數、縮短測試週期等。還有一種情況的疲勞測試是對當前係統效能的評估，用係統正常業務情況下併發用戶數為基礎，進行一定時間的疲勞測試。\\n\\n大數據量測試可以分為兩種類型：針對某些係統存儲、傳輸、統計、查詢等業務進行大數據量的獨立數據量測試；與壓力效能測試、負載效能測試、疲勞效能測試相結合的綜合數據量測試方案。大數據量測試的關鍵是測試數據的準備，可以依靠工具準備測試數據。\\n\\n速度測試目前主要是針對關鍵有速度要求的業務進行手工測速度，可以在多次測試的基礎上求平均值，可以和工具測得的響應時間等指標做對比分析。\\n\\n應用在網絡上效能的測試\\n\\n應用在網絡上效能的測試重點是利用成熟先進的自動化技術進行網絡應用效能監控、網絡應用效能分析和網絡預測。\\n\\n網絡應用效能分析\\n\\n網絡應用效能分析的目的是準確展示網絡帶寬、延遲、負載和TCP的變化是如何影響用戶的響應時間的。利用網絡應用效能分析工具，例如ApplicationExpert，能夠發現應用的瓶頸，我們可知應用在網絡上運行時在每個階段發生的應用行為，在應用線程級分析應用的問題。可以解決多種問題：客戶端是否對數據庫服務器運行了不必要的請求？當服務器從客戶端接受了一個查詢，應用服務器是否花費了不可接受的時間聯絡數據庫服務器？在投產前預測應用的響應時間；利用ApplicationExpert調整應用在廣域網上的效能；ApplicationExpert能夠讓你快速、容易地模擬應用效能，根據最終用戶在不同網絡配置環境下的響應時間，用戶可以根據自己的條件決定應用投產的網絡環境。\\n\\n網絡應用效能監控\\n\\n在係統試運行之後，需要及時準確地瞭解網絡上正在發生什麼事情；什麼應用在運行，如何運行；多少PC正在訪問LAN或WAN；哪些應用程式導致係統瓶頸或資源競爭，這時網絡應用效能監控以及網絡資源管理對係統的正常穩定運行是非常關鍵的。利用網絡應用效能監控工具，可以達到事半功倍的效果，在這方麵我們可以提供的工具是NetworkVantage。通俗地講，它主要用來分析關鍵應用程式的效能，定位問題的根源是在客戶端、服務器、應用程式還是網絡。在大多數情況下用戶較關心的問題還有哪些應用程式占用大量帶寬，哪些用戶產生了最大的網絡流量，這個工具同樣能滿足要求。\\n\\n網絡預測\\n\\n考慮到係統未來發展的擴展性，預測網絡流量的變化、網絡結構的變化對用戶係統的影響非常重要。根據規劃數據進行預測並及時提供網絡效能預測數據。我們利用網絡預測分析容量規劃工具PREDICTOR可以作到：設置服務水平、完成日網絡容量規劃、離線測試網絡、網絡失效和容量極限分析、完成日常故障診斷、預測網絡設備遷移和網絡設備升級對整個網絡的影響。\\n\\n從網絡管理軟件獲取網絡拓撲結構、從現有的流量監控軟件獲取流量資訊（若冇有這類軟件可人工生成流量數據），這樣可以得到現有網絡的基本結構。在基本結構的基礎上，可根據網絡結構的變化、網絡流量的變化生成報告和圖表，說明這些變化是如何影響網絡效能的。PREDICTOR提供如下資訊：根據預測的結果幫助用戶及時升級網絡，避免因關鍵設備超過利用閥值導致係統效能下降；哪個網絡設備需要升級，這樣可減少網絡延遲、避免網絡瓶頸；根據預測的結果避免不必要的網絡升級。\\n\\n應用在服務器上效能的測試\\n\\n對於應用在服務器上效能的測試，可以采用工具監控，也可以使用係統本身的監控命令，例如Tuxedo中可\\n\\n效能測試圖像\\n\\n以使用Top命令監控資源使用情況。實施測試的目的是實現服務器\\n\\n效能測試圖像設備、服\\n\\n務器操作係統、數據庫係統、應用在服務器上效能的全麵監控，測試原理如下圖。\\n\\nUNIX資源監控指標和描述\\n\\n監控指標描述\\n\\n平均負載係統正常狀態下，最後60秒同步進程的平均個數\\n\\n衝突率在以太網上監測到的每秒衝突數\\n\\n進程\\/線程交換率進程和線程之間每秒交換次數\\n\\nCPU利用率CPU占用率（%）\\n\\n磁盤交換率磁盤交換速率\\n\\n接收包錯誤率接收以太網數據包時每秒錯誤數\\n\\n包輸入率每秒輸入的以太網數據包數目\\n\\n中斷速率CPU每秒處理的中斷數\\n\\n輸出包錯誤率發送以太網數據包時每秒錯誤數\\n\\n包輸入率每秒輸出的以太網數據包數目\\n\\n讀入內存頁速率物理內存中每秒讀入內存頁的數目\\n\\n寫出內存頁速率每秒從物理內存中寫到頁檔案中的內存頁數\\n\\n目或者從物理內存中刪掉的內存頁數目\\n\\n內存頁交換速率每秒寫入內存頁和從物理內存中讀出頁的個數\\n\\n進程入交換率交換區輸入的進程數目\\n\\n進程出交換率交換區輸出的進程數目\\n\\n係統CPU利用率係統的CPU占用率（%）\\n\\n用戶CPU利用率用戶模式下的CPU占用率（%）\\n\\n磁盤阻塞磁盤每秒阻塞的字節數\\n\\n效能測試的目的\\n\\n目的是驗證軟件係統是否能夠達到用戶提出的效能指標，同時發現軟件係統中存在的效能瓶頸，優化軟件，最後起到優化係統的目的。\\n\\n包括以下幾個方麵\\n\\n1．評估係統的能力，測試中得到的負荷和響應時間數據可以被用於驗證所計劃的模型的能力，並幫助作出決策。\\n\\n2．識彆體係中的弱點：受控的負荷可以被增加到一個極端的水平，並突破它，從而修複體係的瓶頸或薄弱的地方。\\n\\n3．係統調優：重複運行測試，驗證調整係統的活動得到了預期的結果，從而改進效能。\\n\\n檢測軟件中的問題：長時間的測試執行可導致程式發生由於內存泄露引起的失敗，揭示程式中的隱含的問題或衝突。\\n\\n4．驗證穩定性（resilience）可靠性（reliability）：在一個生產負荷下執行測試一定的時間是評估係統穩定性和可靠性是否滿足要求的唯一方法。\\n\\n效能測試的類型\\n\\n效能測試類型包括負載測試，強度測試，容量測試等。\\n\\n負載測試（LoadTesting）：負載測試是一種效能測試指數據在超負荷環境中運行，程式是否能夠承擔。負載測試強調的是係統能夠達到的峰值指標。\\n\\n強度測試（StressTesting）：強度測試是一種效能測試，他在係統資源特彆低的情況下軟件係統運行情況。強度測試強調的是係統在高負載情況下能夠穩定工作，即在極端情況下係統的穩定性。\\n\\n容量測試（VolumeTesting）：確定係統可處理同時在線的最大用戶數。\\n\\n效能測試觀察指標\\n\\n效能測試主要是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對係統的各項效能指標進行測試。負載測試和壓力測試都屬於效能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下係統的效能，目標是測試當負載逐漸增加時，係統各項效能指標的變化情況。壓力測試是通過確定一個係統的瓶頸或者不能接收的效能點，來獲得係統能提供的最大服務級彆的測試。\\n\\n在實際中作中我們經常會對兩種類型軟件進行測試：bs和cs，這兩方麵的效能指標一般需要哪些內容呢？\\n\\nBs結構程式一般會關注的通用指標如下（簡）：\\n\\nWeb服務器指標指標：\\n\\n*AvgRps:平均每秒鐘響應次數=總請求時間\\/秒數；\\n\\n*Avgtimetolastbyteperterstion（mstes）:平均每秒業務角本的迭代次數,有人會把這兩者混淆；\\n\\n*SuccessfulRounds：成功的請求；\\n\\n*FailedRounds：失敗的請求；\\n\\n*SuccessfulHits：成功的點擊次數；\\n\\n*FailedHits：失敗的點擊次數；\\n\\n*HitsPerSecond：每秒點擊次數；\\n\\n*SuccessfulHitsPerSecond：每秒成功的點擊次數；\\n\\n*FailedHitsPerSecond：每秒失敗的點擊次數；\\n\\n*AttemptedConnections：嘗試鏈接數；\\n\\nCS結構程式，由於一般軟件後台通常為數據庫，所以我們更注重數據庫的測試指標：\\n\\n*User0Connections：用戶連接數，也就是數據庫的連接數量；\\n\\n*Numberofdeadlocks：數據庫死鎖；\\n\\n*ButterCachehit：數據庫Cache的命中情況\\n\\n當然，在實際中我們還會察看多用戶測試情況下的內存，CPU，係統資源調用情況。這些指標其實是引申出\\n\\n效能測試圖像\\n\\n來效能測試中的一種：競爭測試。什麼是競爭測試，軟件競爭\\n\\n效能測試圖像使用各種資源\\n\\n（數據紀錄，內存等），看他與其他相關係統對資源的爭奪能力。\\n\\n我們知道軟件架構在實際測試中製約著測試策略和工具的選擇。如何選擇效能測試策略是我們在實際工作中需要瞭解的。一般軟件可以按照係統架構分成幾種類型：\\n\\nc\\/s\\n\\nclient\\/Server客戶端\\/服務器架構\\n\\n基於客戶端\\/服務器的三層架構\\n\\n基於客戶端\\/服務器的分散式架構\\n\\nb\\/s\\n\\n基於瀏覽器\\/Web服務器的三層架構\\n\\n基於中間件應用服務器的三層架構l\\n\\n基於Web服務器和中間件的多層架構l\\n\\n效能測試的步驟\\n\\n在每種不同的係統架構的實施中，開發人員可能選擇不同的實現方式，造成實際情況紛繁複雜。我們不可能對每種技術都詳細解說，這裡隻是介紹一種方法提供給你如何選擇測試策略，從而幫助分析軟件不同部分的效能指標，進而分析出整體架構的效能指標和效能瓶頸。\\n\\n由於工程和項目的不同，所選用的度量,評估方法也有不同之處。不過仍然有一些通用的步驟幫助我們完成一個效能測試項目。步驟如下\\n\\n1．製定目標和分析係統\\n\\n2．選擇測試度量的方法\\n\\n3．學習的相關技術和工具\\n\\n4．製定評估標準\\n\\n5．設計測試用例\\n\\n6．運行測試用例\\n\\n7．分析測試結果\\n\\n製定目標和分析係統\\n\\n每一個效能測試計劃中第一步都會製定目標和分析係統構成。隻有明確目標和瞭解係統構成纔會澄清測試範圍，知道在測試中要掌握什麼樣的技術。\\n\\n目標：\\n\\n1．確定客戶需求和期望\\n\\n2．實際業務需求\\n\\n3．係統需求\\n\\n係統組成\\n\\n係統組成這裡包含幾方麵含義：係統類彆，係統構成，係統功能等。瞭解這些內容的本質其實是幫助我們明確測試的範圍，選者適當的測試方法來進行測試。\\n\\n係統類彆：分清係統類彆是我們掌握什麼樣的技術的前提，掌握相應技術做效能測試纔可能成功。例如：係統類彆是bs結構,需要掌握http協議，java，html等技術。或者是cs結構，可能要瞭解操作係統，winsock，com等。所以甄彆係統類彆對於我們來說很重要。\\n\\n係統構成：硬體設置，操作係統設置是效能測試的製約條件，一般效能測試都是利用測試工具模仿大量的實際用戶操作，係統在超負荷情形下運作。不同的係統構成效能測試就會得到不同的結果。\\n\\n係統功能：係統功能指係統提供的不同子係統，辦公管理係統中的公文子係統，會議子係統等，係統工能是效能測試中要模擬的環節，瞭解這些是必要的。\\n\\n選擇測試度量的方法\\n\\n經過第一步，將會對係統有清醒的認識。接下來我們將把精力放在軟件度量上，收集係統相關的數據。\\n\\n度量的相關方麵：\\n\\n*製定規範\\n\\n*製定相關流程,角色，職責\\n\\n*製定改進策略\\n\\n*製定結果對比標準\\n\\n學習的相關技術和工具\\n\\n效能測試是通過工具，模擬大量用戶操作，對係統增加負載。所以需要掌握一定的工具知識才能進行效能測試。大家都知道效能測試工具一般通過winsock,http等協議記錄用戶操作。而協議選擇是基於軟件的係統架構實現（web一般選擇http協議,cs選擇winsock協議），不同的效能測試工具，腳本語言也不同，比如rationalrobot中vu腳本用類c語言實現。\\n\\n開展效能測試需要對各種效能測試工具進行評估，因為每一種效能測試工具都有自身的特點，隻有經過工具評估，才能選擇符合現有軟件架構的效能測試工具。確定測試工具後，需要組織測試人員進行工具的學習，培訓相關技術。\\n\\n製定評估標準\\n\\n任何測試的目的都是確保軟件符合預先規定的目標和要求。效能測試也不例外。所以必須製定一套標準。\\n\\n通常效能測試有四種模型技術可用於評估：\\n\\n效能測試圖像\\n\\n*線性投射：用大量的過去的，擴展的或者將來可能發生的數據組成\\n\\n效能測試圖像散佈\\n\\n圖，利用這個圖表不斷和係統的當前狀況對比。\\n\\n*分析模型：用排隊論公式和演算法預測響應時間，利用描述工作量的數據和係統本質關聯起來\\n\\n*模仿：模仿實際用戶的使用方法測試你的係統\\n\\n*基準：定義測試和你最初的測試作為標準，利用它和所有後來進行的測試結果進行對比\\n\\n設計測試用例\\n\\n設計測試用例是在瞭解軟件業務流程的基礎上。設計測試用例的原則是受最小的影響提供最多的測試資訊，設計測試用例的目標是一次儘可能的包含多個測試要素。這些測試用例必須是測試工具可以實現的，不同的測試場景將測試不同的功能。因為效能測試不同於平時的測試用例，儘可能把效能測試用例設計的複雜，纔有可能發現軟件的效能瓶頸。\\n\\n運行測試用例\\n\\n通過效能測試工具運行測試用例。同一環境下作的效能測試得到的測試結果是不準確的，所以在運行這些測試用例的時候，需要用不同的測試環境，不同的機器配置上運行。\\n\\n分析測試結果\\n\\n運行測試用例後，收集相關資訊，進行數據統計分析，找到效能瓶頸。通過排除誤差和其他因素，讓測試結果體現接近真實情況。不同的體繫結構分析測試結果的方法也不同，bs結構我們會分析網絡帶寬，流量對用戶操作響應的影響，而cs結構我們可能更關心會係統整體配置對用戶操作的影響。\\n\\n效能測試方法\\n\\n對於企業應用程式，有許多進行效能測試的方法，其中一些方法實行起來要比其他方法困難。所要進行的效能測試的類型取決於想要達到的結果。例如，對於可再現性，基準測試是最好的方法。而要從當前用戶負載的角度測試係統的上限，則應該使用容量規劃測試。本文將介紹幾種設置和運行效能測試的方法，並討論這些方法的區彆。\\n\\n如果不進行合理的規劃，對J2EE應用程式進行效能測試將會是一項令人望而生畏且有些混亂的任務。因為對於任何的軟件開發流程，都必須收集需求、理解業務需要，並在進行實際測試之前設計出正式的進度表。效能測試的需求由業務需要驅動，並由一組用例闡明。這些用例可以基於曆史數據（例如，服務器一週的負載模式）或預測的近似值。弄清楚需要測試的內容之後，就需要知道如何進行測試了。\\n\\n在開發階段前期，應該使用基準測試來確定應用程式中是否出現效能倒退。基準測試可以在一個相對短的時間內收集可重複的結果。進行基準測試的最好方法是，每次測試改變一個且隻改變一個參數。例如，如果想知道增加JVM內存是否會影響應用程式的效能，就逐次遞增JVM內存（例如，從1024MB增至1224MB，然後是1524MB，最後是2024MB），在每個階段收集結果和環境數據，記錄資訊，然後轉到下一階段。這樣在分析測試結果時就有跡可循。下一小節我將介紹什麼是基準測試，以及運行基準測試的最佳參數。\\n\\n開發階段後期，在應用程式中的bug已經被解決，應用程式達到一種穩定狀態之後，可以運行更為複雜的測試，確定係統在不同的負載模式下的表現。這些測試被稱為容量規劃測試、滲入測試(soaktest)、峰穀測試(peak-resttest)，它們旨在通過測試應用程式的可靠性、健壯性和可伸縮性來測試接近於現實世界的場景。對於下麵的描述應該從抽象的意義上理解，因為每個應用程式的使用模式都是不同的。例如，容量規劃測試通常都使用較緩慢的ramp-up（下文有定義），但是如果應用程式在一天之中的某個時段中有快速突發的流量，那麼自然應該修改測試以反映這種情況。但是，要記住，因為更改了測試參數（比如ramp-up週期或用戶的考慮時間(think-time)），測試的結果肯定也會改變。一個不錯的方法是，運行一係列的基準測試，確立一個已知的可控環境，然後再對變化進行比較。\\n\\n基準測試\\n\\n基準測試的關鍵是要獲得一致的、可再現的結果。可再現的結果有兩個好處：減少重新運行測試的次數；對測試的產品和產生的數字更為確信。使用的效能測試工具可能會對測試結果產生很大影響。假定測試的兩個指標是服務器的響應時間和吞吐量，它們會受到服務器上的負載的影響。服務器上的負載受兩個因素影響：同時與服務器通訊的連接（或虛擬用戶）的數目，以及每個虛擬用戶請求之間的考慮時間的長短。很明顯，與服務器通訊的用戶越多，負載就越大。同樣，請求之間的考慮時間越短，負載也越大。這兩個因素的不同組合會產生不同的服務器負載等級。記住，隨著服務器上負載的增加，吞吐量會不斷攀升，直到到達一個點。\\n\\n注意，吞吐量以穩定的速度增長，然後在某一個點上穩定下來。\\n\\n在某一點上，執行隊列開始增長，因為服務器上所有的線程都已投入使用，傳入的請求不再被立即處理，而是放入隊列中，當線程空閒時再處理。\\n\\n注意，最初的一段時間，執行隊列的長度為零，然後就開始以穩定的速度增長。這是因為係統中的負載在穩定增長，雖然最初係統有足夠的空閒線程去處理增加的負載，最終它還是不能承受，而必須將其排入隊列。\\n\\n當係統達到飽和點，服務器吞吐量保持穩定後，就達到了給定條件下的係統上限。但是，隨著服務器負載的繼續增長，係統的響應時間也隨之延長，雖然吞吐量保持穩定。\\n\\n注意，在執行隊列（圖2）開始增長的同時，響應時間也開始以遞增的速度增長。這是因為請求不能被及時處理。\\n\\n為了獲得真正可再現的結果，應該將係統置於相同的高負載下。為此，與服務器通訊的虛擬用戶應該將請求之間的考慮時間設為零。這樣服務器會立即超載，並開始構建執行隊列。如果請求（虛擬用戶）數保持一致，基準測試的結果應該會非常精確，完全可以再現。\\n\\n您可能要問的一個問題是：“如何度量結果？”對於一次給定的測試，應該取響應時間和吞吐量的平均值。精確地獲得這些值的唯一方法是一次加載所有的用戶，然後在預定的時間段內持續運行。這稱為“flat”測試。\\n\\n與此相對應的是“ramp-up”測試。\\n\\nramp-up測試中的用戶是交錯上升的（每幾秒增加一些新用戶）。ramp-up測試不能產生精確和可重現的平均值，這是因為由於用戶的增加是每次一部分，係統的負載在不斷地變化。因此，flat運行是獲得基準測試數據的理想模式。\\n\\n這不是在貶低ramp-up測試的價值。實際上，ramp-up測試對找出以後要運行的flat測試的範圍非常有用。ramp-up測試的優點是，可以看出隨著係統負載的改變，測量值是如何改變的。然後可以據此選擇以後要運行的flat測試的範圍。\\n\\nFlat測試的問題是係統會遇到“波動”效果。\\n\\n）\\n\\n注意波動的出現，吞吐量不再是平滑的。\\n\\n這在係統的各個方麵都有所體現，包括CPU的使用量。\\n\\n注意，每隔一段時間就會出現一個波形。CPU使用量不再是平滑的，而是有了像吞吐量圖那樣的尖峰。\\n\\n此外，執行隊列也承受著不穩定的負載，因此可以看到，隨著係統負載的增加和減少，執行隊列也在增長和縮減。\\n\\n注意，每隔一段時間就會出現一個波形。執行隊列曲線與上麵的CPU使用量圖非常相似。\\n\\n最後，係統中事務的響應時間也遵循著這個波動模式。\\n\\n注意，每隔一段時間就會出現一個波形。事務的響應時間也與上麵的圖類似，隻不過其效果隨著時間的推移逐漸減弱。\\n\\n當測試中所有的用戶都同時執行幾乎相同的操作時，就會發生這種現象。這將會產生非常不可靠和不精確的結果，所以必須采取一些措施防止這種情況的出現。有兩種方法可以從這種類型的結果中獲得精確的測量值。如果測試可以運行相當長的時間（有時是幾個小時，取決於用戶的操作持續的時間），最後由於隨機事件的本性使然，服務器的吞吐量會被“拉平”。或者，可以隻選取波形中兩個平息點之間的測量值。該方法的缺點是可以捕獲數據的時間非常短。\\n\\n效能規劃測試\\n\\n對於效能規劃類型的測試來說，其目標是找出，在特定的環境下，給定應用程式的效能可以達到何種程度。此時可重現性就不如在基準測試中那麼重要了，因為測試中通常都會有隨機因子。引入隨機因子的目的是為了儘量模擬具有真實用戶負載的現實世界應用程式。通常，具體的目標是找出係統在特定的服務器響應時間下支援的當前用戶的最大數。例如，您可能想知道：如果要以5秒或更少的響應時間支援8,000個當前用戶，需要多少個服務器？要回答這個問題，需要知道係統的更多資訊。\\n\\n要確定係統的容量，需要考慮幾個因素。通常，服務器的用戶總數非常大（以十萬計），但是實際上，這個數字並不能說明什麼。真正需要知道的是，這些用戶中有多少是併發與服務器通訊的。其次要知道的是，每個用戶的“考慮時間”即請求間時間是多少。這非常重要，因為考慮時間越短，係統所能支援的併發用戶越少。例如，如果用戶的考慮時間是1秒，那麼係統可能隻能支援數百個這樣的併發用戶。但是，如果用戶的考慮時間是30秒，那麼係統則可能支援數萬個這樣的併發用戶（假定硬體和應用程式都是相同的）。在現實世界中，通常難以確定用戶的確切考慮時間。還要注意，在現實世界中，用戶不會精確地按照間隔時間發出請求。\\n\\n於是就引入了隨機性。如果知道普通用戶的考慮時間是5秒，誤差為20%，那麼在設計負載測試時，就要確保請求間的時間為5×（1 \\/-20%）秒。此外，可以利用“調步”的理念向負載場景中引入更多的隨機性。它是這樣的：在一個虛擬用戶完成一整套的請求後，該用戶暫停一個設定的時間段，或者一個小的隨機時間段（例如，2×（1 \\/-25%）秒），然後再繼續執行下一套請求。將這兩種隨機化方法運用到測試中，可以提供更接近於現實世界的場景。\\n\\n現在該進行實際的容量規劃測試了。接下來的問題是：如何加載用戶以模擬負載狀態？最好的方法是模擬高峰時間用戶與服務器通訊的狀況。這種用戶負載狀態是在一段時間內逐步達到的嗎？如果是，應該使用ramp-up類型的測試，每隔幾秒增加x個用戶。或者，所有用戶是在一個非常短的時間內同時與係統通訊？如果是這樣，就應該使用flat類型的測試，將所有的用戶同時加載到服務器。兩種不同類型的測試會產生冇有可比性的不同測試。例如，如果進行ramp-up類型的測試，係統可以以4秒或更短的響應時間支援5,000個用戶。而執行flat測試，您會發現，對於5,000個用戶，係統的平均響應時間要大於4秒。這是由於ramp-up測試固有的不準確性使其不能顯示係統可以支援的併發用戶的精確數字。以門戶應用程式為例，隨著門戶規模的擴大和集群規模的擴大，這種不確定性就會隨之顯現。\\n\\n這不是說不應該使用ramp-up測試。對於係統負載在一段比較長的時間內緩慢增加的情況，ramp-up測試效果還是不錯的。這是因為係統能夠隨著時間不斷調整。如果使用快速ramp-up測試，係統就會滯後，從而報告一個較相同用戶負載的flat測試低的響應時間。那麼，什麼是確定容量的最好方法？結合兩種負載類型的優點，並運行一係列的測試，就會產生最好的結果。例如，首先使用ramp-up測試確定係統可以支援的用戶範圍。確定了範圍之後，以該範圍內不同的併發用戶負載進行一係列的flat測試，更精確地確定係統的容量。\\n\\n滲入測試\\n\\n滲入測試是一種比較簡單的效能測試。滲入測試所需時間較長，它使用固定數目的併發用戶測試係統的總體健壯性。這些測試將會通過內存泄漏、增加的垃圾收集(GC)或係統的其他問題，顯示因長時間運行而出現的任何效能降低。測試運行的時間越久，您對係統就越瞭解。運行兩次測試是一個好主意——一次使用較低的用戶負載（要在係統容量之下，以便不會出現執行隊列），一次使用較高的負載（以便出現積極的執行隊列）。\\n\\n測試應該運行幾天的時間，以便真正瞭解應用程式的長期健康狀況。要確保測試的應用程式儘可能接近現實世界的情況，用戶場景也要逼真（虛擬用戶通過應用程式導航的方式要與現實世界一致），從而測試應用程式的全部特性。確保運行了所有必需的監控工具，以便精確地監測並跟蹤問題。\\n\\n峰穀測試\\n\\n峰穀測試兼有容量規劃ramp-up類型測試和滲入測試的特征。其目標是確定從高負載（例如係統高峰時間的負載）恢複、轉為幾乎空閒、然後再攀升到高負載、再降低的能力。\\n\\n實現這種測試的最好方法就是，進行一係列的快速ramp-up測試，繼之以一段時間的平穩狀態（取決於業務需求），然後急劇降低負載，此時可以令係統平息一下，然後再進行快速的ramp-up；反覆重複這個過程。這樣可以確定以下事項：第二次高峰是否重現第一次的峰值？其後的每次高峰是等於還是大於第一次的峰值？在測試過程中，係統是否顯示了內存或GC效能降低的有關跡象？測試運行（不停地重複“峰值\\/空閒”週期）的時間越長，您對係統的長期健康狀況就越瞭解。\\n\\n效能測試工具介紹\\n\\n自動化測試工具介紹LR篇\\n\\nloadrunner啟動介麵\\n\\nloadrunner啟動介麵HPLoadRunner是一種預測係統行為和效能的負載測試工具。通過以模擬上千萬用戶實施併發負載及實時效能監測的方式來確認和查詢問題，LoadRunner能夠對整個企業架構進行測試。通過使用LoadRunner，企業能最大限度地縮短測試時間，優化效能和加速應用係統的釋出週期。\\n\\n目前企業的網絡應用環境都必須支援大量用戶，網絡體係架構中含各類應用環境且由不同供應商提供軟件和硬體產品。難以預知的用戶負載和愈來愈複雜的應用環境使公司時時擔心會發生用戶響應速度過慢，係統崩潰等問題。這些都不可避免地導致公司收益的損失。LoadRunner能讓企業保護自己的收入來源，無需購置額外硬體而最大限度地利用現有的IT資源，並確保終端用戶在應用係統的各個環節中對其測試應用的質量，可靠性和可擴展性都有良好的評價。\\n\\nLoadRunner是一種適用於各種體係架構的自動負載測試工具，它能預測係統行為並優化係統效能。LoadRunner的測試對象是整個企業的係統，它通過模擬實際用戶的操作行為和實行實時效能監測，來幫助您更快的查詢和發現問題。此外，LoadRunner能支援廣範的協議和技術，為您的特殊環境提供特殊的解決方案。\\n\\n輕鬆創建虛擬用戶\\n\\n使用LoadRunner的VirtualUserGenerator，您能很簡便地創立起係統負載。該引擎能夠生成虛擬用戶，以虛擬用戶的方式模擬真實用戶的業務操作行為。它先記錄下業務流程(如下訂單或機票預定)，然後將其轉化為測試腳本。利用虛擬用戶，您可以在Windows，UNIX或Linux機器上同時產生成千上萬個用戶訪問。所以LoadRunner能極大的減少負載測試所需的硬體和人力資源。另外，LoadRunner的TurboLoad專利技術能。\\n\\n提供很高的適應性。TurboLoad使您可以產生每天幾十萬名在線用戶和數以百萬計的點擊數的負載。\\n\\n用VirtualUserGenerator建立測試腳本後，您可以對其進行參數化操作，這一操作能讓您利用幾套不同的實際發生數據來測試您的應用程式，從而反映出本係統的負載能力。以一個訂單輸入過程為例，參數化操作可將記錄中的固定數據，如訂單號和客戶名稱，由可變值來代替。在這些變量內隨意輸入可能的訂單號和客戶名，來匹配多個實際用戶的操作行為。\\n\\nLoadRunner通過它的DataWizard來自動實現其測試數據的參數化。DataWizard直接連於數據庫服務器，從中您可以獲取所需的數據（如定單號和用戶名）並直接將其輸入到測試腳本。這樣避免了人工處理數據的需要，DataWizard為您節省了大量的時間。\\n\\n為了進一步確定您的Virtualuser能夠模擬真實用戶，您可利用LoadRunner控製某些行為特性。例如，隻需要點擊一下鼠標，您就能輕易控製交易的數量，交易頻率，用戶的思考時間和連接速度等。\\n\\n創建真實的負載\\n\\nVirtualusers建立起後，您需要設定您的負載方案，業務流程組合和虛擬用戶數量。用LoadRunner的Controller，您能很快組織起多用戶的測試方案。Controller的Rendezvous功能提供一個互動的環境，在其中您既能建立起持續且循環的負載，又能管理和驅動負載測試方案。\\n\\n而且，您可以利用它的日程計劃服務來定義用戶在什麼時候訪問係統以產生負載。這樣，您就能將測試過程自動化。同樣您還可以用Controller來限定您的負載方案，在這個方案中所有的用戶同時執行一個動作---如登陸到一個庫存應用程式----來模擬峰值負載的情況。另外，您還能監測係統架構中各個組件的效能----包括服務器，數據庫，網絡設備等----來幫助客戶決定係統的配置。\\n\\nLoadRunner通過它的AutoLoad技術，為您提供更多的測試靈活性。使用AutoLoad，您可以根據目前的用戶人數事先設定測試目標，優化測試流程。例如，您的目標可以是確定您的應用係統承受的每秒點擊數或每秒的交易量。\\n\\n定位效能問題\\n\\nLoadRunner內含整合的實時監測器，在負載測試過程的任何時候，您都可以觀察到應用係統的運行效能。這些效能監測器為您實時顯示交易效能數據（如響應時間）和其它係統組件包括applicationserver,webserver，網路設備和數據庫等的實時效能。這樣，您就可以在測試過程中從客戶和服務器的雙方麵評估這些係統組件的運行效能，從而更快地發現問題。\\n\\n再者，利用LoadRunner的ContentCheckTM，您可以判斷負載下的應用程式功能正常與否。ContentCheck在Virtualusers運行時，檢測應用程式的網絡數據包內容，從中確定是否有錯誤內容傳送出去。它的實時瀏覽器幫助您從終端用戶角度觀察程式效能狀況。\\n\\n分析結果以精確定位問題所在\\n\\n一旦測試完畢後，LoadRunner收集彙總所有的測試數據，併爲您提供高級的分析和報告工具，以便迅速查詢到效能問題並追溯原由。使用LoadRunner的Web交易細節監測器，您可以瞭解到將所有的圖象、框架和文字下載到每一網頁上所需的時間。例如，這個交易細節分析機製能\\n\\n夠分析是否因為一個大尺寸的圖形檔案或是第三方的數據組件造成應用係統運行速度減慢。另外，Web交易細節監測器分解用於客戶端、網絡和服務器上端到端的反應時間，便於確認問題，定位查詢真正出錯的組件。例如，您可以將網絡延時進行分解，以判斷DNS解析時間，連接服務器或SSL認證所花費的時間。通過使用LoadRunner的分析工具，您能很快地查詢到出錯的位置和原因並作出相應的調整。\\n\\n重複測試保證係統釋出的高效能\\n\\n負載測試是一個重複過程。每次處理完一個出錯情況，您都需要對您的應用程式在相同的方案下，再進行一次負載測試。以此檢驗您所做的修正是否改善了運行效能。\\n\\nEnterpriseJavaBeans的測試\\n\\nLoadRunner完全支援EJB的負載測試。這些基於Java的組件運行在應用服務器上，提供廣泛的應用服務。通過測試這些組件，您可以在應用程式開發的早期就確認並解決可能產生的問題。\\n\\n利用LoadRunner,您可以很方便地瞭解係統的效能。它的Controller允許您重複執行與出錯修改前相同的測試方案。它的基於HTML的報告為您提供一個比較效能結果所需的基準，以此衡量在一段時間內，有多大程度的改進並確保應用成功。由於這些報告是基於HTML的文字，您可以將其公佈於您公司的內部網上，便於隨時查閱。\\n\\n最大化投資回報\\n\\n所有MercuryInteractive的產品和服務都是整合設計的,能完全相容地一起運作。由於它們具有相同的核心技術，來自於LoadRunner和ActiveTestTM的測試腳本，在MercuryInteractive的負載測試服務項目中，可以被重複用於效能監測。藉助MercuryInteractive的監測功能－－TopazTM和ActiveWatchTM，測試腳本可重複使用從而平衡投資收益。更重要的是，您能為測試的前期佈署和生產係統的監測提供一個完整的應用效能管理解決方案。\\n\\n支援無線應用協議\\n\\n隨著無線設備數量和種類的增多，您的測試計劃需要同時滿足傳統的基於瀏覽器的用戶和無線互聯網設備，如手機和PDA。LoadRunner支援2項最廣泛使用的協議：WAP和I-mode。此外，通過負載測試係統整體架構，LoadRunner能讓您隻需要通過記錄一次腳本，就可完全檢測上述這些無線互聯網係統。\\n\\n支援MediaStream應用\\n\\nLoadRunner還能支援MediaStream應用。為了保證終端用戶得到良好的操作體驗和高質量MediaStream，您需要檢測您的MediaStream應用程式。使用LoadRunner，您可以記錄和重放任何流行的多媒體數據流格式來診斷係統的效能問題，查詢原由，分析數據的質量。\\n\\n完整的企業應用環境的支援。\\n\\nLoadRunner支援廣泛的協議，可以測試各種IT基礎架構。\\n\\n結束語\\n\\n本文介紹了進行效能測試的幾種方法。取決於業務需求、開發週期和應用程式的生命週期，對於特定的企業，某些測試會比其他的更適合。但是，對於任何情況，在決定進行某一種測試前，都應該問自己一些基本問題。這些問題的答案將會決定哪種測試方法是最好的。\\n\\n這些問題包括：\\n\\n結果的可重複性需要有多高？\\n\\n測試需要運行和重新運行幾次？\\n\\n您處於開放週期的哪個階段？\\n\\n您的業務需求是什麼？\\n\\n您的用戶需求是什麼？\\n\\n您希望生產中的係統在維護停機時間中可以持續多久？\\n\\n在一個正常的業務日，預期的用戶負載是多少？\\n\\n將這些問題的答案與上述效能測試類型相對照，應該就可以製定出測試應用程式的總體效能的完美計劃。\\n\\n效能測試是為描述測試對象與效能相關的特征並對其進行評價，而實施和執行的一類測試，如描述和評價計時配置檔案、執行流、響應時間以及操作的可靠性和限製等特征。不同類型的效能測試側重於不同的測試目標，這些效能測試的實施貫穿於整個軟件開發生命週期(SoftwareDevelopmentLifeCycle,SDLC)。起初，在構架迭代中，效能測試側重於確定和消除與構架有關的效能瓶頸。在構建迭代中還將實施和執行其他類型的效能測試，以調整軟件和環境（優化響應時間和資源），並覈實應用程式和係統是否能夠處理高負載和高強度的情況，如有大量事務、客戶機和\\/或數據的情況。\\n\\n效能測試的測試類型\\n\\n效能測試中包含以下測試類型：\\n\\n基準測試-比較新的或未知測試對象與已知參照標準（如現有軟件或評測標準）的效能。\\n\\n爭用測試：-覈實測試對象對於多個主角對相同資源（數據記錄、內存等）的請求的處理是否可以接受。\\n\\n效能配置-覈實在操作條件保持不變的情況下，測試對象在使用不同配置時其效能行為的可接受性。\\n\\n負載測試-覈實在保持配置不變的情況下，測試對象在不同操作條件（如不同用戶數、事務數等）下效能行為的可接受性。\\n\\n強度測試-覈實測試對象效能行為在異常或極端條件（如資源減少或用戶數過多）之下的可接受性。\\n\\n容量測試-覈實測試用戶同時使用軟件程式的最大數量。\\n\\n效能評價通常是和用戶代表一起協作並且以多級方法執行的。\\n\\n效能分析的第一級涉及單一主角\\/用例實例的結果評價和多個測試執行的結果比較。例如，在測試對象上冇有其他活動的情況下，記錄單一主角執行單一用例的效能行為，並將結果與相同主角\\/用例的其他幾個測試執行進行比較。第一級分析有助於確定可以表明係統資源中存在爭用的趨勢，該趨勢將影響從其他效能測試結果所得出的結論的有效性。\\n\\n分析的第二級檢查特定主角\\/用例執行的摘要統計資訊和實際數據值，以及測試對象的效能行為。摘要統計資訊包括響應時間的標準偏差和百分位分佈，這些資訊顯示了係統響應的變動情況，正如每個主角所見到的一樣。\\n\\n分析的第三級有助於理解效能問題的起因和加權值。該詳細分析采用低級數據並且使用統計方法，幫助測試員從數據中得出正確的結論。詳細分析為決策提供客觀和定量的標準，但是它耗時較長，並且要求對統計學有基本的理解。\\n\\n當效能行為差異確實存在，或是由於某些與測試數據收集相關的隨機事件引起時，詳細分析使用統計加權值的概念來幫助理解。即認為在基本級上，任何事件都具有隨機性。統計測試確定是否存在無法用隨機事件解釋的係統差異。\\n\\n效能測試中分析與調優過程的基本原則\\n\\n1）情況許可時，應使用幾種測試工具或手段分彆獨立進行測試，並將結果相互印證，避免單一工具或測試手段自身缺陷影響結果的準確性；\\n\\n2）對於不同的係統，效能關注點是有所區彆的，應該具體問題具體分析；\\n\\n3）查詢瓶頸的過程應由易到難逐步排查：\\n\\n服務器硬體瓶頸及網絡瓶頸（局域網環境下可以不考慮網絡因素）\\n\\n應用服務器及中間件操作係統瓶頸（數據庫、WEB服務器等參數配置）\\n\\n應用業務瓶頸（SQL語句、數據庫設計、業務邏輯、演算法、數據等）\\n\\n4）效能調優過程中不宜對係統的各種參數進行隨意的改動，應該以用戶配置手冊中相關參數設置為基礎，逐步根據實際現場環境進行優化，一次隻對某個領域進行效能調優（例如對CPU的使用情況進行分析），並且每次隻改動一個設置，避免相關因素互相乾擾；\\n\\n5）調優過程中應仔細進行記錄，保留每一步的操作內容及結果，以便比較分析；\\n\\n6）效能調優是一個經驗性的工作，需要多思考、分析、交流和積累；\\n\\n7）瞭解“有限的資源，無限的需求”；\\n\\n8）儘可能在開始前明確調優工作的終止標準。\\n\\n\"

}