根據系統的規模、你從每種測試得到的信息的相對價(jià)值、你可用的時(shí)間多少以及組織愿意接受的風(fēng)險大小，最終確定了測試計劃后，你就可以進(jìn)入第四步，即真正執行測試。在這一一步中，你將根據測試計劃，在專(zhuān)為測試建立的環(huán)境中系統地執行各種測試，并且把各種衡量指標記錄下來(lái)，如交易時(shí)間、響應時(shí)間、輸出和反應等。所有數據都要被收集起來(lái)，在性能測試中，數據是你的朋友，你真正能得到的不過(guò)如此。保存每次發(fā)布之前的測試數據是很重要的。我們將在下一步中介紹，對比各個(gè)發(fā)布版本對于理解數據以及判斷數據是在正常范圍內還是說(shuō)明出現了問(wèn)題，至關(guān)重要。



分析數據

性能測試流程中的第五步是分析收集到的數據。進(jìn)行數據分析的方法有很多，取決于分析師的專(zhuān)業(yè)知識、整體的期望值、可接受的風(fēng)險水平以及分配的時(shí)間。也許，最簡(jiǎn)單的分析是對比即將發(fā)布的版本和過(guò)去發(fā)布的版本。例如，在過(guò)去發(fā)布的版本中，每秒可以執行50次查詢(xún)，而且沒(méi)有明顯的性能下降，而即將發(fā)布的版本每秒卻只能執行25次在詢(xún)，響應時(shí)間并沒(méi)有增加，這就說(shuō)明可能存在問(wèn)題。有趣的是下一步，即嘗試找出為什么會(huì )發(fā)生這種變化。
 
雖然吞吐量下降或者響應時(shí)間增加顯然都是應該進(jìn)行進(jìn)一步調在的情況， 不過(guò)與之相反的情況也應該加以調在。突然急劇增加也許說(shuō)明一個(gè)特定的代碼路徑可能已經(jīng)斷掉了，或者某個(gè)SQL條件失效了， 不過(guò)最好是他能夠注意到這些異常，并且能夠提出問(wèn)題。況也是需要解釋的。我們希望在這些場(chǎng)景中，是由于工程師的確重構了代碼，提高了系統的性能，柱狀圖或餅圖中，更易于我們發(fā)現異常和差別。雖然這種方法也許有意義，也許沒(méi)有，但對于判 更詳細的分析會(huì )繪制數據的曲線(xiàn)圖，以便能直觀(guān)地在看它們。有時(shí)，把數據繪制為曲線(xiàn)圖、斯印將發(fā)布的版本來(lái)說(shuō)，這酒常是種快捷的方法。還有各種統計學(xué)方法可用，如控制圖、檢驗、因子分析、主效應圍、方意分析和交互效應圖等。進(jìn)行分析的報告目的包括確定法成所觀(guān)察的行為的因素是什么、待發(fā)布的版本是否與其他發(fā)布存在顯著(zhù)差異，以及待發(fā)布的版本能否滿(mǎn)足服務(wù)協(xié)議水平等。

報告給工程師

性能測試流程的第六步是把結果報告給負責該次發(fā)布的軟件開(kāi)發(fā)團隊。通常是以非正式的形式把結果報告給工程師，不過(guò)也可以在所有相關(guān)方都在場(chǎng)或者分成更小的團隊時(shí)做這個(gè)報告。這種會(huì )議的目標是讓每個(gè)提出的可能異常都得到處理，可能的情況會(huì )有如下三種。第一種情況是工程師對這種異常作出了解釋。對于這種情況，工程師必須有足夠的理由說(shuō)明為什么測試結果與預期的不同，從而得到網(wǎng)站設計測試者和軟件開(kāi)發(fā)團隊領(lǐng)導者的認同，可以通過(guò)這一測試，而不必采取進(jìn)一步的行動(dòng)。第二種情況是向工程師提出一個(gè)bug，以便他進(jìn)一步調查這個(gè)問(wèn)題，然后修復它，或者給出相應的解釋。第三種情況是軟件開(kāi)發(fā)團隊請求額外的測試，以便得到更多的數據，用以幫助縮小找出真正問(wèn)題的范圍。