ＩＴのソムリエ・デジタリアン

設計開発編：構造化テスト（４）

トップダウンテスト法

　体系的、構造的にテストすることを目的にしており、
　構造化プログラミングの基本に従ってテストします。
　基本的な考え方は次の言葉に表れています。
　・Stepwize　refinement　（段階的精練法）
　・Devide　&　conqure　　　（分割統治法）
　
（１）方法
　・プログラムの頂上、つまり最初に呼び出されるモジュール（例えばmain）から
　　コーディングし、テストします。
　・下位のモジュールはダミーのプログラム（スタブと呼ぶ）を結合しておきます。
　・最初のモジュールのテストが終わったら下位のモジュールをコーディングし、そのテストを行います。
　　（場合によりコーディングが先行していても良いです。）

（２）長所
　・基本構造に関係の深い部分から先にテストするので、根本的なエラーを早期に発見できます。
　・上位とのインタフェースが早く検証でき、重大エラーの早期発見が可能。
　・細部の論理より全体の機能中心のテストができ、早期にシステムの全体像が把握できます。
　　顧客へのデモンストレーションも早めにできます。

（３）短所
　・スタブ開発が以外と面倒なことがあります。
　　入出力関係から先にテストするとデータ入力や結果表示が楽になります。
　・論理の複雑なモジュールや、性能に深く関係するモジュールが後回しになる可能性があります。
　　→重要なモジュールは先に単独でテストするなどの工夫が必要です。

設計開発編：構造的テスト（３）

テスト・カバーレッジ
　ホワイトボックス・テストの一種です。
　ソースコードの何％をテストで実施したかを示す網羅率で表わします。
　多くの場合１００％を目指すのが理想的ですが、実際には、そこまでやらない
　場合もあります。
　よく使う指標には次の２通りがあります。
　Ｃ０メジャー：全命令文網羅率・・・全ての命令文の何％をテストしたか？
　Ｃ１メジャー：条件判定網羅率・・・条件判定分岐の何％をテストしたか？

　この方式の問題点：
　　・仕様の不備や仕様の誤解による不良はチェックできない。
　　・実行したからと言って正しいとは限らない。
　　・コーディング漏れは発見できない。
　　・測定ツールが必要。

設計開発編：構造的テスト（２）

不良件数見積もり
　過去の例から何ステップ当たり何件のバグがあるかを予想します。
　そのためにはプロジェクト毎の開発ステップ、バグ件数などを把握しておくことが大切です。

　組織的に経験の積み重ねが必要となります。
　例えばCOBOLのアプリケーションプログラムでは単体テストで２〜３００ステップ　に１件、
　システムテストでは２〜３Ｋステップに１件の不良が見つかるようです。
　これは私の経験則なので、きちんとした理論があるわけではありません。

　チームのスキルレベルにもよりますが、これより大幅に多いと、開発品質が悪い
　と判断できると思います。
　開発者へ差戻すことなどの処置も必要です。

　バグの発生内容、原因、さらに動機的原因、つまり、なぜバグができたかを、
　その開発者の根本的な動機付け、間接的原因までさかのぼって分析することも大事です。

設計開発編：構造的テスト（１）

構造的、体系的にテストすることで少ない手間で効果的なテストができる。

１．テストの目的

テストはいったい何のためにやるのでしょうか？

E.W.Dijkstra（ダイクストラ）は次のように言っています。
「テストでプログラム中のバグの存在は示せても、バグが存在しないことは示しえない。」

つまり、プログラムが正しく動作することを証明する手段はないということです。
いくらテストしても、プログラムが正しく動作することの証明にはなりません。
そもそもプログラムの仕様自体が間違っている場合もあります。
でも、誤り（バグ）は、それを示せば、存在を証明できます。

テストで見つけられるのはプログラム内の誤りだけなのです。

ただ、言えるのは誤り（バグ）を見つければ見つけるほどプログラムの品質が向上したことになり、
誤動作する可能性が減ります。
これがテストの目的なのです。

たくさんの誤り（バグ）を見つければ見つけるほど、テストは本来の目的に貢献しているのです。
これはちょっと盲点ではないでしょうか？

さて、効果的なテストは多くのバグを見つけることだとすると、いくつかの問題が出てきます。

・テストにおける問題点１：
　　プログラムにバグがないように作るのと、テストでバグを見つけることは矛盾する行動です。
　　積極的にバグを見つけることをプログラマに動機付けできるでしょうか。
　　誰しも自分の作品にケチを付けるのはイヤなことです。
　　できればバグが少ないことを確認したいと思うでしょう。
　　これではテストの目的は達成できなくなります。

　　この解決法は？
　　プログラム開発者（または組織）とテスト担当者（または組織）を別々にします。
　　これならテスト担当者は張り切ってバグを見つけるはずです。
　　それがテストのミッションだからです。
　　またプログラマも他人がテストするわけですから、コーディングに緊張感がでます。


・テストにおける問題点２：
　　テストでバグがもう見つからないとき、
（１）プログラムの品質は高いと確信できるでしょうか？
（２）テスト方法に問題があり、バグを叩き出せないのではないでしょうか？
　　　どちらかなのか判断できないという問題があります。

　　　この解決方法はちょっと難しいです。
　　　プログラムの品質が、もうだいじょうぶという判断材料を与える手段は
　　　色々あります。

（１）検査進捗曲線・・・テスト進捗状況と品質の判定ができます。
（２）不良件数見積・・・テストの終了判定の指針を与えます。
（３）カバーレッジ・・・機械的にテスト完了の判断材料を与えます。
　ただし、最初に述べたように品質を保証する完璧な方法は存在しません。
　これらの方法は各々、欠点も持っています。
　使用に当たっては経験者の判断が必要であることを忘れないで下さい。


・テストにおける問題点３：
　　バグをたくさん見つけるには、どのようなテストをすれば良いのでしょうか？
　　何をどうテストすればよいのでしょうか？
　　またテスト件数の目標値はどの位が妥当なのでしょうか。

　　この解決方法として、いくつかの効果的なテスト手法があります。
　　ここでは私がいつも実践している手法を御紹介致します。
　　　・トップダウン・テスト法・・・プログラムを上位機能からテストします。
　　　・効果的テスト手法・・・・・・最も効果的なテストケースを設計します。

　　特に効果的テスト手法はいくつかの方法論をカスタマイズし、
　　私が実際の開発で使用しているものを次回以降、御紹介致します。

設計開発編：外注管理の心得

プログラムの開発を外注へ任せる場合、キチンと設計通りできているかをチェックすることが大事です。

　完璧な設計書を渡し、完璧なプログラム作りをしてくれるならば理想的ですが、
　現実には、そのようなことは期待できません。性悪説に立つわけではありませんが、人は過ちを犯すものであり、
　コミュニケーションミスもあるので設計者の考えている通りのものができることはないと考えてよいでしょう。

　テストフェーズでチェックすればよいと考える人もいるでしょうが、
　それでは手戻り作業が増えますし、テスト漏れすることもあるので遅すぎます。
　プログラムのコーディング途中でもチェックすべきです。
　では、どのようにしてチェックするかを次に挙げます。

　（１）ソースコード・ウォークスルー
　　　　　プログラム・ソース・コーディングをプログラマが説明し、参加者全員で見てチェックして行きます。
　　　　　説明する人が話しながら、自らの間違いを発見することも多いです。
　　　　　全てのソースコードを見る必要はない。設計上の重要ポイントや性能上、問題になりそうな所だけをチェックします。

　（２）テスト項目リストのチェック
　　　　　ちゃんとテストしているかを見るにはテストチェックリストを見せてもらえば、すぐにわかる。チェックリストを作っていなかったり捏造していたりしていないか確認します。

　（３）コーディング現場の見学
　　　　　委託した最初の段階で作業現場を見せてもらいます。
　　　　　ただ見るだけですが、その効果は大きい。
　　　　　しっかりチェックする顧客だと思われるだけでも、相当なプレッシャーになるはずです。
　　　　　もちろん、人がいなかったり、現場を見せてくれない場合には、より厳重に進捗確認をしていく必要があります。