テスト仕様を作る

SLPでテスト仕様を作ることができます。

多くの場合、テスト仕様はExcelを用いて条件の場合分けを行っています。しかし、条件が多くなった場合、その組み合わせをすべて網羅することは、手間がかかります。さらに、新たな条件を付け加えなければならなかった場合、手間に加えて、間違いが発生する原因にもなります。

SLPは、テスト条件の多数の組み合わせを機械的に行い、手間と間違いを防ぎます。規模の大きなテスト仕様書に、新たな条件を加えたり除いたりする場合に、SLPは有効です。

1. 事例

SLPでは、機能内容欄 (後述) の貼り付けという仕様を修正しましたが、その場合のテストの仕方を例にとります。

1.1 仕様の修正内容の説明

機能内容欄とは、ここです (図1)。SLPでは、この欄に要件を自然言語で書くことができます。また、さまざまなアプリケーションからコピー＆ペーストもできます。

ところが、この仕様を変更せざるを得ない事態が発生しました。機能内容欄に文字列を貼り付けると、稀に文字化けが発生するようになりました。この不具合を修正したのち、テストの仕様書を作ることが、今回のテスト仕様作成の事例です。

1.1.1 プログラム修正の試み

この文字化けに対して、プログラマーは、一度目の対応では、機能内容欄の内部のRTF (リッチテキストフォーマット) を修正しました。しかし、この修正では、カーソル位置がずれる、画面が揺れる、という2点の不具合が新たに発生しました。これは、リッチエディットコントロールの内部データを変更していたためです。

1.1.2 不具合の原因調査

調査したところ、SLPの今回の不具合は、他のアプリケーションのデータをコピーし、SLP内にペーストするときに発生しました。SLP内でのコピー＆ペーストは大丈夫でした。

また、同じような不具合は、他のアプリケーションでも、リッチテキストに関する場合に不具合が少なからず出ていました。SLPでも現象はリッチテキストの場合であることが判明しました。

原因を追究したところ、以下のことが分かりました。

原因は、リッチエディットコントロールの内部データを変更したためです。現象としては、カーソル位置が先頭に戻ってしまい、カーソル位置を復元する処理を入れましたが、マイクロソフトの画面制御仕様 (MFC, Microsoft Foundation Class) の通りにやっても動作しませんでした。また、内部データを変更する際に画面のちらつきを抑える処理をさまざまにトライしましたが、良い結果が得られませんでした。

そこで、次のように新たな仕様を決めました。他のアプリケーションでも同じような現象があるということもあり、リッチテキストへの対応をあきらめ、基本的にはテキストデータを貼り付ける仕様としました。

これによって、文字化けが発生しないこと、カーソル位置がずれないこと、画面が揺れないこと、貼り付けた文字列が既存のフォントと変わらないこと、の4点を修正・実装し、これら4点の実現を期待してテストしました。

1.2 テストされる組み合わせ

SLPの今回の不具合は、他のアプリケーションのデータをコピーし、SLP内にペーストするときに発生したので、このケースをテストすることにしました。

以下のように、ケース (条件) は大きく7ケースあり、ほとんどのケースはさらにいくつかのケース (条件) を持っています。条件の組み合わせが膨らむことが分かります。

貼り付けの操作は、Ctrl + V (貼り付け)、機能内容欄の右クリックメニュー (図2)、メインメニュー (図3) の3点です。
貼り付けられるデータ形式は、すでにコピーされている文字列または画像です。
データ形式が文字列のとき、貼り付け元のソフトウェアはPowerPoint、Word、メモ帳の3通りです。(PowerPointとWordでは、リッチテキストをコピーするときの扱いが異なります。)
データ形式が画像のとき、貼り付け元のソフトウェアはペイント (アプリケーション) です。
データ形式が文字列のとき、半角英数字、半角記号、全角文字という3種類の文字種に対して、期待される動作は、貼り付けた文字列が文字化けしないことと、貼り付けた文字列が既存のフォント (機能内容欄に既に書かれていたフォント) と変わらないことという2項目をテストします。
データ形式が画像のとき、期待される動作は、当然ながら画像が表示されるということです。この1項目が期待される動作です。
また、データ形式が文字列であるか画像であるかに関わらず、期待される動作は、カーソル位置がずれないことと、画面が揺れないことです。この2項目をテストします。

以上より、実施されるテスト項目の総数は、3×3×(3×2+1+2) = 81通りです。81通りのテスト仕様を手書きする (方法1) のは大変です。単純にコピー＆ペーストを繰り返すのは、楽そうではありますが、ケースが漏れる場合があり、ケースの数が多いと修正するのが大変なことがあります。また、漏れていることがすぐにはわからず、テストを行っている最中に発見される場合があります。これも大変な事態です。

実際に81通りのテスト項目をExcelで記述したものは、図4のようになります。(クリックすると一部大きな図になります。)

2. 用語の説明

ここで、テスト対象の理解をしていただくために、SLPで用いられる用語を説明します。

そもそもSLPとは、要求を記述するうえで一定の様式にしたがって記述していただくためのアプリケーションです。SLPはSyntax from a Logical Point of viewの略です。論理的な観点から要求を記述していただくための構文をソフト化したものです。以下、SLPで用いられる用語の説明をします。

2.1 単位機能

SLPで作成した文書 (SLP文書) は、単位機能の集まりです。テスト仕様の作成に使用するのは、単位機能の論理記述欄 (後述) です。

2.2 論理記述欄

論理記述欄は、構文の集まりです。構文の基本は、任意の条件のときに何々せよという条件文です。ただし、その条件が成立しない場合についても記述することにし、条件の漏れをなくするような構文になっています。また、条件文や何々せよという命令文は文の対象と対象の属性から構成されます。文の対象は<>の中に書き、文の属性は{}の中に書きます。すると、例えば「<文字>は{半角文字}である」は条件文を構成する文となります。さらに条件文はifを文の先頭に付けて条件を表現することとし、条件の反対はelseを付けて表現することとします。命令文は「<文字>を{全角文字}とせよ」などと記述し、先頭にDoを付けます。「は」や「を」などの助詞、「である」や「とせよ」などの助動詞は省くことができます。また、if、else、Doなどは他の記号に任意に置き換えることができます。

例えば

if <文字>が{全角文字}である
    Do <文字>が{既存のフォントと変わらない}
else
    Do <文字>が{既存のフォントと変わらない}
endif

endifはif-elseの終わりを指します。また、if-elseの構文はifがその中にifを持つように多重に記述することができます。elseの中にifを持つこともできます。

構文には、その他にFn構文があります。Fn構文は後述します。

2.3 Fn構文

Fn構文の「Fn」はfunctionの略です。Fn構文は、単位機能に名前 (ラベル) を付ける働きをします。多くの機能を1か所にまとめて書く場合、それに名前を付けます。章や節に命名することと似ています。

Fn構文は、その構文の中にFn構文を持つことができます。例えば、ある単位機能が多数の機能を持つ場合、その一部をFn構文として記述します。これにより、その単位機能の記述は、適度な数の機能の表現となります。

もちろん、これは機能を減らしたということではありません。新たに作成されたFn構文には、まとめられた機能が存在するからです。任意の単位機能にFn構文を作るのは、多すぎる機能を分類し、まとめ、簡潔な表現にするためです。

なお、機能の検討過程では、機能の「分割」を行う場合もあります。分割の場合も、上の「分類」と同じく、分割された機能にFn構文を適用できます。

ただし、Fn構文への命名は分かりやすいものにする必要があります。分類されたり、分割されたりする機能が一目でその内容が分かるようにするためです。

Fn構文も1つの単位機能です。したがって、任意の単位機能の中にFn構文を作る場合、その単位機能とFn構文とは親子の関係となります。

この親子関係は、機能に対してばかりではなく、ひろく概念 (あるいは、考えること) に対しても当てはまり、概念の上下関係、あるいは概念の階層関係ということもできます。SLPは、概念の階層関係を記述できます。

3. SLPによるテスト仕様の作成

テスト仕様とは、要求仕様をプログラムが満足しているかどうかをテストするためのものです。すでに、「テストされる組み合わせ」 (1.2) で、プログラムが満たすべき項目を書いています。項目は、「ユーザーがCtrl + Vを押した」、「ユーザーが機能内容欄を右クリックして「貼り付け」を選択した」、「ユーザーが「メインメニュー→編集→貼り付け」を選択した」の3点です。これらの3点のケース (条件) を満たすテスト仕様を作ることになります。

具体的には、SLPでの記述の仕方は、以下となります。

単位機能名を、例えば「操作方法」とします。そこで、この単位機能「操作方法」では、操作方法で「ユーザーがCtrl + Vを押した」、「ユーザーが機能内容欄を右クリックして「貼り付け」を選択した」、「ユーザーが「メインメニュー→編集→貼り付け」を選択した」の3通りの分岐を作ります。

それぞれの分岐においては、さらにコピーしたデータの形式 (文字列や画像) やコピー元が何であるか (PowerPoint、Word、メモ帳、ペイント) に応じて条件の組み合わせを作らなければなりません。これらの条件の組み合わせを、単位機能名「コピー元とデータ形式」と命名し、Fn構文として作ります。Fn構文は、さらに細かい条件の組み合わせが想定される上位の構文となります。

単位機能「コピー元とデータ形式」を詳細に述べます。まずデータ形式の違いで条件が「文字列」と「画像」に分かれます。

データ形式が文字列のとき、コピー元の違いで「PowerPoint」、「Word」、「メモ帳」に分かれます。さらに、それぞれの分岐から、単位機能「文字の種類」と単位機能「一般の期待される動作」に分かれます。これらはFn構文で表現します。

データ形式が画像のとき、コピー元は「ペイント」しかありません。そのため、文字列のときとは異なり、複数ケースを考える必要はありません。

データ形式が画像のときには、画像が所定の位置に張り付けられたか、かつ、そのときに画面が揺れないか、が期待される結果です。前者を「データ形式が画像のときの期待される動作」と命名し、後者を「一般の期待される動作」と命名し、それぞれ下位の単位機能 (Fn構文) とします。

単位機能「文字の種類による期待される動作の検査」では、文字の種類に応じた貼り付けが適切であるかを検査します。文字の種類とは、「半角英数字」、「半角記号」、「全角文字」なので、それらに応じた条件分岐を行います。貼り付けが適切であるか (期待される動作) は、貼り付けた文字が文字化けしないことと、貼り付けた文字列が既存のフォントと変わらないことです。これを単位機能「データ形式が文字列のときの期待される動作」と命名し、下位の単位機能 (Fn構文) とします。

単位機能「データ形式が文字列のときの期待される動作」では、期待される動作として「貼り付けた文字列が文字化けしない」と「貼り付けた文字列が既存のフォントと変わらない」をDo構文として記述します。

単位機能「データ形式が画像のときの期待される動作」では、期待される動作として「画像が表示される」をDo構文として記述します。

単位機能「一般の期待される動作」では、期待される動作として「カーソル位置がずれない」と「画面が揺れない」をDo構文として記述します。

SLPを用いて作成したテスト仕様書は、図7のようになります。論理記述欄に記述した条件文が自動的に図7のように展開されます。図7と先ほどの図4との違いは、各条件文をまとめて (可能なものは) AND条件 (連言) で簡潔にしていることです。(クリックすると一部大きな図になります。)

4. テスト仕様の変更

SLPでテスト仕様を作成していると、テスト仕様の変更も簡単です。例えば、期待される動作として、カーソル位置がずれないことと、画面が揺れないことの2項目を、文字種が半角英数字、半角記号、全角文字の場合 (3通り) について確認 (検証) したくなった場合を考えます。この場合、テスト項目の総数は、3×3×(3×(2+2)+1) = 117通りになります。

このとき必要なことは、単位機能「一般の期待される動作」を指しているFn構文を、単位機能「コピー元とデータ形式」から、単位機能「文字の種類」に移動するだけです。