質問

対象のプログラムが、
どのような処理手順で実装されているかを「しらないまま」テストをする
つまり検査をする人が検査対象を
「どういうしくみかわからないけれどある働きをするもの（ブラックボックス）」としてテストをするので
ブラックボックステストと呼んでいます。

プログラムの機能仕様って、
「こういう入力には、こういう出力をすること」
が、羅列されているもののことです。

けっして、
「こういう手順でデータを加工して出力しなさい」
というものではありません。
これは実装仕様という物であって、機能仕様とは別物です。

なので、
機能仕様書にある全てのパターンの入力を食わせて、
その出力が、全部機能仕様書通りなら、Passです。

実際には、わざと機能仕様書には定義されていない、
いわゆる不正入力を食わせて、
重大な結果を生まないことを確認するということも、
必要なことがあります。
#ちゃんとしたところが作った機能仕様書には、
#最初から要件にありますけれど、
#実際には、いい加減な仕様書が多いから、
#こっそり追加でやっておくんです。
#あとから市場クレームがくる方がよっぽど怖いですから。

さらに、それどころではなくて、
でたらめな入力を山のように食らわせて、
それでも異常終了しないことを確認するという、
クラッシュミー（Crash me）テストなるものもありますが、
これは、もう、OSとか、ファームウェアとか、
ハードウェアのようなものに適用されるテストですね。
もっとも、病院、発電所、飛行機、宇宙船のような
ミッションクリティカルなところでは、
アプリケーションに対しても行っているかもしれません。
たぶん、質問者の方はこれと混同されていたのではないかと。

• 回答者：こういうのは品質保証部のお仕事 (質問から20時間後)
• 3

拍手ついでに、、、

＞機能やプログラムの仕様に関係なく
ここがおかしかったのは既出として、別の観点から言えば、
「機能やプログラムの仕様に無関係な人がテストする 」方が、理想的です。
何故なら、知ってる人間がやると、先入観や固定観念が邪魔をして、無意識の内に手抜きになったり、バグをバグとして認識しなかったりする場合があるから。
なので、テストケースは、誰にでも判るように作る（書く）必要があります。

どうやら、その辺の所とごっちゃになってたような気がしますねぇ。

• 回答者：ムーチョ (質問から16時間後)
• 0

私の会社のある製品で説明
（自分は、システム開発（ソフトウェアの開発）をしていました。）

ブラックボックステストは、入力と出力のみに特化してテストケースを作って
テスト（確認）します。
入出力が正しく動作しているかを確認するにも、マニュアル（機能仕様書）が
必要なんです。

【機能仕様書】
機能仕様書は、そういった入出力の遷移を記述しいているので、これを見ないと
テストケースを作れません。
テスト部門に機能仕様書をキチント提出します。
これは、仕様作成レビュー（製品の機能を決定する会議）での決定事項を
まとめた資料です。

テスト部門は、上記の仕様書を元に何通りにもわたるテストケースを作成します。
代表的なテストケースの例
・入力不整合の確認（数値のみを入力するところに文字列が入力できてしまわないか等）
・境界値チェック（入力値で９までしか入力できないのに、１０以上が入力できてしまわないか等）

テスト中には、当然仕様書の不備（仕様漏れといって、条件分岐（ifとか）のユースケース漏れによるバグ。また、仕様書自体の記述漏れ）が多く見つかります。

このテストが終了する辺りに、マニュアル作成が始まります。この時も機能仕様書を提出します。（マニュアル製作部門に）

＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃
＃　内部的には、システムを実装する上で、
＃　共有できる関数郡をまとめたdll仕様書を作成していました。
＃　部署によるのですが、私たちの部門では、ないとシステムが大きくて
＃　管理できなかったため、作成しました。
＃　これが、いわば内部設計仕様書というもので、プログラム実装者のみ
＃　が閲覧します。ブラックボックステストを実施するテスターに提供の
＃　義務はないし、見せても理解ができないものなのですが、これを使って
＃　テストするのが「ホワイトボックステスト」に相当すると思います。
＃　プログラムの内部に注目しているので、「ホワイトボックス」テスト
＃　になるのでしょう。
＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

実際は、ブラックボックステストしか行われていない状況ですね。。

• 回答者：いかっち (質問から12時間後)
• 2

まず，「処理結果のみをテストする」とした場合，何をもって処理結果の正誤を判断できるのでしょうか？
…という訳で，ななさんの認識（というか…少なくとも本問での説明）は不十分ですね．

「正誤の根拠をどこに求めるか？」となると，機能仕様やインタフェース仕様になります．

仕様は文書として残っているのが理想なのでしょうが，実際には口伝だったり，機能拡張などの場合は「今あるソースが現在の仕様」とかゆわれたりします（オープンソースのプログラムなんか，正にコレです…ま，ソースも文書と同等とも言えます）が，いずれにしろ「前提となる仕様」がどこかにある訳です（個人で作成しているなら脳内だけかもしれない）．
…仕様は紙や文書ファイルである必要は無いので，問題文でも「…仕様書」ではなく「…仕様」となっています．

ブラックボックステストというのは，「プログラムに求められる機能をすべて満たしているかどうかを確認する」のを目的としますので，プログラムの実際の作りは知っている必要がありません．なので，仕様があればテスト項目の設定やテスト自体もプログラマ以外の者が行うことができます．
なので，仕様にない部分についてはテストされない部分が出てきます．エラーとなるケースのすべてなどまで仕様に網羅していることはまず無いので，そもそもプログラムでは仕様に記述されていない挙動を含んでいます．
※仕様(書)の不備は別問題…本問の内容とズレるので割愛します．

それに対してホワイトボックステストというのは「プログラムの構造を意識し，各分岐において漏れが無いよう確認する」ことを目的としますので，プログラムの中身を知っていないとテストケースの設定ができません．
ホワイトボックステスト的な内容は単体テスト…部分的なテストにおいて行われるのが普通な気がします．

ご理解いただけましたでしょうか？（;´ω`）

• 回答者：greeneyes (質問から3時間後)
• 2

ブラックボックステストは、「ある入力を与えた時に仕様通りの出力をする事」をテストします。
「仕様通りの出力」が記載されている物が、プログラムの機能仕様書でありインタフェース仕様書です。

プログラムの世界では、仕様書が全てです。
プログラムが正しく動作しているかどうかは、仕様書通りに動いているかどうかで判断します。
あなたの言う「機能やプログラムの仕様に関係なく出入力が正しく行われたか」では問題です。
この文言だと、仕様書を見ずに入出力が正しいかを判定している事になります。
「何を基準に正しい／正しくないを判断したの？」と問いつめられてしまいます。

この世界にいると「どう考えてもプログラムが正しくて、仕様書が間違っている」という自体に遭遇します。（結構頻繁に）
こういう場合は、ブラックボックステストで「仕様書通りに動いていない。」という不具合を出して、「仕様書の不備であり、仕様書を修正する。」として解決します。

• 回答者：匿名希望 (質問から2時間後)
• 3