一般に、テスト対象のソフトウェアは定期的に変更されます。一部の変更は重要であり、以前のテストを作成し直す必要があります。しかし、変更の多くは、ボタンのラベル変更やレイアウト調整などの軽微なものです。気づかれることもないようなこうした変更でも、自動テストがたやすく中断される可能性があります。
自動修復は、mablがそのような変更に適応するのを助けるので、ブラウザテストはこれらの避けられない変更を通して動作し続けます。この記事では、その仕組みを説明します。
要素の履歴を構築する
テストステップを記録する際、ページ上の要素と対話する場合、mablは属性を収集し、それを使用して要素を見つけ、時間の経過とともに変化を追跡します。ターゲット要素があまりユニークでない場合、要素の履歴には、ターゲット要素を含む祖先要素に関する情報が含まれることがあります。
この情報はステップの要素の履歴の基礎を形成します。mablは自動修復中にステップの要素の履歴を使用します。
カスタム検索ステップは自動修復しません
mablは要素の検索ステップの要素の履歴を追跡しません。要素の検索ステップは、常に提供されたCSSセレクタまたはXPathクエリを使用して要素を見つけます。要素の検索ステップには自動修復は利用できません。
エレメント候補の検索
テスト実行中、mablはインテリジェントな検索ストラテジーを使用して、追跡された属性とステップの要素の履歴に一致する要素を探します。
- エレメントに対して祖先が記録されている場合、mablはこのプロセスをまず祖先に対して実行します。次に祖先内のターゲットエレメントの候補を識別し、最適なものを選択します。
- ステップでConfigure Findが使用されている場合、mablは指定された条件に一致するエレメントのみを検討します。
自動修復は環境単位で行われる
テストステップの要素の履歴は、テストが実行される各環境で追跡され、更新されます。
たとえば、プランが2つあり、一方のプランではQA環境に対して、他方のプランでは本番環境に対してテストを実行する場合、これら2つの環境で別々にエレメント属性が追跡されます。
QA環境で何らかの変更が行われ、その結果自動修復が行われても、本番環境に対して実行されている同じテストの動作には影響しません。
高確度の一致の検索
mablは、過去の実行のデータに基づき、エレメントがページ上に実行可能な状態でいつ表示されるかを判断します。次に、過去の実行から学習したエレメントモデルと高確度で一致するものを探します。
- 強い一致がある場合、mablはターゲット要素に対してステップアクションを実行し、次のステップに進みます。
- 要素が表示され、操作可能になると予想された後に強い一致が見つからない場合、mablは自動修復を試みます。
検索の設定
Configure Findを使用するステップでは、高確度の一致を見つけるプロセスは少し異なります。mablはまず、選択されたタイムアウトが経過するまで、特定の条件で高確度の一致を探します。
- 強い一致がある場合、mablはターゲット要素に対してステップアクションを実行し、必要に応じて要素に小さな更新を行います。
- 選択されたタイムアウトまでに高確度の一致が見つからない場合、その次のフェーズは、ステップに選択されたオプションによって異なります。
- 「自動修復」: mablは自動修復を試みます。
- 「自動修復を無効にする」: mablはステップに失敗し、正しい要素を見つけることができなかったことを示します。
クラウド実行実行での待機時間の判断
ステップが新しく、プラン実行で数回成功していない場合、mablはページのインタラクション速度を使用して、アプリケーション内の要素に対する正確または強い一致を待つ時間を決定します。
プラン実行が何度か成功した後は、mablはインテリジェント待機を使用して、完全一致または高確度の一致を待機する時間を判断します。
自動修復
エレメントの変更度合いが大きく、見つけたエレメントが正しいかどうかを確信できない場合、mablは次のように自動修復を試みます。
標準自動修復
mablは要素モデルに最も適した一致を探します。このプロセスには、ページ上の利用可能な要素に対してモデルとの部分一致を比較することが含まれます。
生成AIによる自動修復
クラウド実行では、標準の自動修復戦略が適切な一致を見つけられない場合、mablは生成AIによる自動修復を試みます。生成AIによる自動修復は、生成AIを使用して新しいテキストと意味のある属性値との意味的類似性を特定し、適切な一致を見つけます。
注
mablは、テストがプランで少なくとも5回成功するまで、生成AIによる自動修復を試みません。
mablが生成AIによる自動修復を使用する場合、ステップ出力ログには検索サマリータブが含まれます。このタブは、適切な一致を見つけるmablの信頼度を要約します。最適な一致が低い信頼度の場合、テストステップは不適切な一致の要素に自動修復するのではなく、失敗します。
生成AIによる自動修復を使用したステップの概要を見つける
自動修復の結果
mablが自動修復を試みた後、次のいずれかの結果が発生します。
- 更新された要素モデル: テストが最終的に成功し、プラン実行の一部である場合、mablは要素モデルを更新し、ステップの自動修復インサイトを記録します。
- 要素モデルの更新なし: テストが最終的に失敗した場合やアドホック実行の一部である場合、mablは出力ログに自動修復を記録しますが、要素モデルを更新したり、ステップのインサイトを記録したりしません。
次の表は、異なる種類のテスト実行における自動修復の動作を示しています。
テスト実行の種類 | 標準自動修復 | 必要に応じて生成AIによる自動修復 | 更新された要素モデル |
プラン実行でテストが成功 | あり | あり | あり |
プラン実行中の失敗したテスト | あり | あり | なし |
アドホッククラウド実行(成功または失敗) | あり | あり | なし |
アドホックローカル実行(成功または失敗) | あり | いいえ | なし |
ローカル実行と自動修復
ローカル実行では、mablは最新のクラウド実行からのモデルを使用して正しい要素を見つけます。ローカル実行中に強い一致が見つからない場合、mablは標準の自動修復ストラテジーを使用します。生成AIによる自動修復はクラウド専用の機能です。ローカル実行で試みられた自動修復は、自動修復インサイトとして保存されず、テストが成功しても要素モデルに影響を与えません。
アドホック実行と自動修復
アドホック実行は、プランやデプロイメントイベントで実行されるテストと同じ実行環境を使用し、全体の統計、メトリクス、インサイトに影響を与えずにテストの編集を検証する方法を提供することを目的としています。このため、アドホック実行はプランやデプロイメントイベントで実行されるテストと同じ検索戦略を使用しますが、アドホック実行での成功した適応は要素モデルを更新しません。