テストの失敗にはさまざまな種類があります。ボタンが最初のクリックに反応しなかった、新しく作成したレコードがページネーションされたリストの2ページ目に表示されたなど、偶発的な理由でテストが失敗することがあります。このような失敗は、実際にテストしている内容とは無関係であり、より重要な作業への集中を妨げる原因となります。
Agentic 実行時リカバリは、テストのクリティカルパス外にある課題からインテリジェントに回復することで、ブラウザテストにおける回避可能な失敗を減らします。実行中にステップが失敗すると、mabl はエージェントを起動して失敗を分析し、テストが失敗としてマークされる前に修正アクションを試みます。
早期アクセス
実行時リカバリは現在、早期アクセスでご利用いただけます。実行時リカバリを有効にするには、ワークスペースの所有者がLabsページで以下の設定を有効にしてください:ワークスペース > Labs
- mabl エージェントでプレビュー AI モデルを使用する - プレビューモデルのデータ処理場所が米国内であることは保証されません。
- 実行時リカバリ - この設定は、mablエージェントのプレビューモデルを有効にしたワークスペースでのみ使用できます。
このエクスペリエンスに関するフィードバックがございましたら、mablのカスタマーサクセスマネージャー(CSM)にお知らせください。
自動修復と実行時リカバリ
mabl は、変更が発生した場合でもテストを実行し続けるために、複数の戦略を使用しています。
- 自動修復は要素レベルで動作します。ターゲットボタンのCSSクラスなど、要素の属性が変更された場合、自動修復は属性の履歴とAIを使用して次に最適な一致を見つけます。
- 実行時リカバリは自動修復の後に動作します。自動修復がステップの失敗を解決できない場合、エージェントは予期しないページの状態、ブロックされたUI、コンテンツの欠落など、要素の属性を超えた課題を調査します。
実行時リカバリの仕組み
ステップが失敗し、自動修復で課題が解決されない場合、エージェントが起動して次のアクションを実行します。
1. 失敗を分析する
エージェントは、失敗をリカバリする価値があるかどうかを判断する際に、テストの目的をコンテキストとして使用し、同じテストの過去の成功および失敗したクラウド実行のコンテキストと合わせて現在の失敗を検証します。特に重要な点として、エージェントがその失敗をテストが検証している内容の核心であると認識した場合、実行時リカバリは起動せず、ステップは失敗となります。
2. 修正アクションを試みる
課題がテストの意図とは無関係な原因によって発生している場合、エージェントは次のような対処を行います。
- 予期しないモーダルまたはポップアップを閉じる
- 前のセッションから残った古い検索フィルターのクリア
- ページネーションリストで正しいページに移動する
- 応答しないボタンの再試行
- ページの更新
3. 次のステップ
リカバリーが成功した場合、エージェントは実行エンジンに制御を返し、テストが続行されます。リカバリーが成功しなかった場合、テストは失敗し、何が失敗したか、エージェントが試みたこと、および結果についての詳細な説明が表示されます。
実行時リカバリが有効になると、テストの出力には何が起きたかの説明が含まれます。
- どのステップが失敗したか、その理由
- エージェントが試みた修正アクション
- リカバリーが成功したかどうか
リカバリーモード
デフォルトでは、実行時リカバリはステップを失敗としてマークし、実行を継続して、最終的にテストを失敗にします。
サポートされているステップタイプとサポートされていないステップタイプ
実行時リカバリは、mablクラウドで実行されるブラウザテストに対応しています。ほとんどの種類のテストステップに対応していますが、以下のステップタイプでは実行時リカバリは有効になりません。
- APIリクエスト
- データベースクエリ
- Echoステップ
- メールステップ
- ダウンロードのアサーション