AI を活用した自己修復機能で Appium スクリプトのメンテナンスを楽にする

一日の終わり、テストチームは荷物をまとめて帰宅する。最後に退社した人が伝統的に照明を消すため、もう一つやらなければならない仕事がある。その途中で、チームメンバーの一人が、夜間テストの実行をタスクの一環として開始する必要がある。 回帰試験 モバイルデバイス向け。しかし翌朝、チームは衝撃と落胆を禁じ得ないほど、アプリケーション内のロケーターの変更が原因で多くのテストが失敗していることに気づきました。

このような変更は頻繁に発生しますが、様々な理由から見過ごされがちです。例えば、開発チームが行った変更があまりにも小さく、重要ではないと判断され、QAチームに伝わらなかった、といったケースが挙げられます。

失敗したスクリプトを確認し、ロケーターを更新し、テストを再実行するために必要な時間と労力により、スプリントはすぐに脱線し、欠陥が本番環境に出荷されるリスクが高まります。

AIがSDLCの中心となる世界において開発者は、コンテキストに応じた提案、コード最適化、さらにはユニットテスト生成といった支援を受けられるようになりました。これにより開発は加速しますが、作成されるコードの増加に対応しきれず、QAチームにとって下流工程の課題となる可能性があります。

上記のような小さなUI変更は、自動化されたエンドツーエンドテストに影響を与えることがよくあります。しかし、AIセルフヒーリングの統合により、スクリプトは即座に適応し、テストフローを中断することなく、実行中に壊れたロケータを修復できます。この機能により、QAチームは急速な開発サイクルに対応し、テストのメンテナンス時間を大幅に短縮し、より迅速なフィードバックを提供することができ、同時にテストのレジリエンス(回復力)も向上します。

このブログでは、 AIによる自己修復 人間の介入なしに実行時に要素の不一致を自律的に解決します。

前提条件: この機能は、Pro および Premium SaaS のお客様のみが利用できます。

AIセルフヒーリングとそれが当社のプラットフォーム上でどのように動作するかをより深く理解していただくために、 Digital.aiAndroid 用に構築された銀行アプリケーションを作成し、変更が検出されるログイン ページの簡単なテストを実行します。

同じアプリケーションの 2 つのバージョン、つまり、変更されていないバージョン (動作することが期待されるビルド) と変更されたバージョン (ロケーターの 1 つが変更されているバージョン) が存在します。

アプリケーションの変更されていないバージョンでは、ID「usernameTextField」がユーザー名ロケータを識別します。

このロケータは、以下に示すように自動化スクリプト内で参照されます。以下の行は、自動化されたAppiumテストがトリガーされた後、ユーザー名フィールドを検証し、操作します。

``` wait.until(ExpectedConditions.elementToBeClickable(By.id("com.experitest.ExperiBank:id/usernameTextField"))); driver.findElement(By.id("com.experitest.ExperiBank:id/usernameTextField")).sendKeys("tester01"); ```

通常の状況では、ロケータが変更されていないため、スクリプトは問題なく実行されます。

しかし、ユーザー名フィールドのロケータが変更されたシナリオを考えてみましょう。この変更されたビルドでは、「UsernameTextField」ではなく「UserTextField」として識別されます。

この場合、スクリプトは「NoSuchElementException」で直ちに失敗します。

この問題にどう対処すればいいでしょうか?

テスト設定の「必要な機能」に1行追加するだけです。アプリケーションをインストールして起動するための簡単なテストスクリプト設定を見てみましょう。 Digital.aiさん Continuous Testing プラットフォーム:

`` `
望ましい機能の上限 = NEW 望ましい機能();

caps.setCapability()「テスト名」, 「ログインシナリオテスト」;
caps.setCapability()「アクセスキー」、アクセスキー);
caps.setCapability()「デバイスクエリ」, 「@os='android'」); //
https://docs.digital.ai/bundle/TE/page/device_queries.html
caps.setCapability()「アプリ」, 「クラウド: com.experitest.ExperiBank/.LoginActivity」);
caps.setCapability()「アプリパッケージ」, 「com.experitest.ExperiBank」);
caps.setCapability()「アプリアクティビティ」, 「.ログインアクティビティ」);

望ましい機能.set(大文字);
ドライバー。セット(NEW AndroidDriver(NEW URL(「https:// /wd/ハブ"), 大文字);

`` `

ここで、次の行を機能内に追加すると、スクリプトは自己修復モードで実行されるようになります。

`` ` 
caps.setCapability()「自己治癒」, true);

`` `

自動化されたスクリプトを通常通り実行できるようになりました。IDE(Eclipse / IntelliJなど)やCICDパイプライン(Azureなど)からの変更は不要です。 DevOps).

AI の自己修復を有効にすると、通常のテストの実行時間に影響しますか?

セルフヒーリングを有効にすると、セルフヒーリングモジュールがテスト実行中にページの変更を継続的にスキャンするため、テスト実行時間が長くなる可能性があります。柔軟性を高めるため、スクリプト内にセルフヒーリングを一時停止および再開するオプションを追加しました。例えば、ログインページが安定しており、エラーが発生する可能性が低い場合は、このセクションでセルフヒーリングを無効にすることでテスト実行時間を短縮できます。テストスクリプトにワンライナーを追加するだけで、セルフヒーリングモードを一時停止できます。

`` `

ドライバー.executeScript()「seetest:client.stopHealing」);

`` `

再開したい場合は、別のワンライナーを呼び出すだけです。

`` `

ドライバー.executeScript()「seetest:client.startHealing」);

`` `

自己修復はカスタマイズ可能ですか?

AI を活用した自己修復機能は、特にさまざまなレベルの複雑さを扱う場合に、テスト対象のアプリケーションのニーズに合わせて構成できます。

  1. 回復の試み: 一致するロケーターを検出するためにアルゴリズムが実行する試行の合計回数を定義します。
    デフォルトでは、自己修復機能は要素ごとにロケータの変更を1回ずつ識別しようとします。例えば、アルゴリズムがユーザー名フィールドの代替ロケータを見つけられなかった場合、アルゴリズムは1回だけ試行してから次の処理に進みます。
  2. スコアキャップ: 一致確率に基づいて、一致スコアのしきい値を設定します。デフォルトのスコアは、0.1~1.0のスケールで0.6に設定されています。
    スコア 0.6 は、一致確率が 60% を超える場合にのみ、新しく識別されたロケータに対して自己修復がトリガーされることを示します。

その Digital.ai サポート チームはリクエストに応じてこれらのプロパティの両方を変更できます。

AI 自己修復はあらゆる種類のモバイル アプリケーションで機能しますか?

現在、AIセルフヒーリングはAndroidのモバイルネイティブテストとWebテスト、そしてiOSのWebテストでサポートされています。iOSのモバイルネイティブアプリケーションはまだサポートされていませんが、今後のアップデートにご期待ください。

単一のテスト スクリプト実行中に複数のロケータの変更が発生した場合はどうなりますか?

ロケータの変更が 1 つでも複数でも、AI 自己修復が有効になっていると、自己修復メカニズムがアクティブになり、1 回のテスト実行中に、手動による介入なしに、影響を受けるすべてのロケータが自動的に更新されます。

テストが修復されました: テストをそのまま実行し続けるか、スクリプトを変更する必要がありますか?

自動テストは引き続き実行でき、期待通りに動作します。 Digital.ai platform 変更の検出を継続し、スクリプトが期待どおりに実行されることを確認します。ただし、これでは問題が完全に解決されるわけではありません。テストは実行時に修復されますが、IntelliJなどのIDEから実行した場合でも、AzureなどのCI/CDパイプラインから実行した場合でも、実際のスクリプトは変更されません。 DevOps元の自動化スクリプトを修正し、必要な変更を加える必要があります。

いずれにせよ変化が必要なら、なぜ癒す必要があるのでしょうか?

セルフヒーリングを使用する利点は、ロケータの変更によってテスト実行が中断されないことです。実行後、都合の良いときにレポートを確認して修復されたロケータを特定し、それに応じてスクリプトを更新できます。真のテスト失敗と自動化の問題を区別することで、エンドユーザーへの影響がはるかに大きい、より優先度の高いタスクに集中できるようになります。その結果、不安定なテストによって進捗が妨げられることを常に心配することなく、新しいアップデートをリリースできます。

何かが治癒したかどうかはどうすればわかりますか?

簡単です!例を見てみましょう。ブラウザからレポーターページに移動できます(Chromeが最適です)。

「https://」 /レポーター/レポーター/テスト ```

または、メインプラットフォームの右上隅にあるイニシャルをクリックして「レポーターへ"

 

そして「テスト” タブ: 

 

このビューには、修復されたテストの割合を含む、プロジェクトで実行されたすべてのテストが表示されます。

 

をクリックする 癒された 円グラフのステータスにより結果がフィルタリングされ、修復されたテストのみが表示されます。

 

各レポートをクリックすると、修復された内容の詳細情報を表示することもできます。

最終的な考え

AIを活用した自己修復はテスト自動化の飛躍的進歩を示すAppiumスクリプトのメンテナンス効率を向上させ、急速な開発サイクルに対応するために必要な手作業を削減します。セルフヒーリングはスクリプトの更新作業を完全になくすことはできませんが、テストの中断を防ぎ、スクリプトのメンテナンスに役立つ貴重な情報を提供することで、シームレスなエクスペリエンスを提供します。これにより、セルフヒーリングは強力なツールとなり、テストの信頼性を向上させます。AIセルフヒーリングがテスト自動化戦略にどのような変革をもたらすか、そして当社のAIイノベーションについて詳しく知りたい方は、ぜひお問い合わせください。

お勧めの関連ガジェット