ブラック ボックスとホワイト ボックスのテスト

Question

(テスター/QA にとって) どのタイプのテストを重点的に行うべきだと思いますか?またその理由は何ですか?

ウィキペディアからの定義の簡単なセット:

ブラックボックステスト

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

ホワイトボックステスト

• システムの内部的な観点を使用して、内部構造に基づいてテスト ケースを設計します。ソフトウェア内のすべてのパスを特定するには、プログラミング スキルが必要です。テスターは、コード内のパスを実行するためのテスト ケースの入力を選択し、適切な出力を決定します。電気ハードウェアのテストでは、回路内のすべてのノードがプローブされ、測定されることがあります。例としては、回路内テスト (ICT) があります。

編集：もう少し明確にしておきますが、両方が重要であることは認識していますが、通常、開発と QA は分離されています。

社内の知識はテスター/QA にとって重要ですか?この知識を念頭に置いてテストすることで、より適切に問題をテストできるという議論を聞いたことがありますが、この知識が機能上のニーズから逸れ、意図したソリューションではなく「コードに対するテスト」を促進する可能性があるという議論も聞いたことがあります。 。

Answer 1

• ブラックボックステストは、テスター/ QAにとって重要です。
• ホワイトボックステストは開発者にとって重要なものです（つまり、単体テスト）。
• この質問に答えた他の人々は、質問をより重要なものとして解釈したようです。ホワイトボックステストまたはブラックボックステスト。私も、それらは両方とも重要であると考えていますが、この IEEEの記事ホワイトボックステストがより重要であると主張しています。

Answer 2

ホワイトボックステストは、ソフトウェアユニットテストに相当します。開発者または開発レベルのテスター（別の開発者など）は、システムに統合する前に、作成したコードが詳細レベルの要件に従って適切に動作していることを確認します。

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

どちらのテスト手法も、私の意見では同等に重要です。

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

Answer 3

ブラックボックス

1  システムの機能に焦点を当てる  システムの構造（プログラム）に焦点を当てています

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

＆＃183;等価パーティション分割

＆＃183;境界値分析

＆＃183;推測エラー

＆＃183;レース条件

＆＃183;原因と結果のグラフ化

＆＃183;構文テスト

＆＃183;状態遷移テスト

＆＃183;グラフ行列

テスターは技術的でない場合があります

機能仕様の曖昧さと矛盾の特定に役立ちます

ホワイトボックス

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

＆＃183;ベーシスパステスト

＆＃183;フローグラフ表記

＆＃183;制御構造のテスト

1. 条件テスト

2. データフローテスト

＆＃183;ループテスト

1. 単純なループ

2. ネストされたループ

3. 連結ループ

4. 非構造化ループ

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

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

Answer 4

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

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

さらに一歩、開発者もブラックボックステストに焦点を当てるべきだと思います。ユニットテストとホワイトボックステストの間のこの広範囲にわたる関連性には同意しませんが、それは単なる語彙/スケールの問題かもしれません。ユニットテストの規模では、テスト対象システムは（署名を通じて）コントラクトを持つクラス/メソッドであり、重要なポイントは、どのようにではなく、何を行うかをテストすることです。 さらに、ホワイトボックステストは、メソッドがどのようにその契約を満たすかを知っていることを意味します。

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

Answer 5

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

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

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

Answer 6

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

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

これは、テスターがシステムがどのように動作するかについて秘密にしておくべきだと言っているのではなく、関数 SomeMethod(int x) が機能するかどうかではなく、問題の領域と実際のユーザーがシステムとどのように対話するかにテスターがもっと集中することを望んでいるというだけです。 x が 5 に等しい場合、正しく例外がスローされます。

Answer 7

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

さらに悪いこと

1. 実行する必要があるが、内部に問題があるソフトウェア

2. ソースを見れば動作するはずのソフトウェアですが、動作しませんか？

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

Answer 8

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

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

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

ホワイトボックスのテスト手法： 1.ステートメントカバレッジ 2.決定カバレッジ 3.支店カバレッジ 4.パスカバレッジ。

Answer 9

• 通常、ホワイトボックス テストはテスターに​​は不可能です。したがって、テスターに​​とって唯一の実行可能な答えは、ブラックボックス アプローチを強調することです。

• ただし、アスペクト指向プログラミングおよび契約による設計の方法論では、テストの目標が契約としてターゲット コードにプログラムされるとき (プログラムの静的ビューから見た)、および/またはテストの時相ロジックがターゲット コードにプログラムされるとき、コードをクロスカット (テスト ロジックの動的ビュー) として表示すると、ホワイト ボックス テストが可能になるだけでなく、テスターに​​とって好ましい方法になります。そうは言っても、専門知識が要求されるテイクとなるため、テスターは優れたテスターであるだけでなく、優れたプログラマー、または優れたプログラマー以上である必要があります。

Answer 10

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

Answer 11

「内部知識」とは何を意味しますか？そのようなアルゴリズムが問題を解決するために使用されたことを知っているか、またはテスターが「内部」であるためにコードのすべての行を確認する必要がありますか？

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

Answer 12

• *ブラックボックステスト：システムレベルでのテストで、システムの機能を確認し、システムが設計されたすべての機能を実行することを確認します。主にユーザーポイントで見つかった欠陥を発見します。システムをブラックボックス化するプロのテスターを雇う方が良いでしょう」誰かを怒らせるつもりはない）
• WhiteboxはSDLCで行われる最初のテストです。これは、ランタイムエラーやコンパイルエラーなどのバグを発見するためです。テスターまたは開発者自身が行うことができますが、コードはそれをテストします。彼は他の人よりもそれらを理解しています。*

Answer 13

ここに私の5セントがあります：

開発者として、ほとんどの場合、メソッドのテストを（クラス内で）ホワイトボックステストとして記述します。これは、コードの内部作業を変更するだけでテストが中断しないようにするためです。

メソッドの動作が変更された場合（たとえば、以前とは異なる結果が返された場合）にのみテストを中断したい。

過去20年間の開発では、ユニットテストがコードに強く結び付けられていて、アプリケーションコードとテストコードの両方を維持する必要があるという理由だけで、2つまでの作業に飽き飽きしていました。

デカップリングコードを作成する（テストをコーディングするときも）ことは非常に良いプラクティスだと思います。

別の5セント：モックフレームワークを使用することはほとんどありません。何かをモックする必要があることがわかったときは、代わりにコードを分離することを好むためです。 ）：-）

Answer 14

*ブラックボックステスト： ソースコードが利用できない場合、テストデータは、ソフトウェアの実装方法に関係なく、ソフトウェアの機能に基づいています。 -strong textブラックボックステストの例：境界値テストおよび等価パーティション。

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

Answer 15

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

while

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

Answer 16

この質問に対する最高評価の回答に部分的にのみ同意します。 どのタイプのテストを強調する必要がありますか（テスター/ QAにとって）、なぜですか？

1. 同意する：＆quot;ブラックボックステストは、 テスター/QA。"
2. ホワイトボックステストは、 開発者ですが、ホワイトボックスのテストが単体であることには同意しません テスト。

ホワイトボックステスト方法が適用可能であると述べているこちらの定義に同意します次のレベルのソフトウェアテスト：

• ユニットテスト：ユニット内のパスのテスト用
• 統合テスト：ユニット間のパスのテスト用
• システムテスト：サブシステム間のパスのテスト用