ソフトウェアのテスト技法

半年くらい前ですが、職場にあったものを読みました。テスト技法の基本的な技法について、書いてあります。章ごとに概要とコメントを、書き連ねます。

防御的設計と契約設計

• こういう使い方をしたら駄目、というAssertが入っている関数に対して、Assertを踏むようなテストケースは不要。
• こういう使い方をしたら、こういうエラー処理がある関数に対しては、エラー処理を踏むようなテストケースが必要。
• ついAssertを踏むテストをやりたくなりますが、この節を読んで、不要な意味が理解出来ました。そもそもこうあって欲しい、という期待値が存在しませんし。

同値分割

• 境界値分析は、同値分割した各クラスの境界値を踏むようにしたもの。境界値分析は同値文化うの上に成り立つ。
• 最も基本的なテスト技法かと思います。大概のテストで使うでしょう。

決定表

• 出力に影響しない入力をDontCareにすることで、テストケースを削減できる。
• 活用しています。上手く使わないと表のサイズが爆発するので注意が必要です。ただし、変に間引くと、漏れを検出する効果が低下するので、これまた注意が必要です。

ペア構成テスト

• 直交表やオールペア法などがある。2つの因子間の組み合わせを網羅する。
• 3つ以上の特定の組み合わせに着目する必要がある場合は、明示的にテストケースの追加が必要となる。
• テストケースの削減効果は絶大です。ただし、あくまで2因子間網羅なので、使いどころには気をつける必要があります。

状態遷移テスト

• 遷移の組合せがテストになる。
• あまり馴染みがないですね。

ドメイン分析

• ドメインとは条件式。テストケースは複数のドメインの組になる。
• 各ドメインのon/off/inに着目し、あるケースでon/offが出たら、他のケースはinで良い。
• あるドメインでon/offが出たら、同じケースのドメインはinで良い。
• ドメイン分析はいつ見てもぱっと頭に入ってこないです。実際に使ったことがないですし。

ユースケーステスト

• あまり入力パターンはカバーされない。
• これも使ったことはありません。運用テストやシステムテストなどの上流テストでは使うのでしょうか。

ホワイトボックステスト

• ブランチカバレッジやサイクロマチック数などを指標とする。
• カバレッジは職場でもテストの網羅度を見る際に活用してますが、サイクロマチック数は活用してないですね。

データフローテスト

• d/u/k…これも馴染みないですね。いまいちピンと来ません。

テストの枠組み

• スクリプトテスト。計画、設計、成績と順を追ってテストを実施する。
• 探索的テスト。振る舞いに対する仮説を立てて、それの証明や反証を繰り返していく。こう動くはずだ、とテスト担当者がテスト仕様を作成してテストを実行し、その結果をもとに次のテストを作成する。
• 今の職場はスクリプトテストですね。ただテスト対象の仕様が大いに揺らいでいる現状もあり、探索的テストも取り入れるテスト計画が有用だったのでは、と今にして思います。

テストケースの分類

• 結局主観が入る。分類についてはいろいろな分類方法があり、考えの整理をする上で役立つ。
• 正常系/異常系や、機能による分類を、良く使います。

テストの終了判定

• 明確な線は引けない。カバレッジの網羅度や欠陥検出数などを判断材料とする。
• テスト担当としては、テスト終了時点のテスト状況を伝えることが任務である。テスト終了の判断は、違う立場の人が行なう。
• どこまでやれば安心できるのか難しいです。結局どこまでやっても完璧はありえなく、工数との折り合いになります。