性能測試十問：測試經理篇(2)

　　我的想法是，性能測試要向組件/服務/接口級別靠近(見Q1)，越接近底層，可復用性也就越高。另外，企業級虛擬化的建設一定要跟上，這樣才不會在測試環境上浪費時間。

　　Q4、性能測試有哪些類型

　　基準測試

　　比如單用戶的測試或者在無數據條件下的測試，目的是提供一個標準供后續測試比對。

　　負載測試

　　向系統施加一定的壓力，一般最大壓力的20%或者日常使用壓力即可，確保系統可正常運轉。

　　壓力測試

　　向系統施加預期最大壓力，測試系統在繁忙狀態下的性能表現。

　　容量測試

　　不斷的增大對系統的壓力，直至出現瓶頸。用于探測系統的瓶頸，為系統的發展提供重要信息。

　　穩定性測試

　　長時間運行的穩定情況。

　　還有很多其他類型的測試，這里只是列出了幾種最常用到的，術語的定義可能也和其他資料有些差別，比如負載和壓力，不過無關緊要。

　　這里需要注意的一點，在負載、壓力和容量測試中，測試的依據都是用戶模型，只有用戶模型準確，測試的結果才會有意義。

　　提起性能測試，需要做那種測試呢?

　　一般來說，除了容量測試，其他幾種都是要做的，這是得到有效測試結果的必備過程。容量測試，屬于獲取“額外信息”的測試，不過這種測試其實是非常有價值的，很多資料都把它列為了必做之一。

　　穩定性測試需要運行多長時間?

　　之所以會有這個疑問，其實是因為測試人員提供的結果數據沒有說服力，不是證明了系統可以長期穩定運行，而只是下了個系統穩定的結論。

　　我也總和性能測試人員強調，測試的結果是要用數據來證明的，不是說測完了下一個通過的結論就可以了，這樣自然要被測試經理、開發經理懷疑(尤其是你是一個新人)。

　　如果能夠提供各種詳盡的數據，比如測試運行12小時內，操作系統的資源利用情況、應用中間件內部的資源利用情況、甚至是程序內部的一些性能指標等等，如果這些指標足夠代表系統的性能，且它們的表現是非常平穩的，那么完全可以從這個趨勢推斷出，即使系統運行更長的時間也將是穩定的。

　　反之，如果不提供數據，而只是描述測試運行了3天，那么自然會有“3天夠不夠長”的疑問，只有通過“足夠長”的運行時間才能減少人們的顧慮。

　　Q5、如何分析性能需求

　　性能相關需求一般由需求人員提供，測試負責人是這些需求的第一個把關人。針對這些需求，測試負責人可以分析哪些內容呢?

　　是否全面

　　用戶角度

　　→ 能不能

　　→ 快不快

　　業務角度

　　→ 吞吐量、TPS、每小時完成工作量

　　→ 處理壓力的方式

　　如12306購票，當壓力太大的時候，是讓所有人都能得到非常慢的服務，還是保證一部分人可以正常使用、另外的人停止服務?

　　技術角度

　　→ 是否使用了某些有潛在風險的技術

　　→ 系統內部的一些資源

　　其他角度

　　→ 比如系統擁有者，要求服務器資源利用率60%左右，想想為什么?

　　是否有效

　　可行性

　　要求發送短信后能即時到達。這就是不可行的需求，因為涉及到運營商的網絡。

　　可量化

　　郵件發出后，較短的時間內到達。

　　是否靈活

　　需求vs.期望

　　→ 需求是必須要達到的。比如發送即時消息，必須保證沒有丟失，這時可能就要有一個到達率的指標，如果達不到100%，那就是不合格。

　　→ 期望是靈活的，比如頁面響應時間3s以內，這就是一個期望，不會因為最后是3.2s而影響結論或者導致延期發布。

　　Q6、如何衡量性能

　　性能的評價標準

　　用戶感受

　　用戶實際的感受是最權威的評價標準。

　　明確的性能指標

　　但大多數情況無法用實際感受來進行衡量，所以我們需要能夠有效代替“感受”的數據，也就是各種性能指標。

　　性能指標一般有哪些

　　響應時間

　　業務類web系統一般主要耗時在服務端，所以通常獲取請求的響應時間即可，這是不涉及到客戶端展現的。

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