「テストについて」の編集履歴（バックアップ）一覧はこちら
「テストについて」(2008/06/20 (金) 00:18:04) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
思いの向くままに、テストについて書いてみよう。
テスト以前に入力と対応する出力を定義する必要がある。
いや待て、そもそも入出力は定義可能なのか？ 定義可能でないとすれば、開発を戦略的に行うことはできない。
従って、投資としてソフトウェア開発を行う場合は、戦略的に開発を行うことが必要なので、定義できる入出のみを扱えば良い。
構文解析機の例で考えよう。C＋＋の変数宣言文パーサ。
入力は トークンの列
出力は 解析成功のときは構文情報、失敗のときは失敗の理由
これは、入出力の各々を独立に定義したもので入力と出力の関係の定義こそがエッセンスだ。
入出力の関係は以下の通り。
構文的に正しいトークン列 に対して 構文情報 が出力される。
構文的に誤ったトークン列 に対して 失敗の理由 が出力される。
テストは”入力、出力が正しいこと”を確認するのではなくて、”入力と出力のペアが正しい”ことを確認する作業になる。
ちょっと待て、入力トークンから、どうして構文的に正しいトークンに飛躍したんだろう。それは、構文解析機のことを考えているからだろう。論理レベルの入出力ではなく、そもそも要求される仕様からそう考えたんだろう。
では、先に進んで、正しい構文とは？ いやその前に、C＋＋の変数宣言文は？ 型 文字列; が最も簡単な例。
+１番目のトークンが型である
+２番面のトークンが変数である
+３番目のトークンがセミコロンである
の３つの条件を満たすトークン列が正しい入力値である。不正な入力の場合、
条件1が正しくないときは、A. 最初に型を書く必要がある旨
条件2が正しくないときは、B. 変数名は文字列である必要がある旨
条件3が正しくないときは、C. 宣言文の終わりにはセミコロンが必要である旨
条件１、２が正しくないときは、A
条件１、３が正しくないときは、B
条件２、３が正しくないとくは、C
条件１、２、３が正しくないときは、A
のメッセージを出力する必要がある。ここまでは、入出力の定義に過ぎない。
ここから、必要不可欠なテストケースをひねり出す必要がある訳だ。
疲れたから寝よう。
z
思いの向くままに、テストについて書いてみよう。
テスト以前に入力と対応する出力を定義する必要がある。
いや待て、そもそも入出力は定義可能なのか？ 定義可能でないとすれば、開発を戦略的に行うことはできない。
従って、投資としてソフトウェア開発を行う場合は、戦略的に開発を行うことが必要なので、定義できる入出のみを扱えば良い。
構文解析機の例で考えよう。C＋＋の変数宣言文パーサ。
入力は トークンの列
出力は 解析成功のときは構文情報、失敗のときは失敗の理由
これは、入出力の各々を独立に定義したもので入力と出力の関係の定義こそがエッセンスだ。
入出力の関係は以下の通り。
構文的に正しいトークン列 に対して 構文情報 が出力される。
構文的に誤ったトークン列 に対して 失敗の理由 が出力される。
テストは”入力、出力が正しいこと”を確認するのではなくて、”入力と出力のペアが正しい”ことを確認する作業になる。
ちょっと待て、入力トークンから、どうして構文的に正しいトークンに飛躍したんだろう。それは、構文解析機のことを考えているからだろう。論理レベルの入出力ではなく、そもそも要求される仕様からそう考えたんだろう。
では、先に進んで、正しい構文とは？ いやその前に、C＋＋の変数宣言文は？ 型 文字列; が最も簡単な例。
+１番目のトークンが型である
+２番面のトークンが変数である
+３番目のトークンがセミコロンである
の３つの条件を満たすトークン列が正しい入力値である。この３条件が正しいときには、変数の型と変数名を出力する。不正な入力の場合、
条件1が正しくないときは、A. 最初に型を書く必要がある旨
条件2が正しくないときは、B. 変数名は文字列である必要がある旨
条件3が正しくないときは、C. 宣言文の終わりにはセミコロンが必要である旨
条件１、２が正しくないときは、A
条件１、３が正しくないときは、B
条件２、３が正しくないとくは、C
条件１、２、３が正しくないときは、A
のメッセージを出力する必要がある。ここまでは、入出力の定義に過ぎない。
ここから、必要不可欠なテストケースをひねり出す必要がある訳だ。
疲れたから寝よう。
z
