再談性能測試(2)

　　(表二)

　　看，是不是一樣的。所以說基本上所有類型的測試過程都是一樣的，不同的就是它們分別針對的是不同的系統特性。

　　性能測試為什么難?

　　雖然從上面的表二看上去性能測試和一般的功能測試沒有什么區別，但為什么大家都覺得性能測試難做呢?難點主要體現在一下幾個步驟中。

　　1 選擇性能測試功能點及確定性能接收標準

　　有些客戶的需求可能比較模糊，對于那些簡單而概括的性能要求(如“系統主要交易的響應時間不超過8秒”)我們必須有針對性的重點的進行選擇。當然如果客戶很清楚的表明具體需要測試的地方，這個步驟可以輕松很多了。

　　2 配置及維護測試環境

　　由于性能測試針對的是系統的性能問題，所以需要一個相對獨立的環境。加上對并發用戶數的要求，對網絡，服務器(應用，數據庫等)和客戶機的真實模擬，要求負責測試的人員具備良好的網絡，數據庫，系統架構，操作系統的等知識。

　　3 實現測試設計

　　測試環境搭建好后，需要根據測試計劃，測試用例進行實現。常見的主要是系統的部署，數據的插入及校驗，工具的安裝及檢查等。所以又要求負責測試的人員不但要具備良好的網絡，數據庫，系統架構，操作系統等知識，還要了解系統的組成，熟練的掌握測試工具。

　　4 繁瑣的測試運行及大量的報告處理

　　測試運行時及之后，負責測試的人員要非常的小心仔細的保留要所有的報告，耐心的多次運行以獲取比較準確的結果。

　　這里還有一個需要注意的地方，隨著測試工具和技術的不斷發展，如同功能測試一樣，大家越來越不滿足簡單的結論，如“用戶登陸的響應時間超過客戶要求的響應時間-8秒”。責任方越來越多的要求測試方可以提供更準確的資料以方便他們定位問題，所以測試方不單單分析客戶機上的數據，各個服務器也是分析的對象，以期能夠使修復方更快的定位問題。

　　5 分析測試結果

　　測試結果收集以后，就該處理，并得出結論。象所有的行業一樣，下結論是應該很慎重的，它需要多種工具或方法來輔助。常用的有統計學，還有概率。當然最后的結論必須是有根據的，也就是說你的結果應當象功能測試發現的bug一樣可以重現，否則單憑一兩次的異常就下結論，是無法說服別人的。

　　當然貫穿性能測試始終的是對性能測試流程，方法，工具等知識的掌握，測試方所應有的公證。

　　誰做性能測試?

　　首先，系統的各個特征(功能性，性能，可用性等)的實現及保障是整個團隊的事情，不是一個人的事情。性能測試簡單說來都是測試人員的工作，但是在實現的過程中，肯定需要開發人員，數據庫管理人員，項目經理，MIS部門的多方配合和幫助。如果有有意愿做測試，對系統了解的高級開發工程師最好不過了。

　　后記

　　其實自己的觀點很簡單，開發人員因為他豐富的開發知識(當然排除剛入行或比較初級的開發人員)和對系統架構及設計的了解，可以極大的保證性能測試的質量。而且當發現問題后，可以幫助開發人員做后續的系統調優。而且性能測試也應該摒著“盡早開始”的原則盡可能的早些在開發早期執行。我也因此將此劃入了性能測試的范疇，但是查找資料發現那其實是性能工程的內容，早已超越了性能測試的范圍。性能測試只是性能工程的一個子集?；氐阶畛?，性能測試和功能測試其實都是一樣的，計劃，設計并實現測試，發現問題，在問題解決后繼續確認問題是否修復，給出評估。

原文轉自：http://www.uml.org.cn/Test/200807231.asp