【SQiP 2014】継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析 #SQiP #SQuBOK

継続的システムテストについての
理解を深めるための
開発とバグのメトリクスの分析
2014/09/11
荻野恒太郎
kotaro.ogino@mail.rakuten.com
Search Platform Group, Search Section,
Big Data Department, Rakuten Inc.
http://www.rakuten.co.jp/

2
アジェンダ
バックグラウンド
メトリクス
分析①
分析②
分析③
まとめと今後の課題

3
メトリクス
分析①
分析②
分析③

4
背景①：開発プロセスの変化とシステムテスト
• ウォーターフォールからアジャイルへ
平鍋健児, ”ソフトウェア工学の分岐点における、アジャイルの役割” SS2010.
• 早期からのシステムテストの実施
永田敦, “アジャイル開発における品質保証部門によるシステムテストの
アプローチ” JASPIC2013.
• 継続的システムテスト
荻野ら, ”システムテスト自動化による大規模分散検索プラットフォームの
設計実装 (ST)
要求(スコープ)
分析
設計
実装
システムテスト(ST)
自動化前自動化後
時間
要求(スコープ)
時間
分析
開発工程改善” JaSST’ Tokyo 2014.
自動化により
システムテストを
日次で実行

5
背景②:継続的システムテストのメリット
テスト自動化に関する通説
• 品質と、コストとデリバリーはトレードオフ
　→ 品質保証が開発プロセスから独立している事を仮定
継続的システムテスト
• 自動化する事でシステムテストを開発プロセスに取り込む事が可能

6
システムテストを開発プロセスに取り込む
JaSST’14 Tokyoの発表より

7
バグ修正日数が改善
JaSST’14 Tokyoの発表より

8
テスト自動化に関する通説
• 品質と、コストとデリバリーはトレードオフ
　→ 品質保証が開発プロセスから独立している事を仮定
• 自動化する事でシステムテストを開発プロセスに取り込む事が可能
バグ修正日数が減少
　= コストとデリバリーも改善

システムテスト自動化への疑問
疑問②: システムテストを開発プロセスに取り込むって?
9
本発表の目的と手法
疑問①: 自動化されたシステムテストは質が低い?
疑問③: 開発をうまく進めるのに必要な工夫は?
目的: 継続的システムテスト環境下での
開発とシステムテストへの理解を深める事
手法: 開発、プロダクトとバグのメトリクスの分析

継続的システムテストの
“ありのままの姿”
10

11
メトリクス
分析①
分析②
分析③

12
分析対象のメトリクス
開発者
開発メトリクス
日次の
• コミット数
• コミットサイズ
コミットソースコード
レポジトリ
ビルド
テスト
バグ
レポート
プロダクトメトリクス
日次の
• LOC　　　　　 • 変更ファイル数
• 変更LOC • 追加ファイル数
• 追加LOC • 削除ファイル数
• 削除LOC • 変更なしファイル数
• 無変更LOC
バグメトリクス
日次の
• 検出バグ数

13
メトリクスの収集方法
グループメトリクス名収集方法単位
開発メトリクス日次のコミット数 git log (*1) 回数
日次のコミットサイズ git log (*2) 行数
プロダクトメトリクス日次のLOC cloc　(*3)　行数
日次の変更LOC
日次の追加LOC
日次の削除LOC
日次の変更無しLOC
cloc –diff (*4) 行数
日次の変更ファイル
日次の追加ファイル
日次の削除ファイル
日次の変更なしファイル
cloc –diff (*4) ファイル数
バグメトリクス日次のプロダクトの
検出バグ数
- システムテストで発見され
たバグ
-バグ票の作成日で集計
- 同じ欠陥に由来する
モノは新しい方を削除
回数
(*1) https://www.atlassian.com/ja/git/tutorial/git-basics#!log
(*2) コメント等を含む
(*3) http://cloc.sourceforge.net/
(*3）(*4) 開発言語はJava。コメント等を含まない

14
分析対象のメトリクス(2013年度1/28~10/23)
コミット数とコミットサイズ日次のコミット数の分布
コミット数コミットサイズ
25000
20000
15000
10000
5000
0
40
30
20
10
0
Commit
Commit size
200
150
100
50
0
０〜４５〜９１０〜
１４
１５〜
１９
２０〜
２４
２５〜
２９
３０〜
３４
一日のコミット数
日次の検出バグ数の分布
１日で見つかった検出バグ数
250
200
150
100
50
0
0 1 2 3 4 5
変更
LOC
追加
LOC
削除
LOC
2000
0
2000
0
2000
1000
0
時間
LOC
時間
行数
頻度
頻度

15
分析対象の開発プロジェクトの開発フェーズ
大きな
機能要件
システム
リファクタリング
断続的な
小さな要件
受け入れ
テスト
受け入れ
テスト
• 継続的な開発とテストが特徴
1400
1200
1000
800
600
400
200
0
90
80
70
60
50
40
30
20
10
0
累積検出バグ数
累積コミット数
A B C
開発フェーズ
検出バグ数
コミット数
99日間 100日間 84日間

16
継続的システムテストの特徴について考察
従来のシステムテスト
STの位置実装の後実装と平行して同時
役割品質の門番（品質の門番）
リグレッションテスト
テストの追加信頼度成長曲線を
見ながらテスト工程で
ユーザーストーリーと
コードカバレッジを
見ながら実装工程で
テスト期間中の
コード変更
バグ修正のみある
リファクタリング少ない多い

17
メトリクス
分析①
分析②
分析③

18
分析①: 自動化されたシステムテストの評価
分析①の目的
分析対象のプロジェクトのテストの質を調べるため
テスト密度とバグ密度で業界標準と比較
• 我々の開発プロセスを逐次的なミニウォーターフォールと考え
　バグとテスト追加の安定している下記のA,B,C３点で計測
3月 5月 7月 9月
A B C

19
分析①：自動化されたシステムテストの評価
2
1.5
1
0.5
IPAが提供する業界標準の値
(*1) ”ソフトウェア開発データ白書 2012-2013
定量データ分析で分かる開発の最新動向”より
50
40
30
20
10
0
新規開発改良開発
0
評価指標
• バグ密度とテスト密度
• IPAが提供する業界標準の値と比較 (*1)
- 最小値、P25, 中央値、P75, 最大値
→ P25 ~ P75の区間が一つの目安
- 主要言語Javaの値を使用
- 新規開発と改良開発
テスト密度バグ密度
テスト密度
= テストケース数
÷ KLOC
バグ密度
= 検出バグ数
÷ KLOC

20
分析①：テスト密度の業界標準との比較
50
40
30
20
10
0
テスト密度
(18.64)
(28.71)
(38.76)
A B C
50
40
30
20
10
0
本プロジェクト業界標準
考察:
- テスト件数は規模に対して標準的
- テスト密度が継続して上昇
→ フレームワークやDSLの完成後テスト追加が容易に
- Cの期間ではテスト密度が若干業界標準より高い
→ システムテストの件数やカバレッジのための指標が必要

21
分析①：バグ密度の業界標準との比較
2
1.5
1
0.5
0
2
1.5
1
0.5
0
バグ密度
(0.74)
(0.08)
(0.31)
A B C
本プロジェクト業界標準
考察:
- 断続的な小さい要件のBの期間で小さいバグ密度
- 機能追加のないシステムのリファクタリングのCの期間でもバグを検出
→ リファクタリングによるリグレッションを自動テストが検出
- 全体を通し業界標準のバグ密度
→ バグカーブが収束するようなリグレッションテストと推察

22
メトリクス
分析①
分析②
分析③

23
分析②：開発メトリクスとバグの関係
分析②の目的
プロダクトメトリクスだけでなく、開発メトリクスも
バグの見つかり方と関係があるか調査する事
先行研究：プロダクトメトリクスとバグの関係を評価
- S Syedら, “Open Source, Agile and reliability Measures”, ISQI, 2009
- 下村ら, “ソフトウェアメトリクスを用いた単体テストの品質リスク評価”, SQiP2013.
開発メトリクス
コミットソースコード
レポジトリ
バグ
レポート
ビルド
テスト
プロダクトメトリクスバグメトリクス

24
分析②：開発メトリクスとバグの関係
分析手法
• バグメトリクスとの相関を調査
- 日次の開発メトリクス、プロダクトメトリクス
- 週次の積算開発メトリクス、プロダクトメトリクス
開発メトリクスプロダクトメトリクスバグメトリクス
時間
コミット数
時間
変更LOC
時間
検出バグ数
時間
コミット数
日次
データ
週次の
積算データ
時間
検出バグ数
時間
変更LOC

累積検出バグ数と変更無しファイル数の
900
800
700
25
分析②：日次データでの相関
グループ説明変数相関係数
開発メトリクスコミット数
コミットサイズ
0.19
0.06
プロダクトメトリクス
変更LOC
追加LOC
削除LOC
無変更LOC
変更ファイル
追加ファイル
削除ファイル
変更なしファイル
0.36
0.17
0.19
-0.17
0.20
-0.09
0.06
-0.19
6
4
2
0
0 20 40
コミット数
検出バグ数
コミット数と検出バグ数の散布図
600
100
50
0
時系列データ
　累積バグ数
変更無しファイル数
考察:
- すべてのメトリクスで相関は弱い→結合バグ発見までの潜在期間
- ファイルに変更を加えない事には意味がある？

層別分析による検出バグ数
26
分析②：週次の積算データでの相関
グループ説明変数相関係数
開発メトリクス週次コミット数
週次コミットサイズ
0.47
0.33
プロダクトメトリクス週次変更LOC
週次追加LOC
週次削除LOC
週次無変更LOC
週次変更ファイル
週次追加ファイル
週次削除ファイル
週次変更なしファイル
0.56
0.42
0.61
-0.29
0.66
0.20
0.33
-0.31
15
10
5
0
積算変更ファイル数と
検出バグ数の散布図
0 100 200
積算変更ファイル数
検出バグ数
15
10
5
0
積算変更ファイルの
100未満
100以上以下
検出バグ数
考察:
- 開発メトリクスも中程度の相関があるがプロダクトメトリクスより弱い
- 積算変更ファイル数が一番高い相関

27
メトリクス
分析①
分析②
分析③

28
分析③：バグ曲線が緩やかに収束しなかった理由の考察
分析③の目的
継続的システムテスト環境下で早くバグを見つけるには?
バグ曲線が緩やかに収束しなかった理由を考察
信頼度成長曲線
• テスト時間と発見した欠陥数に着目。潜在障害数を予測。
【ソフトウェア信頼性モデル, 山田茂, 1994】
従来のシステムテスト
従来の開発工程分析設計実装システムテスト
継続的システムテストの
開発工程
時間

29
分析③：継続的システムテストでのバグ曲線
90
80
70
60
50
40
検出バグ数時間
30
20
10
0
A
B
C
• 一定の傾きでバグが増えている
• フェーズの終了とともに急速に収束

30
100
80
60
40
20
0
分析手法①
• 累積コミット数に対するバグ曲線による分析
時間
A
累積コミット数
100
80
60
40
20
0
B
0 200 400 600 800 1000
C
A
B
C
(検出バグ数) (検出バグ数)

31
100
80
60
40
20
0
(検出バグ数)
分析手法①
時間
100
80
60
40
20
0
A
B
0 200 400 600 800 1000
C
考察:
- A,B,C開発期間は同じ位
コミット数が大きく異なる
- 時間を横軸にとると
フェーズ終了前で急に収束
- コミットを横軸によると
なだらかに収束
- 小さい収束が大きな収束
A
B
C
(検出バグ数) 累積コミット数

32
100
80
60
40
20
0
(検出バグ数)
分析手法①
時間
100
80
60
40
20
0
A
B
0 200 400 600 800 1000
C
A
B
C
考察:

33
100
80
60
40
20
0
(検出バグ数)
分析手法①
時間
100
80
60
40
20
0
A
B
0 200 400 600 800 1000
C
A
B
C
考察:

34
100
80
60
40
20
0
(検出バグ数)
分析手法①
時間
100
80
60
40
20
0
A
B
0 200 400 600 800 1000
C
A
B
C
考察:

35
100
80
60
40
20
0
(検出バグ数)
分析手法①
時間
100
80
60
40
20
0
A
B
0 200 400 600 800 1000
C
A
B
C
考察:
→ コミットに含まれる
バグの減少を示唆

36
100
80
60
40
20
0
(検出バグ数)
分析手法①
時間
100
80
60
40
20
0
A
B
0 200 400 600 800 1000
C
A
B
C
考察:

37
100
80
60
40
20
0
(検出バグ数)
分析手法①
時間
100
80
60
40
20
0
A
B
0 200 400 600 800 1000
C
A
B
C
考察:
→ 開発者がコミット直後に
　　バグに気づき修正

38
分析手法②
• テスト種別ごとのバグ曲線による分析
累積バグ
累積バグ in スモークテスト
積バグ in その他テスト
A
コミット数
100
80
60
40
20
0
B
C
0 200 400 600 800 1000
(検出バグ数)
　システムテスト
スモークテスト
バージョン
その他テスト
累積検出バグ数 in スモークテスト
累積検出バグ数 in その他テスト

39
分析手法②
累累積積バ検グ
出バグ数
累累積積バ検グ出in バスグモ数ークin テススト
モークテスト
in in A
累積積バ検グ出バそグの数他テスそトの他テスト
A
コミット数
100
80
60
40
20
0
B
C
0 200 400 600 800 1000
(検出バグ数)
バージョン
その他テスト
考察:
- スモークテストを壊すようなコミットがAの期間では一度に集中
- Cでは2回 (見つかったバグの数はともに10)
- Cではスモークテストが収束した後、すぐに全体も収束

40
分析手法②
出バグ数
モークテスト
in in A
A
コミット数
100
80
60
40
20
0
B
C
0 200 400 600 800 1000
(検出バグ数)
バージョン
その他テスト
考察:

41
分析手法②
出バグ数
モークテスト
in in A
A
コミット数
100
80
60
40
20
0
B
C
0 200 400 600 800 1000
(検出バグ数)
バージョン
その他テスト
考察:

42
分析手法②
出バグ数
モークテスト
in in A
A
コミット数
100
80
60
40
20
0
B
C
0 200 400 600 800 1000
(検出バグ数)
バージョン
その他テスト
考察:

43
分析手法②
出バグ数
モークテスト
in in A
A
コミット数
100
80
60
40
20
0
B
C
0 200 400 600 800 1000
(検出バグ数)
バージョン
その他テスト
考察:
→ スモークテストを壊すような開発をイテレーションで分割
コミットを小規模化し、バグを早期に発見、修正出来る

44
メトリクス
分析①
分析②
分析③

45
まとめ：システムテスト自動化に関する疑問
まとめ：　
　継続的システムテストへの理解を深めるため
　開発、プロダクトとバグのメトリクスの分析

46
まとめ：疑問①への答え
答え（分析①より）:
自動化されたシステムテストは“質が低い”と
いう事はない
• ただし、自動化した環境ではテスト密度は
上がりやすいので、
システムテストの
50
カバレッジの指標が必要
0
テスト密度
A B C

47
まとめ：疑問②への答え
答え（分析②より）:
システムテストを開発プロセスに取り込むと
プロダクトメトリクスだけでなく
開発メトリクスもバグの発見の仕方と関係
• バグの混入のされ方は、
　変更無しファイル数や
　変更したファイル数等と関係
層別分析による検出バグ数
15
10
5
0
積算変更ファイルの
100以上 100以下
検出バグ数

48
まとめ：疑問③への答え
答え（分析③より）:
自動化した環境では開発者に早期に
フィードバックする事が重要
• コミットのタイプが機能追加からバグ修正へ
• スモークテストを失敗させるような
コミットをイテレーションで
　分割する事でバグを早期に
発見する事が出来る
コミット数
100
50
0
0 500 1000
(検出バグ数)

49
今後の課題
• システムテストの評価指標
　→ 継続的システムテスト下でのテストの改善
　　　- テストケースの優先順位付け
　　　- テストの作り過ぎを防ぐ
• 開発メトリクスの品質管理への利用
• 開発プロセスと品質保証の
相互作用的な変化

【SQiP 2014】継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析 #SQiP #SQuBOK

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 【SQiP 2014】継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析 #SQiP #SQuBOK

Semelhante a 【SQiP 2014】継続的システムテストについての理解を深めるための開発とバグのメトリクスの分析 #SQiP #SQuBOK (20)