Skip to main content
テスト⾃自動化を⾒見見直そう!
⾃自動化への投資が開発チームを
クリエイティブにする
13-‐‑‒B-‐‑‒L:  コベリティジャパン株式会社
Coverity Connect の⾃自動テストの例例

2
本当に⾃自動化が解決策?
3

	


Copyright Coverity, Inc., 2014
担当者が決まらないと 30% 遅い

参照:「不具合管理システム利用時の不具合修正
プロセス改善のための滞留時間分析手法の提案」
伊原・大平・松本 – 文科省次世代IT基盤構築 H21	
4
新規不不具合は優先的に対処(Linux)

参照: Coverity SCAN Report 2013	

5
なるべく客観的なデータを⾒見見る

6
コベリティの製品リリースプロセス
⼀一般的なリリースプロセス:
•  6 ヶ⽉月のリリースサイクル
•  3 ヶ⽉月の次期リリース計画
•  リリース直前の  6 週間の    

“ハードニング” サイクル
•  2 週間の “フィーチャーフリーズ”
•  2 週間の “インテグレーションフリーズ”
•  2 週間の “リリースフリーズ” と GA のた
めのアップロード

•  リリースのコードネームは                            

カリフォルニア州の都市名
•  Alameda, Berkeley, Davis, Eureka, Fresno,

リリースを実⾏行行するプロセス:
•  アジャイルプロセス
•  部⾨門横断的なスクラムチーム
•  2 週間のスプリント
•  メールまたは対⾯面での⽇日次スタン
ド・アップ

•  Jira と PivotalTracker を介した進捗
管理理

•  Bugzilla によるバグ管理理
•  Jenkins-CI による継続的統合
•  週1回のステータスミーティング
•  リリースハードニングでは、週に3回

1つのリリースの詳細

Next Release Planning

Next Release Execution

Release Execution

Release Planning

Prev. Release Execution

October

December
November

7

	


February
January

April
March

June
May

August
July

6 Weeks
Hardening

September
明確な必要性
•  6ヶ⽉月のメジャーリリースサイクル
•  サポートプラットフォームが⾮非常に多い
•  プラットフォームの違いのみのテストケースが多い
•  Jenkins 上のビルドは各プラットフォームに分散

Hardware'for'STS'Test'Farm'
250#
200#
183#

150#

215#

156#
125#

100#
50#

201#

65# 66#

69# 74#

70#

81#

71#

84#

100#
77#

88#

128#
88#

96#

108#

126#

127#

0#
Pre/2011# Q1#2011# Q2#2011# Q3#2011# Q4#2011# Q1#2012# Q2#2012# Q3#2012# Q4#2012# Q1#2013#
Number#of#Physical#Machines#

8

	


Total#Number#of#Machines#incl.#Virtual#Machines#

Today#
担当者のスキルセットは正しい?

9

	


Copyright Coverity, Inc., 2014
Coverity  -‐‑‒  2年年前の状況
•  QA  プロセスは東ヨーロッパで                                                                                                                              
アウトソースし実施していた

•  伝統的な  QA  スキル、開発スキルは  
わずかかもしくは皆無

•  10時間の時差
•  ⾔言語的な壁

•  6  週間のハードニングサイクルは  “ロシアン・ルーレット”のようなものだった
•  “フィーチャー実装完”  と  “フィーチャーテスト”  の時間的解離離
•  開発者は品質に対して、即座の直接的な責任を感じていなかった
•  何に出くわすかわからない  –  “簡単なバグ”  なのか  “致命的バグ”  なのか

•  とるに⾜足らないバグに  QA  サイクルの多くが費やされていた
•  ⼿手動のプロセスでは、テストを  2-‐‑‒3  回しか回せない

•  製品品質による苦しみ
•  よい品質でリリースするために、チームは多くのストレスを抱えていた
10
矯正への最初の試み
•  QAと開発の間の境界を取り除く
•  組織的  +  時間的  (開発とテストを織り込んでいく)

•  2011  初頭に組織を再編
•  2/3  の  QA  リソースを開発組織に移管
•  ⽬目的を、テストの⾃自動化を名⽬目に、
      “開発しながらテストする”  ように設定

•  しかし、結果は期待はずれだった
•  QA  チームはプログラミングに関してトレーニングされておらず、                
⾃自動テストを開発するのが困難であった

•  テストの⾃自動化に関しては、実際ごくわずかしか進歩しなかった

•  時差と⾔言語の壁が存続していた

11
抜本的な改⾰革 – ⼈人
•  リソースを東ヨーロッパから
カナダ、カルガリーに移動
•  1 時間の時差
•  サンフランシスコから  2.5 時間のフライト
•  ⾔言語の壁がない

•  2011 年年の夏に移⾏行行を開始
•  移⾏行行は12ヶ⽉月以上かかった
•  多くは予算に影響を与えなかった

Personnel(Transi,on(from((
Eastern(Europe(to(Calgary(
14"
12"

•  スキルセットの変更更
•  テスト⾃自動化に焦点をあてたプログラミング
スキル

•  テストの⾃自動化に対する⾼高いモチベーション
12

	


10"
8"
6"
4"
2"
0"
Q3"2011"

Q4"2011"

Q1"2012"

Eastern"Europe"

Q2"2012"
Calgary""

Q3"2012"
コードカバレッジの罠

13

	


Copyright Coverity, Inc., 2014
コールグラフ+条件分岐

UI テスト
パフォーマンス
機能テスト
セキュリティ
未テストコード

	
  
	
  
	
  
	
  
全パス	
  
全⾃自動	
  

コードシュミ
レーション	
  

全パスでのコードシュミレーション

コベリティ静的解析エンジン
テストされたコード(%)
% Code Tested

コードカバレッジに対するチャレンジ
100%

1

Diminishing return for
テスト⼯工数の増加
increased test effort
に対し効果は減少

-  ...

3

Effort to develop tests
テスト作成の⼯工数

15

2

テストできないコードも存在
Not all code is testable
-  unreachable statements
- 到達できないステートメント
-  デッドコード
- dead code, ...

テストを⾏行行う価値がないコード
Not all tested code adds
-  重要でないコード
equal value to the test
-  デバッグコード、既存コード
- non-critical code
-  決まりきった例例外処理理
- …
-  debug code, legacy code
- exception handling, ...
コピペミスでさえ…
変数名の書
き換えミス

関数外でも、	
  
検出可能

16
優先度度を設定しているか?

17

	


Copyright Coverity, Inc., 2014
実験(⾃自社製品)
“チェンジセット”にフォーカスしたテストポリシーを評価する単純な試み

•  解析コード数:1,372,376 ⾏行行
•  1,149,036 ⾏行行がテストでカバー (83.7% カバレッジ), 223,340 ⾏行行が未テスト
•  直前の変更更にフォーカスすると、145 ファイル内の  851 ⾏行行をカバーする必要
がある

Untested	
  LOC	
  

250,000	
  	
  

2500	
  

223,340	
  	
  
1979	
  

200,000	
  	
  

2000	
  
1743	
  

150,000	
  	
  

1500	
  

100,000	
  	
  

1000	
  
404	
  

50,000	
  	
  
-­‐	
  	
  	
  	
  

9,636	
  	
  

7,934	
  	

145	
  
851	
  	

Total	
  

Since	
  5.3	
  

Since	
  5.4	
  

Since	
  5.4.1	
  

Untested	
  LOC	
  

223,340	
  	
  

9,636	
  	
  

7,934	
  	
  

851	
  	
  

Untested	
  LOC	
  (%)	
  

100.0%	
  

2.0%	
  

1.6%	
  

0.2%	
  

1979	
  

1743	
  

404	
  

145	
  

#	
  Incomplete	
  Tested	
  Files	
  

500	
  
0	
  

#	
  Incomplete	
  Tested	
  Files	
  

Focus	
  tes6ng	
  on	
  latest	
  changes	
  

	


#	
  Incomplete	
  Tested	
  Files	
  

明らかに対処しやすい:
• 
• 

18

Untested	
  LOC	
  

未テストコードの 0.2%
未テストファイルの 7%
社内での経験 – ケーススタディ
•  ⼗十分テストされている製品のコンポーネントにこの社内ツールを適⽤用
•  3ヶ⽉月間、1テストエンジニアが1週間のうち4時間、テストすべきと判断された箇
所にテストを追加した

•  テストポリシー:  テスト可能なコードは  100%  テストする  (除外:  デバッグコード,  
実⾏行行されないコード,  その他)

Test'Advisor'Applica:on'in'Frontend'Project'
20"
18"

30"

16"

25"

14"
12"

20"

10"
15"

8"
6"

10"

4"

5"

2"
0"

28
*A
pr
*1
2"
5*
M
ay
*1
2"
12
*M
ay
*1
2"
19
*M
ay
*1
2"
26
*M
ay
*1
2"
2*
Ju
n*
12
"
9*
Ju
n*
12
"
16
*Ju
n*
12
"
23
*Ju
n*
12
"
30
*Ju
n*
12
"
7*
Ju
l*1
2"
14
*Ju
l*1
2"
21
*Ju
l*1
2"

0"

Date'

1
9

Tests"added"through"TA"

Bugs"found"by"TA"tests"

Number'of'Bugs'Found'

Number'of'Tests'from'TA'

35"

•  1⼈人週間換算で29件のテストを追加
•  製品から19件のバグを発⾒見見  –  いくつ
かは重⼤大なもの
•  例例:  Keil  コンパイラの正しい機
能を阻害するバグなど
クリーンなコードになってる?

20

	


Copyright Coverity, Inc., 2014
結合レベルでもクリーンに

シングルト
ンの変数
Address渡
し

呼出し先の
関数内表⽰示

渡された変数
を配列列として
アクセス

21
コードレビューの改善
•  ⾃自社製品(Quality Advisor, Security Advisor)を開発に
も使⽤用

Defects'Addressed'by'Coverity'Quality/Security'Advisor''
Number'of'Defects'

400"
350"
300"
250"
200"
150"
100"
50"
0"
Alameda"

Berkeley"
High"Impact"

Carmel"
Medium"Impact"

Davis"
Low"Impact"

Eureka*"
22	
  
製品顧客が発⾒見見した不不具合
Customer4found+Defects+
Normalized+Number+
of+Defects+

1.6"
1.4"
1.2"
1"
0.8"
0.6"
0.4"
0.2"
0"
Alameda"

Berkeley"

Carmel"

Davis"

23
インパクト解析を取り⼊入れた
テスト⾃自動化ワークフロー
01

01001011
0101101011001
01101011000011
010100101101
01011001

問題を適切な開発者に
アサイン
テスト作成とアップデート
結合レベルでの品質と
セキュリティ脆弱性を
チェック
コードの追加・変更
のため、新しいテストが
必要かチェック
25
様々な静的解析が⾃自動化を⾼高める

26
まとめ
•  テスト⾃自動化が解決策か?
•  テスト⾃自動化に必要なスキルセットか?
•  コードカバレッジはゴールではない
•  優先度度を設定しているか?
•  クリーンなコードか?

Make every developer a rock star !	

27
補⾜足資料料

28
OSS  プロジェクトに関わるみなさまへ

29
2013  に⼀一気に拡⼤大  
#	
  of	
  Projects	
  
1200	
  

1000	
  

800	
  

600	
  

#	
  of	
  Projects	
  

400	
  

200	
  

0	
  
Jan.	
  

30

	


Feb.	
  

March	
  

April	
  

May	
  	
  

June	
  

July	
  

Aug.	
  

Sept.	
  

Oct.	
  

Nov.	
  

Dec.	
  
Apache Hadoop (since Aug. 2013)

LOC: 845,000	
31
Coverity Development Testing Platform
  解析 | 修正 | 統制

解析パッケージ	
  

SDLC	
  統合	
  

Policy	
  Manager	
  

サードパーティ	
  
メトリクス	
  

Dynamic	
  
Analysis	
  

IDE	
  

Coverity	
  Connect	
  

コード	
  
カバレッジ 	
  

Architecture	
  
Analysis	
  

解析結果統合	
  

Quality	
  
Advisor	
  

Security	
  
Advisor	
  

Test	
  
Advisor	
  

FindBugs™	
  |	
  
FxCop	
  

テスト	
  
実⾏行行	
  
ビルド/	
  
継続的統合	
  
バグ	
  
トラッキング	
  
SCM	
  

解析結果統合	
  
ツールキット	
  

Coverity	
  SAVE™	
  	
  

Static	
  Analysis	
  Verification	
  Engine	
  

              商⽤用コード  |      オープンソースコード
32

	


ALM	
  連携	
  
HP	
  |	
  IBM	
  
OWASP Top 10 サポート
OWASP	
  Top	
  10	
  

Coverity	
  	
  7.0	
  

1:	
  インジェクション	
  

✔	
  

2:	
  認証とセッション管理理の不不備	
  

✔	
  

3:	
  クロスサイトスクリプティング (XSS)	
  

✔	
  

4:	
  安全でないオブジェクトの直接参照	
  

✔	
  

5:	
  セキュリティ設定のミス	
  

✔	
  

6:	
  機密データの露露出	
  

✔	
  
	
  
✔	
  

7:	
  機能レベルアクセス制御の⽋欠落落	
  
8:	
  クロスサイトリクエストフォージェリ (CSRF)	
  
9:	
  既知の脆弱性を持つコンポーネントの使⽤用	
  
10:	
  未検証のリダイレクトとフォワード	
  

Coming	
  soon	
  
NA	
  
	
  
✔