摘要：自動(dòng)化測(cè)試最基本的功能用來重放請(qǐng)求，并且配合良好的格式化工具。對(duì)局部的也可以使用以及進(jìn)行測(cè)試。而自動(dòng)化測(cè)試用來測(cè)試數(shù)據(jù)是否正確。而且大部分問題是出在數(shù)據(jù)問題上，所以自動(dòng)化測(cè)試性價(jià)比比較高一些。以為例，需要每次提交后運(yùn)行測(cè)試，并保留測(cè)試結(jié)果。

Postman 最基本的功能用來重放請(qǐng)求，并且配合良好的 response 格式化工具。

高級(jí)點(diǎn)的用法可以使用 Postman 生成各個(gè)語言的腳本，還可以抓包，認(rèn)證，傳輸文件。

僅僅做到這些還不能夠滿足一個(gè)系統(tǒng)的開發(fā)，或者說過于瑣碎，你仍需要頻繁地在開發(fā)環(huán)境，測(cè)試環(huán)境，生產(chǎn)環(huán)境中來回切換。單一的請(qǐng)求也不夠，你需要維護(hù)系統(tǒng)所有 API 的請(qǐng)求，并且每個(gè)請(qǐng)求還帶有不同的 querystring 和 body。

github地址

對(duì)服務(wù)器端的所有請(qǐng)求按功能或者業(yè)務(wù)模塊進(jìn)行組織，使用 markdown 對(duì)所有請(qǐng)求和示例添加適當(dāng)?shù)拿枋?，這時(shí)候就用到了 Collection。以下是 postman 的一些術(shù)語以及組織請(qǐng)求的建議。

詳細(xì)參考 Postman SDK Concepts 以及 creating collections

Collection
對(duì)應(yīng)一個(gè)Application，組內(nèi)各個(gè)成員(server, client, QA)共享一個(gè) Collection?？梢詫?duì)整個(gè) Collection 添加測(cè)試，文檔。
對(duì)于一開始未在 postman 組織請(qǐng)求的應(yīng)用，可以設(shè)置 Proxy，跑一遍應(yīng)用，對(duì)應(yīng)用的所有請(qǐng)求進(jìn)行抓包。

Folder (ItemGroup)
對(duì)應(yīng)一個(gè)模塊，或者各層級(jí)子路由。如 router.use("/users") 所有的請(qǐng)求都在一個(gè) Folder，可以根據(jù)路由互相嵌套 Folder。

Request (Item)
對(duì)應(yīng)一個(gè)請(qǐng)求，可以添加認(rèn)證信息。也可以設(shè)置代理，進(jìn)行抓包。詳見 capturing http requests。

Example
對(duì)應(yīng)一個(gè)請(qǐng)求不同的參數(shù)以及響應(yīng)，用于Mock Server 以及文檔。

postman 可以根據(jù) Collection 的結(jié)構(gòu)生成文檔與Mock Server。不過都是付費(fèi)功能，免費(fèi)版有次數(shù)限制。

postman 自動(dòng)生成文檔有助于團(tuán)隊(duì)協(xié)作，解決了手動(dòng)寫文檔，以及更新不及時(shí)的重大bug。

對(duì)于 GET 請(qǐng)求，Postman 上可以添加對(duì)該字段的描述，生成文檔。

對(duì)于 POST 以及 PUT 請(qǐng)求，如果 Content-Type 是 form-data 或者 x-www-form-urlencoded 可以添加描述生成文檔。不過如今傳遞 json 更方便靈活，所以 application/json 也會(huì)有很多，而且 json 又是不能添加注釋的。如果需要對(duì) json 添加文檔說明的話，可以添加冗余字段 _{key}.comment 標(biāo)明注釋

{
  "id": 128,
  "_id.comment": "id",
  "page": 10,
  "_page.comment": "頁數(shù)"
  "pageSize": 15,
  "_pageSize.comment": "每頁條數(shù)"
}

不過這樣冗余字段過多，更好的解決方案是在測(cè)試中對(duì)請(qǐng)求進(jìn)行 json 校驗(yàn)，同時(shí)充當(dāng)了一部分文檔的功能。畢竟 json-schema 就是用來描述數(shù)據(jù)使數(shù)據(jù)更加可讀。

以上說到請(qǐng)求，對(duì)于響應(yīng)的文檔，可以 json-schema 校驗(yàn)或者每個(gè)字段的描述，以及更多的測(cè)試用例代表更多的細(xì)節(jié)。

當(dāng)服務(wù)器端還沒有寫好 API 時(shí)，客戶端可以根據(jù) Examples 來生成 Mock Server。

建議客戶端端自己做 Mock，與項(xiàng)目集成在一起，納入版本控制，方便靈活。強(qiáng)烈推薦 json-server，簡(jiǎn)單好用。

對(duì)于每一個(gè) Request 都需要有測(cè)試用例。驗(yàn)證響應(yīng)是否成功，響應(yīng)時(shí)間是否過長(zhǎng)或者響應(yīng) json 的數(shù)據(jù)類型是否正確。

測(cè)試可以使用 pm.expect 進(jìn)行 BDD 測(cè)試，風(fēng)格和 chai 很像，如果熟悉 chai 就很容易上手。

postman 內(nèi)置了一些第三方庫，如果你更喜歡 chai ，可以直接使用，也可以使用 pm.expect 底層使用 chai 實(shí)現(xiàn)，與 chai BDD API 一致。

postman 也有一些 http 相關(guān)的測(cè)試 API，如 status code，header, body，并且也提供了一些 snippets。

// 響應(yīng)成功
pm.test("Status code is 200", () => {
  pm.response.to.have.status(200)
})

// 響應(yīng)成功 chai.expect
pm.test("Status code is 200", () => {
  chai.expect(pm.response).to.have.property("code", 200)
})

// 校驗(yàn)響應(yīng)數(shù)據(jù)
pm.test("Page is 100", () => {
  const jsonData = pm.response.json()
  chai.expect(jsonData.page).to.eql(100)
})

json-schema 可以用來描述 json 信息，使 json 更加易讀，同時(shí)也可以用來校驗(yàn) json 的合法性。主流語言都有實(shí)現(xiàn) json-schema 的庫。

建議對(duì)所有 GET 響應(yīng)進(jìn)行 json-schema 校驗(yàn)，一來校驗(yàn)數(shù)據(jù)，二來也可以作為文檔使用，使用 tv4 校驗(yàn) json

pm.test("User info", () => {
  const jsonData = pm.response.json()
  const schema = {
    title: "UserInfo",
    discription: "用戶信息",
    type: "object",
    required: ["age", "email", "name"],
    properties: {
      age: {
        description: "年齡",
        type: "number",
        mininum: 0,
      },
      email: {
        description: "郵箱",
        type: "string" 
      },
      name: {
        description: "姓名",
        type: "string" 
      }
    }
  }
  pm.expect(tv4.validate(jsonData, schema)).to.eql(true)
})

同樣對(duì)于請(qǐng)求也可以添加 json 校驗(yàn)，不過更復(fù)雜一些，因?yàn)?postman 沒有直接給出獲取全部請(qǐng)求參數(shù)的api，需要自己解析和計(jì)算

// 獲取 application/json 中的數(shù)據(jù)
const json = JSON.stringify(pm.request.body.raw)

// 獲取 GET query string 的數(shù)據(jù)
const qs = pm.request.url.query.toObject()

如果 postman 可以根據(jù)請(qǐng)求參數(shù)的 json-schema 自動(dòng)生成數(shù)據(jù)就好了...

參考

json-schema.org

tv4 Documentaion

chai bdd - API

postman sandbox api reference

一個(gè)請(qǐng)求帶有若干參數(shù)，如 GET 的 querystring(search) 以及 POST 的 body，不同的參數(shù)會(huì)有不同的響應(yīng)。

假設(shè)一個(gè)請(qǐng)求不同參數(shù)返回的 json schema 完全不同，則可以寫成兩個(gè) Request 分開測(cè)試。如果返回的 json schema 相同，只是值不同，則需要考慮傳遞了哪些參數(shù)，參數(shù)是多少。

一個(gè)經(jīng)典的場(chǎng)景，根據(jù) filter 來篩選符合條件的列表。拿用戶列表舉例，偽代碼如下

const url = "/api/users"
const query = {
  name: "san",
  age: 12,
  sex: "MALE"
}
// 注意query數(shù)據(jù)需要校驗(yàn)，防止 SQL 注入
const sql = `select * from users where name = ${query.name} and age = ${query.age} and sex = ${query.sex}`

一個(gè)思路是根據(jù)請(qǐng)求的參數(shù)進(jìn)行測(cè)試，一段重要的 snipet 是在 postman 中獲取 querystring，query 是一種 PropertyList 的數(shù)據(jù)，定義在 postman-collection - PropertyList。如下

const name = pm.request.url.query.get("name")
const age = pm.request.url.query.get("age")

if (name) {
  pm.test("Items should match the name", () => {
    const jsonData = pm.response.json()
    expect(_.uniq(jsonData.rows.map(row => row.name))).to.eql([name])
  })
}

// 冗余代碼有些多，postman不知道支不支持自建 snipets
if (age) {
  pm.test("Items should match the age", () => {
    const jsonData = pm.response.json()
    expect(_.uniq(jsonData.rows.map(row => row.age))).to.eql([age])
  })
}

當(dāng)然以上 filter 只包含了最簡(jiǎn)單的場(chǎng)景，其中只涉及到了相等測(cè)試。但是有不等以及包含關(guān)系呢。

const query = {
  name: "san",
  age: 12,
  sex: "MALE"
}
const sql = `select * from users where name like ${query.name} and age < ${query.age} and sex = ${query.sex}`

這種請(qǐng)求參數(shù)依賴于前后端的協(xié)商交流，當(dāng)然對(duì)測(cè)試或者一個(gè)不知情的開發(fā)來說很不友好的。

當(dāng)然對(duì)于后端也是不友好的，因?yàn)樾枰獙?duì)你傳入的每個(gè) query 來進(jìn)行處理，而且以后每添加一個(gè)篩選字段，都需要手動(dòng)改一下。

可以由前端自行決定需要篩選的數(shù)據(jù)，比如使用類似于 mongo 的檢索語法。

graphql 是相當(dāng)酷的，值得嘗試一下

const query = {
  name: {
    $like: "san" 
  },
  age: {
    $lt: 12 
  },
  sex: "MALE"
}

不過這對(duì)于測(cè)試的開發(fā)能力要求也比較高了，測(cè)試人員需要解析參數(shù)并且測(cè)試接口。

當(dāng)對(duì)一個(gè)函數(shù)進(jìn)行單元測(cè)試時(shí)，需要大量的輸入以及期望輸出，在postman中，可以使用 data 來模擬多次輸入

data 是一種變量，只能在 Runner 中使用，有必要對(duì)每個(gè) Folder 建立相關(guān)的 data file，并且加入版本控制

using csv and json files in the postman collection runner

單個(gè)API測(cè)試通過后，需要把所有請(qǐng)求集成在一起進(jìn)行測(cè)試。這時(shí)候出現(xiàn)了兩個(gè)問題

如何確保API依賴

API之間如何傳遞數(shù)據(jù)

請(qǐng)求在 Collection 的順序就是他們的發(fā)起請(qǐng)求的順序，如果需要強(qiáng)制更改順序，可以使用 setNextRuest()

在 postman 中有三種作用域的數(shù)據(jù)，data，environment，global。在請(qǐng)求中用 {{}} 占位符替代。

environment 可以用來更改 HOST，避免在 url 中頻繁手動(dòng)切換本地環(huán)境，開發(fā)環(huán)境和生產(chǎn)環(huán)境。另外也可以用來傳遞數(shù)據(jù)。

一個(gè)常見的場(chǎng)景是項(xiàng)目使用 token 來保存登錄信息，每次請(qǐng)求都需要攜帶token?？梢栽诘卿浀臏y(cè)試代碼中設(shè)置 token 的環(huán)境變量

const url = "http://{{HOST}}/api/login"

pm.test("There is a token", () => {
  const jsonData = pm.response.json()
  pm.expect(jsonData.token).to.a("string")
  pm.environment.set("token", jsonData.token)
})

const urlNext = "http://{{HOST}}/api/profile?token={{token}}"

確保依賴后，可以對(duì) Collection 新建一個(gè) Runner，并且引入一個(gè) data 文件來測(cè)試所有的請(qǐng)求。對(duì)局部的 Folder 也可以使用 Runner 以及 data 進(jìn)行測(cè)試。

最新版本的 postman 已經(jīng)可以支持，為每個(gè) Postman 新建變量以及 Test

所有的請(qǐng)求都會(huì)有一些共同測(cè)試，比如測(cè)試接口是否響應(yīng)成功以及以上提到的測(cè)試 filter

pm.test("Response is right", () => {
  // status code: 2XX
  pm.response.to.be.success
})

pm.test("Filter is matching", () => {
  // ...
})

當(dāng)可以測(cè)試 Collection 后，需要對(duì)測(cè)試加入版本控制，與項(xiàng)目集成在一起，保留測(cè)試記錄，以便準(zhǔn)時(shí)定位 bug。可以與 postman 的官方工具 newman 集成在一起，但是有一點(diǎn)不方便的是，持續(xù)集成僅僅可以保存記錄，并不能還原記錄。

newman run https://api.getpostman.com/collections/{{collection_uid}}?apikey={{postman-api-key-here}} --environment https://api.getpostman.com/environments/{{environment_uid}}?apikey={{postman-api-key-here}}

按照我的理解，UI 自動(dòng)化測(cè)試目的是用來測(cè)試流程是否通暢，比如登陸，注冊(cè)，退出，如果用例沒通過則截屏。但是前端需求的不斷變化，加上現(xiàn)在各種前端框架，導(dǎo)致 selector 不是特別容易獲取到且流程容易更改。

而API 自動(dòng)化測(cè)試用來測(cè)試數(shù)據(jù)是否正確。而且大部分問題是出在數(shù)據(jù)問題上，所以 API 自動(dòng)化測(cè)試性價(jià)比比較高一些。

如何編寫測(cè)試用例

postman 底層使用 [chai.js](http://chaijs.com/api/bdd/) 的 bdd 語法作為斷言庫，另外加了一些特有的語法。

如何debug

點(diǎn)擊菜單欄 View -> Show Devtools (Show Postman Console) 可以查看響應(yīng)，檢查輸出，不過不能打斷點(diǎn)。對(duì)于系統(tǒng)的單個(gè)請(qǐng)求，可以使用 Proxy 監(jiān)聽請(qǐng)求進(jìn)行調(diào)試。

如何使用js第三方庫對(duì)請(qǐng)求就行預(yù)處理以及后處理

比如:
發(fā)送請(qǐng)求時(shí)，服務(wù)器端要求時(shí)間為 timestmap(unix) 的格式，但接口調(diào)試時(shí)可讀性過弱，是否可以使用 moment 轉(zhuǎn)化時(shí)間。
收到響應(yīng)時(shí)，也需要 moment 對(duì)時(shí)間進(jìn)行解析，獲得更好的展現(xiàn)形式。或者使用 lodash 一些函數(shù)進(jìn)行數(shù)據(jù)的處理。

可以在 Tests 和 Pre-request Script 中編寫腳本對(duì)請(qǐng)求以及響應(yīng)做一些處理。但是不能對(duì)數(shù)據(jù)格式化，比如日期。
建議前后端交流日期時(shí)使用 ISO 格式的字符串，前后端都容易解析，并且可讀性強(qiáng)。

如何管理請(qǐng)求依賴

比如:
兩個(gè)API需要有依賴關(guān)系，比如當(dāng)創(chuàng)建完一個(gè)用戶后（注冊(cè)），獲取他的個(gè)人信息。獲取個(gè)人信息就需要依賴創(chuàng)建用戶這個(gè)API。

使用 Environment Variables 可以管理依賴

如何設(shè)置統(tǒng)一的請(qǐng)求參數(shù)

比如:
大部分接口都需要統(tǒng)一的 token 參數(shù)。

目前好像沒什么辦法

如何集成到服務(wù)器端項(xiàng)目中

如果系統(tǒng)后續(xù)版本沒有通過API測(cè)試，則保留測(cè)試記錄是很重要的，版本控制可以得知該時(shí)間段內(nèi)的代碼變更。以git為例，需要每次提交后運(yùn)行測(cè)試，并保留測(cè)試結(jié)果。

可以使用 npm 包 newman 來集成到項(xiàng)目中

using variables inside postman and collection runner

writing tests in postman

postman-echo

generate spoitify playlists using a postman collection