プロジェクトフォルダを開く
FlowLatchを起動し、テストを含むフォルダを作業フォルダとして選択します。Ask firstを有効にすると、変更を伴うアクションはすべてあなたの承認を待ちます。モデルがまだ接続されていない場合は接続し、Testボタンでエンドポイントを確認してください。
ワークフロー
自動化Webテスト：開く、実行する、確認する、修正する
03
ステージング環境のチェックアウトフローを確認する
ショップのステージング環境、テスト用アカウント、テストフォルダが準備できているとします。本日の変更後でも、サインイン、カート追加、チェックアウトが正常に動作するかを確認したい場合、これが最小限の自動化Webテストです。1つのフロー、1つのテストコマンド、確認可能な1つの結果。FlowLatchはフォルダを開き、Shellを介してコマンドを実行し、カードに実際の終了コードを表示します。フローが失敗した場合、行を特定し、差分として修正を提案します。承認するかどうかはあなたが決めます。以下の手順は、フォルダから結果に至るまで4つのアクションで完了します。構築中またはテスト権限のあるアプリでのみ作業し、テストアカウントとダミーデータを使用してください。支払いステップでは、実際のカードではなく、ご自身の決済環境のテストモードを使用してください。メールの確認は、テスト用に設定された受信トレイに対して行います。
テストファイルの一覧を表示する
テストの構造について確認しましょう。list_dirやglobでファイルを確認し、read_fileでチェックアウトフローを開けば、実行や変更の前にあなたとエージェントが同じ内容から始められます。各アクションはチャートにカード形式で結果とともに表示されます。
テストコマンドを実行する
エージェントにプロジェクトで使用するテストコマンドを伝えてください。ShellはWindowsまたはWSL上でコマンドを実行し、カードには要約ではなく完全な出力と実際の終了コードが表示されます。すべての行を確認したい場合はカードを展開し、grepで出力から失敗したステップにジャンプしてください。
結果と修正を確認する
失敗が発生した場合、出力の内容についてエージェントに問いかけてください。エージェントは差分として編集案を提示しますが、承認するまでファイルは書き換えられません。誤りがあると思われる場合は拒否し、コマンドを再実行して新しい終了コードを確認してください。フローが成功するか、アプリ側で何を変更すべきかが明確になるまで繰り返します。
コピーして使えるテストフローのアウトライン
ステージング環境でチェックアウトフローを実行し、どこが失敗したか教えてください。
- list_dir
tests/一覧表示完了 - read_file
tests/checkout-flow-test.txt読み込み完了 - Shell
your test command終了コード 0 - grep
FAIL reports/一致0件
次のステップに進む前に承認を待機中拒否承認
checkout-flow-test.txt
# checkout flow for the staging copy of my shop
# uses only the test account and fake data
step 1: open the sign-in page
step 2: sign in with the test account
step 3: search for the sample product
step 4: add the sample product to the cart
step 5: open the cart and start checkout
step 6: pay in the test mode of my payment set-up
expect 1: the order confirmation page is shown
expect 2: the order list shows the new test order
expect 3: the test inbox received the confirmation
# when a step fails, save a screenshot and the page textこのアウトラインはプレーンテキスト形式で、リポジトリ内のテストファイルの隣に配置されます。ご自身のテストフレームワークが各ステップをコードに変換し、FlowLatchはそのファイル仕様に基づいてコードを生成、実行し、結果を3つのexpect行と比較します。製品名やページを、ご自身のステージング環境に合わせて変更してください。
自動化ブラウザテストのための手順解説
既存のテストを見つけ、確認する
まずテストがどこにあるかを確認しましょう。list_dirでフォルダを確認し、globでチェックアウトテストなどのパターンに一致するすべてのファイルを一覧表示します。read_fileで関心のあるファイルを開き、現在のフローがどのように構築されているかを確認できます。grepで、テストで使用されているセレクタや待機処理を検索します。これらはすべて読み取りのみを行うため、Plan onlyモードでの最初のステップとして最適です。このモードでは計画を作成するだけで、何も実行されません。計画は再起動後も維持されるため、翌日再開することも可能です。実際の実行の準備ができたらAsk firstに切り替え、計画をもう一度確認してください。すでにテストされているフローを記録しておけば、テストが不足している箇所がわかります。
テストスイートを実行し、終了コードを確認する
ランタイムのアップグレード後、e2eスイートの失敗はアプリ自体よりも環境要因によるものが多いため、テストファイルに触れる前に最初のエラーを確認してください。Shellでテストコマンドを実行すると、カードには完全な出力と実際の終了コードが保持されます。これが唯一の客観的な合格・不合格の基準です。grepを使えば、長いログから失敗したステップを抽出できます。チャットでエラーの平易な説明を求め、出力と比較してから、テストファイルの編集が必要かどうかを判断してください。エラーが不足しているパッケージや変更された設定を指している場合は、まず環境側を修正し、同じコマンドを再実行してください。多くの場合、編集なしでスイートが成功し、カードの終了コードがそれを証明します。
セレクタを修正し、再実行する
UIテスト自動化におけるセレクタの保守は最も一般的な作業です。レイアウトの変更は、それに紐付いたセレクタを無効にします。grepで古いセレクタをファイル内から探し出し、read_fileで周辺のステップを確認し、edit_fileで安定したラベルやテストIDへの修正案を提示します。Ask firstモードでは、エージェントは一時停止して差分を表示します。正しそうに見える行を承認し、Shellでコマンドを再実行してください。編集後に緑色の終了コードが表示されれば、これが望む結果です。差分は次のレビュアーのためにリポジトリの履歴に残ります。コマンドがまだ失敗する場合、別の修正を依頼する前に新しい出力を確認してください。誤った推測の上に2回目の編集を行うと、根本原因が見えにくくなるためです。各差分は1回のセッションで読める程度に小さく保ってください。
失敗したテストを繰り返し、不安定さを確認する
UI e2eテストが失敗した場合、実際の原因はアプリではなく、固定された待機時間、共有テストデータ、またはテストの実行順序であることがよくあります。FlowLatchに同じコマンドで失敗したテストを複数回実行させ、各回の終了コードを報告させましょう。結果が混在する場合、そのテストは不安定（フラッキー）です。フレームワークがスクリーンショットを保存している場合、ocrでその中のテキストを読み取り、失敗した実行時のページテキストが2つ目の手がかりとなります。差分で待機時間やデータを修正し、レビュー後、テストを再実行してください。各テストに固有のデータを与えてリセットし、固定された待機時間ではなく可視の条件を待ち、テスト間の依存関係を避けてください。修正後に再実行をもう一度行いましょう。1回の成功だけでは、確実性は証明されません。
