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