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