2009年11月24日
二重人格の改造人間が解き放つ、超弩級・バイオレンス駄作
◆書名：メギド
◆著者：渡辺 裕之
◆出版社：角川書店(角川グループパブリッシング) (2009/9/19)
◆著者：渡辺 裕之
◆出版社：角川書店(角川グループパブリッシング) (2009/9/19)
主人公の名前・「メギド」。いきなり記憶喪失。思い出そうとすると・・・ぐっ・・・頭が割れるようにっ・・・！
そう、この時点で読むのを止めるべきだったんだ・・・。
そう、この時点で読むのを止めるべきだったんだ・・・。
一箇所だけ引用しておこう。どんな作品か、これだけでも十分推測できそうなものだ。
『メギド』P.67
「一つ聞きたい。メギドが、"エリア零"から脱走して、いったい何日になる？」
「・・・およそ一ヶ月になります」
答えた松宮の顔が、さっと青くなった。
「松宮。君は以前零チャイルドが薬の投与を受けなくなった場合、三週間以内に死亡すると言っていなかったか」
「これまでの実験では、それ以上長く生きた者はいませんし、理論的にも細胞が死滅してしまいますので、生存率はゼロかと、・・・」
「しかし、生存期限を過ぎてもメギドは、生きている。しかも、奴は、零チャイルドの第一世代で極めて不完全であると君は報告していなかったか」
「過酷な条件で手術を行った結果、我々にも、メギド自身にも彼の力を制御できない時があると報告しました。我々は、それをなんとか矯正できると信じていましたが」
「・・・およそ一ヶ月になります」
答えた松宮の顔が、さっと青くなった。
「松宮。君は以前零チャイルドが薬の投与を受けなくなった場合、三週間以内に死亡すると言っていなかったか」
「これまでの実験では、それ以上長く生きた者はいませんし、理論的にも細胞が死滅してしまいますので、生存率はゼロかと、・・・」
「しかし、生存期限を過ぎてもメギドは、生きている。しかも、奴は、零チャイルドの第一世代で極めて不完全であると君は報告していなかったか」
「過酷な条件で手術を行った結果、我々にも、メギド自身にも彼の力を制御できない時があると報告しました。我々は、それをなんとか矯正できると信じていましたが」
イタ過ぎるキーワードがチラホラと。
技名「鬼殺し」「猿（ましら）崩し」とかヤバ過ぎ(笑)。
技名「鬼殺し」「猿（ましら）崩し」とかヤバ過ぎ(笑)。
出版社に良心はないのか。企画の段階で止めてくれ。
記憶を無くしているとか実はすごい力を秘めているとか二重人格とか第1世代は実験体といいつつ最強とか第2世代以降と戦う悲しい運命とか、きょうび少年ジャンプでもそんなマンガないよ！
・・・いや、けっこうあるか。読み切りで。
きっと、第二人格に覚醒するときには、片目に斑紋が現れたり色が変わったりするんだろうなあ。
記憶を無くしているとか実はすごい力を秘めているとか二重人格とか第1世代は実験体といいつつ最強とか第2世代以降と戦う悲しい運命とか、きょうび少年ジャンプでもそんなマンガないよ！
・・・いや、けっこうあるか。読み切りで。
きっと、第二人格に覚醒するときには、片目に斑紋が現れたり色が変わったりするんだろうなあ。
・・・・・・。
次こそ、ソフトウェア品質に関する話をエントリするぞお！
次こそ、ソフトウェア品質に関する話をエントリするぞお！
2009年11月18日
現実にあるのかも知れない、たぶん普通の人たちの負の連鎖
◆書名：告白
◆著者：湊 かなえ
◆出版社：双葉社 (2008/8/5)
◆著者：湊 かなえ
◆出版社：双葉社 (2008/8/5)
うわわわわ！読後感悪い！
第6回本屋大賞となった、湊かなえのデビュー作・『告白』はそんな小説です。
図書館の500人くらいの予約待ちキューが今日やっと掃け、週末にゆっくり読もうと思ったのですが、3時間で読了してしまいました。いやあ今日は帰宅後、集中して勉強するつもりだったんですけどね、この本のせいで。挫折しました。この本のせいで！
『告白』は、一連の悲惨な事件を6つの章にわけ、それぞれ別の人間の視点から解き明かしていくというミステリー。人間の「心の闇」(笑)が連鎖に連鎖を重ね、モノローグのうちにさりげなく潜むイヤな伏線がどんどん回収されていく・・・。ちょっと話の方向に光が垣間見えても、次の章で全否定されてしまうような底意地の悪さ。
道尾秀介の『鬼の跫音』に納められた一連の短編も、切れ味抜群の伏線と重苦しい空気に満ちているんだけど、そこには何となく「小説」の匂い、「これは作り話だよね」という一線があった。
でも『告白』は、「これ本当にあるんじゃないの？」という、一歩間違ったら現実側に倒れこんできてしまいそうな手触りがあり、とても気持ち悪い。それでいて、とても面白い。（勉強に手がつかないのも無理はないね）
でも『告白』は、「これ本当にあるんじゃないの？」という、一歩間違ったら現実側に倒れこんできてしまいそうな手触りがあり、とても気持ち悪い。それでいて、とても面白い。（勉強に手がつかないのも無理はないね）
面白いけど、でもこういう「見事な伏線」な小説を、最初の1回、伏線確認で2回、まではともかく、3回以上読む人っているんでしょうか。ある意味、星新一のショートショートにすごく肉付けして暗〜くした作品、であり、何回も読むもんじゃないですよね。つまりもっと言うと、買う本じゃないですよね。Amazonにリンク張っておいてナンですけれども。
あ、星新一は未だに何回も読みます。
大好きです、『ボッコちゃん』。
大好きです、『ボッコちゃん』。
2009年11月17日
「IT業界」は虚業なのか！？
『月刊ビジネスアスキー』の読者コーナーに、こんな投稿がありました。
『月刊ビジネスアスキー』2009年11月号
そもそもこの10年、IT業界なる言葉が製造業界や建設業界とさも同格のように使われてきましたが、少なくともIT業界とやらが私の生活を向上させたり、変化をもたらした記憶はありません。
我々一般人にまったく恩恵をもたらさない業種が大きな顔をしていること自体、おかしいとは思いませんか。
我々一般人にまったく恩恵をもたらさない業種が大きな顔をしていること自体、おかしいとは思いませんか。
ITバブルで株の含み損でも抱えているのでしょうか・・・。
現在において、IT業界から恩恵をもたらされていない「一般人」がいるとは思えないのですが、携帯電話も使っていない、インターネットもやらないんでしょうかね。そんな人が、ビジネスアスキーを・・・？
現在において、IT業界から恩恵をもたらされていない「一般人」がいるとは思えないのですが、携帯電話も使っていない、インターネットもやらないんでしょうかね。そんな人が、ビジネスアスキーを・・・？
「IT業界」は、製造業界で培われた製造や品質の方法論をシステム開発にまでに敷衍しようと、日々努力しております。
何も実態を生み出さない虚業のように捉えられているとしたら、悲しいですねえ。
何も実態を生み出さない虚業のように捉えられているとしたら、悲しいですねえ。
2009年11月15日
設計工程の品質を見定めたくて仕方ない(2)
本連載も、今回でいよいよ記念すべき第2回。
カッコイチ。などと連載っぽくすると、一体、第n回で終わればいいのか引き際がわからないので、今回で最終回にしようかと企んでおります。
カッコイチ。などと連載っぽくすると、一体、第n回で終わればいいのか引き際がわからないので、今回で最終回にしようかと企んでおります。
第2回は、レビューの定量化に関する論文をご紹介。
タイトルは、『レビューの質と価値の定量化の提案』。ソフトウェア品質管理に関する、日科技連の2007年度第1分科会（テーマ：「ソフトウェアプロセス評価・改善」）、グループAの論文です。
タイトルは、『レビューの質と価値の定量化の提案』。ソフトウェア品質管理に関する、日科技連の2007年度第1分科会（テーマ：「ソフトウェアプロセス評価・改善」）、グループAの論文です。
本文で8ページの論文なので、（会社の）プリンタで印刷して読みましょう。ちなみにわたしは4in1かつ両面焼きのエコロジストですよ。（blog『ソフトウェアの品質を学びまくる』は、チーム-6%に参加していま せん）
本論文ではレビューを、「価値」(Value)と「質」(Quality)という2つの側面から捉えています。レビューに関して現在普及しているメトリクスが「質」に偏っていることを指摘し、「価値」に関するメトリクスも合わせて提案するものです。
(1)レビューの質
レビューのプロセスに注目。
プロセスの良し悪しの要素は、たとえば「レビューの目的・狙いは明確だったか」といったもので、必ずしも定量化しやすいものとはいえません。よって、これらの要素を12項目のチェックリストにし、その配点をもって質の点数としています。
レビューのプロセスに注目。
プロセスの良し悪しの要素は、たとえば「レビューの目的・狙いは明確だったか」といったもので、必ずしも定量化しやすいものとはいえません。よって、これらの要素を12項目のチェックリストにし、その配点をもって質の点数としています。
(2)レビューの価値
ズバリ、レビューの成果を金額に換算。
この金額を求めるためのパラメタとして、レビューで摘出した不良の修正範囲の広さと発見工程をポイント化します。このポイントに対し、単位ポイントあたりの不良修正時間と、時間単価をかければ、その不良摘出の価値が算出されるというものです。
各パラメタのポイントや算出式など、若干恣意的な部分もありそうですが、何より直感的に理解しやすく、また計算も簡単であるというところが優れていると思います。
ズバリ、レビューの成果を金額に換算。
この金額を求めるためのパラメタとして、レビューで摘出した不良の修正範囲の広さと発見工程をポイント化します。このポイントに対し、単位ポイントあたりの不良修正時間と、時間単価をかければ、その不良摘出の価値が算出されるというものです。
各パラメタのポイントや算出式など、若干恣意的な部分もありそうですが、何より直感的に理解しやすく、また計算も簡単であるというところが優れていると思います。
よく考えてみると、第1回とのつながりがまったくない、第2回になっていますね。第3回では、この2つをアウフヘーベンしていくことになると思います。思うだけなら安いもんですよ。
2009年11月13日
設計工程の品質を見定めたくて仕方ない(1)
社内の有志で、設計工程の品質評価技法についてディスカッションをしています。ソフトウェアの品質を評価するのさえ難しいのに、ドキュメントの品質となるとなおさら手がかりが少なく、いろいろ調べております。
設計のドキュメントの品質を判断するのにまず思いつく量は、
- ドキュメントのページ数
- 見積もった開発規模
- レビューでの指摘件数
- レビューにかけた工数（時間×人数）
など。で、これらを組み合わせた
- 記述密度： 規模あたりのページ数＝� 爿�
- 指摘密度： ページ数あたりの指摘件数＝��÷��
- 生産性： 指摘件数あたりの工数＝�ぁ爿�
といったところでしょうか。
ただ、「枚数」ってあまりに不安定な量ですよね。
ぱっと思いつくだけでも、以下の問題があります。
ぱっと思いつくだけでも、以下の問題があります。
(1)「1ページ」の重みが一定でない
Wordで作った基本設計書と、EXCELで作ったDBのテーブル定義書とで、1ページは同じ価値をもつのでしょうか。フォントや行間が違えば同じ内容でもページ数は変わります。文字数でカウントしようとしても、絵の多いドキュメントだと、中身は濃いのに文字数は少ないかもしれません。
Wordで作った基本設計書と、EXCELで作ったDBのテーブル定義書とで、1ページは同じ価値をもつのでしょうか。フォントや行間が違えば同じ内容でもページ数は変わります。文字数でカウントしようとしても、絵の多いドキュメントだと、中身は濃いのに文字数は少ないかもしれません。
(2)何をもって「1ページ」が決めがたい
たとえばDB上の5個のテーブルで保持されている、1つのカラムの桁数を変えようというとき、テーブル定義書を5ページ書き換えることになりますが、それを「5ページ」と数えてしまうと、１から書いたテーブル定義5ページ分と、桁数をちょっとだけ変える5ページ分が、同じということになってしまう。
たとえばDB上の5個のテーブルで保持されている、1つのカラムの桁数を変えようというとき、テーブル定義書を5ページ書き換えることになりますが、それを「5ページ」と数えてしまうと、１から書いたテーブル定義5ページ分と、桁数をちょっとだけ変える5ページ分が、同じということになってしまう。
ということで、「ページ数」はそう簡単にはメトリクスには使えません。
となると、やはり見積もり技術にも歴史のある��開発規模と、単純に数えられる��指摘件数 が有力候補になります。
となると、やはり見積もり技術にも歴史のある��開発規模と、単純に数えられる��指摘件数 が有力候補になります。
第2回に続く気配がある。
2009年11月11日
Webアプリがまた複雑になっていく恐ろしさ
Webアプリケーションが苦手である。
理由は、ブラウザ特有の動き。
理由は、ブラウザ特有の動き。
ファイル添付しようとして、たとえば画像をD&Dすると、ブラウザごとその画像を開いてしまうような。あわてて「戻る」を押すと、真っ白い画面で「セッションが切れました」と言われちゃうような。
そういう、「自分のオペレーションがちゃんと保持されているかよくわからん」という心もとなさがイヤなのだ。「もうあの頃には戻れない」という、さらば青春的な一抹の寂しさがたまらないのだ。確信をもって、「戻」りたい。
そういう、「自分のオペレーションがちゃんと保持されているかよくわからん」という心もとなさがイヤなのだ。「もうあの頃には戻れない」という、さらば青春的な一抹の寂しさがたまらないのだ。確信をもって、「戻」りたい。
そんな思いも覚めやらぬ今日この頃、『日経NETWORK2009年9月号』で、「Webの限界を打ち破れ！」と題した、HTML5とCometの記事を読んだ。
ちなみにわたしは、雑誌はいつだって図書館で借りる太っ腹男で、そのため情報が常に数ヶ月遅れ。衆院選さえ終わっていないという、まさにインターネット時代の申し子のような存在なのである。
そんな自慢はいいとして、この特集、大変興味深く読んだ。
要約すると、
- HTML： JavaScriptは小さなアプリを想定した言語だし、プラグインやActiveXといった外部プログラムはセキュリティ上のリスクが・・・
→HTML5！もはや単なるマークアップ言語ではなく、JavaScriptがWebブラウザのパーサ・レンダラを利用するルールも規定。機能や表現力がアップ！ - HTTP： サーバからクライアントへ勝手に送りつけることのできないPULL型で、ブラウザが（＝ユーザが）「くれ」といわないと情報が更新されない・・・。
→Comet！サーバ側からいつでも、ブラウザのJavaScriptに情報を送信できる！
ということのようですな。Ajaxすらロクに理解していないというのに、どんどん技術が進んで行く。。。
それにしても、「頼んでもいないのにWebサーバが情報を送りつけてきやがる」っていうこの仕組み、モノスゴク危ないものに思えて仕方ないのだけれど、気の迷いなのかしらん。
それにしても、「頼んでもいないのにWebサーバが情報を送りつけてきやがる」っていうこの仕組み、モノスゴク危ないものに思えて仕方ないのだけれど、気の迷いなのかしらん。
2009年11月07日
ソフトウェアの安定度？成熟度？を計測する
第3回ソフトウェアテストセミナーにおける細川さんのプレゼンテーションで、「SMI」というメトリクスに言及がありました。（待てよ、1つの指標だから「メトリック」というのが正しいのか？しかしそれだとルーティング・プロトコルの話をしているみたいだぜ、ルパン・・・）
このメトリク（単数形）は、IEEE 982.1-1988で規定されているものですね。IEEE 982.1-1988はタイトルがかっこよくて、 「信頼性の高いソフトウェアを構築するための指標の標準辞書」！もうこれさえ読めば、メトリクスのことは全部わかりそうです。
この規格の4.10で、SMI=Software Maturity Indexが規定されています。細川さんによると、「保守フェーズに入ったソフトウェアの安定度を判断するのに使える、珍しいメトリクス」とのこと。
この規格の4.10で、SMI=Software Maturity Indexが規定されています。細川さんによると、「保守フェーズに入ったソフトウェアの安定度を判断するのに使える、珍しいメトリクス」とのこと。
googleで検索すると、Internet黎明期みたいな、「シンプルがいいッ！オレはオレのやりたい方法でwebサイトをデザインするぜッ！」というこのページがめでたくヒットします。
SMIの算出方法は単純。やはり、シンプルがいい。
Software Maturity Index
SMI = ( M - ( A + C + D ) ) / M
・M: 現バージョンでのモジュールの数
・A: 現バージョンで追加されたモジュールの数
・C: 現バージョンで変更されたモジュールの数
・D: 現バージョンで削除されたモジュールの数
・M: 現バージョンでのモジュールの数
・A: 現バージョンで追加されたモジュールの数
・C: 現バージョンで変更されたモジュールの数
・D: 現バージョンで削除されたモジュールの数
モジュールの追加も変更も削除もない場合、つまりそれは機能追加もなければバグフィックスもない、「枯れた」ソフトウェアであるということになるのでしょうが、SMIは1となります。SMIが1に近づけば近づくほど、「安定している」という判断の基準にすることができます。この黎明期のページでも、「ソフトウェア安定度指数の方が近いのでは？」と言っていますね。
一方で、「怖くて直すこともできないソフトウェアは、誰もいじれなくなってSMI=1になっちまうんだから、ソフトウェア停滞度指数でもあるよね」と。
この指数もつまりは、SMIの値だけで判断できると思うな、ってことですな。
一方で、「怖くて直すこともできないソフトウェアは、誰もいじれなくなってSMI=1になっちまうんだから、ソフトウェア停滞度指数でもあるよね」と。
この指数もつまりは、SMIの値だけで判断できると思うな、ってことですな。
1つよくわからないのが、「安定」を表すのに、時間の変数がないのは何故か、ということです。現バージョンリリースから現在までの時間Tを組み込みたくなりませんか？
たとえば、最初のバージョンリリースから現在までの時間T1と、現バージョン（n番目として）Tnの比 Tn/T1は、時間が経てば経つほど1に近づくので、これを掛け算するとかね。
たとえば、最初のバージョンリリースから現在までの時間T1と、現バージョン（n番目として）Tnの比 Tn/T1は、時間が経てば経つほど1に近づくので、これを掛け算するとかね。
2009年11月06日
第3回ソフトウェアテストセミナー(2)
第3回ソフトウェアテストセミナー(1)の続き！よかった、ちゃんと続いて。
ダラダラにならぬよう、今回は箇条書きで書いてみました。
ダラダラにならぬよう、今回は箇条書きで書いてみました。
欠陥密度
- コードのstep数をプログラムの大きさと捉えて、そこに存在する欠陥の数を行数で割った「欠陥密度」を、絶対的な指標として使うべきではない。solidに仕上げたステキコード100行と、同じ内容だけど冗長な150行で、1件の結果があったときに前者の方が欠陥密度が高い=品質が悪い、というパラドックスが起きる。
- step数を使用するとしても、そこに含まれるクラスの数を意識すべき。10,000stepのクラスが1つあるのと、200stepのクラスが50個あるのでは、同じ10,000stepでも意味が違う。
- 欠陥密度を適用するのであれば、初期の開発に対する追加開発の欠陥密度は、といったように「同じ算出方法」「同じ条件下」で比較するのが最低条件。
GQM
- Wikipedia先生のご説明によると、「ソフトウェア工学における計測の枠組みおよびモデル化手法」
- 『Empirical Software Engineering』は読んでおけ。
- う〜ん、このモデルを適用して何が嬉しいのか、どうも理解できない・・・。
↑こんなダメ感想を箇条書きにしてもね。。。全然まとめになっていません。ちゃんと勉強します（20年以内に）。
指標の例
- 変数名の長さ：変数名のつけ方によって、コーディング担当者の開発言語経験の傾向を読み取る。平均的な長さが8文字以下の場合はCOBOL経験者かも・・・？とすると、Javaでのコーディングでおかしがちなミスとして・・・？
- MS Wordの編集時間：ドキュメントをWordで作っているのであれば、プロパティから、そのドキュメントの編集の所要時間がわかる。316ページあるのに編集時間が17分しかないということは・・・？
・・・まったくもって、このような指標を思いつく発想力には、どこから来るのでしょう。この他にも、クラス間の依存関係を可視化したり、step数とコメント数とifの数を軸にした3次元グラフで、アノマリーなクラスを見つけ出したりと、ただただ帽子を脱いではかぶり、脱いではかぶりしてしまいますね。
同じ人類として悔しいので、「人間的な」指標を自分ｄめお編み出そうと、社内の有志で知恵を絞っております。
同じ人類として悔しいので、「人間的な」指標を自分ｄめお編み出そうと、社内の有志で知恵を絞っております。
2009年11月03日
第3回ソフトウェアテストセミナー(1)
10月21日、秋葉原で開催された「第3回ソフトウェアセミナー」に出席してきたので、そのメモを。
基調講演は、IBMの細川宣啓氏。
一度学会発表を聞き、お話したことがあるが、「ソフトウェアの品質はこれからの分野で、自分がそれを作っていくんだ！」という気概に満ちた、エネルギッシュな方。10月23日に40歳になったそうですが、とてもそうは見えない若さに溢れており、刺激を受けます。情熱の余り、プレゼンテーションの最後が超駆け足になるのがチャームポイント！
一度学会発表を聞き、お話したことがあるが、「ソフトウェアの品質はこれからの分野で、自分がそれを作っていくんだ！」という気概に満ちた、エネルギッシュな方。10月23日に40歳になったそうですが、とてもそうは見えない若さに溢れており、刺激を受けます。情熱の余り、プレゼンテーションの最後が超駆け足になるのがチャームポイント！
講演のタイトルは、「現場主導の実践的なソフトウェア・メトリクス測定のもたらす効用・効果」。
アメリカにおいては、この測定にかけるコストは、ソフトウェア開発の費用の5〜9%だそうです。測定が利益に寄与する度合いなんて、具体的に目には見えづらいのに、です。測定とフィードバックは、日本のお家芸のように思っておりましたが、とんでもないですな。
アメリカにおいては、この測定にかけるコストは、ソフトウェア開発の費用の5〜9%だそうです。測定が利益に寄与する度合いなんて、具体的に目には見えづらいのに、です。測定とフィードバックは、日本のお家芸のように思っておりましたが、とんでもないですな。
「効果的なソフトウェアメトリクスの持つべき属性」として、以下の6つが挙げられています（ハンドアウトより引用）。
効果的なソフトウェアメトリクスの持つべき属性
(1)単純で計算しやすいこと
(2)経験や直感に照らし合わせても説得力があること
(3)一貫性があり客観的であること
(4)単位や次元が一貫した使い方をされていること
(5)プログラミング言語から独立していること
(6)品質を改善するための効果的なメカニズムがあること
(2)経験や直感に照らし合わせても説得力があること
(3)一貫性があり客観的であること
(4)単位や次元が一貫した使い方をされていること
(5)プログラミング言語から独立していること
(6)品質を改善するための効果的なメカニズムがあること
わたしが今一番気にしているのは、(1)です。
メトリクスを測定するためには、生データがなくてはならない。自分で集めることもできるけど、すでに誰かが記録しておいてくれたデータがあれば、楽。かといって、その「誰か」に、「こういう測定することになったから、今後これこれのデータをとっておいてくれやー、簡単だべ？」なんて頼んで、受け入れてくれる暇人はまずいません。
なので、もともと記録されているデータを使ったメトリクスを考えるのが、第一歩と思っています。
メトリクスを測定するためには、生データがなくてはならない。自分で集めることもできるけど、すでに誰かが記録しておいてくれたデータがあれば、楽。かといって、その「誰か」に、「こういう測定することになったから、今後これこれのデータをとっておいてくれやー、簡単だべ？」なんて頼んで、受け入れてくれる暇人はまずいません。
なので、もともと記録されているデータを使ったメトリクスを考えるのが、第一歩と思っています。
ところで、「基調講演」（keynote address）って結局、何なんですかね。。。いくら調べてもわからんのですが。
〜(2)に続く（はず）〜
2009年10月20日
Coverageに関する言葉の整理
カバレッジに関する言葉はややこしい。
そもそも「カバレッジ」なのか「カバレージ」なのかという論点からしてコンセンサスが得られず、会議はしばし踊る。ちなみにわたしは「カバレッジ」派閥。「レバレッジ」を「レバレージ」と言わないので！
そもそも「カバレッジ」なのか「カバレージ」なのかという論点からしてコンセンサスが得られず、会議はしばし踊る。ちなみにわたしは「カバレッジ」派閥。「レバレッジ」を「レバレージ」と言わないので！
カバレッジ（coverage）は、ホワイトボックステストの尺度の1つ。プログラムのソースコードが、どの程度の網羅率でテストされたかを示す。
その「網羅」のレベルにもいろいろあって、かつ名前もややこしい・・・。ので、簡単に整理してみました。
その「網羅」のレベルにもいろいろあって、かつ名前もややこしい・・・。ので、簡単に整理してみました。
まず、次のようなVBAのプログラムを考えてみる。テスト対象のプログラムが「カバレッジの確認」で、その動作を試すために、「呼び出す人」から「カバレッジの確認」に引数を与えて呼び出す、ということにしよう。下の例では、aに16を与えており、実行結果「16 は6の倍数ではない。」というメッセージ表示。
Sub 呼び出す人()
Call カバレッジの確認(16)
End Sub
Sub カバレッジの確認(a As Integer)
If a Mod 2 Or a Mod 3 Then '←判定
MsgBox a & " は6の倍数ではない。" '←命令
End If
End Sub
Call カバレッジの確認(16)
End Sub
Sub カバレッジの確認(a As Integer)
If a Mod 2 Or a Mod 3 Then '←判定
MsgBox a & " は6の倍数ではない。" '←命令
End If
End Sub
「カバレッジ確認」では、まず判定がある。この判定は「a Mod 2」（＝aを2で割った余り）か「a Mod 3」（＝aを3で割った余り）のどちらかが0（偽）にならない、つまり「2か3かどちらか（あるいは両方）で割り切れないか」という判定をしている。
割り切れない（＝条件を満たす）場合はメッセージを表示するが、割り切れる（＝条件を満たさない）場合は何もせずIF文から抜ける。
・・・この例こそややこしいな！
割り切れない（＝条件を満たす）場合はメッセージを表示するが、割り切れる（＝条件を満たさない）場合は何もせずIF文から抜ける。
・・・この例こそややこしいな！
さて、2つの条件のORをとっての判定であるから、それぞれの条件が真か偽かによって、4種類のパターンが考えられる。
真偽のパターン
(A) a mod 2：真、a mod 3：真 （たとえば a=5）
→ 判定：真、命令：実行される
(B) a mod 2：真、a mod 3：偽 （たとえば a=3）
→ 判定：真、命令：実行される
(C) a mod 2：偽、a mod 3：真 （たとえば a=2）
→ 判定：真、命令：実行される
(D) a mod 2：偽、a mod 3：偽 （たとえば a=6）
→ 判定：偽、命令：実行されず
→ 判定：真、命令：実行される
(B) a mod 2：真、a mod 3：偽 （たとえば a=3）
→ 判定：真、命令：実行される
(C) a mod 2：偽、a mod 3：真 （たとえば a=2）
→ 判定：真、命令：実行される
(D) a mod 2：偽、a mod 3：偽 （たとえば a=6）
→ 判定：偽、命令：実行されず
さてそれでは、網羅性のレベルを見てみよう。
(1)命令網羅(Statement Coverage、C0)
プログラム上のすべての命令を、1回以上実行するようなテスト。「真偽のパターン」でいうと、(A)か(B)か(C)のどれか1つを行えばいい。たとえば、a=5とすれば、命令は実行される。
プログラム上のすべての命令を、1回以上実行するようなテスト。「真偽のパターン」でいうと、(A)か(B)か(C)のどれか1つを行えばいい。たとえば、a=5とすれば、命令は実行される。
(2)分岐網羅(Branch Coverage、C1)、判定条件網羅(Decision Coverage）
プログラム上のすべての判定結果が、真と偽をそれぞれ1回以上カバーするテスト。「真偽のパターン」でいうと「判定」が、真の場合を1回、偽の場合を1回行えばよいので、(A)か(B)か(C)のどれか1つに加えて、(D)を行えばよい。判定の中のそれぞれの条件は考慮しない。
プログラム上のすべての判定結果が、真と偽をそれぞれ1回以上カバーするテスト。「真偽のパターン」でいうと「判定」が、真の場合を1回、偽の場合を1回行えばよいので、(A)か(B)か(C)のどれか1つに加えて、(D)を行えばよい。判定の中のそれぞれの条件は考慮しない。
(3)条件網羅(Condition Coverage)
プログラム上のすべての条件が、真と偽をそれぞれ1回以上カバーするテスト。分岐の真偽ではなく、分岐を形成する各条件が真/偽になる。
「真偽のパターン」でいうと、(B)と(C)をテストしておけば、条件「a mod 2」も条件「a mod 3」も、それぞれ1度ずつ真にも偽にもある。(A)と(D)でもよい。分岐網羅とは逆に、分岐の結果は考慮しない。
プログラム上のすべての条件が、真と偽をそれぞれ1回以上カバーするテスト。分岐の真偽ではなく、分岐を形成する各条件が真/偽になる。
「真偽のパターン」でいうと、(B)と(C)をテストしておけば、条件「a mod 2」も条件「a mod 3」も、それぞれ1度ずつ真にも偽にもある。(A)と(D)でもよい。分岐網羅とは逆に、分岐の結果は考慮しない。
(4)複数条件網羅（分岐条件網羅、C2）
プログラム上のすべての条件で、真と偽のすべての組み合わせをカバーするようなテスト。各条件のすべての真偽パターンなので、必然的に分岐の真偽もすべてカバーされる。
「真偽のパターン」でいうと、(A)(B)(C)(D)すべてを行う必要がある。
「真偽のパターン」でいうと、(A)(B)(C)(D)すべてを行う必要がある。
世の中の参考書には、例となるフローチャートやプログラムで、分岐の中の条件が1つしかなかったりする。すると、分岐網羅も条件網羅もも複数条件網羅も同じテストケースになってしまうため、わかりづらいのだと思う。
