テストとか

wildcatsさんのエントリから


最近の自分の考えていることに近いので勉強になるなあ.

・ そもそもホワイトボックステストって何ぞや?という点は,いろいろ文献やよく言われているノウハウからいうと三つの立場があると思います.
1.テストケースの抽出方式は関係なく,網羅度評価の分母として内部構造から得られるメトリクスを用いる.(「テスト密度はXX個/kステップにすべし」とか)
2.コードの構造(文,条件分岐など)からテストケースを抽出する方式.
3. とにかくコードが見えることを前提にテストをすること.

ここでは2の立場ということでしょう.

で,元の件ですが,
・ 内部でどのように処理をすべきか(8の倍数なら別のアルゴリズムを使う,など)は要件として,記述すべき.そうすればブラックボックステストで対応可能ということですね.そう思います.ただ,一般的に「どうやって」処理するかに相当するものは要件として書くのですか?

ホワイトボックステストは100%になっても意味はないというのは,まったくの賛成です.実際わかるのは,選んだテストケースは要件を満たしているというだけで,要件全てを満たしているかは,ホワイトボックスによるテストケース抽出では,絶対わからないでしょうし.逆に積極的にホワイトボックステストの良い点をみつけるとすれば,ホワイトボックステストとして機械的にテスト項目を挙げていくと,逆に要件/仕様のあいまいな点抜けている点が明確になるかもしれません.

DbCを使った場合の境界値テスト削減の話ですが,「DbCで定義した事前条件を満たさない呼び出しを正しく例外などとして扱うか」のテストはいらないのでしょうか? #DbCを実際にどのように実装するのかわかってないための疑問かも...



最近,斉藤孝(だっけ)なる3色ペンの人の本を立ち読みして,文章力をつけようとと思ったが,中に書いてあることは,要するに「練習が一番」.道は遠いな.大体,ダイエットも英語もプログラミングも,アイスホッケーもなにもかも結局練習と努力が一番という結論の話が多く,そんなことできるなら誰も困っとらんわ!って感じではある.
もっと,日刊スポーツとかジャンプの裏の方にあるような,努力0でウハウハってな方法ってないだろうか.ドラえも~ん.