【sqip 2014】継続的システムテストについての理解を深めるための...

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

2

アジェンダ

バックグラウンド

メトリクス

分析①

分析②

分析③

まとめと今後の課題

3


メトリクス

分析①

分析②

分析③


4

(ST) 設計実装

システムテスト(ST)

分析

背景①：開発プロセスの変化とシステムテスト

設計

実装

要求(スコープ)

自動化前自動化後

時間

要求(スコープ)

時間

分析

• ウォーターフォールからアジャイルへ平鍋健児, ”ソフトウェア工学の分岐点における、アジャイルの役割” SS2010.

• 早期からのシステムテストの実施永田敦, “アジャイル開発における品質保証部門によるシステムテストのアプローチ” JASPIC2013.

• 継続的システムテスト荻野ら, ”システムテスト自動化による大規模分散検索プラットフォームの開発工程改善” 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)

0

5000

10000

15000

20000

25000

0

10

20

30

40 Commit

Commit size

0

50

100

150

200

０〜４５〜９１０〜１４

１５〜１９

２０〜２４

２５〜２９

３０〜３４

一日のコミット数

コミット数とコミットサイズ日次のコミット数の分布

１日で見つかった検出バグ数

0

50

100

150

200

250

0 1 2 3 4 5

日次の検出バグ数の分布

変更 LOC

追加 LOC

削除 LOC

0

2000

0

2000

0

1000

2000

LOC

時間

時間

コミット数コミットサイズ

行数

頻度

頻度

15

分析対象の開発プロジェクトの開発フェーズ大きな

機能要件システム

リファクタリング断続的な

小さな要件受け入れ

テスト受け入れ

テスト

• 継続的な開発とテストが特徴

0

200

400

600

800

1000

1200

1400

0

10

20

30

40

50

60

70

80

90

累積検出バグ数

累積コミット数

A B C

開発フェーズ

検出

バグ

数

コミ

ット

数

99日間 100日間 84日間

16

継続的システムテストの特徴について考察

従来のシステムテスト継続的システムテスト

STの位置実装の後実装と平行して同時役割品質の門番（品質の門番）

リグレッションテストテストの追加信頼度成長曲線を

見ながらテスト工程でユーザーストーリーとコードカバレッジを見ながら実装工程で

テスト期間中のコード変更

バグ修正のみある

リファクタリング少ない多い

17


メトリクス

分析①

分析②

分析③


18

分析①: 自動化されたシステムテストの評価

3月 5月 7月 9月


A B C

• 我々の開発プロセスを逐次的なミニウォーターフォールと考え　バグとテスト追加の安定している下記のA,B,C３点で計測


分析①の目的分析対象のプロジェクトのテストの質を調べるためテスト密度とバグ密度で業界標準と比較

19

分析①：自動化されたシステムテストの評価

(*1) ”ソフトウェア開発データ白書 2012-2013 定量データ分析で分かる開発の最新動向”より

0

10

20

30

40

50

新規開発改良開発 0

0.5

1

1.5

2

新規開発改良開発

評価指標 • バグ密度とテスト密度 • IPAが提供する業界標準の値と比較 (*1) - 最小値、P25, 中央値、P75, 最大値 → P25 ~ P75の区間が一つの目安 - 主要言語Javaの値を使用 - 新規開発と改良開発

テスト密度バグ密度

テスト密度 = テストケース数 ÷ KLOC

バグ密度 = 検出バグ数 ÷ KLOC

IPAが提供する業界標準の値

20

分析①：テスト密度の業界標準との比較

考察: - テスト件数は規模に対して標準的 - テスト密度が継続して上昇 → フレームワークやDSLの完成後テスト追加が容易に - Cの期間ではテスト密度が若干業界標準より高い → システムテストの件数やカバレッジのための指標が必要

0

10

20

30

40

50

A B C 0

10

20

30

40

50

新規開発改良開発

テスト密度

業界標準本プロジェクト

(18.64)

(28.71)

(38.76)

21

分析①：バグ密度の業界標準との比較

考察: - 断続的な小さい要件のBの期間で小さいバグ密度 - 機能追加のないシステムのリファクタリングのCの期間でもバグを検出 → リファクタリングによるリグレッションを自動テストが検出 - 全体を通し業界標準のバグ密度 → バグカーブが収束するようなリグレッションテストと推察

0

0.5

1

1.5

2

新規開発改良開発 0

0.5

1

1.5

2

A B C

バグ密度

業界標準本プロジェクト

(0.74)

(0.08) (0.31)

22


メトリクス

分析①

分析②

分析③


23

分析②：開発メトリクスとバグの関係

開発メトリクス

コミットソースコードレポジトリ

バグレポート

プロダクトメトリクスバグメトリクス

ビルドテスト

先行研究：プロダクトメトリクスとバグの関係を評価 - S Syedら, “Open Source, Agile and reliability Measures”, ISQI, 2009 - 下村ら, “ソフトウェアメトリクスを用いた単体テストの品質リスク評価”, SQiP2013.


分析②の目的プロダクトメトリクスだけでなく、開発メトリクスもバグの見つかり方と関係があるか調査する事

24

分析②：開発メトリクスとバグの関係

開発メトリクスプロダクトメトリクスバグメトリクス

分析手法 • バグメトリクスとの相関を調査 - 日次の開発メトリクス、プロダクトメトリクス - 週次の積算開発メトリクス、プロダクトメトリクス

時間

コミ

ット

数

時間

変更

LOC

時間

検出

バグ

数

時間

コミ

ット

数

日次データ

週次の積算データ

時間

検出

バグ

数

時間

変更

LOC

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

0

2

4

6

0 20 40 コミット数

検出

バグ

数

コミット数と検出バグ数の散布図

600

700

800

900

0

50

100

　累積バグ数変更無しファイル数

累積検出バグ数と変更無しファイル数の時系列データ

考察: - すべてのメトリクスで相関は弱い→結合バグ発見までの潜在期間 - ファイルに変更を加えない事には意味がある？

累積検出バグ数変更無しファイル数

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

0

5

10

15

0 100 200

積算変更ファイル数と検出バグ数の散布図

積算変更ファイル数

検出

バグ

数

0

5

10

15

100以上 100以下

積算変更ファイルの層別分析による検出バグ数

検出

バグ

数

考察: - 開発メトリクスも中程度の相関があるがプロダクトメトリクスより弱い - 積算変更ファイル数が一番高い相関

100未満

27


メトリクス

分析①

分析②

分析③


28

分析③：バグ曲線が緩やかに収束しなかった理由の考察

信頼度成長曲線 • テスト時間と発見した欠陥数に着目。潜在障害数を予測。

【ソフトウェア信頼性モデル, 山田茂, 1994】

継続的システムテスト従来のシステムテスト

分析設計実装システムテスト従来の開発工程継続的システムテストの

開発工程時間

累積

検出

バグ

数


分析③の目的継続的システムテスト環境下で早くバグを見つけるには? バグ曲線が緩やかに収束しなかった理由を考察

29

分析③：継続的システムテストでのバグ曲線

0

10

20

30

40

50

60

70

80

90 検

出バ

グ数

時間

A B

C

• 一定の傾きでバグが増えている • フェーズの終了とともに急速に収束


30

0

20

40

60

80

100



時間

0

20

40

60

80

100

0 200 400 600 800 1000

A B

C

分析手法① • 累積コミット数に対するバグ曲線による分析

A B

C

(検出

バグ

数)

(検出

バグ

数)

31

0

20

40

60

80

100

分析③：バグ曲線が緩やかに収束しなかった理由の考察 (検

出バ

グ数

)

時間

0

20

40

60

80

100

0 200 400 600 800 1000

A B

C


考察: - A,B,C開発期間は同じ位コミット数が大きく異なる

- 時間を横軸にとるとフェーズ終了前で急に収束

- コミットを横軸によるとなだらかに収束

- 小さい収束が大きな収束

A B

C

(検出

バグ

数)


32

0

20

40

60

80

100


出バ

グ数

)

時間

0

20

40

60

80

100

0 200 400 600 800 1000

A B

C


A B

C

(検出

バグ

数)






33

0

20

40

60

80

100


出バ

グ数

)

時間

0

20

40

60

80

100

0 200 400 600 800 1000

A B

C


A B

C

(検出

バグ

数)






34

0

20

40

60

80

100


出バ

グ数

)

時間

0

20

40

60

80

100

0 200 400 600 800 1000

A B

C


A B

C

(検出

バグ

数)






35

0

20

40

60

80

100


出バ

グ数

)

時間

0

20

40

60

80

100

0 200 400 600 800 1000

A B

C


A B

C

(検出

バグ

数)






→ コミットに含まれるバグの減少を示唆

36

0

20

40

60

80

100


出バ

グ数

)

時間

0

20

40

60

80

100

0 200 400 600 800 1000

A B

C


A B

C

(検出

バグ

数)







37

0

20

40

60

80

100


出バ

グ数

)

時間

0

20

40

60

80

100

0 200 400 600 800 1000

A B

C


A B

C

(検出

バグ

数)







→ 開発者がコミット直後に　　バグに気づき修正

38


コミット数

0

20

40

60

80

100

0 200 400 600 800 1000

累積バグ累積バグ in スモークテスト累積バグ in その他テスト

A

B C

分析手法② • テスト種別ごとのバグ曲線による分析

(検出

バグ

数)

バージョン

スモークテスト

その他テスト

　システムテスト累積検出バグ数

累積検出バグ数 in スモークテスト

累積検出バグ数 in その他テスト

39


コミット数

0

20

40

60

80

100

0 200 400 600 800 1000

累積バグ累積バグ in スモークテスト累積バグ in その他テスト A

B C


考察: - スモークテストを壊すようなコミットがAの期間では一度に集中 - Cでは2回 (見つかったバグの数はともに10) - Cではスモークテストが収束した後、すぐに全体も収束

(検出

バグ

数)

バージョン


その他テスト

　システムテスト

A




40


コミット数

0

20

40

60

80

100

0 200 400 600 800 1000


B C



(検出

バグ

数)

バージョン


その他テスト


A




41


コミット数

0

20

40

60

80

100

0 200 400 600 800 1000


B C



(検出

バグ

数)

バージョン


その他テスト


A




42


コミット数

0

20

40

60

80

100

0 200 400 600 800 1000


B C



(検出

バグ

数)

バージョン


その他テスト


A




43


コミット数

0

20

40

60

80

100

0 200 400 600 800 1000


B C


考察: - スモークテストを壊すようなコミットがAの期間では一度に集中 - Cでは2回 (見つかったバグの数はともに10) - Cではスモークテストが収束した後、すぐに全体も収束 → スモークテストを壊すような開発をイテレーションで分割コミットを小規模化し、バグを早期に発見、修正出来る

(検出

バグ

数)

バージョン


その他テスト


A




44


メトリクス

分析①

分析②

分析③


45

まとめ：システムテスト自動化に関する疑問

まとめ：　　継続的システムテストへの理解を深めるため　開発、プロダクトとバグのメトリクスの分析




46

まとめ：疑問①への答え

答え（分析①より）: 自動化されたシステムテストは“質が低い”という事はない

• ただし、自動化した環境ではテスト密度は上がりやすいので、システムテストのカバレッジの指標が必要

0

50

A B C

テスト密度


47

まとめ：疑問②への答え

答え（分析②より）: システムテストを開発プロセスに取り込むとプロダクトメトリクスだけでなく開発メトリクスもバグの発見の仕方と関係

• バグの混入のされ方は、　変更無しファイル数や　変更したファイル数等と関係

0 5

10 15

100以上 100以下

積算変更ファイルの層別分析による検出バグ数

検出

バグ

数


48

答え（分析③より）: 自動化した環境では開発者に早期にフィードバックする事が重要

• コミットのタイプが機能追加からバグ修正へ • スモークテストを失敗させるようなコミットをイテレーションで　分割する事でバグを早期に発見する事が出来る

まとめ：疑問③への答え

コミット数

0

50

100

0 500 1000 (検出

バグ

数)


49

今後の課題

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

50

Long live testing

【sqip 2014】継続的システムテストについての理解を深めるための...

Technology