Q&A
まったく関係ない処理の分岐の全てのパターンを網羅する必要はないと思うので、個人的にC2の100%が必要ないと思っています。
ChironianさんもC1であれば100%を目指すべきとお考えでしょうか(もちろん無理筋なパスを考えないとして)
アーキテクトとしてアプリの方針などを考える仕事をしています。
単体試験の工程にて、jUnitをやることになると必ず問題になるのがカバレッジ計測率のお話。
多くの本やサイトではカバレッジ100%までやる必要がないと記載がありますし、個人的にもやりたくないのですが、提案の段階でカバレッジを100%を目指さない論理を持っていません。
100%までやらないと全てのパターンを網羅してると言えないのでテストとして不十分だ。と言われてしまうと反論ができません。
そこで、以下をご教示いただきたいです。
- カバレッジを100%にしなくてもいい理由
- お客さんを納得させるための論理・根拠
回答7件
0
多くの本やサイトに載ってると思いますが
データパターンや条件網羅を考えると
カバレッジを100％やっても全然十分ではない。
むしろ無駄が多い。
すべてを100％にするには比例的に工数が増えることを説明し、
お客さんと共に妥協できる着地点を探す。
例えば
- マネーパスや業務上クリティカルな処理などが絡む処理は100％を目指す。
- 利用係数の高い機能は重点的に複数のデータパターンで100％を目指す。
- 利用係数の低い機能は正常系といくつかの異常系のみ80％以上を目指す。
目指すって書いておけば、98％だったときに
残りの2％は工数見合いで、他の機能を優先させました。
クリティカルパスのhogehogeに限っては100％です。
みたいな感じでしょうか。
人と金と納期の引き合いに出すと分かってくれる人もいる。
が、100％にこだわる人もいる。
投稿2017/05/25 03:54
総合スコア1400
0
こんにちは。
まず、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/25 05:52
編集2017/05/25 06:00
総合スコア23272
「まったく関係ない」という判断自体がバグることって意外にありますよ。
予想外の変更が影響していたことってありません?
なので、ソフトのバグを無くすためにはC2 100%は必要と思います。しかし、C2 100%の実施は不可のなのでソフトのバグを撲滅することは残念ながら不可能なのです。
次に、例えば医療機器や飛行機のエンジン制御、原子炉の制御などであればC1の100%も必要かもしれません。(単体テストのC1 100%にどれほど意味があるのかは疑問を感じますが。)
そうではない「普通」のソフトウェア開発でC1 100%は費用対効果的にはやらない方がより良い結果を生むと思います。
C1 100%にするためだけに工数が大きくかかる部分(数%程度の筈)は断念して、実際に発生し得るバグの検出力がより高いテストを行った方が良いと思います。
> 「まったく関係ない」という判断自体がバグることって意外にありますよ。
もちろんそのとおりですが、その判断がバグる理由になるような状況ってたぶん他の問題を抱えていると思います。ドメインがうまく整理されていないとか。
> ソフトのバグを無くすためにはC2 100%は必要と思います。
個人的にはカバレッジを上げることがソフトウェアの品質を上げることにはつながらないと思っています。
http://bliki-ja.github.io/TestCoverage/
> 医療機器や飛行機のエンジン制御、原子炉の制御などであれば
そうですね。社内システムなら何%・社外向けなら・人命が関わるならというのも判断であるでしょうね。
> 実際に発生し得るバグの検出力がより高いテストを行った方が良いと思います。
そのとおりだと思います。お客さんに話をするにはやはり費用対効果の話ができればって感じでしょうかね。
> 個人的にはカバレッジを上げることがソフトウェアの品質を上げることにはつながらないと思っています。
C1で100%を目指す場合、単体テストで行うと思います。これはモジュール間I/Fのテストを行わないテストですから、ソフトウェア全体のテストとしては意味がないです。なので単体テストでカバレッジを上げることにあまり意味はないと私も感じています。
しかし、全体テストで100%カバーできれば、それはたいへん効果的と思います。再度しかし、maisumakunさんの指摘通り、適切にインストールされている環境では通らないバスが存在しますから、そこを通すテスト・ケースを作れませんので事実上100%は無理です。
「実際に使用する環境では通らないパスがあるため、そこをテストするには単体か疑似環境でテストするしかない。実際には通らないパスのテストに工数をかけても、実際の場面で発生するバグの検出力はほとんどない。その分、納期短縮や全体テストの充実等に工数を投入した方がよいのでは？」って感じでしょうかね。
（最後の部分はクライアントが望みそうな提案ができれば食いついてくるかも。）
『フカシギの数え方』の動画がすごすぎて見入ってしまいましたｗ
C0の100％は書いたプログラムがエラーにならずに動くという証明になるだけで、
その結果が正解か否かという、いわゆる仕様バグは全く見つからないですからね。
それを見つけるためには、C1, C2のカバレッジを上げる必要がありますが、
単体テストでのC1 100%は確かにあんまり意味ないでしょうね。。。
モジュール間I/F（複数の業務をまたぐ）が絡んでこないからという理由も、まさにその通りだと僕も思います。
> モジュール間の話
工程をどう組むかによりますが、次工程の試験でやればいいのではないでしょうか？
> それを見つけるためには、C1, C2のカバレッジを上げる必要がありますが、
C1・C2を行っていても、そもそも仕様を把握していない結果「書かれなかった」コードに対してはカバレッジ測定は無力であるのでやはりそれでも完璧ではないのだと思います。
0
最低でもC0は単体試験で100％にするでしょう。って思っているんですが、
そんなに甘くはないんですか？
書いたコードを通さないとかありえるんですか？
どんなにイレギュラーなケースでも、何とか擬似的に再現させてでも通しますよね。
C1は業務処理であれば、業務パターンそのものとも言えるので網羅すべきですが、
フレームワーク部分がしんどいかもしれませんね。。。
問題はC2ですね。
データパターンのマトリクスに◯✕付けまくって、
ありえないケースや無意味なケースはグレーアウトして、
残ったものを片っ端からやっていこうというあれですね。
あれに関しても、本来は必要だと僕は思っていますが、
でかいシステムになるとケース数が、「これほんとにやるの？」っていう数になることも
しばしばあるので、そこは頭使って取捨選択していくのが現実的でしょうね。
つまり、ここの100％は現実的でない時もあります。
そして一番つらいのは、全てをJUnitで再現させるってことじゃないでしょうか。
しかし何かしかの計測ツールを使わないと、パーセンテージに説得力がないし
っていうところですよね。。。
お客さんへの説明は費用対効果しかないんじゃないですかね。
98％から100％にするだけで、さらにこんだけ工数かかりますよ。
かと言って残り2％をやる価値としては、こんなもんですよ。
それでもやりますか？
金払うからやれと言われればやるしかないんでしょうね。。。
ただ、金もらっても間に合うかどうかは別問題なので、スケジュールの調整は必要ですね。
投稿2017/05/25 04:57
編集2017/05/25 05:12総合スコア4666
自分も同じ考えだったのですが、多くの本やサイトで80~90を目指すほうがいいという記述が多かったので質問させていただきました。
例えば以下のサイトなどです。
http://bliki-ja.github.io/TestCoverage/
興味深く読ませてもらいました。ありがとうございます。
ただ、C0が100％でないというのは、僕の中ではあり得ないという思いは変わりません。
100％に固執すると、品質評価が目的ではなく、100％にすることが目的になりがち
ってのは本当にその通りだと思いますね。。。
>カバレッジの数字ばっかり気にして、自分が何をやっているかわかっていない人間のいる臭いがする。
マジでこれです。こればっかりです。マネージャークラスでもこれです。
まぁ、作るアプリケーションがどんなものかってのが、テストへの過敏度は変わりますよね。
このサイトの内容は同意できることも多いですが、アプリケーションの性質によって
この辺りの感覚は、柔軟に変えていくべきなんではと思います。
例えば金融系や、原発の制御などは、テストしすぎなぐらいした方がいいかもしれませんから。
いついかなる時も、「100％が正義！」と固執するのは合理性が全くありませんね。。。
C0は基本的に必要性から生まれた分岐点ですから100%になると思います。
しかし、自然に100%にならないケースもあります。要件に「未定義」とか「この引数は必ず１」とかいう仕様がある場合、僕は何か処理は入れますがすぐにはテストを作りません。ですから、C0が100%より減ることがあります。
「想定外の値が来た時は止めてくれ、進めてくれ」って話を相手が決めてくれたらテストを作ります。
取り決めがない間はとりあえず100%より低くていいと考えています。
相手が面倒臭がって98%になれば、それはそういう仕事です。
0
ベストアンサー
僕は受注開発してないので後者はわかりませんが、前者について。（私見です）
〇カバレッジを100%にしなくていい理由
機械的にC0/C1/C2のテストしようとしたらテストケースってコードで増減しますよね。
分岐を上手に減らせばテストケースは減ります。
逆に、下手なコーディングするとカバレッジ100%を達成するのに必要なコーディング量は倍々ゲームで増えていきます。
ここで、本来のTDDで言われるような単体テストの目的を考えてみてください。
最初に単体テストが提唱されているのは、目的に叶ったメソッドデザインを作成する、そしてその目的が達成できているかどうかをチェックすることです。
つまり、「外側から見た構造」をテストしていくんですよね。
機能設計が先か、実装が先かって話で、内部コードのカバーはデザイン時に決定されません。
ってことは、利用目的から内部コードのカバレッジ100%を目指すことはできません。
＝カバーコスト（内部カバレッジ100%）は顧客要望から導き出すことができないということです。
事前にボリュームが分からないのに、合意は成立しません。
カバーコストは上手な人が作れば減るでしょうし、下手な人が作れば増えるでしょう。
要件がおかしいとか、経験的なボイラーテンプレートによるメトリクスの肥大化も考えられます。
一方で、要求仕様自体は当初から（拡張・変更こそあれ）一定のはずです。
カバレッジからスタートすると、要件とのミスマッチが発生してしまいます。
カバレッジ100%目的のユニットテストは設計とは逆の、パッチングに近いテストコードになってしまうでしょう。
インテグレーションテストは基本的にシナリオベースですし、単体テストもそうではないか、と考えています。
投稿2017/05/25 06:12
編集2017/05/25 07:34総合スコア1591
>利用目的から内部コードのカバレッジ100%を目指すことはできません
>一方で、要求仕様自体は当初から（拡張・変更こそあれ）一定のはずです。
納得です。カバレッジを取る目的を考えると100%は目標にならない。と論理展開できそうな気がします。
0
ソフトウェアによっては、プログラムやインストール状態にバグがあるときしか通らないパスが存在することもあります。たとえば、組版ソフトのTeXには、「This can't happen」というようなメッセージが用意してあって、出た場合には「使用中の TeX に間違いがある．TeX をインストールした人に厳しく文句を言おう」とのことです（情報元）。
Javaではあまりないでしょうが、環境によってコードを差し替えるような場合も、環境ごとに見ればカバレッジは100%に達しえません。
投稿2017/05/25 04:07
総合スコア145183
0
SLAを締結することが大事だと思います。
品質について補償することで、リスクを共有すれば工数として非合理だと言う説明を信じてもらえるとおもわれます。お客さんは品質はタダだと思うので過剰な要求をするのだと思います。
でなければ、ひとつづつわざわざ対応するべきでない事例を上げて許可を取っていくことくらいしか思いつきません。
投稿2017/05/26 15:05
総合スコア2883
0
ソフトウェアの作り方にもよると思うのですが・・・
たとえば、Webアプリを作っているとすると、
インメモリDBの該当するテーブルをわざと一旦Dropして接続させてみてエラーメッセージが吐かれるかどうかをUTのケースにするということがあると思います。
その際、
・そもそもこのテーブルなかったらその前から動かない
・独自のエラーメッセージの出力はしない
などの状況なのであればやる必要はないような気がします。
カバレッジとは何かをお客さんに説明する前提ですが、
お客さんへの説明も上記理由等で100%にする意味がない旨をお伝えすればよいのではないでしょうか。
投稿2017/05/25 03:48
総合スコア2021
確かに、通る可能性の無いコードを無理やりモック化して通していることが多いですよね。
ここらへんも説得材料になりそうですが、やはりモック化してでも100にしないよりはしてくれたほうが安心だとお客さんが思ってたら厳しいんですよね。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/05/26 02:12
2017/05/26 03:02
2017/05/29 04:22