コンテンツにスキップ

A large-scale empirical study of just-in-time quality assurance

アブストラクト

  • 欠陥予測モデルは欠陥が発生しやすいファイルやパッケージを特定し、担当者が品質保証の取り組みを割り当てることができるよく知られた手法
  • しかし、重要なファイルやパッケージが特定された後も、開発者はレビューやテストの対象となる関数やコードの断片を見つけるのにかなりの時間を費やす必要がある
    • そのため、このアプローチは時間がかかりすぎて大規模なソフトウェアシステムに対しては非現実的
  • その代わりに、ファイルやパッケージではなく、欠陥が発生しやすいソフトウェアの変更を特定することに重点を置いた欠陥予測モデルを検討
  • 開発者はこれらのリスクのある変更を記憶が新しいうちにレビューしたりテストしたりできるため、この種類の品質保証活動を「Just-In-Time Quality Assurance」と呼んでいる
  • 変更リスクモデルを構築するために、追加された行数や開発者の経験など、ソフトウェア変更の特性に基づいて様々な要素を使用
  • 複数の分野にわたる6つのオープンソースプロジェクトと5つの商用プロジェクトを対象とした大規模な調査の結果、モデルは変更が欠陥につながるかどうかを平均68%の正解率と平均64%の再現率で予測できることが示された
  • さらに、変更のレビューに必要な労力を考慮すると、全ての変更を検査するのにかかる労力のわずか20%で欠陥を誘発する変更の35%を特定できることが分かった
  • この結果は、「Just-In-Time Quality Assurance」が最もリスクの高い変更に集中するための労力削減方法となり、さらには高品質なソフトウェアの開発コストを削減できる可能性を示唆

はじめに

  • ソフトウェア品質保証活動は、高品質なソフトウェアを開発する上で重要な役割を果たす
  • リリースされた製品に欠陥が存在すると、企業にとって大きな損失となり、企業の評判にも悪影響を及ぼす可能性がある
  • 同時に、企業は利益を挙げつ必要があるため、保守活動のコストを最小限に抑える必要がある
  • この課題に対処するため、ソフトウェア工学における多くの研究は、ソフトウェア品質保証活動の優先順位付けに焦点を当てている
  • 品質保証研究の大部分は、欠陥が発生しやすいモジュールを特定する欠陥予測モデルに焦点を当てている
  • このアプローチの欠点をまとめると、以下のようになる
    • 予測単位の粒度が大きい
    • 関連するQAの専門家が特定されていない
    • 予測が開発サイクルの遅い段階で行われる
  • そのため、研究者たちは、欠陥を誘発する変更を予測することに焦点を当てて、変更レベルで予測を行うことを提案している
  • 既存のアプローチとは対照的に、Just-In-Time Quality Assuranceは、開発者がコードを自分のプライベートワークスペースやチームのワークスペースにコミットするとすぐに実行できるため、より早い段階で継続的な品質管理を行うことを目指している
  • 変更レベルの予測を行う主な利点は、次の通り
    • 予測単位の粒度が小さい
    • 変更によって生じたバグを修正するための開発者への具体的な作業割り当てとして予測を表現できる
    • 予測が開発サイクルの早い段階で行われる
  • 複数の分野にわたる多様なオープンソースや商用のプロジェクトを対象に、変更レベル予測に関する実証研究を行った
  • この複数ドメイン、複数企業のデータセットは、6つのオープンソースプロジェクトと5つの商用プロジェクトで構成され、25万件以上の変更を含み、最も人気のある2つのプログラミング言語（C/C++とJava）を網羅している
  • リサーチクエスチョン
    • RQ1: 欠陥を誘発する変更をどの程度正確に予測できるか？
    • RQ2: 予測されるリスクに基づいて変更の優先順位を付けることによって、レビューの労力は軽減されるか？
    • RQ3: 欠陥を誘発する変更の主な特徴は何か？

背景と関連研究

長期的な品質保証

  • 以前の研究では、McCabeの循環的複雑度、CKメトリクス、コード行数などのメトリクスが使用されていた
  • 他の研究では、プロセスメトリクスを使用して欠陥が発生しやすい場所を予測
  • Graveらは過去の欠陥数や開発者数などの変更履歴に基づくプロセスメトリクスを使用して、欠陥予測モデルを構築
  • 彼らは、プロセスメトリクスがMcCabeの循環的複雑度などのメトリクスよりも優れた欠陥特徴であることを示した
  • NagappanとBallはコード変更の量を測定する相対的なコードチャーンメトリクスを使用して、ファイルレベルの欠陥密度を予測
  • Jiangらは、設計メトリクスとコードメトリクスを用いて障害が発生しやすいモジュールを予測する手法を比較し、コードベースのモデルが設計レベルのモデルよりも優れていることを明らかにした
  • MoserらはEclipseプロジェクトにおいて、プロセスメトリクスが、欠陥が発生しやすいファイルの予測において少なくともコードメトリクスと同等の性能を発揮できることを示した
  • Hassanは散発的な変更が、欠陥が発生しやすいファイrの優れた指標であることを示した
  • 私たちはこれらの先行研究から得られた知見を活用し、コード変更から抽出した14の異なる要因を用いて、変更が欠陥を誘発するかどうかを予測

短期的な品質保証

  • リスクの高いソフトウェア変更の予測に焦点を当てているものがある
  • MockusとWeissは、産業プロジェクトにおけるソフトウェア変更のリスクを予測
    • 彼らは、変更されたサブシステムの数、変更されたファイルの数、追加されたコードの行数、変更要求の数などの変更の尺度を使用
  • SliwerskiらはMozillaとEclipseのオープンソースプロジェクトにおける、欠陥を導入する変更について研究
    • 欠陥を導入する変更は一般に大規模なトランザクションの一部であり、欠陥を修正する変更や金曜日に行われた変更は欠陥を導入する可能性が高いことを発見
  • YinらはLinux、OpenSolaris、FreeBSD、商用オペレーティングシステムにおける誤った欠陥修正を特徴付ける調査を行った
    • その結果、同時に存在する欠陥を正しく修正するのが最も難しいこと、不正確な修正を担当する開発者は通常、変更されるコードに関する十分な知識を持っていないことが判明

変更の測定

  • 変更が将来の欠陥を引き起こすかどうかを予測するために、プロジェクトのソース管理リポジトリデータから得られた5つの側面に分類された14の要因を考慮
    • Diffusion（拡散）
      • 変更の拡散は、欠陥の確率を予測するうえで最も重要な要素の1つ
      • 広範囲に分散した変更は理解がより複雑になり、一般的には変更が必要な箇所を全て追跡する必要がある
      • メトリクス
        • NS（Number of modified Subsystems）: サブシステムの変更数が多いほど欠陥が発生しやすい
        • ND（Number of modified Directories）: ディレクトリの変更数が多いほど欠陥が発生しやすい
        • NF（Number of modified Files）: ファイルの変更数が多いほど欠陥が発生しやすい
        • Entropy（各ファイル間の変更されたコードの広がり）: エントロピーが大きいと各ファイル間の散発的な変更を記憶して追跡する必要があるため、エントロピーが高いほど欠陥が発生しやすい
    • Size（大きさ）
      • 変更が大きいほど、より多くのコードの変更や実装が必要となるため、欠陥が発生する可能性が高くなる
      • メトリクス
        • LA（Lines of code Added）: 追加されたコード行数が多いほど欠陥が発生しやすい
        • LD（Lines of code Deleted）: 削除されたコード行数が多いほど、欠陥が発生しやすい
        • LT（Lines of code in a file before the change）: ファイルが大きいほど欠陥が発生しやすい
    • Purpose（目的）
      • 欠陥を修正する変更は、新たな欠陥を導入する可能性が高くなる
      • 変更が欠陥を修正するかどうかを判断するために、変更ログ内で「bug」「fix」「defect」「patch」などのキーワードと欠陥識別番号を検索
      • メトリクス
        • FIX（変更が欠陥修正であるかどうか）: 欠陥修正は以前の実装で欠陥が混入したことを意味し、その箇所に欠陥が混入しやすいことを示唆している可能性がある
    • History（履歴）
      • 過去の研究では、ファイルに対する過去の変更回数と欠陥修正回数は、ファイルのバグの多さを示す良い指標であることが示されている
      • メトリクス
        • NDEV（the Number of DEVelopers that changed the modified files）: 開発者によって設計やコーディングスタイルが異なるため、NDEVが大きいほど欠陥が発生しやすい
        • AGE（直前の変更と現在の変更の間の平均時間間隔）: AGEが小さいほど欠陥が発生しやすい
        • NUC（the Number of Unique Changes to the modified files）: NUCが大きいと過去の変更を記憶して追跡する必要があるため、NUCが大きいほど欠陥が発生しやすい
    • Experience（経験）
      • プログラマーの経験が豊富なほど変更による欠陥発生確率が低下
      • メトリクス
        • EXP（developer EXPerience）: 経験が豊富な開発者ほど欠陥を導入しにくい
        • REXP（Recent developer EXPerience）: 直近数ヶ月でそのファイルを頻繁に変更している開発者は、最近の開発でより詳しくなっているため欠陥を導入しにくい
        • SEXP（サブシステムにおける開発者の経験）: 変更されたサブシステムに詳しい開発者は欠陥を導入しにくい

研究の準備

研究対象システム

  • 本研究では、結果の一般化可能性を高め、より具体的な知見を得るために、11の異なるプロジェクトを使用
    • 6つは大規模なよく知られているオープンソースプロジェクト
      • Bugzilla
      • Columba
      • Mozilla
      • Eclipse JDT
      • Eclipse Platform
      • PostgreSQL
    • 5つは大規模な商用プロジェクト
      • C-1（仮称）
      • C-2（仮称）
      • C-3（仮称）
      • C-4（仮称）
      • C-5（仮称）
    • これらのプロジェクトはC/C++またはJavaで記述されている

変更の抽出

  • CVSなどの非トランザクションベースのSCMシステムでは、開発者はコミットごとに1つのソースコードファイルしか提出できない
    • そのため、そのようなシステムに対しては、関連する1ファイルのコミットを1つのソフトウェア変更としてグループ化するアルゴリズムを用いた

欠陥を誘発する変更の特定と収集

  • 変更によって欠陥が発生するかどうかを知るためにSZZアルゴリズムを使用
    • このアルゴリズムはCVSなどの情報と課題管理システムの情報を組み合わせることで、各欠陥修正と元の欠陥を発生させたソースコードの変更を結び付ける
  • C-5では、不具合を誘発する変更と不具合を修正する変更が根本原因分析を通じて手動で特定された
  • ColumbaとPostgreSQLの場合は、変更ログで不具合識別子が参照されていないため、変更が不具合を誘発するかどうかを判断するために近似SZZ（ASZZ）を使用

データ準備

  • 共線性への対処
    • 多重共線性のリスクに対処するため、最も相関の高い因子を手動で除去し、その後、ステップワイズ法を使用
    • NFとND、REXPとEXPは高い相関関係にあるため、NDとREXPをモデルから除外
    • LAとLDも高い相関関係にあるため、LAとLDをLTで割って正規化
    • LTとNUCはNFと高い相関関係にあるため、NFで割って正規化
  • 歪みへの対処
    • ブール変数である「FIX」以外の各指標を対数変換
  • 不均衡への対処
    • ランダムアンダーサンプリングを使用

ケーススタディの結果

RQ1: 欠陥を誘発する変更をどの程度正確に予測できるか？

  • 10分割交差検証とロジスティック回帰を用いて予測
  • オープンソースプロジェクトにおいて平均適合率37%、平均再現率67%を達成
  • 商用プロジェクトにおいて平均適合率32%、平均再現率62%を達成

RQ2: 予測されるリスクに基づいて変更の優先順位を付けることによって、レビューの労力は軽減されるか？

  • 本研究では、変更された行の総数を用いて労力を計算
  • 総労力のうち、レビューのために使用できる労力は20%
  • 予測されたロジスティック確率に基づいて、20%の労力でレビューできる変更を労力の降順に並べる
  • ナイーブモデル（LRモデルと呼ぶ）を構築し、10分割交差検証で検証
  • LRモデルの予測性能
    • オープンソースプロジェクト: 平均正解率5%
    • 商用プロジェクト: 平均正解率8%
  • カスタマイズされた労力考慮型モデル（EALRモデルと呼ぶ）の予測性能
    • オープンソースプロジェクト: 平均正解率28%
    • 商用プロジェクト: 平均正解率43%

RQ3: 欠陥を誘発する変更の主な特徴は何か？

  • ロジスティック回帰モデルの回帰係数を分析して重要な特徴量を明らかにする
  • RQ1のモデルではオッズ比を用い、RQ2のEALRモデルでは線形回帰モデルの係数を検証
  • オープンソースプロジェクトでは、NF、LA/LT、LT/NF、FIXがリスクを増加させる最も重要な要因であることが分かった
  • 商用プロジェクトでは、NF、LA/LT、LT/NF、NDEV、AGEがリスクを増加させる最も重要な要因であることが分かった

議論

オープンソースシステムと商用システムの違いは何か？

  • 報告され、調査される欠陥の性質が異なる
    • 商用システムではリリースに基づいて欠陥が報告されるが、OSSではリリース以外のバージョンでも欠陥が報告される
    • その他にも、コードの所有権がOSSと商用システムで異なる

LRモデルのパフォーマンスが低いのはなぜか？

  • 予測粒度の違い
    • MendeとKoschkeは、ファイル単位の予測においてLRモデルの性能がランダムモデルよりも高くなると報告
    • 本研究では、変更単位の予測においてLRモデルの性能がランダムモデルよりも低くなった
  • 予測対象の違い
    • MendeとKoschkeは、ファイル内の欠陥の数を予測
    • 本研究では、特定の変更が欠陥を導入するかどうかを予測

JIT品質保証によりレビュー作業が増えるか？

  • JIT品質保証ではレビュー回数が増えるが、コードの変更直後にレビューできるため、レビュー作業が増えるとは限らない
  • また、より予防的なレビューにより、欠陥の影響を抑えることができる

欠陥を誘発しないものとして分類される、欠陥を誘発する変更（偽陰性）の特徴は何か？

  • 少数のファイルに影響する変更と欠陥に関連しない変更が、モデルでは偽陰性になる可能性が最も高いことが分かった

結論

  • 6つのオープンソースプロジェクトと5つの商用プロジェクトを対象に、欠陥発生リスクの高いソフトウェア変更をリアルタイムで特定する「ジャストインタイム品質保証」アプローチを評価
  • ジャストインタイム品質保証により、開発者は最もリスクの高い変更に最小限の労力で集中でき、高品質なソフトウェアを低コストで構築できる

引用情報

  • 著者: Yasutaka Kamei, Emad Shihab, Bram Adams, Ahmed E. Hassan, Audris Mockus, Anand Sinha
  • タイトル: A large-scale empirical study of just-in-time quality assurance
  • 雑誌 / 会議名: IEEE Transactions on Software Engineering
  • 巻号: vol. 39
  • ページ: pp. 757-773
  • 出版日: June 2013
  • DOI: https://doi.org/10.1109/TSE.2012.70