你離一名優(yōu)秀的測試經(jīng)理,只有這8個(gè)問題的距離
讓數(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é)議
- 目前還沒評(píng)論,等你發(fā)揮!