Using Orthogonal Defect Classification to characterize NoSQL database defects

アブストラクト¶

NoSQLデータベースはビッグデータシステムにおけるデータの保存と管理に使用されている
これらのデータベースにソフトウェアの欠陥が存在すると、提供されているNoSQLサービスに深刻な被害をもたらし、データの損失やサービスの利用不能につながる可能性がある
そのため、これらのデータベースに影響を与える欠陥の種類を理解し、対策を講じることが不可欠である
本研究では、ODCを使用して最も人気のある3つのNoSQLデータベースから合計4096件のソフトウェア欠陥を分類した
3つの異なるNoSQLシステム間で欠陥に高い類似性があることが分かった

はじめに¶

近年、NoSQLの利用が増加しており、現在ではリレーショナルデータベースと競合している
これらのシステムでは、データの損失やストレージサービスの利用不能はユーザーだけでなく、プロバイダーにも悪影響を及ぼす
このような事象は、多くの場合、ソフトウェアの欠陥の存在が原因である
ソフトウェアの欠陥は、ユーザーメッセージ内の単純なスペルや文法の間違いから、セキュリティ上の脆弱性まで多岐にわたる
最も人気のあるNoSQLの場合、バグの特定と修正は主に大規模なコミュニティによってサポートされており、コミュニティはソフトウェアの欠陥を見つけ、イシュートラッキングプラットフォームで報告し、修正を促す
ソフトウェアの欠陥の性質を理解することで、ソフトウェアの検証作業の焦点を絞り込んだり、特定のコンポーネントやコード領域に開発作業を集中させたりできる
本研究では、最も人気のあるNoSQLの1つである、MongoDB、Cassandra、HBaseの欠陥を分析
まず、これらのデータベースに影響する300の欠陥に対して、ODCを適用して1人の研究者をトレーニングする
次に、データベースのイシュートラッキングシステムから抽出した4096件の欠陥セットを分析し、研究者が8つのODC属性のうち6つを使用して手動で分類
次に、得られたODC分類欠陥データセットを4つの観点から分析
- 6つのODC属性に関する値の分布を分析
- 関連研究と同様に、属性のペアを生成して値の分布を分析
- 各データベースごとに最も影響を受ける上位3つのコンポーネントにおけるDefect Typeの分布を分析
- これまでの研究と比較して結果を分析
関連研究では、ドメインごとに欠陥の分布にばらつきがあることが分かっている
本研究の結果から、システムの全体的な性質が欠陥の分布に影響を与える可能性があることが示唆された
3つのNoSQLにおいて、ODC属性の分布には類似性があることも分かった
- 分布の大部分を単一の値が占めることもあった
- 属性のペアを交差させると、次の3つの点が観察された
  - テストはcapabilityよりもreliabilityの欠陥と関連付けられることが2倍以上多い
  - impact属性がreliabilityである場合、checkingの欠陥がより頻繁に発生する
  - checkingの欠陥はmissing qualifierと関連付けられる可能性が高い

背景と関連研究¶

背景¶

ソフトウェア欠陥分類手法は、ソフトウェアエンジニアリングの問題の根本原因を特定し、対策を講じて再発を防ぐことを目的とした欠陥因果分析プロセスで用いられる
人気のあるソフトウェア欠陥分類手法としては、ヒューレット・パッカードのDefect Origins, Types and Modes（DOTM）、IEEE-1044（IEEE Standard Classification for Software Anomalies 2010）、Orthogonal Defect Classificationがある

研究デザイン¶

目標
- NoSQLに影響を与える傾向のある欠陥の種類が、NoSQLプロジェクト間で一貫して同じであるかどうかを知る
- ODC属性間の相互関係を検出
- 各データベースの様々なコンポーネント内の欠陥の種類の変化を知る
目標達成のために5つの手順を実施
- NoSQLデータベースを選択
- 実際の欠陥の説明を使用して、分類プロセスを学習するように研究者をトレーニング
- データベースの公開イシュートラッキングプラットフォームからの欠陥の説明で構成されたデータセットを作成
- ODC分類に従って各ソフトウェア欠陥を手動で分類
- 分類された欠陥を手動で検証
NoSQLの選定
- 広く普及しているオープンソースのNoSQLを対象とした
- 2017年時点の人気ランキング
  - 1位: MongoDB
  - 2位: Redis
  - 3位: Cassandra
  - 4位: HBase
  - 5位: Neo4j
- このうち、MongoDB、Cassandra、HBaseはJiraを使用しており、残り2つはGitHubを使用していた
- GitHubにはODC分類に必要な情報が十分になかったため、本研究の分析対象から除外した
ODC属性の手動分類のためのトレーニング
- ODC分類を理解するには経験が必要
- 最初に300件の不具合の説明を使用して分類プロセスをトレーニング
欠陥データの選択と抽出
- 各NoSQLのJiraに存在する全ての欠陥を分類の候補とした
- クローズまたは解決済みとマークされた欠陥のみを分析対象とした
- 2017年5月1日までに登録された、クローズおよび解決済みのすべてのバグを特定した
- 手動でのODC分類作業の負担を減らすために、特定されたバグの約4分の1にあたる4,096件のバグを実際に分類した

結果¶

ODC属性間の値の分布¶

Activity属性
- Code Inspectionが最も一般的で、約半数のケースで出現し、欠陥発見において重要な役割を果たしている
- テスト関連のActivityは3種類あるが、いずれも欠陥の数がほぼ同じであった
Trigger属性
- Logic/Flowが最も多かった
Impact属性
- CapabilityとReliabilityが3つのデータベース全てで約4分の3を占めた
Target属性
- 報告された欠陥のほとんどがソースコードの問題に関連していた
Defect Type属性
- 3つのデータベースが非常に類似した分布を示し、Algorithm/Methodが最も多かった
- 2番目に多かったFunction/Class/Objectはシステム設計における大規模な変更を表している
Qualifier属性
- 欠陥の半分以上がIncorrectカテゴリーに属し、影響を受けたソースコードを直接変更することで修正された
- 2番目に多かったMissingカテゴリーは、本来存在すべきコードの追加による修正を表している

属性ペア間の値の分布¶

ImpactとTriggerのペア
- 検査関連トリガーはCapabilityと強い関連性を示した
- テスト関連トリガーはReliabilityと同時に発生することが多い
ImpactとDefect Typeのペア
- Reliablity: Checkingの欠陥が多い
- Capability: Function/Class/Objectの欠陥が多い
TriggerとDefect Typeのペア
- テスト関連トリガーでは、Checkingの欠陥が2番目に多く発生し、これらの問題がテスト活動によって適切に捕捉されることを示している
TriggerとQualifierのペア
- 全てのTriggerカテゴリーにおいてIncorrectが最も多く、これはほとんどの場合、バグがコードの修正によって解決されることを意味する
Defect TypeとQualifierのペア
- Checkingの欠陥のQualifierは「Missing」である確率が高く、プログラムのフロー制御に関する命令が不足していることを表している

内部ビューと修正時間¶

MongoDB
- レプリケーションコンポーネントでは、Timing/Serializationの欠陥の割合が大きく、コンポーネントがタイミングの問題に敏感であることを示している
- クエリコンポーネントでは、Interface/O-O Messagesの欠陥が比較的少ない
Cassandra
- ツールコンポーネントでは、Function/Class/Objectの欠陥が比較的少なく、Interface/O-O Messagesの欠陥が多い
- CQLコンポーネントでは、Function/Class/Objectの欠陥が全体のほぼ2倍発生しており、これは頻繁な設計変更を反映している
HBase
- クライアントコンポーネントでは、CheckingとInterface/O-O Messagesの欠陥が比較的少ない
- マスターコンポーネントでは、Checkingの欠陥が少なく、Function/Class/Objectの欠陥が多い
修正時間
- 最も修正時間が長い欠陥
  - Function/Class/Objectの欠陥
  - 設計変更が必要となり、重要な機能に影響するため
- 全体的な傾向として、修正時間はバグの特徴だけでなく、プロジェクトの開発体制にも依存する

実際のユースケース¶

ODC分析を実際の開発改善に応用する実験を実施
対象の選定
- MongoDB: バグレポートが豊富で分析しやすい
- Checkingの欠陥: 検出が容易で修正が比較的単純
- クエリコンポーネント: Checkingの欠陥の発生率が高い
実験範囲
- 17件のバグから根本原因がコンポーネント外部にある8件を除外し、9件を対象とした
値をランダムに生成し、さらに演算子とクエリ修飾子を組み合わせてクエリを自動生成
5600個のテストを作成
この自動テストにより、既知のバグ4個を自動で検出し、未知のバグ1個を発見

考察¶

単一属性の分析では、異なるシステムから抽出された欠陥が少数の属性値に集中する傾向が確認された
- 特にCapabilityとReliabilityが圧倒的に多かった
属性ペアの分析では、Reliabilityの欠陥におけるテスト活動は、Capabilityの欠陥におけるテスト活動と比べての2倍以上頻繁に発生することが判明

妥当性への脅威¶

バグレポートのサブセットを用いてODC分類を行ったため、本研究の結果はバグ全体を代表しない可能性がある
ODC分類における主観性を軽減するために、以下の対策を行った
- 実際のバグレポートを用いた分類トレーニングを実施した
- セルフレビューにより、分類の妥当性を検証した
- 2名の外部研究者が分類の妥当性の検証に協力した
本研究では3つのNoSQLを調査したため、本研究の結果を全てのNoSQLに一般化することはできない

結論¶

Defect Typeの分布は事前に想定できない
Reliabilityの欠陥におけるテスト活動は、Capabilityの欠陥におけるテスト活動と比べて2倍以上頻繁に行われる
Checkingの欠陥は、信頼性への影響が大きい場合により多く発生
システムコンポーネント間でDefect Typeに明確な差異があり、これはコンポーネントの性質と関連している
Function/Class/Objectの欠陥は一貫して修正時間が長くなる傾向がある

引用情報¶

著者: João Agnelo, Nuno Laranjeiro, Jorge Bernardino
タイトル: Using Orthogonal Defect Classification to characterize NoSQL database defects
雑誌 / 会議名: Journal of Systems and Software
巻号: vol. 159
ページ: p. 110451
出版日: January 2020
DOI: https://doi.org/10.1016/j.jss.2019.110451