著者について

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

はじめに

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

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

1. UI 自動(dòng)化の現(xiàn)狀

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

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

2. 動(dòng)作駆動(dòng)開(kāi)発 BDD の導(dǎo)入

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

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

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

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

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

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

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

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

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

#そして、これらの作業(yè)自體にも多くの人手が必要であり、AI によるテスト スクリプトの自動(dòng)生成というシステムの本來(lái)の目的に反しています。 。

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

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

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

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

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

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

次に、料金の詳細(xì)に Black Diamond VIP が含まれているかどうかを確認(rèn)します。

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

5. システム実裝

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

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

#5.1 プロンプトの言葉

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

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

#5.2 デバッグ ツール

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

#5.3 ページ情報(bào)取得ツール

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

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

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

#5.4 AI のさらなる分割

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

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

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

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

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

6. フォローアップ開(kāi)発

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

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

2) 現(xiàn)在、処理が難しい操作や検証がいくつかあります。成功率は 80% であり、改善の余地はまだ多くあります?，F(xiàn)時(shí)點(diǎn)では、生成された結(jié)果をレビューする必要があります。

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