Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
テスト⾃自動化を⾒見見直そう!
⾃自動化への投資が開発チームを
クリエイティブにする
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 週間の “フィーチャーフ...
明確な必要性
•  6ヶ⽉月のメジャーリリースサイクル
•  サポートプラットフォームが⾮非常に多い
•  プラットフォームの違いのみのテストケースが多い
•  Jenkins 上のビルドは各プラットフォームに分散

Hardware'for'...
担当者のスキルセットは正しい?

9

	


Copyright Coverity, Inc., 2014
Coverity  -‐‑‒  2年年前の状況
•  QA  プロセスは東ヨーロッパで                                                                               ...
矯正への最初の試み
•  QAと開発の間の境界を取り除く
•  組織的  +  時間的  (開発とテストを織り込んでいく)

•  2011  初頭に組織を再編
•  2/3  の  QA  リソースを開発組織に移管
•  ⽬目的を、テストの⾃...
抜本的な改⾰革 – ⼈人
•  リソースを東ヨーロッパから
カナダ、カルガリーに移動
•  1 時間の時差
•  サンフランシスコから  2.5 時間のフライト
•  ⾔言語の壁がない

•  2011 年年の夏に移⾏行行を開始
•  移⾏行行...
コードカバレッジの罠

13

	


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

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

	
  
	
  
	
  
	
  
全パス	
  
全⾃自動	
  

コードシュミ
レーション	
  

全パスでのコードシュミレーション...
テストされたコード(%)
% Code Tested

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

1

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

- ...
コピペミスでさえ…
変数名の書
き換えミス

関数外でも、	
  
検出可能

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

17

	


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

•  解析コード数:1,372,376 ⾏行行
•  1,149,036 ⾏行行がテストでカバー (83.7% カバレッジ), 223,340 ⾏行行が...
社内での経験 – ケーススタディ
•  ⼗十分テストされている製品のコンポーネントにこの社内ツールを適⽤用
•  3ヶ⽉月間、1テストエンジニアが1週間のうち4時間、テストすべきと判断された箇
所にテストを追加した

•  テストポリシー:  ...
クリーンなコードになってる?

20

	


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

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

呼出し先の
関数内表⽰示

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

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

Defects'Addressed'by'Coverity'Quality/Security'Advisor''
...
製品顧客が発⾒見見した不不具合
Customer4found+Defects+
Normalized+Number+
of+Defects+

1.6"
1.4"
1.2"
1"
0.8"
0.6"
0.4"
0.2"
0"
Alameda"
...
インパクト解析を取り⼊入れた
テスト⾃自動化ワークフロー
01

01001011
0101101011001
01101011000011
010100101101
01011001

問題を適切な開発者に
アサイン
テスト作成とアップデート...
様々な静的解析が⾃自動化を⾼高める

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

Make every developer a roc...
補⾜足資料料

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

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

1000	
  

800	
  

600	
  

#	
  of	
  Projects	
  

400	
  

200	
  

...
Apache Hadoop (since Aug. 2013)

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

解析パッケージ	
  

SDLC	
  統合	
  

Policy	
  Manager	
  

サードパーティ	
  
メトリク...
OWASP Top 10 サポート
OWASP	
  Top	
  10	
  

Coverity	
  	
  7.0	
  

1:	
  インジェクション	
  

✔	
  

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

✔...
Upcoming SlideShare
Loading in …5
×

デブサミ2014【13-B-L】テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする(安竹由起夫〔コベリティジャパン〕)

2,132 views

Published on

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

Published in: Technology
  • Be the first to comment

デブサミ2014【13-B-L】テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする(安竹由起夫〔コベリティジャパン〕)

  1. 1. テスト⾃自動化を⾒見見直そう! ⾃自動化への投資が開発チームを クリエイティブにする 13-‐‑‒B-‐‑‒L:  コベリティジャパン株式会社
  2. 2. Coverity Connect の⾃自動テストの例例 2
  3. 3. 本当に⾃自動化が解決策? 3 Copyright Coverity, Inc., 2014
  4. 4. 担当者が決まらないと 30% 遅い 参照:「不具合管理システム利用時の不具合修正 プロセス改善のための滞留時間分析手法の提案」 伊原・大平・松本 – 文科省次世代IT基盤構築 H21 4
  5. 5. 新規不不具合は優先的に対処(Linux) 参照: Coverity SCAN Report 2013 5
  6. 6. なるべく客観的なデータを⾒見見る 6
  7. 7. コベリティの製品リリースプロセス ⼀一般的なリリースプロセス: •  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
  8. 8. 明確な必要性 •  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. 9. 担当者のスキルセットは正しい? 9 Copyright Coverity, Inc., 2014
  10. 10. Coverity  -‐‑‒  2年年前の状況 •  QA  プロセスは東ヨーロッパで                                                                                                                               アウトソースし実施していた •  伝統的な  QA  スキル、開発スキルは   わずかかもしくは皆無 •  10時間の時差 •  ⾔言語的な壁 •  6  週間のハードニングサイクルは  “ロシアン・ルーレット”のようなものだった •  “フィーチャー実装完”  と  “フィーチャーテスト”  の時間的解離離 •  開発者は品質に対して、即座の直接的な責任を感じていなかった •  何に出くわすかわからない  –  “簡単なバグ”  なのか  “致命的バグ”  なのか •  とるに⾜足らないバグに  QA  サイクルの多くが費やされていた •  ⼿手動のプロセスでは、テストを  2-‐‑‒3  回しか回せない •  製品品質による苦しみ •  よい品質でリリースするために、チームは多くのストレスを抱えていた 10
  11. 11. 矯正への最初の試み •  QAと開発の間の境界を取り除く •  組織的  +  時間的  (開発とテストを織り込んでいく) •  2011  初頭に組織を再編 •  2/3  の  QA  リソースを開発組織に移管 •  ⽬目的を、テストの⾃自動化を名⽬目に、       “開発しながらテストする”  ように設定 •  しかし、結果は期待はずれだった •  QA  チームはプログラミングに関してトレーニングされておらず、                 ⾃自動テストを開発するのが困難であった •  テストの⾃自動化に関しては、実際ごくわずかしか進歩しなかった •  時差と⾔言語の壁が存続していた 11
  12. 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. コードカバレッジの罠 13 Copyright Coverity, Inc., 2014
  14. 14. コールグラフ+条件分岐 UI テスト パフォーマンス 機能テスト セキュリティ 未テストコード         全パス   全⾃自動   コードシュミ レーション   全パスでのコードシュミレーション コベリティ静的解析エンジン
  15. 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. コピペミスでさえ… 変数名の書 き換えミス 関数外でも、   検出可能 16
  17. 17. 優先度度を設定しているか? 17 Copyright Coverity, Inc., 2014
  18. 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. 19. 社内での経験 – ケーススタディ •  ⼗十分テストされている製品のコンポーネントにこの社内ツールを適⽤用 •  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. 20. クリーンなコードになってる? 20 Copyright Coverity, Inc., 2014
  21. 21. 結合レベルでもクリーンに シングルト ンの変数 Address渡 し 呼出し先の 関数内表⽰示 渡された変数 を配列列として アクセス 21
  22. 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. 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. 24. インパクト解析を取り⼊入れた テスト⾃自動化ワークフロー 01 01001011 0101101011001 01101011000011 010100101101 01011001 問題を適切な開発者に アサイン テスト作成とアップデート 結合レベルでの品質と セキュリティ脆弱性を チェック コードの追加・変更 のため、新しいテストが 必要かチェック 25
  25. 25. 様々な静的解析が⾃自動化を⾼高める 26
  26. 26. まとめ •  テスト⾃自動化が解決策か? •  テスト⾃自動化に必要なスキルセットか? •  コードカバレッジはゴールではない •  優先度度を設定しているか? •  クリーンなコードか? Make every developer a rock star ! 27
  27. 27. 補⾜足資料料 28
  28. 28. OSS  プロジェクトに関わるみなさまへ 29
  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. 30. Apache Hadoop (since Aug. 2013) LOC: 845,000 31
  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. 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     ✔  

×