注文確認画面では、標準の文字サイズなら住所も注文確定ボタンもすべて表示されます。ところが、ユーザーがiPhoneの文字を大きくすると、ボタンが画面下部の固定バーに隠れてしまうことがあります。開発用端末で一度画面を開くだけでは、こうした問題を見落としがちです。Dynamic Typeは文字を拡大するだけでなく、改行位置、セルの高さ、スクロールできる範囲も変えます。ここではクラウドMac上のiOSシミュレータでテスト条件を固定し、UIテストで重要な操作経路を確認します。
テスト対象と合格条件を決める
注文確認、設定の詳細、エラーの説明など、実際に内容が長い画面を一つ選びます。プロジェクトのXcodeプロジェクト、scheme、シミュレータのデバイス、iOSランタイム、テストアカウントの状態を記録してください。以降の比較には、同じ条件を使います。クラウドMacを複数人で共有している場合は、このテスト専用のシミュレータデバイスを指定し、別の作業によって文字サイズが変わったり、アプリのデータが消されたりしないようにします。
まず画面上で完了できなければならない操作を挙げ、その後にアサーションを書きます。少なくとも、タイトルが読めること、主ボタンを操作できること、長い説明を末尾までスクロールできること、戻る操作が使えることを確認しましょう。ビューが存在するかを調べるだけでは、文字が切れていないことまでは証明できません。
| 確認対象 | 操作で確認できる合格条件 | 目視で再確認する点 |
|---|---|---|
| 画面タイトル | 想定したアクセシビリティ識別子を見つけられる | 改行後に隣のコンテンツに重ならないか |
| 主操作 | スクロール後にタップでき、想定した状態に進む | ボタンの文字がすべて表示されるか |
| 長い説明 | 末尾の内容を表示領域までスクロールできる | テキストやコンテナの端が切れていないか |
「正常に見える」を、実際に操作できる経路と確認すべきスクリーンショットに分けます。自動アサーションで明確な不具合を検出し、まだアサーションで表現できていない視覚上の問題をスクリーンショットで見つけます。
シミュレータを固定して文字サイズを切り替える
クラウドMacで、Xcodeのコマンドラインツールが想定したバージョンを指していることを確認し、利用可能なデバイスを一覧表示します。bootedが常に同じデバイスを指すとは考えないでください。同じMacで並行する作業が、複数のシミュレータを起動することがあります。対象デバイスのUDIDをテストタスクの設定に記録し、起動後はシステムの起動完了を待ちます。
xcode-select -p
xcrun simctl list devices available
export SIM_UDID="从上一步选择的设备 UDID"
xcrun simctl boot "$SIM_UDID"
xcrun simctl bootstatus "$SIM_UDID" -b
xcrun simctl help ui
デバイスがすでに起動している場合、bootは現在の状態を通知します。UDIDが正しいことを確認したら、そのままbootstatusを実行してください。simctl uiに渡す文字サイズの値は、インストール済みツールのヘルプで確認します。別のXcodeバージョンで使えた値を、そのままスクリプトに書き写さないでください。ローカルのヘルプで確認した値を、たとえば環境変数TEXT_SIZEでテストタスクに渡してから、次を実行します。
: "${TEXT_SIZE:?set a supported content size}"
xcrun simctl ui "$SIM_UDID" content_size "$TEXT_SIZE"
xcrun simctl ui "$SIM_UDID" content_size
標準サイズ、大きめのサイズ、製品がサポートを約束する最大サイズを少なくともテストします。両端だけで済ませてはいけません。中間のサイズでタイトルがちょうど一行増えても、最大サイズ向けのレイアウトにはまだ切り替わらない場合があります。サイズを変えるたびに対象アプリを再起動し、表示中の画面が切り替え前の状態を保持していないことを確認します。
UIテストで操作経路を確認する
アプリ内の重要なコントロールには、checkout.title、checkout.submit、checkout.lastNoteのような安定したアクセシビリティ識別子を設定します。識別子は機能を表すものにし、言語によって変わるボタンの表示文言には依存させません。テストは毎回同じ初期画面から確認画面へ進めます。ログインやデータの準備が必要なら、プロジェクト既存のテスト環境を使い、実際の認証情報をテストコードやログに書かないでください。
以下のXCTestコードはアサーションの考え方を示すものです。具体的な画面遷移と成功状態の識別子は、プロジェクトの実装に合わせて置き換えてください。長い画面ではまずスワイプし、末尾の段落とボタンを操作できるか確認します。
let app = XCUIApplication()
app.launch()
let title = app.staticTexts["checkout.title"]
XCTAssertTrue(title.waitForExistence(timeout: 10))
let page = app.scrollViews["checkout.content"]
let lastNote = app.staticTexts["checkout.lastNote"]
for _ in 0..<6 where !lastNote.isHittable {
page.swipeUp()
}
XCTAssertTrue(lastNote.isHittable)
let submit = app.buttons["checkout.submit"]
for _ in 0..<6 where !submit.isHittable {
page.swipeUp()
}
XCTAssertTrue(submit.isHittable)
submit.tap()
XCTAssertTrue(app.staticTexts["checkout.success"].waitForExistence(timeout: 10))
画面がScrollViewでない場合、サンプルを通すためだけにこのセレクタを当てはめず、実際のコンテナに合わせて調整します。スワイプ回数に上限を設ければ、レイアウトが壊れたときにテストが無限に待つことを防げます。ただし、「タップできる」ことはボタンの文字がすべて表示されている証拠にはならないため、スクリーンショットも残します。
サイズごとの証拠を残して原因を特定する
各サイズについて、デバイスのUDID、ランタイム、Xcodeのバージョン、文字サイズ、テスト結果を記録します。失敗時にはまずUIテストの添付ファイルを保存し、同じサイズで再実行してシミュレータのスクリーンショットを取得します。並行する作業でファイルが上書きされないよう、ファイル名にはサイズと画面名を入れてください。コマンドラインで撮影するならxcrun simctl io "$SIM_UDID" screenshot output.pngを使えます。実際のタスクでは、固定のファイル名をタスク固有の出力パスに変えます。
スクリーンショットを確認するときは、まず外側のレイアウトから原因を探します。高さが固定されたタイトルのコンテナでは、二行目が見えなくなりがちです。横並びのラベルと金額は幅を取り合います。画面下部に浮かせたボタンが、説明の最後の段落を覆うこともあります。文字を収めるコンテナが内容に応じて伸びるようにし、必要なら横並びの情報を縦並びに変え、スクロール領域の下部に余白を確保してください。文字を小さくして、大きな文字サイズでの不具合を隠してはいけません。
「テストがときどき通る」場合は、常に同じUDIDを使っているか、サイズ変更後にアプリを再起動しているか、画面外にある同名の要素をアサーションが誤って選んでいないかを先に確認します。条件が安定していることを確かめてからレイアウトを修正し、デバイスの状態による影響をコードの回帰と取り違えないようにします。
保守できるチェックリストにまとめる
デバイス、ランタイム、サポートする文字サイズをテストタスクの設定に入れ、各サイズで同じUIテストを実行します。失敗するたびに、文字サイズ、失敗したアサーションの位置、スクリーンショットを残します。修正するたびに、少なくとも問題が起きたサイズとその前後のサイズで再テストします。自動判定が難しい文字切れや重なりはスクリーンショットを目視確認し、「要素が存在する」ことだけをリリース可の根拠にしないでください。
最後に、最も重要なユーザーの操作経路を手動で一通り確認します。文字を大きくした状態で説明を最後まで読み、主ボタンを見つけ、操作を完了して戻ります。テストの目的は、どの文字サイズでも同じスクリーンショットを得ることではありません。サポートするすべてのサイズで、内容を最後まで読めて、必要な操作を完了できるようにすることです。
よくある質問
最大の文字サイズだけを試せば十分ですか?
十分ではありません。標準、大きめ、サポート対象の最大サイズを確認してください。途中のサイズだけで改行による重なりが起きる場合もあります。
UIテストで要素が見つかれば合格ですか?
いいえ。重要な操作が可能か、スクロールして到達できるかも確認し、失敗時の画面を画像で調べます。
次のビルドは専有クラウドMacにお任せください。
ViewMiniの機種、リージョン、利用期間を確認し、ワークフローに合った専有物理ノードを設定しましょう。