単体テスト フレームワーク ツールは、単体テストの作成、実行、レポートをサポートするツールです。単体テストとは、ソース コード内の個々のソフトウェア コンポーネント (関数やメソッドなど) の機能と品質を検証するテストです。単体テスト フレームワーク ツールは、テスト ケースの生成、テスト ケースの実行、テスト結果の比較、テスト カバレッジの測定などの機能を提供することで、ソース コード内の関数またはメソッドの欠陥を検出するのに役立ちます。単体テスト フレームワーク ツールの例としては、JUnit、 NUnit、TestNG など。他のオプションは、ソース コード内の関数やメソッドの欠陥を検出する可能性のあるツールではありません。構成管理ツールは、ソフトウェア製品またはコンポーネントのさまざまなバージョンやバリアントの管理と制御をサポートするツールです。テスト設計ツールは、いくつかの基準またはルールに基づいてテスト ケースの設計と生成をサポートするツールです。監視ツールは、テスト対象のシステムまたはコンポーネントの動作またはパフォーマンスを監視するツールです。検証済みの参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、10 ページ。

レビューに関する次の記述は真実です。
* I) ウォークスルーでは、通常、レビュー ミーティングは著者が主導します。ウォークスルーは、事前に定義された目的と議題はあるものの、正式なプロセスや役割を持たないレビューの一種です。ウォークスルーは通常、レビュー対象の成果物の作成者によって主導され、参加者をシナリオに沿ってガイドし、フィードバックを求めます。
* IV) 経営陣が技術検討会議に参加することはほとんどありません。技術レビューは、事前に定義された目的と議題はあるものの、正式なプロセスや役割を持たないタイプのレビューです。技術レビューは通常、成果物の技術的側面を評価するために、技術的専門知識を持つ同僚によって実行されます。
経営陣は効果的に貢献するのに十分な技術的知識やスキルを持っていない可能性があるため、技術レビュー会議に参加することはほとんどありません。レビューに関する次の記述は誤りです。
* II) 検査は、無制限の検討会議を特徴としています。検査は、正式な開始基準と終了基準、参加者の役割と責任を伴う、定義されたプロセスに従う一種のレビューです。検査は、期間と議題が固定された構造化されたレビュー会議によって特徴付けられます。
※Ⅲ）検討会前の準備は非公式検討の一部です。レビュー会議前の準備は、検査や技術レビューなどの正式なレビューの一部です。準備にはチェックが含まれます

ブランチ カバレッジは、テスト ケースによって実行されるブランチまたは意思決定結果の割合を測定する構造カバレッジ メトリックの一種です。分岐とは、制御フローが条件に基づいて 2 つ以上の代替パスを取ることができるコード内のポイントです。たとえば、if-else ステートメントは、条件の評価に応じて if-ブロックまたは else ブロックのいずれかを実行できる分岐です。ブランチ カバレッジにより、テスト ケースで各ブランチが少なくとも 1 回選択されることが保証されるため、さまざまなシナリオでのソフトウェアの動作が明らかになります。ブランチ カバレッジは、ディシジョン カバレッジまたはオールエッジ カバレッジとも呼ばれます。
ブランチ カバレッジは、アクションを決定する条件の考えられるすべての結果をテスト ケースがカバーしていることを検証できるため、特定のアクションが許可されないケースをテストするのに適しています。たとえば、プログラムに製造ステージを停止できるかどうかをチェックする条件がある場合、分岐カバレッジにより、ステージを停止できるケースと停止できないケースの両方をテスト ケースで確実にカバーできます。
このように、ブランチ カバレッジは、望ましくないアクションや安全でないアクションにつながる可能性のある、欠落しているブランチや間違ったブランチを特定するのに役立ちます。
他のオプションは、特定のアクションが許可されないケースのテストには適していないため、不正解です。コード カバレッジは、ステートメント カバレッジ、ブランチ カバレッジ、データ フロー カバレッジなど、さまざまなタイプのカバレッジ メトリックを含む一般的な用語です。コード カバレッジでは、分析にどのタイプのカバレッジ メトリックが使用されるかは指定されません。データ フロー カバレッジは、テスト ケースによって実行されるデータ フロー パスの割合を測定する構造カバレッジ メトリックの一種です。データ フロー パスは、変数を定義、使用、または強制終了する一連のステートメントです。データ フロー カバレッジは、ソフトウェアでのデータ操作の正確性と完全性をテストする場合には役立ちますが、アクションを決定する条件をテストする場合には役立ちません。ステートメント カバレッジは、テスト ケースによって実行されるステートメントまたはコード行の割合を測定する構造カバレッジ メトリックの一種です。ステートメント カバレッジにより、各ステートメントがテスト ケースによって少なくとも 1 回実行されることが保証されますが、さまざまなシナリオでのソフトウェアの動作は明らかにされません。
ステートメント カバレッジは、コード内の分岐や意思決定の結果を考慮していないため、ブランチ カバレッジよりも弱い基準となります。参考文献 = ISTQB Certified Tester Foundation Level (CTFL) v4.0 シラバス、第 4 章: テスト技術、セクション 4.3: 構造テスト技術、51 ～ 54 ページ。

終了基準は、テスト アクティビティがいつ完了するか、またはテスト フェーズをいつ終了できるかを定義する条件です。終了基準は、次のようなさまざまな要因に基づくことができます。
I) 欠陥密度または信頼性尺度の推定。これらは、ソフトウェア製品にどれだけの欠陥が存在するか、または特定の条件下でソフトウェア製品が失敗する可能性がどれくらいあるかを示す定量的な尺度です。これらは、次のフェーズに進む前、または顧客にリリースする前に、ソフトウェア製品が一定の品質またはパフォーマンスのレベルを満たしていることを確認するための終了基準として使用できます。
III) コードカバレッジ、機能カバレッジ、リスクカバレッジなどの精度測定。これらは、コード、機能、またはリスクの観点から、ソフトウェア製品のどの程度がテストされたかを示す定量的な尺度です。これらは、次のフェーズに進む前、または顧客にリリースする前に、テスト スイートが適切または完全であることを確認するための終了基準として使用できます。
IV) 特定の領域でのコード カバレッジの欠如、未解決の欠陥、未知の要因などの残留リスク。これらは、テスト後にソフトウェア製品に関連する残りのリスクまたは不確実性を示す定性的な尺度です。これらは、次のフェーズに移行する前、または顧客にリスクをリリースする前に、残存リスクが許容可能または管理可能であることを確認するための終了基準として使用できます。次の要因は有効な終了基準ではありません。
II) 徹底的なテストレポートの完成と発行。これはテストプロセスや製品の品質や完全性を反映していないため、有効な終了基準ではありません。テスト レポートは、テスト アクティビティまたはフェーズの結果と成果を要約した文書です。テスト レポートは、テスト アクティビティまたはフェーズを終了するかどうかを決定するための入力として使用できますが、いつ終了するかを定義する条件ではありません。検証済み参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、第 2 章、13 ページ。第 6 章、58 ～ 59 ページ。

ステートメント B は、テストの一般原則に矛盾します。テスト結果に影響を与えるシステムまたは環境の変更がない限り、同じテスト セットをより頻繁に実行しても、新しい欠陥が見つかる可能性は増加しません。異なる入力、出力、または条件を使用して異なるテスト セットを実行すると、新しい欠陥を見つけるのがより効果的になります。ステートメント A、C、および D はテストの一般原則と一致しています。ステートメント A は、ほとんどの欠陥はシステムのモジュールの小さなサブセットで見つかると述べていますが、これは欠陥クラスタリングの原則によれば真実です。ステートメント C では、プロジェクトの開始時にテストを開始する方が効果的であると述べていますが、これは初期テストの原則に従うと当てはまります。ステートメント D では、テストがどのように行われるかは特定のプロジェクトの状況に基づいていると述べており、これはコンテキスト依存のテスト原則に従うと当てはまります。検証済み参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、4 ～ 6 ページ。