テストについて


※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

思いの向くままに、テストについて書いてみよう。

テスト以前に入力と対応する出力を定義する必要がある。
いや待て、そもそも入出力は定義可能なのか? 定義可能でないとすれば、開発を戦略的に行うことはできない。
従って、投資としてソフトウェア開発を行う場合は、戦略的に開発を行うことが必要なので、定義できる入出のみを扱えば良い。
構文解析機の例で考えよう。C++の変数宣言文パーサ。

入力は トークンの列
出力は 解析成功のときは構文情報、失敗のときは失敗の理由

これは、入出力の各々を独立に定義したもので入力と出力の関係の定義こそがエッセンスだ。
入出力の関係は以下の通り。

構文的に正しいトークン列 に対して 構文情報  が出力される。
構文的に誤ったトークン列 に対して 失敗の理由 が出力される。

テストは”入力、出力が正しいこと”を確認するのではなくて、”入力と出力のペアが正しい”ことを確認する作業になる。
ちょっと待て、入力トークンから、どうして構文的に正しいトークンに飛躍したんだろう。それは、構文解析機のことを考えているからだろう。論理レベルの入出力ではなく、そもそも要求される仕様からそう考えたんだろう。

では、先に進んで、正しい構文とは? いやその前に、C++の変数宣言文は? 型 文字列; が最も簡単な例。
  1. 1番目のトークンが型である
  2. 2番面のトークンが変数である
  3. 3番目のトークンがセミコロンである
の3つの条件を満たすトークン列が正しい入力値である。この3条件が正しいときには、変数の型と変数名を出力する。不正な入力の場合、

条件1が正しくないときは、A. 最初に型を書く必要がある旨
条件2が正しくないときは、B. 変数名は文字列である必要がある旨
条件3が正しくないときは、C. 宣言文の終わりにはセミコロンが必要である旨
条件1、2が正しくないときは、A
条件1、3が正しくないときは、B
条件2、3が正しくないとくは、C
条件1、2、3が正しくないときは、A

のメッセージを出力する必要がある。ここまでは、入出力の定義に過ぎない。
ここから、必要不可欠なテストケースをひねり出す必要がある訳だ。


疲れたから寝よう。












 z