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/
