Index: [Article Count Order] [Thread]

Date:  Mon, 29 Jul 2002 15:11:17 +0900 (JST)
From:  Ryuji Hattori<hattori@....jp>
Subject:  [XP-jp:03621] Re: ソフトウェア品質指標についての考察
To:  extremeprogramming-jp@....jp
Message-Id:  <200207290611.PAA23480@....jp>
In-Reply-To:  HAMAI Kyoichi's message of "Mon, 29 Jul 2002 11:07:02 +0900"	<iss.6a82.3d44a34e.56ee0.1@....com>
References:  <OFB8C33635.DE0BA5EC-ON49256BFF.002AEC75@....jp>	<iss.6a82.3d44a34e.56ee0.1@....com>
X-Mail-Count: 03621


どうも、はっとり@HZです。

#素朴な疑問です。

In message "[XP-jp:03619] Re: ソフトウェア品質指標についての考察"
    on 02/07/29, HAMAI Kyoichi <k-hamai@....com> writes:
>			:
>			: 
> 2002/07/23 19:19:38 +0900にhkikuchi@....jpさんが送られた
> メールに関する返信です。
> 
> > そこで「テストユニット+テストカバレッジ」の組み合わせで品質指標を算出する
> >方法を紹介したいと思います。
> > テストユニットは、ソフトウェア品質を向上させる効果的な手法だと思います。
> >さらにこのテストユニットがどれだけ頼りになるのか定量的に把握できれば、
> >品質はより堅固になると考えます。
> 
> 水を差すことになるかもしれませんが、カバレッジ率を重視しすぎない方が
> いいかもしれません。
> 
> マイヤーズの本にも書かれていますが、カバレッジ率100%でも見つからない
> 種類の欠陥があることがわかっています。あるべき処理が抜けていると
> いうようなケースは、カバレッジ率は役に立ちません。CodeRedやNimdaで
> 悪用されたバッファオーバーフローや、最近ウェブサイトで次々と
> 見つかっているクロスサイトスクリプティング脆弱性などはその例です。
> 
> このように仕様そのものに欠陥がある、仕様そのものが考慮不足である
> というような例は珍しくありません。
 
濱井さんのメールを読んでいて思ったのですが、実行させるテスト
が機能仕様のどの範囲までをカバーしているかを判定するための方
法論というのはあるのでしょうか。

#単体テストと結合テストの役割とかをごちゃ混ぜにしているかも
#しれませんが

今、私が調査している Clover* では、ant の JUnit タスクや Cactus
タスクなどと連動させて、build ファイルでコンパイルする個々の 
Java のソースファイルが JUnit を用いた単体テストケースから呼び
出されているかをメソッドレベルまで解析していき、Javadoc API 形
式に良く似た形でレポートを吐き出します。この場合はソースコード
に対してテストが行われているか否かの把握はわかりますが、ここで
のテストの内容・質については問うていないと思います。つまり行っ
たテストケースの集合が(単体テストで出来る範囲でということにな
るのでしょうが)システムに要求される機能仕様をどの程度カバーし
ているのかは保証されていないと思います。定性的にみるなら XP で
は Simple Design、Small Release によってその辺をカバーしている
のかなという気もしているのですが。

*Clover:http://www.thecortex.net/clover

個人的には、システム開発を UseCase ベースにやってしまう人なので
UseCase で機能仕様を上手にブレイクダウンして、個々の機能仕様の
要素が Java のクラスにマッピングされていれば、ソースコードカバ
レッジはソフトウェアの品質のよき指標になるのではと思っています。

 
> > 市販のカバレッジツールで算出されたテストユニットコードカバレッジ率(全コー
> >ドステップ数における実行ステップ数の割合)は、品質を知る一指標になりえると思
> >います。なぜなら、コードカバレッジが50%のモジュールより90%のモジュールの方
> >が絶対的な信頼があるからです。
> 
> ある点ばかり重視していると、それ以外のところが疎かになりがちです。
> カバレッジ率ばかり重視していると、それでは見つからない欠陥を見逃す
> リスクが高くなります。
> そもそも、品質は信頼性だけではありません。[XP-jp:02842]でも
> ふれられているように、デマルコが「ゆとりの法則」の「第16章 品質管理」
> において、品質向上プログラムが品質低下プログラムになっていると批判
> しています。やっていることが欠陥数の削減だけで、品質全体としてはむしろ
> 低下しているということです。
> 
> カバレッジ率が無意味だとは思いませんが、カバレッジ率が重要か否かは
> 一概には言えないでしょう。
 
ここはちょっと一般論として扱うのは大雑把なような気がします。具体的
にどのような状況(コンテキスト)でそのような「品質向上プログラムが
品質低下プログラムになっていく」のかという問題が発生するかを把握し
て、その歯止めを掛けていけばよいと思います。ただそれはテスト工程や
テストの方法論そのものに内在する問題ではなく、プロジェクトの進め方
についての問題だと思うのですが。あとこうした問題の改善については 
CMM が本来その対象とするところかなとも思います。(レベル3か4あ
たりかな)
 
-- 
------笑う門には (^o^) 福が来る --------
はっとり@HZ技研・大正区・大阪市
hattori@....jp (from 2001.07.16)