ブラックボックスまたはホワイトボックスのテストはテスターにとって重要ですか？
どのタイプのテストを強調する必要がありますか（テスター/ QAにとって）、なぜですか？
ウィキペディアの定義のクイックセット：
ブラックボックステスト
- テストオブジェクトの外部の視点を使用して、テストケースを導き出します。これらのテストは、通常は機能しますが、機能する場合と機能しない場合があります。テスト設計者は、有効な入力と無効な入力を選択し、正しい出力を決定します。テストオブジェクトの内部構造に関する知識はありません。
ホワイトボックステスト
- システムの内部的な観点を使用して、内部構造に基づいてテストケースを設計します。ソフトウェアを通るすべてのパスを識別するには、プログラミングスキルが必要です。テスターは、テストケースの入力を選択して、コードを介してパスを実行し、適切な出力を決定します。電気ハードウェアテストでは、回路内のすべてのノードをプローブして測定できます。例は、インサーキットテスト（ICT）です。
もう少し明確にするために、両方が重要であることに気づきましたが、通常は、devとQAの間で分離されています。
テスター/ QAにとって内部知識は重要ですか？この知識を念頭に置いてテストすることで問題をより適切にテストできるという議論を聞いたことがありますが、この知識は機能的なニーズをそらし、意図したソリューションよりも「コードに対するテスト」を促進できるという議論も耳にしました。
- ブラックボックステストは、テスター/ QAにとって重要です。
- ホワイトボックステストは、開発者にとって重要なものです（つまり、単体テスト）。
- この質問に答えた他の人々は、質問をと解釈したようです。これはより重要で、ホワイトボックステストまたはブラックボックステストです。私も、それらは両方とも重要であると信じていますが、これをチェックアウトすることをお勧めします IEEE記事 ホワイトボックステストがより重要であると主張しています。
ホワイトボックステストは、ソフトウェアユニットテストに相当します。開発者または開発レベルのテスター（別の開発者など）は、システムに統合する前に、詳細レベルの要件に従って、自分が書いたコードが適切に機能していることを確認します。
ブラックボックステストは統合テストに相当します。テスターは、システムが機能レベルの要件に従って動作することを確認します。
私の意見では、両方のテストアプローチは同様に重要です。
徹底的な単体テストは、ソフトウェアがシステムに統合された後ではなく、開発段階で欠陥を検出します。システムレベルのブラックボックステストでは、すべてのソフトウェアモジュールが統合されたときに正しく動作することを確認します。通常、モジュールは互いに独立して開発されるため、開発段階の単体テストではこれらの欠陥を検出できません。
ブラックボックス
1システムの機能に焦点を当てるシステムの構造（プログラム）に焦点を当てる
2使用されるテクニックは次のとおりです。
・等価パーティション
・境界値分析
・推測エラー
・競合状態
・原因と結果のグラフ化
・構文テスト
・状態遷移テスト
・グラフマトリックス
テスターは技術的ではない場合があります
機能仕様のあいまいさと矛盾を識別するのに役立ちます
ホワイトボックス
使用される手法は次のとおりです。
・ベーシスパステスト
・フローグラフ表記
・制御構造のテスト
条件テスト
データフローテスト
・ループテスト
単純なループ
入れ子ループ
連結ループ
非構造化ループ
テスターは技術的であるべき
論理的およびコーディングの問題を識別するのに役立ちます。
QAはブラックボックステストに焦点を当てる必要があります。 QAの主な目標は、システムの機能をテストすることではなく、機能が要件を満たしているかをテストすることです。
とにかく、QAのほとんどは技術者ではないため、QAがホワイトボックステストを行うのは難しいはずです。そのため、通常、ユーザー（ユーザーなど）を通じて機能をテストします。
さらに一歩、開発者もブラックボックステストに焦点を当てるべきだと思います。ユニットテストとホワイトボックステストの間のこの広範囲にわたる関連性には同意しませんが、それは単なる語彙/規模の問題かもしれません。単体テストの規模では、テスト対象システムは（署名を介して）コントラクトを持つクラス/メソッドであり、重要なポイントはテストすることです方法ではなく、それが何をするか。さらに、ホワイトボックステストは、メソッドがその契約を満たす方法を知っていることを意味します。これは、TDDとは相性が悪いようです。
SHOが非常に複雑で、ホワイトボックステストを行う必要がある場合は、通常、リファクタリングの時間です。
「両方」は上記で述べられており、明らかな答えです...しかし、IMO、ホワイトボックステストは開発者ユニットテストをはるかに超えています（ただし、白と黒の間の線を引く場所に依存するかもしれませんが）。たとえば、コードカバレッジ分析は一般的なホワイトボックスアプローチです。つまり、いくつかのシナリオまたはテストを実行し、テストで穴を探して結果を調べます。単体テストのccが100％であっても、一般的なユーザーシナリオでccを測定すると、さらにテストが必要になる可能性のあるコードが明らかになる可能性があります。
ホワイトボックステストが役立つもう1つの場所は、データ型、定数、その他の情報を調べて境界、特別な値などを探すことです。たとえば、アプリケーションに数値入力を取る入力がある場合、bbのみのアプローチではテスターがどの値がテストに適しているかを「推測」しますが、wbアプローチでは、1〜256の値はすべて一方向に処理され、大きな値は別の方法で処理されます。 。
したがって、元の質問に答えるには、bbとwbの両方が良いテストのために不可欠です。
私の経験では、ほとんどの開発者は自然にホワイトボックステストに移行します。基になるアルゴリズムが「正しい」ことを確認する必要があるため、内部に重点を置く傾向があります。しかし、指摘されているように、ホワイトボックステストとブラックボックステストの両方が重要です。
そのため、ほとんどの開発者が実際にそれを行わず、頻繁にそれが得意ではないという事実をカバーするために、テスターにブラックボックステストにもっと焦点を合わせることを好みます。
それは、システムがどのように機能するかについてテスターを暗闇に置いておくべきだということではなく、関数SomeMethod（int x） xが5の場合、正しく例外がスローされます。
それは少し開いたドアですが、最終的には両方がほぼ同様に重要です。
何が悪いの？
必要なことを行うが、内部的に問題があるソフトウェア
ソースを見れば動作するはずのソフトウェアですが、動作しませんか？
私の答え：どちらもまったく受け入れられませんが、ソフトウェアが100％バグがないことを証明することはできません。そのため、いくつかのトレードオフを行う必要があります。オプション2はクライアントにより直接的に認識されるため、より早く問題が発生します。長い目で見れば、オプション1には問題があります。
通常、テスターはホワイトボックステストを実行できません。したがって、テスターにとって実行可能な唯一の答えは、ブラックボックスアプローチを強調することです。
ただし、アスペクト指向プログラミングおよび設計による契約の方法論では、テストの目標が契約としてターゲットコードにプログラムされている場合（プログラムの静的ビューから見た場合）、および/またはテスト時相論理がプログラムされている場合クロスカットとしてのコード（テストロジックの動的なビュー）、ホワイトボックステストは可能になるだけでなく、テスターにとっても好まれます。そうは言っても、それは専門家に要求されるテイクである必要があり、テスターは優秀なテスターだけでなく、優秀なプログラマーまたは優秀なプログラマー以上である必要があります。
ブラックボックステスト：ブラックボックステストは、ソフトウェア製品の内部的な知識や構造を必要としない観察です。有効なデータと無効なデータを入力し、正しい結果を期待するだけです。テスターは欠陥を見つけましたが、すべてのテストレベルで行われた不良の場所を見つけることができません。
ブラックボックステストの手法は次のとおりです。
ホワイトボックステスト：ホワイトボックスのテストでは、ソフトウェア製品の内部ロジックと構造の知識が必要です。ここでは、ループ、条件、および分岐を確認します。ここでは、欠陥だけでなく、欠陥の場所も見つけます。
ホワイトボックステスト手法：1.ステートメントカバレッジ2.決定カバレッジ3.ブランチカバレッジ4.パスカバレッジ。
ブラックボックステストは、テスト対象のアイテムの内部構造/設計/実装がテスターにわからないソフトウェアテスト方法です。ホワイトボックステストは、テスト対象のアイテムの内部構造/設計/実装がテスターに知られているソフトウェアテスト方法です。
これが私の5セントです。
開発者として、ほとんどの場合、メソッドのテストを（クラス内で）ホワイトボックステストとして記述します。これは、コードの内部動作を変更するだけでテストを中断させたくないためです。
メソッドの動作が変更された場合（たとえば、以前とは異なる結果が返された場合）にのみテストを中断します。
過去20年間の開発では、ユニットテストがコードに強く結び付いていて、アプリケーションコードとテストコードの両方を維持する必要があるため、単純に最大2倍の作業にうんざりしていました。
（テストをコーディングするときにも）コードを分離することは非常に良い習慣だと思います。
別の5セント：モックフレームワークを使用することはほとんどありません。何かをモックする必要があることがわかったときは、代わりにコードを分離することを好みます。 ）
「内部の知識」を構成するものは何ですか？そのようなアルゴリズムが問題を解決するために使用されたことを知っていることは資格がありますか、またはテスターは「内部」であるためにコードのすべての行を見る必要がありますか？
どのテストケースでも、使用された仕様によって期待される結果があるはずであり、テスターが仕様を解釈する方法によって決定されるのではなく、それぞれが正しいと考え、問題を他の人のせいにする問題につながる可能性があるはずです。
- *ブラックボックステスト：システムレベルでのテストで、システムの機能を確認し、システムが設計されたすべての機能を実行することを確認します。主にユーザーポイントで見つかった欠陥を発見します。システムをブラックボックス化するプロのテスターを雇う方が良いでしょう」 「誰かを怒らせるつもりはない」）
- ホワイトボックスは、SDLCで行われる最初のテストです。これは、ランタイムエラーやコンパイルエラーなどのバグを発見するためです。彼は他の人よりもそれらを理解しています。*
*ブラックボックステスト：ソースコードが利用できない場合、テストデータは、実装方法に関係なく、ソフトウェアの機能に基づいています。 -strong textブラックボックステストの例：境界値テストと等価分割。
*ホワイトボックステスト：テスト対象システムのソースコードが利用可能な場合、テストデータはこのソースコードの構造に基づきます。 -ホワイトボックステストの例：パステストおよびデータフローテスト。
この質問に対する最高評価の回答に部分的に同意します。どのタイプのテストを強調する必要がありますか（テスター/ QAにとって）、なぜですか？
- 「ブラックボックステストはテスター/ QAにとって重要であるべきです」と私は同意します。
- ホワイトボックステストは開発者にとって強調すべきであることに同意しますが、ホワイトボックステストが単なる単体テストであることには同意しません。
定義に同意します ここ ホワイトボックステスト方法は、次のレベルのソフトウェアテストに適用可能であると述べています。
- ユニットテスト：ユニット内のパスをテストするため
- 統合テスト：ユニット間のパスのテスト用
- システムテスト：サブシステム間のパスのテスト用
シンプル...ブラックボックステストは、統合テストまたはスモークスクリーンテストとも呼ばれます。これは主に、イベント駆動型アーキテクチャに依存する分散環境で適用されます。別のサービスに基づいてサービスをテストし、考えられるすべてのシナリオを確認します。 SOA/Enterpriseアプリの各コンポーネントは自律的に機能することを意図しているため、ここではすべての可能な出力を完全に予測することはできません。これは、高レベルテストと呼ばれます。
ながら
ホワイトボックステストは、単体テストを指します。予想されるすべてのシナリオと出力を効果的に予測できます。すなわち、入力と期待される出力。これは、低レベルのテストと呼ばれます。