なぜインターフェーステストを行う必要があるのでしょうか?
フロントエンド テストだけで高いカバレッジを確保することは困難です。インターフェーステストでは、フロントエンドでシミュレートできないものも含め、さまざまなタイプの入力パラメータをシミュレートできます。また、インターフェースドキュメントの定義に基づいて比較的完全な入力パラメータ値を設計して、インターフェース層でそれを保証することもできます。品質に関しては、残りの問題のほとんどは、アプリケーション自体の対話とデータ表示です。
インタラクティブなインターフェイス テストや機能テストと比較して、インターフェイス テストは自動化が容易で、実行がより安定しており、メンテナンス コストが低くなります。
インターフェイスの自動化は、回帰テスト、オンライン インターフェイス検査などに適しています。手動による回帰テストの人件費を削減し、オンライン インターフェイスの健全性を監視できます。
フロントエンドとバックエンドのシステムが分離されている セキュリティの観点から、フロントエンドのみに依存するとセキュリティ要件を満たせない フロントエンドを回避するのは比較的容易であるため、バックエンドでも入力を行う必要があるインターフェイスのテストを利用して検証できます。
1. インターフェーステストプロセス
1. インターフェイスをテストするにはどうすればよいですか?
インターフェイスをテストするにはどうすればよいですか? インターフェイスをテストするための基礎は何ですか? そのためには、機能テストのための要件仕様書と同じ機能を持つ、提供されたインターフェース文書の開発が必要となります。これには、インターフェイスの説明、呼び出し URL、リクエスト メソッド (Get、Post、または RPC プロトコル フレームワーク、Doubbo インターフェイス プロトコル)、リクエスト パラメータ、パラメータ タイプ、リクエスト パラメータの説明、および戻り結果の説明が含まれます。インターフェイス ドキュメントがあれば、インターフェイス テスト ケースを設計できます。一般に、インターフェイス テストのユース ケースは次の側面から作成できます。
2. インターフェースブラックボックスとホワイトボックスのテスト方法
◦ インターフェイスの通過可能性の検証 (最も基本)
▪ 正しいパラメータを渡し、正しい結果が返されるかどうか。
◦ パラメータの組み合わせの検証 ▪
必須パラメータと非必須パラメータがあるため、
▪ パラメータのタイプと長さ、
▪ 渡す際に考えられるいくつかのビジネス制限、
▪ パラメータの順列と組み合わせをテストして、すべての状況がカバーできることを確認します。
◦ インターフェイスのセキュリティと例外の検証
たとえば、検証をバイパスするには、注文を送信するとき、製品価格パラメータを渡すときに、バックエンドが検証を行ったかどうかを確認するために製品価格を変更するか、支払いを行うときに、可能な場合は注文金額を変更します。修正された金額で支払われました はい、このインターフェースには問題があります。
認証を回避すると、特別な権限を持ったユーザーのみが特定の機能を操作できることになりますが、一般ユーザーでも操作できるのでしょうか？
パラメータが暗号化されるかどうかは、一部のアカウントのセキュリティに関係します。たとえば、一部の Web サイトにログインするときに、ログイン情報を暗号化する必要があります。
▪ パスワード セキュリティ ルール、パスワード設定時の複雑さの検証。
注文冪等性の検証、同じ注文番号を持つ 2 つの注文を支払いに送信できるかどうか
支払い注文の支払いステータスの変更
例外テスト (トライ キャッチ テスト)
論理 OR および論理 AND のテスト
インターフェイス パラメータ 境界テスト 0負の数、int の最大値など;
◦ ビジネス ロジックに基づいてユース ケースを設計する ▪
ビジネス ロジックに準拠するということは、このインターフェイスにこの機能ロジックのすべてのアプリケーション シナリオが含まれることを意味します;
▪ 他のビジネスとのインターフェイス 輸出ビジネスの組み合わせには除外されます他のビジネスへの影響。
3. テスト分析
◦ インターフェイス テストの範囲と優先順位
◦ 独立したインターフェイス テスト分析
◦ 共同デバッグ インターフェイス テスト分析
◦ インターフェイス テスト フレームワーク分析
◦ 関連する問題:
▪ インターフェイス テスト設計文書がない場合の対処方法
▪ インターフェイス設計文書が存在しない
場合はどうすればよいかインターフェイス設計書はラフなことが多いですか?インターフェイス設計書が理解できない場合はどうすればよいですか?
4. 発煙試験
◦ ツールの選択、ポストマン
◦ スモークテスト用ツールの使い方、ポストマンの使用法
◦ スモークテスト基準の確立 ▪
新しいプロジェクトの場合、スモークテスト基準を高く設定すべきではない
▪ テスト対象のすべての機能が通常どおりに使用できる、すべての手順が正常に使用できる合格した
5. インターフェーステストスクリプトの作成
◦ 定数パラメータ
◦ 可変パラメータ
◦ テストデータのループ処理
◦ インターフェイスリクエストによって返された結果に対してアサートを実行
◦ ファイルからテストデータを抽出
6. 作業概要
◦ インターフェイス テスト プロセスの概要
◦ インターフェイス テスト テクノロジの概要
▪ ライブラリ ファイルの
インポート ▪ インターフェイス リクエストの送信
▪ 一定のクエリ条件の入力
▪ インターフェイスの戻り結果の取得
▪ 予想される入力と実際の結果の比較
◦ インターフェイス テスト作業の要約
2. ポストマンインターフェイステスト
1. インターフェースの概念
入出力の検証
2. インターフェース構成
https://svr-6-9008-api.share.51env.net/v1/article/view?id=1
◦ プロトコル https
◦ ドメイン名 svr-6-9008-api.share.51env.net
◦ ポート番号
◦パス/v1/article/view?
◦ パラメータ id=1
3. インターフェースの要素
◦ リクエストアドレス URL
◦ リクエストメソッド get/post/rpc/doubbo プロトコルなど
◦ リクエストパラメータ ID
◦ レスポンス
4. ポストマンインターフェイステスト
◦ インターフェイスのテストケースのテスト
◦ リクエストが成功しました
◦ アサーション/チェック▪
応答結果アサーション
▪ 応答データ アサーション
▪ 応答時間
3. pytest フレームワーク
1. Pythonのインターフェイステストで一般的に使用される2つのフレームワークの違い
◦ 単体テスト フレームワークは、次の規則に従う必要があります
。 ▪ テスト ファイルは、最初に Unittest をインポートする必要があります。
▪ テスト クラスは、unittest.TestCase を継承する
必要があります。 ▪ テスト メソッドは、「test_」で始まる必要があります。
▪ テスト クラスは、unittest.main() メソッドを使用する必要があります。
pytest は、Python 用のサードパーティ テスト フレームワークです。unittest に基づく拡張フレームワークであり、unittest よりもシンプルで効率的です。pytest を使用する場合は、次のルールに従う必要があります。
▪ テスト ファイル名は、「test_」で始まるか、「test_」で終わる必要があります。
▪ テスト メソッドは、「test_」で始まる必要があります。
▪ テスト クラス名は、「Test」で始まる必要があります。
2. pytest テストフレームワークのインストール
3.pytestスイッチ
4. テストケースの作成
5. インターフェイスの自動レポート生成
◦ 最初に allure をインストールします: https://www.cnblogs.com/Durant0420/p/15867983.html
◦ その後、allure を使用します。
• pytest --alluredir=report を使用して、テスト ファイル内のユース ケースを実行します。
• alluregenerate report --clean を使用して、テスト レポートを生成します。-clean は、前のレポートを上書きします。
6. インターフェーステストプロセス
◦ ライブラリファイルをインポートする
◦ インターフェイスリクエストを送信する
◦ 一定のクエリ条件を入力する
◦ インターフェイスによって返された結果を取得します
。 ◦ 予想される入力と実際の結果を比較します。
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。
この情報は、[ソフトウェア テスト] の友人にとって最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。また、皆さんのお役に立てれば幸いです。