利益:
- テストピラミッドに従って人工知能を使用して単体テスト、統合テスト、UIテストを作成し、限界やエラーの状況や満足のいくシナリオをカバーする能力
- 生成された各テストが実際に動作を検証していることを確認することで、空の/無駄なテストや肥大化したカバレッジを排除する機能
- コードが何をすべきかを AI に指示することで、テストがバグを確実にキャッチし、バグの修正を防ぐ
コードを書くことが仕事の半分です。コードが正しく動作することを証明するのが残りの半分です。モバイル アプリは、何百もの異なるデバイス、画面サイズ、オペレーティング システムのバージョン、ユーザーの行動に遭遇します。これらすべてを手動でテストすることは不可能です。そのため、自動テスト (コード テスト コード、つまり人間によるクリックなしで実行されるテスト) がモバイル品質のバックボーンとなっています。 AI は、テストの作成において驚くほど効率的です。テストの作成は、特定の入力に対する特定の動作を検証するという、まさに AI が好むパターン作業であるためです。この単元では、単体テスト、インターフェイス テスト、AI による自動化を加速し、人間の目を通してテストの品質を確保する方法を学びます。
テストピラミッド: 何をどれだけテストするか
健全なテスト戦略はピラミッドに似ています。基本には、多数の単体テスト (単一の関数またはクラスを分離してテストするクイック テスト) が含まれています。彼らは速くて安いです。中間には、統合テスト (複数の部分がどのように連携して動作するかテスト) が含まれていません。上部には最小限の UI/エンドツーエンドのテストがあります (テストはユーザーと同じように画面をクリックして行われます)。それらは現実的ですが、遅くて壊れやすいです。 AI はあらゆる層で役に立ちますが、最も価値があるのはベースにあり、ビジネス ロジックの単体テストを迅速に作成することです。
テストの種類
範囲
速度
AIの効率化
単体テスト
単一の関数/クラス
とても速い
非常に高い
統合
中間層
中程度
高い
UI / エンドツーエンド
全画面ストリーム
遅い
中（壊れやすい）
ヒント: AI に「この関数のテストを生成する」ように指示する場合は、空の入力、NULL、負の数、非常に大きな値、ネットワーク エラーなどのエッジ ケースを明示的に要求します。 AIが幸せな道を簡単に生成します。本当の間違いは境界線に隠れており、そこにあることを望まない場合は飛び出してきます。
AI を使用してテストを作成する手順
- テストする動作を定義します。 「この関数はこの入力にこの出力を与える必要があります。」
- フレームワークを指定します。 Android では JUnit + MockK、iOS では XCTest、UI には Espresso (Android) または XCUITest (iOS)。
- 限界状態を尋ねます。満足のいくシナリオ + エラー + ブレークポイント。
- モックオブジェクトを管理します。ネットワークやデータベースなどの外部依存関係はテスト用にエミュレートされます (モック - 実際のサービスの代わりに制御されたモック)。
- テストを実行して確認します。テストは合格しましたか?本当に意味のあることが確認されましたか?
5 番目のステップが重要です。 AI は、「常に合格する」役に立たないテストを作成することがあります。たとえば、何も検証しないテストや、独自の偽データをチェックするテストなどです。合格するテストと価値のあるテストは別のものです。
注意: AI が生成できるからといって、テストが正しいとは限りません。場合によっては、AI はコードの現在の (おそらく欠陥のある) 動作を「正しい」ものとして受け入れ、それに応じてテストを作成します。このようなテストでは、バグを発見するのではなく、バグを修正します。テストで何を期待するかを決めるのはあなたです。コードが何をするかではなく、AI が何をすべきかを指示します。
テストカバレッジの測定と誤謬
テスト カバレッジ (テストによって実行されるコードの割合) は便利ですが、誤解を招きやすい指標です。カバレッジ 90% は、コードの 90% が実行されたことを示します。ただし、これらの回線が正しく動作するかどうかは確認されていません。行を実行して結果をチェックしないテストはスコープを拡張しますが、セキュリティは提供されません。目標は高い数値ではなく、意味のある検証です。 AI を使用するとすぐにスケールアップできますが、各テストが実際に動作をテストしていることを確認してください。
ミニケース3個
ケース 1 — 国境状況が把握されました。 AIは銀行アプリケーションの送金機能のテストを依頼され、具体的には「マイナス金額」と「残高超過」のシナリオが追加された。テストの結果、マイナスの金額では転送がブロックされないことが判明しました。これは実稼働環境における重大なセキュリティ脆弱性となります。 1 行のコントロールを追加して閉じます。教訓: 境界テストは最も価値のあるテストです。
ケース 2 — 偽のテスト。あるチームは、AI によって生成された 40 個の単体テストでカバレッジを 85% まで高めることができ、安心しました。検査中に、ほとんどのテストは実際には出力を検証しておらず、関数を呼び出してassertTrue(true)を書き込んだだけであることがわかりました。カバレッジは高かったが、保護はゼロだった。テストは徹底的に見直され、実際の検証によって書き直されました。教訓: カバレッジの数字は嘘をつく可能性があります。
ケース 3 — UI テストを加速します。電子商取引チームは、AI を使用してカートに追加するフローの XCUITest スクリプトを 20 分で作成しました。手書きだと半日くらいかかります。 AI が画面要素の識別子を推測しました。チームはそれらを実際のコードと照合して修正しました。ドラフトの速度は実際のものですが、識別子の検証は人間の作業です。
弱いプロンプト / 強いプロンプト
弱いプロンプト: 「この関数のテストを作成してください。」
強力なプロンプト: 「JUnit5 + MockK を使用して、この Kotlin 関数の単体テストを作成します。関数: 送金 (金額、ソース、ターゲット)。テストする動作 (コードが行うべきこと):- 有効な送金が成功する必要があります。- 負の金額またはゼロの金額は拒否される必要があります。- 残高を超える金額は拒否される必要があります。- ネットワーク エラーは、適切な例外をスローする必要があります。各テストは 1 つのことのみを検証する必要があります。テスト名は説明的である必要があり、外部サービスを模擬する必要があります。空のアサーションを作成しないでください。」
コピー可能なテンプレート
単体テスト テンプレート: 「[言語] のこの関数の [JUnit/XCTest] 単体テストを生成します。期待される動作: [何をするか]。含まれるもの: 満足のいくシナリオ、null 入力、ブレークポイント、エラー ケース。各テストで単一の動作を検証します。意味のあるアサーションを使用します。モック。[コード]」
UI テスト テンプレート: 「[Espresso/XCUITest] を使用して次のフローの UI テストを作成します: [ユーザー フロー ステップ バイ ステップ]。アクセシビリティ ID を持つ画面要素を選択し、テキストの代わりに ID を使用します。待機戦略を追加します。要素 ID を実際のコードと一致させるよう通知します。」
テスト監査テンプレート:「これらのテストを調べます:1) 出力/動作を実際に検証しますか? それとも null ですか?2) 限界ケースをカバーしますか?3) コードのバグを修正しますか、それとも正しい動作が期待されますか?弱いテストにフラグを立てて強化します。[テスト]」
カバレッジ最適化テンプレート: 「このクラスのテストされていない部分を特定し、意味のあるテストを提案します。カバレッジの数だけでなく、実際のリスクのあるパスに優先順位を付けます。[コード]」
よくある間違い
- 幸せなシナリオをテストしているだけです。エラーは限界状態に保存されます。率直に尋ねてください。
- 空の/役に立たないテストを受け入れる。 assertTrue(true) タイプのテストはスコープを拡張し、保護を提供しません。
- コードが何をしているのかをAIに検証させる。テストではコードが何をすべきかを予測する必要があります。それ以外の場合はバグが修正されます。
- スコープ番号を目的と間違えています。 90% のカバー率は 90% の精度を意味するものではありません。
- UI テストでのテキストへのリンク。テキストが変更されるとテストは中断されます。安定した識別子 (id) を使用します。
- モックの設定が間違っている。実際のサービスを呼び出す「単体テスト」は遅くて脆弱になります。
要約すれば
テストはモバイル品質の根幹であり、AI はこの分野、特に単体テストにおいて非常に効率的です。テスト ピラミッドに従ってください: 多くのユニット、中程度の統合、小さな UI テスト。 AI に明示的に幸せなシナリオを要求し、ケースとエラー パスを制限します。生成された各テストが実際に動作を検証していることを確認してください。空のテストや誇張された適用範囲は誤解を招きます。最も重要なことは、コードが何をするかではなく、コードが何をすべきかを AI に伝えることです。そうすることで、テストはバグを修正するのではなく、バグをキャッチします。
アプリケーションタスク
ビジネス ロジック機能 (割引計算やフォーム検証など) の「単体テスト テンプレート」を使用して AI にテストをリクエストし、制限ケース (NULL、負、大きすぎる) を明示的に指定します。生成されたテストを実行し、「テスト監査テンプレート」を使用して同じテストを監査します。少なくとも 1 つの弱いテストを見つけて強化し、(小さなバグを追加して) テストが関数の実際のエラーを検出するかどうかをテストします。
チェックリスト
- [ ] テストピラミッド (優先ユニット) に適切なレイヤーを選択しました
- [ ] ハッピーシナリオ以外に制限とエラーのケースが欲しかった
- [ ] 各テストに意味のあるアサーションが含まれていることを確認しました
- [ ] 私は AI に、コードが何をするかではなく、コードが何をすべきかを伝えました
- [ ] 補償範囲の数ではなく、実際のリスク経路に焦点を当てました
- [ ] UI テストで安定した識別子を使用しましたが、テキストにバインドしませんでした