一日の終わり、テストチームは荷物をまとめて帰宅する。最後に退社した人が伝統的に照明を消すため、もう一つやらなければならない仕事がある。その途中で、チームメンバーの一人が、夜間テストの実行をタスクの一環として開始する必要がある。 回帰試験 モバイルデバイス向け。しかし翌朝、チームは衝撃と落胆を禁じ得ないほど、アプリケーション内のロケーターの変更が原因で多くのテストが失敗していることに気づきました。
このような変更は頻繁に発生しますが、様々な理由から見過ごされがちです。例えば、開発チームが行った変更があまりにも小さく、重要ではないと判断され、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」で直ちに失敗します。
この問題にどう対処すればいいでしょうか?
`` ` 望ましい機能の上限 = 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」); `` `
自己修復はカスタマイズ可能ですか?
- 回復の試み: 一致するロケーターを検出するためにアルゴリズムが実行する試行の合計回数を定義します。
デフォルトでは、自己修復機能は要素ごとにロケータの変更を1回ずつ識別しようとします。例えば、アルゴリズムがユーザー名フィールドの代替ロケータを見つけられなかった場合、アルゴリズムは1回だけ試行してから次の処理に進みます。 - スコアキャップ: 一致確率に基づいて、一致スコアのしきい値を設定します。デフォルトのスコアは、0.1~1.0のスケールで0.6に設定されています。
スコア 0.6 は、一致確率が 60% を超える場合にのみ、新しく識別されたロケータに対して自己修復がトリガーされることを示します。
その Digital.ai サポート チームはリクエストに応じてこれらのプロパティの両方を変更できます。
AI 自己修復はあらゆる種類のモバイル アプリケーションで機能しますか?
単一のテスト スクリプト実行中に複数のロケータの変更が発生した場合はどうなりますか?
テストが修復されました: テストをそのまま実行し続けるか、スクリプトを変更する必要がありますか?
いずれにせよ変化が必要なら、なぜ癒す必要があるのでしょうか?
何かが治癒したかどうかはどうすればわかりますか?
「https://」 /レポーター/レポーター/テスト ```
または、メインプラットフォームの右上隅にあるイニシャルをクリックして「レポーターへ"
そして「テスト” タブ:

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

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

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