性能測試十問：測試經理篇

　　現狀

　　測試經理不知道性能測試人員在做什么

　　不知道性能測試進展如何

　　不知道性能測試是否有效

　　不知道如何協助性能測試人員

　　本文目的

　　了解性能測試的進展，更好的控制整個測試流程

　　了解性能測試的質量

　　十問

　　性能測試何時介入

　　性能測試的過程是怎樣的

　　是否有必要提起性能測試

　　性能測試有哪些類型

　　如何分析性能需求

　　如何衡量性能

　　性能測試(不)能做什么

　　如何檢驗性能測試的質量

　　…

　　Q1、性能測試何時介入

　　開發生命周期中的性能測試

　　單元測試

　　代碼層面的測試。寫完一塊代碼，對代碼的執行效率、內存使用、資源占用等情況進行測試，由開發人員完成。

　　組件/服務/接口測試

　　此層面的測試，通常是針對一個已完成的公用功能，此功能向外提供服務或者接口。既可以是代碼級別的測試，也可以是不涉及代碼的調用測試(如webservice接口)，應由測試人員完成。

　　系統測試

　　整個系統已經實現，通過模擬用戶的使用對系統進行測試。我們做的性能測試主要就是這個，由測試人員完成。

　　生產環境測試

　　在系統測試通過的基礎上，構建出更完整的生產環境。比如一個生產環境，部屬多個系統，這些系統共同使用時可能會相互影響，需要考慮到此種情況進行測試。

　　系統測試中，何時介入呢

　　穩定版

　　→ 進入太晚，進度無法保證

　　→ 可能會影響到功能測試

　　這是測試負責人最害怕的，即測試晚期發現性能問題，修改涉及面較大，造成功能測試返工。

　　盡早

　　→ 流程可跑通

　　→ 數據無嚴重問題

　　等到穩定版再進入是不靠譜的，要盡早。

　　盡早到什么時候，性能測試需要哪些流程和數據呢?關注性能方案中的用戶模型。

　　Q2、性能測試的過程是怎樣的

　　敏捷方式的最大特點就是不斷確認、不斷修正、多次迭代。

　　在傳統方式的測試過程中，經常出現的問題恰恰是缺少了敏捷思想中的確認過程，導致了測試方向偏離、測試有效性不夠

　　當前進展到哪個階段?

　　文檔

　　步驟1～3

　　執行

　　步驟4～7

　　在傳統方式中，可以很簡單的將過程分為文檔和執行兩部分。文檔過程很容易被檢查，問題主要是在執行過程，這個過程有可能對測試經理是不可見的。

　　考慮這個問題：如果一次性能測試，沒有提起任何問題，是否在性能報告之前的執行過程是不可知的?

　　如果現有的工作方式確實存在這個問題，該如何解決呢?

　　這就需要依靠性能測試執行過程規范和檢查制度，請繼續往后看。

　　Q3、是否有必要提起性能測試?

　　新項目

　　目前基本都需要進行性能測試。

　　新版本(哪些變化可能涉及性能)→ 用戶量

　　用戶數的增加，如推廣使用、知名度提高。

　　→ 數據量

　　數據量的增加，如分布式部屬變成集中式部屬。

　　→ 實現改變

　　架構實現的變化，如音視頻點播系統更換了流媒體服務器。

　　測試負責人的疑問主要是新版本需不需要再做一次性能測試?比如只新增加了一個功能。

　　拋開上面提到的3個方面，新增功能或模塊可能會引起性能測試用戶模型的變化。如果經過確認，用戶模型無需變化，那自然也沒必要重新測試。如果用戶模型確實發生了改變，其實我覺得是有必要再次執行測試的，畢竟性能測試也算是一種自動化的測試，就應該能夠持續性的運行。

　　只不過我們現在的問題是，性能測試的復用性太低，基于HTTP請求的腳本很容易失效，測試環境也總需要重新搭建，這些因素導致了性能測試的成本和投入變大，即使只是增加了一個小功能，可能也需要重頭來做一次性能測試。如果有辦法改變這個狀況，那么每次新版本只要補充一下相關的測試代碼就可以了。

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