Postmanの最も基本的な機能は、要求を再生するために使用され、優れた応答フォーマットツールと連携します。
高度な使用法については、Postmanを使用してさまざまな言語でスクリプトを生成したり、パケットをキャプチャしたり、認証したり、ファイルを転送したりできます。
これを行うだけではシステムの開発に不十分であるか、ささいなことですが、開発環境、テスト環境、本番環境を頻繁に切り替える必要があります。1つのリクエストだけでは不十分です。システムのすべてのAPIリクエストを維持する必要があり、各リクエストには異なるクエリ文字列と本文があります。
コレクション
サーバー側のすべてのリクエストは、機能またはビジネスモジュール別に整理されています。マークダウンを使用して、すべてのリクエストと例に適切な説明を追加します。現時点では、コレクションが使用されます。以下は、郵便配達の用語と組織の要求に対する提案の一部です。
-
コレクションはアプリケーションに対応し、グループの各メンバー(サーバー、クライアント、QA)はコレクションを共有します。コレクション全体にテストとドキュメントを追加できます。最初にpostmanでリクエストを整理しなかったアプリケーションの場合は、プロキシを設定し、アプリケーションを再度実行して、アプリケーションのすべてのリクエストをキャプチャできます。
-
フォルダー(ItemGroup)は、各レベルのモジュールまたはサブルートに対応します。場合は
router.use('/users')
、すべての要求は、フォルダ内にある、フォルダは、ルーティングに応じて互いの中に入れ子にすることができます。 -
リクエスト(アイテム)はリクエストに対応し、認証情報を追加できます。パケットをキャプチャするようにプロキシを設定することもできます。
-
例は、さまざまなパラメーターと応答を持つ要求に対応し、モックサーバーとドキュメントに使用されます。
Postmanは、コレクションの構造に従ってドキュメントとモックサーバーを生成できます。ただし、いずれも有料機能であり、無料版は回数に制限があります。
ドキュメンテーション
Postmanは、チームの共同作業を支援するドキュメントを自動的に生成し、手動でのドキュメントの作成とタイムリーな更新の主要なバグを解決します。
GETリクエストの場合、Postmanにフィールドの説明を追加して、ドキュメントを生成できます。
POSTおよびPUTリクエストの場合、Content-Typeがの場合、 form-data
または x-www-form-urlencoded
説明を追加してドキュメントを生成できます。ただし、最近ではjsonを渡す方が便利で柔軟性があるため application/json
、多数あり、jsonにコメントすることはできません。ドキュメントをjsonに追加する必要がある場合、冗長フィールドを追加し_{key}.comment
てコメントを示すことができ ます
{
"id": 128,
"_id.comment": "id",
"page": 10,
"_page.comment": "页数"
"pageSize": 15,
"_pageSize.comment": "每页条数"
}
ただし、冗長なフィールドが多すぎるため、テストでリクエストに対してjson検証を実行し、同時にドキュメント関数の一部として機能させることをお勧めします。結局のところ、json-schemaを使用してデータを記述し、読みやすくしています。
上記のリクエストといえば、応答ドキュメントの場合、json-schemaまたは各フィールドの説明を確認できます。テストケースが多いほど、詳細がわかります。
モック
サーバーがAPIを作成していない場合、クライアントは例に従ってモックサーバーを生成できます。
クライアントが独自のモックを作成し、それをプロジェクトと統合し、便利で柔軟なバージョン管理を組み込むことをお勧めします。
テスト
リクエストごとに、テストケースが必要です。応答が成功したかどうか、応答時間が長すぎるかどうか、または応答jsonのデータ型が正しいかどうかを確認します。
テストが使用可能 pm.expect
のため BDD
のテスト、およびスタイルがある chai
非常に似ています。あなたが精通している場合 chai
、それは、始めるのは簡単です。
Postmanにはサードパーティのライブラリがいくつか組み込まれています。必要に応じて chai
、直接使用するか、またはpm.expect
chai BDD APIと整合性のある基礎となるchai実装を使用でき ます。
Postmanには、ステータスコード、ヘッダー、本文などのhttp関連のテストAPIもいくつかあり、スニペットもいくつか提供しています。
// 响应成功
pm.test('Status code is 200', () => {
pm.response.to.have.status(200)
})
// 响应成功 chai.expect
pm.test('Status code is 200', () => {
chai.expect(pm.response).to.have.property('code', 200)
})
// 校验响应数据
pm.test('Page is 100', () => {
const jsonData = pm.response.json()
chai.expect(jsonData.page).to.eql(100)
})
Jsonスキーマ
json-schemaは、json情報を記述し、jsonをより読みやすくするために使用でき、jsonの正当性を検証するためにも使用できます。主要な言語には、jsonスキーマを実装するライブラリがあります。
すべてのGET応答でjson-schema検証を実行することをお勧めします。最初にデータを検証し、次にドキュメントとして使用することもできます。tv4を使用して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)
})
リクエストにjson検証を追加することもできますが、postmanはすべてのリクエストパラメータを取得するためにAPIに直接渡さないため、自分で解析および計算する必要があります。
// 获取 application/json 中的数据
const json = JSON.stringify(pm.request.body.raw)
// 获取 GET query string 的数据
const qs = pm.request.url.query.toObject()
postmanがリクエストパラメータのjson-schemaに基づいてデータを自動的に生成できれば素晴らしいと思います...
テスト要求パラメーター
ようなパラメータの数と要求 も 異なるパラメータが異なる応答を有します。GET
querystring(search)
POST
body
リクエストの異なるパラメーターによって返されるjsonスキーマが完全に異なると仮定すると、2つのリクエストを記述して別々にテストできます。返されたjsonスキーマは同じでも値が異なる場合は、渡されるパラメーターとパラメーターの数を考慮する必要があります。
古典的なシナリオでは、修飾リストはフィルターに従ってフィルタリングされます。例としてユーザーリストを取り上げます。擬似コードは次のとおりです。
const url = '/api/users'
const query = {
name: 'san',
age: 12,
sex: 'MALE'
}
// 注意query数据需要校验,防止 SQL 注入
const sql = `select * from users where name = ${query.name} and age = ${query.age} and sex = ${query.sex}`
1つのアイデアは、要求されたパラメーターに従ってテストすることです。重要なスニペットは、postmanでクエリ文字列を取得することです。クエリは、PropertyList
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])
})
}
もちろん、上記のフィルターには、等価性テストのみを含む最も単純なシナリオのみが含まれています。しかし、格差と包含関係があります。
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}`
この種のリクエストパラメータは、フロントエンドとバックエンドの間のネゴシエーションと通信に依存します。もちろん、テストや無知の開発には非常に不向きです。
もちろん、渡した各クエリを処理する必要があり、将来フィルターフィールドを追加するたびに手動で変更する必要があるため、バックエンドには適していません。
mongoと同様の検索構文を使用するなど、フィルタリングするデータを決定するのはフロントエンドです。
graphqlはかなりクールで、試す価値があります
const query = {
name: {
$like: 'san'
},
age: {
$lt: 12
},
sex: 'MALE'
}
ただし、これには比較的高いテスト開発機能が必要であり、テスターはパラメーターを分析してインターフェースをテストする必要があります。
複数のリクエストをテストする
関数を単体テストする場合、多くの入力と予想される出力が必要です。郵便配達では、data
複数の入力をシミュレートするために使用できます
データは変数であり、ランナーでのみ使用できます。フォルダごとに関連データファイルを確立し、バージョン管理を追加する必要があります
- postmanコレクションランナーでのcsvおよびjsonファイルの使用
統合テスト
1つのAPIテストに合格したら、すべてのリクエストをテスト用に統合する必要があります。現時点では2つの問題があります
- APIの依存関係を確認する方法
- API間でデータを渡す方法
これは、順番コレクションで要求を開始し、順序を変更するために強制的に必要であれば、あなたが使用することができます彼らの要求の順序で setNextRuest()
郵便配達にデータの3つの範囲を、data
、environment
、global
。リクエストで{
{}}
プレースホルダーに 置き換えます。
environment
これを使用しHOST
て、URL内のローカル環境、開発環境、および実稼働環境を頻繁に手動で切り替えることを回避でき ます。データの転送にも使用できます。
一般的なシナリオは、プロジェクトがトークンを使用してログイン情報を保存し、各リクエストがトークンを運ぶ必要があるというものです。トークンの環境変数は、ログインテストコードで設定できます。
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}}'
テストコレクション
依存関係を確認したら、コレクションに新しいランナーを作成し、すべてのリクエストをテストするためのデータファイルを導入できます。ランナーとデータを使用して、部分的なフォルダーをテストすることもできます。
最新バージョンのポストマンはすでにサポートされています。ポストマンごとに新しい変数とテストを作成します
すべてのリクエストには、テストインターフェイスが正常に応答するかどうか、上記のテストフィルターなど、いくつかの一般的なテストが含まれます
pm.test('Response is right', () => {
// status code: 2XX
pm.response.to.be.success
})
pm.test('Filter is matching', () => {
// ...
})
継続的インテグレーション
コレクションをテストできる場合、バージョン管理をテストに追加し、それをプロジェクトに統合し、テスト記録を保存して、バグを予定どおりに見つける必要があります。郵便配達員の公式ツールとnewman
統合できます が、1つの不便な点は、継続的な統合ではレコードを保存するだけで、レコードを復元できないことです。
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自動化テスト
私の理解によると、UI自動化テストの目的は、ログイン、登録、ログアウトなどのプロセスがスムーズかどうかをテストし、ユースケースが失敗した場合のスクリーンショットをテストすることです。ただし、フロントエンド要件の絶え間ない変更と、さまざまなフロントエンドフレームワークが組み合わさることで、セレクターを取得するのが特に簡単でなくなり、プロセスを変更するのも簡単です。
API自動テストは、データが正しいかどうかをテストするために使用されます。また、問題のほとんどはデータの問題であるため、API自動テストの方が費用対効果が高くなります。
ソフトウェアテスト、インターフェーステスト、自動テスト、インタビューの経験を交換する場合。興味がある場合は、ソフトウェアテスト通信(1085991341)を追加できます。同僚との技術交流があります。
総括する
- テストケースの書き方
[chai.js]
postmanの下部で使用さ れているbdd文法がアサーションライブラリとして使用され、いくつかの一意の文法が追加されています。
- デバッグする方法
メニューバーの[表示]-> [Devtoolsの表示(Postmanコンソールの表示)]をクリックして、応答を表示し、出力を確認しますが、ポイントを中断することはできません。システムの単一の要求に対して、プロキシを使用してデバッグの要求を監視できます。
- jsサードパーティライブラリを使用してリクエストを前処理および後処理する方法
例:リクエストを送信するとき、サーバーは時間timestmap(unix)
の形式を必要と しますが、デバッグ時にインターフェースの読みやすさが弱すぎる場合、moment
変換時間を使用でき ますか?応答を受け取っmoment
たら、より良いプレゼンテーションを得るために時間を分析する必要もあります 。またはlodash
、データ処理にいくつかの関数を使用 します。
テストと事前リクエストスクリプトでスクリプトを記述して、リクエストとレスポンスの処理を行うことができます。ただし、日付などのデータをフォーマットすることはできません。フロントエンドとバックエンドの間で日付をやり取りするときは、ISO形式の文字列を使用することをお勧めします。フロントエンドとバックエンドの両方が解析しやすく、読みやすくなっています。
- リクエストの依存関係を管理する方法
例:2つのAPIには依存関係が必要であり、たとえば、ユーザーが作成(登録)されると、その個人情報が取得されます。個人情報を取得するには、APIを使用してユーザーを作成する必要があります。
環境変数を使用して依存関係を管理する
- 統一リクエストパラメータを設定する方法
次に例を示しtoken
ます。ほとんどのインターフェイスには、統一されたパラメータが必要です 。
仕方がないようです
- サーバー側プロジェクトに統合する方法
システムの後続のバージョンがAPIテストに失敗した場合、テストレコードを保持することが重要であり、バージョン管理はこの期間中のコードの変更を認識できます。gitを例にとると、各送信後にテストを実行し、テスト結果を保持する必要があります。
npmパッケージnewmanを使用してプロジェクトに統合できます
上記の内容は、この記事の内容全体です。上記の内容は、あなたのお役に立てれば幸いです。