コベリティの静的解析は、数多くの開発現場で導入されテスト工程の手戻り作業を削減してきました。クリーンなコードはテストを円滑に実施していくうえで既に必須条件となっています。では、開発マネージャ、開発組織は次に何を目指すべきでしょうか。 本セッションでは「テスト自動化」に焦点をあて、開発チームの利益を拡大するために、いつ、どこを自動化すべきなのか、自動化作業をサポートするツールを含めご紹介します。

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

2. Coverity Connect の⾃自動テストの例例
2

3. 本当に⾃自動化が解決策？
3
Copyright Coverity, Inc., 2014

4. 担当者が決まらないと 30% 遅い
参照：「不具合管理システム利用時の不具合修正
プロセス改善のための滞留時間分析手法の提案」
伊原・大平・松本 – 文科省次世代IT基盤構築 H21
4

5. 新規不不具合は優先的に対処（Linux）
参照： Coverity SCAN Report 2013
5

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

7. コベリティの製品リリースプロセス
⼀一般的なリリースプロセス:
• 6 ヶ⽉月のリリースサイクル
• 3 ヶ⽉月の次期リリース計画
• リリース直前の 6 週間の
“ハードニング” サイクル
• 2 週間の “フィーチャーフリーズ”
• 2 週間の “インテグレーションフリーズ”
• 2 週間の “リリースフリーズ” と GA のた
めのアップロード
• リリースのコードネームは
カリフォルニア州の都市名
• Alameda, Berkeley, Davis, Eureka, Fresno,
リリースを実⾏行行するプロセス:
• アジャイルプロセス
• 部⾨門横断的なスクラムチーム
• 2 週間のスプリント
• メールまたは対⾯面での⽇日次スタン
ド・アップ
• Jira と PivotalTracker を介した進捗
管理理
• Bugzilla によるバグ管理理
• Jenkins-CI による継続的統合
• 週１回のステータスミーティング
• リリースハードニングでは、週に３回
１つのリリースの詳細
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

8. 明確な必要性
• ６ヶ⽉月のメジャーリリースサイクル
• サポートプラットフォームが⾮非常に多い
• プラットフォームの違いのみのテストケースが多い
• 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. 担当者のスキルセットは正しい？
9
Copyright Coverity, Inc., 2014

10. Coverity -‐‑‒ ２年年前の状況
• QA プロセスは東ヨーロッパで
アウトソースし実施していた
• 伝統的な QA スキル、開発スキルは
わずかかもしくは皆無
• 10時間の時差
• ⾔言語的な壁
• 6 週間のハードニングサイクルは “ロシアン・ルーレット”のようなものだった
• “フィーチャー実装完” と “フィーチャーテスト” の時間的解離離
• 開発者は品質に対して、即座の直接的な責任を感じていなかった
• 何に出くわすかわからない – “簡単なバグ” なのか “致命的バグ” なのか
• とるに⾜足らないバグに QA サイクルの多くが費やされていた
• ⼿手動のプロセスでは、テストを 2-‐‑‒3 回しか回せない
• 製品品質による苦しみ
• よい品質でリリースするために、チームは多くのストレスを抱えていた
10

11. 矯正への最初の試み
• QAと開発の間の境界を取り除く
• 組織的 + 時間的 (開発とテストを織り込んでいく)
• 2011 初頭に組織を再編
• 2/3 の QA リソースを開発組織に移管
• ⽬目的を、テストの⾃自動化を名⽬目に、
“開発しながらテストする” ように設定
• しかし、結果は期待はずれだった
• QA チームはプログラミングに関してトレーニングされておらず、
⾃自動テストを開発するのが困難であった
• テストの⾃自動化に関しては、実際ごくわずかしか進歩しなかった
• 時差と⾔言語の壁が存続していた
11

12. 抜本的な改⾰革 – ⼈人
• リソースを東ヨーロッパから
カナダ、カルガリーに移動
• 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. コードカバレッジの罠
13
Copyright Coverity, Inc., 2014

14. コールグラフ＋条件分岐
UI テスト
パフォーマンス
機能テスト
セキュリティ
未テストコード
全パス
全⾃自動
コードシュミ
レーション
全パスでのコードシュミレーション
コベリティ静的解析エンジン

15. テストされたコード（％）
% 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. コピペミスでさえ…
変数名の書
き換えミス
関数外でも、
検出可能
16

17. 優先度度を設定しているか？
17
Copyright Coverity, Inc., 2014

18. 実験（⾃自社製品）
“チェンジセット”にフォーカスしたテストポリシーを評価する単純な試み
• 解析コード数：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%

19. 社内での経験 – ケーススタディ
• ⼗十分テストされている製品のコンポーネントにこの社内ツールを適⽤用
• 3ヶ⽉月間、１テストエンジニアが１週間のうち４時間、テストすべきと判断された箇
所にテストを追加した
• テストポリシー: テスト可能なコードは 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"
• １⼈人週間換算で29件のテストを追加
• 製品から19件のバグを発⾒見見 – いくつ
かは重⼤大なもの
• 例例： Keil コンパイラの正しい機
能を阻害するバグなど

20. クリーンなコードになってる？
20
Copyright Coverity, Inc., 2014

21. 結合レベルでもクリーンに
シングルト
ンの変数
Address渡
し
呼出し先の
関数内表⽰示
渡された変数
を配列列として
アクセス
21

22. コードレビューの改善
• ⾃自社製品（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

23. 製品顧客が発⾒見見した不不具合
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

24. インパクト解析を取り⼊入れた
テスト⾃自動化ワークフロー
01
01001011
0101101011001
01101011000011
010100101101
01011001
問題を適切な開発者に
アサイン
テスト作成とアップデート
結合レベルでの品質と
セキュリティ脆弱性を
チェック
コードの追加・変更
のため、新しいテストが
必要かチェック
25

25. 様々な静的解析が⾃自動化を⾼高める
26

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

27. 補⾜足資料料
28

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

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.

30. Apache Hadoop (since Aug. 2013)
LOC: 845,000
31

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

32. OWASP Top 10 サポート
OWASP
Top
10
Coverity
7.0
1:
インジェクション
✔
2:
認証とセッション管理理の不不備
✔
3:
クロスサイトスクリプティング (XSS)
✔
4:
安全でないオブジェクトの直接参照
✔
5:
セキュリティ設定のミス
✔
6:
機密データの露露出
✔
✔
7:
機能レベルアクセス制御の⽋欠落落
8:
クロスサイトリクエストフォージェリ (CSRF)
9:
既知の脆弱性を持つコンポーネントの使⽤用
10:
未検証のリダイレクトとフォワード
Coming
soon
NA
✔