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

1、性能測試何時(shí)介入

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

單元測試

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

組件/服務(wù)/接口測試

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

系統(tǒng)測試

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

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

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

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

穩(wěn)定版

→ 進(jìn)入太晚，進(jìn)度無法保證

→ 可能會(huì)影響到功能測試

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

盡早

→ 流程可跑通

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

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

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

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

敏捷方式的最大特點(diǎn)就是不斷確認(rèn)、不斷修正、多次迭代。

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

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

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

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

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

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

新項(xiàng)目

目前基本都需要進(jìn)行性能測試。

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

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

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

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

→ 實(shí)現(xiàn)改變

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

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

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

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

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

4、性能測試有哪些類型

基準(zhǔn)測試

比如單用戶的測試或者在無數(shù)據(jù)條件下的測試，目的是提供一個(gè)標(biāo)準(zhǔn)供后續(xù)測試比對(duì)。

負(fù)載測試

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

壓力測試

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

容量測試

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

穩(wěn)定性測試

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

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

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

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

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

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

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

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

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

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

5、如何分析性能需求

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

用戶角度

→ 能不能

→ 快不快

業(yè)務(wù)角度

→ 吞吐量、TPS、每小時(shí)完成工作量

→ 處理壓力的方式

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

技術(shù)角度

→ 是否使用了某些有潛在風(fēng)險(xiǎn)的技術(shù)

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

其他角度

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

可行性

要求發(fā)送短信后能即時(shí)到達(dá)。這就是不可行的需求，因?yàn)樯婕暗竭\(yùn)營商的網(wǎng)絡(luò)。

可量化

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

需求vs.期望

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

→ 期望是靈活的，比如頁面響應(yīng)時(shí)間3s以內(nèi)，這就是一個(gè)期望，不會(huì)因?yàn)樽詈笫?.2s而影響結(jié)論或者導(dǎo)致延期發(fā)布。

6、如何衡量性能

• 性能的評(píng)價(jià)標(biāo)準(zhǔn)
• 用戶感受
• 用戶實(shí)際的感受是最權(quán)威的評(píng)價(jià)標(biāo)準(zhǔn)。
• 明確的性能指標(biāo)

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

性能指標(biāo)一般有哪些？

響應(yīng)時(shí)間

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

頁面展現(xiàn)時(shí)間

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

吞吐量

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

特定需求的評(píng)估標(biāo)準(zhǔn)

如上面舉的例子，消息到達(dá)率。

這些對(duì)性能的評(píng)價(jià)標(biāo)準(zhǔn)，應(yīng)該在測試設(shè)計(jì)時(shí)就明確下來，測試負(fù)責(zé)人可對(duì)此進(jìn)行檢查。

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

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

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

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

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

如何模擬用戶的實(shí)際行為

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

如何建立用戶模型

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

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

測試負(fù)責(zé)人需要重點(diǎn)關(guān)注和確認(rèn)用戶模型的建立。

性能測試的覆蓋率

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

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

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

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

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

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

• 持續(xù)交互確認(rèn)
• 性能報(bào)告

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

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

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

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