IT ニュース＆コラム    2018/ 3/26   通巻759号  技術版

                             ソフトウェアデザイン館  Sage Plaisir 21

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣


■■　カバレッジ100%を目標にしないほうが品質が高い　■■


木を見て森を見ず、という言葉は目標管理において非常に重要である。
特に100%パーセント以上達成が不可能な目標については、100%を目指してはいけない。

プログラムの品質を上げる方法の１つとしてカバレッジ（網羅率）を上げることが
ある。 網羅率には、以下の種類がある。

・C0: 命令網羅率。 すべての命令コードを実行しているか
・C1: 分岐網羅率。 C0だけでなく、命令コードのない条件分岐（else が記述されて
　いないコードの else になる条件）も実行しているか
・C2: 条件網羅率。 C1だけでなく、条件式に and/or 条件があり、それぞれの条件
　の真偽の組み合わせも実行しているか

ややこしいのは、ソフトウェア品質の分野においてカバレッジ（網羅率）は、
C0, C1, C2 がすべてであって、すべてのケースを網羅している訳ではないということだ。
つまり、C2の網羅率を100%にしても、すべてのケースにバグがないことを確認
したわけではないので、まだバグが潜んでいる可能性があるということだ。

たとえば、データの境界値という観点に関してはカバレッジで網羅すべき対象には
含まれていない。 データの範囲が 0から100 の間しか出力値として許されない
仕様があったとしても、そもそもその範囲チェックをするコードが無ければ、
網羅率が 100%でもバグがあることになる。

input=50 だけで網羅率は100%だが、バグのある（仕様と異なる）コード：
    output = input;
    return  output;

input=50 だけで網羅率は33%だが、バグのないコード：
    output = input;
    if ( output < 0 ) { output = 0; }
    if ( output > 100 ) { output = 100; }
    return  output;

また、文書に書かれた仕様自体にバグがある可能性もある。コンピューターによる
簡易的なチェックさえ通していない仕様書は、むしろコードよりもバグが多いだろう。

網羅率が簡単に100%を達成できるのなら、その目標でも問題ないのだが、90%から
100%を達成するのに何か月もかかるのなら問題だ。 そんなに期間があるのなら、
網羅率の観点以外の観点、たとえばデータの境界値についてテストするほうが、
より広いケースで問題ないことが実証できていることになる。 無限に開発期間が
あるわけではないので、まず網羅率を100%にすること、話はそれからだ、という
わけにはいかない。

たとえば、以下の簡単なコードの命令網羅率が100%になるための入力値
（input_type とinput_value の値）をすべて挙げてみてほしい。

    if ( input_type == 1 ) {
        output = input_value * 2;
    } else if ( input_type == 2 ) {
        output = input_value * 3;
    } else {
        exit(1);
    }
    if ( output < input_value ) {
        exit(2);
    }
    if ( output < input_value  &&  input_value >= 0 ) {
        exit(3);
    }
    return  output;

exit(2)を通るための入力値を挙げられるだろうか。
exit(3)を通るための入力値を挙げられるだろうか。
実は、このコードはC0（命令網羅率）100%を達成することは不可能である。
exit(2)のコードは input_value の値をマイナスの値にすれば通るが、
exit(3)のコードは、通すことができないからだ。

しかし、このコードは問題なく動く。 エラーとなる条件がないので、
exit(3)で強制終了する必要がないからだ。 余分なコードがあることは
問題だが、プログラムの実行速度が一瞬遅くサイズが少し増えるだけで、
実質問題にはならない。

なんとなく実行しなさそうではコードだからとコードを削除できないので、
exit(3)に関するコードを削除して網羅率100%を達成するにはかなりの
工数がかかるだろう。有り得ない条件であることを証明することは悪魔の
証明に近いものがある。 それだけ工数をかけて実質問題にならない問題を
解決する意味はない。

以上から、リリース後のバグの発生件数を下げる目標を立てるときは、網羅率を90%
から100%に上げるという手段を目標を立てても、バグの発生件数はほとんど変わらない。
実際、グーグルは 85%を努力目標としており、著名な方法論の著者であるマーティン・
ファウラー氏によれば、「思慮深くテストを実施すれば、テストカバレッジはおそらく
80%台後半か90%台になるだろう。100%は信用ならない。」とブログに載せている。

https://qiita.com/bremen/items/d02eb38e790b93f44728
http://monoist.atmarkit.co.jp/mn/articles/1611/17/news013.html
https://www.ibm.com/developerworks/jp/java/library/j-cq01316/index.html
http://bliki-ja.github.io/TestCoverage/
https://ja.wikipedia.org/wiki/アンチパターン



■■　注目ニュース  一覧　■■


◇ 生産性向上を前提にしたソフトウェア開発に警鐘。IPA。
https://builder.japan.zdnet.com/off-topic/35115706/
 … 品質要求レベルに見合った目標を設定しないと納期は遅れる。

◇ Windowsの次期アップデートでONNXベースのAIモデルがネイティブに実行可能に。
http://www.atmarkit.co.jp/ait/articles/1803/12/news029.html
 … アプリケーションに AI を導入できる。

◇ Oracle、Java SE 10／JDK 10 の一般提供を開始：6カ月サイクルでの初リリース。
http://www.atmarkit.co.jp/ait/articles/1803/23/news051.html
 … Java言語が拡張されていく。

◇ Apple、障害者絵文字をUnicode Consortiumに提案。
http://www.itmedia.co.jp/news/articles/1803/25/news013.html
 … 文字にすると悪いイメージが付きやすいものをイメージ化。

◇ AIによるタクシー需要予測で平均売上が20.4％増、トヨタと日本交通が今年度に実用化。
https://it.impressbm.co.jp/articles/-/15802
 … AIが出した答に全員が従ったときは、また結果が違うはず。

◇ Web制作をぐっと効率化するスタイルガイドの作り方とは？
https://www.webprofessional.jp/web-designers-should-do-compassion/
 … ガイドに同意すれば効率が良くなるが、ガイドがダサいと逆効果。

◇ 子ども向けのYouTube「エルサゲート」を避けるコツ。
https://japan.cnet.com/article/35116449/
 … 削除ではなく悪意のないジャンルでフィルタリングしないと発生し続ける。



■■　ソフトウェアデザイン館  Sage Plaisir 21　■■


  ホームページ   >>> http://www.sage-p.com/
  メルマガ       >>> http://www.mag2.com/m/0000083983.html
  ブログ         >>> http://blog.livedoor.jp/sage_p/
  ツイッター     >>> http://twitter.com/Ts_Neko
  ダウンロード   >>> http://www.sage-p.com/freesoft.htm
  サポート掲示板 >>> http://www.sage-p.com/kg_ban09/z6037C8.cgi
  東日本大震災   >>> http://www.sage-p.com/saigai.html
  メール         >>> ts-neko◇sage-p.com   ←◇を@に変えてください
                     緊急メールは件名に「うどんメール」を付けてください。

      このメルマガの登録・解除 - http://www.mag2.com/m/0000083983.htm