testing - テスターは、ブラックボックステストとホワイトボックステストのどちらを重視する必要がありますか？

Question

（テスター/ QAの）どのタイプのテストに重点を置くべきだと思いますか、またその理由は何ですか？

ウィキペディアからの定義のクイックセット：

ブラックボックステスト

テストケースを導き出すために、テストオブジェクトの外部の視点を取ります。これらのテストは、通常は機能しますが、機能する場合と機能しない場合があります。テスト設計者は、有効な入力と無効な入力を選択し、正しい出力を決定します。テストオブジェクトの内部構造に関する知識はありません。

ホワイトボックステスト

システムの内部パースペクティブを使用して、内部構造に基づいてテストケースを設計します。ソフトウェアを介したすべてのパスを識別するには、プログラミングスキルが必要です。テスターは、コードを介してパスを実行するためのテストケース入力を選択し、適切な出力を決定します。電気ハードウェアテストでは、回路内のすべてのノードをプローブして測定できます。例として、インサーキットテスト（ICT）があります。

もう少し明確にするために、両方が重要であることに気付きましたが、通常、それらはdevとQAの間で分離されています。

テスター/QAにとって内部知識は重要ですか？この知識を念頭に置いてテストすることで、問題をより適切にテストできるという議論を聞いたことがありますが、この知識が機能上のニーズをそらし、意図した解決策ではなく「コードのテスト」を促進する可能性があるという議論も聞いています。

score 53 · Accepted Answer

ブラックボックステストは、テスター/QAの重点となるはずです。
ホワイトボックステストは、開発者にとって重点となる必要があります（つまり、単体テスト）。
この質問に答えた他の人々は、質問をホワイトボックステストとブラックボックステストのどちらがより重要であるかと解釈したようです。私も、どちらも重要だと思いますが、ホワイトボックステストの方が重要であると主張しているこのIEEEの記事を確認することをお勧めします。

score 11 · Accepted Answer

ホワイトボックステストは、ソフトウェア単体テストと同じです。開発者または開発レベルのテスター（別の開発者など）は、自分が作成したコードがシステムに統合される前に、詳細なレベル要件に従って正しく機能していることを確認します。

ブラックボックステストは統合テストと同じです。テスターは、システムが機能レベルの要件に従って機能することを確認します。

私の意見では、両方のテストアプローチが等しく重要です。

徹底的な単体テストは、ソフトウェアがシステムに統合された後ではなく、開発段階で欠陥を検出します。システムレベルのブラックボックステストでは、すべてのソフトウェアモジュールが統合されたときに正しく動作することを確認します。モジュールは通常、互いに独立して開発されるため、開発段階での単体テストではこれらの欠陥を検出できません。

score 8 · Accepted Answer

ブラックボックス

1 システムの機能性に着目システムの構造（プログラム）に着目

2 使用されるテクニックは次のとおりです。

· 同値分割

・境界値解析

・エラー推測

・レースコンディション

・因果関係グラフ

· 構文テスト

・状態遷移試験

・グラフマトリックス

テスターは技術者でなくてもかまいません

機能仕様のあいまいさと矛盾を特定するのに役立ちます

白い箱

使用される手法は次のとおりです。

· ベーシスパステスト

・フローグラフ表記

· 制御構造のテスト

状態試験
データフローのテスト

・ループ試験

シンプルなループ
ネストされたループ
連結ループ
非構造化ループ

テスターは技術者でなければなりません

論理的およびコーディングの問題を特定するのに役立ちます。

score 5 · Accepted Answer

QA はブラックボックステストに重点を置く必要があります。QA の主な目的は、システムがどのように機能するかではなく、システムが何を行うか (機能が要件を満たしているか) をテストすることです。

とにかく、QA担当者のほとんどは技術者ではないため、QAがホワイトボックステストを行うのは難しいはずです。そのため、通常はUI（ユーザーなど）を介して機能をテストします.

さらに一歩進んで、開発者もブラックボックステストに集中すべきだと思います。単体テストとホワイトボックステストの間のこの広範な関連付けには同意しませんが、語彙/尺度の問題にすぎない可能性があります。単体テストの規模では、テスト対象のシステムは (署名を通じて) コントラクトを持つクラス/メソッドであり、重要な点は、それがどのようにではなく何を行うかをテストすることです。さらに、ホワイトボックステストは、メソッドがコントラクトをどのように満たすかを知っていることを意味します。これは、TDD と互換性がないように思えます。

SUT が非常に複雑でホワイトボックステストを行う必要がある場合は、通常はリファクタリングの時期です。

score 4 · Accepted Answer

「両方」は上記で述べられており、明らかな答えです...しかし、IMO、ホワイトボックステストは開発者単体テストをはるかに超えています（ただし、白と黒の線をどこに引くかによって異なると思います）。たとえば、コードカバレッジ分析は一般的なホワイトボックスアプローチです。つまり、いくつかのシナリオまたはテストを実行し、結果を調べてテストの穴を探します。単体テストの cc が 100% であっても、一般的なユーザーシナリオで cc を測定すると、さらに多くのテストが必要になる可能性があるコードが明らかになる可能性があります。

ホワイトボックステストが役立つもう 1 つの場所は、データ型、定数、およびその他の情報を調べて、境界、特別な値などを探すことです。たとえば、アプリケーションに数値入力を受け取る入力がある場合、bb のみのアプローチではテスターがどの値がテストに適しているかを「推測」しますが、wb アプローチでは、1 から 256 までのすべての値が 1 つの方法で処理され、より大きな値は別の方法で処理されることが明らかになる可能性があります...そしておそらく 42 という数値にはさらに別のコードパスがあります.

したがって、元の質問に答えるには、bb と wb の両方が適切なテストに不可欠です。

score 3 · Accepted Answer

私の経験では、ほとんどの開発者は自然にホワイトボックステストに移行します。基礎となるアルゴリズムが「正しい」ことを確認する必要があるため、内部に重点を置く傾向があります。しかし、指摘されているように、ホワイトボックステストとブラックボックステストの両方が重要です。

したがって、私はテスターにブラックボックステストにもっと焦点を合わせてもらい、ほとんどの開発者が実際にはそれを行わず、しばしばそれがあまり得意ではないという事実をカバーすることを好みます。

これは、テスターがシステムの動作について暗闇にさらされるべきだということではありません。関数SomeMethod（int x）かどうかではなく、問題のドメインと実際のユーザーがシステムを操作する方法に焦点を当てることを望んでいます。 xが5に等しい場合、例外を正しくスローします。

score 2 · Accepted Answer

それは少し開いたドアですが、最終的には両方がほぼ同じように重要です。

何が悪いの？

必要なことを実行するが、内部的に問題があるソフトウェア？
ソースを見れば動作するはずのソフトウェアですが、動作しませんか？

私の答え：どちらも完全に受け入れられるわけではありませんが、ソフトウェアが100％バグがないことを証明することはできません。したがって、いくつかのトレードオフを行う必要があります。オプション2はクライアントに直接気付かれるので、すぐに問題が発生します。長期的には、オプション1は問題になります。

score 2 · Accepted Answer

通常、テスターはホワイトボックステストを実行できません。したがって、テスターにとって実行可能な唯一の答えは、ブラックボックスアプローチを強調することです。
ただし、アスペクト指向プログラミングとデザイン・バイ・コントラクトの方法論では、テストの目標がコントラクトとしてターゲットコードにプログラムされている場合 (プログラムの静的ビューから見た場合)、および/またはテストの時相論理がコントラクトにプログラムされている場合コードをクロスカット (テストロジックの動的ビュー) として表示することで、ホワイトボックステストが可能になるだけでなく、テスターに好まれる方法にもなります。そうは言っても、専門知識を必要とするテイクが必要になるでしょう。テスターは、優れたテスターであるだけでなく、優れたプログラマー、または優れたプログラマー以上である必要があります。

score 2 · Accepted Answer

ブラックボックステスト: ブラックボックステストは単なる観察であり、ソフトウェア製品の内部知識や構造は必要ありません。有効なデータ入力と無効なデータ入力を入れて、正しい結果を期待するだけです。ここで、テスターは欠陥を見つけますが、欠陥の場所を見つけることができません。すべてのテストレベルで行われるブラックボックステスト。

ブラックボックステストの手法は次のとおりです。 1. 等価分割 2. 境界値分析 3. 意思決定表 4. 状態遷移図 4. ユースケース図

ホワイトボックステスト: ホワイトボックステストでは、ソフトウェア製品の内部ロジックと構造に関する知識が必要です。ここでは、ループ、条件、および分岐を確認します。ここでは、欠陥だけでなく、欠陥の場所も特定します。

ホワイトボックステスト手法: 1. ステートメントカバレッジ 2. 決定カバレッジ 3. 分岐カバレッジ 4. パスカバレッジ。

score 2 · Accepted Answer

ブラックボックステストは、テスト対象の項目の内部構造/設計/実装がテスト担当者に知られていないソフトウェアテスト方法です。ホワイトボックステストは、テスト対象の項目の内部構造/設計/実装がテスターに知られているソフトウェアテスト方法です。

score 1 · Accepted Answer

「内なる知識」とは何か？問題を解決するためにこれこれのアルゴリズムが使用されたことを知ることは、資格を与えますか?それとも、テスターはコードのすべての行を「内部」であると見なす必要がありますか?

どのテストケースでも、使用される仕様によって与えられる期待される結果があり、テスターが仕様を解釈することを決定する方法によって決定されるのではないと思います。

score 0 · Accepted Answer

*ブラックボックステスト：ソースコードが利用できない場合、テストデータは、ソフトウェアの実装方法に関係なく、ソフトウェアの機能に基づいています。-強力なテキストブラックボックステストの例は次のとおりです。境界値テストと等価分割。

*ホワイトボックステスト：テスト対象のシステムのソースコードが利用可能な場合、テストデータはこのソースコードの構造に基づいています。-ホワイトボックステストの例は、パステストとデータフローテストです。

score 0 · Accepted Answer

シンプル...ブラックボックステストは、統合テストまたはスモークスクリーンテストとしても知られています。これは主に、イベント駆動型アーキテクチャに依存する分散環境で適用されます。別のサービスに基づいてサービスをテストして、考えられるすべてのシナリオを確認します。ここでは、SOA/エンタープライズアプリの各コンポーネントが自律的に機能することを意図しているため、考えられるすべての出力を完全に予測することはできません。これは、高レベルのテストと呼ぶことができます

その間

ホワイトボックステストとは単体テストのことです。予想されるすべてのシナリオと出力を効果的に予測できる場所。つまり、入力と期待される出力です。これは、低レベルテストと呼ばれます。

score 0 · Accepted Answer

この質問に対する最高評価の回答に部分的にしか同意しません。(テスター/QA 向けに) どのタイプのテストに重点を置くべきだと思いますか? また、その理由は何ですか?

「テスター/QA はブラックボックステストに重点を置くべきだ」という意見に同意します。
ホワイトボックステストが開発者にとって重要であることには同意しますが、ホワイトボックステストが単なる単体テストであることに同意しません。

私は、ホワイトボックステスト手法が次のレベルのソフトウェアテストに適用できるという定義に同意します。

ユニットテスト: ユニット内のパスをテストする場合
統合テスト:ユニット間のパスのテスト用
システムテスト: サブシステム間のパスのテスト用

testing - テスターは、ブラックボックステストとホワイトボックステストのどちらを重視する必要がありますか？

17 に答える 17

Related

Reference