これはなに？

カバレッジについて自分の知っている知識をさらけ出す記事です！
タイトルは天元突破グレンラガンのニアちゃんの声で脳内再生ください（歳がばれる）。

私はじつは今の会社に入る前、パワエレ回路設計および制御設計のエンジニアでしたが、
今は大規模モデル・ソフトウェアの検証に関するサポート業務も担当しています！

全然違う分野に飛び込んだので、業界ではチョー当たり前で今更書くか？ということでも
ぜんぜんわかんないことがありました。その一つがカバレッジという言葉です。

この怪文書ではカバレッジとは何か？という記述と
Simulinkモデルでカバレッジを計測した結果をご紹介したいと思います。
お仕事を通じていろいろ勉強中なので間違ってたらすみません！

前座の怪文書

いやでもその前にきいてくださいよ。
カバレッジの前に、ほかにもいろんなよくわからなかった言葉があるんですよ。
例えばですね・・・

怪文章を読んでもいいという人は展開

ハーネス

ソフトウェア検証での領域でハーネスというとテストハーネスのことを指します。
これはあるソフトウェアの動作が正しかを検証するためのテストプログラムや実行環境のことです。

ACDC電源の回路評価をするときの入力電圧を作る可変AC電源や、電子負荷、オシロスコープなんかがテストハーネスに相当するのかなと勝手に思ってます。試験環境といえばいいのかな。
ていうかパワエレエンジニアがハーネスって言われたらだいたいワイヤーハーネスを思い浮かべますよね。

テストベクタ

これはソフトウェアではテストを実行するための入力信号です。
必ずしも製品で実際に入力される信号と一致する必要はないのですが、目的としては検査対象となるソフトウェアユニット・モデルがただしく実装するかを確認するために用意した入力信号だと理解してます。

これは試験要件に相当する言葉だとおもっています。
電源回路でもいろんな条件でテストをします。たとえば世界で使われるあらゆるAC仕様のいずれでも動作することを仕様としたい場合、実際にその要件でテストをしないといけません。このAC仕様のバリエーションがテストベクタに相当するかなと思います。

期待値

これはテスト対象となるソフトウェアユニット・モデルの要求から落とし込まれたもので、検査対象がテストベクタ入力に対して期待される出力値となります。これは基本的にソフトを作る前に決定されます。もちろん後から追加や修正は入ることはあると思いますが。

電源でも最初からDC何ボルト出すのか、どの範囲の誤差を許容するかを決めずに回路作っているのでは設計とはいえませんからね。それがないで作り始めて出力が既定の電圧だったとしてもそれはたまたまその電圧になっただけで、狙った設計ではないということになり、製品の信頼性を示すには非常に危険な状態になると思います。

テストケース

テストベクタと期待値をまとめたものをテストケースと呼ぶことがあります。
またテストを実施するための手順や、期待値に対してテスト対象の出力結果がどうなっていれば合格とみなすかという合格基準もこの言葉に含まれることがあると思います。

例えば期待値一つでも、完全一致をOKとするか、期待値から±何パーセントを誤差範囲として許容するかなどの合格基準を設けると結果が変わってきたりしますよね。
そこらへんの観点がテストケースという言葉に含まれると私は理解してます。
結構揺らぎがある言葉なので一概には言えなさそうですけどね。

これらの言葉をハードウェア評価観点でイメージ化

ハードウェアエンジニアとしてこれらの言葉をハード観点でイメージ化したのはこちら。
往々にして間違いは含まれると思うので色々気が付いたこと指摘してくださると嬉しいです。勉強になりますので！

カバレッジとは？

初めてこの言葉聞いた私は「わかんないからGoogle先生にきこう」ってこととで検索しました。
Wikipediaのコード網羅率が引っかかりました。

コード網羅率（コードもうらりつ、英: Code coverage、コードカバレッジ）は、ソフトウェアテストで用いられる尺度の1つである。プログラムのソースコードがテストされた割合を意味する。この場合のテストはコードを見ながら行うもので、ホワイトボックステストに分類される。

コード網羅率は体系的なソフトウェアテストのための技法として最初に生み出されたものの1つである。1963年の Communications of the ACM にある Miller と Maloney の論文に言及されているのが最初である。

へーそうなんだ。へー・・・

で、それが何の役に立つの？

これが一番わかんなかったです。そんなもん調べてどうなんの？というのが率直な感想でした。
しかしこれは大規模モデル・ソフトウェアを構築する上でコードの品質を担保するために重要な指標の一つだと気が付くのにちょっと時間がかかりました。

世の中で動いているプログラム、主に私が取り扱うのは組み込みプログラムですが、
どちらにせよその規模は増大しており何万行、はたまた一つのシステムに億を超える行数のプログラムが記載されています。
そしてその行のたびに ifだのswitch caseだので変数に応じて分岐が施され、実行される振る舞いが分岐されていくのです。

このすべての分岐に対してソフトウェアが正しく動作するのを確認するとき、
じゃあどこまでできたらOKなの？という基準を設定するのが大変です。なにせ量が多いですから。

ソフトウェアの動作検証のための基準は主に

テストが網羅的に実施されたか？
それらテストが何をもって合格と判定されたか？（要求からみて合格基準は妥当か？）

この両方が具体化され、それをもって評価されていることが非常に大事になってくると認識してます。
この前者について具体的な指標を提供するのがカバレッジ、コード網羅率です。

ちなみによくカバレッジ100%だったら万事OK　というわけではない。それを目的化させちゃだめ。という議論を目にしますが、
これは「網羅的にテストしたといっても、そのテスト判定結果がめちゃくちゃだったら意味ないよ。カバレッジだけがテスト指標のすべてではないよ」というのがその主張を支える根拠の一つなのかなとおもっています。

どのカバレッジ基準でどの程度のカバレッジ網羅率であればよしとするかは、そのソフトウェアを構築する組織が判断することなのかなと個人的には思ってます。

ハードでいうと・・・

これはハードだって同じことでよく設計で議論になるポイントだと思います。
例えば製品の仕様で”AC入力電圧ワールドワイド対応”をうたうとします。そうすると世界中で使用されているあらゆるAC条件（電圧・周波数）に対応する必要があります。
また、ここでもいわゆるTypical値だけに合わせるだけでは”ACワールドワイド対応”というわけにもいきません。

たまにですが頻繁に電圧が変動したり、需要と供給の変化が激しいとある時に瞬時的に系統電圧が跳ねるといったことがあります。そうなるとAC位相のいずれの位置で電圧急変が起こっても大丈夫であるかを、各電圧条件、周波数条件で調べないといけないかも・・・
実際にはもっといろんな項目がありそうですね。でもそれを全部しらみつぶしにやってるとキリがないですよね？

こういう基準を何処に持つか？どこまでやるのか？
つまり、製品の品質を何をもって担保するかというのは、その製品の開発責任を持つメーカが判断することかなと個人的には思います。（個人的にはですよ？メーカー勤務時代はそう教えられましたので。）

この判断の違いで同じ”ACワールドワイド対応”という謳い文句でも実際に動く製品と動かない製品が出てくるのだとおもいます。

カバレッジ基準

カバレッジの基準は実はいくつかあって、
業界で共通して使える一般的なカバレッジ基準と、同じ名前でも業界によって揺らぎのあるカバレッジ基準があるのでコミュニケーションをとる際には注意が必要です。

ここではMATLAB/Simulink AdcなのでSimulinkで解析できるカバレッジ基準を見てみましょう！
https://jp.mathworks.com/help/slcoverage/ug/types-of-model-coverage.html

多すぎ・・・
じゃあ、すげー簡単な超基本な基準２個についてみてみましょう。
ヘルプドキュメントによると・・・

実行カバレッジ (EC)

実行カバレッジは最も基本的な形式のカバレッジです。各項目について、実行カバレッジはその項目がシミュレーション時に実行されたかどうかを判定します。

条件カバレッジ (CC)

条件カバレッジでは、入力の論理組み合わせを出力するブロック (Logical Operator ブロックなど) と Stateflow 遷移を解析します。テストケースでフルカバレッジが得られるのは、モデル内で論理ブロックの各インスタンスへの入力と遷移での各条件が、シミュレーション中に少なくとも 1 回 true になり、かつシミュレーション中に少なくとも 1 回 false になる場合です。条件カバレッジ解析では、モデル内のブロックごとに、テストケースが当該のブロックを完全に網羅しているかどうかがレポートされます。

・・・フーン　これが一番簡単なやつなんだ。へー

・・・僕頭悪いんで実際に使ってみないとわかんないや。

Simulinkモデルで複数カバレッジ基準で解析しよう

この上ないほどシンプルなモデルを作りました。

最近お仕事で使っていて私のお気に入りになっているSimulinkTestのテストハーネスという機能でテストの環境を作ります。
これはモデルの一部を切り出して、その一部機能の単体動作を検証するのに役立ちます。
ハーネスでの編集結果が元のモデルにも同期されるので便利だなぁと思っております。

ここでは
入力信号1．常に0
入力信号2．－1から5秒地点で１に切り替わる
の二種類のテストベクタ（ベクタと呼べるのか？）を用意してそれぞれカバレッジを
SimulinkCoverageという製品で計測してみます。

私の理解では、

入力信号１だと
- 実行カバレッジ100%、条件カバレッジ50%になる
- 実行バリエーションは一つしかないので問答無用で実行カバレッジは100%
- Relational Operatorの分岐条件を片方しか満たしてないから条件カバレッジは100%にならない。
入力信号２だと
- 実行カバレッジ、条件カバレッジともに100%になる
- Rerational Operatorの分岐条件を両方満たすから

ということかなと思います。