性能測試過程的六個階段

性能測試過程的六個階段性能測試的工作千頭萬緒，最怕的就是像無頭蒼蠅般盲目地測試，不但曠日費(fèi)時，還累積不到經(jīng)驗，團(tuán)隊與個人都難以成長，(下次再進(jìn)行性能測試時，還是亂測一通)。我們需要擬定步驟分階段執(zhí)行，如此才能循序漸進(jìn)，一步步向目標(biāo)前進(jìn)。根據(jù)微軟公司的研究顯示，性能測試的過程應(yīng)該為六個階段，分別是發(fā)現(xiàn)、探究、提案、執(zhí)行、復(fù)查、收尾。原文如下：1，Discovertheproblem：發(fā)現(xiàn)問題。這個步驟最重要的就是發(fā)現(xiàn)(Discover)問題，詳述(Discribe)問題，并且正確而詳細(xì)地記錄(Document)下來。在進(jìn)入下一步驟前，我們測試人員應(yīng)該問問自已以下這些問題：對于問題是否已經(jīng)有簡明的描述用戶的基線與期待在哪2，Exploretheconditions：探究原因，為問題提供明確的定義與定位。這個步驟的主要任務(wù)：是廣泛搜集相關(guān)數(shù)據(jù)，盡量了解系統(tǒng)的每一個方面，避免深入分析時，漏了某個關(guān)鍵的現(xiàn)象而誤入歧途；重點：是探索(Explore),尋找證據(jù)(Evidence),建立(Establish)整個問題的來龍去脈的假設(shè)。有的時候在這個階段就可以發(fā)現(xiàn)重大問題，一眼就看出關(guān)鍵點，例如硬件毀損，某個硬盤區(qū)塊或內(nèi)存塊不穩(wěn)，或某個其他程序吃掉所有的內(nèi)存，讓SQLServer無內(nèi)存可用，或是該程序常常死當(dāng)，拖垮CPU等等。3，Trackdownpossibleapproaches：提供可能的解決方案。這個步驟的主要任務(wù)：深入分析數(shù)據(jù)間的關(guān)聯(lián)性，并對整個問題的前因后果提出假設(shè)，最后擬定出相應(yīng)的策略(計劃)。如果前一個步驟做得不夠詳實，在這個步驟我們可能就會誤判，導(dǎo)致努力了半天，但就是找不到瓶頸點。這個步驟最重要的動作是：擬定計劃。一個好的計劃，你才能知道方向與步驟。4,Executethemostlikelyapproach：執(zhí)行最有可能的解決方案。這是DETECT方法中最簡單的一步，因為只要執(zhí)行上一步中所擬定的計劃就行了。但是在執(zhí)行計劃時，仍然要注意系統(tǒng)的反應(yīng)（隨時都可能會要放棄當(dāng)前的計劃，因為新的證據(jù)可能證明你先前的判斷錯誤，因而要修正計劃，甚至是退回到上一步以重新擬定計劃。這時切勿躁，因為整個性能測試的過程就是在考驗團(tuán)隊的細(xì)心與耐力、知識的廣度與深度?。瑫r還要小心觀察會不會有新的問題出現(xiàn)并嚴(yán)重影響當(dāng)前系統(tǒng)的執(zhí)行，不要原來系統(tǒng)遲緩，而你的測試卻成為壓垮駱駝的最后一根稻草。5,Checkforsuccess（如果需要的話，重復(fù)之前的步驟）：確認(rèn)解決方案成功與否。這一步驟主要任務(wù)是：重新收集數(shù)據(jù)，以驗證該計劃的成功與否。如果證實假設(shè)是對的，則繼續(xù)搜集相關(guān)數(shù)據(jù)，以確立接下來的步驟；如果到這一步發(fā)現(xiàn)執(zhí)行的結(jié)果不如預(yù)期，證明我們的假設(shè)錯誤。這會非常讓人氣餒,進(jìn)而放棄這個性能測試的方法，因為無法忍受整個時間的流失。其實，定錯性能的目標(biāo)是常有的事，這個方法論就是要你在錯誤的當(dāng)前，停下來好好思考，重新理出頭緒，最重要的是要清楚知道這一回是錯在哪，如此新的步驟就能更逼近目標(biāo)。有系統(tǒng)的犯錯，是整個計劃的一部分，踩著錯誤走向成功是性能測試的常態(tài)。6，Tieuplooseends：完成收尾工作。重復(fù)前五個步驟直到達(dá)到目標(biāo)。但當(dāng)我們完成目標(biāo)后，依然要注意以下的問題：解決的方式是否有邊際效應(yīng)，造成其他的問題例如：為了某類的查詢工作建立了大量的索引，事后原本正常的新建、修改、刪除都出現(xiàn)了性能問題。是否真正根除了問題，還是僅表象地頭痛醫(yī)頭，腳痛醫(yī)腳建立問題的假設(shè)時，很容易將問題特殊化，僅局部地解決該現(xiàn)象。例如：加了某個索引或稍稍改變查詢語法，舒緩了當(dāng)前的瓶頸，但當(dāng)用戶稍微增加，或是采用了不同的查詢方式，就老問題復(fù)發(fā)。是否要建立持續(xù)跟蹤的計劃當(dāng)你無法確定已經(jīng)根除問題，那可能就要擬定持續(xù)跟蹤的計劃。決定是否要持續(xù)觀查某些計數(shù)器，跟蹤某些現(xiàn)象是否還會發(fā)生，若發(fā)生了要如何解決等等。如此不但可以讓用戶安心，更可以讓你知道之前的行為到底有多少效益，下次的性能測試才有更完整的解決方式。性能測試及調(diào)校需要有耐心和毅力，能夠與用戶充分地溝通與協(xié)調(diào)，每一個步驟都小心翼翼，盡量擴(kuò)充團(tuán)隊的知識廣度與深度。這需要日常培養(yǎng)，并非一觸可及。在進(jìn)行性能測試和調(diào)校的過程中要有步驟，確定每一次的動作都讓你更接近目標(biāo)，妥善搜集各種信息，每一個測試動作都會影響系統(tǒng)本身，導(dǎo)致看到的現(xiàn)象都是系統(tǒng)與你互動的結(jié)果，小心不要被自己的盲動所誤導(dǎo)。另外：定義瓶頸，所謂瓶頸：就是整個系統(tǒng)原本可以流暢地執(zhí)行，但系統(tǒng)中若有一個點無法處理該需求量，導(dǎo)致整個系統(tǒng)執(zhí)行效率被卡住，該點就是瓶頸。所以定義瓶頸的定義如下：瓶頸=需求到達(dá)的處理量〉實際處理量(Throughput)以我們現(xiàn)今分布式運(yùn)算的系統(tǒng)而言，要找出整體流程卡在哪一點上，是蠻復(fù)雜的，因為系統(tǒng)的瓶頸點可能相當(dāng)多，所以我們要重點研究是卡在整體系統(tǒng)處理流程的哪一點上，比如web服務(wù)，其中的組成部分包括SQLServer/COM/IIS/IE,在整體的響應(yīng)時間中，如果IE花2秒鐘(因為PC老舊，而執(zhí)行動作很復(fù)雜)，ASP處理時間0.5秒,COM4秒鐘,SQLS