Excel2003でも使用できる PictMaster 6.1.1J をリリースしました
PictMaster 6.1.1J をリリースしました。
Excel2003で使いたいという要望があるのでExcel2003で使用できる PictMaster v6.1.1 をリリースしました。確認はしていませんが Excel2000 でも動作すると思います。
このバージョンでは ver6.1 に対して以下の変更点があります。
【バグ修正】
・１つのパラメータでエイリアスかつ無効値である値が２つ以上ある場合に、その２つ以上の値を結果表で同一の期待する結果として同時に指定すると生成結果に結果表の指定が正しく反映されなかったバグを修正した。
・ある特定の複雑な制約を指定した場合、現状のCIT-BACHで正しくない生成結果が出力される問題があり、その問題を修正したバージョン1.02 のCIT-BACHを同梱した。
【その他】
・Excel2003でも動作するPictMasterが必要との要望にこたえるため、Excel2003に対応した旧バージョンを修正してリリースした。
PictMaster 6.1.1J は次のサイトからダウンロードすることができます。
https://osdn.jp/projects/pictmaster/
Excel2003で使いたいという要望があるのでExcel2003で使用できる PictMaster v6.1.1 をリリースしました。確認はしていませんが Excel2000 でも動作すると思います。
このバージョンでは ver6.1 に対して以下の変更点があります。
【バグ修正】
・１つのパラメータでエイリアスかつ無効値である値が２つ以上ある場合に、その２つ以上の値を結果表で同一の期待する結果として同時に指定すると生成結果に結果表の指定が正しく反映されなかったバグを修正した。
・ある特定の複雑な制約を指定した場合、現状のCIT-BACHで正しくない生成結果が出力される問題があり、その問題を修正したバージョン1.02 のCIT-BACHを同梱した。
【その他】
・Excel2003でも動作するPictMasterが必要との要望にこたえるため、Excel2003に対応した旧バージョンを修正してリリースした。
PictMaster 6.1.1J は次のサイトからダウンロードすることができます。
https://osdn.jp/projects/pictmaster/
PictMaster 6.3J をリリースしました
PictMaster 6.3J をリリースしました。主な変更点は以下の通りです。
【機能改善】
・最小テストケース生成およびカバレッジを指定して生成で、プログレスバーを表示する／しないを環境設定で指定できるようにした。
・生成エンジンにCIT-BACHを使用した場合でも最小テストケース生成でプログレスバーの表示が可能となるようにした。
・最小テストケース生成およびカバレッジを指定して生成を実行中に、ESCキーを押して実行を中止した場合にVBAのダイアログが表示されないようにし、ワークファイルおよびワーク用のシートの削除を行なうようにした。
・環境設定の数値入力欄で入力内容が全角文字の場合にエラー表示を行なうようにした。
【バグ修正】
・ウインドウ分割を行なった状態でテストケース生成を行なうとVBAのエラーとなるバグを修正した。
・Excel2013を使用して「カバレッジを指定して生成」を実行した際に、プログレスバーが表示されない場合があるバグを修正した。
PictMaster 6.3J は次のサイトからダウンロードすることができます。
https://osdn.jp/projects/pictmaster/
【機能改善】
・最小テストケース生成およびカバレッジを指定して生成で、プログレスバーを表示する／しないを環境設定で指定できるようにした。
・生成エンジンにCIT-BACHを使用した場合でも最小テストケース生成でプログレスバーの表示が可能となるようにした。
・最小テストケース生成およびカバレッジを指定して生成を実行中に、ESCキーを押して実行を中止した場合にVBAのダイアログが表示されないようにし、ワークファイルおよびワーク用のシートの削除を行なうようにした。
・環境設定の数値入力欄で入力内容が全角文字の場合にエラー表示を行なうようにした。
【バグ修正】
・ウインドウ分割を行なった状態でテストケース生成を行なうとVBAのエラーとなるバグを修正した。
・Excel2013を使用して「カバレッジを指定して生成」を実行した際に、プログレスバーが表示されない場合があるバグを修正した。
PictMaster 6.3J は次のサイトからダウンロードすることができます。
https://osdn.jp/projects/pictmaster/
市場障害の８割は「考慮漏れ」が原因で起きている
製品出荷後にユーザ先で起きるいわゆる市場障害は何が原因で起きているのでしょうか。市場障害の発生原因を分析することで障害の見逃しを防ぐことの理解に役立てることができます。障害がテストの不備で見逃されたのであればテスト方法を改善する必要があります。障害が設計の不備で作りこまれたものであれば設計方法を改善する必要があります。実際にはこの２つが同時に起きているために市場障害が起きていると言えます。
障害が何を原因として起きているかは、障害発生原因の分類を明確にしなければなりません。この障害原因の分類方法には様々な考え方がありえます。重要なことは、その分類方法が今後の障害の見逃しを防ぐ方法に対する理解が得られるものである必要があります。そしてその障害原因は開発担当者とテスト担当者で共有されなければなりません。開発担当者はなぜ障害を作りこんでしまったのか。テスト担当者はなぜ障害を見逃してしまったのか。その障害原因の分類からそうした洞察が得られるものである必要があります。
障害発生原因の分類と似ているようで違うものがあります。例えば「障害区分」などとして、その障害が開発工程や開発作業のどの局面で起きたか、あるいは障害の種類を分類したものです。そのいくつかの例をあげてみます。
・機能の定義誤り
・機能の欠如
・アルゴリズム／制御の誤り
・インターフェース誤り
・タイミングの誤り
・エラーチェックの誤り
・リソースの誤り
これらの分類では、障害がプログラムや仕様のどの部分で起きたかは分かりますが、なぜそうした障害を作りこんでしまったのか、なぜそうした障害をテストで発見できなかったのかといった障害発生原因そのものの分析には役に立ちません。障害発生原因そのものに焦点を当てた分類が必要です。
次のグラフはある製品出荷後に市場で見つかった障害の発生原因を分類したものです。
制御手順不正
正しくない処理を行なっていた。
条件の考慮漏れ
考慮すべき条件を考慮していなかった。
調査不足
処理の変更・追加を行なった際に、それによって影響を受ける部分の調査が不足していた。
コーディングミス
コーディングの誤り
シーケンス不正
メッセージの衝突や受信順序の逆転が起きた場合の処理に誤りがあった。
情報要素値不正
システムデータなどの設定値が誤っていた。
その他
これには仕様変更を他の担当者に周知していなかったなど、さらに細かい分類がありますが、分類が多くなりすぎるのでここでは上にあげた以外のその他の分類をすべてその他としてまとめたものです。
この分類結果では、「条件の考慮漏れ」は障害発生原因の２割にとどまっています。これは少ないなと思い、「制御手順不正」に分類されている障害内容を調べてみたところ、「考慮漏れ」が原因であるとみなすべき障害が数多く見つかりました。「調査不足」と分類されている障害は、必要な調査が漏れていたということとほぼ同じですから、これはほとんど考慮漏れに分類される障害です。「コーディングミス」に分類されている障害を調べてみたところ、純粋なタイプミスが原因である障害は意外と少なく、考慮漏れに分類すべき障害がかなりの割合で見つかりました。
ごく大雑把にいって、制御手順不正の８割、条件の考慮漏れの１０割、調査不足の９割、コーディングミスの７割、シーケンス不正の８割、情報要素値不正の６割、その他の５割。全体で市場障害の８割が広い意味での「考慮漏れ」が原因で発生していると見られます。例えば、「仕様変更を他の担当者に周知していなかった」という原因は、他の担当者に周知することが考慮から漏れていたために起きたのであり、広い意味での考慮漏れに該当します。また「考慮漏れ」のおおよそ７割が「例外条件」の考慮漏れが原因で障害となっているようです。その中でも比較的多いのが他の機能と組み合わせて動作した場合のことが考慮から漏れている例がかなりありました。
それではなぜ障害発生原因を考慮漏れとすべきなのに制御手順不正などと別の分類にしてしまうのでしょうか。そこには開発者特有の心理が関係している可能性がありそうです。これは推測に過ぎませんが、開発者が作りこんでしまった障害がなぜ発生したかと理由を分類分けするとき、「考慮漏れ」とするよりも、「制御手順不正」とか、「コーディングミス」とかにしたほうが精神的に楽だからなのかもしれません。考慮漏れとすると、「本来考慮すべきであったのにそれを怠った」というニュアンスを帯びることになります。制御手順不正とか、単純なコーディングミスとかの場合より、考慮漏れは開発者の責任がより強く意識される傾向があるために、往々にして考慮漏れではなく制御手順不正とか、コーディングミスとかに分類しがちになるのかもしれません。
市場障害の８割が考慮漏れが原因で起きているとして、それを防ぐにはどうしたらよいでしょうか。考慮漏れには例外的な条件が考慮されていなかったという狭い意味での考慮漏れから、仕様変更を他の担当者に周知していなかったという広い意味での考慮漏れまでが含まれます。また思い込みで作りこみを行なってしまい、現実を見ることを怠ったということも広い意味での考慮漏れに含まれるでしょう。
なぜ考慮漏れが起きるかと分析しようとして、考慮が漏れる原因をことこまかに分類しようとすればできないことではありませんが、それで考慮漏れを防ぐことができるようになるとは思えません。なぜなら、市場障害になるほどの障害はそれぞれが極めて特殊であり、独特であり、特有であり、何かに分類分けすること、そこから何かの教訓らしきものを得ることがはなはだ困難だという事情があるからです。何か言えるとすれば、「例外条件」の考慮漏れが多い、「思い込み」による考慮漏れがある、といったことぐらいです。
考慮漏れを防ぐには方法は、開発担当者とテスト担当者では当然違ってきます。開発担当者は、開発の各段階で何か考慮すべきことを怠っていないかあらゆる場面で確認しておく必要があります。レビューの場においては、なかなか気づけない極めて例外的な条件についての考慮漏れがないか常にチェックする心構えが必要となります。テスト担当者には、開発者が考慮漏れを起こしそうなあらゆるイリーガルな条件の組み合わせでの動作を確認していく姿勢が求められます。
開発担当者はシステムの仕組みを知っているために、その視点から考慮を怠っている点はないかを確認することになります。テスト担当者はシステムの仕組みを知らないので、開発担当者のような確認の仕方はできませんが、開発担当者ではないからこその視点を持つことができます。ここで威力を発揮するのが「エラー推測テスト」です。開発者は機能が正常に動作するかを確認するためにテストを行ないますが、テスト担当者はバグを見つけるためにテストを行ないます。この目的の違いが開発担当者では見逃してしまう障害を、テスト担当者が見つけられる理由になっています。
エラー推測テストについては「テストの観点をどう決めるか」という記事が役に立つでしょう。
障害が何を原因として起きているかは、障害発生原因の分類を明確にしなければなりません。この障害原因の分類方法には様々な考え方がありえます。重要なことは、その分類方法が今後の障害の見逃しを防ぐ方法に対する理解が得られるものである必要があります。そしてその障害原因は開発担当者とテスト担当者で共有されなければなりません。開発担当者はなぜ障害を作りこんでしまったのか。テスト担当者はなぜ障害を見逃してしまったのか。その障害原因の分類からそうした洞察が得られるものである必要があります。
障害発生原因の分類と似ているようで違うものがあります。例えば「障害区分」などとして、その障害が開発工程や開発作業のどの局面で起きたか、あるいは障害の種類を分類したものです。そのいくつかの例をあげてみます。
・機能の定義誤り
・機能の欠如
・アルゴリズム／制御の誤り
・インターフェース誤り
・タイミングの誤り
・エラーチェックの誤り
・リソースの誤り
これらの分類では、障害がプログラムや仕様のどの部分で起きたかは分かりますが、なぜそうした障害を作りこんでしまったのか、なぜそうした障害をテストで発見できなかったのかといった障害発生原因そのものの分析には役に立ちません。障害発生原因そのものに焦点を当てた分類が必要です。
次のグラフはある製品出荷後に市場で見つかった障害の発生原因を分類したものです。
制御手順不正
正しくない処理を行なっていた。
条件の考慮漏れ
考慮すべき条件を考慮していなかった。
調査不足
処理の変更・追加を行なった際に、それによって影響を受ける部分の調査が不足していた。
コーディングミス
コーディングの誤り
シーケンス不正
メッセージの衝突や受信順序の逆転が起きた場合の処理に誤りがあった。
情報要素値不正
システムデータなどの設定値が誤っていた。
その他
これには仕様変更を他の担当者に周知していなかったなど、さらに細かい分類がありますが、分類が多くなりすぎるのでここでは上にあげた以外のその他の分類をすべてその他としてまとめたものです。
この分類結果では、「条件の考慮漏れ」は障害発生原因の２割にとどまっています。これは少ないなと思い、「制御手順不正」に分類されている障害内容を調べてみたところ、「考慮漏れ」が原因であるとみなすべき障害が数多く見つかりました。「調査不足」と分類されている障害は、必要な調査が漏れていたということとほぼ同じですから、これはほとんど考慮漏れに分類される障害です。「コーディングミス」に分類されている障害を調べてみたところ、純粋なタイプミスが原因である障害は意外と少なく、考慮漏れに分類すべき障害がかなりの割合で見つかりました。
ごく大雑把にいって、制御手順不正の８割、条件の考慮漏れの１０割、調査不足の９割、コーディングミスの７割、シーケンス不正の８割、情報要素値不正の６割、その他の５割。全体で市場障害の８割が広い意味での「考慮漏れ」が原因で発生していると見られます。例えば、「仕様変更を他の担当者に周知していなかった」という原因は、他の担当者に周知することが考慮から漏れていたために起きたのであり、広い意味での考慮漏れに該当します。また「考慮漏れ」のおおよそ７割が「例外条件」の考慮漏れが原因で障害となっているようです。その中でも比較的多いのが他の機能と組み合わせて動作した場合のことが考慮から漏れている例がかなりありました。
それではなぜ障害発生原因を考慮漏れとすべきなのに制御手順不正などと別の分類にしてしまうのでしょうか。そこには開発者特有の心理が関係している可能性がありそうです。これは推測に過ぎませんが、開発者が作りこんでしまった障害がなぜ発生したかと理由を分類分けするとき、「考慮漏れ」とするよりも、「制御手順不正」とか、「コーディングミス」とかにしたほうが精神的に楽だからなのかもしれません。考慮漏れとすると、「本来考慮すべきであったのにそれを怠った」というニュアンスを帯びることになります。制御手順不正とか、単純なコーディングミスとかの場合より、考慮漏れは開発者の責任がより強く意識される傾向があるために、往々にして考慮漏れではなく制御手順不正とか、コーディングミスとかに分類しがちになるのかもしれません。
市場障害の８割が考慮漏れが原因で起きているとして、それを防ぐにはどうしたらよいでしょうか。考慮漏れには例外的な条件が考慮されていなかったという狭い意味での考慮漏れから、仕様変更を他の担当者に周知していなかったという広い意味での考慮漏れまでが含まれます。また思い込みで作りこみを行なってしまい、現実を見ることを怠ったということも広い意味での考慮漏れに含まれるでしょう。
なぜ考慮漏れが起きるかと分析しようとして、考慮が漏れる原因をことこまかに分類しようとすればできないことではありませんが、それで考慮漏れを防ぐことができるようになるとは思えません。なぜなら、市場障害になるほどの障害はそれぞれが極めて特殊であり、独特であり、特有であり、何かに分類分けすること、そこから何かの教訓らしきものを得ることがはなはだ困難だという事情があるからです。何か言えるとすれば、「例外条件」の考慮漏れが多い、「思い込み」による考慮漏れがある、といったことぐらいです。
考慮漏れを防ぐには方法は、開発担当者とテスト担当者では当然違ってきます。開発担当者は、開発の各段階で何か考慮すべきことを怠っていないかあらゆる場面で確認しておく必要があります。レビューの場においては、なかなか気づけない極めて例外的な条件についての考慮漏れがないか常にチェックする心構えが必要となります。テスト担当者には、開発者が考慮漏れを起こしそうなあらゆるイリーガルな条件の組み合わせでの動作を確認していく姿勢が求められます。
開発担当者はシステムの仕組みを知っているために、その視点から考慮を怠っている点はないかを確認することになります。テスト担当者はシステムの仕組みを知らないので、開発担当者のような確認の仕方はできませんが、開発担当者ではないからこその視点を持つことができます。ここで威力を発揮するのが「エラー推測テスト」です。開発者は機能が正常に動作するかを確認するためにテストを行ないますが、テスト担当者はバグを見つけるためにテストを行ないます。この目的の違いが開発担当者では見逃してしまう障害を、テスト担当者が見つけられる理由になっています。
エラー推測テストについては「テストの観点をどう決めるか」という記事が役に立つでしょう。
PICTの組み合わせ生成に長時間かかるケースとその解決策
PictMasterでは、PICTとCIT-BACHの二つの生成エンジンが使えますが、制約指定が複雑で生成に長時間かかる場合はCIT－BACHを使うとして、そうでない場合にはPICTを使わなければならないことがあります。例えば、組み合わせるパラメータ数に１を指定したい場合がそうです。徹底したテストが必要な新機能のテストでは組み合わせテストにしなければなりませんが、そうでない既存機能のテストでは組み合わせを行なわず、要因を列挙するだけにしたいといった場合です。
残念ながらCIT-BACHでは、組み合わせるパラメータ数に１を指定することができません。そこでPICTの出番となります。ただし、PICTでは複雑な制約を指定した場合に生成に長時間かかる場合があります。今回、こうした現象が複雑な制約ではなく、比較的単純な制約指定でも起きることが分かりました。さらに調査の結果、この問題の解決策も分かりました。
次のモデルは比較的な単純な制約指定ですが、この組み合わせ生成には26秒かかります（Core i5 3.1GHz）。
単純な制約指定で生成に長時間かかるようになる条件は次の通りです。
(1) 制約条件で指定する値の数が10個以上と多い
(2) 制約条件の指定が２つあり、一方で少数の値だけを指定し、もう一方で残りの多くの値を指定している
(3) 多くの値を制約条件に指定している制約で、同時に制約対象として多くのパラメータの値を指定している
この３つの条件を満たす制約指定が存在すると生成に時間がかかるようになります。
この現象はPICTのインプリメントに問題があるために発生しているようです。制約条件で指定する値が値の並びのどこに位置していようが、論理的に考えて組み合わせ生成時間に違いの出るはずがないのですが、奇妙なことに大きな違いが出てしまっています。
この問題は、他の制約が絡んでくるともっと深刻な影響を及ぼします。多くの制約を指定すると、それらの相互作用の結果として生成に極めて長時間、あるいはいつまでたっても生成が完了しないということになるのです。
次のモデルは先ほどのモデルに制約が１つ追加になっただけですが、１時間たっても生成が完了しませんでした。
PICTでは、パラメータとパラメータの制約を指定すると生成に時間がかかるようになることはこれまで知られていました。しかし、そうした制約がなく、パラメータと値の制約のみでも時間がかかるケースがまれですが存在します。おそらくそうしたケースではここで指摘した事態が生じている可能性があります。
組み合わせるパラメータ数に１を指定したい場合や、いくつかのパラメータのみ他のパラメータとは異なるパラメータ組み合わせ数を指定したいといった場合には、CIT-BACHではなくどうしてもPICTを使う必要があります。PICTを使って生成に時間がかかって困った時は、ここで説明した条件と合致していないか確認してみてください。
残念ながらCIT-BACHでは、組み合わせるパラメータ数に１を指定することができません。そこでPICTの出番となります。ただし、PICTでは複雑な制約を指定した場合に生成に長時間かかる場合があります。今回、こうした現象が複雑な制約ではなく、比較的単純な制約指定でも起きることが分かりました。さらに調査の結果、この問題の解決策も分かりました。
次のモデルは比較的な単純な制約指定ですが、この組み合わせ生成には26秒かかります（Core i5 3.1GHz）。
単純な制約指定で生成に長時間かかるようになる条件は次の通りです。
(1) 制約条件で指定する値の数が10個以上と多い
(2) 制約条件の指定が２つあり、一方で少数の値だけを指定し、もう一方で残りの多くの値を指定している
(3) 多くの値を制約条件に指定している制約で、同時に制約対象として多くのパラメータの値を指定している
この３つの条件を満たす制約指定が存在すると生成に時間がかかるようになります。
この現象はPICTのインプリメントに問題があるために発生しているようです。制約条件で指定する値が値の並びのどこに位置していようが、論理的に考えて組み合わせ生成時間に違いの出るはずがないのですが、奇妙なことに大きな違いが出てしまっています。
この問題は、他の制約が絡んでくるともっと深刻な影響を及ぼします。多くの制約を指定すると、それらの相互作用の結果として生成に極めて長時間、あるいはいつまでたっても生成が完了しないということになるのです。
次のモデルは先ほどのモデルに制約が１つ追加になっただけですが、１時間たっても生成が完了しませんでした。
PICTでは、パラメータとパラメータの制約を指定すると生成に時間がかかるようになることはこれまで知られていました。しかし、そうした制約がなく、パラメータと値の制約のみでも時間がかかるケースがまれですが存在します。おそらくそうしたケースではここで指摘した事態が生じている可能性があります。
組み合わせるパラメータ数に１を指定したい場合や、いくつかのパラメータのみ他のパラメータとは異なるパラメータ組み合わせ数を指定したいといった場合には、CIT-BACHではなくどうしてもPICTを使う必要があります。PICTを使って生成に時間がかかって困った時は、ここで説明した条件と合致していないか確認してみてください。
パズルを解くような組み合わせテスト マスター／スレーブシステムでのテスト
先日、組み合わせテストで面白い事例があったのでこれを取り上げてみたいと思います。これはビジネスホンシステムの機能のひとつである着信代理応答を、マスター／スレーブシステムでテストするというものです。着信代理応答とは、ある電話機にかかってきた着信に別の電話機から代わって応答できる機能です。マスター／スレーブシステムとは、例えば本社にマスターシステムを設置し、支社にスレーブシステムを設置して本社－支社間で内線通話が行なえるシステムです。また1つの大きなオフィスで部署ごとにマスターまたはスレーブシステムを設置するという使用形態もあります。でマスターシステムはスレーブシステムでの接続を制御します。
この機能のテストでは同時に３台の電話機（端末）を使用します。１台は発信端末、別の１台は着信端末、もう１台は着信に代理応答する応答端末です。実際の運用ではほとんどの場合、同じシステム内の着信に代理応答することになりますが、他のシステムでの着信に代理応答するという使い方がされないという保証はありません。機能上は他のシステムでの着信に代理応答が可能なので、そうした条件でのテストも必要になります。
このテストを行なうシステムの構成図を次に示します。
スレーブ２システムの２台の端末は、着信端末と代理応答端末です。スレーブ３システムの１台の端末は代理応答端末です。スレーブ３システムに代理応答端末しか必要としない理由はこれから説明していきます。
このテストでは組み合わせテストのパラメータとして発信システム、着信システム、応答システムの３つを用います。これは発信端末、着信端末および代理応答端末がどのシステムに収容されている端末かを意味します。
パラメータとしての発信システムには値としてマスターとスレーブ１を定義します。スレーブ２とスレーブ３を定義しないのは、マスターシステムから見て発信端末がスレーブ１であってもスレーブ２であっても制御形態上の違いがないため、ここではスレーブ１から発信するとしているからです。
パラメータとしての着信システムには値としてマスター、スレーブ１およびスレーブ２を定義します。ここでスレーブ１とスレーブ２の２つのスレーブシステムが必要となるのは、発信システムがスレーブ１で着信システムもスレーブ１の場合と、発信システムがスレーブ１で着信システムがスレーブ２の場合があるからです。この２つの場合は、マスターシステムから見て制御形態が異なるためにどちらもテストする必要があります。
パラメータとしての応答システムには値としてマスター、スレーブ１、スレーブ２およびスレーブ３のすべてのシステムを定義します。応答システムにスレーブ３まで必要となるのは、発信システムがスレーブ１、着信システムがスレーブ２、応答システムがスレーブ３の場合をテストする必要があるからです。
この組み合わせテストのモデルを次に示します。
制約１
発信システムがマスターの場合、着信システムはマスターまたはスレーブ１だけでよいこと。応答システムにはスレーブ３は必要ないことを定義しています。発信システムがマスターであることは、着信システムがスレーブ１であれば応答システムとしてスレーブが必要となるのは着信システムと応答システムが同じであるスレーブ１が応答の場合と、着信システムと応答システムが異なるスレーブ２が応答の場合の２通りをテストすればよいことになります。
制約２
発信システムと着信システムがともにマスターである場合、応答システムとしてテストする必要がある組み合わせはマスターとスレーブ１の２通りだけであることを定義しています。
制約３
発信システムがスレーブ１で着信システムがマスターである場合、応答システムとしてテストする必要のある組み合わせはマスター、スレーブ１およびスレーブ２の３通りだけであることを定義しています。
制約４
発信システムと着信システムがともにスレーブ１である場合、応答システムとしてテストする必要がある組み合わせはマスター、スレーブ１およびスレーブ２の３通りだけであることを定義しています。
以上のモデルで生成したテストケースを次に示します。
今回の組み合わせテストでは、各パラメータの値の決め方が重要です。スレーブが発信システムとなる場合にはスレーブ１だけをテストすればよいということに気がつけば後の組み合わせは比較的簡単に決めることができます。
組み合わせテストでは時々今回のようにパズルを解くような問題に遭遇することがあります。
この機能のテストでは同時に３台の電話機（端末）を使用します。１台は発信端末、別の１台は着信端末、もう１台は着信に代理応答する応答端末です。実際の運用ではほとんどの場合、同じシステム内の着信に代理応答することになりますが、他のシステムでの着信に代理応答するという使い方がされないという保証はありません。機能上は他のシステムでの着信に代理応答が可能なので、そうした条件でのテストも必要になります。
このテストを行なうシステムの構成図を次に示します。
スレーブ２システムの２台の端末は、着信端末と代理応答端末です。スレーブ３システムの１台の端末は代理応答端末です。スレーブ３システムに代理応答端末しか必要としない理由はこれから説明していきます。
このテストでは組み合わせテストのパラメータとして発信システム、着信システム、応答システムの３つを用います。これは発信端末、着信端末および代理応答端末がどのシステムに収容されている端末かを意味します。
パラメータとしての発信システムには値としてマスターとスレーブ１を定義します。スレーブ２とスレーブ３を定義しないのは、マスターシステムから見て発信端末がスレーブ１であってもスレーブ２であっても制御形態上の違いがないため、ここではスレーブ１から発信するとしているからです。
パラメータとしての着信システムには値としてマスター、スレーブ１およびスレーブ２を定義します。ここでスレーブ１とスレーブ２の２つのスレーブシステムが必要となるのは、発信システムがスレーブ１で着信システムもスレーブ１の場合と、発信システムがスレーブ１で着信システムがスレーブ２の場合があるからです。この２つの場合は、マスターシステムから見て制御形態が異なるためにどちらもテストする必要があります。
パラメータとしての応答システムには値としてマスター、スレーブ１、スレーブ２およびスレーブ３のすべてのシステムを定義します。応答システムにスレーブ３まで必要となるのは、発信システムがスレーブ１、着信システムがスレーブ２、応答システムがスレーブ３の場合をテストする必要があるからです。
この組み合わせテストのモデルを次に示します。
制約１
発信システムがマスターの場合、着信システムはマスターまたはスレーブ１だけでよいこと。応答システムにはスレーブ３は必要ないことを定義しています。発信システムがマスターであることは、着信システムがスレーブ１であれば応答システムとしてスレーブが必要となるのは着信システムと応答システムが同じであるスレーブ１が応答の場合と、着信システムと応答システムが異なるスレーブ２が応答の場合の２通りをテストすればよいことになります。
制約２
発信システムと着信システムがともにマスターである場合、応答システムとしてテストする必要がある組み合わせはマスターとスレーブ１の２通りだけであることを定義しています。
制約３
発信システムがスレーブ１で着信システムがマスターである場合、応答システムとしてテストする必要のある組み合わせはマスター、スレーブ１およびスレーブ２の３通りだけであることを定義しています。
制約４
発信システムと着信システムがともにスレーブ１である場合、応答システムとしてテストする必要がある組み合わせはマスター、スレーブ１およびスレーブ２の３通りだけであることを定義しています。
以上のモデルで生成したテストケースを次に示します。
今回の組み合わせテストでは、各パラメータの値の決め方が重要です。スレーブが発信システムとなる場合にはスレーブ１だけをテストすればよいということに気がつけば後の組み合わせは比較的簡単に決めることができます。
組み合わせテストでは時々今回のようにパズルを解くような問題に遭遇することがあります。