(1) インターフェースの自動化をどのように行うか?
0. リサーチ、前提準備と思考
a) 前提:
1. ユースケースを正式に設計する場合、postman/jmeter などのツールを組み合わせる
2. さまざまなテストデータを設計し、リクエストを開始し、応答結果が設計と一致するかどうかを確認する
3. (手動テストを行う必要があります) -- バグが見つかりました。
b) ユースケースの保存方法:
1. Excel フォーム - JSON パスを設定します。
2. JSON ファイル - JSON ファイルに記述された多くのリクエストパラメータがあります。
3. yaml ファイル - httprunner3.0
4 、データベース - テーブルの作成
c) 自動化のカバレッジはどうですか
: 機能/手動ユースケースのカバレッジ - 30% - 90%
1. このプロジェクトのインターフェースを自動化してどのくらいですか?
2. システムの規模はどれくらいですか? 複雑ですか？
3. 対象となるユースケースは何件ありますか? どのような困難 (および解決策) に遭遇しましたか?
1. 要件分析
プロジェクトのビジネス機能、バグが多いモジュール、比較的安定したインターフェイスは何か、コア機能は何かを理解します。
2. インターフェースを理解する
2.1 パケットをキャプチャしてインターフェースを見る
2.2 インターフェースドキュメントを通して理解する
3. 自動化フレームワークとツールの選択
3.1 作業と拡張言語のスケーラビリティ + 試用のためのいくつかの複雑なインターフェイスの選択
3.2 フレームワーク構造の比較
3.3 仕様の命名
4. インターフェースのユースケースを書く
4.1 インターフェースのユースケーススクリプトを書く
- 1. コアビジネスを第一に - 最高のユーザー稼働率を実現
- 2. ユースケースの優先順位 - 一般的な機能シナリオ/必要なパラメーター
- 3. パラメータの形式の有効性 - バックエンドでは検証は行われません
- 4. 通常のユースケースが最初に設計され、異常なシナリオが最初に設計されます（包括的）
4.2 できるだけ早く jenkins 統合に参加する
4.3 進捗状況を定期的に報告する
4.4 レポートをテストし、レポートを自動的に送信し、ユースケースの失敗の原因を分析する
4.5 最初から現在のバグまでインターフェースの自動化を記録する
4.6 例外処理
5. 永続化レイヤー構造
1. データをデータベースに直接挿入する
6. メンテナンス フェーズ
1. インターフェイスの開発と変更、インターフェイス スクリプトの同期的な変更のテスト
2. 新しいインターフェイスの追加、新しいインターフェイスの使用例の同期的な追加3.
スクリプトと日常のフレームワークの
最適化
(2) 単一モジュールをテストするにはどうすればよいですか?
単一モジュールテスト: 主に、単一のビジネス機能のインターフェイス実装をチェックするか、テストデータをデバッグするテスト作業で使用されます。
ステップ 1: 上流と下流のコール チェーンを整理する
1) 上流と下流のコール チェーンを整理する必要があるのはなぜですか?
現在、インターネット製品のバックエンドサービスは基本的に分散配置されており 、インターフェースが他のインターフェースを呼び出したり、他のインターフェースから呼び出されたりするなど、インターフェース間には無数の依存関係が存在します。パラメータだけを調整する
だけでは、インターフェースのテストを適切に行うことは明らかに不可能です。（開発者は（tiao）インターフェイスパラメータを自分で調整できますが、他に何をテストする必要がありますか？）2) 上流と下流の呼び出しチェーンをどのように分類するか? 1. プロジェクト Wiki、製品ドキュメント、開発ドキュメントを見る2. 開発者が書いたコードを見て、コードを読む3. 上流と下流の呼び出しの関係を整理し、システム フローチャートを描くポイント、PM、開発者通信確認を見つけることができます
ステップ 2: インターフェイスのテスト ケースを作成する
インターフェイスを自動化したい場合は、インターフェイス テスト ケースも非常に役立ちます。
以下はインターフェースのテストケースの例です。
ステップ 3: インターフェースのドキュメントとデバッグインターフェースをテストする
プロジェクト開発の開始時に、フロントエンド開発とバックエンド開発は共同で一連のインターフェース仕様に合意し、その後バックエンド開発がインターフェース文書を作成します。その後、フロントエンドとバックエンドは、協定に基づき共同開発を実施します。
インターフェイス ドキュメントを管理および編集するには、いくつかの方法があります。
- 一部のチームは、 Wikiまたはオンライン ドキュメントを使用してインターフェイス ドキュメントを作成することに慣れています。
- 一部のチームは、 Swagger、Yapiなどのプロフェッショナルなインターフェイス ドキュメント ツールを使用してインターフェイス ドキュメントを生成することを好みます。
テスト インターフェイスのドキュメントでは、次のテスト ポイントを参照できます。
- 開発を確実にするために、インターフェイスのドキュメントを提供する必要があります。開発者にインターフェイス ドキュメントを作成する習慣がない場合は、開発者にインターフェイス ドキュメントを作成するよう促す必要があります。
- URL、リクエストメソッド、ヘッダー、入力パラメータ、戻り値、サンプルデモなどを含むインターフェースドキュメントの形式と内容が完全であるかどうかを確認します。
- インターフェースの設計が会社の仕様に準拠しているかどうかを確認してください。インターフェイスの名前、インターフェイスの形式、フィールドの名前、フィールド タイプ、応答ステータス コード、インターフェイスのフォールト トレランス、フィールドが冗長であるかどうか、インターフェイスが認証されているかどうか、バージョンを区別するかどうかなどが含まれます。
バックエンド開発がインターフェースの開発を完了すると、事前にインターフェースの予備テストを開始できます。
次のように進めます。
- バックエンド コードをテスト環境にデプロイします。
- postman または swaggerを使用して、インターフェイスのドキュメントに記載されているインターフェイスをテストします。
ステップ 4: フロントエンド インターフェイス テスト & モック データ (インターフェイス レベル テスト)
前の手順は、テスト ツールを使用してネットワーク リクエストを開始し、インターフェイス呼び出しをシミュレートするだけです。
しかし、実際のシナリオでは、検索ゲートウェイのインターフェイスは、APP/WEB/小さなプログラムが呼び出すために実際に提供されます。
フロントエンドの呼び出しプロセスが正常であるかどうかにも注意する必要があります。(テストに介入する前に、フロントエンドの開発が完了するまで待つ必要があります)
Charles を使用して、フロントエンドによって送信されたリクエストをキャプチャできます。
- フロントエンド呼び出しインターフェイスに渡されたパラメータが正しいことを確認します。
- バックエンドのインターフェース応答が期待どおりかどうかを検証します。
- フロントエンドがデータを取得した後、インタラクションと UI 表示が正しいかどうか。
一部のデータに複数の状態があり、データの構築が難しい場合は、モック データを使用してテストできます。
データをモックする一般的な方法は次のとおりです。
- Fiddler または Charles を使用してリクエストとレスポンスを改ざんします。
- PHP や Python などの動的言語の場合は、バックエンド コードで条件を直接変更できます。
- データベース内のデータを変更するため。
- EasyMock、TestableMock、Mockjs などのプロフェッショナルな Mock ツールを使用してデータを構築します。
もちろん、より早い方法は、 Charles を直接使用してシミュレーションすることです。
ステップ 5: バックエンド インターフェイスのテストとビジネス ロジックのカバレッジ (ログ、コードを参照)
ログを参照してください
ビジネステスト中は、バックエンドのログステータスを監視する必要があります。
場合によっては、インターフェイスの応答データは正常であっても、バックエンド ログがエラーを報告している場合があります。
コードを見てください
インターフェイスのテストを行うときは、開発のソース コードを必ず読むことをお勧めします。
ソース コードを読むと、ビジネス ロジックの実装についてより深く理解できます。
コードの量が多い場合はどうすればよいでしょうか?
ちょっとしたトリックを教えましょう。開発者がコードを送信した後、Gitlab で彼のコミット レコードを表示したり、開発ブランチと運用環境のブランチの間の差分を作成したりして、開発者が何を変更したかを知ることができます。
ステップ 6: インターフェイスのパフォーマンスのチューニング (Arthas)
トラブルシューティング プロセス :
(1) まず、APP 上で再現してみます。
(2) Arthas のトレースを通じて、インターフェイスの応答が遅い理由を段階的にトラブルシューティングします。Arthas
コマンド ラインを入力します。
java -jar arthas-boot.jar
トレースインターフェイスによって呼び出されるメソッド
trace 类名 方法名
ステップ 7: インターフェイスのバージョン管理と diffy
一般に、インターフェイスはバージョンを区別しますが、インターフェイスがあまり標準化されていない場合、または一般的なロジックが変更されている場合は、この時点で古いバージョンでの回帰テストが必要です。
最も愚かな方法は、2 つのアプリの新旧バージョンを比較してテストすることです。回帰テストには diffy ツールを使用することもできます。
ステップ 8: インターフェースの自動化を開始する
インターフェイスの自動化は通常、オンライン検査の回帰やスモーク テストなどのシナリオで使用されます。
インターフェイスの自動化を実現するには、次の方法を使用します。
コーディング：
現在、python+pytest+requests がこの方法で使用されています。(小さくて美しく、カスタマイズが簡単)
(3) 複数のモジュールの関連付けをテストするにはどうすればよいですか?
モジュール関連付け: トランザクション全体のテスト カバレッジを実現し、基本的なツール インターフェイス自動テストを実現するために、パラメータ化の形式で 2 つ以上の関連する API の入力パラメータと出力パラメータを動的に関連付けることを指します。
ステップ 1: 上流と下流のコール チェーンを整理する
1) 上流と下流のコール チェーンを整理する必要があるのはなぜですか?
現在、インターネット製品のバックエンドサービスは基本的に分散配置されており 、インターフェースが他のインターフェースを呼び出したり、他のインターフェースから呼び出されたりするなど、インターフェース間には無数の依存関係が存在します。パラメータだけを調整する
だけでは、インターフェースのテストを適切に行うことは明らかに不可能です。（開発者は（tiao）インターフェイスパラメータを自分で調整できますが、他に何をテストする必要がありますか？）2) 上流と下流の呼び出しチェーンをどのように分類するか? 1. プロジェクト Wiki、製品ドキュメント、開発ドキュメントを見る2. 開発者が書いたコードを見て、コードを読む3. 上流と下流の呼び出しの関係を整理し、システム フローチャートを描くポイント、PM、開発者通信確認を見つけることができます
ステップ 2: インターフェイスのテスト ケースを作成する
インターフェイスを自動化したい場合は、インターフェイス テスト ケースも非常に役立ちます。
以下はインターフェースのテストケースの例です。
ステップ 3: インターフェースのドキュメントとデバッグインターフェースをテストする
プロジェクト開発の開始時に、フロントエンド開発とバックエンド開発は共同で一連のインターフェース仕様に合意し、その後バックエンド開発がインターフェース文書を作成します。その後、フロントエンドとバックエンドは、協定に基づき共同開発を実施します。
インターフェイス ドキュメントを管理および編集するには、いくつかの方法があります。
- 一部のチームは、 Wikiまたはオンライン ドキュメントを使用してインターフェイス ドキュメントを作成することに慣れています。
- 一部のチームは、 Swagger、Yapiなどのプロフェッショナルなインターフェイス ドキュメント ツールを使用してインターフェイス ドキュメントを生成することを好みます。
テスト インターフェイスのドキュメントでは、次のテスト ポイントを参照できます。
- 開発を確実にするために、インターフェイスのドキュメントを提供する必要があります。開発者にインターフェイス ドキュメントを作成する習慣がない場合は、開発者にインターフェイス ドキュメントを作成するよう促す必要があります。
- URL、リクエストメソッド、ヘッダー、入力パラメータ、戻り値、サンプルデモなどを含むインターフェースドキュメントの形式と内容が完全であるかどうかを確認します。
- インターフェースの設計が会社の仕様に準拠しているかどうかを確認してください。インターフェイスの名前、インターフェイスの形式、フィールドの名前、フィールド タイプ、応答ステータス コード、インターフェイスのフォールト トレランス、フィールドが冗長であるかどうか、インターフェイスが認証されているかどうか、バージョンを区別するかどうかなどが含まれます。
バックエンド開発がインターフェースの開発を完了すると、事前にインターフェースの予備テストを開始できます。
次のように進めます。
- バックエンド コードをテスト環境にデプロイします。
- postman または swaggerを使用して、インターフェイスのドキュメントに記載されているインターフェイスをテストします。
ステップ 4: インターフェイス シーンのデザイン
背景: 既存のプラットフォームは、単一サービス、単一インターフェイスの自動テスト プロセスとしては比較的成熟しており、複雑なサービス間での自動ユースケース構成に対する需要のフィードバックが増加しているため、複雑なテスト シナリオのサポートが追加されています。
どのようなユース ケースがシナリオに適していますか
? ビジネス フローと呼ぶこともできます。たとえば、e コマース ケースを取り上げ、購入 - 支払い - 支払いステータスの確認 - 権限の表示 - 返金 - 返金ステータスの確認
- クロスアプリケーションであるかどうかに関係なく、ステップの前後には強い依存関係があります。
- 注文、支払い、履行、返金などのコア ビジネス シナリオ
上記の背景を踏まえ、本プロジェクトの対応する機能点は以下のとおりです。
- 従来の[プロジェクト]に相当する[シーンセット]の概念を追加
- 従来の「ユースケースセット」と同様の「テストシナリオ」の概念を追加
- 関連するテストシナリオのトリガー
ステップ 5: フロントエンド インターフェイス テスト & モック データ (インターフェイス レベル テスト)
前の手順は、テスト ツールを使用してネットワーク リクエストを開始し、インターフェイス呼び出しをシミュレートするだけです。
しかし、実際のシナリオでは、検索ゲートウェイのインターフェイスは、APP/WEB/小さなプログラムが呼び出すために実際に提供されます。
フロントエンドの呼び出しプロセスが正常であるかどうかにも注意する必要があります。(テストに介入する前に、フロントエンドの開発が完了するまで待つ必要があります)
Charles を使用して、フロントエンドによって送信されたリクエストをキャプチャできます。
- フロントエンド呼び出しインターフェイスに渡されたパラメータが正しいことを確認します。
- バックエンドのインターフェース応答が期待どおりかどうかを検証します。
- フロントエンドがデータを取得した後、インタラクションと UI 表示が正しいかどうか。
一部のデータに複数の状態があり、データの構築が難しい場合は、モック データを使用してテストできます。
データをモックする一般的な方法は次のとおりです。
- Fiddler または Charles を使用してリクエストとレスポンスを改ざんします。
- PHP や Python などの動的言語の場合は、バックエンド コードで条件を直接変更できます。
- データベース内のデータを変更するため。
- EasyMock、TestableMock、Mockjs などのプロフェッショナルな Mock ツールを使用してデータを構築します。
もちろん、より早い方法は、 Charles を直接使用してシミュレーションすることです。
ステップ 6: バックエンド インターフェイスのテストとビジネス ロジックのカバレッジ (ログ、コードを参照)
ログを参照してください
ビジネステスト中は、バックエンドのログステータスを監視する必要があります。
場合によっては、インターフェイスの応答データは正常であっても、バックエンド ログがエラーを報告している場合があります。
コードを見てください
インターフェイスのテストを行うときは、開発のソース コードを必ず読むことをお勧めします。
ソース コードを読むと、ビジネス ロジックの実装についてより深く理解できます。
コードの量が多い場合はどうすればよいでしょうか?
ちょっとしたトリックを教えましょう。開発者がコードを送信した後、Gitlab で彼のコミット レコードを表示したり、開発ブランチと運用環境のブランチの間の差分を作成したりして、開発者が何を変更したかを知ることができます。
ステップ 7: インターフェイスのパフォーマンスのチューニング (Arthas)
トラブルシューティング プロセス :
(1) まず、APP 上で再現してみます。
(2) Arthas のトレースを通じて、インターフェイスの応答が遅い理由を段階的にトラブルシューティングします。Arthas
コマンド ラインを入力します。
java -jar arthas-boot.jar
トレースインターフェイスによって呼び出されるメソッド
trace 类名 方法名
ステップ 8: インターフェース例外メカニズム (Chaosblade)
インターフェイスは多くのサービスに依存するため、多くの場合、他のインターフェイスを呼び出す必要があります。依存するサービスに例外がある場合、インターフェイスがフォールト トレラントであるか、ダウングレードされているかを考慮する必要があります。
Chaosblade を使用して例外を挿入できます。(必須ではありませんが、あったほうが良いです)
ステップ 9: インターフェイスのバージョン管理と diffy
一般に、インターフェイスはバージョンを区別しますが、インターフェイスがあまり標準化されていない場合、または一般的なロジックが変更されている場合は、この時点で古いバージョンでの回帰テストが必要です。
最も愚かな方法は、2 つのアプリの新旧バージョンを比較してテストすることです。回帰テストには diffy ツールを使用することもできます。
ステップ 10: インターフェースの自動化を開始する
インターフェイスの自動化は通常、オンライン検査の回帰やスモーク テストなどのシナリオで使用されます。
インターフェイスの自動化を実現するには、次の方法を使用します。
コーディング：
現在、python+pytest+requests がこの方法で使用されています。(小さくて美しく、カスタマイズが簡単)