MCDCカバレッジを​満たすテストケースが​、テストとして不十分​な場合があるように思​える

現在matlab simulinkにて、単体テストを行っております。

テストにおいて、網羅率を調査するためにMC/DCカバレッジを満たしているかをチェックしているのですが、MC/DCチェック方法を行うだけでは取りこぼしてしまうポイントがあるように思えてなりません。

具体的には、〇〇&&✕✕という条件において、MC/DC解析では、TT, Fx, TFの3パターンを行えば問題ないとなっておりますが、個人的にはTT, FT, TFの3パターンが必要であるように感じております。

例えば、以下のようなモデルを作成してみました。

入力値が、１から２に立ち上がった時に、A1ステートに移動するというモデルとなります。

また、Signal Builderは以下のようになっております。

この時、最初は入力が0であるので、in_unit_delay == 1が成り立たず、[(in_unit_delay == 1) && (in == 2)] がFxとなります。

次に、入力が１となってからしばらくの間、in_unit_delay == 1は成り立ちますがin == 2は成り立たないので、[(in_unit_delay == 1) && (in == 2)] はTFとなります。

最後に、１から２へと立ち上がる時、(in_unit_delay == 1), (in == 2)のどちらも成り立つので、[(in_unit_delay == 1) && (in == 2)]はTTとなります。

結果、この条件式は、AステートにいるときにTT, Fx, TFすべてのパターンの入力がなされるので、MC/DCカバレッジは満たされていると判断されます。

一方で、以下のようなモデルを考えます。

これは、先ほどのモデルの条件式の順番を入れ替えただけのモデルとなります。

このモデルで先ほどと同じテストを行った場合、入力が０（もしくは１）の場合、in == 2が成り立たないので、[(in == 2) && (in_unit_delay == 1)]はFxとなります。

また、１から２へと立ち上がる時、(in == 2), (in_unit_delay == 1)のどちらも成り立つので、[(in == 2) && (in_unit_delay == 1)]はTTとなります。

しかし、[(in == 2) && (in_unit_delay == 1)]がTFとなる場面は、A1ステートに移った後にしかないので、条件TFは満たされていないものと判断されてしまいます。

このような場合を回避するため、私はテストはTT, Fx, TFではなくTT, FT, TFのパターンを行うべきだと考えているのですが、なぜMC/DCカバレッジでは前者のパターンで問題ないとされているのでしょうか？

Answer 1

[Atsushi Ueno]

こういう事ですよね

• 3条件のANDなら (TTT, FTT, TFT, TTF)、4条件のANDなら (TTTT, FTTT, TFTT, TTFT, TTTF)、5条件...
• 3条件のANDなら (TTT, Fxx, TFx, TTF)、4条件のANDなら (TTTT, Fxxx, TFxx, TTFx, TTTF)、5条件...

>なぜMC/DCカバレッジでは前者のパターン (TT, Fx, TF) で問題ないとされているのでしょうか？

• C言語では「短絡評価」(&&の条件は左から順に評価される) が規定されているからです
• MC/DCカバレッジは「複数の入力条件がそれぞれ独立して出力に影響を与えるか」が判れば良いのです

>〇〇&&✕✕という条件において、MC/DC解析では、TT, Fx, TFの3パターンを行えば問題ないとなっておりますが、個人的にはTT, FT, TFの3パターンが必要であるように感じております。

• 下記の意味では同意です
• 全条件を揃えてから1条件ずつ順に (TT⇒FT⇒TT⇒TF) とするのが分かり易く間違い難いから
• 「短絡評価」が規定されていない環境なのに、同じ方法 (TT, Fx, TF) でテストして失敗する可能性があるから
• (※信頼性のあるツールで自動化されたテストなら絶対に間違えないのでこれらの点は心配無用です)

>[(in == 2) && (in_unit_delay == 1)]がTFとなる場面は、A1ステートに移った後にしかない

そんな事はありません。Signal Builderの信号の動きを0⇒2⇒1等とすれば、Aステートのまま [(in == 2) && (in_unit_delay == 1)] を TF とする事が出来ます。実際には in の値域が 0 ~ 2 で、1 ずつインクリメントする動きしか起こり得ないのかも知れませんが、単体テストにおいて信号の値域や動きを制約する必要は無く、当該ロジックはどちらの順序でAND条件判断してもMC/DCカバレッジを満たします。

あと、なにも状態遷移ロジックを一度に一筆書きでテストする必要はありません。質問のモデルにおける状態遷移はAステート⇒A1ステートの一方通行なので尚更です。テストを複数回に分け、各テストケースが通った道を合わせた結果がカバレッジを満たせばOKです。

[佳樹]

ご回答、誠にありがとうございます。

短絡評価というものがあるのですね、非常に勉強になりました。

お手数をおかけしてしまいますが、こういった単体テストの基礎を学べる資料やネットの記事等はございますでしょうか？

また、現在開発工程においてテストケースを手動で作成しており、その後テストのMC/DCカバレッジを見て評価を行っているのですが、テストケースの作成を自動で生成するような、テストにおいて便利なツール等はございますでしょうか？

勝手を申し上げてしまい恐縮ですが、ご教示いただけますと幸いです。

[Atsushi Ueno]

>単体テストの基礎を学べる資料やネットの記事等はございますでしょうか？

• 単体テスト - Wikipedia
• 「単体テスト」「ソフトウェアテスト」等のキーワードで検索すると沢山出てきます

>テストケースの作成を自動で生成するような、テストにおいて便利なツール等はございますでしょうか？

⇒Simulink Design Verifier が該当します。(タグに design verifier があるので既に使用中なのでは?)

「Monte-Carlo法に基づいたテスト自動生成ツール」論文の中で、Simulink Design Verifier が主に形式手法に基づいた解析によりテストケース生成を試みる事、一方でモンテカルロ法によるテストケース生成を行うツールがある事、それらの比較結果などが論じられています。

[佳樹]

何度も質問にご回答いただき、誠にありがとうございます。

Simulink Design Verifierは、少しだけ使用してみたのですが、作成されたテストケースは簡単なモデルのものであってもMC/DCカバレッジを全く満たしていないものばかりで、使用に耐えられるものではないと感じたため、今回質問させていただきました。

しかしながら、ただ単に私がこのアプリを使いこなせていない可能性もあるので、後日Mathworksのエンジニアの方に質問させていただこうと考えております。

また、「Monte-Carlo法に基づいたテスト自動生成ツール」の情報につきまして、ありがとうございます。

一つ質問なのですが、このモンテカルロ法によるテストケースの作成ツールというのは、すでに世に出ているものなのでしょうか？

少しネットで検索してみたのですが、該当するツールが見当たりませんでした、、、

また、この方法でははじめはランダムでテストケースを作成するようですが、以下のような条件式の場合はカバレッジを満たすテストケースの作成が少し困難ではと感じました。

1ステップ前のＡの値 == 1 || 2

&&

現在のＡの値 == 3 || 4

上記のような条件式では、現在の値と1ステップ前の値の両方を指定しているため、ランダムでテストケースを作成する場合は難しいのではないか？と感じました。

また、A < Bのような比較を行う条件式の場合においても、境界値分析を行いたいので、Bの周辺の値を3つほど参照するテストケースを作成したいと考えております。

以上のことから、結局のところテストケースの作成を自動生成ツールに丸投げするようなことはできないのか？というように考えたのですが、Atsushi Uenoさんはどのようにお考えでしょうか？

よろしければご意見をお聞かせください。

[Atsushi Ueno]

>しかしながら、ただ単に私がこのアプリを使いこなせていない可能性もあるので

⇒巷の形式手法ツールより使い易いのですが私も使いこなせません。形式手法は敷居が高いです。使いこなせば完璧で最強の方法です。（参考：「モデル検査」「形式手法はなぜ流行っていないのか - Qiita」）

>モンテカルロ法によるテストケースの作成ツールというのは、すでに世に出ているものなのでしょうか？

⇒はい。取り挙げた論文「Monte-Carlo法に基づいたテスト自動生成ツール」でも「7.関連ツール」において比較対象として T-VEC Tester for Simulink と Reactis を取り挙げています。

>上記のような条件式では、現在の値と1ステップ前の値の両方を指定しているため、ランダムでテストケースを作成する場合は難しいのではないか？と感じました。

⇒工夫次第です。今回値と前回値の入力を別々にランダム生成する考え方は良いのですが、なかなか当たりが引けず効率が悪いです。この場合は前回値生成ロジックもテスト対象に含めてしまうのが良いです。

より広義には下記の方法が考えられます。

• テスト対象を細分化する(場合によっては一体化する)
• 重み付けしたランダム生成で狙いを定める
• ランダム信号を後加工して狙いを定める
• 動かしてみてレアなパスを補うテストケースを追加する ← 結局手作業が必要に...

＞A < Bのような比較を行う条件式の場合においても、境界値分析を行いたいので、Bの周辺の値を3つほど参照するテストケースを作成したい

⇒カバレッジ計測に必要な境界値は(整数なら) A=B-1 と A=B 、真/偽の 2 つだけです。代表値でテストして見つかるのは演算結果と期待値の不一致で、カバレッジ計測に代表値は不要です。各種ツールに代表値を設定する機能はあると思います。代表値を設定出来ないツールがあったとしても、境界の定義を増やせば代表値の代わりとなる境界値を増やせます。

>結局のところテストケースの作成を自動生成ツールに丸投げするようなことはできないのか？

⇒YES/NOです。モンテカルロ法によるテストケースの自動生成ツールに丸投げ出来るのはカバレッジ計測(の為のテストケース生成)です。これまでに挙げた様な問題を解消する必要がありますが、ビルド時にカバレッジ計測を自動化する事は可能です。一方、モンテカルロ法では演算結果の期待値を自動生成する事は出来ません。

[佳樹]

返信が遅くなってしまい、申し訳ございません。

>巷の形式手法ツールより使い易いのですが私も使いこなせません。形式手法は敷居が高いです。使いこなせば完璧で最強の方法です。

「形式手法」という方法があるのですね、初めて拝見いたしました。

リンクを添付していただいた資料を拝見しましたが、内容が難しく、少なくともすぐには理解が出来なさそうな内容でした。

仮に私が理解できたとしても、この手法を大規模開発の現場において浸透させるのは、なかなか難しいように感じました。

>はい。取り挙げた論文「Monte-Carlo法に基づいたテスト自動生成ツール」でも「7.関連ツール」において比較対象として T-VEC Tester for Simulink と Reactis を取り挙げています。

ReactisとT-VEC Tester for Simulinkがそれにあたるものだったのですね、資料の読み込み不足でした。

私の開発現場において、Reactisが使用可能でしたので試してみたのですが、謎のエラーによって使用することができませんでした、、、

Reactisのバージョンが2018のものと古いものだったということもあるかもしれませんが、Reactisについての資料がほとんどない、Reactisの発行元となるReactive Systems社が日本にない等、使用していくうえで不便であるように感じ、このツールを今後使用するのはなかなか難しいように感じました。

また、T-VEC Tester for Simulinkに関しては、現在使用することができない環境にあるため試せておりませんが、こちらのソフトウェアに関しても資料に乏しく、Reactisと同様使用するのが難しいような気がしました。

>YES/NOです。モンテカルロ法によるテストケースの自動生成ツールに丸投げ出来るのはカバレッジ計測(の為のテストケース生成)です。これまでに挙げた様な問題を解消する必要がありますが、ビルド時にカバレッジ計測を自動化する事は可能です。一方、モンテカルロ法では演算結果の期待値を自動生成する事は出来ません。

承知いたしました。

テストにおいては、MC/DCカバレッジを見るテストと、境界値分析を行うテストは分けた方がよさそうですね、参考になりました。