テスト勉強 "ソフトウェアテストの教科書" メモ1

 テストについて改めて体系的に学ぶことにした。そういうわけでソフトバンク出版の「ソフトウェアテストの教科書」とオライリーの「初めての自動テスト」を買ったので読み進めている。まず"ソフトウェアテストの教科書"を読んでいてそのメモ。

ホワイトボックステスト
===================

 ソフトウェアの中身の動作を把握して行うテスト。処理のフローチャートを用意して、そのフローチャートの分岐を網羅するようにテストしたり。

ブラックボックステスト
===================

 中の細かい動作を意識せずに、入力とその結果を見る。たとえばこのブログは、TravisCI上でSeleniumを使って管理メニューへのログインの成功と失敗を試すテストがある。これはブラックボックステストに該当するだろう。

境界値
=====

 たとえば65歳以上の人には割引を適用する販売システムを作ったとする。そうすうと、65歳未満の人には割引がない。この場合、65歳の人に割引を適用し、64歳の人には割引が適用されないことを確認すべきだろう。

同値クラス
========

 上述のシステムの場合、68歳の人や70歳の人には同じ割引が適用される。この同じ結果を返す条件に入るもの同士が、同値クラスと呼ばれる。たとえば60歳の人と50歳の人という条件があったらこれらも同値クラス。


***************
 さいきんどこかのTDDの話題で、「コンパイルに時間がかからない言語だと、TDDって向いてるよね」ってコメントを見た気がする。これはスクリプト言語とかいわれてるあれらのことだろうか。そして裏には「いちいちコンパイルに時間がかかるような言語ではTDDは向いていない」というのがあったりするんだろうか。
 ぼくは会社で唐突に炎上中のVB.NETの案件に入れられることになった。VB.NETなんて書いたことなかったし。TDDもやったことはなかった。ただ自分のOSSでCI/CDは導入していたので、自動テストは書いた経験があった。ぼくはそのVB.NETプロジェクトをTDDで進めて成功した。
 TDDのテストはもちろんコンパイルのあとに行われる。ではTDDではない場合、テストはいつ行うんだ?コンパイル後だろう?どうせテストするならもう自動テストにしておけばいいじゃないか。まさかテストしないでなんてことがあるだろうのか?まあそのまさかがあるのはうわさで聞いている。
 よっぽどコンパイルに時間がかかるような状況なら場合に応じた対応を考えるべきだ。それをコンパイルが必要な言語、不必要な言語でスッパリ分けてしまうのには疑問を感じる。ちょっとぐらい時間がかかろうが、何度も繰り返し手で行うようなことは自動化しておきたい。プログラマは健康のために一時間ごとに席を立って軽く歩いたりストレッチをするべきだと考えている。そのあいだにコンパイルから自動テストまでを走らせておけばいいじゃないかと考えている。
comment: 0