質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.92%

カバレッジ100%について

解決済

回答 7

投稿

  • 評価
  • クリップ 6
  • VIEW 12K+

7tsuno

score 310

アーキテクトとしてアプリの方針などを考える仕事をしています。

単体試験の工程にて、jUnitをやることになると必ず問題になるのがカバレッジ計測率のお話。

多くの本やサイトではカバレッジ100%までやる必要がないと記載がありますし、個人的にもやりたくないのですが、提案の段階でカバレッジを100%を目指さない論理を持っていません。
100%までやらないと全てのパターンを網羅してると言えないのでテストとして不十分だ。と言われてしまうと反論ができません。

以下をご教示いただきたいです。

  • カバレッジを100%にしなくてもいい理由
  • お客さんを納得させるための論理・根拠
  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 7

+17

多くの本やサイトに載ってると思いますが

データパターンや条件網羅を考えると
カバレッジを100%やっても全然十分ではない。
むしろ無駄が多い。

すべてを100%にするには比例的に工数が増えることを説明し、
お客さんと共に妥協できる着地点を探す。

例えば

  • マネーパスや業務上クリティカルな処理などが絡む処理は100%を目指す。
  • 利用係数の高い機能は重点的に複数のデータパターンで100%を目指す。
  • 利用係数の低い機能は正常系といくつかの異常系のみ80%以上を目指す。

目指すって書いておけば、98%だったときに

残りの2%は工数見合いで、他の機能を優先させました。
クリティカルパスのhogehogeに限っては100%です。

みたいな感じでしょうか。

人と金と納期の引き合いに出すと分かってくれる人もいる。
が、100%にこだわる人もいる。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/26 11:12

    > データパターンや条件網羅を考えると
    カバレッジを100%やっても全然十分ではない。
    むしろ無駄が多い。

    ここが本質ですね。100%という数字の魔力なんでしょう。
    論理の一つとして使わせていただきます。

    キャンセル

  • 2017/05/26 12:02


    逆の発想なんですが、
    立場的に100%というモノが必要なケースを考えてみました。

    こちら側の人間はシステムリリースが終わりの人が多いですが、
    お客さんはシステムリリースは通過点か始まりの場合が多いですよね。

    システムリリースから始まった場合、
    改修・機能追加というモノは必然的なものになります。
    (小規模なものやパッケージ製品は対象にならないかもしれません)

    その時にカバレッジが98%だったら、
    残りの2%を毎回確認することになります。
    確認が自動化されていればいいですが、
    手動で毎回確認するのは非常に面倒です。

    仮に当時の担当者・開発者がいなくなる場合、引継ぎの対象にもなります。
    カバレッジ2%のことなんて詳しく引継ぎしないかもしれません。

    そういった後々のことを考えると、100%というモノが意味を持ってきます。
    こちら側の人間も、カバレッジ98%のシステムを途中から運用・機能追加したいとは思わないかと。
    どちらにも100%という安心感はあるかと思います。

    まぁそこまでシステムを理解してるお客さんなら、ある程度の話は分かってくれそうですけどね。
    リリース後(納期外)に順次100%にする、とか、
    カバレッジ100%用要員(工数)を追加する、とかで。
    結局100%の必要があるって着地点なんすが、反論のケースは多いほうがいいと思いまして。

    キャンセル

  • 2017/05/29 13:22

    最終的にはやはり100%必要な感じですね。
    100%という安心感っていうのもよく考えると怪しい気がしますが、やっぱり数字の安心感って納得しやすい話なんでしょうね

    キャンセル

+3

最低でもC0は単体試験で100%にするでしょう。って思っているんですが、
そんなに甘くはないんですか?
書いたコードを通さないとかありえるんですか?
どんなにイレギュラーなケースでも、何とか擬似的に再現させてでも通しますよね。

C1は業務処理であれば、業務パターンそのものとも言えるので網羅すべきですが、
フレームワーク部分がしんどいかもしれませんね。。。

問題はC2ですね。
データパターンのマトリクスに◯✕付けまくって、
ありえないケースや無意味なケースはグレーアウトして、
残ったものを片っ端からやっていこうというあれですね。
あれに関しても、本来は必要だと僕は思っていますが、
でかいシステムになるとケース数が、「これほんとにやるの?」っていう数になることも
しばしばあるので、そこは頭使って取捨選択していくのが現実的でしょうね。
つまり、ここの100%は現実的でない時もあります。

そして一番つらいのは、全てをJUnitで再現させるってことじゃないでしょうか。
しかし何かしかの計測ツールを使わないと、パーセンテージに説得力がないし
っていうところですよね。。。

お客さんへの説明は費用対効果しかないんじゃないですかね。
98%から100%にするだけで、さらにこんだけ工数かかりますよ。
かと言って残り2%をやる価値としては、こんなもんですよ。
それでもやりますか?

金払うからやれと言われればやるしかないんでしょうね。。。
ただ、金もらっても間に合うかどうかは別問題なので、スケジュールの調整は必要ですね。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/26 11:15

    自分も同じ考えだったのですが、多くの本やサイトで80~90を目指すほうがいいという記述が多かったので質問させていただきました。
    例えば以下のサイトなどです。
    http://bliki-ja.github.io/TestCoverage/

    キャンセル

  • 2017/05/26 11:57

    興味深く読ませてもらいました。ありがとうございます。
    ただ、C0が100%でないというのは、僕の中ではあり得ないという思いは変わりません。

    100%に固執すると、品質評価が目的ではなく、100%にすることが目的になりがち
    ってのは本当にその通りだと思いますね。。。

    >カバレッジの数字ばっかり気にして、自分が何をやっているかわかっていない人間のいる臭いがする。
    マジでこれです。こればっかりです。マネージャークラスでもこれです。

    まぁ、作るアプリケーションがどんなものかってのが、テストへの過敏度は変わりますよね。
    このサイトの内容は同意できることも多いですが、アプリケーションの性質によって
    この辺りの感覚は、柔軟に変えていくべきなんではと思います。
    例えば金融系や、原発の制御などは、テストしすぎなぐらいした方がいいかもしれませんから。

    いついかなる時も、「100%が正義!」と固執するのは合理性が全くありませんね。。。

    キャンセル

  • 2017/05/26 16:37

    C0は基本的に必要性から生まれた分岐点ですから100%になると思います。

    しかし、自然に100%にならないケースもあります。要件に「未定義」とか「この引数は必ず1」とかいう仕様がある場合、僕は何か処理は入れますがすぐにはテストを作りません。ですから、C0が100%より減ることがあります。

    「想定外の値が来た時は止めてくれ、進めてくれ」って話を相手が決めてくれたらテストを作ります。
    取り決めがない間はとりあえず100%より低くていいと考えています。
    相手が面倒臭がって98%になれば、それはそういう仕事です。

    キャンセル

+3

こんにちは。

まず、C0/C1カバレッジ100%にしても十分なテストではありません。
本当にやりたいことは全ての条件分岐の全ての組合せについてテストすることです。C2カバレッジ100%ですね。しかし、これは組合せ爆発が発生するため事実上不可能です。

if文1つならパスは2通りです。if文が2つならパスは4通り、if文が8つならバスは256通り、...、if文が32個でパスは‭4,294,967,295‬通りです。
実際には合流するのでここまで極端には増えないですが、増え方のオーダーは大差ありません。
if文が32個しかないプログラムってかなり小規模ですね。通常のプログラムはif文は数百~数万と存在するでしょう。
その全てをテストしようとすると組合せ爆発が起きます。
組合せ爆発は↓が感動的です。
『フカシギの数え方』 おねえさんといっしょ! みんなで数えてみよう!

そこで、せめて全てのコードを最低一通り通してテストしましょうと言う考え方がC0カバレッジです。せめて条件分岐については全てtrueとfalseの両方を通しましょうというのがC1カバレッジです。
C1でさえ条件分岐の組合せを考慮しないため全く不十分です。(*1)
しかし、目安にはなるのでよく使われます。

問題は、maisumakunさんも指摘されていますが、適切にインストールされた本番環境では通らないバスが存在します。
そこをテストするためには、特殊な環境を構築してテストするしかありません。その環境構築にもバグは発生します。

通常の使用方法では発生しない不具合を検出するために、特殊な環境を構築し、そのデバッグ(場合によってはその環境自体のテスト)を行う工数を投入するより、通常の使い方でよく通るパスについて、全部は無理にしてもたった一通りではなく、よく通ると思われる組合せについて重点的にたくさんテストするべきと思います。


(*1)
例えば、C1カバレッジ・テストで、if文Aがfalseの時のみ、if文Bがtrueとfalseの両方の条件をテストしているかも知れません。
そのような時、if文Aがtureでif文Bがfalseの時のみ発生する不具合は検出できません。
実際、C1カバレッジは特定のif文については両方テストしますが、その時、他のif文がどうなっているか考慮しません。

きちんとプログラム全体を結合した状態でテストする場合は、他のif文はtrueかfalseのどちらか限定となります。
通常は、C1カバレッジの測定は単体テストで実施するため、あるモジュールが他のモジュールへ与える影響を考慮しません。仮にC1カバレッジを100%にしても、モジュール間I/Fに存在するバグを検出する能力がありません。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/26 16:23

    > 個人的にはカバレッジを上げることがソフトウェアの品質を上げることにはつながらないと思っています。

    C1で100%を目指す場合、単体テストで行うと思います。これはモジュール間I/Fのテストを行わないテストですから、ソフトウェア全体のテストとしては意味がないです。なので単体テストでカバレッジを上げることにあまり意味はないと私も感じています。

    しかし、全体テストで100%カバーできれば、それはたいへん効果的と思います。再度しかし、maisumakunさんの指摘通り、適切にインストールされている環境では通らないバスが存在しますから、そこを通すテスト・ケースを作れませんので事実上100%は無理です。

    「実際に使用する環境では通らないパスがあるため、そこをテストするには単体か疑似環境でテストするしかない。実際には通らないパスのテストに工数をかけても、実際の場面で発生するバグの検出力はほとんどない。その分、納期短縮や全体テストの充実等に工数を投入した方がよいのでは?」って感じでしょうかね。
    (最後の部分はクライアントが望みそうな提案ができれば食いついてくるかも。)

    キャンセル

  • 2017/05/26 17:47 編集

    『フカシギの数え方』の動画がすごすぎて見入ってしまいましたw

    C0の100%は書いたプログラムがエラーにならずに動くという証明になるだけで、
    その結果が正解か否かという、いわゆる仕様バグは全く見つからないですからね。

    それを見つけるためには、C1, C2のカバレッジを上げる必要がありますが、
    単体テストでのC1 100%は確かにあんまり意味ないでしょうね。。。
    モジュール間I/F(複数の業務をまたぐ)が絡んでこないからという理由も、まさにその通りだと僕も思います。

    キャンセル

  • 2017/05/29 13:13

    > モジュール間の話
    工程をどう組むかによりますが、次工程の試験でやればいいのではないでしょうか?

    > それを見つけるためには、C1, C2のカバレッジを上げる必要がありますが、
    C1・C2を行っていても、そもそも仕様を把握していない結果「書かれなかった」コードに対してはカバレッジ測定は無力であるのでやはりそれでも完璧ではないのだと思います。

    キャンセル

checkベストアンサー

+2

僕は受注開発してないので後者はわかりませんが、前者について。(私見です)

〇カバレッジを100%にしなくていい理由
機械的にC0/C1/C2のテストしようとしたらテストケースってコードで増減しますよね。
分岐を上手に減らせばテストケースは減ります。
逆に、下手なコーディングするとカバレッジ100%を達成するのに必要なコーディング量は倍々ゲームで増えていきます。

ここで、本来のTDDで言われるような単体テストの目的を考えてみてください。
最初に単体テストが提唱されているのは、目的に叶ったメソッドデザインを作成する、そしてその目的が達成できているかどうかをチェックすることです。
つまり、「外側から見た構造」をテストしていくんですよね。

機能設計が先か、実装が先かって話で、内部コードのカバーはデザイン時に決定されません。
ってことは、利用目的から内部コードのカバレッジ100%を目指すことはできません。
=カバーコスト(内部カバレッジ100%)は顧客要望から導き出すことができないということです。
事前にボリュームが分からないのに、合意は成立しません。

カバーコストは上手な人が作れば減るでしょうし、下手な人が作れば増えるでしょう。
要件がおかしいとか、経験的なボイラーテンプレートによるメトリクスの肥大化も考えられます。
一方で、要求仕様自体は当初から(拡張・変更こそあれ)一定のはずです。

カバレッジからスタートすると、要件とのミスマッチが発生してしまいます。
カバレッジ100%目的のユニットテストは設計とは逆の、パッチングに近いテストコードになってしまうでしょう。
インテグレーションテストは基本的にシナリオベースですし、単体テストもそうではないか、と考えています。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/26 11:21

    >利用目的から内部コードのカバレッジ100%を目指すことはできません
    >一方で、要求仕様自体は当初から(拡張・変更こそあれ)一定のはずです。

    納得です。カバレッジを取る目的を考えると100%は目標にならない。と論理展開できそうな気がします。

    キャンセル

+2

ソフトウェアによっては、プログラムやインストール状態にバグがあるときしか通らないパスが存在することもあります。たとえば、組版ソフトのTeXには、「This can't happen」というようなメッセージが用意してあって、出た場合には「使用中の TeX に間違いがある.TeX をインストールした人に厳しく文句を言おう」とのことです(情報元)。

Javaではあまりないでしょうが、環境によってコードを差し替えるような場合も、環境ごとに見ればカバレッジは100%に達しえません。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/26 11:13

    やはり通らないパスのことを気にしますよね。
    逆に言えば通りうるパスは全て通すべきなのでしょうか?

    キャンセル

+1

ソフトウェアの作り方にもよると思うのですが・・・

たとえば、Webアプリを作っているとすると、
インメモリDBの該当するテーブルをわざと一旦Dropして接続させてみてエラーメッセージが吐かれるかどうかをUTのケースにするということがあると思います。

その際、
・そもそもこのテーブルなかったらその前から動かない
・独自のエラーメッセージの出力はしない
などの状況なのであればやる必要はないような気がします。

カバレッジとは何かをお客さんに説明する前提ですが、
お客さんへの説明も上記理由等で100%にする意味がない旨をお伝えすればよいのではないでしょうか。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/26 11:10

    確かに、通る可能性の無いコードを無理やりモック化して通していることが多いですよね。
    ここらへんも説得材料になりそうですが、やはりモック化してでも100にしないよりはしてくれたほうが安心だとお客さんが思ってたら厳しいんですよね。

    キャンセル

+1

SLAを締結することが大事だと思います。

品質について補償することで、リスクを共有すれば工数として非合理だと言う説明を信じてもらえるとおもわれます。お客さんは品質はタダだと思うので過剰な要求をするのだと思います。

でなければ、ひとつづつわざわざ対応するべきでない事例を上げて許可を取っていくことくらいしか思いつきません。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/29 13:20

    やはり工数として非合理というのが攻めどころってとこですね。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.92%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る