問題タブ [white-box]

たとえば、CsvReader に対するテストを書いています。これは、テキスト行を列挙して分割する単純なクラスです。その唯一の理由は、引用符内のコンマを無視することです。1ページ未満です。

クラスを「ブラックボックス」でテストすることにより、次のようなことを確認しました

• ファイルが存在しない場合はどうなりますか?
• ファイルに対するアクセス許可がない場合はどうなりますか?
• ファイルに Windows 以外の改行がある場合はどうなりますか?

しかし実際には、これらはすべて StreamReader の仕事です。私のクラスは、これらのケースについて何もせずに機能します。したがって、本質的に、私のテストは StreamReader によってスローされたエラーをキャッチし、フレームワークによって処理される動作をテストしています。それは無駄に多くの仕事のように感じます。

関連する質問を見てきました

• QA は厳密にブラックボックスの観点からテストする必要がありますか?
• 単体テスト用のテスト ケースを厳密にキャプチャする

私の質問は、この種の作業を回避するために知っていることを使用する場合、「ガラスの箱」テストのポイントを見逃しているのでしょうか?

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

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

ブラックボックステスト

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

ホワイトボックステスト

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

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

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

このコードの循環的複雑度を見つけて、いくつかのホワイト ボックス テスト ケースとブラック ボックス テスト ケースを提案する必要があります。しかし、コードの CFG を作成するのに問題があります。

テストケースについても助けていただければ幸いです。

いくつかの数式が正しい結果を提供しているかどうかを確認する必要があります。これらの数式は VB プログラムの一部として記述されています。これらの数式を単体テストするための最適なツールと方法は何ですか?

私はホワイトボックステストの世界に比較的慣れていないので、現在取り組んでいるプロジェクトの1つについてテスト計画を立てるのに助けが必要です。現時点では、テスト可能なコードを探して、そのための単体テストを作成しています。私はどういうわけかそれが行われるべき方法ではないことを感じています。このプロジェクトをテストするための最善の準備についてアドバイスをいただけますか？使用できるツールやテストプランテンプレートはありますか？違いが出るのであれば、使用されている言語はC++です。

ホワイトボックステストのいくつかの概念で立ち往生している本を読んでいます。以下のリンクの記事は、本から正確に引用されています。 http://testdesigners.com/testingstyles/ControlFlowTesting.html

1. 「ON-Units」という用語は、それが何であるかを説明することなく、「Decision Coverage」の記事で最初に紹介されています。この記事では、この用語を後で使用し続けますが、ON-Unit の意味がわからないと難しいです。

質問 - 「ON-Unit」は意思決定がたどる、または通過する経路ですか? On units を「呼び出す」にはどうすればよいですか?

2. 「Condition Coverage」の下の例では、DO K=0 TO 50 WHILE (J+K < QUEST)

記事は説明します-「決定テストを使用している場合、WHILE句が偽になる状況を調査することなく、ループをK = 0から51まで実行させることで基準を満たすことができます」

質問 -

判定カバレッジの定義により、テスト ケースは判定の true 分岐と false 分岐の両方を少なくとも 1 回は調査する必要があります。つまり、While (J+K < Quest) が True 分岐、(J+K < QUEST) が False 分岐であるため、K = 0 ～ 50 は重要ではありません。なぜこの記事は判定カバレッジの下で言及されているのですか - While 句が false であることを調査していないのですか?

また、判定カバレッジの行の最初の部分では、真の分岐である K = 0 から K = 51 までのループを実行することによって判定基準が満たされます。真の分岐のテスト ケースを持つだけでは、判定基準は満たされません。 、なぜ記事はこれに沿って決定基準を満たすのに十分であると言っているのですか?

3 つのメソッドがあるとします。すべて非常に似ていますが、入力の種類が異なります。

3 つすべてが同じ基本ロジックを使用します。たとえば、double数値を比較するのはバージョンだけで、他の 2 つは入力を に変換するだけかもしれませんdouble。

いくつかの異なる単体テストを想像することができます: 最初の入力が大きい、2 番目の入力が大きい、両方の入力が負である、など。

私の質問

3 つのメソッドすべてに完全なテスト セットが必要です (コアの実装が同じであるとは想定していないため、ブラック ボックスです)。

また

パラメータ変換を検証するために、バージョンのみdoubleを厳しくテストし、他の 2 つを軽くテストする必要がありますか (同じ実装を共有し、テストで既にテストされていることがわかっているため、ホワイト ボックス テストをdouble行います)。

こんにちは、製品をテストするためにクラスから呼び出していますが、「オブジェクト参照がオブジェクトのインスタンスに設定されていません」というエラーが表示され続けます。

テスト:

ここで何が問題なのですか？

長い投稿でごめんなさい...

ブラウンフィールドプロジェクトに紹介されている間、私は特定のユニットテストのセットと何を考えるべきかについて疑問を持っています。ストアドプロシージャをラップするrepostoryクラスがあり、開発者ガイドブックに、このクラスをどのように構成するかを説明する特定のガイドライン（ルール）があるとします。クラスは次のようになります。

ここで、もちろん、いくつかの統合テストを作成し、SPを呼び出すことができ、動作が期待どおりであることをテストします。ただし、次のことを主張する単体テストを作成しますか。

• 入力パラメーター「someKey」を持つSomeProfilerのコンストラクターが呼び出されます
• PersonStoredProcedureのコンストラクターはと呼ばれます
• ストアドプロシージャのaddNameArgumentメソッドは、パラメータpersonNameを使用して呼び出されます。
• ストアドプロシージャのaddCityArgumentメソッドは、パラメータcityNameを使用して呼び出されます。
• ストアドプロシージャでinvokeメソッドが呼び出されます-

もしそうなら、私は潜在的に、振る舞いに加えて、メソッドの構造全体をテストするでしょう。私の最初の考えは、それはやり過ぎだということです。ただし、チームによって実施されたコーディングプラクティスに関して、これらのテストは、均一で「正しい」構造を確認し、次のレイヤーが正しく呼び出されることを確認します（DALからDB、BLLからDALなど）。

私の場合、これらのタイプのテストは、アプリケーションの各レイヤーに対して実行されます。

フォローアップの質問-SomeProfilerクラスの使用は私には慣習のような匂いがします-これに対する明示的なテストを作成する代わりに、静的コード分析またはユニットテスト+リフレクションを使用して慣習スタイルのテストを作成できますか？

前もって感謝します。