@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
コードカバレッジに関して
1|2|3
次のページへ»
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-10-19 13:30
お世話になります。
最近、品質管理のメトリクス関連の仕事を割り振られました。 そこで、コードカバレッジを使いたいな、と思っているのですが よく理解出来ないので皆様のお知恵を拝借したいと思います。 コードカバレッジに関しては C0: 命令網羅率(ステートメントカバレッジ): コード内の全てのステートメントを 少なくとも1回は実行 C1: 分岐網羅率(ブランチカバレッジ): コード内の全てのブランチを少なくとも1回は実行 C2: 条件網羅率(コンディションカバレッジ): コード内のすべての条件を少なくと も1回は実行 があると思いますが、お聞きしたいのはここの「C0」と「C1」です。 例えば、
とある場合、 1. intCount = 10 で「XXX」を実行 2. intCount = 11 で「YYY」を実行 で「C0」と「C1」のカバレッジ率は 100% だと思います。 疑問なのは「C1」が 100% にならないと「C0」も 100% にならない ( 逆も同じ ) と思います。 つまり「C0のカバレッジ率が100%」だと、自動的に「C1のカバレッジ率も100%」 といえることなり、そもそも「C0」と「C1」を分ける必要はあるのですか? と思ってしまいます。 多分、命令網羅率や分岐網羅率などの本来の意味を理解していないためだと 思いますが、どこが間違っているのかをご教示頂ければ幸いです。 宜しくお願いいたします。 | ||||||||
|
投稿日時: 2005-10-19 14:06
unibon です。こんにちわ。
#良くは知りませんが。 高級言語ではなく低級(?)言語で考えたほうが良いのかもしれません。アッセンブリー言語の jmp のようなものや、あるいは GOTO を多用した BASIC などでは、どこかからいきなり飛んでくるようなことがあり、C0 は満たしても C1 は満たさないことがあるのではないでしょうか。 | ||||||||
|
投稿日時: 2005-10-19 14:11
こんにちは。
品質管理とかコードカバレッジに関してはあまり詳しくないんですが、 こんなコードだとどうでしょう?
#コードをちょっと修正 [ メッセージ編集済み 編集者: ぼのぼの 編集日時 2005-10-19 14:20 ] | ||||||||
|
投稿日時: 2005-10-19 14:53
懐かしいなぁ・・・
たしか、C0、C1等に関しては、コードに対してどれだけカバーしたテストかかというものだったかと。 C0は、条件文を除いた実行処理、C1は分岐方向の方向、だったかな。 以下のコードがあったとします。
でC1 100%でテスト項目作成となれば、 1、intCount = 10 2、intCount = 0 3、intCount = 11 で、一応100%は達成されます(条件分岐命令に関する方向数) 条件分岐が二つあり、その二つが両方とも実行され、さらに全ての方向(3つ)が実行されていますよね? この三つの方向(intCount = 10 のTRUE,FALSE、FALSEのときのintCount <> 0のTRUE,FALSE)に対する%だったかと。 C0が100%となれば、 1、intCount = 10 2、intCount = 11 だけですね。 (YYY実行しなければならないため) この場合、3方向のうち2方向だけなのでC1は66.6%。 たしかこんなのだったかと。 #もう6年前にちょこっと(1分ほど)聞いただけなので忘れちゃった・・・ | ||||||||
|
投稿日時: 2005-10-19 15:36
一応補足しますと、品質管理という事であれば、C0/C1等は残念ながらこれだけでは品質の維持は出来ないはずです。
これは書いたコード数に対する、テスト項目のカバー率なので。 悪く言えば、C0/C1を100%で全部不合格というのもありえるのですよ。 先のコードで、「XXX」となっているところは本当は「AAA」となっていなければならないかもしれません。 しかし、C0/C1等カバレッジは、あくまでも「カバー率」なので、「XXX」であろうが「AAA」であろうが「CCC」であろうが、テスト項目の結果予想内容とは関係ないんですね、テスト項目がコードに対してC0/C1が100%であることとは。
C0/C1を100%でテスト項目の作成をする。 テスト結果予想は、仕様書にあるとおりとする。 仕様書 ・intCount = 10のときAAAが表示される ・intCount = 0のときなにも表示されず ・intCount = 11のときYYYが表示される No,テスト項目条件,テスト結果予想,合否,備考 1,intCount = 10 ,AAAが表示される,否,XXXが表示された 2,intCount = 0 ,なにも表示されず,合, 3,intCount = 11 ,YYYが表示される,合, 仕様書に対するテストの合格率は66.6%、C0/C1は100%。 となってしまいます。 でも、テスト項目の作成のためには活用出来ると思います。 品質の維持であれば、C0/C1以外に他の何かも必要になると思います。 _________________ #「やらない」と「出来ない」を混同してはならない | ||||||||
|
投稿日時: 2005-10-19 17:05
この例でのXXXとYYYの内容によりますね。 C0はステートメントベースですから、もしYYYがExit、End、Breakなどのような ものですと、特にカウントしません。 また、YYYが単に外部共通処理なら、別のところで実行していればここでは実行 しなくても100%になるということです。(普通はしますけどね) C1の場合には、単にExitであってもその分岐条件を満たすテストを行うという ことで、よくC0とC1で違いが出るのはシステムエラーとかの対応部分だったり します。エラー処理というひとつのところにいろんなところから飛ばしますから ね。 ま、テストツールとかの場合にはこんな感じでしょうけど、人間系でやる場合 にはC0、C1なんてとてもじゃないけど区別してやってられないでしょうね。 | ||||||||
|
投稿日時: 2005-10-20 13:10
返信、ありがとうございます。
まず最初に謝罪なのですが、 当方、最初は某 ML にて同じ問題を投げましたが、 メーラーの調子が悪く私だけ ML のメールが受信出来ませんでした。 ですが、私は勘違いして「ML に投稿出来ない」と判断してしまい、 ここの掲示板に記述させて頂きました。 何が言いたいかというと、結果的にマルチポストになってしまい、 大変申し訳なく思っています、という事です。 今後はこのような事がないように致しますので、ご寛恕頂ければ幸いです。 > unibonさん GOTO 文とかがあれば仰る通りですね。 この観点はなかったので大変参考になりました。 > ぼのぼのさん えっと、、、どの辺りを重点的に見れば宜しいのでしょうか? 個人的には 1. da.exist の結果が true 2. da.exist の結果が false 3. da.update or da.insert ( or da.exist ? ) で Exception を発生させる で全ての条件を網羅するのでは?と思ってしまうのですが。 何か勘違いしているのでしょうか? > 宣伝中止!さん サンプルソースも書いていただきありがとうございます。 お蔭様でやっと内容を理解出来ました。 ただ、これを目視で確認するのは非常に辛いですね。。。 やはりツールを使わなければならないのでしょうかね。。。 > Beatleさん 具体的な状況を想定して頂きありがとうございます。 エラー処理などの状況も想定していなかったので、新たな観点として 勉強させて頂きました。 ありがとうございます。 ついでに、というと失礼ですが、品質に関してもう 1 点質問させて頂ければ幸いです。 よく、「 1 関数の行数は 30 行以下が望ましい」などの文を ( 私は ) 良く見かけるのですが、 「1 関数 30 行以上と以下だと、こんなに品質に違いがあります」のような 根拠ってあるのでしょうか? 感覚的には短い方がいいというのは理解していますが、 「僕が良いと思っているので皆さんもやりましょう」じゃー、 もちろん説得力が無く。。。 宜しくお願いいたします。 | ||||||||
|
投稿日時: 2005-10-20 14:06
ども。
ツール、使わないとならないでしょうね。 昔私がC0/C1の話を聞いて仕事していたときには、あくまでも「机上デバッグ」で不具合をたたき出すために使ってました。 その後、実際にテストで使う場合には仕様どおりに動くかどうかを確認するために仕様書からテスト項目を作成していました。 現在の開発の仕方からすると、C0/C1はコーディング実装時にきちんと把握してもらい、 他の方法でテスト項目作成をして品質を保たせるという方法が有力なのではないかな?と思っております。(但し私の偏見・私見です)
私が昔見た本から考えると、それは、一画面に表示される行数の問題かと・・・ 昔のディスプレイだと、一画面に表示されるのは20〜30行というのが多かったから、そういう話が受け継がれているのかもしれません。 特に、エディタによってはスクロールは画面表示単位(!)というのもあったので、 違うページに表示されるとわかりにくくなるとか、そういったことでしょうね。 短いほうがいいとは思いますが、品質の問題とは直接の関係が無いのかと。 もしあるとしたら、「保守のしやすさ」と関連して間接的に関連があるのかもしれません。 (一発で全体が見えるので、コードが読みやすくなっているから、画面を見ながら妥当性を検証しやすいとか) _________________ #「やらない」と「出来ない」を混同してはならない |
1|2|3
次のページへ»