一般的なソフトウエアテスト手順を教えてください。


ある資格試験問題の回答では
「単体テスト⇒結合テスト⇒システムテスト⇒運用テスト」
と書いてありました。

またある参考書には
「ソフトウエア単体テスト(開発者)⇒ソフトウエア結合テスト(開発者)⇒ソフトウエア適格性確認テスト(開発者)⇒システム結合テスト(開発者・ユーザ)⇒システム適格性確認テスト(開発者・ユーザ)⇒受け入れテスト(ユーザ)⇒運用テスト(ユーザ・実稼働環境で)」
と詳しく書いてありました。

また、私の経験上は
「単体テスト(開発者)⇒結合テスト(開発者)⇒運用テスト(開発者が現地のテスト系統で)⇒システム検証(ユーザが現地のテスト系統で運用テスト仕様書を元に行う)」
です。

言い回しはいろいろあるのでしょうけど、
単なる言い回しの違いだけではないような気がします。
これは状況に応じて様々なパターンがあるということでしょうか?

また、少ない経験上ですが、現地のテスト系統で運用テスト後、本番データを本番系統へ移行し、本番系統でのテストはなく本稼働と思っていますが正しいでしょうか?

宜しくお願いします。

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2011/07/31 22:37:58
  • 終了:2011/08/01 22:54:05

ベストアンサー

id:a-kuma3 No.3

a-kuma3回答回数4619ベストアンサー獲得回数19552011/08/01 00:43:47

ポイント25pt

まず、気をつけたいのは「ソフトウェアのテスト」と「システムのテスト」は、イコールじゃない、というところだと思います。


現地のテスト系統で運用テスト後、本番データを本番系統へ移行し、本番系統でのテストはなく本稼働と思っていますが正しいでしょうか?

正しくないです。

テストというのは、ミスを検出するための手順だと考えれば、

  • 本番系に、一部のプログラムの修正、もしくは、マスタの変更を適用しなかった
  • 本番系は、ハード的に二重化されているが、その結線間違い
  • 本番系のハードの初期不良

などなど、プログラムのバグ以外にも、間違いが混入する原因はいろいろあります。


最後の例など、あり得ないだろう、と思うでしょうが、

実体験として、ソフトを入れ替えなくても、CPU のボードを交換しただけで、

ソフトウェアの不具合が解消されたことがあります。

CE いわく、宇宙線で CPU やメモリのパターンの一部だけが破壊されることが稀にあるのだとか。

# けっこう長く、こんな仕事をやってますが、一回だけしか経験はありません。


テストの分類については、いろいろな側面があるので、分け方もいろいろありますが、

「状況に応じて」というよりは、考え方によって変わってくる、というふうに

とらえた方が良いと思います。


id:kentaro_jpn さんが聞かれている範囲では、手順は、そう大きく変わりません。

それぞれの手順の中で、どこまでしつこくテストをやるか、という密度については、

場面というか状況に応じて変わってくると思います。

問題があったら困る、というのは同じですが、

原発の制御システムと、携帯のゲームで、同じレベルのテストはできないです。


# 経済的な側面もありますけど。



以下、ちょっと細かい話です。


「単体テスト⇒結合テスト⇒システムテスト⇒運用テスト」

ちょっと古い教科書の分け方ですね。


「単体テスト」

ソースひとつをコンパイルしてできるモジュールを、スタブとドライバを用意して、

そのソースのミスを検出するテストです。

「結合テスト」

複数のモジュールをリンクしてできる、業務をこなすプロセスに対するテストです。

モジュール間で受け渡すパラメータの間違いなんかを検出します。

「システムテスト」

複数のプロセスを動かすテストです。

単独で動かすと正しく動くが、同時に動かすと駄目、とか、

開発環境では動作するが、実環境で動かない、というような問題を検出します。

「運用テスト」

実際に、運用に応じた使い方をして正しく使えるかどうかテストします。

業務上、同時に使えないと駄目な機能が、同時に使えない、とか、

夜間バッチが、夜中のうちに完了しないとか、

そういったような問題を検出します。


「古い」というのは、開発環境が変わるにつれ、意味が無くなってきたものがあるからです。

例えば、VB でフォームにコードを記述するような類では、

フォーム単体では、ほぼ、動作するように作られませんし、

スタブやドライバをいちいち用意していると、VB だと(見た目の)生産性が上がる、

という利点を消してしまいます。


でも、コードの断片が正しく動くかどうかの検証をせずに、いきなり結合テストをすると

問題が続出するので、かえって生産性が悪い、みたいなことがあるので、

JUnit みたいな仕組みができてくるわけです。


後、古い教科書では、テストをだれの責任でやるべきか、みたいな話は、あまり言及されてません。

どちらかというと、ベンダーの責任の範囲内で規定されている面が強いです。

でも、現実には、ベンダー任せだと、問題が多いこともあるので、

今どきの開発プロセスでは、ユーザがシステム開発に参画すべき、というのが主流です。

その他の回答(3件)

id:taknt No.1

きゃづみぃ回答回数13539ベストアンサー獲得回数11982011/07/31 22:56:45

ポイント25pt

ソフトウェアの内容やレベルによって試験内容は 変わってきます。

人命に関わるような重要なソフトの場合、本番の環境を作成し、本番データを移行して 本番ではないが本番さながらのテストを 行う場合もありうるでしょう。

簡単に書けば

>「単体テスト⇒結合テスト⇒システムテスト⇒運用テスト」

という内容ですが、

それぞれ何をするのかを 詳細に書くとすれば 二番目の内容にもなりうりますよね。

ま、資格試験の内容としては どのように 評価すべきなのかは 難しいところですが。

id:km1981 No.2

km1981回答回数429ベストアンサー獲得回数492011/07/31 23:27:07

ポイント25pt

設計手順とテスト手順は密接に関係していて

  1. 要件定義書⇔運用テスト 【ユーザー責任】
  2. 基本(概念)設計書⇔システムテスト 【開発者・ユーザー共同責任】
  3. 詳細設計書⇔結合テスト 【開発者責任】
  4. プログラム設計書⇔単体テスト 【開発者責任】

という関係になってます

たとえば要件定義書に書かれていることはすべて運用テストで検証するという具合です

言葉の定義は会社によって違いますが

設計の順序とテストの順序が逆の関係になっていることは

(設計:1→2→3→4/テスト:4→3→2→1)

どの開発会社でも共通していると思います


以上はウォーターフォール開発での話

Webシステムなんかで流行のアジャイル開発では

(基本設計+詳細設計+プログラム設計)がワンセットで繰り返されるので

  1. 要件定義書⇔運用テスト
  2. 繰り返し(基本設計+詳細設計+プログラム設計)⇔システムテスト

という感じになります

でも設計手順とテスト手順が絡み合うことには変わりありません


>現地のテスト系統で運用テスト後、本番データを本番系統へ移行し、本番系統でのテストはなく本稼働と思っていますが正しいでしょうか?

合ってます

現地のテスト環境はユーザーの持ち物なので

ユーザー責任の運用テストだけ行うのが通則です

またセキュリティテストを本番環境でやる場合があります

id:a-kuma3 No.3

a-kuma3回答回数4619ベストアンサー獲得回数19552011/08/01 00:43:47ここでベストアンサー

ポイント25pt

まず、気をつけたいのは「ソフトウェアのテスト」と「システムのテスト」は、イコールじゃない、というところだと思います。


現地のテスト系統で運用テスト後、本番データを本番系統へ移行し、本番系統でのテストはなく本稼働と思っていますが正しいでしょうか?

正しくないです。

テストというのは、ミスを検出するための手順だと考えれば、

  • 本番系に、一部のプログラムの修正、もしくは、マスタの変更を適用しなかった
  • 本番系は、ハード的に二重化されているが、その結線間違い
  • 本番系のハードの初期不良

などなど、プログラムのバグ以外にも、間違いが混入する原因はいろいろあります。


最後の例など、あり得ないだろう、と思うでしょうが、

実体験として、ソフトを入れ替えなくても、CPU のボードを交換しただけで、

ソフトウェアの不具合が解消されたことがあります。

CE いわく、宇宙線で CPU やメモリのパターンの一部だけが破壊されることが稀にあるのだとか。

# けっこう長く、こんな仕事をやってますが、一回だけしか経験はありません。


テストの分類については、いろいろな側面があるので、分け方もいろいろありますが、

「状況に応じて」というよりは、考え方によって変わってくる、というふうに

とらえた方が良いと思います。


id:kentaro_jpn さんが聞かれている範囲では、手順は、そう大きく変わりません。

それぞれの手順の中で、どこまでしつこくテストをやるか、という密度については、

場面というか状況に応じて変わってくると思います。

問題があったら困る、というのは同じですが、

原発の制御システムと、携帯のゲームで、同じレベルのテストはできないです。


# 経済的な側面もありますけど。



以下、ちょっと細かい話です。


「単体テスト⇒結合テスト⇒システムテスト⇒運用テスト」

ちょっと古い教科書の分け方ですね。


「単体テスト」

ソースひとつをコンパイルしてできるモジュールを、スタブとドライバを用意して、

そのソースのミスを検出するテストです。

「結合テスト」

複数のモジュールをリンクしてできる、業務をこなすプロセスに対するテストです。

モジュール間で受け渡すパラメータの間違いなんかを検出します。

「システムテスト」

複数のプロセスを動かすテストです。

単独で動かすと正しく動くが、同時に動かすと駄目、とか、

開発環境では動作するが、実環境で動かない、というような問題を検出します。

「運用テスト」

実際に、運用に応じた使い方をして正しく使えるかどうかテストします。

業務上、同時に使えないと駄目な機能が、同時に使えない、とか、

夜間バッチが、夜中のうちに完了しないとか、

そういったような問題を検出します。


「古い」というのは、開発環境が変わるにつれ、意味が無くなってきたものがあるからです。

例えば、VB でフォームにコードを記述するような類では、

フォーム単体では、ほぼ、動作するように作られませんし、

スタブやドライバをいちいち用意していると、VB だと(見た目の)生産性が上がる、

という利点を消してしまいます。


でも、コードの断片が正しく動くかどうかの検証をせずに、いきなり結合テストをすると

問題が続出するので、かえって生産性が悪い、みたいなことがあるので、

JUnit みたいな仕組みができてくるわけです。


後、古い教科書では、テストをだれの責任でやるべきか、みたいな話は、あまり言及されてません。

どちらかというと、ベンダーの責任の範囲内で規定されている面が強いです。

でも、現実には、ベンダー任せだと、問題が多いこともあるので、

今どきの開発プロセスでは、ユーザがシステム開発に参画すべき、というのが主流です。

id:Baku7770 No.4

Baku7770回答回数2832ベストアンサー獲得回数1812011/08/01 00:57:00

ポイント25pt

http://akademeia.info/index.php?%A5%BD%A5%D5%A5%C8%A5%A6%A5%A7%A5%A2%A5%C6%A5%B9%A5%C8

 一般的なテスト工程というのはあるようで、実はありません。また大手のSIerなら独自の開発手法を確立していますので、単体テストもさらに幾つかの工程に分類されているのが常識です。

 少なくとも10年前の流行りは全ての工程を詳細に分けておいて、開発規模や要件に応じて、不要なテストを省くといったやり方です。

>「単体テスト(開発者)⇒結合テスト(開発者)⇒運用テスト(開発者が現地のテスト系統で)⇒システム検証(ユーザが現地のテスト系統で運用テスト仕様書を元に行う)」

 といったのを挙げられていますが、確かにそういった例もありますが、運用テストを開発者ではなく、ユーザが行う場合も多々ありますし、システム検証については私が経験している多くは本番系でテスト運用するというのが殆どですね。負荷が分らないですから。表現の違いだけかもしれませんが。

  • id:taknt
    >CPU のボードを交換しただけで、

    CPUのボードの破損なんじゃない?
    ハードはモノだから 壊れることはよくある話。
  • id:a-kuma3
    ボードの破損かもしれないんですが、すごく状況が不思議だったんです。
    光ケーブルを使ってるけど、IP レベルから自前のプロトコルを使った通信で、
    特定のステーションだけが受け取る、一部の電文だけデータのチェックサム計算が正しく行われなくて。
    パターンの断線とか、ハンダが浮くとかいう感じの状況じゃなかったんですね。

    「とりあえず、交換してみましょう」という CE さんの言葉を、
    僕も含めた SE 連中は、「そんなんで直ったら世話は無い」みたいなことを言ってたんですが、
    見事に問題が出なくなってしまいました。

    いまだに信じられないんですけどね。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません