プログラム設計書・仕様書から、単体テスト項目を浮き上がらせ、テスト仕様書を手作業で作成する方法

　今まで書いてきた、
仕様書から、テスト項目を浮き上がらせる（モデルと、コントロール編）と
仕様書から、テスト項目を浮き上がるためのExcelシートって、こんな感じ？
のまとめ＆これらの作業は手作業でもできるので、手作業でやる場合の方法を示します。
これによって、単体テストのやり方は、一応、いいんでないかい？

---

手作業で作成する場合の方法

１．テスト対象をモデル・ビュー・コントロールにわけます

　それぞれテスト方法が違うので、分けます。

　ビューとは、ユーザーへの入出力をするところをさしてます。
　コントロールとは、モデルの起動部分を指します
　モデルとは、処理を行っているところをさします。

　モデルの中で、資源の入出力を行っているところは、そこでも、資源の実際の入出力部分と、それらの呼び出し・セッション管理と分かれているかもしれません。そうした場合、実際の入出力部分をモデル、呼び出し・セッション管理部分をコントロールとします。
　つまり、このときは、業務モデルと、資源管理部分の２階層になっているということです。
　２階層以上になることもあります（例：Webサービスをよびだし、そのWebサービスがほかのWebサービスを呼ぶ）。
　何階層になっているかは、コントロールがいくつあるかで見分けます。

---

２．ビュー部分のテスト作成

・外部仕様書等から、画面（ウィンドウ）の項目を拾い出します。ふつう、一覧表になっています。

・その項目のタイプ（テキスト入力、ラジオボタン、チェックボックスなど）を判断します。

・あらかじめ、偉い人（プロジェクトマネージャーなど）が、前もって、どのタイプは、どのテスト（たとえば、テキスト入力は、字種チェック、限界値チェック、入力値の構文チェックなど）を行う可能性があるかのテスト候補を決めておき、

・仕様書をみて、どのテストを行うべきかを決めていきます。

---

３．コントロール部分のテスト作成

・プログラム設計書から、どの値のとき、どのモデルを動かすとか、エラーにするとかが書いてある部分を拾い出します。
　気の利いたSEなら、表にしてあります（単なる表か、決定表かは別として）

・その値を入力（引数なら、ドライバから入力、メソッドの返り値なら、スタブからの返り値とか、スローされたエラー）したとき、どのモデルが動く、エラーになる等をエラー項目として書く。エビデンスは、ログとなる

・それに基づき、ドライバ、スタブを書く。また、どのメソッド（モデル）を起動したかわかるように、テストしようとしているコントローラーからメソッド（モデル）を起動するところに、ログを入れる。

---

４．モデル部分のテスト方法
・プログラム設計書から、処理内容が書かれているところ（フリーフォーマットで書かれているところが多い）を見て、後述するプログラムのパターン単位になるように、拾い出します。

・あらかじめ、偉い人が、このプログラムパターンなら、このテストというふうに決めておきます。
　プログラムパターンっていうのは（デザインパターンとは違い）
　　　　前処理
　　　　値チェック
　　　　主処理：値設定・更新
　　　　主処理：ソート
　　　　　：
　　　　（中略）
　　　　　：
　　　　主処理：ＤＢ更新
　　　　後処理

　のように、処理内容部分を意味ある処理ごとに、まとめたものです。
　これは、意識的にSEさんが、仕様書を書かないと、できないです。
　このパターンごとに、テスト内容が違います。
　（どんなパターンと、どんなテスト項目が考えられるかは、今度、気が向いたら書きます）

・そのプログラムパターンに対し、偉い人が決めたテストができるか（というか、たいていできるはず）を判断し、テスト仕様書に書きます。
　たいてい、エビデンスは、ログです。
　プログラムには、あらかじめ、偉い人が定めたログの書き方（たとえば、ソート処理の場合、順番に、ソートキーを出力など）にしたがって、ログを入れます。

---

　したがって、この方法で抽出するには、SEさんと偉い人が、どういう処理機能を使い、その処理機能ごとに、プログラムをまとめ、その処理機能に対し、どういうテストをするから、機能を満たしているといえるということを、あらかじめ決めて、熟知させる必要があります。
　でも、そんなもん、熟知させるのは、難しい。そこで、パターンを作ってしまい、パターンに当てはまるようにすると、ある程度、この処理機能の型にはまるというようにします。
　なので、パターン（フレームワークの場合もあるけど）は、必要。

　モデルとコントロールに分かれていない場合、モデルに、「条件分岐」というプログラムパターンを入れておき、そこにコントロールに相当するところを押し込めばOK
　そうすれば、ユーザーインターフェースと、それ以外の部分というふうに分けてテストできる。

　ということで、あとは情報処理試験のテキストでも、なんでもいいんだけど、そんなのを参考に、偉い人が、この項目、このプログラムパターンには、このテストを行う可能性あり！ときめてしまえば、いいわけっす。

　ちなみに、これは、仕様書がある場合。
　仕様書がなく、さらにパターンもないと、プログラムを読んで、ここまでの品質保証ができるテストをするのは、難しい。
　（仕様書を作らない場合、プログラムパターンに当てはめないことが多い。なんとなく、処理をならべ、結果をだすというような。。その場合、どういうテストをやれば、品質保証できるのかがわからない。ログも、なんとなく入れていて、通過したエビデンスにしかならないことも！！）

---

　というのが、単体テストの場合でした。
　それ以外のテスト（結合テスト）については、また、仕様書のみる箇所と、テスト項目の作り方が違います。

　それは、別の機会に。