ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

JSTQB-TTAシラバスのお勉強 ─ 第2章「構造ベースドテスト」(1)

 TTAシラバスの第2章「構造ベースドテスト」は非常に謎めいた構成で、2.2から2.6までがコードカバレッジの話なのに、2.7が突然「APIテスト」なのです。なんだかとてもバランスが悪い印象なのですが、とにかく進むしかありません。
 あと「based」の訳が当初「ベース」と「ベースド」で不統一だったことから現在は「ベースド」に統一されていますが、さすがに「漢字熟語+ベースド」にはギャグ感があります・・・。

2 構造ベースドテスト

 構造ベースドテストは、シラバスに

テスト設計のベースとして、コード、データ、アーキテクチャ、およびシステムフローを使用する。

とあるように、プログラムの中身からテストを作っていく方法です。
 第2章で説明されるコードカバレッジについては、以前の記事で自分なりの整理をしました。詳しくはそちらを参照!ということで、個々で気になる点だけ補足していきたいと思います。

www.kzsuzuki.com

2.2 条件テスト

 対応するコードカバレッジは、条件網羅です。「判定」と「条件」がなんとなく似ているので混乱しがちなのですが、「条件」(condition)は不可分な命題です。∧や∨を含みません。「判定」(decision)は、条件やその組み合わせを評価した結果のブーリアンです。

 条件網羅はあまり実用的な意味のない概念だと思います。
 たとえば条件100個からなる、こんな判定を考えてみましょう。

(条件1 ∧ 条件2 ∧ ... ∧ 条件99) ∨ 条件100

 考えられる組み合わせは2100個ありますが、この場合に条件網羅を100%にするには、

条件1~99 = True、条件100 = False 条件1~99 = False、条件100 = Ture

の2つでOKです。一方、この2つのテストケースでは判定がともにFalseになるので、Trueの場合を実行できず、判定網羅は50%になってしまいます。

2.3 判定条件テスト

 対応するコードカバレッジは、判定網羅です。
 制限/注意事項としては「テストケースの増加」に言及していますが、条件網羅が保証されない点も重要でしょう。
 シラバスの表を少し書き換えて以下のようにしても判定網羅は満たされますが、条件網羅は満たされていない(条件AがFalseの場合がカバーされていない)ですね。

#ABA and B
1TrueTrueTrue
2TrueFalseFalse

2.4 改良条件判定カバレッジテスト

 対応するコードカバレッジは、改良条件判定カバレッジ(MC/DC)です。そのままですね。

定義が難解

 それにしても、シラバスの以下の文章は理解が難しいです。

N個の一意な不可分条件を想定した場合、MC/DCは通常、N+1個のテストケースで実現できる。MC/DCは判定条件カバレッジを達成するが、次の要件も満たす必要がある。
  1. 不可分条件Xが真になると判定結果が変わる1つ以上のテスト
  2. 不可分条件Xが偽になると判定結果が変わる1つ以上のテスト
  3. 各不可分条件に、上記の要件1と要件2を満たすテストが存在する。

 かみ砕いていうと、「その条件の真偽値が変わることで判定全体の真偽値が変わる」場合、そのテストケースはやっておけということ。裏を返すと、「その条件の真偽値が変わっても判定全体の真偽値が変わらない」のであれば、そのテストケースはやらなくていい(判定網羅を満たす範囲であれば)。

 TechMatrix社のページには以下のようにあります。こちらの1.は判定網羅、2.は条件網羅なので、シラバスの3つの項目が、3.の1文にまとめられていることになります。

DO-178Bに従うと、完全な(100%の)MC/DCカバレッジを得るには、次の3つの条件を満たす必要があります。
  1. 各「判断文」が、少なくとも1回すべての可能な結果を得ている。
  2. 1つの「判断文」中の各条件が、少なくとも1回すべての可能な結果を得ている。
  3. 1つの「判断文」中の個々の条件が、単独で全体の「判断文」の結果を左右する。

www.techmatrix.co.jp

具体例

 シラバスに示された、MC/DC=100%の例で確認してみましょう。

#ABC(A ∨ B) ∧ C
1TrueFalseTrueTrue
2FalseTrueTrueTrue
3FalseFalseTrueFalse
4TrueFalseFalseFalse
  • 条件A・B・Cが、TrueとFalseの両方の値をとるテストケースがある(条件網羅)
  • 判定結果 (A or B) and C が、TrueとFalseの両方の値をとるテストケースがある(判定網羅)
  • テスト1はAがTrueで判定がTrue。テスト3ではAだけをFalseに変えて、判定がFalseになっている。
  • テスト2はBがTrueで判定がTrue。テスト3ではBだけをFalseに変えて、判定がFalseになっている。
  • テスト1はCがTrueで判定がTrue。テスト4ではCだけをFalseに変えて、判定がFalseになっている。

 確かに、満たされているようです。

どうやって導出するのだ?

 さて、ではどのようにMC/DCを満たすテストケースを導出するのか。シラバスには書かれていません。「MC/DCは通常、N+1個のテストケースで実現できる」の根拠もわかりません。
 ネットを調べてみても(論文は調べていません!)、「これはMC/DC100%のテストケース群ですよ」といきなり「答え」が出ているものばかり。TechMatrix社のツールではMC/DCのカバレッジ分析ができるとのことなので、論理的に導出できるのではないかと思うのですが・・。。

 唯一希望を持てるのは、キャッツ株式会社のWebサイトで読める「ZIPC WATCHERS Vol.13」の記事「組込みソフトウェア開発課題への挑戦~網羅度~」(PDF)です。ここに以下の記述があります。

MC/DCテストケースを最小化する方法、MC/DCランダムテストに確率値誤差逆伝播法(バックプロパゲーション)を用いる方法については、別稿で述べる。→リンク先:松本

 でも「リンク先:松本」が見つからない・・・
 と言いますか、ん? バックプロパゲーション? ディープラーニングでちらっと勉強したあれ? 気になりすぎるのですが、とりあえず発見できませんでした。

導出方法を勝手に考えてみる

 ここからはあまり根拠のない話なので、冷やかし程度で読んでください。

 先の記述の、「ランダム」「最小化する」という言葉を見るに、MC/DCの場合は論理的に導ける唯一解があるわけではなく、何らかのランダム性を入れて、そこから最小な群を見つけていくアプローチなのでは、と想像しています。

 では自分なりにその方法を考えてみましょう。

 まずOR文。「または」なので、2つ以上の条件がTrueの場合、どれが独立にFalseに変わっても、OR文全体の結果は変わりません。
 次にAND文。「かつ」なので同様に、2つ以上の条件がFalseの場合、どれが独立にTrueに変わっても、AND文全体の結果は変わりません。
 よって、テストケース削減の方針として、以下2つを挙げることができるでしょう。

  • 方針1: OR内で複数条件がTrueになっているテストケースは省略する
  • 方針2: AND内で複数条件がFalseになっているテストケースは省略する

 では、シラバスの例である (A or B) and C について考えてみましょう。真理値表は以下の通りです。

#ABC(A ∨ B) (A ∨ B) ∧ C
1TrueTrueTrueTrueTrue
2TrueTrueFalseTrueFalse
3TrueFalseTrueTrueTrue
4TrueFalseFalseTrueFalse
5FalseTrueTrueTrueTrue
6FalseTrueFalseTrueFalse
7FalseFalseTrueFalseFalse
8FalseFalseFalseFalseFalse

 方針1から、AとBが両方Trueになっているテスト1と2を落とします。次に方針2から、(A ∨ B)とCが両方Falseになるテスト8を落とします。
 残るのはテスト3・4・5・6・7です。

 テスト3とテスト7は、条件Aを反転することで結果が反転しています。
 テスト4とテスト3は、条件Cを反転することで結果が反転しています。
 テスト5とテスト7は、条件Bを反転することで結果が反転しています。
 テスト5とテスト6は、条件Cを反転することで結果が反転しています。  

 条件Aの反転と条件Bの反転のために、テスト3・5・7は必須。あとは条件Cのために3・4を選ぶか、5・6を選ぶか。
 シラバスでは前者の3・4・5・7のパターンになっていますが、3・5・6・7でもMC/DCを満たしているといえるのではないでしょうか。なお、判定条件網羅はともに満たしています。

■シラバスの解

#ABC(A ∨ B) ∧ C
3TrueFalseTrueTrue
4TrueFalseFalseFalse
5FalseTrueTrueTrue
7FalseFalseTrueFalse

■別の解

#ABC(A ∨ B) ∧ C
3TrueFalseTrueTrue
5FalseTrueTrueTrue
6FalseTrueFalseFalse
7FalseFalseTrueFalse

 自力の導出方法として、この程度が限界でした。何かスマートなやり方あるんだろなあ。
 長くなってきたので、第2章の残りは別途。