做了幾次簡單的性能測試，沉淀了一點小經(jīng)驗，也踩過些小坑。
1、性能測試實際的測試時間，通常比我預估的測試時間更久。
性能測試是一個獨立于功能測試的部分，我在做測試的時候，性能測試往往是安排在第一輪測試周期中的，但是，千萬不要用功能測試的周期去對待性能測試。它是一個完整的、獨立的事件，沒有二輪，沒有回歸測試！
新手測試，很容易遇到忽視或看輕造數(shù)據(jù)的時間、不明確測試的方法等問題。
預估測試時間，可分為幾個步驟：
- 明確測試場景、測試數(shù)據(jù)量、測試要求
- 準備測試環(huán)境
- 準備測試數(shù)據(jù)的腳本
- 造數(shù)據(jù)所需時間
- 準備測試腳本
- 測試腳本的執(zhí)行時間
- 獲取測試結(jié)果的方式
- 分析測試結(jié)果
- 發(fā)送測試報告
2、造數(shù)據(jù)、調(diào)腳本，你真的熟練嗎？
前期做單一場景的性能測試時，只需要調(diào)用一個http接口，copy一下請求頭就可以執(zhí)行，如此簡單，讓我以為所有的性能測試都可以這么簡單。太天真了好嗎，調(diào)用鏈路長的你試試，調(diào)腳本都調(diào)哭我了好嗎。TT
- 造數(shù)據(jù)
兩種造數(shù)據(jù)的方式：
1、調(diào)用接口
2、直接sql插入
兩種方式各有利弊吧，如果操作鏈路較長，調(diào)接口造數(shù)據(jù)經(jīng)常會遇到調(diào)用失敗的情況，想造100條數(shù)據(jù)，往往會因為各種原因，失敗成70、80條；用sql插入數(shù)據(jù)，就要涉及到大數(shù)據(jù)量的組裝，整不好還得寫個腳本來幫忙，不過成功率會比調(diào)接口好很多。
- 登錄
涉及到登錄，參數(shù)化http頭信息就很麻煩了。需要分析到請求頭里的cookies，token，獲取session，來參數(shù)化http頭信息。
- 獲取上一個請求的返回值，進行參數(shù)化，傳入下一個請求
1、正則表達式提取器。能夠幫你在各種返回信息中過濾出有用的信息。
2、json提取器。提取json格式返回時常用，寫法簡單，和json的語法類似。
- 定時器
設(shè)置一個固定定時器，可以防止請求響應太慢，拿不到返回結(jié)果。
- 響應斷言
判斷請求是否成功，是否有想得到的數(shù)據(jù)。
- 計數(shù)器
可以用來設(shè)置自增的數(shù)據(jù)，例如要造數(shù)據(jù)為「測試-001」至「測試-099」，即可使用如下設(shè)置，引用時，使用「測試-${cnt-customer}」即可。
3、測試執(zhí)行
- 流程控制
1、 if 循環(huán)控制器
2、 while循環(huán)控制器 語法是JavaScript，如果不會寫，可以用函數(shù)助手中的__javascript幫你生成
- 當腳本中有可無限成立的等式時，可以用「調(diào)度器配置」執(zhí)行腳本，循環(huán)次數(shù)設(shè)置為1，設(shè)置持續(xù)時間來控制腳本的執(zhí)行時間。
- 當需要腳本執(zhí)行多次時，設(shè)置循環(huán)次數(shù)為多次即可。這個比較常用，不寫了。
4、性能測試分析時的小經(jīng)驗
首先要明確做的是對比測試還是第一次優(yōu)化的性能測試。（這是我所接觸項目的類型，其他類型的測試先不敢說話。）
如果是對比測試，數(shù)據(jù)量可以不需要一次性定太大，適量，然后對比響應時間即可。
有對比的測試是指啥樣的測試
A、相同環(huán)境下相同請求對比測試
B、相同測試環(huán)境下相似業(yè)務對比測試
- 明確所需要的測試環(huán)境
cpu的核數(shù)和內(nèi)存大小
- 數(shù)據(jù)準備：直接從數(shù)據(jù)庫導出數(shù)據(jù)，sublime text處理數(shù)據(jù)
- 服務器掛掉一次后，就對半減少測試數(shù)據(jù)
- 后端返回結(jié)果較快的情況下，關(guān)注前臺的渲染時間
- http接口測試還是RPC接口測試
- 是否依賴其他環(huán)境
5、測試結(jié)果分析及優(yōu)化方向
grep后臺請求，查看后臺服務的流轉(zhuǎn)過程，分析耗時較長的請求在哪里。
1、建議代碼優(yōu)化
2、耗時較長的請求分批處理
