01?前端交互測試?

前端頁面與后端代碼之間的交互測試，可以理解為接口功能測試的一個子集。

測試準備?

在進行交互測試前，首先要對前端功能有明確的認知，能夠明確區(qū)分：?

• 什么功能屬于前端頁面邏輯功能?

• 什么功能又屬于前端與后端交互功能?

• 前端功能與后端是通過什么接口方式進行交互?

• 前、后端，雙方有什么樣約束?

在這里提到了約束這個概念，在實際項目研發(fā)過程中，功能測試階段所產生 的 bug，有很大一方面是由于前、后端溝通不徹底，需求確認模糊導致。在進入研發(fā)前，雙方將各自 后續(xù)由于 bug 導致的反工工作量。

測試方法

可以使用抓包工具來進行交互層面測試，查看每個交互功能，對應的接口是否正確 （包含請求頭、請求參數(shù)、響應以及其他約束項），確保前端按照后端的要求正確地進行了調用。

在交互過程中，針對一個接口也會有多個場景，前端會根據不同的入參來調 用不同的場景，根據不同響應結果， 進行響應數(shù)據的改寫，來獲得不同響應，驗證不同響應下前端的展示效果。在這里我們也可以使用一些 不同場景的交互測試。

推薦 Mock 工具：?

• moco 框架：https://github.com/dreamhead/moco?

• easy-mock: https://github.com/easy?

• Metersphere 一站式測試平臺上也可以定義?

02?后端邏輯測試?

接口后端邏輯測試依然遵循“輸入—處理—輸出”這樣的模式。用戶輸入一串數(shù)據，然后讓這個接口或者讓這個后臺功能來處理，檢查輸出結果跟期望是否一 致。

接口測試用例設計應該滿足需求文檔，且對異常場景進行友好處理；且測試 這個接口是否安裝接口文檔進行開發(fā)

測試用例設計思路

• 從輸入參數(shù)進行考慮設計

1) 優(yōu)先級-針對所有接口?

1、暴露給其他系統(tǒng)、第三方調用的接口

2、系統(tǒng)內部調用的核心功能接口

3、系統(tǒng)內部調用的非核心功能接口

2）優(yōu)先級-針對單個接口

1、正向測試用例優(yōu)先，逆向測試用例次之（通常情況下是這樣）；

2、是否需要滿足前提條件 > 是否攜帶默認值參數(shù) > 參數(shù)是否必填 > 參數(shù)之間是否存在關聯(lián) > 參數(shù)數(shù)據類型限制校驗 > 參數(shù)數(shù)據類型自身的數(shù)據范圍值 限制校驗。

3）設計分析?

從接口測試后端業(yè)務邏輯來講，設計接口測試用例需要考慮以下幾方面：?

1、是否滿足前提條件 有的接口需要首先滿足一定條件，才可成功獲取數(shù)據。最常見的就是需 要用戶登錄信息的接口（用戶 token） 逆向用例：設計不滿足前置條件的用例。

2、是否攜帶默認值參數(shù) 正向測試用例：存在默認值的參數(shù)都不填寫、不傳參，必填參數(shù)都填寫正確并且存在正 確的常規(guī)值，這方面考慮設計測試用例。

3、業(yè)務邏輯、功能需求 這個環(huán)節(jié)需要根據具體的業(yè)務需求，結果接口定義文檔，可設計出多條 正向用例和逆向用例。

4、參數(shù)是否必填 針對每個必填參數(shù)，設計一條或多條參數(shù)值為空的逆向測試用例。

5、參數(shù)之間是否存在關聯(lián) 可根據參數(shù)之間的相互關聯(lián)關系設計一條或多條用例。

6、參數(shù)數(shù)據類型限制 針對每個參數(shù)類型設計與定義的類型不符的逆向測試用例。

7、參數(shù)自身的數(shù)據范圍值限制校驗 針對所有參數(shù)，設計每個參數(shù)在數(shù)據范圍內為最大或者最小的正向測試用例；?

針對所有參數(shù)，設計一條或者多條參數(shù)值超過或者小于數(shù)據范圍的逆向 測試用例；

總結一下，如果以上幾個方面考慮全面的話，基本可覆蓋以下三點：?

a、主流程測試用例：正常的主流程業(yè)務需求校驗?

b、分支流程測試用例：正常的分支流程需求校驗?

c、異常流程測試用例：異常業(yè)務場景的容錯校驗

• 從輸出參數(shù)進行考慮設計?

1、輸出結構是否與接口文檔定義的一致?

2、輸出的各個字段類型是否與接口文檔定義的一致?

3、輸出的各個字段的值是否符合邏輯且值正確?

測試環(huán)境?

進行接口測試之前首先需要與開發(fā)確認好測試環(huán)境，通常情況下，需要在三 個環(huán)境進行測試：測試環(huán)境、準生產環(huán)境及生產環(huán)境。

為了方便快捷切換接口測試環(huán)境的 host 指向，我們可借助以下工具進行切 換：SwitchHosts、Nohost、postman 等。

測試方式?

• 手工測試?

手工測試就是借助瀏覽器或者部分測試工具（postman、Jemter 等）手動執(zhí) 行測試用例的過程。針對新開發(fā)接口建議首先進行全面的手工測試后再將部分可 重復執(zhí)行用例加入自動化測試。

• 自動化測試?

接口測試相對容易實現(xiàn)自動化，且相對 UI 自動化也比較穩(wěn)定，可以減少人 工回歸測試人力成本與時間，縮短測試周期，是支持后端快速發(fā)版需求，達到低 成本高收益的根源。

接口自動化測試同樣需要有需求分析、用例設計，依據用例設計使用 python 或者 java 等語言結合框架，編寫自動化測試腳本，實現(xiàn)接口自動化測試、自動 執(zhí)行及自動發(fā)送測試報告等環(huán)節(jié)。

一個好的接口自動化測試框架應該涵蓋以下幾點：

a) 流程方面：在回歸階段加強接口各種場景的覆蓋度，并逐步向系統(tǒng)測試， 冒煙測試階段延伸，最終達到全流程自動化。?

b) 結果展示：更加豐富的結果展示、趨勢分析，質量統(tǒng)計和分析等。?

c) 問題定位：報錯信息、日志更精準，方便問題復現(xiàn)與定位。?

d) 結果校驗：加強自動化校驗能力，如數(shù)據庫信息校驗。

其他關注點?

以下這部分測試同業(yè)務邏輯測試同等重要，甚至從某種意義上講，比業(yè)務邏 輯測試更加重要，測試過程中不容忽視。

---

最后感謝每一個認真閱讀我文章的人，看著粉絲一路的上漲和關注，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走

這些資料，對于做【軟件測試】的朋友來說應該是最全面最完整的備戰(zhàn)倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！凡事要趁早，特別是技術行業(yè)，一定要提升技術功底。希望對大家有所幫助…….

總結

以上是生活随笔為你收集整理的接口测试系列之 —— 前端交互测试和后端逻辑测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。