回答:
最も正確でなければなりません。
真剣に、ホワイトボックステスト（つまり、コードの内部をテストする）は、コードを書いた開発者による単体テストで行うのが理想的です。ユニットテストは時間の経過とともにビルドされ、ビルドプロセスの一部となるため、正しく動作しないことがわかっているコードで貧弱なテスターの時間を無駄にすることはありません。ユニットテストは、チームが小さいほど重要になります。特に、問題を解決するためのテスターの軍隊がないためです。
通常、ブラックボックステスト（つまり、ユーザー/システムインターフェイスを介したテスト）は、ほとんどのテスターが行うことです。
すべてのテストでは、完成品にとって機能がどれほど重要であるかを優先する必要があります。Xを実行するツールを提供することがミッションであり、製品がXを実行しない場合、それは大きな問題です。
機能を検証するためのブラックボックステスト。破損した場合は、必要に応じてホワイトボックステストを実施します。すべてのブラックボックステストに合格し、カバレッジが良好であれば、ホワイトボックステストは不要です。
ブラックボックス。
通常、ホワイトボックスコンポーネントはブラックボックスコンポーネントに依存しているため、まずブラックボックスをテストしてから、ホワイトボックスに移動します。
良いテストサイクルが必要な場合は、両方を実行する別の人が必要です。
ホワイトボックステストに主に焦点を当てた開発者は、最近のコードの変更点、より複雑な（したがって壊れる可能性のある）領域などを知っており、新しい欠陥を引き起こす可能性が最も高いこれらの領域に適切に努力を集中できます。
一方、ブラックボックステストに重点を置いたQAテスターは、エンドユーザーのようなテストにより簡単にアプローチできます。コードの内部知識がなくても、新しいアプローチをとることができ、ソリューションのさまざまな部分がどのように実装されているかという知識に偏ることはありません。開発者が見落としていたバグや、アプリケーションの他の領域を誤って壊してしまったコード変更からの退行をキャッチします。
質問に答えるには、まずホワイトボックステストを実行する必要があります。ただし、効果的にするためには、ブラックボックステストを別の人に依頼する必要があります。
私が言うブラックボックスがとにかく存在テストは、コード（またはボックス）の前に書かれている、という理由だけTDDの提唱者として、最初のテスト:)
ホワイトボックステスト（私が理解している限り）は、デバッグの考え方においてより有用です。
コードが存在する前にテストを作成しているため、ブラックボックステスト。テスターは、小さなチームで効率的に作業するために、コードを記述する開発者と並行して、時間のかかる自動テストを開発する必要があります。
コードが既に作成されている場合、ブラックボックスの観点からテストカバレッジをスケッチして、実際のコードで脳を混乱させる前にブレインストーミングを行う時間を確保することをお勧めします。ただし、ホワイトボックスに切り替えてコードを見てから実際のテストをやりすぎて、危険な領域を感じ取り、先にブレインストーミングしたテストに優先順位を付けることができます複雑または疑わしいと思われるコードの部分を見てください）。
どちらでもない。Right BICEPを使用して、正しい順序に関係なく、正しい境界条件を念頭に置いて、適切なテストを記述しようとしています。これらはどちらも実用的な単体テストで提案されている頭字語です。
私の目標は、最初にどの色を書くかではなく、良いテストを書くことに集中することです。
最初にホワイトボックステストを行います。
ブラックボックステストの2番目に進みます。
>ブラックボックステスト
I.テスターは、テキストボックス、ラジオボタン、リストボックス、コマンドボタンなど、アプリケーションの機能をチェックする必要があります。
II。テスターは、ロゴ、画像、スペルなど、アプリケーションの非機能性をチェックする必要があります。
III。テスターは、アプリケーションのフロー全体をチェックする必要があります。
注：ポジティブおよびネガティブ条件を確認するには。