２０代後半、３０代前半の人の中には、上司のいう話が、「何考えてるの？」という人たちがいるのではないだろうか？
全部コーディングが終わってからテストしろとか、すぐに修正するなとか。。。
で、「昔はよかった」といいだす。。。
たぶん、宇宙人に近い？発想に聞こえるかもしれない。しかし、実は、現場の大きな流れは、その時代の考え方で流れている。なので、その時代の考え方を理解しないと、上の人間との溝ができて永遠に埋まらないだけでなく、開発の中に矛盾を生じる（やりたくない仕事ばかりしている）。。。のだが、それについて、語る人はいない。。。ので、ウィリアムのいたずらが語ってあげよう！というこの企画。その第一回目は、テストについて。
上司の時代、今の５０台、４０台の人、COBOL文化の人は、だいたい８０年代後半、９０年代初頭に完成した考え方が中心だと思う。この考え方に基づき、まとまられたのが、IPAのCAIT(中央情報教育研究所）が出した、情報処理試験のテキストだろう。
テストに関しては、プロダクションエンジニアテキスト（上）にまとめられている（そんな試験区分が当時あった。今はない。ちなみにウィリアムのいたずらは、プロダクションエンジニアに受かっている）。
テスト区分としては、
・総合テスト
・結合テスト
・単体テスト
があり、単体の場合は、ホワイトボックステストが中心となる（とまで、テキストには書いていないが、たいてい、当時はそう思っていた。いまも、上司の本音は、そうだと思ったほうがいい。モジュールテストで単体完了なんて、ありえねーだろーと思ってるのが本音。ただし、そのホワイトボックステストを省略して、モジュールの呼び出しのテストで済ませることには、反対しない。なぜなら、本気で単体やる時間はないから）。
で、単体のホワイトボックスの実施手順は、以下のとおり（上述「プロダクションエンジニアテキスト（上）」P526ページからP531をまとめたもの）
（１）プログラムリストから、制御グラフを作成する
（２）選択基準をもとに、エッジまたはパスの選択をする
選択基準は、以下のとおり
・エッジによる選択（エッジ網羅法）
命令網羅
判定条件網羅
条件網羅
複数条件網羅
・パスを網羅する（パス網羅法）
（３）（２）で得られた経路をもとに、その経路をとおる、テストケース
（テスト入力データ）を作成する。
単体でホワイトボックスをやるのなら、この考えは、今も使えるかも。。。
現在において、
実際には、ブラックボックステストをおこなって、デバッガで確認する時間はない。
そこで、現場的には、代表的なエッジに対して、見たい値をログ出力するようにしておき、テスト入力データを工夫して、ユニットテストを行うだけで、エッジ通過のエビデンスをとる方法をとる。
こうすれば、流しだけで、単体テストと同じ効果が得られる。
アクセス
トータル
ランキング
