やぼったい開発 > ウォータフォールモデルによる開発手法の基礎 > 試験工程(補足)

試験工程(補足)

試験工程の分類法

  • サーバなどはUT,FT,IT各工程を以下のように分類することもある。
    1. 各装置(サーバ)内試験
    2. 開発内 装置間試験
    3. ネットワーク結合試験
  • 積み上げについての観点は変わらない。

  • 組み込み系は IT工程から ハードウエアである開発機と結合し始めることもある。

他の試験の分類

省略したが他にも開発対象によって 以下のような試験がある。
上記の3つなどは FDからひっくり返る可能性も十分ある。たいていは、一部直してFDからやり直すだけで済むことが多いが。。。
  • 性能(スループット)試験
  • 負荷試験
  • 本番環境試験(ネットワークや、特殊ハードウエア系は重要)
  • サニタイジングなどのセキュリティ試験(設計工程で組み込まれているから対応工程の試験で行われているはず)
  • 使用するユーザに実際に使ってもらう試験
  • ゲームやMP3など ユーザやテスターにめちゃくちゃな操作をしてもらう意地悪試験
  • 自動車など特異な(気温や湿度)環境下で行う厳環境試験
  • 高電圧や割り込み信号などによるハードウエア特有の試験(設計工程に組み込まれている)
  • 医療や交通機関における安全性試験(設計工程に組み込まれている)
  • お客様前での導入時に行う、受け入れ試験(簡易な試験や導入試験)
  • 第3者の観点で行う 別テスト部隊による 品質保証試験(ちゃんと試験が終わっていれば特に問題ないはず)
  • 改良や、不具合対応後のデグレード確認試験

試験手法

以下の試験は、UTだけでなく、ITやFTで行うこともある。とくにどの工程でどの手法を使うかは関係ない。
  • 境界値試験
  • ホワイトボックス
  • マトリックス試験、CFD試験

他のソフトウエア環境試験

以下は UT試験のために 、どれだけ設計工程で集約したり、切り分けられるかが重要になる。
うまく行うと自動化がしやすい。
  • GUI試験(UT部分でも自動化がしずらいが ロボットや マウスを自動で動かす物などがある。)
  • DB試験(アクセス方式、インスタンス保持や、検索速度など)
  • web試験(セッションや クッキーなど スコープ的な試験が必要になる。)

テストの自動化

  • 基本はUT工程が対象となる。FT工程以降も一部できる部分がある。
  • 先の工程でなにか不具合が起きた場合、他に影響していないか コストをかけずにできる。
  • デイリービルドしている場合、ビルド作業にテストを組み込む(自動化されていれば組み込みやすい)ことで、品質改善に貢献できる。
  • テスト自動化によりテストコードを書くため、テスト仕様書の曖昧性が無くなる。
  • 何の観点でテストしたかの証拠とテスト時の環境を残しやすい。


製造・単体試験ツール

これはすごい!? コード品質のカイゼン化プラグイン2種
JUnit Factory:テストケースを自動生成するという優れもの。
http://www.atmarkit.co.jp/fjava/rensai3/eclipseplgn24/eclipseplgn24_1.html

単体試験項目自動作成ツール『おじどうくんDR4』
C向けに、Excel表で 単体試験を自動的につくってくれるツール。GNU Licence.Perlで動作。ちょっとすごいかも
http://park.ruru.ne.jp/ando/work/autoUt/index_ja.html

関連記事

なぜ自動化するのか?単体テスト自動化のメリットとデメリット

JUnitの役割はどこまで? 試験工程内で 単体テストのできることとできないこと

早わかり Junit 30分講座


試験作成について

試験作成はメンバーのためにも

ただ、グループで作業をしているので、個人でしか理解出来ない試験項目はNGです。 明確で曖昧さの無い試験項目を作成することも大事です。

なかなか、試験項目作成が始められないときは

試験項目作成のこつ

よくある試験作成ミス(アンチパターン)

よくある試験作成ミス(アンチパターン)

試験品質について

試験品質

上記で説明した、FTとの住み分けの観点を明確にすることで、漏れや過剰な試験が減少し、対象が明確になり、効率が上がるため試験工程全体の品質を上げることができます。

それ以外に重要なこととして、試験項目書そのものの品質を上げるには、 チェックリストや、過去の試験項目に知恵が詰まっているかもしれません。 過去の経験を活かすためにまずは、目を通すぐらいはしておきます。

もちろん過去の機能を知っているメンバーに早めに情報(ちょっと気づきにくいポイントや、関連モジュールやシステムの注意点、データ用意のポイント、試験実施のポイントなど)を貰っておくのも品質向上に役立ちます。

製造・単体試験ツール

http://findbugs.sourceforge.net/
find bugs本家のサイト。コンパイルされた classファイルを静的に解析し問題点を指摘してくれます。たまに鋭い指摘をもらってびっくりするときも。classファイルの解析なので、コードスタイルは指摘できません。
http://findbugs.sourceforge.net/
FindBugsの説明ページ(Eclips Plugin)
ソフトウェアの品質向上を支援するプラグイン
http://www.atmarkit.co.jp/fjava/rensai3/eclipseplgn02/eclipseplgn02_1.html

第2回 Eclipseで使える静的解析ツール
Checkstyle というソース向けの静的解析ツール。細かいコーディングスタイルを規定できる。
http://www.atmarkit.co.jp/fjava/rensai3/eclipsetst02/eclipsetst02_2.html

javaNCSS
複雑度や、非コメント行をチェックしてくれるツール。あまりに複雑なところは、気合入れてレビューするか、シンプルに作り直したほうが良いかも
http://www.kclee.de/clemens/java/javancss/

類似コンテンツ

単体試験と機能試験の違い

ウォータフォールモデルではテストファーストは当たり前?

デバッグ〜ソフトウエア開発手法で身につける問題解決力




RETURN > ウォータフォールモデル 目次へ 戻る



http://www2.ocn.ne.jp/~cheerful/develop/
since 2001/3/3
http://www2.ocn.ne.jp/~cheerful/develop/index.html