エンドツーエンドテストと統合テスト: それぞれが捉えるもの (例付き)
エンドツーエンドテストと統合テスト: それぞれが見るもの、画面のテストだけが捉えるチェックアウトのバグ、テストピラミッド、そしてエンドツーエンドテストがいくつ必要か。
読了 10 分執筆: Ait Nohaila (事業開発担当)
エンドツーエンドテストと統合テスト: 一行で言う違い
Definition
統合テストは、アプリケーションの 2 つ以上の部品がコードや API を通じてその継ぎ目で一緒に動くことを確かめ、エンドツーエンドテストは、ユーザーがたどるとおりに、画面を通してアプリケーション全体を確かめます。統合テストはコードに問いかけます: カートサービスはチェックアウトが期待する合計を返したか? エンドツーエンドテストは画面に問いかけます: ユーザーは期待する場所に正しい合計を見ているか? どちらも必要であり、どちらも相手の問いには答えられません。
この 2 つが混同されるのは、どちらも一度に複数の部品をテストするからです。違いは、テストが立つ場所にあります。統合テストは 2 つの部品の継ぎ目に立ち、そこを渡るものを見張ります。エンドツーエンドテストはユーザーが立つ場所、つまり画面の前に立ち、その背後にあるすべての結果を見張ります。
統合テストは継ぎ目を確かめます。エンドツーエンドテストは画面に描かれたものを確かめます。
E2E テストと統合テストを並べて比べる
何を自動化するか決めるときにチームが問う質問について、2 つを比べると次のようになります。
| 質問 | 統合テスト | エンドツーエンドテスト |
|---|---|---|
| 範囲 | アプリケーションの 2 つ以上の部品を一緒に: サービスとそのデータベース、API とそれを呼ぶモジュール。 | ユーザーが出会うままのアプリケーション全体と、それが依存するすべての部品: 画面、その背後のサービス、多くの場合は決済事業者などの他のシステム。 |
| 入り口 | コードまたは API: テストは関数を呼ぶか要求を送り、答えを読みます。 | 画面: テストは人と同じように、クリックし、入力し、描かれたものを読みます。 |
| 見つけるもの | 次の部品の期待どおりに答えなくなった部品: 名前の変わったフィールド、間違ったステータス、欠けたレコード。 | ユーザーに正しい結果を与えなくなった流れ: 画面上の間違った合計、何も起きないボタン、開かないページ。 |
| 速度 | テスト 1 件あたりミリ秒から数秒。コミットのたびに数百件を実行できます。 | 流れ 1 件あたり数秒から数分。数十件のスイートをビルドのたび、または毎晩実行します。 |
| コスト | 継ぎ目を知る開発者にとって書くのが安く、実行も安い。 | コードで書くと高くつきます: 再設計のたびにセレクターが壊れます。画面から記録してコードなしで保つなら安くすみます。 |
| 誰が書くか | 開発者が、継ぎ目を作りながら。 | ユーザーの期待を知るテスター、QA エンジニア、プロダクトオーナー、そして開発者も。 |
| いつ実行するか | コミットのたびに、ビルドの中で、何かがマージされる前に。 | 重要な少数の流れはビルドまたはプルリクエストのたびに、スイート全体は毎晩、リリース前にはすべてのブラウザーとデバイスで。 |
統合テストには見えないバグ
チェックアウトを例にとります。カートサービスが商品を足し、価格サービスが送料を適用し、チェアウトページが結果を 3 行に描きます: 小計、送料、合計です。ある日、開発者がチェックアウトのテンプレートを整理します。1 行が動きます。その背後のコードには手を触れていません。
統合テストは API にカートの合計を尋ね、期待する数値と比較します。受け取るのは 48.90、完全に正しく、合格します。どのサービスも仕事を果たし、その間の継ぎ目は健全です。
エンドツーエンドテストは顧客と同じことをします: 商品を 2 点追加し、チェックアウトを開き、支払う前に合計を読みます。画面では合計の行が空で、48.90 は今や送料の横にあります。顧客は、送料が 48.90 で支払額はないと読み取ります。これは誰も異論を挟まないバグですが、統合テストはページを決して見ないため、どの統合テストにも見えません。
- 同じ構図の中に、ユーザーに届くバグの多くが隠れています。ドルで計算され、ユーロ記号付きで描かれた合計。新しいバナーに押されて画面の下に隠れた「支払う」ボタン。ウィンドウの背後に現れる確認メッセージ。翻訳後に欄に収まらなくなったラベル。どの場合も、データは正しく、画面が間違っています。
これは自動テストが見逃すビジュアルバグが反対側から述べているのと同じ隙間です: 要素が存在するかを問うアサーションでは、人がそれを見られるか、読めるか、クリックできるかはわかりません。
テストピラミッド: 各層が持ち場を得る理由
テストピラミッドは、スイートの大きさをどう配分すべきかを示すおなじみの図です。その形はコストの話であって、重要度の話ではありません: ユニットテストは 1 ミリ秒で動き、すべてのケースについて書けますが、エンドツーエンドテストは実際のアプリケーションを起動して 1 つの流れをたどるので、数が少なくなります。
テストピラミッド: テストの数と、各層が見るもの
ユニットテスト
ユニットテストは、間違った計算を、それを生んだ関数の中で、書かれた瞬間に捉えることで持ち場を得ます。統合テストは、壊れた継ぎ目を捉えることで持ち場を得ます: あるサービスで名前が変わり、別のサービスがまだ元の名前を期待しているフィールドです。エンドツーエンドテストは、画面にしか現れないものを捉えることで持ち場を得ます: 間違った欄の正しい数値、クリックできないボタン、決して開かないページです。
システムテストはピラミッドの頂上のすぐ隣にあり、多くのチームは 2 つの名前を同じものに使っています。役に立つ区別はこうです: システムテストは組み上がったアプリケーションを要件に照らして確かめ、エンドツーエンドテストは 1 人のユーザーの流れを、その流れが触れるすべてを通してたどります。エンドツーエンドテストとは何かで全体像を説明しています。
統合テストとエンドツーエンドテスト: どちらをいつ使うか
選択は、どちらか一方であることはめったにありません。各層はそれぞれ異なる種類の質問に最も安く答えられ、自分がどの質問をしているかを知るチームは、テストを正しい場所に置きます。
- 質問が継ぎ目についてなら、統合テストを使います。API はまだモジュールが期待する形で答えるか? 注文はすべてのフィールドを伴ってデータベースに届くか? 決済事業者の拒否は、コードが処理するエラーとして返ってくるか? これらは多くの小さなケースであり、継ぎ目を作った開発者が、コミットのたびに、速く確かめるのが最適です。
- 質問がユーザーの結果についてなら、エンドツーエンドテストを使います。顧客はサインインし、商品を見つけ、支払い、正しい注文番号の確認画面を見られるか? 経理チームが毎週月曜にエクスポートするレポートは、まだ正しい列で開くか? これらは少数の流れ全体であり、ユーザーが確かめるであろう場所で、ビルドのたびに確かめます。
- お金、データ、サインインが関わるところでは両方を使います。上のチェックアウトには、間違った合計をそれを生んだ継ぎ目で捉えるための統合テストと、正しい合計が間違った場所に描かれたことも捉えるためのエンドツーエンドテストの両方が必要です。あの日、どちらも相手の代わりにはなれませんでした。
どちらの層もリグレッションテストです: 変更のたびに再び実行し、動いていたものが壊れていないことを証明します。リグレッションテストとは何かで、それぞれをいつ実行するか、そしてスイートが捉える以上にコストがかかると放棄される理由を説明しています。
エンドツーエンドテストはいくつ必要か?
思っているより少なく、よく選んで。ピラミッドの頂上は、すべての画面を並べる場所ではありません。壊れたら最も痛い流れのための場所であり、それぞれを最初のクリックからユーザーが求めた結果までたどり、それぞれがその結果を検証します。
- 1ほとんどのアプリケーションは短いリストでカバーできます。サインアップとサインイン、パスワードが間違っているときのエラーも含めて。アプリケーションの存在理由である主な作業: 注文する、枠を予約する、顧客を作成する、申請を送る。支払い、確認画面とその注文番号まで。ユーザーが毎日そこから始める検索や一覧。顧客が頼りにするエクスポートやレポート。かつて壊れてユーザーに届いたすべての流れ。
このような 5 件から 15 件の流れをビルドのたびに実行すれば、統合スイートが通してしまうもののほとんどを捉えられます。それぞれは画面に表示されるもののアサーションで終わります: 合計、確認画面、エクスポートされたファイルです。流れをクリックして通るだけで何も検証しないテストは、ほとんど何も証明しません。
各ステップで何を検証するかは、意識して選ぶ価値のある選択です: 要素の画像か、その言葉か、画面に表示されたものか。テストが検証するものを選ぶで順に説明しています。
エンドツーエンドの層をコードなしで自動化する
エンドツーエンドの層は、保つのに最もコストがかかってきたため、ほとんどのチームが薄いままにしている層です: コードで書いたテストはセレクターで要素を見つけ、再設計のたびに壊れます。GUI Test Studio はその層からコードを取り除きます。Web アプリ、Windows デスクトップアプリ、Android スマートフォン、ゲームを、ユーザーと同じように画面を通してテストします。
記録するか、記述するか
「記録」をクリックし、実際のアプリケーションで流れをたどってください: 商品を追加し、チェックアウトを開き、合計を読みます。クリック、入力、表示されたもののアサーションが、書くコードなしでテストになります。AI アシスタントへのプロンプトで流れを記述すれば、テストが代わりに作成されます。最初のテストを手順どおりには 10 分ほどで終わります。
- テストは画面に表示されるものを確かめ、その背後のコードは確かめません。ビジュアルアサーションは要素の画像を比較し、テキストアサーションはその言葉を読み、表示されたもののアサーションはそのステップが開いたダイアログやメッセージを捉えます。GTS Engine + AI は各要素を、まずアプリケーションのアクセシビリティ情報を通じて見つけ、アプリケーションが何も伝えないときは見た目で見つけます。
ビルドのたびに実行する
gtr-cli は Windows のビルドマシンでエンドツーエンドのスイートを実行し、パイプラインが期待する形で答えます: 失敗した流れはビルドを失敗させ、JUnit ファイルがテストタブを埋め、失敗したもののすべての画像が統合テストの結果の横に残ります。
gtr-cli run tests\journeys --countdown 0 --junit results\junit.xml --artifacts results\artifactsTeamCity、Jenkins、GitHub Actions、GitLab、Azure DevOps で動きます: パイプラインでテストを実行するをご覧ください。
信頼度レポートが何が変わったかを伝える
すべての実行は信頼度レポートで終わります。各アサーションについて、要素が見つかったか、記録したときと同じ見た目のままかを、期待画像と見つかった画像を並べ、差分を枠で示して伝えます。上のチェックアウトなら、合計の行が空で 48.90 が 1 行上にあることを示します: テスターがバグレポートに書いたであろう内容そのものです。
- ノイズは無視され、リグレッションは捉えられます。誰も気づかないようなわずかな描画の違いは数えられず、変わった単語、欠けたバッジ、間違った行の数値はアサーションを不合格にします。画像が異なるときは、自分のキーを使ってクラウドで、または自分のコンピューターでローカル AI モデル (当社が提供するモデルか自前のモデル) を使って、AI スマート分析がもう一度見て、何が変わったかをわかりやすい言葉で伝えられます。
変更がプッシュされる
チェックアウトのテンプレートが整理される
ビルドが実行される
統合テスト、次に gtr-cli
信頼度レポート
合計が間違った行にある
マージ前に修正
ユーザーは目にしなかった
要点
- 1統合テストは部品間の継ぎ目を確かめ、エンドツーエンドテストはユーザーのために画面に描かれたものを確かめます。
- 2同じバグが同時に緑にも赤にもなり得ます: API は正しい合計を返し、画面はそれを間違った欄に表示します。
- 3ピラミッドの形はコストの話であって、重要度の話ではありません: 下には多くの速いテスト、上には少数の流れ全体、それぞれが他には捉えられないものを捉えます。
- 4お金、データ、サインインが関わるところでは両方を使い、誰がバグレポートを書くかで層を選んでください: ユーザーか、開発者かです。
- 5それぞれが結果を検証する 5 件から 15 件の流れが、統合スイートが通してしまうもののほとんどをカバーし、コードなしで記録できます。
よくある質問
エンドツーエンドテストと統合テストの違いは何ですか?
統合テストは、アプリケーションの 2 つ以上の部品が、通常はコードや API を通じて、その継ぎ目で一緒に動くことを確かめます。エンドツーエンドテストは、ユーザーがたどるとおりに、画面を通してアプリケーション全体を確かめます。統合テストは、画面が間違ったものを表示していても合格することがあります。
エンドツーエンドテストはシステムテストと同じですか?
重なる部分があり、多くのチームは 2 つの言葉を同じものに使っています。システムテストは、完成し組み上がったアプリケーションを要件に照らして確かめます。エンドツーエンドテストは、ユーザーの流れを最初のクリックから結果まで、他のシステムも含めてその流れが触れるすべての部品を通してたどります。
統合テストはエンドツーエンドテストの代わりになりますか?
いいえ。統合テストが証明するのは部品同士が一致していることであって、ユーザーが画面で正しい結果を得られることではありません。合計はすべてのサービスで正しく計算されていても、間違った欄に描かれたりバナーの背後に隠れたりすることがあり、それを見るのは画面を見るテストだけです。
統合テストとエンドツーエンドテスト、どちらを先に書くべきですか?
開発者は継ぎ目を作りながら統合テストを書くので、通常はそちらが先です。最初のエンドツーエンドテストは、サインインやチェックアウトなど、壊れたら最も痛い流れのためのものであり、それらの流れが動くようになり次第、記録できます。
プロジェクトにはエンドツーエンドテストがいくつあるべきですか?
思っているより少なく、よく選びます。5 件から 15 件の流れで、ほとんどのアプリケーションが壊すわけにいかないものをカバーできます: サインアップ、サインイン、主な作業、支払い、顧客が頼りにするエクスポートです。それぞれがユーザーの求めた結果まで流れをたどり、その結果を検証します。
エンドツーエンドテストはなぜ統合テストより遅いのですか?
エンドツーエンドテストは実際のアプリケーションを起動し、その画面を操作し、それぞれが応答するのを待つので、統合テストがミリ秒で終わるところを、1 つの流れに数秒から数分かかります。だからこそエンドツーエンドテストは少数の重要な流れをカバーし、統合テストは多くのケースをカバーするのです。
テストピラミッドとは何ですか?
テストピラミッドはテストスイートの大きさを配分する考え方です: 土台には多くの速いユニットテスト、中段にはより少ない統合テスト、頂上には少数のエンドツーエンドテスト。各層は下の層には捉えられないものを捉え、頂上の層はユーザーが見るものを見る唯一の層です。
エンドツーエンドテストは誰が書きますか?
ツールがコードを必要としなければ、ユーザーの期待を知る人なら誰でも書けます。GUI Test Studio なら、テスターやプロダクトオーナーがアプリケーションを使いながら流れを記録するか、プロンプトで記述し、テストは gtr-cli でビルドのたびに実行されます。
TeamCity、Jenkins、GitHub、GitLab、Azure DevOps はそれぞれの所有者の商標です。
テスト対象のアプリでご覧になりますか? チームとの 30 分の無料相談を予約してください。