起因
現狀
-
測試經理不知道性能測試人員在做什么
-
不知道性能測試進展如何
-
不知道性能測試是否有效
-
不知道如何協助性能測試人員
本文目的
-
了解性能測試的進展，更好的控制整個測試流程
-
了解性能測試的質量
十問
-
性能測試何時介入
-
性能測試的過程是怎樣的
-
是否有必要提起性能測試
-
性能測試有哪些類型
-
如何分析性能需求
-
如何衡量性能
-
性能測試（不）能做什么
-
如何檢驗性能測試的質量
-
…
Q1.性能測試何時介入
開發生命周期中的性能測試
- 單元測試
代碼層面的測試。寫完一塊代碼，對代碼的執行效率、內存使用、資源占用等情況進行測試，由開發人員完成。 - 組件/服務/接口測試
此層面的測試，通常是針對一個已完成的公用功能，此功能向外提供服務或者接口。既可以是代碼級別的測試，也可以是不涉及代碼的調用測試（如webservice接口），應由測試人員完成。 - 系統測試
整個系統已經實現，通過模擬用戶的使用對系統進行測試。我們做的性能測試主要就是這個，由測試人員完成。 - 生產環境測試
在系統測試通過的基礎上，構建出更完整的生產環境。比如一個生產環境，部屬多個系統，這些系統共同使用時可能會相互影響，需要考慮到此種情況進行測試。
系統測試中，何時介入呢
- 穩定版
- 進入太晚，進度無法保證
- 可能會影響到功能測試
這是測試負責人最害怕的，即測試晚期發現性能問題，修改涉及面較大，造成功能測試返工。
- 盡早
- 流程可跑通
- 數據無嚴重問題
等到穩定版再進入是不靠譜的，要盡早。
盡早到什么時候，性能測試需要哪些流程和數據呢？關注性能方案中的用戶模型。
Q2.性能測試的過程是怎樣的
| 傳統 | 敏捷 |
 |
 |
敏捷方式的最大特點就是不斷確認、不斷修正、多次迭代。
在傳統方式的測試過程中，經常出現的問題恰恰是缺少了敏捷思想中的確認過程，導致了測試方向偏離、測試有效性不夠。
當前進展到哪個階段？
- 文檔
步驟1～3 - 執行
步驟4～7
在傳統方式中，可以很簡單的將過程分為文檔和執行兩部分。文檔過程很容易被檢查，問題主要是在執行過程，這個過程有可能對測試經理是不可見的。
考慮這個問題：如果一次性能測試，沒有提起任何問題，是否在性能報告之前的執行過程是不可知的？
如果現有的工作方式確實存在這個問題，該如何解決呢？
這就需要依靠性能測試執行過程規范和檢查制度，請繼續往后看。
Q3.是否有必要提起性能測試？
- 新項目
目前基本都需要進行性能測試。 - 新版本
（哪些變化可能涉及性能） - 用戶量
用戶數的增加，如推廣使用、知名度提高。 - 數據量
數據量的增加，如分布式部屬變成集中式部屬。 - 實現改變
架構實現的變化，如音視頻點播系統更換了流媒體服務器。
測試負責人的疑問主要是新版本需不需要再做一次性能測試？比如只新增加了一個功能。
拋開上面提到的3個方面，新增功能或模塊可能會引起性能測試用戶模型的變化。如果經過確認，用戶模型無需變化，那自然也沒必要重新測試。如果用戶模型確實發生了改變，其實我覺得是有必要再次執行測試的，畢竟性能測試也算是一種自動化的測試，就應該能夠持續性的運行。
只不過我們現在的問題是，性能測試的復用性太低，基於HTTP請求的腳本很容易失效，測試環境也總需要重新搭建，這些因素導致了性能測試的成本和投入變大，即使只是增加了一個小功能，可能也需要重頭來做一次性能測試。如果有辦法改變這個狀況，那么每次新版本只要補充一下相關的測試代碼就可以了。
我的想法是，性能測試要向組件/服務/接口級別靠近（見Q1），越接近底層，可復用性也就越高。另外，企業級虛擬化的建設一定要跟上，這樣才不會在測試環境上浪費時間。
Q4.性能測試有哪些類型
- 基准測試
比如單用戶的測試或者在無數據條件下的測試，目的是提供一個標准供后續測試比對。 - 負載測試
向系統施加一定的壓力，一般最大壓力的20％或者日常使用壓力即可，確保系統可正常運轉。 - 壓力測試
向系統施加預期最大壓力，測試系統在繁忙狀態下的性能表現。 - 容量測試
不斷的增大對系統的壓力，直至出現瓶頸。用於探測系統的瓶頸，為系統的發展提供重要信息。 - 穩定性測試
長時間運行的穩定情況。
還有很多其他類型的測試，這里只是列出了幾種最常用到的，術語的定義可能也和其他資料有些差別，比如負載和壓力，不過無關緊要。
這里需要注意的一點，在負載、壓力和容量測試中，測試的依據都是用戶模型，只有用戶模型准確，測試的結果才會有意義。
提起性能測試，需要做那種測試呢？
一般來說，除了容量測試，其他幾種都是要做的，這是得到有效測試結果的必備過程。容量測試，屬於獲取“額外信息”的測試，不過這種測試其實是非常有價值的，很多資料都把它列為了必做之一。
穩定性測試需要運行多長時間？
之所以會有這個疑問，其實是因為測試人員提供的結果數據沒有說服力，不是證明了系統可以長期穩定運行，而只是下了個系統穩定的結論。
我也總和性能測試人員強調，測試的結果是要用數據來證明的，不是說測完了下一個通過的結論就可以了，這樣自然要被測試經理、開發經理懷疑（尤其是你是一個新人）。
如果能夠提供各種詳盡的數據，比如測試運行12小時內，操作系統的資源利用情況、應用中間件內部的資源利用情況、甚至是程序內部的一些性能指標等等，如果這些指標足夠代表系統的性能，且它們的表現是非常平穩的，那么完全可以從這個趨勢推斷出，即使系統運行更長的時間也將是穩定的。
反之，如果不提供數據，而只是描述測試運行了3天，那么自然會有“3天夠不夠長”的疑問，只有通過“足夠長”的運行時間才能減少人們的顧慮。
Q5.如何分析性能需求
性能相關需求一般由需求人員提供，測試負責人是這些需求的第一個把關人。針對這些需求，測試負責人可以分析哪些內容呢？
是否全面
- 用戶角度
- 能不能
- 快不快
- 業務角度
- 吞吐量、TPS、每小時完成工作量
- 處理壓力的方式
如12306購票，當壓力太大的時候，是讓所有人都能得到非常慢的服務，還是保證一部分人可以正常使用、另外的人停止服務？
- 技術角度
- 是否使用了某些有潛在風險的技術
- 系統內部的一些資源
- 其他角度
- 比如系統擁有者，要求服務器資源利用率60％左右，想想為什么？
是否有效
- 可行性
要求發送短信后能即時到達。這就是不可行的需求，因為涉及到運營商的網絡。 - 可量化
郵件發出后，較短的時間內到達。
是否靈活
- 需求vs.期望
- 需求是必須要達到的。比如發送即時消息，必須保證沒有丟失，這時可能就要有一個到達率的指標，如果達不到100％，那就是不合格。
- 期望是靈活的，比如頁面響應時間3s以內，這就是一個期望，不會因為最后是3.2s而影響結論或者導致延期發布。
Q6.如何衡量性能
性能的評價標准
- 用戶感受
用戶實際的感受是最權威的評價標准。 - 明確的性能指標
但大多數情況無法用實際感受來進行衡量，所以我們需要能夠有效代替“感受”的數據，也就是各種性能指標。
性能指標一般有哪些
- 響應時間
業務類web系統一般主要耗時在服務端，所以通常獲取請求的響應時間即可，這是不涉及到客戶端展現的。 - 頁面展現時間
互聯網網站通常最關注展現時間，一般有更具體的指標如首屏展現時間。大家用一用淘寶或者京東就能理解了。 - 吞吐量
- TPS
業務上的需求，比如百度一定會有每秒鍾處理多少萬次搜索請求這類的指標。 - 特定需求的評估標准
如上面舉的例子，消息到達率。
這些對性能的評價標准，應該在測試設計時就明確下來，測試負責人可對此進行檢查。
有一點需要注意的是，性能指標是否可檢測。通用的指標如頁面響應時間很容易獲取，所有的測試工具都可以做到。但一些特殊的指標，尤其是涉及到客戶端的，可能會存在技術上的問題。比如即時通訊軟件的測試中，要求最大壓力時，發送信息能夠在1s內到達。那么這個到達時間如何獲取呢？如果沒有提前做好准備，在測試執行時很可能會遇到問題，而測試人員遇到這個問題，很有可能會選擇忽視它，只顧把壓力加上去就算測完了。
Q7.性能測試（不）能做什么
web系統性能測試
最常見的目的是模擬用戶的實際行為，獲取用戶的感受。
如何模擬用戶的實際行為
建立用戶模型。即用戶做什么操作、操作路徑是什么、操作頻率……
如何建立用戶模型
- 常用業務
- 性能敏感業務
- 關鍵業務
- 特殊關注
這里只是用戶模型覆蓋度的問題，實際使用的用戶模型還需要很多其他信息才能建立起來。
測試負責人需要重點關注和確認用戶模型的建立。
性能測試的覆蓋率
由上可知，性能測試只能覆蓋系統的一部分功能。不要指望所有和性能相關的問題都由性能測試來發現。
性能測試最最想發現的是瓶頸，而不是缺陷。
我比較害怕聽到這樣的話，“生產環境的一個操作很慢，去做下性能測試吧”。
Q8.如何檢驗性能測試的質量
執行過程
- 建立執行規范
明確定義執行過程各檢查點需要的輸出物 - 指派檢查人員
根據執行規范進行檢查 - 輸出執行記錄
測試人員都知道，設計的用例和實際的執行總是不一樣的。性能測試更是如此，調整參數重新運行腳本也是一次執行，這些信息必須有清晰的記錄。 - 持續交互確認
性能報告
- 讓數據證明結論，而不是下結論
TO DO
這是在部門內做的一次培訓交流，聽眾是測試經理。這里把PPT改成文檔了，居然用了一天工時……
給這個培訓起了個名字，叫性能測試十問，結果自己只整理出了8個。留下2個名額給大家吧：）