AI にリアルタイム デバッグを備えた効果的な UI オートメーションを作成させましょう

著者について

Ctrip のシニア R&D マネージャーである Thales Fu は、AI とエンジニアリングを組み合わせて現実の問題を解決するより良い方法を見つけることに尽力しています。

はじめに

迅速に反復されるソフトウェア開発サイクルでは、ユーザー インターフェイス (UI) の自動テストが効率を向上させ、製品の品質を確保するための鍵となっています。しかし、アプリケーションがますます複雑になるにつれて、従来の UI 自動化方法では徐々に限界が明らかになります。 AI 主導の UI 自動化が実現しましたが、精度と信頼性の課題に依然として直面しています。これに関連して、この記事では、リアルタイム デバッグ テクノロジを通じて、AI によって作成された UI 自動化スクリプトの有効性を大幅に向上できるという革新的な視点を提案します。

この問題は単なる技術的な課題ではなく、ソフトウェアの品質を確保しながらソフトウェアの配信を迅速化する方法に関連しています。 この記事では、リアルタイム デバッグが AI による UI テスト スクリプトのより正確な理解と実行にどのように役立つのか、またこの方法がソフトウェア開発にどのように革命的な変化をもたらすことができるのかについて説明します。

1. UI 自動化の現状

UI 自動化は、単純な記録および再生ツールから始まり、かなりの発展を遂げてきました。今日の複雑なスクリプト フレームワークに。テクノロジーは継続的に進歩していますが、従来の UI 自動化手法は、急速に変化するアプリケーション インターフェイスに対処する際に依然として課題に直面しています。アプリケーションがより複雑かつ動的になるにつれて、従来のアプローチでは不十分になる可能性があります。したがって、エンジニアは、UI 自動化の効率と信頼性を向上させる、より柔軟で信頼性の高いソリューションを探しています。

#業界調査によると、新世代の UI 自動化ツールとテクノロジが登場しつつあります。業界調査によると、テスト スクリプトを手動で作成するのは非効率的で、更新プログラムの適用時に再作業するのに多くの時間がかかります。調査によると、UI 自動テスト スクリプトの保守がテスト作業全体の 60% ～ 70% を占める可能性があります。アジャイル開発環境では、アプリケーションの更新ごとに既存の自動化スクリプトを書き換えてテストするのに 100 時間以上かかることがあります。この高額なメンテナンス コストは、従来の UI 自動化方法の非効率性とリソース消費を浮き彫りにしています。

2. 動作駆動開発 BDD の導入

動作駆動開発 (BDD) は、ソフトウェアを促進するアジャイル ソフトウェア開発手法です。プロジェクトの開発者、テスター、および技術以外の関係者間のより効果的なコミュニケーション。 Cucumber は、BDD 手法を実装するための人気のあるツールであり、チーム メンバーが自然言語を使用して明示的な実行可能なテスト ケースを作成できるようになります。

Cucumber は、Gherkin と呼ばれるドメイン固有言語 (DSL) を使用します。これは非常に読みやすく、技術者以外の人でもテストの目的と内容を理解できます。テスト シナリオは、一連の Given-When-Then ステートメントの形式で記述され、特定の条件下でシステムがどのように応答するかを明確に記述します。

たとえば、オンライン ショッピング Web サイトのショッピング カート機能には、次のような Gherkin シナリオが考えられます:

# # このアプローチでは、自然言語記述機能を活用して、技術チームと非技術チーム間のコミュニケーションと理解を促進します。同時に、自然言語テスト シナリオはプロジェクトの文書化の役割も果たし、新しいチーム メンバーがプロジェクトの機能をすぐに理解できるようにします。これにより、技術者以外の担当者もテスト ケースの作成と検証のプロセスに直接参加できるようになり、開発作業がビジネス ニーズと密接に一致することが保証されます。

ただし、制限もあります。テスト シナリオは自然言語で記述されていますが、各ステップの背後にある実装 (ステップ定義) は、依然として技術担当者がプログラミング言語で記述する必要があります。これは、テスト ロジックの実装には複雑なコーディング作業が必要になる可能性があることを意味します。アプリケーションが成長して変化するにつれて、対応するテスト手順の維持と更新が面倒になる場合があります。特に UI が頻繁に変更される場合は、関連するステップ定義もそれに応じて更新する必要があります。柔軟性と適応性にも制限があります。Cucumber テスト スクリプトは事前定義されたステップと構造に依存しているため、テストの柔軟性が制限される可能性があります。一部の複雑なテスト シナリオでは、特定のテスト ロジックを実装するには、フレームワークの制限を回避するための創造的な方法が必要になる場合があります。

3. UI オートメーションにおける AI の現在の応用

近年、AI テクノロジーは、独自のコード生成機能を備えているため、特に GPT に代表される大規模モデルの出現後、UI オートメーションに統合されています。業界はまた、大規模なモデルを通じて Gherkin のテスト ケース記述言語をテスト コードに直接生成する試みも始めています。

しかし、現在の大規模モデルによって生成されたテスト コードは期待を完全には満たすことができません。主な問題がいくつかあります。まず、生成されたスクリプトです。構文エラーにより実行できない可能性があり、次に、テスト ケースでテストする必要があるチェックポイントを正確にカバーしていない可能性があります。私たちの実践では、最初の試行での成功率はわずか 5% です。

生成に失敗した後は、修復作業を行うために人が介入する必要があります。これには、デバッグ、再生成するためのユースケースの変更、または生成されたスクリプトの直接変更が含まれます。

#そして、これらの作業自体にも多くの人手が必要であり、AI によるテスト スクリプトの自動生成というシステムの本来の目的に反しています。 。

4. AI が効果的なテスト スクリプトを完全に自動で作成します

この問題を解決するために、AI がテスト スクリプトを生成する方法を再考しました。プロセス全体。

#私たちは人々の仕事についても一緒に考えます。システムのデバッグと変更作業は人間が行ってきたため、この部分の作業を AI が行うことはできますか? 生成されたコードをシステム自身で実行し、生成されたエラー コードを AI にデバッグおよび変更させます。

したがって、人間の代わりに AI が自律的にこれらのタスクを実行できるようにシステム設計を調整しました。最終的に、Ctrip のホテル注文詳細ページのすべてのユースケースでは、83.3% のケースが誰の参加もなしに正常に生成され、スクリプト生成プロセス中に 8% のケースでバグが発見されました。これらのユースケースを 3 回連続で生成し、成功率はそれぞれ 84.3%、81.4%、83.3% であり、システムは安定していて効果的です。

具体的なテスト ケースとコードは次のとおりです。

まず、次のページにスライドする必要があります。注文の詳細ページに移動してユーザー権利モジュールをドロップし、予約最適化領域をクリックして価格変動レイヤーをポップアップ表示します。

次に、料金の詳細に Black Diamond VIP が含まれているかどうかを確認します。

最終的に生成されたテスト コードは次のとおりです。

5. システム実装

##システム全体のコアアーキテクチャ図は以下のとおりです。システムの中核部分は、langchain フレームワーク プログラムです。大規模モデルにアクセスすることになりますが、大きく分けてページ情報を取得するツールとデバッグツールの2つに分けて複数のツールを搭載しています。

Langchain は、ページ情報取得ツールを自動的に使用して必要に応じてページ データを取得し、コードを生成する現在の操作にどの特定のコントロールが必要かを判断します。次に、デバッグツールを使用して実際に携帯電話上でコードを実行し、デバッグのフィードバックに基づいて生成されたコードが正しいかどうかを判断します。

#5.1 プロンプトの言葉

「はい」の後基本的なアーキテクチャでは、これらのツールをつなぎ合わせ、AI がどのように機能するかを理解させるための即効性のある言葉が必要です。構造的には、プロンプトワードにはいくつかの部分が含まれています。まず、AI がどのように考えて動作するかを伝え、次に、生成された各ステートメントをデバッグを通じてデバッグするように伝え、出力形式が何であるかを再度伝え、最後に AI に伝えます。 AI が処理するユースケースの完全なテキスト。

AI に AI がどのように考えて動作するかを指示するため、拡張には次の部分が含まれます。 まず、ページ上にどのようなモジュールがあるかを確認し、どのモジュールを操作したいステップにする必要があるかを確認します。 、およびこのモジュールの内容 コントロールとコンポーネント、現在操作したいコントロールまたはコンポーネント、操作したいアクション、使用できる特別な構文は何かを確認し、ステートメントを生成します。

#5.2 デバッグ ツール

デバッグ ツール本質は、adb ツールを介して電話にリモート接続することです。接続後、AIが生成した命令を携帯電話に送信して実行し、操作後の結果を読み取ってAIに与えることで、AIが生成した命令が正しいかどうかを判断できるようになります。

#5.3 ページ情報取得ツール

ページ情報取得ツールの最終的な目的は、BDD ユースケースに記述されている操作対象のコンテンツと、操作したい特定のコントロールの ID を AI が判断できるようにすることです。 ID に基づいて後続のコンテンツを生成できるプログラム命令。 ID を取得するには、コントロールとコンポーネントのライブラリが必要です。このライブラリの核となるのは、各コントロールとコンポーネントの ID とその説明です。これら 2 つのコンテンツにより、AI は BDD ユースケースを読んだ後、コントロールの記述に基づいてどのコントロールが必要かを推測することができます。

この目標を達成するために、私たちはページ コントロール ライブラリを確立しました。このライブラリには、ページ上の各コントロールの ID と説明に加えて、ページとコンポーネントの間の関係、およびコンポーネントとコントロールの間の関係も含まれています。これにより、AI が段階的にクエリを実行できるようになります。

#コントロール ライブラリ自体は、ジョブによるコードの静的分析に基づいて生成されます。ただし、実際のアプリケーションでは、シーンの状態に応じて現在ページに表示されているコントロールが異なるため、シナリオによってはページ上のコントロールが非表示になることがあります。したがって、ページ情報取得ツールは、ページ上の現在存在するコントロールとコントロール ライブラリでクエリされたコントロールを交差させ、それによって現在のページに実際に表示されるコントロールとその説明情報を取得します。

#5.4 AI のさらなる分割

## 完了後これらのタスクにおいて、AI は基本的に上の図の黄色の部分、つまり人間の仕事を行うことができます。生成成功率も5%から55%に上昇しましたが、55%の成功率ではまだ十分ではありません。

#私たちは失敗したケースをさらに分析しました。主な問題はAIの幻覚にあることが判明し、プロンプトの言葉は比較的詳細なものであったものの、AIが要求通りに処理できなかったり、勝手に意味不明なことを話したりすることがありました。

私たちの結論は、AI には過大な責任が与えられており、考慮すべきことが多すぎるということです。トークンが足りないのではなく、やらなければならないことが多すぎると忘れられてしまい、要件を正確に完了できなくなるのです。そこで分割を検討し、引き続きlangchainの機能を利用することになったのですが、AIはツールで機能を完結できるのに、なぜこのツール自体がAIにならないのでしょうか？

#また分割することもできます。

これらの分割により、各 AI が考慮する必要がある作業が減り、簡略化され、処理がより正確になります。成功率は80％以上に上昇しました。

6. フォローアップ開発

現在、私たちの取り組みを通じて、AI は人間の介入なしで約 80% の成功率でうまく活用できています。自動テスト コードを高速で生成するのは興味深いことですが、解決すべき問題はまだたくさんあります。

1) 大規模なモデルを呼び出すコストはまだ低くありません。より低いコストで作業を完了するためのより良い方法はありますか?

2) 現在、処理が難しい操作や検証がいくつかあります。成功率は 80% であり、改善の余地はまだ多くあります。現時点では、生成された結果をレビューする必要があります。

3) さらに、他の側面でも改善の余地があり、継続的に改善する価値があります。

以上がAI にリアルタイム デバッグを備えた効果的な UI オートメーションを作成させましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。