Q＆Aで読むソフトウエアテスト「オールペア法、直交表の基本」：現場で使うためのオールペア法、直交表の基本（5）（1/3 ページ）

今回は連載の総集編として、ここまでで解説してきたポイントをFAQ形式でまとめてみました。本稿を、ソフトウエアテストで「考え過ぎた」ときに、リファレンスとして使ってみてください。詳細を確認したい場合は連載各回の解説を確認してみましょう。

» 2015年06月11日 05時00分公開

[五味弘，OKI（沖電気工業）]

　本連載では、ソフトウエアの品質を担保するテスト手法として、組み合わせテストの網羅率を保証する「オールペア法」と「直交表」について見てきました。

　第一回では現状のソフトウエアテストが持つ課題を紹介、第二回で本連載のメインテーマである「オールペア法」と「直交表」の概念とツールの使い方を解説、第三回では、現場で使うためのコツを見てきました。この手法は、コツと見極めが必要なことに変わりはありませんが、原則としては素直に実施することがポイントになります。コツを使い過ぎなければ網羅基準に準じたテストケースを生成できることは、第四回の記事でお分かりいただけたと思います。これらの手法が持つ性質と原則、制約が分かれば使いこなしていくことも難しくなくなるはずです。

　今回は今までに紹介してきたことや、これまでの連載では紹介し切れなかったことを、FAQ形式にまとめてみました。これからソフトウエアテストを学んでいく方だけでなく、既に「ベテラン」の皆さんも、実務上の判断が難しくなってしまったときに読み返すと、本質を思い返すことができるでしょう。

「ソフトウエアテストの基本FAQ」目次

（1）ソフトウエアテスト全般

（1-1）ソフトウエアテストはそもそも何のためにするのですか？
（1-2）ソフトウエアテストをするときの一番大切な注意点は何ですか？
（1-3）ソフトウエアテストで要求される品質とテストに掛けるコストはどのように決めればいいのですか？
（1-4）テストはいつ終わらせればいいのですか？
（1-5）ホワイトボックステストとは何ですか？
（1-6）ブラックボックステストとは何ですか？
（1-7）制御パステストとは何ですか？
（1-8）デシジョンテーブルとは何ですか？

（2）組み合わせテスト

（3）オールペア法

（4）直交表

（5）ツールと職人

（1）ソフトウエアテスト全般

　連載第一回では、ソフトウエアテストの目的と主要な手法が抱える問題点を整理しました。また、本連載で紹介した「オールペア法・直交表」で重視すべき項目は、第三回で紹介しています。ここでは、それらの記事で示した、ソフトウエアテスト全般で重要なポイントを、あらためてまとめておきます。

（1-1）ソフトウエアテストはそもそも何のためにするのですか？

Ans.

　ソフトウエアテストは、対象ソフトウエアシステムの「動作の妥当性」を検証するために行います。

　ソフトウエアテストの究極の目的はシステムの品質を向上させ、保証することです。ソフトウエアテストでは必要十分な品質を得ると同時に、効率的にテストを実施することが求められます。

　連載第一回ではソフトウエアテストの全体像を示し、第四回では、実践の場でどのように考えるべきかを紹介しています。

目次へ

（1-2）ソフトウエアテストをするときに一番大切な注意点は何ですか？

Ans.

　テストはやみくもにするものではなく、「コスト」と「効果」を考慮して実施します。品質は、不足も過剰も好ましくありません。テストコストも、同様に少な過ぎても多過ぎてもだめです。テストで正当性が完全に検証できないときは、「合理性のある制限」を設けてテストをする必要があります。制限の付け方については、第三回、第四回をご覧ください。

目次へ

（1-3）ソフトウエアテストで要求される品質とテストに掛けるコストはどのように決めればいいのですか？

Ans.

　プロダクトの種別、業種、今までの稼働実績やこれからの運用など、多種多様な条件があるため、それぞれに求められる「品質」は異なります。このため、それぞれの「品質」を保証するテストに掛けるコストも違ってきます。判断は要件や案件ごとに、個別に検討せざるを得ません。組織全体でガイドラインを策定しつつ、運用を開発現場に弾力的に任せるなどの施策が有効です。

目次へ

（1-4）テストはいつ終わらせればいいのですか？

Ans.

　テストの完了基準は、

（a）規模当たりのテストケース数（テスト密度）
（b）信頼度成長曲線（バグ曲線）における規模当たりの残存バグ数（バグ率）
（c）何らかの計測可能な網羅基準
（d）費用

などを勘案して、決められます。

　本連載で紹介してきたように、筆者は（c）の「何らかの計測可能な網羅基準を設けて、それを満たしたときにテストを終了させる」という方法を推奨します。

目次へ

（1-5）ホワイトボックステストとは何ですか？

Ans.

　ソフトウエアシステムの実装を見て得られた情報を元にテストケースを作成する方法です。「制御パステスト」や「データフローパステスト」「状態遷移パステスト」「リソースパステスト」などがあります。

　ホワイトボックステストは機械化できるテストですが、もし手動で実施するときは「あまり細かく見過ぎない」ことも重要です。見過ぎてしまうとテストに掛かるコストが増大しますので、コストと効果のバランスを考える必要があります。ホワイトボックステストについては、第一回でも解説しています。

目次へ

（1-6）ブラックボックステストとは何ですか？

Ans.

　ソフトウエアシステムの実装を見ることなく実施するテストです。この場合、テストの「入力」はソースコードなどの実装ではなく、マニュアルや仕様書です。

　現場の原則として、ブラックボックステストだからといって、ソースコードを全く気にしなくていいということではありません。ソースコードが見えないからこそ、ソースコードを「想像」して、どんな実装かを予測し、テストをする必要があります。

　ブラックボックステストには、「同値分割」や「境界値分析」「デシジョンテーブル」「オールペア法」「直交表」「探索的テスト」などがあります。

　ブラックボックステストは発見的なテストであり、機械化しにくいテストです。このため、エンジニアの勘や経験が重要になってきます。ブラックボックステストについては、第一回、第三回でも解説しています。

目次へ

（1-7）「制御パステスト」とは何ですか？

Ans.

　ホワイトボックステストの一種で、プログラムの「処理経路」に注目して、それを網羅するテストです。網羅基準には「命令網羅」（C0、全てのコードがテストで通る）、「分岐網羅」（C1、分岐の全てのパスがテストで通る）などがあります。ツールによって機械的にテストケースが生成でき、また網羅率も計算できます。連載では、第一回で触れています。

目次へ