ICST 2017R01トラックまとめ

2017/8/26

森 ⿓⼆

1

⾃⼰紹介• お仕事• テスト会社で現場サポート

• 関⼼事• ソフトウェア⽋陥

• SQiP研で論⽂2本• ODC• レビュー

• 書籍• システムテスト⾃動化標準ガイド(⼀部訳)

• 最近の活動• ⽇科技連ODC研究会メンバー(会員募集中！)• テスト⾃動化研究会(幽霊)

2

きっかけ• ICST 2017 TokyoのASTER招待枠に当選！• さてざっとセッションを⾒たものの、⾃分の関⼼事が少ない...• Faultって書いてあるからとりあえずこれにしてみよう！

3

数式だらけやん！

前提• Fault Localizationとは⽋陥の⾃動検出技術• このまとめでは仮に「⾃動検出」と訳出しておきます• テスト結果を使って⽋陥を特定する技術

• この技術の⽬的は「テストオラクルなしで⽋陥を検出したい」• テストオラクルからの期待値導出は⼤変• この意味では静的解析ツールと似ているが、プログラムの構造解析⾃

体は⾏わないところが違う• 今のところプログラマの⽀援が⽬的だが、⾃動検出→⾃動修正へ発展する技術の基礎研究

4

⽬次1. Localizing Faults in SQL Predicates

• Yun Guo, Amihai Motro and Nan Li• SQL⽂の述語に対する⾃動検出

2. Prevalence of Single-Fault Fixes and its Impact on Fault Localization• Alexandre Perez, Rui Abreu and Marcelo d'Amorim• 単⼀⽋陥修正の発⽣率と、それが⾃動検出に及ぼす影響について

3. FIFA: A Kernel-Level Fault Injection Framework for ARM-based Embedded Linux System• Eunjin Jeong, Namgoo Lee, Jinhan Kim, Duseok Kang and Soonhoi Ha.• ARMベースの組み込みLinuxシステム向けカーネルレベルの⽋陥埋め込みフ

レームワーク

5

1. Localizing Faults in SQL PredicatesSQL⽂の述語に対する⾃動検出Yun Guo, Amihai Motro, Nan Li

6

⽬次• Abstract1. Introduction2. A Motivating Example3. The Fault Localization Strategy4. Implementation and Experimentation5. Related Work6. Conclusion• 【感想】

7

Abstract• SQLに対するこれまでの⾃動検出の⽅法では、壊れたSQL⽂を特定できても、SQL内部の詳細な位置まで特定できていなかった。• ⾃動検出の新しい⽅法を考えた• ⾏ベースの動的スライシング• デルタデバッギング

• 新しい⽅法はALTARというツールに実装し、フリーで使えるDB２つに適⽤した• その結果ALTARは従来よりも多種類の⽋陥を⾒つけ、⾒つけた⽋陥の内容は従来よりも詳細で⽋陥特定に役⽴つことがわかった

8

1. Introduction• Fault LocalizationをSQLの分野に適⽤した過去研究は、いずれも問題のあるWHERE句の特定⽌まり• 本研究の⽬的：WHERE句の中の誤った述語の特定• 述語の例：=, <>, EXISTS…

• 2つのステップ1. ⾏ベースの動的スライシングで述語を特定2. デルタデバッギングで偽陽性の述語を排除

• この論⽂の貢献は、⽐較的⻑くて複雑なSQL⽂の誤りを指摘すること

9

2. A Motivating Example• ⾃動検出の世界で有名なTrantulaの公式を使ってみたが、SQL構⽂の誤り検出には有効でないことがわかった

10

3. The Fault Localization Strategy(1/4)# ⾏ 意味 ⽇本語意味G1 選ばれるべき⾏が選ばれている true positive 真G2 選ばれるべきでない⾏が選ばれて

いないtrue negative 偽

G3 選ばれるべきでない⾏が選ばれている

false positive うっかりもの(余計)

G4 選ばれるべき⾏が選ばれていない false negative ボンヤリもの(不⾜)

# 状態 例F1 定数誤り 定数の綴り間違い、浮動⼩数点の置き間違いF2 符号誤り ＞を≧と間違えたF3 列誤り 別の列を使うべきだったF4 句漏れ その句は追加すべきF5 不要な句 その句は削除すべき

11

3. The Fault Localization Strategy(2/4)

# Clause 接続詞 Conjuctive Predicate(連⾔形)

C1 Year > 2007AND CP1

C2 Price > 100C3 Zipcode = 10008

AND CP2C4 Discount = 0

正 SELECT Orderid FROM OrderWHERE (Year > 2009 AND Price > 100) or (Zipcode = 10007 AND Discount = 0)

偽 SELECT Orderid FROM OrderWHERE (Year > 2007 AND Price > 100) or (Zipcode = 10008AND Discount = 0)

今、以下の誤ったSQLから誤っているClauseを検出したいとする。

SQLをClause単位に分解する(DNF:選⾔標準形)

12

3. The Fault Localization Strategy(3/4)• 以下のデータを誤ったSQLに与える

Orderid Year Price Discount Zipcode 判定1 2008 110 0 22102 G32 2014 120 10 22102 G13 2013 110 5 22017 G14 2006 80 5 22017 G25 2014 90 0 10017 G4

# Clause 1⾏⽬の怪しさ 5⾏⽬の怪しさ 怪しさ合計C1 Year > 2007 1 0 1C2 Price > 100 1 1 2C3 Zipcode = 10008 0 1 1C4 Discount = 0 0 0 0

G1,G2はバグがないG3とG4を対象にする

１⾏⽬はG3(余計)なので、過剰にTrueと判定されていると考えると、Trueのものが怪しいと考える同様に5⾏⽬はG4(不⾜)なので、過剰にFalseと判定されていると考えると、Falseのものが怪しい

13

3. The Fault Localization Strategy(4/4)

• 正しい候補の排除(デルタデバッギング)• G3(余計)と判定された⾏から正しいものを排除する• G4(不⾜)と判定された⾏から正しいものを排除する

詳細は論⽂参照！14

4. Implementation and Experimentation

• ALTARというツールに実装• Ruby• Githubに公開

• github.com/carolfly86/altar • 現在はPostgreSQLに対応

15

5. Related Work• ⾃動検出の⽅法は現在のところ8つのカテゴリーが存在する• スライスベース• スペクトラムベース• 統計ベース• プログラム状態ベース• 機械学習ベース• データマイニングベース• モデルベース• その他

16

6. Conclusion• SQL⽂の⾃動検出に新しい⽅法を提案した• ⾏ベースの動的スライシング• デルタデバッギング

• ツールALTARに実装した• ３つのカテゴリの⽋陥を⾒つけることが可能• 列の間違い・列の漏れ・間違いと漏れの混合

• 従来の⽅法に⽐べて有効性が証明された• 現在はWHERE句だけだが、HAVINGやUPDATEにも対応したい

17

【感想】• 新しい予測式を考えただけでなく、ちゃんとツールに実装して実証している点がよい• 過去の研究をあまり知らなくても読める点もよい• ただアルゴリズムは細かすぎて読む気がしなかった• SQLバグでお困りのSI関係者は試してみるといいと思う• O/Rマッパー(Hibernate, MyBatis等)が吐く⼤量のログ解析など使え

るところはあるはず

18

2. Prevalence of Single-Fault Fixes and its Impact on Fault Localization単⼀⽋陥修正の発⽣率と、それが⾃動検出に及ぼす影響Alexandre Perez, Rui Abreu and Marcelo d'Amorim

19

⽬次• Abstract1. Introduction2. Background & Related Work3. Research Questions4. Methodology For Fault Classification5. Empirical Study6. Discussion7. Conclusion• 【感想】

20

Abstract• スペクトラムベースの⾃動検出では、ソフトウェアコンポーネント

をその疑わしさ順に並べるために、予測式(predictor)がいくつか提案されてきた• その多くがシステムに⽋陥は⼀つという前提

• その後の⾃動検出の研究は、より複雑で複合原因の⽅向へ• 我々は「開発者は⼀度に⼀つの⽋陥を直す」という仮説を設定• リポジトリを検索して修正の痕跡を探し、修正したバグ数を記録し、

「単⼀⽋陥の発⽣率」を評価した• 279のオープンソースプロジェクトに適⽤し、82％以上が⼀度に1

つの⽋陥を修正しているにすぎないことを⽰した• その結果、複雑な予測式は考える必要がないことがわかった

21

1. Introduction• ⽋陥予測の精度を上げようと、過去の研究者は様々な予測式を提案

してきた• その中でもAbreu等のO(オー)予測式が単⼀⽋陥の場合に⽐較的良い

ことがわかった• 我々は、プログラマは⼀度に⼀つの⽋陥しか対応していないのでは

ないかという仮説を検証してみようと思った• 本論⽂の貢献

• リポジトリからバグを⾒つける⽅法• オープンソースのJavaプロジェクトのうち82.5%が単⼀⽋陥であるという実

証• スペクトラムベースの⽋陥予測⼦に対する単⼀⽋陥の場合のパフォーマンス

評価• スペクトラムベースの⽋陥予測⼦に対する複数⽋陥の場合のパフォーマンス

評価

22

2. Background & Related Work(1/4)• スペクトラムの定義

記号 意味c コンポーネント(M個)t トランザクション(N個)

テストケースとほぼ同義e 判定結果(1:false, 0:true)Aij コンポーネントcjに対してテストケー

スtiを⾏わせたときの振る舞い

23

t1はc1, c2, c6を通り結果はpasst2はc2, c3, c6, c7を通り結果はfail

2. Background & Related Work(2/4)• component frequency aggregator

• j番⽬のコンポーネントが• p:活性(1)、⾮活性(0)• q:テストが失敗(1)か成功(0)か• 例：n11(j)→活性コンポーネントの失

敗数• n10(j)→活性コンポーネントの成功数

• 代表的な予測式は表1のようになる

24

2. Background & Related Work(3/4)予測式 特徴 提唱者

D* コンポーネントｊのフォールトの起こりやすさは(1)jをカバーする失敗テストに⽐例(2)jをカバーする成功テストに反⽐例(3)jをカバーしない失敗テストに反⽐例＊はウエイトで通常1以上（この論⽂では2を採⽤）

Wong等

O システムには1つしか⽋陥がないと仮定する最適メトリック。本当に⼀つしかない場合には最適であるが、必ずしも最速のアルゴリズムとは⾔えない。

Naish等

OP O予測式の仮定を緩くしたもの Naish等Ochiai カバレッジマトリックスAijとエラーベクトルeのコサイン類似度をとっ

たものAbreu等

Tarantula 失敗テストに使われるコンポーネントが最も根本原因に近くて、成功テストに使われるコンポーネントは最も根本原因から遠いという仮説に基づく式

Jones等

25

2. Background & Related Work(4/4)• 「修正」の定義• Fix:システムから⼀組の⽋陥を除去するためのソースコードの何らか

の変更• Single-Fault Fix:システムから1つの⽋陥を除去すること• Multiple-Fault Fix:システムから1つより多くの⽋陥を除去すること

• ヒッティングセット：変更がテストに及ぼす影響の数• この論⽂では「⽋陥は⼀度に⼀つ」という仮定を置く• システムに1つしか⽋陥がないという意味ではないので注意• 現場の開発者は出たバグをすぐ直すのでこの仮定を置いても無理はな

いと考えた

26

3. Research Questions• RQ1:オープンソースプロジェクトにおいて単⼀⽋陥はどれくらいあるのか？• RQ2:最先端の⽋陥予測式によって単⼀⽋陥を検出するのに必要な労⼒はどれほどか？• RQ3:複数⽋陥を考慮した場合にどれほどパフォーマンスが落ちるか？

27

4. Methodology For Fault Classification

• 修正コミットのマイニング• masterブランチから逆に辿る• 修正前後でテストを流して通れば修正候補にラベル• テストが失敗すればカーディナリティ分けに進む

• 修正コミットのカーディナリティ分け• スペクトラム収集• 同義グループの除去

• 振る舞いが同じものは区別できないので融合させる（同値クラスと同様）

• 未変更コードの除去• ⽋陥は修正セットの中に含まれるはず

• ヒッティングセットと分類

Single-Faultc3を直せば通る

Multi-Fault通すにはc3とc5の修正が必要

28

5. Empirical Study(1/4)• Github上の6000プロジェクトから以下を選択

• 1288のJavaプロジェクト（ツールの都合）• Mavenでないプロジェクトを排除(701に減少)• テストのないプロジェクトを排除(279に減少)

• 平均のテスト数＝596• ツールはここ：https://github.com/aperez/single-fault-prevalence• 労⼒のメトリクス

• 最初に⾒つかった時の労⼒(first-fault),平均(average-fault),最後に⾒つかった時の労⼒の3種類を計測

Sc:コンポーネントCの予測式スコア(0〜1)0:⽋陥がすぐ⾒つかる状態1:全ソースを検査しないと⽋陥が⾒つからない状態

29

5. Empirical Study(2/4)• RQ1:オープンソースプロジェクトにおい

て単⼀⽋陥はどれくらいあるのか？• Answer

• 修正数1135/1375=82.5%が単⼀⽋陥• 中央値で91.1%

• O(オー)予測式が最も効率が良い

30

5. Empirical Study(3/4)• RQ2:最先端の⽋陥予測式によって単⼀⽋陥を検出するのに必要な労⼒はど

れほどか？• Answer

• 検出⼒が安定していたのはO(オー)とOP

• 複数⽋陥のシナリオではO(オー)予測式は以下の3つのシナリオとも効率が悪かったFirst-fault Average-fault worst-fault

31

5. Empirical Study(4/4)• RQ3:複数⽋陥を考慮した場合にどれほどパフォーマンスが落ちるか？• Answer• どの予測式でも、first-fault測定法であれば単⼀⽋陥の場合と同等• O(オー)以外の予測式では複数⽋陥でもほぼ同等

32

6. Discussion• 実証的な意味合い• 複数⽋陥で不安定なO(オー)よりもOPの⽅がよい• CIなどのように、検知してすぐ修正する環境では開発のムダが減る• 複数⽋陥の検知はさらなる研究が必要• 今後⾃動修正に研究の⽅向が向かってもOPの⽅がよい

• 有効性への脅威• 似たようなプロジェクトの選択バイアス• 単⼀⽋陥と複数⽋陥の定義• インターフェイスの変更は扱わないとしたこと• 複数のコミットをまとめるような場合の⽋陥の数え⽅• 使⽤したツールの複雑さ

33

7. Conclusion• オープンソースのJavaプロジェクトについて、⼀つの⽋陥はそれぞ

れ独⽴に検出されるという仮説を⽴て、単⼀⽋陥の有病率を調査した• 我々はソースコードリポジトリに対してデータを収集する⽅法を提

案した• 70プロジェクトの1375個の修正に対し、82.5%が単⼀⽋陥である

ことがわかった• O(オー)とOP予測式では似たような結果を得るが、複数⽋陥でも安

定しているOP予測式が我々のお勧めである• 今後はスペクトラムベース以外の予測式にも研究の⽅向を向けてい

きたい

34

【感想】• 数式が多く、ハードタイプの論⽂• 結論ありきの実験をやっているように⾒えるため、結果に意外性はない• それでもこの分野の初⼼者として、この論⽂のリサーチ論⽂としての価値を評価したい• そもそもスペクトラムベースの⾃動検出について、わかりやすく解説

している論⽂が少ない• 数式を乗り越えれば書いてあること⾃体は理解しやすい• 参照⽂献も多く、⾃動検出を極めたい⼈はここを起点に読み始めるこ

とをお勧めする

35

3. FIFA: A Kernel-Level Fault Injection Framework for ARM-based Embedded Linux SystemARMベースの組み込みLinuxシステム向けカーネルレベルの⽋陥埋め込みフレームワークEunjin Jeong, Namgoo Lee, Jinhan Kim, Duseok Kang and SoonhoiHa

36

⽬次• Abstract1. Introduction2. Background3. Related Work4. Fault Injection Framework5. Proposed Fault Injection Techniques6. Implementation7. Experiments8. Conclusions

37

Abstract• ハードウェア数の増加とともにハードウェア関係の故障の可能性が

増⼤するにつれ、ハード故障のエミュレーションが重要に• 我々はカーネルレベルで意図的に⽋陥を混⼊するフレームワーク

(FIFA)を提案する• 従来のランダムな統計的⼿法よりも、⽋陥検出の効率を上げること

を狙っている• FIFAの特徴は2つ

• Kernel GNUデバッガ• ハードウェアブレークポイント

• ビットを反転させるだけの従来⼿法と⽐較して、時間の遅延やデバイスエラーをサポートしている• 本⼿法をODROI-XU4システムに適⽤し、有効性が証明された

38

1.Introduction• Linuxベースの組み込みシステムの爆発的な普及• その組み込みシステムに繫がるデバイスもうなぎ登り• Linuxベースの組み込みシステムに対して、ハードウェア障害の影響を調べるために⽋陥を注⼊したい• Linuxの動作レベルにはカーネルレベルとアプリレベルがある• 元々LinuxにはFICI(Fault Injection Capabilities Infrastruture)という仕組みが⽤意されているが使いにくい• 本研究の元になった2つの⽅法• KGDB(Kernel GNU Debugger)• ハードウェアブレークポイント

39

1.Introduction• 本研究で提案するFIFA(Fault Injection Framework for ARM-based system)• 現在ODROID-XU4上に実装

• 本研究の貢献1. ARM Linux上で動く⽋陥注⼊フレームワークであること2. 2つの注⼊法を持っていること

• KGDB:遅いがカーネル修正なしで⽋陥注⼊できる• ハードウェアブレークポイント:制限はあるが⾼速に注⼊できる

3. ビット反転以外の⽋陥タイプをサポート• タイミングの遅れ、デバイスの障害など

40

ODROID-XU4

2. Background• 過去研究SWIFI(Software Implemented Fault Injection)• データエラー• インターフェイスエラー• コード変更

• Kernel GNU Debugger• ホストPCとシリアルポートで通信

• ARM Hardware Breakpoint• ARM固有の機能• アセンブラ上でブレークポイントのセット→有効をする必要がある

41

FIFAの扱う範囲

3. Related Work

42

4. Fault Injection Framework• 概要• KGDB：コンパイル不要だがエ

ラーの種類が限られる• HB：コンパイル必要だがエラー

種類が多い• アーキテクチャ

43

5. Proposed Fault Injection Techniques

• ⽋陥注⼊属性1. 注⼊ポイント：場所と対象2. ⽋陥種類：bit-flipやその他3. ⽋陥の頻度：⼀時的/繰り返し/常時

• KGDBによる注⼊• 通信速度の問題で⽋陥頻度に制限あり

• ハードウェアブレークポイントによる注⼊• 挿⼊箇所は関数の始まりに限定される

ものの、⽋陥頻度はほぼ制限なし

44

6. Implementation• ⽋陥注⼊設定• C/C++でおなじみのlibconfig形式

• 注⼊実験の流れ• エラー検知のメカニズム• 3種類のエラーに対応

• カーネルパニック• ハング• カーネルエラーログ

45

7. Experiments• 実験の準備• ホストマシン：Ubuntu• ターゲットマシン：ODROID-XU4 + USB-UARTコネクタ• カーネルモジュールの組み込み(ハードウェアブレークポイント⽤)

• パフォーマンス⽐較

46

8. Conclusions• FIFAという⽋陥注⼊フレームワークを開発した• KGDBとハードウェアブレークポイントの2つの注⼊⽅法がある• KGDB：コンパイルなしで実⾏できるが、シリアル回線経由なのでと

ても遅い。ちょっと試すのに向いている• ハードウェアブレークポイント：⾼速。繰り返しや常に起こる事象に

向いている• ODROID-XU4というハードウェア上で実験した• eMMC(SSDの軽量版)コントローラで動作を確認

• 他のハードウェアやエラーのタイプのサポートは今後の課題

47

【感想】• Fault Localizationの論⽂ではないような...• 同じ内容の繰り返しで疲れる• エンプラ・Web系でよく⾏われるモックエミュレートを、組み込みのLinuxカーネルまわりでやれるというあたりがこの論⽂の価値• 実⽤性は3つの中で⼀番⾼いと思う• 特に再現性にお困りのAndroidの現場

• FIFA⾃体は公開されていない点が残念

48

【全体感想】• 知らない分野だったのでとても勉強になりました！• アイディアが浮かんだらとにかくツールとして実装(公開)して、実証するという姿勢は⾒習った⽅がいい• ただ個⼈的にはもう少し⽋陥の性質を⾒た⽅がいいように感じる• 定性分析結果の⽋陥モデル→数値予測モデルとか

• ⼒業で推し進めるなら、起こりやすい箇所を機械学習で予測する⽅が早い気もする• ソフトがソフトを修正する時代の幕開け？

49

ご清聴ありがとうございました！

50