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