H29 技術士(情報工学)ソフトウェア工学 II-2-2:ソフトウェアテスト

(1)ソフトウェアテストの分類
ソフトウェアテストには、プログラムコードを意識して実施するホワイトボックステストと、プログラムコードではなくソフトウェアの動作に着目して実施するブラックボックステストに大きく分けることができる。

(2)ソフトウェアテストの内容
プログラムコードを意識して行うホワイトボックステストでは、コードデバッガを使用しプログラムを動作させ、ポイントポイントでプログラムを止めその時点での変数の値などを確認しながらテストを行っていく。
特にプログラムの中でも分岐条件式については、分岐方向でのみテストを行ったり、すべての条件の組合せでテストを行うなどの種類がある。
また、コードデバッガを使用することでプログラムコードのどの部分に対してテストを行ったかを計測することが可能であり、プログラムのすべての箇所のテストを終了条件にすることができる。
プログラムの動作に着目して行うブラックボックステストでは、テストするプログラムの機能の入力と出力の関係に着目して、テスト用のデータを用意してテストを行い、設計上の入力値から予想される出力値と実際のプログラムの出力値を比較してテストを進める。
また、ブラックボックステストではテスト対象を関数レベルから、より大きな単位であるタスクやジョブ、そしてソフトウェア全体と規模を大きなものにしながらテストを進める。

(3)テストの実施手順
テストはまず関数レベルでのホワイトボックステストから実施し、関数ごとにテストを行い品質問題を解消してから、関数間のインタフェース部分に着目するブラックボックステストを開始する。ここで大事なのは必ずホワイトボックステストが完了したものに対してブラックボックステストを行うようにし、ホワイトボックステストが未完了な関数に対しブラックボックステストを行うことがあってはならない。
ブラックボックステストでは関数間のインタフェースのみに着目することが必要で、不具合が見つかった場合にはそれを記録して関係する関数の担当者に伝え、継続してテストを進めることが大事である。
往々にして、ブラックボックステストを行っていると見つけた不具合についてプログラムコードレベルでの問題対策(デバッグ)を行ってしまうことがあるが、ブラックボックスを行うときはプログラムコードレベルでの調査、対策は行わないようにする必要がある。
経験の少ない技術者が作成した関数とベテランが開発した関数のインタフェースを確認するブラックボックステストでは、不具合が見つかったときにベテランが経験の少ない技術者が開発した関数のプログラムコードを見ながらかが解決を行ってしまうことがあるが、スキルアップの面ではよくないので、そういったことは行わず各担当者が自分の開発範囲について責任をもってテストを行い、見つかった不具合の開発を行うことが大事である。

[Intermission]
テストの分類視点というのを正しく理解できていなかったようで、問題が期待する内容の解答にはなっていないと思います。
後々考えると、テストの分類としては“静的テスト(解析)”と“動的テスト(検証)”、“ホワイトボックステスト”と“ブラックボックステスト”の2つとして書けばよかったと思います。
と、いうことで書き直してみました。


(1)ソフトウェアテストの分類
ソフトウェアテストにはいくつかの種類がありこれを分類すると、ソフトウェアを動作させることなくプログラムコードについてチェックを行う静的テストとソフトウェアを動作させて行う動的テストに分けることができる。
また、動的テストにはプログラムコードを意識して行うホワイトボックステストとソフトウェアに入力として与えるデータと出力結果の関係に注目して行うブラックボックステストがある。

(2)ソフトウェアテストの内容
静的テストはプログラムコードの記述内容をチェックするテストで、異なる型の変数の代入や0による除算などソフトウェアを動作させなくても不具合につながる箇所を洗い出すものである。また、静的テストで使用するツールの多くはプログラムの複雑度を計測する機能があり、複雑で不具合の発生しやすい箇所(関数)を教えてくれる。
動的テストは実際にソフトウェアを動作させるテストであり、そのテスト内容はソースコードデバッガを用いてプログラムコードレベルで変数の値を確認したり、条件分岐箇所の動作を確認するホワイトボックステストがある。また、動的テストにはホワイトボックステストと異なりプログラムコードに着目せず、ソフトウエアが処理する与えられた入力データと処理した結果の出力データの関係からソフトウェアが期待する動作となっているかを確認する。

(3)テストの実施手順
ソフトウェアの手順としてはプログラミング工程が完了したら作成したプログラムコードに対し静的テストを実施する。不具合の検出という面でみるとソフトウェアをどうさせることなくツールを使用して不具合を見つけられる静的テストは不具合検出に係る工数、労力が少ないため最初に静的テストを行い不具合につながる箇所を修正することが短期間で品質を安定させることに寄与する。
静的テストが完了したプログラムコードは次にホワイトボックステストを行う。ホワイトボックステストはソフトウエアを構成している関数ごとに動作させたときの変数の値や条件分岐の動作などをテストし確認する。また、静的テストツールから得られたソフトウェアの複雑度から複雑で不具合の発生しやすい箇所についてはより細かい粒度でテストをすることで不具合を検出し品質を向上することができる。
ホワイトボックステストが完了した関数は、ブラックボックステストに移る。ブラックボックステストはその関数がインタでフェースする他の関数との受け渡しデータについての確認を行う。ここで大事なのは必ずホワイトボックステストが完了したものに対してブラックボックステストを行うようにし、ホワイトボックステストが未完了な関数に対しブラックボックステストを行うことがあってはならない。
ブラックボックステストでは関数間のインタフェースのみに着目することが必要で、不具合が見つかった場合にはそれを記録して関係する関数の担当者に伝え、継続してテストを進めることが大事である。
往々にして、ブラックボックステストを行っていると見つけた不具合についてプログラムコードレベルでの問題対策(デバッグ)を行ってしまうことがあるが、ブラックボックスを行うときはプログラムコードレベルでの調査、対策は行わないようにする必要がある。
経験の少ない技術者が作成した関数とベテランが開発した関数のインタフェースを確認するブラックボックステストでは、不具合が見つかったときにベテランが経験の少ない技術者が開発した関数のプログラムコードを見ながらかが解決を行ってしまうことがあるが、スキルアップの面ではよくないので、そういったことは行わず各担当者が自分の開発範囲について責任をもってテストを行い、見つかった不具合の開発を行うことが大事である。

戻る 一覧へ