構造テストは、テストによって実行されたコード行を追跡することでテストの有効性を測定するテストの一種です。ホワイトボックステストまたはグラスボックステストとも呼ばれる構造テストは、ソフトウェアの内部構造、設計、または実装に基づいています。構造テストの目的は、コードパス、分岐、ステートメント、条件、またはデータフローを実行することで、ソフトウェアがパフォーマンス、セキュリティ、信頼性、保守性などの指定された品質特性を満たしていることを確認することです。構造テストでは、関数カバレッジ、行カバレッジ、分岐カバレッジ、ステートメントカバレッジなどのさまざまなカバレッジ指標を使用して、コードのどの程度がテストされているかを判断し、テストされていない部分や到達不可能な部分を特定します。構造テストは、単体テスト、統合テスト、システムテスト、受け入れテストなど、あらゆるレベルのテストに適用できますが、テスターがソースコードにアクセスできる下位レベルでより一般的に使用されます。
その他の選択肢は正しくありません。なぜなら、テストによって実行されたコード行を追跡することで有効性を測定するタイプのテストではないからです。受け入れテストは、ソフトウェアが受け入れ基準とユーザー要件を満たしていることを確認するテストの一種です。受け入れテストは通常​​、エンドユーザーまたは顧客によって実行されますが、彼らはソフトウェアのソースコードや技術的な詳細にアクセスできない場合があります。受け入れテストは、ソフトウェアの内部構造や実装よりも、ソフトウェアの機能性、ユーザビリティ、適合性を重視します。統合テストは、ソフトウェアコンポーネントまたはサブシステムが期待どおりに連携して動作することを確認するテストの一種です。統合テストは通常​​、開発者またはテスト担当者によって実行され、コンポーネントまたはサブシステム間のインターフェース、相互作用、依存関係を確認するために、構造テストと機能テストの両方の手法が使用される場合があります。統合テストは、個々のコード行よりも、ソフトウェアの統合ロジック、データフロー、または通信を重視します。探索的テストは、同時学習、テスト設計、およびテスト実行を伴うテストの一種です。探索的テストは通常​​、テスト担当者によって実行されます。テスト担当者は創造性、直感、経験を駆使してソフトウェアを探索し、欠陥、リスク、改善の機会を発見します。探索的テストは、ソフトウェアの内部構造や実装よりも、ソフトウェアの動作、品質、価値に重点を置いています。参考資料：ISTQB Certified Tester Foundation Level (CTFL) v4.0 シラバス、第4章「テスト技法」、セクション4.3「構造的テスト技法」、51～54ページ、第1章「テストの基礎」、セクション1.4「ソフトウェア開発ライフサイクル全体にわたるテスト」、11～13ページ、第3章「静的テスト」、セクション3.4「探索的テスト」、40～41ページ。

非機能テストとは、ソフトウェアの特定の動作や機能に関係せず、パフォーマンス、ユーザビリティ、信頼性などの属性に関係する側面をテストすることを指します。ファイルの保存にかかる時間を捕捉するテストは、システムのパフォーマンスに直接関係するため、非機能テストに分類されます。
参考資料:ISTQB 認定テスター基礎レベル シラバス v4.0、セクション 1.2.5「機能テストと非機能テスト」。

包括的かつ詳細な解説：テスト計画とは、テストプロセスの範囲、目的、スケジュール、リソース、リスクを概説した管理文書です。予算とスケジュール（A）は、リソースとタイムラインの制約を計画する上で不可欠な要素です。
* (B) は不正解です。欠陥分析はテスト計画の一部ではなく、テスト概要レポートの一部だからです。
* (C) は、最終レポートは実行の概要を示しますが、テスト計画はテストが開始される前に作成されるため、正しくありません。
* (D) は不正解です。テスト ログは計画要素ではなく実行成果物だからです。
テスト計画はテスト活動をガイドし、プロジェクトの目標との整合性を確保します。

ISTQB の基礎テストプロセスは、ISTQB Foundation Level シラバス、バージョン 4.0、2018、セクション 2.2、15 ページに記載されているように、5 つの主要なフェーズで構成されています。
* テストの計画と制御: このフェーズでは、テストの目的、範囲、戦略、リソース、スケジュール、リスク、およびメトリックの定義、およびテスト プロセス全体にわたるテスト アクティビティと結果の監視と制御が行われます。
* テスト分析と設計：このフェーズでは、テストベース（要件、仕様、ユーザーストーリーなど）を分析し、テストが必要なテスト条件（機能、機能、シナリオなど）を特定し、テスト条件をカバーするテストケースとテスト手順（入力、期待される結果、実行手順など）を設計します。また、テストベースとテスト項目（ソフトウェアやシステムコンポーネントなど）のテスト可能性を評価し、テスト目標の達成とテストカバレッジおよび効率の最適化を図るためのテスト手法（同値分割、境界値分析、状態遷移テストなど）を選択して実装します。
* テストの実装と実行：このフェーズでは、テスト実行のためのテスト環境（ハードウェア、ソフトウェア、データ、ツールなど）とテストウェア（テストケース、テスト手順、テストデータ、テストスクリプトなど）を準備し、テスト計画とスケジュールに従ってテスト手順またはスクリプトを実行します。また、テスト実行結果のログ記録、実際の結果と期待結果の比較、そして差異をインシデント（欠陥、エラー、故障など）として報告することも含まれます。
* 終了基準の評価と報告：このフェーズでは、計画されたテスト活動が完了し、終了基準（品質、カバレッジ、リスクレベルなど）が満たされているかどうかを確認し、テスト結果と成果を関係者に報告します。また、テスト結果と成果に基づいてリリースまたは受け入れの決定に関する推奨事項を作成し、対処または軽減が必要な残存リスク（既知の欠陥や未テスト領域など）を特定します。
* テスト終了活動：このフェーズでは、テストウェアとテスト環境を将来の再利用のために完成させてアーカイブ化し、テスト目標とテスト計画に照らしてテストプロセスとテストプロジェクトを評価します。また、得られた教訓やベストプラクティスを特定し、その結果と改善提案を関係者に伝達します。
参考資料 = ISTQB 認定テスター基礎レベル シラバス、バージョン 4.0、2018 年、セクション 2.2、15 ページ; ISTQB テスト用語集、バージョン 4.0、2018 年、37 ～ 38 ページ; ISTQB CTFL 4.0 - サンプル試験 - 解答、バージョン 1.1、2023 年、質問 88、32 ページ。

包括的かつ詳細な説明：
テストとデバッグは別個の活動ですが、関連性があります。テストはソフトウェアを実行し、欠陥（A）に起因する障害を特定します。デバッグは開発者の責任であり、障害（欠陥）の原因を特定し、分析し、修正することが含まれます。ISTQBシラバスでは、これらの活動を明確に区別しています。テストはソフトウェアを変更しませんが、デバッグは変更します。