手把手帶你設計接口自動化測試用例（二）：根據接口信息設計測試用例

上一篇文章 手把手帶你設計接口自動化測試用例（一）：提取接口信息並分析 詳細介紹了如何提取並分析登錄、發布、修改、刪除、查詢等接口信息，這篇文章來看一下如何根據接口信息設計測試用例。

 

ZrLog 系統接口測試用例的字段可以設計為 3 個部分，分別是主測試用例的字段（重要）、配置信息的字段、執行結果記錄的字段。下面分別介紹這 3 部分字段的名稱和含義。

 

1、設計主測試用例的字段

主測試用例的字段一般包含用例標識的字段、請求信息的字段和響應信息的字段，響應信息的字段一般作為接口用例執行結果的斷言字段；另外由於本書的接口涉及 cookies 信息及接口之間的關聯信息，所以需要加上 cookies 字段及接口關聯字段。基於以上規則，ZrLog 系統主測試用例的字段設計如表1 所示。

表1 主測試用例的字段

 

2、設計配置信息的字段

 配置信息的字段一般用來存放接口自動化框架中所需要的各類環境配置信息，具體需要哪些字段，在實際中可根據項目需求靈活設置，在 ZrLog 系統中對配置信息設置了 4 個常用字段，如表2 所示。

表2 配置信息的字段

 

 

 

 

 

 3、設計執行結果記錄字段

執行結果記錄的字段主要用來存放測試用例執行的最終結果及相關的信息。具體需要設置哪些字段可根據項目情況靈活決定。

在 ZrLog 系統中對執行結果記錄設置了以下常用的 5 個字段，如表3 所示。

表3 執行結果記錄的字段

 

 

 4、設計主測試用例內容並解決關聯關系

 

接口測試用例與功能測試用例本質上並無區別，常用的設計方法有：有效、無效、邊界、錯誤推測、場景法、正交法等。接口測試包括單接口測試和多接口測試，單接口測試是指針對單個接口的用例設計，而多接口測試是指針對多個接口的用例設計，一般是基於正向的業務流程去設計用例，並且要處理上下游接口的關聯關系。

基於此規則，對於文章 手把手帶你設計接口自動化測試用例（一）：提取接口信息並分析 的 5 個接口，共設計出 11 個測試用例。其中登錄接口為單接口，一共設計了 7 個用例；其他的 4 個接口為多個接口，一共設計了 4 個用例。主測試用例的內容及結構如圖1、圖2所示。

 

  圖1 主測試用例的內容及結構（1）

 

 圖2 主測試用例的內容及結構（2）

用例分析如下。

• 第 1 個測試用例為登錄接口的測試用例，使用了錯誤的密碼進行登錄，登錄過程無須攜帶 cookies，所以 cookies 字段設置為空，登錄失敗后，預期的業務狀態碼為 1。如果服務端響應的業務狀態碼不為 1，則代表此測試用例執行沒有通過。

• 第 2個測試用例為登錄接口的測試用例，請求主體信息中不攜帶密碼這個參數，登錄過程無須攜帶 cookies，所以 cookies 字段設置為空，預期的業務狀態碼為 1。如果服務端響應的業務狀態碼不為 1，則表明此測試用例執行沒有通過。

• 第 3個測試用例為登錄接口的測試用例，請求主體信息中使用了錯誤的用戶名，登錄過程無須攜帶 cookies，所以 cookies 字段設置為空，預期的業務狀態碼為 1。如果服務端響應的業務狀態碼不為 1，則表明此測試用例執行沒有通過。

• 第 4個測試用例為登錄接口的測試用例，請求主體信息中用戶名參數使用非字符串類型的數據，登錄過程無須攜帶 cookies，所以 cookies 字段設置為空，預期的業務狀態碼為 1。如果服務端響應的業務狀態碼不為 1，則表明此測試用例執行沒有通過。

• 第 5個測試用例為登錄接口的測試用例，請求主體信息中不攜帶用戶名參數，登錄過程無須攜帶 cookies，所以 cookies 字段設置為空，預期的業務狀態碼為 1。如果服務端響應的業務狀態碼不為 1，則表明此測試用例執行沒有通過。

• 第 6個測試用例為登錄接口的測試用例，請求主體信息中用戶名為空字符串，登錄過程無須攜帶 cookies，所以 cookies 字段設置為空，預期的業務狀態碼為 1。如果服務端響應的業務狀態碼不為 1，則表明此測試用例執行沒有通過。

• 第 7個測試用例為登錄接口的測試用例，請求主體信息中使用了正確的用戶和密碼進行登錄，登錄過程無須攜帶 cookies，所以 cookies 字段設置為空，登錄成功之后服務端響應的預期的業務狀態碼為 0。如果服務端響應的業務狀態碼不為 0，則表明此測試用例執行沒有通過。另外， 用戶登錄成功之后，會在服務端產生 cookies 信息。在 relation 字段中設置了 token=cookiess.admin-token，它代表的含義是取得 cookies 信息中的 admin-token 字段的值，並把這個值賦給變量 token，以便下游接口引用 token 變量而得到 cookies 的秘鑰。

• 第 8個測試用例為發布文章接口的測試用例，在 cookies 字段中設置了{"admin-token" : "${token}"}，這說明發布文章過程中需要攜帶 cookies信息，且 cookies 信息中鍵為“admin-token”，其值引用了登錄接口中所設置的 token 這個變量。從 request_body 字段的信息中可以看到發布文章的標題（title 為標題參數）為“付出”，文章別名（alias 為別名參數）為“付出”。在文章發布成功后，將會產生文章的 id 號和文章的 alias （文章別名），所以又在 relation 字段中設置了 id_name=body.id,alias_ name=body.alias，它代表的含義是取到響應正文中的 id 號，並把它賦給變量 id_name；同時取到響應正文中的 alias（文章別名），並把它賦給變量 alias_name，以便下游接口可以引用這兩個變量。最后，當文章發布成功之后，服務端響應的預期業務狀態碼為 0。如果服務端響應的業務狀態碼不為 0，則表明此測試用例執行沒有通過。

• 第 9個測試用例為修改文章接口的測試用例，在 cookies 字段中設置了{"admin-token" : "${token}"}，這說明修改文章過程中需要攜帶 cookies 信息，且 cookies 信息中鍵為“admin-token”，其值引用了登錄接口測試用例中所設置的 token 這個變量。從 request_body 字段的信息中可以看到，文章的 id 號引用的是發布文章接口測試用例中設置的 id_name 這個變量的值，文章的 alias 引用的是發布文章接口測試用例設置的 alias_ name 這個變量，也就是說要修改的文章是 id 為 id_name 的文章，並且在修改過程中把文章的標題修改成了“付出才能傑出”。最后，在文章修改成功之后，服務端響應的預期業務狀態碼為 0。如果服務端響應的業務狀態碼不為 0，則表明此測試用例執行沒有通過。

• 第 10 個測試用例為刪除文章接口的測試用例，在 cookies 字段中設置了{"admin-token" : "${token}"}，這說明文章過程中需要攜帶 cookies 信息，且 cookies 信息中鍵為“admin-token”，其值引用了登錄接口測試用例中所設置的 token 這個變量。從 request_body 字段的信息中可以看到，要刪除的文章的 id 號引用的是發布文章接口測試用例中設置的 id_name這個變量的值，這說明要刪除的文章是 id 為 id_name 的文章。最后，在文章刪除成功之后，服務端響應的預期業務狀態碼為 0。如果服務端響應的業務狀態碼不為 0，則表明此測試用例執行沒有通過。

• 第 11 個測試用例為查詢文章接口的測試用例，在 cookies 字段中設置了{"admin-token" : "${token}"}，這說明查詢文章過程中需要攜帶 cookies 信息，且 cookies 信息中鍵為“admin-token”，其值引用了登錄接口測試用例中所設置的 token 這個變量。因為此接口的請求方式為 GET 請求，所以 request_body 字段中信息為空，請求的參數直接放在 url 中。最后，由於文章已刪除，查詢的結果為空才是正常的，服務端響應的預期業務狀態碼應該為 0。如果服務端響應的業務狀態碼不為 0，則表明此測試用例執行沒有通過。

 

 5、設計配置信息的內容

本框架中所涉及的配置信息是被測環境服務器的 IP 地址，在配置信息中設置服務端的 IP 地址，其原因在於可以將服務器的 IP 地址從接口地址中分離出來，主要是因為一旦服務器的 IP 地址要改變，只需要在配置信息的字段進行更改便可，而不需要到每個接口用例當中對 url 中的 IP 地址進行一一更改，以實現公共數據的分離。在實際項目中具體需要在配置信息的字段中設置哪些內容，可根據項目需求靈活設置。ZrLog 系統配置信息字段的內容如圖3所示。

 

 圖3 配置信息字段的內容

 

6、執行結果記錄的內容

執行結果記錄字段的內容是由程序運行之后自動填充，無須手工填寫。

 

下一篇文章將分享如何建立數據庫實例和主測試用例表，敬請期待！