通用介面測試平臺中文安裝及使用手冊
專案用途：解決網際網路介面測試資料依賴的通用測試框架。 說明： 介面測試用例的介面測試物件是介面，介面的主要特徵是它的入參和返回值。 介面的入參實際上就是一條資料，這條資料需要具備時效性和正確性，入參是保證介面正確執行的前置條件。 介面入參的正確性是指它的資料格式、資料本身及它所存在的位置都是符合介面業務邏輯、技術設計所規定的資料格式即string型別就不要是true or false, 一個特定的類型別，就不要是其他類型別； 資料本身：顧名思義，具體來講入參期望是123456字串，但只傳了12345或 654321。 資料存在的位置：期望這條資料是在資料庫裡，或是在快取裡。弱不存在，或存在的位置不對，那麼介面在執行過程中從期望位置取不到值，介面就不會返回期望的正確結果。 資料的時效性：指介面用例在當前執行時該介面的入引數據是可用的。必入使用者登入成功後獲取的token值是使用者登入成功的令牌，這個令牌有時效性，令牌過期了即代表失效，再用這個token值做身份驗證，一定會失敗。所以需要重新獲取。像這樣入引數據時效性要在用例每次執行時都需要獲取一次最新值。 入引數據的正確性和實效性的保證就需要在用例裡增加呼叫相應的介面貨訪問資料庫的步驟。這些步驟就是被測介面的前置條件，構造不同介面的前置條件的複雜度都可能不一致，有的只需要一步，有的需要多個步驟，並且還需要對某步步驟裡的資料做特殊處理或業務自定義的操作，才能構造出被測介面所期望的入引數據。 這裡的特殊處理即對 資料做構造。舉例來講，把json格式的資料裡某個特值key的值做替換，若value期望是一個guid，那麼久聲稱一個guid來替換這個特定key的值。弱value期望是一個手機號或者郵箱，那麼隨機生成一個手機號或者郵箱，這種場景比較常見，介面執行一個符合格式的心的資料，弱勢老資料，介面就不會返回期望的值。網際網路應用這種使用新郵箱和手機號的場景很常見。 業務自定義處理：是指資料按照產品或業務先自身特有的義務邏輯進行處理，這種處理不具有普遍性和通用性，是非常個性化的資料處理邏輯。 這樣一個測試用例要執行的物件是介面d,但由於d需要另外三個介面(a、b、c)執行後並獲取者三個介面返回結果或介面引數中的部分特定值、全部值，才能正常執行介面D。 這種多個介面順序執行來完成一個測試用例的執行，就是測試用例介面執行之間的關聯性。網際網路應用的測試用例往往都是場景化的用例。
使用說明：
-
部署說明 1.1. git地址. 1.2. jdk版本 部署機器需要安裝jdk1.8,(jdk1.8.0_131)並在tomcat的catelina.sh裡增加export JAVA_HOME=/usr/local/jdk1.8.0_131/ 1.3. 打包方法 rebuild+mvn package, 生成target的lib包，依賴包，classes資料夾。 1.4. 用例存放地址 存在在/opt/iframework/testCases，測試用例用資料夾來區分、管理 1.5. 部署路徑 路徑是/opt/iframework/,
-
呼叫框架執行介面測試的原理 2.1. 呼叫原理說明 2.1.1. 呼叫說明 呼叫框架執行用例是通過http的get請求，url裡字首是ip+埠+標示+引數的形式，即
http://ip:port/iframework/irun? 。如：機器部署在172.18.5.30上，埠號8888，那麼呼叫的url字首就是http://172.18.5.30:8888/iframework/irun? 2.1.2. 原理說明 框架的核心功能都以dubbo協議來暴露介面，註冊中心在測試環境的zookeeper上。其中IRemoteServer介面是負責解析呼叫框架請求的，暴露成rest形式，目的是方便對框架的呼叫來執行測試用例。 2.2. 呼叫引數資訊 引數名 是否必填 引數說明 path 是 測試用例的xml的絕對路徑。 路徑放在/opt/iframework/testCases下，呼叫路徑就是 ip:port/iframework/irun?path=/opt/iframework/testCases/CIA/Authentication/ciaAuthBatch1.xml, 如果不指定具體的xml，只是指定了某個資料夾，那麼就會跑這個資料夾下及子資料夾下全部的用例。 dburl 否 資料庫連線字串，如果你的用例需要訪問資料庫，可以通過這個引數來指定，一旦指定dburl，那麼就會替換測試用例裡的dburl；如果不指定，會指定用例裡寫的dburl uid 否 資料庫訪問的使用者名稱 pwd 否 資料庫訪問的密碼 dn 否 域名，url裡一旦帶有這個引數，就會替換測試用例裡的url字首，如http://a.c.com、http://b.c.com。 注意：如果用例裡沒有寫明字首，那麼請求引數裡需要帶有dn引數，這個dn會和用例裡的path進行拼接成完整的url； 假設用例裡沒有寫明字首，如果請求引數裡不傳dn引數，用例會報錯，因為找不到用例的url.
2.3.
- 用例的執行過程 1）框架解析呼叫的引數，舉例172.10.5.5:8888/iframework/irun?path=/opt/iframework/testCases/CIA/Authentication/ciaAuthBatch1.xml 通過這個請求，框架得知，要執行的用例是/opt/iframework/testCases/CIA/Authentication/ciaAuthBatch1.xml
- 解析這個xml，轉成框架定義的測試用例物件testCaseNode
- 按testCaseNode定義的step順序，順序執行每個step，即每個介面。 4）每個step的執行過程是，先解析step裡的url和請求引數，然後呼叫httpcient來發送你的請求，再然後對請求的返回結果做驗證，驗證的邏輯是寫在step裡的Response/Expect下的Parameter，最後是把用例執行結果存到資料庫中。
- 每個step執行結果都會新增到StringBuilder裡，目的是在xml裡用例都跑完之後，把完整結果返回給前端。
- 用例執行完畢，會換行列印Finish！！！字樣，如果執行異常，會把異常堆疊資訊返回出來。
- 用例的組織形式 4.1 ¥ 測試用例都是xml，寫好xml放在部署機器上，執行呼叫時指定好用例的存放路徑，即可執行你剛寫的測試用例，不需要程式重新打包。 ¥ 組織用例首先按業務線名稱來區分，好比第一級資料夾名稱統一是testCases，第二級就是各業務線的名字，如bia, cenc,cia, tplus, 第三級就是業務線下各模組或各feature,如cia下的Authentication、login、administrator。還可以再多級，根據業務線特點來區分吧。 ¥ 注意一點，如果某一個模組下有10個介面可以單獨執行，不需要過多依賴其它介面，那麼建議統一放到一個xml檔案裡，檔名建議是batch1為結尾，方便其它人知道這是一個批量執行單介面的測試用例。 ¥ 如果是測一個場景化的介面測試用例，即需要2個以上的接口才能完成最終的測試場景，建議把這些放到一個xml裡。
¥ 注意： 測試用例支援資料與用例分離，即一份測試用例可以跑多組資料，資料都放到配置檔案裡，即/src/main/resources/properties/下某個自定義的配置檔案裡，也可以放到csv檔案裡。
4.2 針對介面測試不同業務場景的詳細設計
4.2.1 測試用例引數化
4.2.1.1 excel作為介面引數的資料來源，介面結果驗證值也在excel資料來源裡，excel每一行都代表用例的一組測試資料，一組測試陣列包含介面引數和該記錄的期望返回值。 dataPathName指明excel資料來源的檔案位置。 excelExpectParameterColName指明excel裡的某列，該列作用是該條記錄的期望返回值。
4.2.2 介面引數從之前步驟裡提取 4.2.2.1 從指定步中取特定關鍵字的值
4.2.2.2使用sequence_type_keyword_key和offlineFlag獲取指定步驟某值去替換陣列指定值. random%email% 生產隨機郵件名稱。
4.2.2.3使用storeParam自定義標籤儲存引數的值
4.2.2.4使用自定義標籤param_type_key獲取之前步驟裡儲存的引數值
4.2.2.5獲取多個儲存的引數值，以及獲取多個介面返回值中的部分值
4.2.2.6從多步裡取值。從第0步和第2步取值。
4.2.2.7使用xpath來對介面結果返回的json格式特定內容的讀取
4.2.3 資料庫相關 4.2.3.1 讀資料庫，返回指定列值
4.2.3.2 讀資料庫，讀指定結果裡的值做為資料庫sql的引數來查詢結果
4.2.3.3讀資料庫，讀上n步介面引數裡的值做為資料庫sql查詢引數
4.2.3.4 執行sql指令碼來完成對資料庫的操作
4.24 結果值驗證 4.2.4.1對動態結果值的驗證
4.2.4.2非空驗證
4.2.4.3 string字串比較驗證
4.2.4.4對陣列的驗證
4.2.4.5對json裡string型別的驗證
4.2.4.6對json格式裡陣列型別含有元素個數的驗證
<Parameter path="Obj___Context,Array___ViewOpts" value="1" action="equal" type="array" />
4.2.4.7對json格式裡的物件數組裡某物件元素的驗證，注意此例子的type=obj
<Parameter path="Obj___Layout,Obj___ReportHeader, Array___CarriedItems" value="{"FieldName":"voucherdate","Title":"單據日期","Value":"2017.07.01 - 2017.07.31","Width":250}" action="contain" type="obj" />
4.2.4.8對json格式裡數組裡某陣列元素的驗證，注意此例子的type=array
<Parameter path="Obj___DTO,Obj___PU_PurchaseOrderSumRpt, Array___columns" value="["PartnerCode","PartnerName","BaseQuantity","OrigDiscountAmount","OrigTax","OrigTaxAmount","OrigDiscount","sumbasequantity","GroupLevel","rowType","reportRowType"]" action="contain" type="array" />
或：
<Parameter path="Obj___DTO,Obj___PU_PurchaseOrderSumRpt, Array___Rows" value="[["","","","","","","","","999","T",null]]" action="contain" type="array" />
4.2.4.9介面是void時(不返回值)時使用voidReturn="true"不對結果做驗證
4.2.4.10使用jsonArray保留字作為返回結果型別為物件陣列時的驗證
4.8.4.11使用arraystring保留字處理返回結果型別為字串陣列時的驗證
4.2.5 對引數做特殊處理 4.2.5.1使用keyword給特定數值內的值做替換 Step name="aaa" url="http://a.b.com/active">
4.2.5.2 使用offlineFlag標籤來宣告對value裡的值做自定義處理
4.2.5.3 對callback的處理
4.2.5.4 對引數需要做自定義處理 ／／生成手機號 ／／需對value解密 //做md5操作 //隨機生成15位數字
4.2.5.5對於引數為陣列型別的支援
4.2.5.6 讀配置檔案裡定義的字串來做自定義處理
4.8.5.7 不指定關鍵字的情況下，直接從某部介面結果裡獲取對應值來替換當前引數的值
4.8.5.8 對引數為陣列型別的引數賦值
4.8.5.9 引數是巢狀json：
4.2.6 對http請求的支援 rest介面包括http和https兩種形式，http含有get、post、put、delete、head、 根據HTTP標準，HTTP請求可以使用多種請求方法。 HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。 HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
GET 請求指定的頁面資訊，並返回實體主體。 POST 向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。 PUT 從客戶端向伺服器傳送的資料取代指定的文件的內容。 DELETE 請求伺服器刪除指定的頁面。 我們對四種最常見的請求方法做了支援，即在action裡指明get, post, put,delete 即可實現對應協議的執行: 如對put的支援
對delete的支援 http的header和cookie也是介面設計中常用的設定，所以也需要增加對其的支援。 支援如下: 4.2.6.1 設定header
4.2.6.2 header需要引數來初始化的情況：
4.2.6.3獲取cookie
4.8.6.4設定cookie
4.8.6.5使用exchangeFlag="true"和step裡的action="singlekey"對介面引數沒有name，Content-Type為application/json的場景：
<Step name="step0_sample" url=http://ip/finance/data action="singlekey">
<Request>
<Parameter name="paramvalue" value="{"cardNo":"111"}" exchangeFlag="true" />
</Request>
4.2.6.6 header初始化：
4.2.7 對rpc呼叫的介面，測試用例使用type="jar"表明是jar型別的呼叫。 4.2.7.1 對jar包裡的類型別的介面含有建構函式的支援： clsName指明要例項化的類；parameterType指明建構函式的型別、引數值、次序；method指明要呼叫的介面名稱。
4.2.7.2 當引數是一個自定義的類型別時，
- 用例的寫法 5.1. 基礎寫法:
- Step裡的url代表介面的地址。
- Step裡的name用於區分用例。
- rule代表請求是get還是post
- action是對header、cookie的get或set
- 在Step裡的Request的Parameter裡寫請求引數。key是url引數的key， value是引數的值，這個值可以放到csv檔案裡exceldata資料夾裡，也可以放到配置檔案裡resources/.propertities。
- 可對在Step裡的Request的Parameter的value值可做幾種擴充套件，有action，sequence，colName，keyword，typesqlScript。分別代表： 6.1.1. action: action目前可做對value值的md5, 但是功能上可以擴充套件。 6.1.2. sequence: 指定要讀取之前結果集中特定步驟的結果。 6.1.3. colName: 對應excel/csv引數檔案裡的列名。 6.1.4. keyword: 與sequence配合，讀取sequence指定返回結果集中某個結果中名稱與keyword同名的對應的值。 6.1.5. type: 指明從結果集合中獲取值的型別，可以是string, array, 6.1.6. sqlScript:用於對資料庫操作時候使用，用於指定sql指令碼的路徑，如，而value可以直接是一個sql語句，如：。
5.2 一些特殊場景的應用：
- 對手機號的支援： ◆ 動態生成手機號：在引數裡含有這個特殊標記random%mobile%，代表框架會自動生成一個11位手機號 ◆ 獲取上一步介面使用的手機號：get%mobile% 2. 生成指定長度的隨機數： ◆ 生成8位長度的數字和字母： random%string8% ◆ 生成15位長度的數字和字母： random%string15% 3. 獲取上一步返回的特殊值： ◆ 獲取簡訊驗證碼 special#registCode# ◆ 獲取userId special#userId# ◆ 獲取orgid special#orgId#
5.3 對結果的驗證： 主要是對返回型別為json的驗證，驗證邏輯是： ◆ 當json為json object時，path以obj開頭(因為obj代表object)，然後加三個下劃線___, 後面跟json的關鍵字；如 { "Context": { "ReportSearchType": "Advance", "MenuCode": "PU6002" } } 如果是要驗證ReportSearchType的值是否為Advance，那麼驗證這麼寫：
◆ 當要驗證json裡的陣列的個數，如驗證下面json裡的CarriedItems個數，那麼驗證邏輯這麼寫：
{
"Layout": {
"ReportHeader": {
"SearchItems": [],
"CarriedItems": [
{
"FieldName": "voucherdate",
"Title": "單據日期",
"Value": "2017.07.01 - 2017.07.31",
"Width": 250
},
{
"FieldName": "PartnerCode",
"Title": "供應商",
"Value": "",
"Width": 250
},
{
"FieldName": "inventoryCode",
"Title": "存貨",
"Value": "",
"Width": 250
}
]
}
}
} ◆ 當要驗證的json是數組裡的每個元素，比如驗證上面json的CarriedItems裡的三個元素，驗證邏輯就這麼寫：
<Parameter path="Obj___Layout,Obj___ReportHeader, Array___CarriedItems" value="{"FieldName":"PartnerCode","Title":"供應商","Value":"","Width":250}" action="contain" type="obj" />