介面測試用例設計

2022-08-11 19:39:11 字數 2561 閱讀 5191

介面測試的必要性

ž   可以發現很多頁面操作發現不了的問題

ž   檢查系統的異常處理能力

ž   檢查系統的安全性、穩定性

ž   前端隨便變,介面測好了,後端不用變

介面測試的流程

ž   需求評審,熟悉業務和需求

ž   開發提供介面文件

ž   編寫介面測試用例

ž   用例評審

ž   提測後開始測試

ž   提交測試報告

介面文件是介面測試的參照,至少包括:

1、介面說明

2、呼叫url

3、請求方法(get\post ……)

4、請求引數、引數型別、請求引數說明

5、返回引數說明

6、支援格式(xml/json)

介面測試用例設計

通過性驗證:首先保證介面好用,按文件正常傳入,檢視是否可以返回正確的結果。

引數組合: 按介面文件中對引數的要求進行有目的的組合,比如必填未填是否通過,標誌類引數值的切換是否能對應正確的功能等。(這部分很關鍵)

介面安全:     

1)、繞過驗證,比如說購買了乙個商品,它的**是300元,那我在提交訂單時候,我把這個商品的**改成3元,後端有沒有做驗證,更狠點,我把錢改成-3,是不是我的餘額還要增加?

2)、繞過身份授權,比如說修改商品資訊介面,那必須得是賣家才能修改,那我傳乙個普通使用者,能不能修改成功,我傳乙個其他的賣家能不能修改成功

3)、引數是否加密,比如說我登陸的介面,使用者名稱和密碼是不是加密,如果不加密的話,別人攔截到你的請求,就能獲取到你的資訊了,加密規則是否容易破解。

4)、密碼安全規則,密碼的複雜程度校驗

異常驗證:不按照介面文件上的要求輸入引數,來驗證介面對異常情況的反應。

介面測試用例模板(可根據專案實際情況設計增減)

1、專案            測試針對哪個專案

2、模組            哪個功能模組

3、用例id

4、介面名稱

5、用例標題      測試用途概括

6、請求方式      get/post

7、請求url        url位址

8、請求引數

9、前置條件       執行當前請求依賴的條件,不滿足就不能正確執行

10、結果驗證     預期結果

11、請求報文     可以不寫

12、返回報文  一定要寫,這裡應該是你請求返回的真實結果

13、測試結果    通過/失敗

14、測試人員   

測試http介面

請求常見有get請求和post請求。get請求通常用來接收資料,post請求通常用來傳送資料;測get請求可用瀏覽器完成,引數都可以寫在url裡面,測post請求需要借助工具如postman,因為客戶端需要提供給伺服器的資訊較多,你要寫body傳輸大量資料。

介面呼叫有兩種傳參方式:key-value形式,json串傳參形式。

key-value形式可以把引數拼接在url的後面由?相連,多個引數之間用&相連,如url?parameter1=key1¶meter2=key2…

json串傳參不能把引數直接連在url中,需要寫在請求的body裡面,可借助工具postman,開啟請求的body寫入json格式引數(由花括號括起來的『鍵:值』對)如

「count」: 1,

「start」: 0,

「total」: 1

請求發出後,http會返回乙個狀態碼表示請求是否成功,狀態碼有三位,其中開頭一位確定了狀態型別:

ž   2xx: 表示請求傳送成功,常見200。

ž   3xx: 代表重定向,要完成請求必須進行更進一步的操作,或把請求重定向到別的地方了,最常見的是302。

ž   4xx: 客戶端錯誤,請求有語法錯誤或請求無法實現。400代表客戶端傳送的請求有語法錯誤,不能被伺服器所理解;401代表訪問的頁面沒有授權;403伺服器收到請求,但是拒絕提供服務,比如沒有許可權訪問這個頁面;404請求的資源不存在,比如輸入錯的url沒有這個頁面。

ž   5xx: 代表伺服器有異常,500代表伺服器內部異常;503伺服器當前不能處理客戶端的請求,一段時間後可能恢復正常;504代表伺服器端超時,沒返回結果。

測試websevice介面

不需要像測http介面那樣拼報文,直接把wsdl位址或wsdl檔案(這兩個都由開發人員提供)填寫或匯入到工具soapui裡面,工具裡可顯示所有相關介面或報文,直接填入引數傳送請求參照介面文件檢視結果即可。

cookie 和 session

cookie是存在於本地的乙個鍵值對,session是存在於伺服器端的乙個鍵值對,通常儲存在資料庫或快取裡。cookie和session在第一次傳送某個請求時成對生成,兩端都會記錄下生成的時間,超出既定的時限後便會自動刪除。當請求在時限內再次發出後,cookie和session兩者會相互比對,匹配上了便執行某些操作,匹配不上則不允許執行某些操作,以此實現快速處理,它們並不是孤立作用的。

介面測試用例設計

介面測試用例設計點主要包括 功能 邏輯業務 異常 安全 功能 1.功能是否正常 2.功能是否按照介面設計文件實現 舉例 有些新增到購物車,需要登入才能新增。也就是業務要求不支援遊客新增購物車功能,如果設計乙個沒有登入的使用者,然後去測試新增購物車介面,結果介面能新增到購物車,說明功能不正常,不符合需...

介面測試用例設計

主要是子模組或者子系統間互動並相互作用的部分。因此,可以分析,系統間的介面包含三部分 輸入 處理邏輯 輸出。在沒有特殊要求的情況下,至少需要考慮以下內容 1 業務功能覆蓋是否完整 2 業務規則覆蓋是否完整 3 引數驗證是否達到要求 邊界 業務規則 4 介面異常場景覆蓋是否完整如果介面需求還包含效能或...

介面測試用例設計

輸入引數測試 引數必填 選填 合法輸入 非法輸入 邊界值 引數為空或null異常處理,基於業務場景的考慮。如 登陸狀態 許可權 依賴等設計到dao層呼叫的,考慮資料增刪改查的準確性。返回結果測試 與需求一直 返回碼及返回字段 每種錯誤要有單獨且明確的錯誤碼 功能測試 邏輯測試 兩個請求有嚴格的先後順...