iOS 自動テスト Xcode UIフレームワーク

⚡ スマートサマリー

iOS 自動化テスト Xcode テスト対象アプリケーションに対するユーザーインターフェースの操作を記録し、再生します。設計、テスト、実装、そしてすべてのケースが合格するまで、テスト駆動型のサイクルに従って操作を繰り返します。

  • 🔘 TDDサイクル: iOSアプリケーションのテストには、設計、テスト、実装、そして再テストという4つの段階が適用されます。
  • ☑️ 受験資格: OS X を搭載した Mac Xcode IDE、自動化フレームワーク、およびiOS SDKがインストールされていること。
  • 楽器ルート: オートメーション機器はスクリプトを記録し、スクリプトログに表示し、必要に応じて再生します。
  • 🧪 OCUnitルート: Objective-Cで記述された単体テストバンドルのターゲット、アクティブなスキーム、テストグループ、およびテストクラス。
  • ⚠️ 非推奨: UIAutomation インストゥルメントは非推奨になりました Xcode 8は削除されました。XCUITestがサポートされている後継バージョンです。
  • 🛠️ 現代の同等語: UI Testing BundleターゲットとXCUIApplicationクエリにより、記録されたInstrumentsスクリプトが置き換えられます。

iOS の自動化テスト Xcode UIオートメーションフレームワークがアプリに対して記録されたスクリプトを実行する

を使用した iOS 自動テスト Xcode

iOSアプリケーションの品質を保証するためには、下図に示すテスト駆動開発プロセスに従う必要があります。

iOS自動化テストのためのテスト駆動開発サイクル。設計、テスト、実装、再テストの各フェーズを示す。

テスト駆動開発 (TDD) は、 テスト iOSアプリケーションテストに適用されるモデルであり、より広範な実践の中に位置づけられる。 モバイルテストこのモデルでは、テスターは以下の4つの段階に従う必要があります。

  • デザイン: テストしたい内容を明確にし、テストケースを設計してください。
  • テスト: すべてのテストを実行し、テストケースが失敗するかどうかを確認してください。
  • 実装: Revコードを修正し、テスト失敗の原因となったバグを修正してください。
  • もう一度テストしてください: テストが失敗した場合は、設計段階までロールバックします。すべてのテストケースが合格した場合は、コードはテスト対象の要件をすべて満たしています。

セットアップ Xcode UIテストのプロジェクト

iOSテストプログラムを作成するにはMacが必要です。Macには以下のソフトウェアが既にインストールされている必要があります。

  • OS X ―Mac用のオペレーティングシステム。
  • Xcode IDE ― iOS向け開発ツール。
  • 自動テストフレームワーク — UIオートメーション、OCUnitなど。
  • iOS SDK 4 以上です。

⚠️ バージョンに関する注記: 上記の前提条件は、以下の 2 つのチュートリアルが書かれた時代のツールチェーンについて説明しています。現在の Mac では、 Xcode XCTestとXCUITestフレームワークは同梱されており、別売りのUIオートメーションツールはインストールに含まれなくなりました。元の手順はフレームワークの動作方法を説明するために以下に記載されていますが、最新の同等の手順については後述します。

UI オートメーション フレームワークを使用して iOS オートメーションを作成する方法

以下の8つの手順では、オートメーションツールを使用してスクリプトを記録し、テスト対象のアプリケーションに対してそれを再生します。

ステップ 1) インストゥルメントを起動する

Xを開くCode -> 開発者ツールを開く -> インストゥルメント

オープニング楽器 Xcode 開発者ツールメニューを開く

ステップ 2) 自動化インストゥルメントを追加する

「計測器」ウィンドウで、「オートメーション」計測器を選択します。

計測器テンプレートセレクターでオートメーション計測器を選択する

テストスクリプトを作成するには、 テストシナリオ または、手動でプログラムすることもできます。

ステップ3) 赤いボタンを押します

楽器が起動しました。録音をすぐに停止してください。録音を開始するには、赤いボタンを押してください。

楽器ツールバーの赤い録音ボタンは、 trace

ステップ 4) 新しいスクリプトを作成する

スクリプトウィンドウで、[追加] > [作成] をクリックして新しいスクリプトを作成します。

新しいオートメーションスクリプトを作成するには、インストゥルメントスクリプトウィンドウの「追加」メニューと「作成」メニューを使用します。

ステップ5) ターゲットを選択します

あなたは今、 Trace ウィンドウを使用します。[選択] を使用します。 Target プルダウンして、アプリのデバッグバージョンに移動してください。

選択する Target 機器のプルダウン Tracデバッグビルドを指すウィンドウ

この場合、Appleのサンプルは シンプルドリルダウン このアプリはテスト対象アプリケーションとして使用されます。そのGUIは以下のとおりです。

テスト対象アプリケーションとして使用されるSimpleDrillDownサンプルアプリケーションインターフェース

ステップ 6) スクリプトの記録を開始します

ツールの上部または下部にある記録ボタンを押して、スクリプトを記録します。

スクリプトキャプチャを開始する、インストゥルメントウィンドウの端にある録音ボタン

これで、テスト対象のアプリケーションでUI操作を実行でき、そのスクリプトが記録されます。

ステップ 7) スクリプトを確認する

スクリプトを表示するには、 Traceログ/エディターログのドロップダウンメニューを開き、スクリプトログビューに切り替えます。

Traceログとエディターログのドロップダウンを使用して、スクリプトログビューに切り替えます。

記録されたスクリプトが表示されます。

記録されたUIオートメーションスクリプトがInstrumentsスクリプトログビューに表示されます

ステップ 8) スクリプトを再生する

再生ボタンを押してください。スクリプトが実行され、ログが表示されたら停止できます。

記録されたオートメーションスクリプトの再生とログ出力がインストゥルメントウィンドウに表示されます。

⚠️ 歴史的注記: これら8つのステップで使用された自動化機器は、 Xcode 8以降削除されたため、現在のバージョンには存在しません。 Xcode インストール手順。これらの手順は、フレームワークの動作記録としてここに残されています。新規作業の場合は、このページの下部にある XCUITest のチュートリアルを参照してください。

OCUnitフレームワークを使用してiOSオートメーションを作成する方法

2番目のルートではテストを内部に配置します Xcode Instrumentsの内部ではなく、プロジェクト自体が対象となります。

ステップ1)開始 Xcode IDE、単体テストバンドルターゲットの追加

既存のユニットテストバンドルターゲットを追加する Xcode プロジェクト

ステップ2)新しい単体テストバンドルの名前を記入します 上の図に示すように、次に「完了」をクリックします。

ステップ3)単体テストをアクティブターゲットにする

ユニットテストバンドルをアクティブなターゲットとして選択すると、 Xcode

ステップ4)テストクラス用のグループを追加する

iOSユニットテストクラスを格納するためのプロジェクトグループを作成する

ステップ 5) 単体テスト クラスを追加する

テストグループ内に新しい単体テストクラスファイルを追加する Xcode

ステップ6)さあ、実装を開始しましょう

空の単体テストクラス Xcode エディタはテスト実装の準備ができました

OCUnitはObjective-C言語を使用してテストプログラムを作成するため、開発者はその言語を知っている必要があります。 Xcode バージョンが出荷されます 単体テスト 代わりに XCTest を介して、Objective-C と Swiftしかし、これら6つのステップで示されているターゲットとクラスの構造は変更されていません。

UIAutomationとXCUITest:何が変わったのか

上記で使用した2つのフレームワークはどちらもAppleのツールチェーンの旧世代に属するため、それらを置き換えたものとその理由について正確に説明しておく価値がある。

側面 UIオートメーション(ツール) XCUITest
ステータス 非推奨 Xcode 8 以降のリリースでは削除されました AppleがサポートするUIテストフレームワーク
テストが存在する場所 楽器内のスクリプト trac電子文書 UI テストバンドルターゲット内 Xcode プロジェクト
言語 Javaスクリプト Swift またはObjective-C
テストランナー 自動化機器 XCTestは、ユニットテストと同じランナーです。
継続的インテグレーション ぎこちない - 楽器を通して駆動 コマンドラインから単体テストと並行して実行します。
レコーディング 楽器ツールバーの録音ボタン 録画ボタン Xcode エディタは、 Swift

実際には、XCUITest スイートは通常のプロジェクト ソース コードです。コード ベースの他の部分と同様にレビュー、バージョン管理、実行されます。これが記録されたテストの主な理由です。traceモデルが消えた。

XCUITest を使用した iOS UI テストの書き方

8 つの Instruments ステップの現代版は短い。以下の構造は、同じ録音して再生するというアイデアを反映しているが、出力はソース ファイルであり、 trace.

  1. 対象を追加します。 In Xcode ファイル > 新規 > を選択 Target UIテストバンドルテンプレートを選択するか、新しいプロジェクトを作成する際にテストを含めるオプションにチェックを入れてください。
  2. 生成されたテストクラスを開きます。 Xcode 空のセットアップメソッドとテストメソッドを持つXCTestCaseサブクラスを作成します。
  3. テスト対象のアプリを起動します。 XCUIApplicationインスタンスを作成し、そのインスタンスに対してlaunchメソッドを呼び出すと、アプリが別のプロセスで起動します。
  4. 問い合わせて、行動を起こす。 要素クエリを使用して、ボタン、テーブル、静的テキストなどの要素にアクセスし、それらの要素に対してtap、typeText、またはswipeを呼び出します。
  5. アサート。 XCTAssertを使用して、アクション実行後に期待される要素が存在することを確認します。
  6. 実行します。 テストを実行する Xcode テストナビゲーター、またはコマンドラインから実行することで、同じテストスイートを継続的インテグレーション環境で実行できます。

最小限のテストは以下の形式に従います。

import XCTest

final class AppUITests: XCTestCase {

    func testTappingFirstRowShowsDetail() {
        let app = XCUIApplication()
        app.launch()

        // act on the first row of the list
        app.tables.cells.element(boundBy: 0).tap()

        // verify that the next screen appeared
        XCTAssertTrue(app.staticTexts.firstMatch.waitForExistence(timeout: 5))
    }
}

レコーダーは依然として存在します。テスト メソッド内にカーソルを置き、エディタの記録ボタンを押すと、これらのクエリが自動的に生成されます。これは上記のステップ 6 の直接の子孫です。より広範な原則は、 自動化テスト 変更せずに適用する。

UI自動化サンプル Code

この記事にはいくつかのソースコード例が含まれています。これらはチュートリアルをより明確かつ迅速に理解するのに役立ちます。

UI自動化サンプル — UIオートメーションデモ用のテストスクリプト。

よくあるご質問

いいえ。 Xcode iOSシミュレーターは macOSそのため、ローカル環境またはホスト型ビルドマシンとしてMacが必要となります。クラウドデバイスファームやホスト型CIプロバイダーは、Macハードウェアを持たないチームでもこのスイートを実行できるようにするために存在します。

機械学習モデルは、画面が変更された際に代替要素クエリを提案し、不安定な障害を根本原因ごとにクラスタリングし、失敗した実行のうちどれが真の回帰障害であるかをランク付けします。これは、小さなレイアウト変更でも一度に多くのセレクタが壊れてしまうようなUIスイートにとって重要です。

テストクラスのスキャフォールディング、起動引数、ページオブジェクトラッパー、アサーションの定型コードといった反復的な部分はうまく処理されます。要素識別子は実際のアプリケーションと一致させる必要があるため、生成されたクエリはすべて、信頼する前に実行中のビルドに対して検証する必要があります。

Appium iOS は、古い UIAutomation ドライバーに代わる XCUITest ドライバーを介して駆動されます。利点は、iOS 用のクロスプラットフォーム テスト言語が 1 つで、 Androidその代償として、テストとApple独自のランナーの間に余分なレイヤーが追加されることになる。

単体テストはアプリのプロセス内で実行され、コードを直接呼び出します。UIテストはアプリを別のプロセスとして起動し、インターフェースのみを介して操作するため、処理速度は遅くなりますが、ユーザーが実際に体験する内容を検証できます。

シミュレーターは、パイプライン内のほとんどの機能フローにおいて高速かつ十分な性能を発揮します。しかし、カメラ、生体認証、プッシュ通知、パフォーマンス、およびハードウェアセンサーを使用するあらゆる機能には実機が必要となるため、ほとんどのチームは開発サイクルの異なる段階でシミュレーターと実機の両方を活用しています。

各テストではアプリを再起動し、アニメーションが完了するまで待機します。ラベルでマッチングする代わりにアクセシビリティ識別子を設定し、スリープではなく要素の存在を待機すると、安定性が向上します。pingテスト間で状態をリセットし、各ケースを1つのプロセスに集中させる。

直接的にはできません。言語や要素モデルが異なるためです。通常の手順としては、既存のスクリプトを想定されるカバレッジのドキュメントとして残し、本番環境で最も頻繁に失敗するシナリオから順に、各シナリオをXCUITestケースとして書き直します。