6月12日に開催されたSE勉強会にて発表したスライドです。

1. SE勉強会
国立情報学研究所
2014年6月12日
国立情報学研究所 助教 坂本 一憲
東京大学 修士２年生 鈴木 貴之

2. 自己紹介
• 坂本 一憲
– 興味：テスト、プログラム解析、プログラミング言語
– 参加セッション
• 1日目) Testing 1, Social Aspects of Software Engineering,
Prediction
• 2日目) Testing 2, Search & APIs, Build and Package Management
• 鈴木 貴之
– 興味：リポジトリマイニング
– 参加セッション
• 1日目) Perspectives on Software Engineering, Repair, Prediction
• 2日目) Panel2: Analyzing Software Data, Search and APIs, Mining
• 3日目) Modeling and Interfaces, Refactoring and Reverse
Engineering

3. 1日目) Testing 1, Social Aspects of Software Engineering, Prediction
2日目) Testing 2, Search & APIs, Build and Package Management
2014/6/13 3

4. Code Coverage for Suite
Evaluation by Developers
• Rahul Gopinath et al. (Oregon State University, USA )
• カバレッジ指標を比較する研究は存在するが、対象プロジェクトが少ない
• Statement, Block, Branch, Path(AIMP) CoverageとMutation analysis
• Coverage：Cobertura, Emma, CodeCover, Jmockit; Mutation：PIT
• プロジェクトに存在する・Randoopで生成したテストスイートで2回実験
• 各指標で250件程度が測定に成功、CoverageとMutationの相関性を計算
• Statementカバレッジ(!)が最も高い相関性(相関係数R2, Kendall correlations)
• 所感1：PITは2013年にリリースされたOSSで、学術会で有効性が未検証
• 所感2：Test Oracleについて評価がされていないため、妥当性について疑問*
*) Staats et al. Programs, tests, and oracles: the foundations of testing revisited, ICSE, pp. 391-400, 2011.
79ページのTable 7
Preprintはこちら

5. Coverage Is Not Strongly Correlated with Test
Suite Effectiveness (Distinguished Paper)
• Laura Inozemtseva et al.
(University of Waterloo, Canada)
• 5種類のOSSを対象（Apache
POI, Closure, HSQLDB,
JFreeChart, Joda Time）
• Randoopで1000テストスイー
ト作成: 3,10,30,100 メソッド
• CodeCoverでStatement,
Decision, Modified Condition
Coverageを測定
• PITでミューテーション解析を
実施（欠陥の検出率を測定）
• どのカバレッジ指標も欠陥数と
弱い相関性しかなかった！
• 所感：前の論文と同様にテスト
オラクルの評価は一切なし！
441ページのFigure 3
Preprintはこちら

6. Time Pressure: A Controlled Experiment of Test-
Case Development and Requirements Review
概要: Time
Pressureによっ
て、簡単なタス
ク（要求仕様レ
ビューとテスト
作成）の品質を
下げずにコスト
削減、その他デ
メリットもない
88ページのFigure 1
90ページのFigure 3
Preprintはこちら

7. Software Engineering at the Speed of Light:
How Developers Stay Current using Twitter
• Grounded Theory-based studyを実施：GitHubで活動する開発者271名に
Exploratory Survey、27名にインタビュー、1,207名にValidation Surveyを実施
• RQ 1: どうやってTwitterから人・流行・プラクティスの情報を得るか？(*)
77%/9%：指導者的な人をフォロー、62%/17%：プロジェクトや技術発展に有用
– a) other developers, b) projects, c) news curators, d) thought leaders
• RQ 2: どのようにTwitterはソフトウェア開発の知識を拡張するか？ 62%/14%：
習得すべき技術を認知できる、32%/38%：より良い開発者になれる
– 専門家をフォローして質問、キャリアに関する定常的な調査や偶然の学習
• RQ 3: どのようにTwitterは開発者間の関係を育むか？ 44%/28%：コミュニティ
を育成できる、69%/14%：面白い開発者を発見できる、28%/42%：求職できる
– 自身の公のイメージ・評判を管理、面白い開発者を発見、良好な関係の形成
• RQ 4: Twitterでどんな課題に直面するか？どうやって対処するか？ 72%/11%：
フォローする人を注意深く選ぶ、 65%/17%試しにフォロー・アンフォローする
– 継続的にネットワークを維持・管理、情報量が多すぎるのでフィルタリングなどで対処
• RQ 5: Twitterを利用しない開発者の理由は？
– Too much noisy、140文字制限が嫌い（誤解を生みやすい）、他と比べ会話しにくい
*) xx%/yy%: Validation Surveyでxx%の人がagreeでyy%の人がdisagree
Preprintはこちら

8. Micro Execution
• Patrice Godefroid (Microsoft Research)
• Micro execution（任意のコード断片をテストドライバ及び入力データな
しで実行する能力）という概念を提案
• x86のバイナリファイルに対応したプロトタイプVMを開発
• 入力データ生成方法
– Zero mode、Random mode、File mode、Process-dump mode、SAGE
mode（過去に開発したSymbolic Executionツールでできるだけ多くのパス
を通るように生成）
• 利用例
– Automated API fuzzing：DLLが提供する関数を叩いてクラッシュを探す
– Packet parser isolation and fuzzing：従来はシステムテストで頑張っていた
が、パケットのパーサーやパース結果の処理部分を個別にテスト
– Targeted fuzzing：Excelなどにある複雑なパーサを結合テストするのは大変
なので、サブパーサを個別にテスト
– Unit verification：同様に複雑なコンポーネントを個別にテスト
– Malware detection：実際に動かして怪しい挙動を検出（パケット送信等）
Preprintはこちら

9. Unit Test Virtualization with VMVM
(Distinguished Paper)
• Jonathan Bell et al. (Columbia University)
• Junitはテストケース毎にJVM全体を初期化
• 提案では副作用のあったクラスのみ初期化
– なお、TestNGやNunitはそもそも初期化しない
• テストケースの実行時間を大幅に削減
• AntとMavenで利用可能なツールを公開！
551ページのFigure 1
557ページのTable 4
Preprintはこちら

10. CodeHint: Dynamic and Interactive Synthesis of
Code Snippets (Awarded as Prof. R. Narasimhan Lecture)
• Joel Galenson et al.
(University of California at Berkeley, USA)
• 従来手法では静的解析（型情報）でコード補完
• 提案手法では動的解析でコード補完（コード生成）
1. デバッガとブレークポイントで実際に実行&停止
2. 停止したコンテキストで利用可能な変数を列挙
3. メソッド呼び出しや演算子で条件を満たす式を作成
– 条件はホスト言語（Java）で記述できる任意の内容
• o’ instanceof JMenuBar や o’.toString().contains(“Alice”) など
• 動画: http://www.cs.berkeley.edu/~joel/codehint/
661ページのFigure 3661ページのFigure 2
Preprintはこちら

11. その他ざっくりと紹介
• Two‘s Company, Three’s a Crowd: A Case Study of
Crowdsourcing Software Development (Preprint, リンク切れ?)
– TechPlatform Inc (TopCoderを利用) でクラウドソーシングし
たら想像以上に大変だった！（お金はかかるし品質は悪い）
• Comparing Static Bug Finders and Statistical Prediction
(Preprint)
– 欠陥検出の静的解析手法と欠陥予測手法の比較を実現
– 欠陥予測手法で欠陥のありそうなモジュールから順に、
静的解析手法で警告が出た箇所を確認すると効果的
• How Do API Documentation and Static Typing Affect
API Usability? (Preprint)
– ドキュメント有/無と静的/動的型付け言語がAPI使用性にどのよ
うな影響を与えるか実験で検証(従来はドキュメントなしのみ)
– いずれにせよ静的型付けの方が動的型付け言語より良い
– ドキュメントがあったほうが静的型付け言語がさらに有利

12. 1日目) Perspectives on Software Engineering, Repair, Prediction
2日目) Panel2: Analyzing Software Data, Search and APIs, Mining
3日目) Modeling and Interfaces, Refactoring and Reverse Engineering
2014/6/13 12

13. A Study and Toolkit for Asynchronous
Programming in C# (Distinguished Paper)
C#において並行処理を実現する
async/awaitキーワードの誤用を調査
誤用パターン 割合
打ちっぱなし 19%
不必要なasync 14%
時間がかかる可能性のある処理 5%
不必要なコンテキストキャプチャ 74%
☞これらの誤用パターンを修正するツールを開発
Preprintはこちら

14. Effects of Using Examples on Structural Model
Comprehension: A Controlled Experiment
ドメイン知識の伝達において具体例が有効であることを示した
いくつかの要求の下でポイン
トカードのモデルのオブジェ
クトダイアグラムを作成
Control
クラスダイアグラムの概要のみ
EDM
クラスダイアグラムの概要
+他のポイントカードの具体例
961ページのFigure 2
Preprintはなし

15. Mining Billions of AST Nodes to Study Actual and
Potential Usage of Java Language Features
Javaの新機能の使われ方に関する調査
1. 新機能はリリース前に使われるか？
使われているがコンパイラのサポート状況に大きく依存する
2. 新機能はどのぐらい使われているのか？
アノテーション，拡張for，ジェネリクスは多く使われているがその他
は多くない
3. 開発者はどのように適応していくのか？
新機能を使ったコードのほとんどは少数の開発者によって書かれている
4. 新機能を使うべきなのに使っていないコードはあるか？
たくさんある
5. 古いコードは新機能で置き換えられているか？
徐々に置き換えられつつある
Preprintはこちら

16. Cowboys, Ankle Sprains, and Keepers of
Quality: How Is Video Game Development
Different from Software Development?
ゲーム開発とその他のソフトウェア開発における慣習の差を調査
ゲーム開発とその他ソフトウェアの開発経験の両方がある開発者
14人にインタビュー，MSの開発者にアンケート
• 自動化されたユニットテストよりも人手によるテストがよく
用いられる
– 状態空間が大きすぎてテストを書くのが大変
• ゲーム開発ではアジャイル開発がよく用いられる
– ……とはいうものの決まったプロセスが無いことをアジャイルと言っ
ているだけ
• その他のソフトウェア開発に比べて多様な能力を要求される
☞ゲーム以外の開発での常識が通用しない
Preprintはこちら

17. Mining Fine-Grained Code Changes to
Detect Unknown Change Patterns
コミット単位よりも細かい単位での変更履
歴から変更パターンをマイニング
抽出されたパターン
void addPerson(Person p) {
…
}
Nullチェック
void addPerson(Person p) {
if (p == null) {return;}
…
}
Enum要素の追加
switch(e){
case START:
}
switch(e){
case START:…
case STOP:…
}
if (e.isStart())… if (e.isStart())…
if (e.isStop())…
Preprintはこちら