Troubleshooting Smart API Test Generator Tests

はじめに

トラフィックから Smart API テストを作成して Smart API テスト生成を構成した後もなおテストで問題が発生する場合は、以下の情報が問題のトラブルシューティングに役立つ可能性があります。

認証/承認

Smart API Test Generator は、認証/承認に関連するテスト手順を適切に構成できない場合があります。Smart API Test Generator でテストスイートが作成された後、承認ヘッダーでユーザーの注意と構成が必要になることがよくあります。テスト手順の早い段階でテストスイートが失敗し、「401 Unauthorized」という応答が表示される場合、これはテストスイートの認証/承認の処理方法に問題があることを示しています。

アプリケーションが外部のログインページにリダイレクトされるか？

これは、外部エンティティ プロバイダーがテスト対象アプリケーションの認証/承認を処理する OAuth2 または同様のメカニズムを指している可能性があります。一般的に言えば、これは、アプリケーションへのリダイレクト時に生成されて送り返されるトークンがあり、アプリケーションが API 呼び出しを行う際にこのトークンを使用することを意味します。

アプリケーションがログインを処理する方法について、技術的な詳細 (通常は HTTP トラフィック) を調査する必要があります。テスト クライアントのログインに認証される正しいデータが含まれていない原因として、リクエストの欠落またはパラメータライズの欠落/誤設定が複合的に存在する可能性があります。詳細については、以下の「Troubleshooting Steps」のセクションを参照してください。

アプリケーションが実際に OAuth2 で保護されている場合、フロントエンド API でサポートされている許可タイプを調べることが重要です。

SOAtest での OAuth2 認証の設定の詳細については、「OAuth 認証」を参照してください。

この認証が多くのテストシナリオに共通するものである場合、スマート テスト テンプレートを使用して、Smart API Test Generator で生成されたテストスイートで適切な OAuth2 ステップを自動構成することを検討できます。詳細については「OAuth 2.0 Client Credential Flow での Smart Test Template の使用」を参照してください。

その他

ログインページがアプリケーション自体に統合されている場合でも、Smart API Test Generator がテストスイートを適切に構成できない場合があります。ブラウザーがフロントエンド API への認証をどのように処理するか (Cookie、Authorization ヘッダー、その他の方法など) を調査することは、ログイン時に UI によって実行されるトラフィックを適切に再生するためにテスト スイートに必要な設定の変更を見つける上で、重要な役割を果たします。

Cookie

多くのアプリケーションでは、セッション情報、ユーザー設定、または認証ステータスを維持するために特定の Cookie が必要です。最初の HTTP リクエストで必要な Cookie を取得できない場合、その後の呼び出しに失敗する可能性があります。テストスイートの早期のエラーは、多くの場合、SOAtest が送信していないがアプリケーション UI が送信している HTTP リクエストが欠落していることを表します。詳細なトラブルシューティングの手順については、以下の「トラブルシューティングの手順」のセクションを参照してください。

HTTP ヘッダーの欠落/誤り

アプリケーション API が API クライアントで特定のセキュリティ ヘッダーを期待している場合、リクエストの欠落またはパラメータライズの欠落/誤設定が複合的に存在する可能性があります。認証された API クライアントにつながる、予想される HTTP トラフィックを把握することは、このようなケースのトラブルシューティングにおいて非常に重要です。レコーディングからの生のトラフィック ファイルには、UI を介してエンドツーエンドのフローを実行しているときにブラウザーから送信された正確な HTTP トラフィックが含まれるため、このトラフィック ファイルを分析するのは最初のステップとして有効です。詳細については、以下の「Troubleshooting Steps」のセクションを参照してください。

テストの失敗/悪い結果

テストスイートが認証/承認の手順を通過し、アプリケーションが機能 API からテストクライアントにデータを正常に返している場合、一般的な構成の問題の 1 つは排除されます。 ただし、テスト手順がまだ失敗している可能性があります。または、テストスイートの実行後に確認したときに、テストの期待通りの結果がアプリケーションで得られない可能性があります。

同時に複数の問題が発生している可能性があります。テストスイートに重要なリクエストが欠落している、データバンクがデータを抽出できない、データバンクが間違ったデータを抽出している、またはデータバンクに格納されなかったハードコードされたデータがある可能性があります。これらの問題は、後続のテスト手順で連鎖的な問題を引き起こす可能性があります。詳細については、以下の「Troubleshooting Steps」のセクションを参照してください。

テストスイートは動作していたが、現在は失敗 / 悪い結果

テスト環境に新しいビルドがデプロイされましたか? テスト対象のシナリオのビジネスロジックが、API レイヤーで何らかの形で変更された可能性があります。新しい API トラフィックをキャプチャし、エクスペリエンス API との UI インタラクションの最新の動作を反映したテストスイートを作成するには、ユースケースの UI フローを再記録する必要がある場合があります。

UI テストが自動化されている場合は、Smart API Test Generator REST API を使用して、レコーディングプロセスを UI テスト フレームワークに挿入できます。

Java Selenium を使用した次のサンプル リポジトリを参照してください:  Selenium Recorder API Example

トラブルシューティングの手順

リクエストの欠落

トラブルシューティングの適切な手順は、レコーディングから生のトラフィック ファイルをレビューし、トラフィック ファイルに存在する HTTP リクエストが SOAtest テスト スイートで欠落していないかどうかを確認することです。記録から TST ファイルが作成されると、SOAtest ワークスペースの /TestAssets/users/<USERNAME>/recorded_traffic に生のトラフィック ファイルが含まれます。

tst_creation.properties ファイルの操作の詳細については、「テスト作成プロパティ」を参照してください。

デフォルトでは、Smart API Test Generator は、application/json および application/x-www-form-urlencoded 以外のコンテンツ タイプの HTTP トラフィックをフィルタリングします。HTTP トラフィックがレコーディングから適切にフィルタリングされるように、tst_creation.properties ファイルを調整する必要がある場合があります。たとえば、テスト スイートが正しく機能するために必要な HTTP 呼び出しのフローに関連する別のコンテンツ タイプが存在する場合、それを includeContentTypes プロパティに追加できます。また、アプリケーション サーバーがレスポンスでコンテンツ タイプを返さない場合は、そのコンテンツ タイプもフィルターで除外される可能性があります。このような場合は、includeURLPatterns プロパティと excludeURLPatterns プロパティの使用を検討してください。

このフィルタリングは、Smart API Test Generator の設定における重要なステップです。ブラウザー トラフィックの一部は、アプリケーションの API レイヤーのテストには無関係であり (HTML、CSS、JS、PNG、その他のコンテンツなど) 、デフォルト設定ではフィルタリングが過剰になる可能性があるからです。

データ バンクの失敗

これは、データバンクが特定の XPath を使用して構成されており、SOAtest クライアントが受信したレスポンスから要素を見つけることができないことを意味します。

トラブルシューティングの適切な手順は、tst_creation.properties ファイルで disableDiffCreation プロパティが false に設定されていることを確認することです。これにより、各テスト ステップで Diff ツールが作成され、ライブレスポンスが、最初に記録された HTTP トラフィックに基づく期待されるレスポンスと比較されます。

tst_creation.properties ファイルの操作の詳細については、「テスト作成プロパティ」を参照してください。

テストスイート内の最初の失敗したテストからトラブルシューティングを開始します。レスポンスペイロードが正しいか有効であることを確認します。エラーの受信など、実際のレスポンスと期待されるレスポンスに大きな違いがある場合は、この特定のテストステップが誤って構成されているか、または問題が以前のテストステップに起因している可能性があります。Smart API Test Generator によって作成されたテスト スイートでは、テスト クライアント全体でデータの連鎖効果が見られることがよくあります。API レスポンスのシーケンスの複数のポイントに同じデータ要素が存在する場合、Smart API Test Generator は、そのデータが最初に現れた元のテストステップを使用するのではなく、各レスポンスでそのデータ要素を再抽出することを優先します。

失敗したテストクライアントの設定を確認し、特に、前のテストステップを参照するデータバンク変数にパラメータライズされたリクエストパラメーターに注意してください。これにより、前のテスト ステップが成功している場合でも、シナリオが失敗し始めた原因となっている可能性のある、以前のテスト ステップをトレースする手がかりが得られます。

レスポンスペイロードが正しく、期待されるレスポンスと類似している場合、データバンクの XPath 構成を分析して、JSON の構造が Diff ツールでキャプチャされた元の記録されたレスポンスからまったく変化していないかどうかを確認します (または生のトラフィックファイルを調べます)。期待されるデータ値はレスポンスに存在しますが、順序が異なっていたり、配列内にあったりしていませんか? データ要素をより効率的に見つけられるように、XPath 条件と関数を組み込むことで、データ バンク抽出の XPath を改善する必要がある場合があります。 

データバンクが誤ったデータを抽出する

これは、抽出されるデータが配列に含まれている場合に発生する可能性があります。Smart API Test Generator が、テストシナリオの以降の実行でレスポンスがどのように変化するかを処理しない XPath を生成している可能性があり、これは配列に含まれるデータ要素によって明らかになることがあります。XPath 関数を組み込むか XPath 自体をパラメータライズすることで XPath を改善し、データ抽出のために配列の正しいインデックスを確実に選択できるようにする必要があります。

ハードコーディングすべきパラメータライズされたデータ

Smart API Test Generator が、ハードコーディングされたままにしておくべきデータを過剰にパラメータライズしてしまうケースがあります。たとえば、レスポンスペイロードに、後続のリクエストパラメーターと偶然一致するデータが含まれているが、それらのデータ要素が互いに関連していない場合、テストを再実行した際にデータが変更されると、テスト スイートが失敗する可能性があります。これに対処するために、tst_creation.properties ファイルの requestPayloadParameterizationExcludeNames プロパティを使用できます。

tst_creation.properties ファイルの操作の詳細については、「テスト作成プロパティ」を参照してください。

パラメータライズすべきハードコーディングされたデータ

Smart API Test Generator が、テストスイートで成功した結果を得るためにパラメータライズする必要があるデータをハードコーディングしている場合があります。たとえば、multipart/form-data のようなパラメータライズに対応していないリクエストコンテンツタイプの場合に、このようなことが起こり得ます。このような場合、以前のテスト ステップから抽出された適切な動的データを使用して、ハードコーディングされた値を手動でパラメータライズする必要があります。

重要な動的データが HTML ページでのみ利用できる場合があります (API トラフィックからは見つけられず、HTML にハードコーディングされたデータとしてのみ存在します)。このデータは、後続の API テスト クライアントのリクエスト パラメーターで必要な場合があります。このような状況の場合、tst_creation.properties ファイルには、Smart API Test Generator がそのようなデータをデータバンクに登録するよう検索する設定があります。具体的には、次のとおりです。

1. includeTextResponseContentTypes: このプロパティを、関連データを含むレスポンス トラフィックのコンテンツ タイプ (text/html など) に設定します。
2. includeTextResponseValues: このプロパティを、テキストレスポンスで発見されるデータを一意に識別する正規表現に設定します。

SOAtest は、テキストの左境界と右境界に正規表現を使用してテキスト データ バンクを作成し、後続の API テスト クライアントで使用される動的データを抽出します。

tst_creation.properties ファイルの操作の詳細については、「テスト作成プロパティ」を参照してください。

アサーションの失敗

アサーションを作成するように Smart API Test Generator を設定している場合、類似したレスポンス (たとえば同じリソースへの繰り返しのリクエストなど) を識別し、レスポンスデータがどのように変更されたかをアサーションの候補として分析します。ユーザーは、これらのアサーションが期待どおりに機能していることを確認する必要があります。データ バンクとパラメータライズのトラブルシューティングと同様に、アサーション対象のデータに対して不適切な XPath が生成される場合があります。このような場合は、XPath 条件と関数を組み込むことを検討してください。複数の実行で変更されると予想されるデータに対して、異なるタイプのアサーション (たとえば正規表現や範囲アサーションなど) を適用してみることもできます。

また、テストにとって重要ではないデータに対して表明が適用される可能性もあります。この場合は、tst_creation.properties ファイルの assertorToolIgnore プロパティを使用することを検討してください。ベスト プラクティスは、これらのアサーションを確認し、アプリケーションの回帰を明らかにする予期せぬ変更を検出していることを確認することです。

tst_creation.properties ファイルの操作の詳細については、「テスト作成プロパティ」を参照してください。