讓數(shù)據(jù)證明結(jié)論，而不是下結(jié)論。

1、性能測試何時介入

開發(fā)生命周期中的性能測試

單元測試

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

組件/服務/接口測試

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

系統(tǒng)測試

整個系統(tǒng)已經(jīng)實現(xiàn)，通過模擬用戶的使用對系統(tǒng)進行測試。我們做的性能測試主要就是這個，由測試人員完成。

生產(chǎn)環(huán)境測試

在系統(tǒng)測試通過的基礎(chǔ)上，構(gòu)建出更完整的生產(chǎn)環(huán)境。比如一個生產(chǎn)環(huán)境，部屬多個系統(tǒng)，這些系統(tǒng)共同使用時可能會相互影響，需要考慮到此種情況進行測試。

系統(tǒng)測試中，何時介入呢？

穩(wěn)定版

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

→ 可能會影響到功能測試

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

盡早

→ 流程可跑通

→ 數(shù)據(jù)無嚴重問題

等到穩(wěn)定版再進入是不靠譜的，要盡早。

盡早到什么時候，性能測試需要哪些流程和數(shù)據(jù)呢？關(guān)注性能方案中的用戶模型。

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

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

在傳統(tǒng)方式的測試過程中，經(jīng)常出現(xiàn)的問題恰恰是缺少了敏捷思想中的確認過程，導致了測試方向偏離、測試有效性不夠。

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

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

如果現(xiàn)有的工作方式確實存在這個問題，該如何解決呢？

這就需要依靠性能測試執(zhí)行過程規(guī)范和檢查制度，請繼續(xù)往后看。

3、是否有必要提起性能測試？

新項目

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

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

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

→ 數(shù)據(jù)量

數(shù)據(jù)量的增加，如分布式部屬變成集中式部屬。

→ 實現(xiàn)改變

架構(gòu)實現(xiàn)的變化，如音視頻點播系統(tǒng)更換了流媒體服務器。

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

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

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

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

4、性能測試有哪些類型

基準測試

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

負載測試

向系統(tǒng)施加一定的壓力，一般最大壓力的20％或者日常使用壓力即可，確保系統(tǒng)可正常運轉(zhuǎn)。

壓力測試

向系統(tǒng)施加預期最大壓力，測試系統(tǒng)在繁忙狀態(tài)下的性能表現(xiàn)。

容量測試

不斷的增大對系統(tǒng)的壓力，直至出現(xiàn)瓶頸。用于探測系統(tǒng)的瓶頸，為系統(tǒng)的發(fā)展提供重要信息。

穩(wěn)定性測試

長時間運行的穩(wěn)定情況。

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

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

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

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

穩(wěn)定性測試需要運行多長時間？

之所以會有這個疑問，其實是因為測試人員提供的結(jié)果數(shù)據(jù)沒有說服力，不是證明了系統(tǒng)可以長期穩(wěn)定運行，而只是下了個系統(tǒng)穩(wěn)定的結(jié)論。

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

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

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

5、如何分析性能需求

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

用戶角度

→ 能不能

→ 快不快

業(yè)務角度

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

→ 處理壓力的方式

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

技術(shù)角度

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

→ 系統(tǒng)內(nèi)部的一些資源

其他角度

→ 比如系統(tǒng)擁有者，要求服務器資源利用率60％左右，想想為什么？

可行性

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

可量化

郵件發(fā)出后，較短的時間內(nèi)到達。

需求vs.期望

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

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

6、如何衡量性能

• 性能的評價標準
• 用戶感受
• 用戶實際的感受是最權(quán)威的評價標準。
• 明確的性能指標

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

性能指標一般有哪些？

響應時間

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

頁面展現(xiàn)時間

互聯(lián)網(wǎng)網(wǎng)站通常最關(guān)注展現(xiàn)時間，一般有更具體的指標如首屏展現(xiàn)時間。大家用一用淘寶或者京東就能理解了。

吞吐量

業(yè)務上的需求，比如百度一定會有每秒鐘處理多少萬次搜索請求這類的指標。

特定需求的評估標準

如上面舉的例子，消息到達率。

這些對性能的評價標準，應該在測試設(shè)計時就明確下來，測試負責人可對此進行檢查。

有一點需要注意的是，性能指標是否可檢測。通用的指標如頁面響應時間很容易獲取，所有的測試工具都可以做到。但一些特殊的指標，尤其是涉及到客戶端的，可能會存在技術(shù)上的問題。比如即時通訊軟件的測試中，要求最大壓力時，發(fā)送信息能夠在1s內(nèi)到達。

那么這個到達時間如何獲取呢？如果沒有提前做好準備，在測試執(zhí)行時很可能會遇到問題，而測試人員遇到這個問題，很有可能會選擇忽視它，只顧把壓力加上去就算測完了。

7、性能測試（不）能做什么

web系統(tǒng)性能測試

最常見的目的是模擬用戶的實際行為，獲取用戶的感受。

如何模擬用戶的實際行為

建立用戶模型。即用戶做什么操作、操作路徑是什么、操作頻率……

如何建立用戶模型

• 常用業(yè)務
• 性能敏感業(yè)務
• 關(guān)鍵業(yè)務
• 特殊關(guān)注

這里只是用戶模型覆蓋度的問題，實際使用的用戶模型還需要很多其他信息才能建立起來。

測試負責人需要重點關(guān)注和確認用戶模型的建立。

性能測試的覆蓋率

由上可知，性能測試只能覆蓋系統(tǒng)的一部分功能。不要指望所有和性能相關(guān)的問題都由性能測試來發(fā)現(xiàn)。

性能測試最最想發(fā)現(xiàn)的是瓶頸，而不是缺陷。

我比較害怕聽到這樣的話，“生產(chǎn)環(huán)境的一個操作很慢，去做下性能測試吧”。

8、如何檢驗性能測試的質(zhì)量

• 執(zhí)行過程
• 建立執(zhí)行規(guī)范
• 明確定義執(zhí)行過程各檢查點需要的輸出物
• 指派檢查人員
• 根據(jù)執(zhí)行規(guī)范進行檢查
• 輸出執(zhí)行記錄

測試人員都知道，設(shè)計的用例和實際的執(zhí)行總是不一樣的。性能測試更是如此，調(diào)整參數(shù)重新運行腳本也是一次執(zhí)行，這些信息必須有清晰的記錄。

• 持續(xù)交互確認
• 性能報告

讓數(shù)據(jù)證明結(jié)論，而不是下結(jié)論。

作者：陳迪 Derek，Testin云測SaaS運營總監(jiān)，前樂視高級運營經(jīng)理，增長黑客， 加拿大MBA海歸，多年國內(nèi)和海外互聯(lián)網(wǎng)公司運營經(jīng)驗。曾在北美B2C 100強公司任運營管理工作?；貒?，曾多次創(chuàng)業(yè)，并參與多個互聯(lián)網(wǎng)公司運營咨詢工作。

本文由 @陳迪 Derek? 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0 協(xié)議

愛盈利-運營小咖秀(www.jza6.com) 始終堅持研究分享移動互聯(lián)網(wǎng)App運營推廣經(jīng)驗、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運營從業(yè)者的知識啟蒙、成長指導、進階學習的集聚平臺；

想了解更多移動互聯(lián)網(wǎng)干貨知識，請關(guān)注微信公眾號運營小咖秀（ID: yunyingshow）