上司の頭の中にある、テスト方法の考え方１ 単体のホワイトボックステスト：今もこの考え、使えるかも

　２０代後半、３０代前半の人の中には、上司のいう話が、「何考えてるの？」という人たちがいるのではないだろうか？
　全部コーディングが終わってからテストしろとか、すぐに修正するなとか。。。
　で、「昔はよかった」といいだす。。。

　たぶん、宇宙人に近い？発想に聞こえるかもしれない。しかし、実は、現場の大きな流れは、その時代の考え方で流れている。なので、その時代の考え方を理解しないと、上の人間との溝ができて永遠に埋まらないだけでなく、開発の中に矛盾を生じる（やりたくない仕事ばかりしている）。。。のだが、それについて、語る人はいない。。。ので、ウィリアムのいたずらが語ってあげよう！というこの企画。その第一回目は、テストについて。

---

　上司の時代、今の５０台、４０台の人、COBOL文化の人は、だいたい８０年代後半、９０年代初頭に完成した考え方が中心だと思う。この考え方に基づき、まとまられたのが、IPAのCAIT(中央情報教育研究所）が出した、情報処理試験のテキストだろう。
　テストに関しては、プロダクションエンジニアテキスト（上）にまとめられている（そんな試験区分が当時あった。今はない。ちなみにウィリアムのいたずらは、プロダクションエンジニアに受かっている）。

　テスト区分としては、
・総合テスト
・結合テスト
・単体テスト
があり、単体の場合は、ホワイトボックステストが中心となる（とまで、テキストには書いていないが、たいてい、当時はそう思っていた。いまも、上司の本音は、そうだと思ったほうがいい。モジュールテストで単体完了なんて、ありえねーだろーと思ってるのが本音。ただし、そのホワイトボックステストを省略して、モジュールの呼び出しのテストで済ませることには、反対しない。なぜなら、本気で単体やる時間はないから）。

---

　で、単体のホワイトボックスの実施手順は、以下のとおり（上述「プロダクションエンジニアテキスト（上）」P526ページからP531をまとめたもの）

（１）プログラムリストから、制御グラフを作成する
（２）選択基準をもとに、エッジまたはパスの選択をする
　　選択基準は、以下のとおり
　　　・エッジによる選択（エッジ網羅法）
　　　　　命令網羅
　　　　　判定条件網羅
　　　　　条件網羅
　　　　　複数条件網羅
　　　・パスを網羅する（パス網羅法）
（３）（２）で得られた経路をもとに、その経路をとおる、テストケース
　　　（テスト入力データ）を作成する。

単体でホワイトボックスをやるのなら、この考えは、今も使えるかも。。。

---

　現在において、

　実際には、ブラックボックステストをおこなって、デバッガで確認する時間はない。

　そこで、現場的には、代表的なエッジに対して、見たい値をログ出力するようにしておき、テスト入力データを工夫して、ユニットテストを行うだけで、エッジ通過のエビデンスをとる方法をとる。
　こうすれば、流しだけで、単体テストと同じ効果が得られる。

本家ブログのアクセス数が１０倍に！でも、アクセスアップの理由はわからず！？

本家のブログが、大変なことになってるんです！
昨日から、急にアクセス数が増えて、いつもなら、こっち（分家）のほうが、アクセス数が多いのに、

昨日は、
　　　　分家（こっち）アクセス数　338 pv 165 ip
　　　　本家アクセス数（PVのみ） 1563pv
で、楽天ブログの、「そのほか」の３６位に載ってるんです！

メルマガで、ブログのアクセスアップの話とか、書いてました。
当然、今回のアクセスアップについても書かねば。。。

というところなんですけど、問題は

「なぜ、こんなにアクセス数が増えたのか、さっぱりわからない！？」

レースクウィーンの憂鬱は、こっちにも書いたしなあ
かおる姫ネタも、こっちに書いてるしなあ。。

何かに載ったのかなあ。。。
なにか、しかけれれている（＾＾；）

さっぱりわからん。。。
これでは、メルマガに、書けんぞ！