摘要：接口驗證是
軟件測試中一個重要的方面。本文按被測對象與周邊實體的消息處理關系將接口驗證方式抽象成幾種模式：C模式、S模式、C&S模式、分發模式、異步模式等。然后按模式從接口契約定義、請求和響應配合等方面，給出接口驗證的一般要求。
關鍵詞：接口驗證 測試模式 協議一致性
1、相關概念
1.1 接口
這里所說的接口主要是指的是消息接口，是二個部件之間的通信契約，有發送方、接收方等方面的屬性，同GUI接口、文件接口一樣，它本質上屬于一種輸入、 輸出方式，只是它涉及到2個不同部件/實體，有請求/響應、有連接通道要求，由此帶來超時、重發、重連等方面的一系列要求。
1.2 接口、流程、處理的關系
一個流程由一系列的處理、接口調用組成。
一個流程可能涉及多個不同部件，涉及多個不同的接口調用。
一個接口可能服務于多個流程，多個流程共用同一個接口。由此，接口驗證里需要對同一個接口遍歷不同的流程調用場景。
接口作為數據的一種形式，它影響流程的走向。
接口作為數據的一種形式，它影響流程的結果。
有些接口處理可能是純接口的、只做中轉、協議轉換等。例：下面例子中的E部件接口；有些接口處理可能有較強的功能邏輯，根據需要可能還會進一步細化成內部接口。由此，接口驗證可能需要針對接口處理作進一步的功能邏輯驗證。
2、一個例子
以下為某個處理的簡化流程。P部件發出請求，E部件協議轉換后轉發給M部件，M部件進業務邏輯處理后返回響應給E部件。
接口的測試設計思路：
● 列出與每個部件的交互點。 包括：與P 部件的交互點1.1~1.2；與E 部件的交互點2.1~2.4；與M部件的交互點3.1~3.2
● 對每個部件的每個交互點進行正常與異常方面的驗證。
字體: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿
3、接口驗證模式
3.1 基本模式
● C模式：被測對象作為客戶端發送請求消息。一般來說，流程起點的接口（例子中的P部件接口）多數為C模式。
基本驗證要求：
◇ 發送請求消息正確性。包括：協議、消息格式、各參數驗證。
◇ 響應消息字段、錯誤碼遍歷。確認根據對端不同響應作了相應的正確處理。比如：根據錯誤碼展示
正確的錯誤提示也為一種正確處理方式。
進一步驗證要求：
◇ 考慮接口請求和響應配合上的異常，包括：
——請求發送異常：發送失敗、失敗重發。
——響應接受異常：無響應、響應超時、超時重發、收到重復請求
● S 模式：被測對象作為服務端接收請求，一般來說，流程終點的接口（例子中的M 部件）多數為S模式。
基本驗證要求：
◇ 收到的請求消息參數合法性校驗。包括：
——協議、消息格式的驗證、非系統識別消息、存在非法字段、收到重復消息
——遍歷各字段進行參數合法性校驗：是否可選、唯一性、類型、取值范圍、長度(<、=、>)等
◇ 遍歷請求消息的各字段取值及組合，確認根據不同輸入返回了不同的結果（可以等價）
◇ 發出響應消息正確性：協議、消息格式、各參數驗證等。
S&C 模式：被測對象既作為服務端接收請求又作為服務端發送請求。一般來說，流程中點（例子是的E 部件）多數為S&C 模式。
如果將周邊部件1 作為被測對象一部分，它即是C
如果將周邊部件2 作為被測對象一部分，它即是S
基本驗證要求：除了C 模式和S 模式的基本驗證要求，考慮對不同消息間相關參數一性性進行校驗。
例：R1 接口中X 參數取值為1-255，經過轉換后的R2 接口中相應的X 參數取值也應為1-255。
進一步驗證要求：參見C 模式和S 模式中的進一步驗證要求。
3.2 復合模式
● 異步模式：被測對象發出消息后，對端立即響應，對端在處理結束后再發送回執消息給部件，部件根據對端所給出的消息作出相應的處理，流程結束。一般來說，如果對端處理較為復雜、為避免被測對象長時間被阻塞，會采用此通信方式。
對于異步模式，可以拆分為2 對消息，但這2 對消息是基于事務、有狀態的。因此，對這類消息的驗證除了基本模式C 和S 的驗證要求外，還需要考慮2 對消息關系的配合對被測對象的狀態影響驗證。
以圖示為例，被測對象的驗證內容包括：
◇ 對A 接口的驗證。參見C 模式
◇ 對B 接口的驗證。參見S 模式
◇ A 和B 接口的配合：
條件：A 接口處理失敗、未收到B 接口消息、B 接口處理失敗、B 接口處理成功
結果：被測對象的狀態、數據
● 分發模式：需要將消息采用同步方式向其它多個部件進行分發，待消息收齊后才能決定自身的最終狀態。例：被 測對象通過分發部件將數據同步分發給不同的部件。需要說明的是：圖示中的分發部件，這時從物理上來說，可能看到的只是一個部件，由它統一接受和分發消息， 但從邏輯上來說，它是代表了不同部件的接口處理的。
對于分發模式一般也是基于事務、有狀態的，但由于涉及到了2 個以上的周邊部件，還需要考慮對不同部件的接口消息處理結果進行結合。
以圖示為例，被測對象的驗證內容一般包括：
◇ 對A 接口的驗證。（參見C 模式）
◇ 對B 接口的驗證。（參見C 模式）
◇ 對部件1 和部件2 處理結果結合驗證：
條件：1 成功2 成功；1 成功2 失敗；1 失敗2 成功；1 失敗2 失敗
結果：被測對象的狀態、數據
● 異步分發模式：即采用異步方式進行消息分發，為異步和分發模式的結合。比較 典型的是數據同步異步接口。被測對象 通過分發部件 同時將數據同步消息通知分發給不同的部件，各個不同部件收到通知后再向被測對象請求獲取同步數據。如果通知有優先級，例：部件1> 部件2，待部件1 處理完再通知部件2，即為異步分發模式1。如果多個部件的分發并行執行（一般來說，部件1 和部件2 可能代表的是同類部件的不同物理實例），即為異步分發模式2。
對于異步分發模式，也即異步+分發模式的組合。此時被測對象涉及到2 種類型的消息配合：同一個部件的通知和回執的組合；不同部件間的消息處理結果的配合。由此，被測對象的狀態遷移會更為復雜些。
以圖示為例，被測對象的驗證內容包括：
◇ 對A 接口的驗證。（參見C 模式）
◇ 對B 接口的驗證。（參見S 模式）
◇ 對C 接口的驗證。（參見C 模式）
◇ 對D 接口的驗證。（參見D 模式）
◇ 對A 和B 接口的配合驗證。（參見異步模式）
◇ 對C 和D 接口的配合驗證。（參見異步模式）
◇ 對部件1 和部件2 處理結果組合驗證。（參見分發模式）
4、相關說明
● 參數合法性檢驗策略
如果業務流程涉及多次轉發，原則上由邏輯處理部件進行接口參數的強校驗；其它轉發部件（例：E部件）進行弱校驗。
消息序列驗證
如果不同的接口消息之間是基于事務、有狀態的，則還需要考慮消息序列異常的問題，無論是何種模式。其驗證點包括：消息亂序、少傳消息包、多傳消息包、傳重復消息包、事務超時后收到消息等。
接口可靠性保證
◇ 對于重發的驗證，一般來說，重發機制中需要有重發策略、重發次數方面的考慮，不能出現消息反復重發引發消息風暴的問題。
◇ 對于超時的驗證，需要考慮各部件超時配置不一致的問題。
◇ 對于處理失敗造成雙方數據不一致問題，需要有事務號、回滾或補償機制等方面的設計考慮。
● 接口驗證的不同階段
對于接口驗證在單部件測試、點-點接口聯調、E2E聯合測試等不同階段都有所涉及。一般來說：
單部件測試：理論上通過測試樁可以模擬對端各種情況，對于真實實體只能通過系統狀態預置、輸入數據從外部觸發。所以，能在單部件測試考慮的盡可能放到單部件去做，至少保證單部件自身是OK的。
點-點接口聯調：如果將2個部件看作一個整體的話，則相當于單部件測試。對于部件-部件間的接口無法通過測試樁來模擬，需要通過外部驅動輸入。另外還需要關注部件-部件間的網絡連接，包括：是否可正常建立連接、連接中斷后是否會重連、連接吊死與釋放、時斷時續等。
E2E聯合測試：所有內部部件均為真實實體，對于接口間配合的問題（例：事務或數據一致性問題）可以考慮放到此考慮。除此還需要關注與外部部件間的接口對接測試。