ReproBreak: A Dataset of Reproducible Web Locator Breaks

技術概要：ReproBreak

問題定義
Cypress や Playwright などの自動 GUI テストフレームワークは、Web アプリケーションと対話するために要素ロケーター（ID、CSS セレクター、XPath など）に大きく依存しています。「ロケーター破損」とは、アプリケーションの構造変更（要素 ID の名前変更や DOM の再構成など）によって、基盤となる機能は正しくてもロケーターが機能しなくなる現象を指します。GUI テストにおけるロケーターの脆弱性はよく文書化された課題ですが、既存の研究やデータセットは主に Selenium に焦点を当てています。Selenium の外部ドライバモデルとは異なり、要素の照会や操作に異なる内部メカニズムを採用する Cypress および Playwright 向けの、大規模なロケーター脆弱性の評価に関する文献には大きなギャップがあります。その結果、これらの現代的なフレームワークに対するロケーター修復技術や堅牢性戦略を実証的に評価・比較するための既存データセットは存在しません。

手法
著者は、オープンソースリポジトリに適用された 3 段階の自動化パイプラインを通じて、再現可能なロケーター破損のデータセット「ReproBreak」を構築しました。

1. データソースと特定: 本研究は E2EGit データセットから始まり、Cypress、Playwright、またはその両方を使用する 374 のリポジトリをフィルタリングしました。これらのうち 359 のリポジトリが分析対象となりました。著者は、特定の拡張子（例：.spec.ts）やフレームワーク固有のキーワード（Cypress の cy.get、Playwright の page.locator など）でフィルタリングすることでテストファイルを特定しました。git log と git diff を使用して、テストファイルを変更したコミットを特定し、ロケーター変更を含むコードハンク（$L_c$）を抽出しました。
2. Docker ベースの環境セットアップ: ロケーター変更が破損を構成するかどうかを検証するために、著者は一貫した環境でテストを実行する必要がありました。変更数の多い上位 10 プロジェクトに焦点を当てました。手作業の必要性と依存関係の問題により、上位 4 プロジェクトに対してのみ、Dockerfile と実行スクリプトを含む再現可能な Docker 環境の作成に成功しました。
3. ロケーター破損の検証: 検証済みプロジェクト内の特定された各ロケーター変更（$L_c$）に対して、著者は 2 段階の検証を行いました。
   • ステップ 3a: 更新されたアプリケーション上で、新しいロケーターを使用してテストを実行します。合格した場合、新しいロケーターは有効です。
   • ステップ 3b/c: 同じコミット内で新しいロケーターを古いロケーターに置き換え、再度実行します。テストが失敗した場合、その変更はロケーター破損（$L_b$）として分類されます。合格した場合、その更新は予防的なものであり、非破損ロケーター変更（$L_{nb}$）として分類されます。

主要な貢献

• ReproBreak データセット: 4 つの主要なオープンソースプロジェクト全体で確認された 449 の再現可能なロケーター破損を含む構造化されたリレーショナル SQLite データベースです。スキーマは、ロケーター変更を特定のコミット、リポジトリ、および再現スクリプトにリンクします。
• 自動化された再現スクリプト: 著者は、研究者が Docker 環境を自動的にセットアップし、古いロケーターを注入して破損を確認できる reproduce.py スクリプトを提供しています。これにより、静的なスナップショットを超えた、動的かつ実行可能な検証が可能になります。
• フレームワーク固有の分析: このデータセットは特に Cypress と Playwright を対象としており、Selenium に比べてこれらのフレームワークの脆弱性を評価するためのリソースが不足しているという課題に対処しています。

結果

• 範囲: 分析は 359 のリポジトリ（Playwright 189、Cypress 154、両方 16）をカバーしました。
• ロケーター変更: パイプラインは、リポジトリ全体で合計 9,572 のロケーター変更を特定しました。
• 検証: 再現可能な Docker 環境を確立できるプロジェクトにフィルタリングした後、著者は 580 のロケーター変更を検証しました。
• 特定された破損: 検証された変更のうち、449 がロケーター破損（$L_b$）として確認され、131 は非破損変更（$L_{nb}$）でした。
• 分布: データセットには、ghiscoding/angular-slickgrid、nasa/openmct、tryghost/koenig、microsoft/playwright の 4 つのプロジェクトからのデータが含まれています。

意義と主張
本論文は、ReproBreak を現代的なフレームワークにおける GUI テスト保守の研究を進展させるための基盤的アーティファクトとして位置づけています。著者は、このデータセットが以下のことを可能にすると主張しています。

• 堅牢性技術の評価: Selenium ベースの堅牢なロケーター生成技術（Robula+、Sidereal など）が Cypress や Playwright に適用可能かどうかを研究者がテストできるようにすること。
• 脆弱性スコアの査定: 元々 Selenium 向けに設計された脆弱性スコアをこれらの新しいフレームワークに適応・検証するための基盤を提供すること。
• 修復アプローチのベンチマーク: ロケーター修復ツール（Similo、Vista など）の評価や、自動化修復のための LLM ベースのエージェントの開発を可能にすること。
• 自然言語ベースのテスト研究: ロケーター破損に対する自然言語ベースのテストアプローチの堅牢性を評価するための大規模データセットを提供すること。

著者は、自動化された再現スクリプトの組み込みが重要な差別化要因であると強調しており、研究者が静的解析に依存するのではなく、実際の実行環境で破損を積極的に確認し、修復技術をテストすることを可能にしていると述べています。また、現在のデータセットは 4 つのプロジェクトをカバーしているものの、この手法は新しいロケーター正規表現パターンを定義することで他のフレームワークにも拡張可能であると指摘しています。