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