分析數據
性能測試流程中的第五步是分析收集到的數據。進行數據分析的方法有很多,取決于分析師的專業知識、整體的期望值、可接受的風險水平以及分配的時間。也許,最簡單的分析是對比即將發布的版本和過去發布的版本。例如,在過去發布的版本中,每秒可以執行50次查詢,而且沒有明顯的性能下降,而即將發布的版本每秒卻只能執行25次在詢,響應時間并沒有增加,這就說明可能存在問題。有趣的是下一步,即嘗試找出為什么會發生這種變化。
雖然吞吐量下降或者響應時間增加顯然都是應該進行進一步調在的情況, 不過與之相反的情況也應該加以調在。突然急劇增加也許說明一個特定的代碼路徑可能已經斷掉了,或者某個SQL條件失效了, 不過最好是他能夠注意到這些異常,并且能夠提出問題。況也是需要解釋的。我們希望在這些場景中,是由于工程師的確重構了代碼,提高了系統的性能,柱狀圖或餅圖中,更易于我們發現異常和差別。雖然這種方法也許有意義,也許沒有,但對于判 更詳細的分析會繪制數據的曲線圖,以便能直觀地在看它們。有時,把數據繪制為曲線圖、斯印將發布的版本來說,這酒常是種快捷的方法。還有各種統計學方法可用,如控制圖、檢驗、因子分析、主效應圍、方意分析和交互效應圖等。進行分析的報告目的包括確定法成所觀察的行為的因素是什么、待發布的版本是否與其他發布存在顯著差異,以及待發布的版本能否滿足服務協議水平等。
報告給工程師
性能測試流程的第六步是把結果報告給負責該次發布的軟件開發團隊。通常是以非正式的形式把結果報告給工程師,不過也可以在所有相關方都在場或者分成更小的團隊時做這個報告。這種會議的目標是讓每個提出的可能異常都得到處理,可能的情況會有如下三種。第一種情況是工程師對這種異常作出了解釋。對于這種情況,工程師必須有足夠的理由說明為什么測試結果與預期的不同,從而得到網站設計測試者和軟件開發團隊領導者的認同,可以通過這一測試,而不必采取進一步的行動。第二種情況是向工程師提出一個bug,以便他進一步調查這個問題,然后修復它,或者給出相應的解釋。第三種情況是軟件開發團隊請求額外的測試,以便得到更多的數據,用以幫助縮小找出真正問題的范圍。
本文地址:http://m.123beaconmarketing.com//article/3856.html