一. 性能測試
1.0 為什么要進行性能測試？
- 評估當前系統的能力
- 尋找性能瓶頸，優化系統性能
- 評估軟件是否滿足未來的需要
- 招聘需要
1.1 什么是性能
時間：系統處理用戶請求的響應時間
資源：系統運行過程中，系統資源的消耗情況
1.2. 性能測試是什么
1.2.1 廣義定義
基于協議模擬用戶發出請求，對服務器形成一定負載，來測試服務器的性能指標是否滿足要求性能指標關注點：時間性能、空間性能性能測試與頁面無關
1.2.1 狹義定義
指通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。
1.3 功能和性能測試
- 不同
功能測試驗證系統的功能需求規格，聚焦功能。
性能測試驗證系統的業務性需求場景，聚焦時間和資源。 - 關系
一般項目中，先功能測試通過后，后進行性能測試。
1.4 性能測試的分類
1.4.1 基準測試
狹義：單用戶測試
廣義：建立基準線，當系統軟硬件環境發生變化之后再進行一次基準測試以確定變化對性能的影響。
1.4.2 負載測試
概念
通過逐步增加系統負載，確定在滿足性能指標的情況下，找出系統所能承受最大負載量的測試。作用
系統最大負載量達到用戶要求時，系統才能正式上線使用。-
案例
電梯行業規范：電梯從1樓到5樓的運行時間不超過24s1人 20s 7人 20s 13人 20s 達到最大負載 16人 25s 19人 28s 21人 斷繩子 注意
通過負載測試，可以確定系統的最大負載量和極限負載量
系統對外宣稱的最大負載量
負載測試的時間一般為1-2小時
1.4.3 穩定性測試
- 概念：在服務器穩定運行（用戶正常業務負載下）的情況進行長時間測試（1天-一周等），并最終保證服務器能滿足線上業務需求。
- 系統在用戶需求的業務負載下運行達到規定的時間時，系統才能正式上線使用。
1.4.4 壓力測試
- 概念：在強負載下的測試，查看系統在峰值下是否功能隱患、系統是否具有良好的容錯能力和可恢復的能力。
- 測試場景
高負載下的長時間穩定性壓力測試 （如：B-C區間內進行24/3*24小時長時間測試）
極限負載下的破壞性壓力測試（如：C-D區間內進行測試）
1.4.5 并發測試
- 概念：在極短時間內，發送多個請求，來驗證服務器對并發的處理能力。
- 應用場景
特定的活動場景：搶紅包、秒殺、搶購等。 - 與負載測試對比：
負載測試：主要目的是測試高負載情況下，對系統資源的消耗，是否會耗盡的問題（雙11活動）
并發測試：主要目的是測試極短時間內，并發請求時，系統資源爭搶的問題（搶紅包、秒殺）
1.5 性能測試的指標
1.5.1 響應時間
- 指從客戶端發起請求開始，到客戶端接收到結果的總時間
- 包括：服務器處理時間 + 網絡傳輸時間
1.5.2 并發用戶數
某一時刻同時向服務器發送請求的用戶數
1.5.3 吞吐量（Throughout）
1.概念：單位時間內處理客戶端的請求數量，直接體現軟件系統能能承載能力。
- 吞吐量單位分類
1.5.4 QPS
QPS（Query Per Second）每秒查詢數，即控制服務器每秒處理的指定請求的數量。
1.5.5 TPS
TPS（Transaction Per Second）每秒事務數，即控制服務器每秒處理事務請求的數量。
如：支付請求事務=查詢用戶余額請求+校驗支付安全請求+發送支付請求
每秒處理查詢用戶余額15請求，每秒處理校驗支付安全15個請求，每秒處理發送支付15個請求
支付tsp為15
1.5.6 點擊數
所有的頁面元素（如：圖片、鏈接、框架等）的請求總數量
- 注意：
- 點擊數是請求數，不是頁面上的一次點擊
1.5.7 錯誤率
- 指系統在負載情況下，失敗業務的概率
- 注意：
- 錯誤率是性能指標，是高負載下的失敗業務的概率
-隨機bug是功能bug，先解決隨機bug才能進行性能測試
1.5.8 資源利用率
- 概念：系統各種資源的使用情況，率=資源使用量/總資源可用量x100%
- 常見資源指標
CPU使用率：不高于75%-85%
內存大小使用率：不高于80%
磁盤IO（速率）：不高于90%
網路（速率）：不高于80%
1.6 性能測試工具
二. Jmeter簡介
2.1. 我們為什么使用Jmeter
開源，免費，基于Java編寫，可集成到其他系統可拓展各個功能插件
支持接口測試，壓力（負載和壓力）測試等多種功能，支持錄制回放，
入門簡單相較于自己編寫框架活其他開源工具，有較為完善的UI界面，便于接口調試
多平臺支持，可在Linux，Windows，Mac上運行，支持多協議
2.2. Jmeter的作用
- 接口測試 面試說postman，因為方便好用。
- 性能測試 jmeter，也可以用postman（runner），但是沒有性能指標
- 數據庫測試
2.3. Jmeter怎么用
Windows下Jmeter下載安裝，登錄 http://jmeter.apache.org/download_jmeter.cgi ，根據自己平臺，下載對應文件
2.4. 安裝JAVA環境
安裝JDK，配置環境變量（具體步驟不做介紹）
將下載Jmeter文件解壓，打開/bin/jmeter.bat
2.5. Jmeter的目錄結構
/bin 目錄常用文件介紹：
examples：目錄下包含Jmeter使用實例
ApacheJMeter.jar：JMeter源碼包
jmeter.bat：windows下啟動文件
jmeter.sh：Linux下啟動文件
jmeter.log：Jmeter運行日志文件
jmeter.properties：Jmeter配置文件
jmeter-server.bat：windows下啟動負載生成器服務文件
jmeter-server：Linux下啟動負載生成器文件
/docs目錄——Jmeter幫助文檔
/extras目錄——提供了對Ant的支持文件，可也用于持續集成
/lib目錄——存放Jmeter依賴的jar包，同時安裝插件也放于此目錄
/licenses目錄——軟件許可文件，不用管
/printable_docs目錄——Jmeter用戶手冊
三. 使用Jmeter測試快速入門
3.1. 線程組是什么
進程： 一個正在執行的程序對應一個進程
線程： 一個進程有多個執行線程
線程組： 按照線程性質對線程分組。查看任務管理器（愛奇藝有多個）
三者關系： 一個進程有多個線程組，一個線程組有多個線程
測試計劃—線程組—線程組屬性中的線程數
并發執行：多個線程同時執行，特點：執行結束的順序與開始的順序不一致
順序執行：按照線程的啟動順序挨個執行
默認情況下，線程組中的線程是并發執行
每一個線程都要執行組內的http請求
設置線程組順序執行：勾選測試計劃中的（獨立運行每個線程組）
線程組用來模擬用戶的并發訪問
3.1.1. 創建線程組
3.1.2. 線程組主要包含三個參數：
線程數、準備時長(Ramp-Up Period(in seconds))、循環次數。
3.1.3. 線程數：
虛擬用戶數。一個虛擬用戶占用一個線程。設置多少虛擬用戶數在這里也就是設置多少個線程數。
3.1.4. 準備時長（秒）：
設置的虛擬用戶數需要多長時間全部啟動。如果線程數為20 ，準備時長為10 ，那么需要10秒鐘啟動20個線程。也就是每秒鐘啟動2個線程。
3.1.5. 循環次數：
每個線程發送請求的次數。如果線程數為20 ，循環次數為100 ，那么每個線程發送100次請求。總請求數為20*100=2000 。如果勾選了“永遠”，那么所有線程會一直發送請求，一直到選擇停止運行腳本。
3.1.6. 調度器
設置線程組啟動的開始時間和結束時間(配置調度器時，需要勾選循環次數為永遠)
3.1.7. 持續時間（秒）
測試持續時間，會覆蓋結束時間
3.1.8. 啟動延遲（秒）
測試延遲啟動時間，會覆蓋啟動時間
3.1.9. 啟動時間
測試啟動時間，啟動延遲會覆蓋它。當啟動時間已過，手動只需測試時當前時間也會覆蓋它。
3.1.10. 結束時間
測試結束時間，持續時間會覆蓋它。
3.2. 創建http請求
見得最多，所以我們著重講解：
3.3. 指定請求域名，請求路徑
| 一個HTTP請求有著許多的配置參數，下面將詳細介紹： |
|---|
| 名稱：本屬性用于標識一個取樣器，建議使用一個有意義的名稱。 |
| 注釋：對于測試沒有任何作用，僅用戶記錄用戶可讀的注釋信息。 |
| 服務器名稱或IP ：HTTP請求發送的目標服務器名稱或IP地址。 |
| 端口號：目標服務器的端口號。 |
| 方法：發送HTTP請求的方法，可用方法包括GET、POST、HEAD、PUT、OPTIONS、TRACE、DELETE等。 |
| Content encoding ：內容的編碼方式，默認值為iso8859 |
| 路徑：目標URL路徑(不包括服務器地址和端口) |
點擊run測試，很麻煩，我們使用postman測試更簡單，使用postman操作。
可以使用剛才的接口文檔中的，聚合接口中演示一個。
3.4. 設置對應的查看內容
注意：如果監聽器中有jp@gc開頭的，都是第三方插件
3.5. 查看表格信息
| Sample：每個請求的序號 |
|---|
| Start Time：每個請求開始時間 |
| Thread Name：每個線程的名稱 |
| Label：Http請求名稱 |
| Sample Time：每個請求所花時間，單位毫秒 |
| Status：請求狀態，如果為勾則表示成功，如果為叉表示失敗。 |
| Bytes：請求的字節數 |
| 樣本數目：也就是上面所說的請求個數，成功的情況下等于你設定的并發數目乘以循環次數 |
| 平均：每個線程請求的平均時間 |
| 最新樣本：表示服務器響應最后一個請求的時間 |
| 偏離：服務器響應時間變化、離散程度測量值的大小，或者，換句話說，就是數據的分布。 |
3.6. 查看結果樹
-
請求的數據展示(請求頭信息，請求參數,,)
image -
響應的數據展示(響應碼，響應頭,,)
image通過察看結果樹，我們可以看到每個請求的結果，其中紅色的是出錯的請求，綠色的為通過。
Thread Name：線程組名稱
Sample Start: 啟動開始時間
Load time：加載時長
Latency：等待時長
Size in bytes：發送的數據總大小
Headers size in bytes：發送數據的其余部分大小
Sample Count：發送統計
Error Count：交互錯誤統計
Response code：返回碼
Response message：返回信息
Response headers：返回的頭部信息
3.7. 聚合報告參數說明
| lable：對應每一個http請求，顯示的是http請求的Name，如百度http請求name為baidu |
|---|
| #Samples：表示這一次的測試中一共發出了多少請求，如上圖所示，sougou和baidu的http請求每個都發出30個請求 |
| Average：平均響應時間，指的是所有的請求的平均響應時間，如上圖的30個請求的總的響應時間除以30得出的平均響應時間，默認的情況下是單個請求的平均響應時間，但當使用了“事務控制器”時，則以事物為單位顯示平均響應時間 |
| Median：中位數，也就是50%用戶的響應時間 |
| 90%Line：90%用戶的響應時間 |
| Min：最小響應時間 |
| Max：最大的響應時間 |
| Error%：本次測試中出現錯誤的請求的數量/請求的總數，如上圖所示，本次的測試中，sougou的http請求66.6%的請求出錯，而baidu的請求則沒有出錯的請求 |
| Throughput：吞吐量，默認情況下表示每秒完成的請求數，如上圖所示，每秒完成的請求數分別為6.6個每秒，6.2個每秒 |
| Recived KB/Sec：每秒從服務器端接收到的數據量，以kb為計算的單位 |
掌握：平均時間、錯誤率、吞吐量。
3.8. 圖形結果
作用：通過圖形展示出本次性能測試數據的分布。 圖形結果一般作為聚合報告的分析輔佐
樣本數目：總共發送到服務器的請求數。
最新樣本：代表時間的數字，是服務器響應最后一個請求的時間。
吞吐量：服務器每分鐘處理的請求數。
平均值：總運行時間除以發送到服務器的請求數。
中間值：有一半的服務器響應時間低于該值而另一半高于該值。
偏離：表示服務器響應時間變化、離散程度測量值的大小。
四. Jmeter主要組件介紹
- 測試計劃：使用 JMeter 進行測試的起點，它是其它 JMeter 測試元件的容器。
- 線程組：代表一定數量的并發用戶，它可以用來模擬并發用戶發送請求。實際的請求內容在Sampler中定義，它被線程組包含。可以在“測試計劃->添加->線程組”來建立它，然后在線程組面板里有幾個輸入欄：線程數、Ramp-Up Period(in seconds)、循環次數，其中Ramp-Up Period(in seconds)表示在這時間內創建完所有的線程。如有8個線程，Ramp-Up = 200秒，那么線程的啟動時間間隔為200/8=25秒，這樣的好處是：一開始不會對服務器有太大的負載。線程組是為模擬并發負載而設計。
- 取樣器（Sampler）：模擬各種請求。所有實際的測試任務都由取樣器承擔，存在很多種請求。如：HTTP 、ftp請求等等。
- 監聽器：負責收集測試結果，同時也被告知了結果顯示的方式。功能是對取樣器的請求結果顯示、統計一些數據（吞吐量、KB/S……）等。
- 斷言：用于來判斷請求響應的結果是否如用戶所期望，是否正確。它可以用來隔離問題域，即在確保功能正確的前提下執行壓力測試。這個限制對于有效的測試是非常有用的。
- 邏輯控制器：允許自定義JMeter發送請求的行為邏輯，它與Sampler結合使用可以模擬復雜的請求序列。
- 定時器：負責定義請求（線程）之間的延遲間隔，模擬對服務器的連續請求。
- 配置元件維護Sampler需要的配置信息，并根據實際的需要會修改請求的內容。
- 前置處理器和后置處理器負責在生成請求之前和之后完成工作。前置處理器常常用來修改請求的設置，后置處理器則常常用來處理響應的數據。
4.1. 測試計劃
1.測試計劃就是一個完整的場景
2.“獨立運行每個線程組” ：勾選以后所有的線程組都是順序執行的了。一般不勾選，讓所有 的線程組并發啟動。
3.“函數測試模式” ：勾選后會有詳細的請求記錄，消耗資源，影響客戶端性能。一般不勾選。
4.用戶定義的變量：全局變量，測試計劃上可以添加用戶定義的變量。一般添加一些系統常用的配置。如果測試過程中想切換環境，切換配置，一般不建議在測試計劃上添加變量
4.2. 線程組
（1）thread group(線程組)
這個就是我們通常添加運行的線程。通俗的講一個線程組，可以看做一個虛擬用戶組，線程組中的每個線程都可以理解為一個虛擬用戶。
（2）setup thread group
一種特殊類型的ThreadGroup的，可用于執行預測試操作。這些線程的行為完全像一個正常的線程組元件。不同的是，這些類型的線程執行測試前進行定期線程組的執行；類似LoadRunner的init，測試開始時進行初始化的工作。
（3）teardown thread group
一種特殊類型的ThreadGroup的，可用于執行測試后動作。這些線程的行為完全像一個正常的線程組元件。不同的是，這些類型的線程執行測試結束后執行定期的線程組；類似LoadRunnner的end，測試結束時進行回收工作。
4.3. 取樣器(Http請求)
關于http請求的的屬性參數說明：
1）名稱：用于標識一個sample。建議使用一個有意義的名稱
2）注釋：對于測試沒任何影響，僅用來記錄用戶可讀的注釋信息
3）服務器名稱或IP：http請求發送的目標服務器名稱或者IP地址，比如http://www.baidu.com
4）端口號：目標服務器的端口號，默認值為80，可不填
5）協議：向目標服務器發送http請求時的協議，http/https，大小寫不敏感，默認http
6）方法：發送http請求的方法(鏈接：http://www.cnblogs.com/imyalost/p/5630940.html）
7）Content encoding：內容的編碼方式（Content-Type=application/json;charset=utf-8）
8）路徑：目標的URL路徑（不包括服務器地址和端口）
9）自動重定向：如果選中該項，發出的http請求得到響應是301/302，jmeter會重定向到新的界面
10）Use keep Alive：jmeter 和目標服務器之間使用 Keep-Alive方式進行HTTP通信（默認選中）
11）Use multipart/from-data for HTTP POST ：當發送HTTP POST 請求時，使用
12）Parameters、Body Data以及Files Upload的區別：
1. parameter是指函數定義中參數，而argument指的是函數調用時的實際參數
2. 簡略描述為：parameter=形參(formal parameter)， argument=實參(actual parameter)
3.在不很嚴格的情況下，現在二者可以混用，一般用argument，而parameter則比較少用
While defining method, variables passed in the method are called parameters.
當定義方法時，傳遞到方法中的變量稱為參數.
While using those methods, values passed to those variables are called arguments.
當調用方法時，傳給變量的值稱為引數.（有時argument被翻譯為“引數“）
4、Body Data指的是實體數據，就是請求報文里面主體實體的內容，一般我們向服務器發送請求，攜帶的實體主體參數，可以寫入這里
5、Files Upload指的是：從HTML文件獲取所有有內含的資源：被選中時，發出HTTP請求并獲得響應的HTML文件內容后還對該HTML
進行Parse 并獲取HTML中包含的所有資源（圖片、flash等）：（默認不選中）
如果用戶只希望獲取特定資源，可以在下方的Embedded URLs must match 文本框中填入需要下載的特定資源表達式，只有能匹配指定正則表達式的URL指向資源會被下載
4.4. 監聽器
監聽器(Listener)負責收集測試結果，同時也被告知了結果顯示的方式。我們常用的包括：聚合報告、查看結果樹、用表格查看結果，都支持將結果數據寫入文件。其他的添加上去看看就行。聚合報告前面我們介紹過，后面是查看結果樹和用表格查看結果的截圖。
4.5. 循環控制器
4.6. 事務控制器
作用： 事務控制器會生產一個額外的采樣器，用來統計該控制器子結點的所有時間。
在線程組下創建事務控制器
參數：
· Generate parent sample：(選中這個參數結果展示如下圖紅框，否則顯示為下圖藍框)
· Include duration of timer and pre-post processors in generated sample：選中這一項會統計定時器(timer)的時間，否則只統計采樣器(sample)的時間
創建sample 訪問首頁和注冊頁面
生成聚合報告
勾選
聚合報告中只有一項事務報告
4.7. 斷言---檢查點
斷言(Assertions)可以用來判斷請求響應的結果是否如用戶所期望的。它可以用來隔離問題域，即在確保功能正確的前提下執行壓力測試。這個限制對于有效的測試是非常有用的。
兩個重要斷言：響應斷言和JSONAssertion
響應斷言：
JSON斷言：
4.8. 前置處理器和后置處理器
前置處理器(Pre Processors)和后置處理器(Post Processors)負責在生成請求之前和之后完成工作。前置處理器常常用來修改請求的設置，后置處理器則常常用來處理響應的數據。我們主要在動態關聯中用到后置處理器的正則表達式提取器。
https://www.cnblogs.com/fengpingfan/p/4755411.html
4.9. 定時器
定時器(Timer)負責定義請求之間的延遲間隔
<meta charset="utf-8">
五. Jmeter組件參數化
5.1. 參數化是什么
動態的獲取并設置數據
5.2. 為什么使用參數化
執行批量操作，批量添加批量刪除，人工效率太低
運用程序代替人工獲取并設置數據，安全高效
比如：對被測系統的用戶名和密碼進行參數化，來模擬多個用戶同時登錄系統
5.3. 參數化實現之用戶自定義變量
通過這個功能，能實現多接口共享數據，修改一條即可修改全部
Filename：所需數據文件的路徑。如和腳本同一路徑，可直接填寫文件名
File encoding：編碼和文件保持一致即可，默認為ANSI。如有中文，建議為UTF-8
Variable Names：引用變量時的變量名，對應數據文件中的每一列，以逗號分隔。如不填寫，文件的第一行數據將被讀取為變量名
Delimiter：在.txt、.dat文件中，可以用逗號（,）或者Tab鍵（\t）來區分列與列
Allow quote data：選項選為“true”的時候對全角字符的處理出現亂碼
Recycle on EOF：到數據文件結尾時是否循環讀取。設置為True時，線程數過多，數據文件讀取到最后一行時，會再次從第一行開始讀取。設置為False，到達文件結尾時如繼續讀取，則值會默認為<EOF>，可通過設置jmeter屬性csvdataset.eofstring來改變該值。
Stop thread on EOF：Recycle on EOF設置為False，Stop thread on EOF設置為True，則讀取數據文件最后一行后，停止測試，不管還有多少線程組未執行。
Sharing mode：共享模式。默認在所有線程組中使用，可選擇每個線程組單獨打開
相同的部分使用用戶自定義變量
只需要修改一次接口
效果展示
5.4. 參數化實現之CSV Data Set Config
添加CSV Data Set Config：
添加界面：
通過這個組件可以動態獲取并設置數據，實現批量添加操作
名詞解釋：
Filename：所需數據文件的路徑。如和腳本同一路徑，可直接填寫文件名
File encoding：編碼和文件保持一致即可，默認為ANSI。如有中文，建議為UTF-8
Variable Names：引用變量時的變量名，對應數據文件中的每一列，以逗號分隔。Delimiter：在.txt、.dat文件中，可以用逗號（,）或者Tab鍵（\t）來區分列與列
Allow quote data：選項選為“true”的時候對全角字符的處理出現亂碼
Recycle on EOF：到數據文件結尾時是否循環讀取。設置為True時，線程數過多，數據文件讀取到最后一行時，會再次從第一行開始讀取。設置為False，到達文件結尾時如繼續讀取，則值會默認為<EOF>，可通過設置jmeter屬性csvdataset.eofstring來改變該值。
Stop thread on EOF：Recycle on EOF設置為False，Stop thread on EOF設置為True，則讀取數據文件最后一行后，停止測試，不管還有多少線程組未執行。
Sharing mode：共享模式。默認在所有線程組中使用，可選擇每個線程組單獨打開
添加引用文件：
引用：
在jmeter中添加
線程數改為某個值
查看結果樹：
其他：
- 線程組線程數改為大于文件中數據的處理：
遇到結束符在循環
遇到結束符停止線程 - 如果數據來自數據庫
數據庫導出txt文件
5.5. 使用Jmeter函數助手(文件中不要出現中文)：
1、點擊 選項-->函數助手 調出函數助手對話框
2、選擇 _CSVRead 函數（下圖第一個框）
3、函數參數：
1）第一個參數：填寫文件路徑。
2）第二個參數：文件列號是從0開始的，第一列0、第二列1、第三列2、依次類推,然后點擊【生成】按鈕，則會自動生成我們需要的參數化函數。
3) 復制生成的參數化函數， copy過程需要使用的地方即可。
4) _Random函數是從某數據段隨機讀取數據替換參數，當需要添加多條數據記錄且某些字段需要唯一性時使用。
六. Jmeter正則表達式提取
6.1. 使用正則提取
運用Jmeter正則提取器，可以從請求的響應結果中取到需要的內容，從而實現關聯。關聯是請求與請求之間存在數據依賴關系，需要從上一個請求獲取下一個請求需要回傳回去的數據
正則表達式(regular expression)描述了一種字符串匹配的模式（pattern），可以用來檢查一個串是否含有某種子串、將匹配的子串替換或者從某個串中取出符合某個條件的子串等。
| 字符 | 描述 |
|---|---|
| * | 匹配前面的子表達式零次或多次。例如，zo* 能匹配 "z" 以及 "zoo"。* 等價于{0,}。 |
| + | 匹配前面的子表達式一次或多次。例如，'zo+' 能匹配 "zo" 以及 "zoo"，但不能匹配 "z"。+ 等價于 {1,}。 |
| ? | 匹配前面的子表達式零次或一次。例如，"do(es)?" 可以匹配 "do" 、 "does" 中的 "does" 、 "doxy" 中的 "do" 。? 等價于 {0,1}。 |
| ( ) | 標記一個子表達式的開始和結束位置。子表達式可以獲取供以后使用。 |
| . | 匹配除換行符 \n 之外的任何單字符。要匹配 . ，請使用 . 。 |
構造正則表達式的方法和創建數學表達式的方法一樣。也就是用多種元字符與運算符可以將小的表達式結合在一起來創建更大的表達式。正則表達式的組件可以是單個的字符、字符集合、字符范圍、字符間的選擇或者所有這些組件的任意組合。
正則表達式提取的相關設置
說明：
(1)引用名稱：下一個請求要引用的參數名稱，如填寫title，則可用${title}引用它。
(2)正則表達式：
()：括起來的部分就是要提取的。
.：匹配任何字符串。
+：一次或多次。
?：不要太貪婪，在找到第一個匹配項后停止。
(3)模板：用$$引用起來，如果在正則表達式中有多個正則表達式，則可以是$2$$3$等等，表示解析到的第幾個值給title。如：$1$表示解析到的第1個值
(4)匹配數字：0代表隨機取值，1代表全部取值，通常情況下填0
(5)缺省值：如果參數沒有取得到值，那默認給一個值讓它取。
案例:api接口
