Upgrade to Pro — share decks privately, control downloads, hide ads and more …

mablの要素選択を完全理解〜壊れないテストを作るための技術選択

 mablの要素選択を完全理解〜壊れないテストを作るための技術選択

2026/05/27開催のウェビナー「mablの要素選択を完全理解〜壊れないテストを作るための技術選択」のスライドです。

More Decks by Masahiko Funaki(舟木 将彦)

Other Decks in Programming

Transcript

  1. テストの自己修復 1. mablのネイティブなポイント&クリック • テスト実行時に要素が変わっても、mabl が自動的に修復 ✅ 失敗したステップは次回実行のために自動更新される。メンテナンスコストを大幅に削減。 シナリオ 従来ツール

    mabl IDが動的に変わった ❌ 失敗 ✅ 他の属性で特定 クラス名が変更された ❌ 失敗 ✅ テキストや位置で特定 DOM構造が微修正 ❌ 失敗 ✅ 相対的な関係で特定
  2. 🔍 デモ:自動修復の仕組みを体験する 1. mablのネイティブなポイント&クリック • デモサイトで、Auto Healingの3つのフェーズを体験します フェーズ 内容 ①

    識別プロパティ mabl がテスト記録時に学習する 11種類の属性を確認 ② スコアリング 要素の変化に対してどの候補が選ばれるかを可視化 ③ 自動修復判定 スコアが閾値を超えた場合に自動修復が発動するかを確認
  3. ビジュアル検索:視覚的要素の特定 1. mablのネイティブなポイント&クリック • クリックステップで画像・地図・ Canvasなどのテキスト情報のない要素に対応 ◦ AIが要素の視覚的な説明を自動生成して保存 ◦ 実行時にDOM属性だけでは特定できない場合、

    視覚的説明にフォールバック ◦ 地図・画像・Canvasなど、HTML属性が乏しい要素に特に有効 設定方法: ステップの挿入のクリックから「ビジュアル検索」を選択 デフォルトは英語で生成。 ワークスペース > ワークスペース で言語を変更可能
  4. 検索の設定 2. 検索の設定 • 検索の設定 ◦ ネイティブなポイント&クリックで要素の特定が一貫しない場合に利用 ◦ 特定の属性(例:id, class,

    name など)を指定することで、 mabl が要素を正確に識別するための追加の手がかりを与える ◦ CSSやXPathの知識が不要 なため、テストのメンテナンスが容易になる ✅ カスタム検索(CSS/XPath)より先に検索の設定を試すことを強く推奨。 トラブルシュート時もコードの知識なしで対応できる。
  5. 安定した属性の選び方 2. 検索の設定 • 検索の設定に指定すべき属性(安定性が高い順) ⚠ 動的なクラス名(例:MuiButton-root-:r3:)や揮発性IDは使用を避ける 優先度 属性の種類 例

    ★★★ カスタムテストID data-testid, data-qa, data-cy ★★★ アクセシビリティ属性 aria-label, role, aria-labelledby ★★ 安定した属性 name, title, placeholder, innerText ★ 動的な属性 id(動的生成), class(フレームワーク生成)
  6. 検索の設定の高度な設定 2. 検索の設定 • タイムアウト設定 ◦ デフォルト:15秒 / 最大:15分(900秒)まで延長可能 ◦

    静的Waitより効率的(要素が見つかり次第すぐ次のステップへ進む) • 自動修復オプション(ブラウザテスト) ◦ タイムアウト後、一致する要素が見つからない場合: ▪ 自動修復を無効にする(デフォルト) :ステップ失敗 ▪ 自動修復:検索パラメーターを拡張して最も近い候補を選択 • 変数の活用 ◦ 属性値にmablの変数を使用可能:{{@varname}} ◦ 例:新しいタブのURLに {{@productId}} が含まれるまで待機
  7. 祖先要素(コンテナ)でスコープを絞る 2. 検索の設定 • ターゲット要素自体に安定した属性がない場合、親要素でスコープを制限 • ユースケース:繰り返し UIのn番目の要素を特定したい ❌ 特定困難:削除ボタン(SVGアイコン、属性なし)

    ↓ 祖先要素を使ってスコープを制限 ✅ 解決策:data-test-id="delete-button" を持つ 親 div の中にある SVG を対象にする ✅ 繰り返しのテーブル行、モーダル、フォームなど繰り返し構造 のUIで特に有効
  8. アプリケーションレベルのカスタムテストID 2. 検索の設定 • 開発チームが独自のテスト属性規則を使っている場合、 mabl 側で優先属性として登録できる • テスト環境設定 >

    アプリケーション でアプリケーションを編集✎ → 詳細セクション 登録可能な属性例 : data-qaid data-cy formcontrolname data-testid (1アプリにつき最大3属性まで登録可能) 登録済みの属性が要素に存在する場合、mabl はその値を要素特定の最優先識別子 として使用する。 既存テストへの反映は再トレーニングが必要。
  9. XPath / CSSセレクタ 3. XPath / CSSセレクタ • XPath /

    CSSセレクタ ◦ 要素の設定でも十分な結果が得られない場合に利用 • 使うべき典型的なシーン ◦ ある要素に隣接する別の要素を基準にしてターゲットを特定する場合 ◦ 特定のテキストを含まない要素を特定する場合 例: //button[not(starts-with(text(),"Submit"))] ◦ 頻繁に変化する類似要素の集合の中のn番目を特定する場合 ◦ 一致する要素の個数を検証したい場合
  10. XPathの特徴 3. XPath / CSSセレクタ • XPathの特徴 ◦ より柔軟:DOMを上下に移動可能(子要素から親要素へ) ◦

    テキストによって要素を検索可能 ◦ 構文は複雑になる傾向がある ◦ 速度はCSSセレクタより遅い場合がある
  11. CSSセレクタの特徴 3. XPath / CSSセレクタ • CSSセレクタの特徴 ◦ 記述が容易で理解しやすい構文 ◦

    一般的にXPathよりも高速 ◦ Shadow DOMの要素を操作可能 ◦ DOMを上方向には移動できない(順方向のみ) Shadow DOM内の要素を操作できるのは CSSセレクタのみ 。 XPath では Shadow DOM 内部の要素には到達できない。
  12. XPath / CSSセレクタ比較 3. XPath / CSSセレクタ 基本はCSS、テキスト検索や親要素参照が必要なときはXPath 特性 XPath

    CSSセレクタ テキストで要素を検索 ✅ 可能 ❌ 不可 子要素から親要素を参照 ✅ 可能(上下移動) ❌ 不可(順方向のみ) Shadow DOM対応 ❌ 不可 ✅ 対応 構文の習得しやすさ ⚠ 複雑 ✅ 容易 実行速度 ⚠ やや遅い ✅ 速い
  13. XPath / CSSセレクタ:ベストプラクティス 3. XPath / CSSセレクタ • 相対XPathを使用 ◦

    絶対XPathは避ける。 テキスト、ID、または一意の属性を基準にして、相対XPathで指定する。 ◦ 可能であれば、開発者にテスト専用の属性(data-testid など)を 追加してもらうようアドバイスする。 ⚠ Chrome DevToolsの「セレクタをコピー」は使わない! DevToolsが自動生成するセレクタは具体的すぎるため、アプリの軽微な変更でも簡単に壊れる。
  14. カスタム検索の制限事項 3. XPath / CSSセレクタ • CSS / XPath によるカスタム検索ステップは、通常の記録ステップと比べて、

    以下の機能が使えない。 カスタム検索は最終手段。使う場合はメンテナンスコストが高くなることを念頭に。 機能 記録ステップ 検索の設定 カスタム検索 自動修復 ✅ ✅(オプション) ❌ なし インテリジェント待機 ✅ ✅ ❌ なし ダウンロードアサーション ✅ ✅ ❌ なし
  15. まとめ 4. まとめ mabl での要素操作は、次の順序に従うことが「効率的 かつ 堅牢」なテスト構築の鍵 • ポイント&クリック -

    95%はこれでカバー ◦ ビジュアル検索で画像・Canvas にも対応。 • 検索の設定 ◦ CSS/XPathの知識不要。タイムアウト・変数・祖先要素で柔軟に対応。 • XPath / CSS セレクタ ◦ XPathは柔軟性(DOMの上下移動、テキスト検索)が高い。 ◦ CSSセレクタはShadow DOM要素の操作に不可欠。