SlideShare a Scribd company logo

継続的インテグレーションとテストの話

•Download as KEY, PDF•
•
Preferred Networks
Preferred Networks
1 of 46
Downloaded 94 times
PFIセミナー 継続的インテグレーションと テストの話 Eiichiro Iwata 2012年 5月 10日
自己紹介  岩田 英一郎 (@eiichiroi)  元さいたまな人  経歴  2009年6月∼ アルバイト  2010年3月  埼玉大学 大学院理工学研究科 修了  2010年8月∼ PFI入社  所属  製品開発部  Sedueプロジェクト  仕事  Sedue(検索エンジン)の開発  コア∼運用ツールを幅広く  研究開発成果の取り込み 2
本日の内容 3
本日の内容  型？  残念ながら違います 3
本日の内容  型？  残念ながら違います  継続的インテグレーション  概要/流れ/価値/懸念点/導入  テスト  単体テスト/統合テスト/システムテスト/受け入れテスト  結論  継続的インテグレーションとテストは重要 3
本日の内容  型？  残念ながら違います  継続的インテグレーション  概要/流れ/価値/懸念点/導入  テスト  単体テスト/統合テスト/システムテスト/受け入れテスト  結論  継続的インテグレーションとテストは重要  注意  基礎的な話が多めなので、ご存知の方はあまり面白くないかも 3
継続的インテグレーションとは？  インテグレーション  複数のコンポーネントで構成されるソフトウェアが一つのシステム として機能することを検証すること  継続的？  変更がある度に！  目的  ソフトウェア品質の向上  特に重要なこと  迅速なフィードバックを得られるようにすること  自動化が効果的(ボタン一発！) 4
継続的インテグレーションの流れ 監視 バージョン管理 インテグレーション システム サーバー (git, subversion, ...) (jenkins, ...) 5
継続的インテグレーションの流れ 監視 バージョン管理 インテグレーション システム サーバー (git, subversion, ...) (jenkins, ...) 1.開発/検証/パッチレビュー 2.プライベートビルド 5 (開発環境でのビルド)
継続的インテグレーションの流れ 監視 変更をコミット バージョン管理 インテグレーション システム サーバー (git, subversion, ...) (jenkins, ...) 1.開発/検証/パッチレビュー 2.プライベートビルド 5 (開発環境でのビルド)
継続的インテグレーションの流れ 監視 実行 変更をコミット ビルドスクリプト バージョン管理 インテグレーション 1.コンパイル システム サーバー 2.テストの実行 (git, subversion, ...) (jenkins, ...) 3.インスペクションの実行 (コードの解析) 4.デプロイ 1.開発/検証/パッチレビュー (パッケージ作成など) 2.プライベートビルド 5 (開発環境でのビルド)
継続的インテグレーションの流れ フィードバックの生成 監視 実行 変更をコミット ビルドスクリプト バージョン管理 インテグレーション 1.コンパイル システム サーバー 2.テストの実行 (git, subversion, ...) (jenkins, ...) 3.インスペクションの実行 (コードの解析) 4.デプロイ 1.開発/検証/パッチレビュー (パッケージ作成など) 2.プライベートビルド 5 (開発環境でのビルド)
継続的インテグレーションの流れ フィードバックの通知 フィードバックの生成 監視 実行 変更をコミット ビルドスクリプト バージョン管理 インテグレーション 1.コンパイル システム サーバー 2.テストの実行 (git, subversion, ...) (jenkins, ...) 3.インスペクションの実行 (コードの解析) 4.デプロイ 1.開発/検証/パッチレビュー (パッケージ作成など) 2.プライベートビルド 5 (開発環境でのビルド)
ビルドの種類 プライベートビルド インテグレーションビルド リリースビルド  種類  プライベートビルド  インテグレーションビルド  リリースビルド  実行される場所や内容が異なる  迅速なフィードバックを得られるようにするため 6
ビルドの種類 - プライベートビルド プライベートビルド インテグレーションビルド リリースビルド  開発環境でのビルド  リポジトリに変更をコミットする前に実行する  個人(開発者)向け  ビルドの範囲  コンパイル  軽量なテスト(単体テスト)  実行時間の目安  10分以内 7
ビルドの種類 - インテグレーションビルド(1/3) プライベートビルド インテグレーションビルド リリースビルド  インテグレーションサーバーでのビルド  開発チーム向け  分類  コミットビルド  2次ビルド 8
ビルドの種類 - インテグレーションビルド(2/3) プライベートビルド インテグレーションビルド リリースビルド  コミットビルド  リポジトリに変更がコミットされる度に実行される  ビルドの範囲  コンパイル  軽量なテスト(単体テスト)  実行時間の目安  10分以内 9
ビルドの種類 - インテグレーションビルド(3/3) プライベートビルド インテグレーションビルド リリースビルド  2次ビルド  コミットビルドが成功した後に実行される(場合によって日次/週次)  ビルドの範囲  コンパイル  軽量なテスト(単体テスト)  重量なテスト(統合テスト/システムテスト/受け入れテスト)  インスペクション  デプロイ  実行時間の目安  10分∼数時間以内 10
ビルドの種類 - リリースビルド プライベートビルド インテグレーションビルド リリースビルド  リリース前に行うビルド  ユーザ(顧客)向け  ビルド範囲  コンパイル  テスト  単体テスト/統合テスト/システムテスト/受け入れテスト  性能テスト/負荷テストを含めることも  インスペクション  デプロイ  実行時間の目安  インテグレーションビルドと同様 + α 11
継続的インテグレーションの価値 12
継続的インテグレーションの価値  検証コストの削減  ビルドの自動化による恩恵  常にデプロイ可能なソフトウェアを提供できる  迅速なフィードバックによりバグの混入∼修正まで短時間で  失敗したら最優先で直す  修正/機能追加を自信を持って行える  既存のテストを壊してないかすぐ分かる 12
継続的インテグレーションの価値  検証コストの削減  ビルドの自動化による恩恵  常にデプロイ可能なソフトウェアを提供できる  迅速なフィードバックによりバグの混入∼修正まで短時間で  失敗したら最優先で直す  修正/機能追加を自信を持って行える  既存のテストを壊してないかすぐ分かる 品質の高いソフトウェアへ 12
継続的インテグレーションの懸念点  CIシステムの構築が大変？  出来ればプロジェクトの初期から導入するのが望ましい  プロジェクトの途中から導入する場合はやや大変  自動化に必要な機能開発など  段階的導入を検討する ‒ 日次ビルド、コンパイルと単体テスト∼  ハードウェア/ソフトウェアの費用は？  削減できる検証コストに比べれば微々たるもの  開発環境で走らせれば良いのでは？  クリーンなビルド環境は重要です  プライベートビルドが通っても、インテグレーションビルドが通ら ないこともあります(迫真) 13
継続的インテグレーションの導入 Jenkins Travis CI  インテグレーションサーバーのセットアップ  Jenkins  Travis CI  ビルドの自動化 1. コンパイル 2. テスト 3. インスペクション 4. デプロイ 14
Jenkins - セットアップ Jenkins Travis CI  Jenkins  インストール  起動  ブラウザ経由でポチポチ設定  リポジトリの場所の登録  ビルドスクリプトの登録  ビルド結果の通知方法の設定  ビルド結果もブラウザで確認できる  プラグインも豊富  続きは  Jenkins実践入門  Jenkins ユーザ・カンファレンス 2012 東京 15
Jenkins - 色々なフィードバック手段を試してみる Jenkins Travis CI  フィードバック手段  メール  光(ランプ)  音  タスクバー、Growl  ブラウザのプラグイン  いつ、だれに、何をフィードバックするのかを考慮しつつ決める 16
Jenkins - 最近リリースされたDashbozu Jenkins Travis CI  今回は試す時間が確保できず...紹介のみ 17
Travis CI Jenkins Travis CI  Travis CI  継続的インテグレーションを提供するサービス  オープンソース向け  GitHubと連携  http://travis-ci.org/  ※公式対応言語に注意(C++とかD言語とか公式対応してません)  セットアップ 1. GitHubとの連携を許可 2. リポジトリ毎にTravisの有効/無効を設定 3. ビルドスクリプトを書いてリポジトリにコミット  .travis.ymlをリポジトリのトップディレクトリへ  pficommonをforkして登録してみた  http://travis-ci.org/#!/eiichiroi/pficommon 18
継続的インテグレーションの導入 コンパイル テスト インスペクション デプロイ  インテグレーションサーバーのセットアップ  Jenkins  Travis CI  ビルドの自動化 1. コンパイル 2. テスト 3. インスペクション 4. デプロイ 19
ビルドの自動化 - 1.コンパイル コンパイル テスト インスペクション デプロイ  コンパイル手順の自動化  waf  autotools  make  rake  ant  (言語やプロジェクトに応じて選択) 20
ビルドの自動化 - 2.テストの実行 コンパイル テスト インスペクション デプロイ  テストフレームワーク  Google Test, Boost.Test  (言語やプロジェクト、テストの種類に応じて選択)  テストの実行範囲が重要  迅速にフィードバックを得られるように、分類して実行範囲を絞る  段階的にテストを実施すると良い  軽量なテスト  単体テスト  重量なテスト  統合テスト/システムテスト/受け入れテスト/...  データベースのセットアップなどが必要になることも多い 21
ビルドの自動化 - 3.インスペクションの実行(1/2) コンパイル テスト インスペクション デプロイ  ソースコードの静的解析・動的解析  コーディング規約違反の検出(cpplint)  コピペの検出  各種コードメトリクスの計測  クラス数  メソッド数  テストの網羅率(カバレッジ)  注意点  解析をして終わりにしない。何かしらの対処を行う  コーディング規約違反を直す  コピペは共通化できるなら直す  カバレッジが低いところを補強する 22
ビルドの自動化 - 3.インスペクションの実行(2/2) コンパイル テスト インスペクション デプロイ  pficommonのカバレッジを測定してみた  gcc + gcov + lcov  スクリプト  https://gist.github.com/2643761  結果  http://eiichiroi.github.com/pficommon/  network...(^p^)...pull requestお待ちしております 23
ビルドの自動化 - 4.デプロイ コンパイル テスト インスペクション デプロイ  ソフトウェアを利用可能な状態で提供すること  デプロイ対象のプラットフォームごとに  (テストやインスペクションの実施)  パッケージの作成  設定ファイルの準備  ...  継続的にデプロイまで行うのは割と大変  短期間でのリリースを行う場合はほぼ必須になる 24
テスト 単体テスト 統合テスト システムテスト 受け入れテスト  テストのないコードはレガシーコード！  ソフトウェアの品質を担保するために必要  テストの分類(IEEE標準規格)  単体テスト  統合テスト  システムテスト  受け入れテスト  注意  組織によっては分類が少ないことも コンパイル 単体テスト 統合テスト システムテスト 受け入れテスト インスペクション デプロイ プライベートビルド コミットビルド 2次ビルド リリースビルド 25
単体テスト 単体テスト 統合テスト システムテスト 受け入れテスト  個々のコンポーネントに対して個別に行うテスト  コンポーネント 車の場合  関数 エンジン  クラス キャリブレータ 他のエンジン部品  ...ねじ？  テストする人 燃料モジュール 空気モジュール  各コンポーネントの開発者 ねじ1 ねじX 何か ねじ1 何か  優れた単体テスト  実行速度が速い(1テスト0.1秒では遅い)  問題箇所の特定がしやすい 26
単体テストの例: pficommon 単体テスト 統合テスト システムテスト 受け入れテスト 27
単体テストの例: pficommon 単体テスト 統合テスト システムテスト 受け入れテスト  文字列をbase64エンコードする関数  テストコード 27
単体テストの注意点 単体テスト 統合テスト システムテスト 受け入れテスト  単体テストではないもの  外部リソースに依存するテスト  データベース/ネットワーク/ファイルシステムにアクセスする  →モックオブジェクトなどで分離  細かいテクニックはレガシーコード改善ガイドを参照  ソフトウェアを変更するにはテストが重要  テストのない状況からテストを整備していく方法  依存関係を排除するテクニック集 28
統合テスト 単体テスト 統合テスト システムテスト 受け入れテスト  システムの一部を対象とするテスト  複数のコンポーネントが依存関係を持つテスト  外部リソースへ依存するテスト  データベース/ネットワーク/ファイルシステムにアクセスする 車の場合  テストする人  開発チームの人 エンジン  優れた統合テスト キャリブレータ 他のエンジン部品  網羅率が高い 燃料モジュール 空気モジュール  単体テストと統合テストの境界  ソフトウェアの規模による ねじ1 ねじX 何か ねじ1 何か  テストの実行時間が十分少ないときには分けないことも 29
統合テストの例: pficommon 単体テスト 統合テスト システムテスト 受け入れテスト  pfi::text::jsonのテスト  pficommon/src/text/json_test.cpp  粒度が粗めのテストが多い  pfi::data::serializationのテスト  pficommon/src/data/serialization_test.cpp  色んな型の変数をファイルへシリアライズしている  興味ある型はgithubを見てください 30
システムテスト 単体テスト 統合テスト システムテスト 受け入れテスト  システム全体を対象とするテスト 車の場合  UIやAPIを経由してテストする 車  テストする人  テストチーム 駆動装置 HVAC 他の車体部品  優れたシステムテスト  幅広いテスト エンジン トランスミッション  機能/負荷/性能テストなど キャリブレータ 他のエンジン部品  統合テストとシステムテストの境界  ソフトウェアの規模によって変わる  何を「システム」と定義するか？サブシステムに分割することも  統合テストとシステムテストを合わせて結合テストと呼ぶことも？  組織によって違ったりしてカオス 31
受け入れテスト 単体テスト 統合テスト システムテスト 受け入れテスト  ユーザの要件を満たしているかどうかのテスト  アルファテスト  開発者側で行う受け入れテスト  ベータテスト  顧客側で行う受け入れテスト  ユーザビリティのテストなども行う  テストする人  顧客  顧客層を代表する人  顧客やソフトウェアのユースケースを良く理解している  優れた受け入れテスト  実環境とテスト環境が同じ  ハードウェア/ソフトウェア/データ/人 32
まとめ  継続的インテグレーション  概要/流れ/価値/懸念点/導入  テスト  単体テスト/統合テスト/システムテスト/受け入れテスト  結論  継続的インテグレーションとテストは重要  検証コストの削減  常にデプロイ可能なソフトウェアを提供できる  修正/機能追加を自信を持って行える  段階的にでも良いので導入しましょう 33
参考文献  継続的インテグレーション入門  やや古くなっているが、まとまっている  Jenkins実践入門  Jenkins導入するなら  体系的ソフトウェアテスト入門  テストプロセス、テスト計画、テスト実行  レガシーコード改善ガイド  開発者は読むべき 34
Copyright © 2006-2012 Preferred Infrastructure All Right Reserved.

More Related Content

継続的インテグレーションとテストの話

  • 1. PFIセミナー 継続的インテグレーションと テストの話 Eiichiro Iwata 2012年 5月 10日
  • 2. 自己紹介  岩田 英一郎 (@eiichiroi)  元さいたまな人  経歴  2009年6月∼ アルバイト  2010年3月  埼玉大学 大学院理工学研究科 修了  2010年8月∼ PFI入社  所属  製品開発部  Sedueプロジェクト  仕事  Sedue(検索エンジン)の開発  コア∼運用ツールを幅広く  研究開発成果の取り込み 2
  • 4. 本日の内容  型？  残念ながら違います 3
  • 5. 本日の内容  型？  残念ながら違います  継続的インテグレーション  概要/流れ/価値/懸念点/導入  テスト  単体テスト/統合テスト/システムテスト/受け入れテスト  結論  継続的インテグレーションとテストは重要 3
  • 6. 本日の内容  型？  残念ながら違います  継続的インテグレーション  概要/流れ/価値/懸念点/導入  テスト  単体テスト/統合テスト/システムテスト/受け入れテスト  結論  継続的インテグレーションとテストは重要  注意  基礎的な話が多めなので、ご存知の方はあまり面白くないかも 3
  • 7. 継続的インテグレーションとは？  インテグレーション  複数のコンポーネントで構成されるソフトウェアが一つのシステム として機能することを検証すること  継続的？  変更がある度に！  目的  ソフトウェア品質の向上  特に重要なこと  迅速なフィードバックを得られるようにすること  自動化が効果的(ボタン一発！) 4
  • 8. 継続的インテグレーションの流れ 監視 バージョン管理 インテグレーション システム サーバー (git, subversion, ...) (jenkins, ...) 5
  • 9. 継続的インテグレーションの流れ 監視 バージョン管理 インテグレーション システム サーバー (git, subversion, ...) (jenkins, ...) 1.開発/検証/パッチレビュー 2.プライベートビルド 5 (開発環境でのビルド)
  • 10. 継続的インテグレーションの流れ 監視 変更をコミット バージョン管理 インテグレーション システム サーバー (git, subversion, ...) (jenkins, ...) 1.開発/検証/パッチレビュー 2.プライベートビルド 5 (開発環境でのビルド)
  • 11. 継続的インテグレーションの流れ 監視 実行 変更をコミット ビルドスクリプト バージョン管理 インテグレーション 1.コンパイル システム サーバー 2.テストの実行 (git, subversion, ...) (jenkins, ...) 3.インスペクションの実行 (コードの解析) 4.デプロイ 1.開発/検証/パッチレビュー (パッケージ作成など) 2.プライベートビルド 5 (開発環境でのビルド)
  • 12. 継続的インテグレーションの流れ フィードバックの生成 監視 実行 変更をコミット ビルドスクリプト バージョン管理 インテグレーション 1.コンパイル システム サーバー 2.テストの実行 (git, subversion, ...) (jenkins, ...) 3.インスペクションの実行 (コードの解析) 4.デプロイ 1.開発/検証/パッチレビュー (パッケージ作成など) 2.プライベートビルド 5 (開発環境でのビルド)
  • 13. 継続的インテグレーションの流れ フィードバックの通知 フィードバックの生成 監視 実行 変更をコミット ビルドスクリプト バージョン管理 インテグレーション 1.コンパイル システム サーバー 2.テストの実行 (git, subversion, ...) (jenkins, ...) 3.インスペクションの実行 (コードの解析) 4.デプロイ 1.開発/検証/パッチレビュー (パッケージ作成など) 2.プライベートビルド 5 (開発環境でのビルド)
  • 14. ビルドの種類 プライベートビルド インテグレーションビルド リリースビルド  種類  プライベートビルド  インテグレーションビルド  リリースビルド  実行される場所や内容が異なる  迅速なフィードバックを得られるようにするため 6
  • 15. ビルドの種類 - プライベートビルド プライベートビルド インテグレーションビルド リリースビルド  開発環境でのビルド  リポジトリに変更をコミットする前に実行する  個人(開発者)向け  ビルドの範囲  コンパイル  軽量なテスト(単体テスト)  実行時間の目安  10分以内 7
  • 16. ビルドの種類 - インテグレーションビルド(1/3) プライベートビルド インテグレーションビルド リリースビルド  インテグレーションサーバーでのビルド  開発チーム向け  分類  コミットビルド  2次ビルド 8
  • 17. ビルドの種類 - インテグレーションビルド(2/3) プライベートビルド インテグレーションビルド リリースビルド  コミットビルド  リポジトリに変更がコミットされる度に実行される  ビルドの範囲  コンパイル  軽量なテスト(単体テスト)  実行時間の目安  10分以内 9
  • 18. ビルドの種類 - インテグレーションビルド(3/3) プライベートビルド インテグレーションビルド リリースビルド  2次ビルド  コミットビルドが成功した後に実行される(場合によって日次/週次)  ビルドの範囲  コンパイル  軽量なテスト(単体テスト)  重量なテスト(統合テスト/システムテスト/受け入れテスト)  インスペクション  デプロイ  実行時間の目安  10分∼数時間以内 10
  • 19. ビルドの種類 - リリースビルド プライベートビルド インテグレーションビルド リリースビルド  リリース前に行うビルド  ユーザ(顧客)向け  ビルド範囲  コンパイル  テスト  単体テスト/統合テスト/システムテスト/受け入れテスト  性能テスト/負荷テストを含めることも  インスペクション  デプロイ  実行時間の目安  インテグレーションビルドと同様 + α 11
  • 21. 継続的インテグレーションの価値  検証コストの削減  ビルドの自動化による恩恵  常にデプロイ可能なソフトウェアを提供できる  迅速なフィードバックによりバグの混入∼修正まで短時間で  失敗したら最優先で直す  修正/機能追加を自信を持って行える  既存のテストを壊してないかすぐ分かる 12
  • 22. 継続的インテグレーションの価値  検証コストの削減  ビルドの自動化による恩恵  常にデプロイ可能なソフトウェアを提供できる  迅速なフィードバックによりバグの混入∼修正まで短時間で  失敗したら最優先で直す  修正/機能追加を自信を持って行える  既存のテストを壊してないかすぐ分かる 品質の高いソフトウェアへ 12
  • 23. 継続的インテグレーションの懸念点  CIシステムの構築が大変？  出来ればプロジェクトの初期から導入するのが望ましい  プロジェクトの途中から導入する場合はやや大変  自動化に必要な機能開発など  段階的導入を検討する ‒ 日次ビルド、コンパイルと単体テスト∼  ハードウェア/ソフトウェアの費用は？  削減できる検証コストに比べれば微々たるもの  開発環境で走らせれば良いのでは？  クリーンなビルド環境は重要です  プライベートビルドが通っても、インテグレーションビルドが通ら ないこともあります(迫真) 13
  • 24. 継続的インテグレーションの導入 Jenkins Travis CI  インテグレーションサーバーのセットアップ  Jenkins  Travis CI  ビルドの自動化 1. コンパイル 2. テスト 3. インスペクション 4. デプロイ 14
  • 25. Jenkins - セットアップ Jenkins Travis CI  Jenkins  インストール  起動  ブラウザ経由でポチポチ設定  リポジトリの場所の登録  ビルドスクリプトの登録  ビルド結果の通知方法の設定  ビルド結果もブラウザで確認できる  プラグインも豊富  続きは  Jenkins実践入門  Jenkins ユーザ・カンファレンス 2012 東京 15
  • 26. Jenkins - 色々なフィードバック手段を試してみる Jenkins Travis CI  フィードバック手段  メール  光(ランプ)  音  タスクバー、Growl  ブラウザのプラグイン  いつ、だれに、何をフィードバックするのかを考慮しつつ決める 16
  • 27. Jenkins - 最近リリースされたDashbozu Jenkins Travis CI  今回は試す時間が確保できず...紹介のみ 17
  • 28. Travis CI Jenkins Travis CI  Travis CI  継続的インテグレーションを提供するサービス  オープンソース向け  GitHubと連携  http://travis-ci.org/  ※公式対応言語に注意(C++とかD言語とか公式対応してません)  セットアップ 1. GitHubとの連携を許可 2. リポジトリ毎にTravisの有効/無効を設定 3. ビルドスクリプトを書いてリポジトリにコミット  .travis.ymlをリポジトリのトップディレクトリへ  pficommonをforkして登録してみた  http://travis-ci.org/#!/eiichiroi/pficommon 18
  • 29. 継続的インテグレーションの導入 コンパイル テスト インスペクション デプロイ  インテグレーションサーバーのセットアップ  Jenkins  Travis CI  ビルドの自動化 1. コンパイル 2. テスト 3. インスペクション 4. デプロイ 19
  • 30. ビルドの自動化 - 1.コンパイル コンパイル テスト インスペクション デプロイ  コンパイル手順の自動化  waf  autotools  make  rake  ant  (言語やプロジェクトに応じて選択) 20
  • 31. ビルドの自動化 - 2.テストの実行 コンパイル テスト インスペクション デプロイ  テストフレームワーク  Google Test, Boost.Test  (言語やプロジェクト、テストの種類に応じて選択)  テストの実行範囲が重要  迅速にフィードバックを得られるように、分類して実行範囲を絞る  段階的にテストを実施すると良い  軽量なテスト  単体テスト  重量なテスト  統合テスト/システムテスト/受け入れテスト/...  データベースのセットアップなどが必要になることも多い 21
  • 32. ビルドの自動化 - 3.インスペクションの実行(1/2) コンパイル テスト インスペクション デプロイ  ソースコードの静的解析・動的解析  コーディング規約違反の検出(cpplint)  コピペの検出  各種コードメトリクスの計測  クラス数  メソッド数  テストの網羅率(カバレッジ)  注意点  解析をして終わりにしない。何かしらの対処を行う  コーディング規約違反を直す  コピペは共通化できるなら直す  カバレッジが低いところを補強する 22
  • 33. ビルドの自動化 - 3.インスペクションの実行(2/2) コンパイル テスト インスペクション デプロイ  pficommonのカバレッジを測定してみた  gcc + gcov + lcov  スクリプト  https://gist.github.com/2643761  結果  http://eiichiroi.github.com/pficommon/  network...(^p^)...pull requestお待ちしております 23
  • 34. ビルドの自動化 - 4.デプロイ コンパイル テスト インスペクション デプロイ  ソフトウェアを利用可能な状態で提供すること  デプロイ対象のプラットフォームごとに  (テストやインスペクションの実施)  パッケージの作成  設定ファイルの準備  ...  継続的にデプロイまで行うのは割と大変  短期間でのリリースを行う場合はほぼ必須になる 24
  • 35. テスト 単体テスト 統合テスト システムテスト 受け入れテスト  テストのないコードはレガシーコード！  ソフトウェアの品質を担保するために必要  テストの分類(IEEE標準規格)  単体テスト  統合テスト  システムテスト  受け入れテスト  注意  組織によっては分類が少ないことも コンパイル 単体テスト 統合テスト システムテスト 受け入れテスト インスペクション デプロイ プライベートビルド コミットビルド 2次ビルド リリースビルド 25
  • 36. 単体テスト 単体テスト 統合テスト システムテスト 受け入れテスト  個々のコンポーネントに対して個別に行うテスト  コンポーネント 車の場合  関数 エンジン  クラス キャリブレータ 他のエンジン部品  ...ねじ？  テストする人 燃料モジュール 空気モジュール  各コンポーネントの開発者 ねじ1 ねじX 何か ねじ1 何か  優れた単体テスト  実行速度が速い(1テスト0.1秒では遅い)  問題箇所の特定がしやすい 26
  • 37. 単体テストの例: pficommon 単体テスト 統合テスト システムテスト 受け入れテスト 27
  • 38. 単体テストの例: pficommon 単体テスト 統合テスト システムテスト 受け入れテスト  文字列をbase64エンコードする関数  テストコード 27
  • 39. 単体テストの注意点 単体テスト 統合テスト システムテスト 受け入れテスト  単体テストではないもの  外部リソースに依存するテスト  データベース/ネットワーク/ファイルシステムにアクセスする  →モックオブジェクトなどで分離  細かいテクニックはレガシーコード改善ガイドを参照  ソフトウェアを変更するにはテストが重要  テストのない状況からテストを整備していく方法  依存関係を排除するテクニック集 28
  • 40. 統合テスト 単体テスト 統合テスト システムテスト 受け入れテスト  システムの一部を対象とするテスト  複数のコンポーネントが依存関係を持つテスト  外部リソースへ依存するテスト  データベース/ネットワーク/ファイルシステムにアクセスする 車の場合  テストする人  開発チームの人 エンジン  優れた統合テスト キャリブレータ 他のエンジン部品  網羅率が高い 燃料モジュール 空気モジュール  単体テストと統合テストの境界  ソフトウェアの規模による ねじ1 ねじX 何か ねじ1 何か  テストの実行時間が十分少ないときには分けないことも 29
  • 41. 統合テストの例: pficommon 単体テスト 統合テスト システムテスト 受け入れテスト  pfi::text::jsonのテスト  pficommon/src/text/json_test.cpp  粒度が粗めのテストが多い  pfi::data::serializationのテスト  pficommon/src/data/serialization_test.cpp  色んな型の変数をファイルへシリアライズしている  興味ある型はgithubを見てください 30
  • 42. システムテスト 単体テスト 統合テスト システムテスト 受け入れテスト  システム全体を対象とするテスト 車の場合  UIやAPIを経由してテストする 車  テストする人  テストチーム 駆動装置 HVAC 他の車体部品  優れたシステムテスト  幅広いテスト エンジン トランスミッション  機能/負荷/性能テストなど キャリブレータ 他のエンジン部品  統合テストとシステムテストの境界  ソフトウェアの規模によって変わる  何を「システム」と定義するか？サブシステムに分割することも  統合テストとシステムテストを合わせて結合テストと呼ぶことも？  組織によって違ったりしてカオス 31
  • 43. 受け入れテスト 単体テスト 統合テスト システムテスト 受け入れテスト  ユーザの要件を満たしているかどうかのテスト  アルファテスト  開発者側で行う受け入れテスト  ベータテスト  顧客側で行う受け入れテスト  ユーザビリティのテストなども行う  テストする人  顧客  顧客層を代表する人  顧客やソフトウェアのユースケースを良く理解している  優れた受け入れテスト  実環境とテスト環境が同じ  ハードウェア/ソフトウェア/データ/人 32
  • 44. まとめ  継続的インテグレーション  概要/流れ/価値/懸念点/導入  テスト  単体テスト/統合テスト/システムテスト/受け入れテスト  結論  継続的インテグレーションとテストは重要  検証コストの削減  常にデプロイ可能なソフトウェアを提供できる  修正/機能追加を自信を持って行える  段階的にでも良いので導入しましょう 33
  • 45. 参考文献  継続的インテグレーション入門  やや古くなっているが、まとまっている  Jenkins実践入門  Jenkins導入するなら  体系的ソフトウェアテスト入門  テストプロセス、テスト計画、テスト実行  レガシーコード改善ガイド  開発者は読むべき 34
  • 46. Copyright © 2006-2012 Preferred Infrastructure All Right Reserved.

Editor's Notes

  1. \n
  2. \n
  3. \n
  4. \n
  5. \n
  6. \n
  7. \n
  8. \n
  9. \n
  10. \n
  11. \n
  12. \n
  13. \n
  14. \n
  15. \n
  16. \n
  17. \n
  18. \n
  19. \n
  20. \n
  21. \n
  22. \n
  23. \n
  24. \n
  25. \n
  26. \n
  27. \n
  28. \n
  29. \n
  30. \n
  31. \n
  32. \n
  33. \n
  34. \n
  35. \n
  36. \n
  37. \n
  38. \n
  39. \n
  40. \n
  41. \n
  42. \n
  43. \n
  44. \n
  45. \n
  46. \n
  47. \n