WWDC Quick Look 💓 By SwiftGGTeam
Fix failures faster with Xcode test reports

Fix failures faster with Xcode test reports

元の動画を見る

ハイライト

Xcode 15 はテスト レポートを再設計しました。これにより、手動によるログ レビューによるテスト失敗の根本原因の特定にかかる時間が、失敗パターンの自動識別、インタラクティブな UI テスト再生、およびヒート マップ ビューによってわずか数分に短縮されました。

主要内容

プロジェクトには、複数の言語構成と複数のデバイスで実行される何千ものテストがあります。特定の CI ビルドが失敗し、膨大なテスト マトリックスに直面します。よくある問題はどの失敗ですか?デバイス固有のものはどれですか?どこから始めればよいでしょうか?

Xcode 15 のテスト レポートは、この問題点を解決するように設計されています。

(00:19) テストレポートには、ローカルテスト、Xcode Cloud CI テスト、およびリモートマシンテストの結果が均一に表示されます。テストの規模に関係なく、単一のデバッグ テストから数千の CI テストまで、すべてが同じインターフェイスで編成されます。

テスト構造のレビュー

(01:03) Xcode のテスト階層は下から上に次のようになります: テスト メソッド (単一のテスト メソッド) → テスト クラス (テスト クラス) → テスト バンドル (テスト パッケージ、ユニット、または UI) → テスト プラン (テスト計画)。テスト計画には複数のバンドルを含めることができ、複数の実行条件 (構成) とデバイス (実行先) を構成できます。

(03:11) 講演者は多言語サポートを例に挙げました。テストプランは英語、フランス語、日本語、その他の言語構成で構成されており、iPhone 14、iPhone 14 Pro、iPad の 3 つのデバイスで実行されます。 「テスト方法 + 構成 + 機器」の各組み合わせによってテスト方法実行が生成され、完全なテスト結果マトリックスが形成されます。

テストの概要: 全体の状況を一目で明確に把握

(05:57) テストの概要には、テスト実行の全体的な概要が示されています。

  • テスト環境情報: 実行コンフィギュレーション、デバイスリスト、テスト計画の特性 (テストの繰り返し数、パフォーマンス指標の収集など) を表示します。
  • ヒート マップ: マルチデバイスおよびマルチ構成マトリックスでどの組み合わせが成功し、どの組み合わせが失敗したかを色を使用して視覚的に表示します。
  • 失敗クイック入力: 失敗したすべてのテストを直接リストします。階層検索を拡張する必要はありません。

(07:05) ヒートマップの色とカウントは、異なる実行間のパフォーマンスをすばやく比較するのに役立ちます。すべての構成でデバイスに障害が発生する場合、問題はコード ロジックではなくデバイス環境にある可能性が高くなります。

インサイト: 障害パターンを自動的に検出します。

(06:11) インサイトはテスト レポートの中核となるハイライトであり、すべての構成とデバイスのテスト結果を自動的に分析して隠れたパターンを発見します。

一般的な失敗パターン

(06:32) Xcode は、同様の失敗メッセージを持つテストを自動的にグループ化します。講演者の例では、同様の失敗メッセージがあったため、3 つのテストがグループ化されました。 [Insight] をクリックすると、一般的な失敗メッセージ、どのテストが関係していたのか、どの構成とデバイスで発生したのかが表示されます。

(08:01) この種のグループ化により、修復の優先順位が直接与えられます。共通の問題を解決すると、複数のテストが修復される可能性があります。

最長のテスト実行

(06:42) パフォーマンスのボトルネックを特定するのに役立つ最長のテストをリストします。これは、テスト スイート全体が遅い場合に開始する最も効果的な場所です。

テストの詳細: 単一のテスト用の専用デバッグ スペース

(08:12) [テスト メソッドの実行] をクリックして [テストの詳細] ビューに入ります。これは、単一のテスト結果に焦点を当てたデバッグ スペースです。

単体テストの場合:

  • すべての構成とデバイスにわたる実行結果の比較
  • 失敗メッセージとコールスタック (Call Stack)
  • コールスタック内のエントリはソースコードに直接ジャンプできます

UI テストの場合、デバッグ機能が強化されています。

(09:50) UI テストのテスト詳細には、次の 3 つの領域が含まれます。

テスト活動

タイムライン形式では、テストの各イベントが開始から終了まで表示されます。上部はテストの開始点、下部は終了点、中央の各行は操作イベントを表します。

オートメーション エクスプローラー

(10:17) テストアクティビティにリンクされたビデオ再生領域。タイムライン上の任意のイベントをクリックすると、Automation Explorer に対応する瞬間のスクリーンショットが表示され、テスト プロセス全体を完全に再現できます。

スクラバー (タイムライン)

(10:25) クリック、スライド、回転、その他のインタラクティブなイベントでマークされた、テスト実行の線形タイムライン。障害アイコンは障害が発生した正確な位置をマークし、問題の瞬間を素早く特定するのに役立ちます。

(11:46) UI 要素の境界ボックスをクリックすると、要素の識別子 (Identifier) と階層情報 (Hierarchy) が表示されます。講演者の例では、「アカウント」ボタンがはっきりと見えますが、テストではそれを見つけることができません。要素情報を見ると、ラベルが間違って書かれていることがわかります。

詳細

多言語テスト マトリックスの構成

(02:19) テスト計画の構成で異なる言語と地域を設定します。

Test Plan: Backyard Birds
├── Configuration: English (US)
├── Configuration: French (FR)
├── Configuration: Japanese (JP)
└── Run Destinations: iPhone 14, iPhone 14 Pro, iPad

キーポイント:

  • 各構成は完全なテスト スイートを個別に実行します
  • 複数の実行先を組み合わせて完全なテスト カバレッジ マトリックスを形成します
  • 国際化、ローカリゼーション、地域形式 (日付、数値、通貨) の正確性の検証に適しています。

Insights を使用して一般的な問題に優先順位を付ける

(07:34) Insights に「3 つのテストは同様の失敗メッセージを共有しています」と表示されている場合、プロセス フローは次のとおりです。

  1. [インサイト] をクリックして、一般的な失敗メッセージを表示します。
  2. どのテストメソッドとクラスが関係しているかを確認する
  3. どの構成/デバイスでこの問題が発生するかを確認します
  4. すべての構成で失敗する場合 → コードロジックの問題
  5. 特定の構成でのみ失敗する場合 → ローカリゼーションまたは環境の問題

(08:07) 講演者の 3 つの失敗したテストはすべて、同じ API が原因で例外を返しました。 1 つを修正すると、3 つのテストの失敗を同時に解決できます。

UI テストとデバッグの練習

(09:39) UI テストが失敗した場合のデバッグ手順:

  1. 「テスト概要」で失敗した項目をクリックして、「テストの詳細」を入力します。
  2. デフォルトで「アクティビティ」タブに入ります
  3. タイムラインで赤色でマークされた障害イベントを見つけます。
  4. Automation Explorer で失敗した瞬間のスクリーンショットを表示する
  5. Scrubber が失敗を確認する前に対話シーケンスを確認する
  6. ターゲット UI 要素の境界ボックスをクリックして、識別子とアクセシビリティ情報を表示します。
  7. コード内のクエリ条件と実際の要素の属性を比較します。

(12:12) 講演者は、ボタンのアクセシビリティ ラベルがコード内では「アカウント」と書かれているが、実際の要素には「設定」と表示されていることがわかりました。ラベルの不一致が原因でした。XCTAssert要素が見つかりません。

ローカルと CI の統合エクスペリエンス

(12:27) テスト レポートは、Xcode IDE と Xcode Cloud 全体で一貫したインターフェイスを提供します。ローカル デバッグ中に再発する問題は、CI でも同様に分析できます。 CI によって発見された障害は、同じツール チェーンを使用してローカルでチェックすることもできます。

重要ポイント

1.複数構成の CI テストのアクセス制御を確立

  • やるべきこと: Xcode Cloud ワークフローで複数言語、複数デバイスのテスト計画を構成し、PR ごとに自動的に実行します。
  • 実行する価値がある理由: Insights の Common Failure Patterns は、障害が発生するとすぐに一般的な問題を指摘し、問題がメイン ブランチにマージされるのを防ぐことができます。
  • 開始方法: テスト計画に言語/地域構成を追加し、Xcode Cloud ワークフローでテスト計画を関連付けます

2.ヒート マップを使用して機器固有の問題を特定します

  • 対処法: テスト概要のヒート マップを定期的に確認して、「デバイスの系統的障害」のパターンを探します。
  • 実行する価値がある理由: デバイス固有の問題は通常、環境または適応の問題であり、コード ロジックとは関係ありません。ヒートマップの色分布が一目で分かります。
  • 開始方法: テスト計画で複数の実行先を構成し、CI の実行後にヒート マップの列 (デバイス ディメンション) を表示します。

3.遅いテストを最適化して CI 効率を向上

  • 何をすべきか: 最長テスト実行インサイトを使用して最長のテストを見つけ、それに応じて最適化または分割します。
  • 実行する価値がある理由: CI のビルド時間は開発効率に直接影響します。 30 秒かかるテストを 3 つの 10 秒テストに分割する場合、並行して実行すると合計時間を大幅に短縮できます。
  • 開始方法: Insights で最長テスト実行リストを表示し、上位のテストでパフォーマンス分析を実行します。

4. UI テストの再生を使用して、時折発生するバグを見つけます

  • 対処方法: 時折失敗する傾向にある UI テストの場合は、Automation Explorer のビデオ再生とスクラバー タイムラインを使用して、失敗前の操作を分析します。
  • 実行する価値がある理由: 時折発生するバグは、再現するのが最も困難です。テスト レポートには完全なテスト プロセスが自動的に記録されるため、手動で再現する必要がなくなります。
  • 開始方法: UI テストのテスト手順が明確であることを確認してください。失敗したら、「テストの詳細」の「アクティビティ」タブでフレームごとにそれらを表示します。

関連セッション

コメント

GitHub Issues · utterances