テストケース作成する上で必要な視点、作成にあたっての良い方法はありますでしょうか？
現場によって変わるとは思うのですが、
大抵のWebシステムを扱う現場で作成するテストケースの作成方法としては、
画面レイアウトを見て、プログラム仕様書を見て、そこからケースを起こす、
という流れが一般的なのでしょうか？
また、Webシステムの画面におけるテストケース作成の際の視点としては、
一番最初には「各項目に対してどのような処理内容（表示条件）があるのか」を視点と置くべきでしょうか？
それとも、DB更新値など処理の結果的な部分を先に視点とおく方が良いのでしょうか？
またこちら、別件で、
テストケースの作成を行うタイミングについてなのですが、
一般的なテストケース作成のタイミングは、
「プログラム仕様書が完成した後」が基本なのでしょうか？
そのほか、資料として画面レイアウトのみしか存在していない場合など、
プログラムの記述内容が判っていない状態で、
テストケースを作成する場合などはあるのでしょうか？
No.1
5960
633
35pt
業界でテストケースに関する標準化がイマイチなので、以下は個人的な考えです――。
まず、単体テストと結合テストに分けて考えます。
一番最初には「各項目に対してどのような処理内容（表示条件）があるのか」を視点と置くべきでしょうか
この質問は結合テストを指しているという前提ですが、Webアプリだと、一般的にユーザー入力から処理が始まるので、データフローに沿ってテストケースを設定していくとよいでしょう。もちろん、異常データを投入したり（XSS，SQL印じぇくしょん）や、正規のデータフローの途中から悪意のあるデータを紛れ込ませる（パラメーター改竄）ケースも含めてテスト・シナリオを用意しましょう。
資料として画面レイアウトのみしか存在していない場合
「基本設計しかない」状態と考え、ブラックボックステストを準備します。
ただ、ブラックボックステストには莫大な工数がかかるので（かといって手を抜けばセキュリティホールの温床となりかねない）、画面レイアウトしかない状態でのテスト設計は勘弁してほしいですね。
参考サイト
No.2
92813
35pt
＞大抵のWebシステムを扱う現場で作成するテストケースの作成方法としては、
＞画面レイアウトを見て、プログラム仕様書を見て、そこからケースを起こす、
＞という流れが一般的なのでしょうか？
単体テストはプログラム仕様書をみて、
結合テスト意向は機能仕様書とか実際の業務を想定したケースを作ってテストします。
>また、Webシステムの画面におけるテストケース作成の際の視点としては、
>一番最初には「各項目に対してどのような処理内容（表示条件）があるのか」を視点と置くべきでし>ょうか？
>それとも、DB更新値など処理の結果的な部分を先に視点とおく方が良いのでしょうか？
テストはインプットに対してアウトプットの妥当性を検証するので、両方必要です。
＞「プログラム仕様書が完成した後」が基本なのでしょうか？
プログラムが完成した時点で、プログラム仕様書をみて作成します。
プログラム仕様書が絶対に変わらないのなら可能ですが、
実際には、プログラマーからのフィードバックもあって仕様書が変わるので、
理論通りには行きません。
＞そのほか、資料として画面レイアウトのみしか存在していない場合など、
＞プログラムの記述内容が判っていない状態で、
＞テストケースを作成する場合などはあるのでしょうか？
はてなはそのやり方をしてる可能性が・・。
ＸＰ手法に近いやり方なので、そうかも。
はてなの人に聞いてください。
微妙にＵＩが統一されていないので、各自勝手に開発してそうです。
17
16
1
4
2
コメント（3件)
ご回答ありがとうございます。
お返事が遅れて申し訳ありません。
単体テストについて
プログラム仕様書作成時に同時にテストケースを作成とのこと、ありがとうございます。
となると･･･
いままでの私がいってきた現場では偶々だったのか、
プログラムが完成した後にテストケースを作成していた流れは、
少し順序が可笑しいということですよね。(汗）
＞異常データを投入したり（XSS，SQL印じぇくしょん）
＞正規のデータフローの途中から悪意のあるデータを紛れ込ませる（パラメーター改竄）
こちら把握はできていないのですが。
こういうテストの検証もあるのですね･･･
＞一番最初には「各項目に対してどのような処理内容（表示条件）があるのか」を視点と置くべきでしょうか
質問の説明不足な点申し訳ありません(汗）
こちら単体テストケースについてどこを視点とするべきか分からずにいました。
今までの現場では、
単体テストケースの作成は、現場（出先）で、
予め作成方法のサンプルが載っており、それを元に真似て作成しただけのもので、
実際に１から作成するとなると、どこを作成の視点としておくべきなのか？というのが分からなかったのです。
＞ただ、ブラックボックステストには莫大な工数がかかるので（かといって手を抜けばセキュリティホールの温床となりかねない）、画面レイアウトしかない状態でのテスト設計は勘弁してほしいですね。
ありがとうございます。
勘弁してほしい、と言われていますので、
画面レイアウトのみのケース作成ということも、
スケジュールリングが不十分？という事態の場合にはやむを得ずすることが有るのでしょうか･･･
画面レイアウトだけで、となるとケース不足で検証漏れが多発しそうで怖いですね(汗）
参考サイトありがとうございます。
まだ十分には見れていませんが、とても為になる事が沢山書かれてました（驚
ご回答ありがとうございます。
ご返事が遅れて申し訳ありません。
＞結合テスト意向は機能仕様書とか実際の業務を想定したケースを作ってテストします。
＞テストはインプットに対してアウトプットの妥当性を検証するので、両方必要です。
ありがとうございます。
今後テストケースを作成する機会がありましたら、
これらの点を意識して作成していきます。
＞実際には、プログラマーからのフィードバックもあって仕様書が変わるので、
＞理論通りには行きません。
確かに仕様書は変わりますね（汗
行っていた現場では納品が近いにも関わらず、何度も修正が入って大変だった事があります。
どこかで確定させて欲しいのですが難しいものなのでしょうか・・・汗
普段テストデータにコード値や区分値などがあります。それはテストケースの組み合わせパターンを決めます。
データの組み合わせのパターンを決めてからテストケースを書くのも多いです。
品質のよいテストをするために、品質のよいデータを使わなければなりません。
下記のソフトは大量データの組み合わせパターンの作成ができます
またExcelで60種類以上の本番擬似テストデータを生成して、
そのままExcelシートからOracleやMySQLなど複数のデータベースへ登録できます。
大量のテストデータ自動生成にはとても便利です。
ExcelDBTool(ExcelでDB検索更新データ作成)
http://www.vector.co.jp/soft/winnt/business/se475115.html
ExcelDevTool(エクセル機能拡張でパワーアップ)
http://www.vector.co.jp/soft/winnt/business/se475869.html
http://www.superdbtool.com