ユニットテストにおけるブラックボックステストの重要性
2324 ワード
add by zhj:原文が見つかりませんでした
ブラックボックステストは,プログラム内部の論理構造を考慮せずにユーザの観点から機能および外部構造をテストする.ホワイトボックステストはプログラムの内部論理だけに注目し、文の上書き、分岐の上書きなどを通じてテストされ、プログラムがユーザーにとって実現する機能には関心がありません.ブラックボックスとホワイトボックスの主な区別は,前者は使用者の観点からテストされ,後者はプログラムの機能に関心を持たず,内部の論理にしか関心を持たないことである.ユニットテストは論理的または経路的な面だけを考慮すると(すなわちホワイトボックステスト)、確かに不足します.使用例が全面的でない場合がある.
例えば、A=BまたはA=Bという文字列があります.AとBを取り出します.
例えば、この簡単な関数ですが、私が例を設計すると、1つの文字列A=Bだけを用意すれば、100%のパスオーバーライドができますが、このcaseだけでは、実際には2つの文字列があるので、まだ不足しています.
私はかつてこのようなバグに出会ったことがあって、上のこの関数を書く時、最後の2行を漏らしました
strLeft = strLeft.Trim();//左文字列の前後のスペースを削除
strRight = strRight.Trim();//右文字列の前後のスペースを削除
上の関数に最後の2行が欠けている場合、A=Bは正しく解析できますが、A=Bは解析できません.しかし、ユニットテストで提供されるcaseはA=Bの1つしかなく、A=Bが欠けており、ホワイトボックステストの観点から100%の文オーバーライドを実現しています.しかし、実はこのようなユニットテストは不完全です.
ユーザーの観点からテスト(すなわちブラックボックステスト)すれば、それを補うことができます.たとえば、この2つの文字列が処理されることを知っておくと、2つのcaseを設計することができます.
また、実際にユニットテストを行うと、下位レベルのテストはパスや論理的に良いカバー率が得られることがわかりますが、上になると、ますます集積テストに向かう傾向にあるとき、クラスが特に多く、このときカバーをするのは難しいので、私は主にブラックボックステストの考えを取っています.もちろん,下位層のこれらのクラスのインタフェースや関数が非常に包括的なユニットテストを行ったことが前提である.
ブラックボックステストは,プログラム内部の論理構造を考慮せずにユーザの観点から機能および外部構造をテストする.ホワイトボックステストはプログラムの内部論理だけに注目し、文の上書き、分岐の上書きなどを通じてテストされ、プログラムがユーザーにとって実現する機能には関心がありません.ブラックボックスとホワイトボックスの主な区別は,前者は使用者の観点からテストされ,後者はプログラムの機能に関心を持たず,内部の論理にしか関心を持たないことである.ユニットテストは論理的または経路的な面だけを考慮すると(すなわちホワイトボックステスト)、確かに不足します.使用例が全面的でない場合がある.
例えば、A=BまたはA=Bという文字列があります.AとBを取り出します.
void f(const CString& strLine, CString& strLeft, CString& strRight)
{
int nPos = strLine.find('='); // =
strLeft = strLine.Left(nPos); //
strRight = strLine.Right(strLine.GetLength() - nPos - 1); //
strLeft = strLeft.Trim(); //
strRight = strRight.Trim(); //
}例えば、この簡単な関数ですが、私が例を設計すると、1つの文字列A=Bだけを用意すれば、100%のパスオーバーライドができますが、このcaseだけでは、実際には2つの文字列があるので、まだ不足しています.
私はかつてこのようなバグに出会ったことがあって、上のこの関数を書く時、最後の2行を漏らしました
strLeft = strLeft.Trim();//左文字列の前後のスペースを削除
strRight = strRight.Trim();//右文字列の前後のスペースを削除
上の関数に最後の2行が欠けている場合、A=Bは正しく解析できますが、A=Bは解析できません.しかし、ユニットテストで提供されるcaseはA=Bの1つしかなく、A=Bが欠けており、ホワイトボックステストの観点から100%の文オーバーライドを実現しています.しかし、実はこのようなユニットテストは不完全です.
ユーザーの観点からテスト(すなわちブラックボックステスト)すれば、それを補うことができます.たとえば、この2つの文字列が処理されることを知っておくと、2つのcaseを設計することができます.
また、実際にユニットテストを行うと、下位レベルのテストはパスや論理的に良いカバー率が得られることがわかりますが、上になると、ますます集積テストに向かう傾向にあるとき、クラスが特に多く、このときカバーをするのは難しいので、私は主にブラックボックステストの考えを取っています.もちろん,下位層のこれらのクラスのインタフェースや関数が非常に包括的なユニットテストを行ったことが前提である.