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

19 次查看（过去 30 天）
佳樹
佳樹 2023-2-16
评论： 佳樹 2023-2-24
現在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カバレッジでは前者のパターンで問題ないとされているのでしょうか？

请先登录，再回答此问题。

采纳的回答

Atsushi Ueno
Atsushi Ueno 2023-2-16
こういう事ですよね
  • 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です。
  5 个评论
显示 3更早的评论
Atsushi Ueno
Atsushi Ueno 2023-2-20
>しかしながら、ただ単に私がこのアプリを使いこなせていない可能性もあるので
⇒巷の形式手法ツールより使い易いのですが私も使いこなせません。形式手法は敷居が高いです。使いこなせば完璧で最強の方法です。（参考：「モデル検査」「形式手法はなぜ流行っていないのか - Qiita」）
>モンテカルロ法によるテストケースの作成ツールというのは、すでに世に出ているものなのでしょうか？
⇒はい。取り挙げた論文「Monte-Carlo法に基づいたテスト自動生成ツール」でも「7.関連ツール」において比較対象として T-VEC Tester for Simulink と Reactis を取り挙げています。
>上記のような条件式では、現在の値と1ステップ前の値の両方を指定しているため、ランダムでテストケースを作成する場合は難しいのではないか？と感じました。
⇒工夫次第です。今回値と前回値の入力を別々にランダム生成する考え方は良いのですが、なかなか当たりが引けず効率が悪いです。この場合は前回値生成ロジックもテスト対象に含めてしまうのが良いです。
より広義には下記の方法が考えられます。
  • テスト対象を細分化する(場合によっては一体化する)
  • 重み付けしたランダム生成で狙いを定める
  • ランダム信号を後加工して狙いを定める
  • 動かしてみてレアなパスを補うテストケースを追加する ← 結局手作業が必要に...
＞A < Bのような比較を行う条件式の場合においても、境界値分析を行いたいので、Bの周辺の値を3つほど参照するテストケースを作成したい
⇒カバレッジ計測に必要な境界値は(整数なら) A=B-1 と A=B 、真/偽の 2 つだけです。代表値でテストして見つかるのは演算結果と期待値の不一致で、カバレッジ計測に代表値は不要です。各種ツールに代表値を設定する機能はあると思います。代表値を設定出来ないツールがあったとしても、境界の定義を増やせば代表値の代わりとなる境界値を増やせます。
>結局のところテストケースの作成を自動生成ツールに丸投げするようなことはできないのか？
⇒YES/NOです。モンテカルロ法によるテストケースの自動生成ツールに丸投げ出来るのはカバレッジ計測(の為のテストケース生成)です。これまでに挙げた様な問題を解消する必要がありますが、ビルド時にカバレッジ計測を自動化する事は可能です。一方、モンテカルロ法では演算結果の期待値を自動生成する事は出来ません。
佳樹
佳樹 2023-2-24
返信が遅くなってしまい、申し訳ございません。
>巷の形式手法ツールより使い易いのですが私も使いこなせません。形式手法は敷居が高いです。使いこなせば完璧で最強の方法です。
「形式手法」という方法があるのですね、初めて拝見いたしました。
リンクを添付していただいた資料を拝見しましたが、内容が難しく、少なくともすぐには理解が出来なさそうな内容でした。
仮に私が理解できたとしても、この手法を大規模開発の現場において浸透させるのは、なかなか難しいように感じました。
>はい。取り挙げた論文「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カバレッジを見るテストと、境界値分析を行うテストは分けた方がよさそうですね、参考になりました。

请先登录，再进行评论。

更多回答（0 个）

类别

在 Help Center 和 File Exchange 中查找有关 テスト ケースの生成 的更多信息

标签

产品


版本

R2020b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!