テストについて

コーディング終了後に行うテストのDD、MT、PTの区別がうまくつきません。特にDD、MTが…。
各テストの意味と目的などを教えて下さい。

No.1 回答者： noname#147912 回答日時： 2006/05/27 23:16

会社によって違いますからね。

何の略?

この回答への補足

DDが机上デバッグ
MTがモジュールテスト
PTがプログラムテストになります。
それぞれの目的と相違をご教授願います。

補足日時：2006/05/28 10:36

No.2 回答者： Bonjin 回答日時： 2006/05/28 00:38

＃１の方が書いていますが略語は会社によって違います。

例えて書くと、PTは「Program Test」や「Performance Test」といった意味があり、どちらを使っているのかは会社によって違います。

なので、まずは略語が何の略なのかを調べてみて、それらの意味を知れば良いと思います。そうすれば必然的にテストの意味と目的がハッキリすると思います。

No.3 回答者： toraneko001 回答日時： 2006/05/29 13:17

皆さんの答えのように開発工程をどう呼ぶかは会社によって異なるので、略す前の名称に対して私の経験を元に回答します。

・机上デバッグ
作ったプログラム（ソース）を実行せずに目視で問題ないかチェックします。
開発プロジェクトでは一般的にコーディング規約と呼ばれるものがあるためそれに違反していないかをチェックします。
規約どおりソースが作られているかどうかはデバッグソフトなどでは検知できないため（できるソフトもありますが）、人が直接目視確認をします。
プログラムとは人によって作り方が千差万別なので、これを行うことで仕事の成果物であるプログラムの品質の平均化を図ることができます。
ソースレビューなどと呼ばれたりもします。

・モジュールテスト
プログラムというのは当然何かしらの目的を持って作られます。
その目的を達成するためには更に細かい複数の機能が必要です。
その細かい機能は別のプログラムからでも再利用できるように単独で一つの機能を持つプログラムとして作られます。
それを大体においてモジュールと呼びますが、その細かい単位で各モジュールが目的どおりに機能するかどうかを確認するのがモジュールテストです。

拙い説明でうまく伝われば幸いですが。。。

No.4 回答者： don_go 回答日時： 2006/05/29 20:57

・机上デバッグ

作成したプログラムをリスト出力して目視で問題ないか
チェックします。
モニタ画面上では見逃しがちな入力ミスやアルゴリズムの
不具合、冗長記述等を見付けるのに効果的です。
通常プログラムを作成した本人のみで行います。

SEや上級PG等と複数人で行うのをソースレビューと呼びます。
経験の浅いPGがやりがちなコーディング上の不具合が無いか
チェックします。
また、複数人での開発の際に決められているコーディング
規約に違反していないか、仕様通りにできているか等の
チェックを行います。
場合によっては、この時点で仕様の不具合が判明する場合
があります。

No.5 ベストアンサー 回答者： ko_kinta 回答日時： 2006/05/30 18:06

・机上デバッグ

コンパイルエラーを取り除いた後のソースを目視でチェックし、単純なバグを潰します。
変数の初期化は行われているか、分岐ルートに漏れはないか、無限ループになっていないか、正常時とエラー時に適当な戻り値を返しているか、などを表にしてチェックするのもひとつの方法です。

・モジュールテスト
ある程度大きなプログラムの場合は、モジュールを単独で実行してテストを行います。
予定通りの結果をきちんと返すか、途中で落ちることがないか、共有のデータに悪さをしていないかなどを確認します。
モジュールを実行するためにテスト用のプログラムを作らなければならない場合もあります。
これを怠ると結合した後の不具合で責任の擦り付け合いになったりします。

・プログラムテスト
結合テストになるのでしょうね。
全てのモジュールを結合して、処理が最後まで通るかどうかを確認します。
運用テストなどもこれが通ってからになります。

この回答への補足

とてもわかりやすいです。ありがとうございます！
ＭＴなのですが、モジュール単位の確認のとき分岐処理を全部通すように作成すると思うですが、デバッガを使用しないで、リリース版だけで分岐処理を全パス通る場合はホワイトボックスのテストは実行しなくてもいいのでしょうか？

補足日時：2006/05/31 07:17

No.6 回答者： ko_kinta 回答日時： 2006/05/31 18:00

一人で作るような小さなプログラムでリリース版で全パスを通るのなら、ホワイトボックステストはプログラムテストで代行してもいいでしょう。

ただ複数人のチームで、プログラム、システムが大きくなればなるほどホワイトボックステストはモジュールテストで必ず行うべきです。

地味で面倒な作業であるため、責任感を持たないPGだとすっとばしがちですがね。
概ねそういうPGのモジュールに、リーダーがクライアントへの言い訳に困るような単純バグが潜んでいるものです。