Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開

2012年1月6日

ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。

igrigorik/bugspots - GitHub

そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。

gitのレポジトリを分析

bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。

以下のようにインストールして実行(説明ページから引用)。

$> gem install bugspots
$> git bugspots /path/to/repo
$> git bugspots . # (in current git directory)

すると、次のようなレポートが返ってくるそうです(下記は説明ページの内容から抜粋)。

$> cd /your/git/repo
$> git bugspots .

  .. example output .. 

    Scanning /git/eventmachine repo
    Found 31 bugfix commits, with 23 hotspots:

    Fixes:
        - Revert "Write maximum of 16KB of data to an SSL connection ...
        - Do not close attached sockets (fixes #200)
        - Write maximum of 16KB of data to an SSL connection per tick ...
        - Merge branch 'master' into close_schedule_fix
        - Remove dependency on readbytes.rb for ruby 1.9 (fixes #167, #234)
        - Fix compilation on MSVC2008 (fixes #253)
        - EM::Deferrable#(callback|errback|timeout) now return self so ...
        - Make EventMachine::Connection#get_peername and #get_socknam...
        :

    Hotspots:
        0.9723 - ext/ed.cpp
        0.3311 - ext/ed.h
        0.3271 - ext/em.cpp
        0.3034 - lib/eventmachine.rb
        0.2433 - lib/em/protocols/postgres3.rb
        0.2403 - ext/project.h
        0.0431 - lib/em/deferrable.rb
        0.029 - ext/cmain.cpp
        0.0278 - ext/rubymain.cpp
        0.0277 - ext/eventmachine.h
        0.0241 - lib/em/resolver.rb
        0.0241 - tests/test_resolver.rb
        :

Hotspotsの項目に並んでいるモジュールの上から、数字が大きいほどバグが含まれている可能性が高いモジュールということになります。簡単に使えそうですね。

バグ修正の40%が新たなバグを混入という研究結果

ソフトウェア品質の研究をされている静岡大学の森崎修司助教は、「バグ修正のための変更の40%が新たなバグを混入するという研究結果 - Googleのバグ予測方法との共通点」というブログのエントリで、バグ修正のための変更のうち40%が新たなバグを混入しているという、電話交換機のサブシステムを構成するソフトウェアを対象にした研究結果を紹介しています。

この研究では、以下のような発見があったそうです。

  • バグ修正のための変更のうち40%が新たなバグを混入している(デグレード)
  • 500行以上の変更の約半分がバグ混入のきっかけとなっている。
  • 1行だけの変更のうちバグを混入してしまう変更は4%
  • バグ混入してしまう変更は、1行だけの追加の場合約2%、1行だけの変更の場合には約5%

こうした知見やツールを使うことで、人海戦術でテストをしがちだったバグ発見の効率化やソフトウェアの品質向上が、現場でも実現しやすくなるのではないでしょうか。

あわせて読みたい

ソフトウェアテスト・品質 プログラミング言語 システム開発




Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed