いくつかのテストが次のパスをたどっている Web サイトのテスト計画に取り組んでいます。
それは機能テストを行う正しい方法ですか？そのリクエストが Ajax リクエストだった場合、答えは何になりますか? 統合テストの場合、答えは異なりますか?
これはどういうわけか間違っていると信じさせる何らかの理由があります....それでもあなたの意見が必要です！
この種のテストは、データベースとエンドユーザーへの表示の間に開発者ロジックがあまりない場合に、テスターの労力を比較的少なくして大量のデータセットをテストするのに適しています。私たちのチームはこれを何度も行ってきました。実際のシナリオが期待どおりに処理されることを確認するために、テストを通じて大量の実際の本番データを実行する場合に特に役立ちます。DBとWebページで異なる方法で処理される可能性が特に高いまれなシナリオ（null値、特殊文字、その他の奇妙なもの）については、少なくとも少し固定入力テストを行うようにしてください。
個人的には、これを「統合テスト」と呼びます。これは、「機能テスト」ではなく、DBとWebサイトの統合をテストしているためです。「機能テスト」の場合、期待する形式で事前に作成されたデータセットを提供するデータソース（データベースなど）のモックを作成したいと思います。
そうは言っても、DBデータの有効性に高い信頼があり、DBクエリとWebページ表示の間のロジックが非常に小さく、リスクが低い場合は、モックを気にせずに統合を許可します。テストは機能もカバーします。この場合、機能と統合を別々にテストすることが大きな品質の勝利になるかどうかはわかりません。利用可能なテスト時間でより良いことができる可能性があります。このデータの周りに多くのロジックがある場合は、機能とは別に統合をテストする必要があります。追加の統合テストには、「データベースにアクセスできない場合はどうなりますか？」などが含まれる可能性があります。および「データベースが遅い場合はどうなりますか？」
この手法はAjaxで機能しますが、テストツールがAjaxで機能することを確認してください。具体的には、データベースクエリの結果をキャプチャする方法と、Webページに表示される結果を収集する方法について考えてください。
これはテスト計画のテストの1つのタイプにすぎないとおっしゃっていたので、クエリのデータの有効性は他の場所でテストされていると思います。また、データベースとこのレポートとの統合についても説明していますが、他の機能やコンポーネントではなく、テストの他の側面（パフォーマンス、セキュリティなど）についても説明していません。これが、質問の範囲でした。
はい、これは生産的なテストになる可能性があります。固定データ セットがあるか、ないかのどちらかです。
固定データ セットがある場合は、固定出力と比較するだけなので、これをテストするのははるかに簡単です。
固定データ セットがない場合は、ビジネス ロジックを複製して、開発者が既に行った作業を効果的に複製する必要があります。次に、維持するロジックのセットが 2 つあります。
2 番目のアプローチは、同じことを 2 つの方法で行うことができるため、最良のアプローチです。つまり、仕様とコードの実質的なピア レビューです。また、時間とリソースの面でも非常にコストがかかるため、ほとんどの人は固定データ セットを選択します。
あなたの質問に答えるために、クエリのビジネス ロジックが単純であれば、非常に簡単にテストを取得できます。ただし、あまりテストを行っていないため、テストがもたらす価値は大きくありません。
ビジネス ロジックが複雑な場合、テストからより多くの価値が得られますが、長期的に維持するのは難しくなります。
私にとって、あなたのテストがもたらすのは、システムがデータベースから正しく読み取り、データを正しく表示することを証明する簡単な統合テストです。これは優れたテストであり、自動化されている場合はさらに優れています。
ここでは反対意見になる可能性が高いですが、これが生産的なテストであるとは考えていません。あなたがしていることは、ページを生成するコードを単純に複製することです。また、重複したコードを (部門間であっても) 導入するときはいつでも、長期的に発生する欠陥に注目することになります。
DB に既知のデータを (アプリを介して、または直接) ロードし、出力が期待どおりであることを確認する方がはるかに優れています。これにより、DB レイヤーまたは DB 自体が予期しない方法でデータを変更していないことも保証されます。
あれは：
これは、機能テストには問題ないようです。私の考えでは、統合テストは、機能テストよりも一般的には、連携して動作するはずのさまざまなテクノロジまたはコンポーネントのテストに関係しています。もちろん、この種のテストは、アプリケーションがどのように組み立てられているか、および開発のライフサイクルのどこでテストが行われているかによって、統合テストと見なすこともできます。たとえば、このサイトが機能するためには、独自に開発されたいくつかのコンポーネントを組み合わせる必要がある場合があります。これは、統合が機能することを検証するためのテストの 1 つかもしれません。
これがAjaxであるかどうかが、答えを変えることにどのように関係しているかはわかりません。