ブラックボックステストの内容について

このQ&Aのポイント
  • ブラックボックステストの範囲と、テスト技法の「限界値分析」「同値分割」について知りたい
  • システム開発テストの単体テスト、結合テスト、システムテスト、運用テストの区別が曖昧で理解できない
  • ブラックボックステストはどの段階のテストに入るのか、ホワイトボックステストは単体テストで行われるという記述があるが、理科系ではないため理解できない
回答を見る
  • ベストアンサー

ブラックボックステストの内容について

ITパスポート試験を勉強中の者です。 テスト技法に「限界値分析」「同値分割」がありますが、これはどの段階でのテストなのでしょうか?ブラックボックステストの範囲で行われるテストなのでしょうか? システム開発テストには、単体テスト、結合テスト、システムテスト、運用テストがあり区別が曖昧でよく分かりません。 特に「同値分割、限界値分析」はテスト技法なのでブラックボックステストに限らず、各段階のテストでなされるテストだと思うのですが良く分かりません。ブラックボックステストの中だけで行われるテストなのでしょうか? とすれば、ブラックボックステストはどの段階のテストに入るのでしょうか? ホワイトボックステストは単体テストで行われると記述してありましたが・・・。 文化系で理科系ではないので良く分かりません。宜しくお願いします。

質問者が選んだベストアンサー

  • ベストアンサー
  • 0909union
  • ベストアンサー率39% (325/818)
回答No.1

>ブラックボックステストはどの段階のテストに入るのでしょうか? >ホワイトボックステストは単体テストで行われると記述してありましたが・ ブラックとか、ホワイトとかはイメージです。飛行機のフライトレコーダーをイメージするとわかるかと。あれは通称ブラックボックスです。外国の企業の物を(戦闘機など)買って、ライセンス生産する時、システムの電子機器を ブラックボックス(暗くて何も見えない=>何も中身はわからない) と表現しますね。そのイメージです。ホワイトとは、それとは逆の状況の時にいいます。 それで、わかりませんか? わからなければ、こちらの宣伝用サイトの概略で、 http://gihyo.jp/dev/serial/01/tech_station/0004 この短い文書で簡略に説明していますが、実は感じな事が抜けている。 両方とも、テスト手段の理論であって、考え方です。テストフェーズとは関係ありません。 ただ、テストフェーズの移行段階を追うと、ホワイトは、主に開発部隊内、ブラックは、それ以外が好ましい。 と言うレベルの物です。ようはどちらで行われなければ、ならないか。なんて決め付ける物ではありません。 普通、結合テストまでは、内部で行い、そこから先は、外部に委託する事が多い。内部とはコーダー及びそのアシスタントまでの人材。 テストフェーズは会社単位(チーム単位)で違うし、また時代とともに違う。 なので必然的に、ブラックは製品として世の中にでるレベルまで出来上がったフェーズ(結合、あるいはシステム)で行う事が多い。 しかも、このフェーズ移行は、業種レベルでも違う。例えば、金融や、原子力、医療、交通機関など、緻密さと正確さ、冗長性、堅牢性、耐久性、どれをとってもパーフェクトを求められる所では、 ダブルチェックが普通(同時変更で行われる)。つまり、ブラック+ホワイトを行う事になる。 なので、 >ホワイトボックステストは単体テストで行われると 一般を話しているのであって、実践ではない。そのようになることが多い、と言うだけの話。 例えば、実践では「限界値分析」は本来、コーダーのデバックレベルで行われていないといけない話で、それを行ったとしても、システムテスト、運用テストで、前のフェーズで行ったからといって、行っていない。又は評価対象になっていない。 これだけで、リスクがかなり大きくなる。実際、私がかかわったプロジェクトでも、システム以降のテストでやらなくていいと、上層部からお達しがあり(スケジュールの問題)、やらなかったせいで、現場のSEや、顧客からかなり苦情がきていた。開発側の説明だと限界値はない。といいはったが、それでは当然顧客は納得できなかった。 そこでやっと、プログラム的な限界値を提示してきたが、それでは実際その値はてすとされているのか。と突っ込まれた。この値は、ユーザー数が100億とかの数字になり、実際に起こりえる話ではない。顧客がもんだいにしているのは、その時システム全体のパフォーマンスを気にしていた。つまり、このパフォーマンスを出すための、マシンスペックにある。いくらかねかけたら、1ユーザーと同じパフォーマンスをだせるんだ。 という事。 この問題は、単に限界値は、ホワイトだから、単体。という問題ではない事をしめしている。 ただの手法なので、それぞれのテストフェーズで、スケジュールと金と相談して、取り入れるべき話なのだ。

CZD03316
質問者

お礼

さっそくの回答ありがとうございました。分かり易い説明で感心しました。 >一般を話しているのであって、実践ではない。そのようになることが多い、と言>うだけの話。 なるほど。そうなんですね。 テスト技術と考え方がごちゃ混ぜになっていました。やっぱり実務で活躍されている方の回答だと思います。机上で学ぶ知識は平面的で、全部並列のイメージでした。 この問題は、単に限界値は、ホワイトだから、単体。という問題ではない事をしめしている。 >ただの手法なので、それぞれのテストフェーズで、スケジュールと金と相談>して、取り入れるべき話なのだ。 実際には、この考え方でテストが行われているのですね。 どの本を読んでも曖昧な感じでした。本当にありがとうございました。m(_ _)m

その他の回答 (2)

  • layy
  • ベストアンサー率23% (292/1222)
回答No.3

結合テスト他以降の作業で不正が見つかると、さらに細かい視点でテスト実施になり、前のテストはうまくいってたのか?となります。単体テストやり直しです。どこかのテスト工程でホワイトボックステストしますが早い段階のが作業戻りが少ない。 実際システム使うユーザー側は値入力して結果が出るかに着目ですから、システムでどんな事しているかはさほど意識しない。ブラックボックスに近いです。 システム作るのも1つの製造業で、設計図、製造、テスト、検査あります。各部署で部品作って組み合わせ、稼動するか、ユーザーの環境と同等でどうか。性能はどうか、等段階あります。 試験では、これに設計時のレビューのタイプについても出るし、トップダウンテストとかの用語も絡みます。

CZD03316
質問者

お礼

回答ありがとうございます。 >結合テスト他以降の作業で不正が見つかると、さらに細かい視点でテスト>実施になり、前のテストはうまくいってたのか?となります。単体テストやり直しです。 なるほど、各フェーズごとに進んでも、うまく行かない場合はやり直す場合もあるんですね。 ケースバイカースでテストも臨機応変にやるという事でしょうね。 テキストに記載があるのは、一般論、原則論で実際は、ユーザーの要求や不具合の場合には柔軟な対応とそれに見合う各テストを行うと言うことでしょうか。 みなさんありがとうございました。 ベストアンサーは、開発者側から見たテストをご説明頂いた、#0909unionさんからの答えをベストアンサーにします。ありがとうございましたm(_ _)m。

  • layy
  • ベストアンサー率23% (292/1222)
回答No.2

>ホワイトボックステストは単体テストで行われると 「プログラムA」のテストをするときに、 プログラムAは何やっているのか着目する、しない。 例えば、 バラエティ番組のバツゲームで プラスチックケースに「物体」を入れて、 左右の空いているところから手を指しこんでみせるものあります。 バツゲームの本人からの視点は 中の「物体」が見えないのでブラックボックス、 視聴者からの視点は 透明で中の「物体」が見えるので(ブラックの逆で)ホワイトボックス、 イメージはそんな感じです。 テストにおいて、 プログラムの中を明確にしないといけないのは 単体テスト時がほとんどです。 【条件網羅】というのも学習してみると良いです。 「IT用語辞典バイナリ」サイトを参考。 IT用語辞典バイナリ > 分野別用語辞典 >産業・技術 > システム開発 http://www.sophia-it.com/word-category/%E7%94%A3%E6%A5%AD%E3%83%BB%E6%8A%80%E8%A1%93/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%96%8B%E7%99%BA

CZD03316
質問者

お礼

丁寧なご回答ありがとうございます。 >プラスチックケースに「物体」を入れて、 >左右の空いているところから手を指しこんでみせるものあります。 >バツゲームの本人からの視点は >中の「物体」が見えないのでブラックボックス、 >視聴者からの視点は >透明で中の「物体」が見えるので(ブラックの逆で)ホワイトボックス、 イメージはそんな感じです。 #0909unionnさん、layyさんの説明イメージで段々ブラックボックステストのイメージが湧いて来ました。 お二人ともありがとうございましたm(_ _)m。 単体テストって、大事なテストなんですね。テキストでは重要度合いが良く分かりませんでした。 特に、#0909unionさんは、現場の立場からご説明頂いたので、開発者側から見たご苦労が良く分かりました。SEって大変なのですね。

関連するQ&A

  • 授業で学んだブラックボックステストでわからなかったこと。

    こんにちは。 現在プログラミングを勉強しています。 本日の授業でブラックボックステストについて学びました。 ブラックボックステストでは、同値分割法と境界値分析について学びましたがわからなかったので質問させていただきます。 先生の問題:次の境界値を求めなさい。 有効同値範囲: 18≦年齢≦60 先生の答え:18,19,60,61 という事でした。 先生が出した問題なので問題に曖昧な部分もあると思いますが答えについて納得できません。 添付したのような図になると思うので、 境界値は【17,18,60,61】になるとおもうのですが、、、 正しい答えを教えてください。 お願いします。 参考URLなどあったらよろしくお願いします。

  • ホワイトボックステスト と ブラックボックステストの違い

    現在、PHPで簡単なアンケートフォームを作り、自らチェックリストを作る作業をしているのですが、その際に作る、「ホワイトボックステスト」と「ブラックボックステスト」のテスト項目がほとんど同じになってしまい、違いがよく分かりません。 ホワイトボックステスト:コードの中身に着目し、全てのコードを実行するテスト。 ブラックボックステスト:入出力に着目し、プログラムが仕様に沿った動きをするかをチェックするテスト。 ということは、だいたい把握しています。 しかし、実際にチェック項目を作ると大差ないチェック項目になりませんか? 何が違うのか教えてください。 例えば:名前(全角10文字)、年齢(半角3ケタ)、性別(ラジオボタン) のフォームを作り、条件入力にはエラーを表示するというプログラムのチェックリストです。 よろしくお願いします。

  • web系システムのテストについて

    web系システムにおけるテストについてですが、 一般的には単体テスト、結合テスト、システムテストなどありますが、 web系の場合、どこまでが単体でどこまでが結合でといった境界 がはっきりしません。 たとえば、サーバサイドのjavaの場合、JSP、javaScript、HTML、java など複数の要素が含まれており、なにをもって単体と呼ぶかがわか らず、strutsなどのフレームワークを利用した場合はさらに MVCと機能が分離するためさらにテストが複雑です。 テストフェーズ別の具体的な成果物や、テスト項目、 テスト内容などをご教授いただけないでしょうか。 よろしくおねがいします。

  • システム導入時のテスト種別について

    わたしは経理システムの更改に関わっておりますが、 コンピュータについては、苦手意識をもっています。 システムの入れ替えをするにあたり、ベンダから提示 されたスケジュールには、「単体」テスト、「結合」テスト 「総合」テスト、「ユーザ」テストと、4種類もテスト種類が あり、戸惑っています。 ベンダの技術者や、社内のシステム担当者に違いを 聞いてみたのですが、ユーザテスト以外は、わたしには 理解できませんでした。 単体・結合・総合といったテストについて、正確でなくて 構いませんので、猿にも解りそうなイメージをご教示 願えませんでしょうか。 よろしくお願いいたします。

  • 単体テスト、結合テスト、テスト仕様はどこまで詰め込む?

    今、テスト仕様書を作成しており、 みなさまのご意見が伺えたらと思って書き込みさせていただきました。 単体テスト、結合テストの仕様書を作っているのですが、 パターン数がやはりべらぼうに多いので、どこまでで 割り切るかで悩んでいます。 考えれば考えるほどパターン数は出てくるのですが、 それらを作る工数、テストする工数を考えると、 う~ん・・・という感じです。 100%バグのないシステムを作ることは不可能で、 そのコストは∞とされていますが、可能な限りそうしたいのは やまやまですが。 ある本には顧客が70%を望んでいるなら開発としては71%を達成できたらよく、それ以上を求めることは技術者のエゴと書いてありました。 確かにまずされない操作のテストパターンを大量に生成する時間があったら、クライアントはユーザビリティを上げるなどして欲しいはずです。 でも70%ってどうやって決めたらいいのでしょう? 何でもいいので皆さんどうされているか、アドバイスいただけたら幸いです。

  • テストケースの作成方法

    ソフトウェアのウォータフォール開発における 結合テストについて質問させていただきます。 私は、ソフトウェアテストの経験が浅く、テストにおける納期・品質・コスト・責任分担について、いろいろと悩んでおります。 1つの例として、ある処理をコンボボックスで指定した回数 (2回から10回まで選択可能) 繰り返すプログラムをブラックボックステストしようとしています。 (出力されるデータは、「繰り返し回数」個のレコードが含まれるファイルになります。) この場合のテストケースとしては、任意の「繰り返し回数」を1つ代表値として選択して、その回数処理が行われていることを1度確認すれば良いと考えているのですが、正しいでしょうか。 「繰り返し回数」 という入力値は、数値が違っていても同じグループ (同値グループ) の値であり、決められた範囲の有効な数値しか入力できないため、たとえば、5を代表値として選択してテストするだけで、すべての場合をテストしたと言えるのではないかと考えています。 テストケースとして、2回と 10回の2パターンをテストするものを良く見るのですが、それはどういった理由によるものなのでしょうか? -- 上記の場合に加えて、 出力データは「繰り返し回数」 3レコード毎に、改ページをして出力するという条件があった場合の考え方について質問いたします。 テストケースは、 単一ページ出力する「繰り返し回数」:2,3 複数ページ出力する「繰り返し回数」:4,5,6,7,8,9,10 のグループに分けて考え、任意の代表値を2パターンテストすればよい という考え方で正しいでしょうか。 -- ご教示いただければ、大変助かります。どうぞよろしくお願いいたします。

  • 同値分割について

    入力項目”コード”(整数値)の正常データ範囲が”101<=コード<=300”又は”601<=コード<=800”であるとき、同値分割(同値分析)に用いるテストデータの組み合わせとして、適切なものはどれか。 ア 0,200,500,700,900 イ 0,400,500,800,900 ウ 101,300,601,800 エ 150,250,650,750 答えは、アなんですがなぜなのかがわかりません。 解説をお願いします。

  • テスト、試験の方法について

    私は新人の社内SEです。主にCOBOLを使った設計、開発をしています。 プログラミングのテスト、試験の方法について、お伺いします。 私の会社は、試験の際のルールは特に決まっておらず、 そのプログラムが通るロジックが正常に動作するか、を網羅するくらいで、 あとはバグの条件を経験と勘で探ることをしています。 テスト不足で迷惑をかけることが多く、なんとかしたいと思い方方調べてみました。 すると、テストにはいろいろな手法があるらしい、ということがわかりました。 制御パステスト、境界値テスト、ホワイトボックステスト 、ブラックボックステスト ・・・分類と内容はまだよくわかりませんが、 世間一般ではこういった手法にのっとり行われるようだ、ということがわかりました。 Q1.私の会社のようなことをしているのは珍しいのでしょうか。 それともやはり経験と勘が頼りなのでしょうか。 Q2.ある手順にのっとって進めることで、ミスは減るのでしょうか。 外注、社内問いません。みなさんの状況と経験をお聞かせください。

  • テストフェーズで何をするか

    SI企業で勤めております。 恥ずかしい話ですが、開発の経験が少なく、 各テストフェーズでどういった観点のテストをするのか、 あまりわかっていません。 単体テストは、モジュール内の分岐やエラーハンドリングなど 網羅的に確認するとしてイメージがあります。 これ以外にも、 1.結合テスト 2.機能テスト 3.システムテスト など今まで耳にしました。 それぞれのテストでは、一般的にはこれをする、など 考え方や手法はあるのでしょうか?。 例えば以下のようなテストは、 どのテストでやれば良いのでしょうか?。 ・Webアプリでの画面遷移(ログインして一覧画面から、選択し更新~完了画面の表示) ・夜間バッチの正常終了(バッチは、ジョブスケジューラから起動) (ざっくりですみません、、) 「画面遷移」というのは、システム側(開発者側)から見た用語ですが、その画面遷移の 提供機能である、例えば「在庫参照」、「受注登録」は、ユーザから見た「機能」だと思います。 テストとしては、両方の観点でテストフェーズを設けるものでしょうか・・?。 アドバイスを頂ければ幸いです。

  • デバッグの方法を教えてください。経験談等も

    会社でデバッグしてと言われています。 デバッグの項目の洗い出し方を教えてください ホワイトボックステストとかブラックボックステストとか 限界値?境界値テスト等は資格試験の勉強で覚えたつもりです。 具体的にまず何から手おつけてよいのかわかりません 手順とかデバッグのロジック洗い出し方法の 具体的な方法を教えてください。 エクセルか何かに網羅したものを書き出した方がいいのでしょうか 会社にテスト仕様書みたいなものはないとの事です。 また、どうしてもテストデータとかを作るとき正常に 通る簡単なロジックのデータしか作っていないような気がします。 経験不足でテストデータを作るのも一苦労です。 会社で作っているシステム自体よく理解していないので テストデータを作るのも一苦労です。 ちなみに部署に配属されたばかりの新人です。