Download as PDF, PPTX
Uploaded byHiro Yoshioka
テスト勉強会よしおか100311 1
大規模ソフトウェア開発におけるディリービルド＆リグレッションテストについて。 OracleやDECにおける経験を話します。Samba3.0国際化のプロジェクトの経験も紹介します。
More Related Content
テスト勉強会よしおか100311 1
- 1. よしおかひろたか テスト勉強会 楽天株式会社 開発部 アーキテクトGよしおかひろたか ｜ 2010年3月12日 1
- 2. よしおか 本日のメッセージ 開発者の皆さん、 テストを書こう テストを書く＝テストコード＋入力データ＋期待する出力デー タ Excelでテストケースを作ることではない。 2
- 3. アジェンダ • 大規模ソフトウェア開発におけるディ リービルド＆リグレッションテスト 3
- 4. 自己紹介 • 開発部、ACT課アーキテクトG、技術理事 よしおかひろたか • 2009年8月入社 • カーネル読書会の主宰者、DEBUG HACKS共著 ISBN978-4-87311-404-0 • twitter @hyoshiok http:// d.hatena.ne.jp/hyoshiok 4
- 5. わたしの経験から • 大規模ソフトウェア開発の現場の経験をお 話する。 – ソフトウェア製品開発は受託開発とは相当異な る。 • 事例： – Oracle8の開発現場 – DEC Rdbの日本語化、国際化 – 日本語COBOL – Samba3.0国際化対応（オープンソースの場合） 5
- 6. Oracleの場合 • 開発環境 • 開発プロセス • プログラマの日常 • リズム • チェックアウト、チェックイン • ディリービルド • リグレッションテスト • 学んだこと 6
- 7. Oracle 8の場合 • わたしが参加した時期、1995年～2000年 •Oracle8/8iあたりのころ • 開発環境：Sun Workstation、SunOSから Solaris • Clearcaseベースの開発環境。 – ファイルの仮想化。一人で複数のブランチを同 時に持てる。 • 例えば、Oracle 7.3用、Oracle 8用、Oracle 8.1用。バグ 修正、機能ごと、ちょっとした確認用などなど • check-outしたものはcheck-inするまで他の人には見え ない。 7
- 8. 開発プロセス（Oracleの場合） • 要求仕様作り（開発者） – 外部API、UIなどを決定する。 • 例：SQLのシンタックス、セマンティックスを定義する。 – リファレンスマニュアルのベースになる。 • 設計（開発者） – APIなどを決定したら、設計＆実装になる。 • 実装（開発者） – コードを書く、テストを書く、テストをする • ディリービルド＆リグレッションテスト（自動） – チェックインされた最新のコードをスクラッチからビルドして、リグレッションテ ストを実行。 • チェックインしたコードの概要と、テスト結果の概要が日々担当者にメールで送られる • 常に動くコードが毎日ある。 • 安定化プロセス – フィーチャーフリーズ（機能追加を凍結する） – コードフリーズ（重大なバグフィックス以外のチェックインを認めない） 8
- 9. ソフトウェア製品開発のプログ ラマ • 設計者が実装者でテストも書く • 一つの機能については、すべて知って いる。 • コーダーという人がいるわけではない 。 9
- 10. プログラマの一日 • 朝会社に来る。 • コーヒーでも飲みながら、メールをチェックする。 – 担当のテストを確認する。 • 自分が昨日チェックインしたコードがリグレッションテストを壊していないか。 • 他の人のチェックインが、担当テストを壊していないか。 • 壊れている場合は、調査する。あるいは調査を依頼する。 • 仕掛の作業を行う。 – コードを書いたり、テストを流したり、あれやこれや。 – 全テストを流すと時間がかかるので、サブセットを流す – コードが安定したら当該ブランチの最新版にマージする • 自分の環境で動作確認ができたら、 – 同僚にレビュー依頼をして、コメントをもらう。特に問題がなさそうの場合、リリ ースマネージャーにチェックインの許可をもらう。 • 許可が出たら、チェックインする。 – 次の日はどきどきしながらリグレッションテストの結果を見る • 休暇の前に確認しないでチェックインをするな、という不文律 – http://d.hatena.ne.jp/hyoshiok/20040516#p1 10
- 11. リズム • チェックアウトして • コードをいじって、テストを書いて、 •テストを実行して、OKになるまで繰 り返して、 • 同僚にレビューしてもらって、 • リリースマネージャに許可をもらって 、 • チェックイン 11
- 12. チェックアウト、チェックイン • 複数のブランチを同時にいじっている • バージョンがいくつか •それぞれについて、バグフィックス、 機能変更、機能追加、機能ごとに別々 のブランチを切っておく。 • 最新のバージョンでバグフィックスし たものを昔のバージョンに適用するこ ともある。（バックポート） 12
- 13. ディリービルド • 毎日大量のチェックインがある。数十 ～ • 最新のソースからビルドする。 – コンパイルエラーが出るチェックインは 無条件にロールバックされる。 – 複数のビルドマシンで分散ビルド • 安定性に差こそあれ常に動くものがあ る。 – Oracle8の最初のビルドは前バージョン (Oracle 7.3)と同一。ここから始まる。 13
- 14. リグレッションテスト • ディリービルドされた最新の実行イメージ でリグレッションテスト（数千）を実行す る – 10数台（？）のサーバーマシンで何時間もかか る。 – テストコード、入力データを与えて、期待する 出力と実際の出力の差分を見る – diff（差分）が出たらそれを目視確認する。期待 する結果なのか、いなか。 – 新機能追加、バグフィックスの場合は対応する テストの追加、修正などを行う。 – リグレッションテストがあるので、既存の機能 の予期しない影響がすぐにわかる。リグレッシ ョンの発見。 14
- 15. 安定化プロセス • あるクライテリアで、安定化プロセスに入 る。 – 新機能の追加を凍結する（feature freeze)期間に 入る – バグ修正だけを行う – リグレッションテストのdiffの数を減少させる – テストの追加、実行だけをやって、製品の安定 化を図る。 – あるクライテリアで、重大なバグ修正以外は一 切変更を認めない(code freeze)期間に入る。 – バグ（不具合）はリリースノート等に記載し出 荷する 15
- 16. 学んだこと • ディリービルドによって、常に動作が確認されてい るものがある。 – どの機能が実装されていて、どの機能が実装されていない かが一目でわかる – 実装すべき機能のプライオリティが変更になったとしても 、すぐに対処可能 – スケジュールが遅延した場合、どの機能を落とすかの判断 が容易に可能。（どれが動いているかいないかを把握でき ているので） • 大規模ソフトウェア開発において俊敏性を高めるベ ストプラクティスで、ソフトウェア製品開発では広 く利用されている。（例：マイクロソフトのOS開 発など） • 闘うプログラマー http://books.rakuten.co.jp/rb/6130084/ 16
- 17. DEC Rdbの日本語化、国際化 • ソフトウェアの日本語化プロセス •ビルド環境って • インターネット以前のソフトウェア開 発 • 学んだこと 17
- 18. DEC Rdbの場合 • ソフトウェアの日本語化プロセス – 米国本社で開発されたソフトウェアを日本で日 本語化した。（別のバイナリーになる） • 1980年代後半のころ • 参加人員：日本側開発者3名～。US側は100名前後 • 開発環境の入手 – ソースコードの入手 – ビルドスクリプト – テスト環境 • 開発環境構築 – VAX/VMS、OSの違い、コンパイラの違い、その他ツールの違 いなどなどで一筋縄では行かない場合も • 実際の開発 – ビルド＆リグレッションテスト 18
- 19. ビルド環境 • 開発環境を日米で完璧に一致させることは 難しい – もちろん仮想化環境などはない。ツール、コン パイラ、OSのバージョン • 社内ネットワークはあったが回線が細い – 100MBをコピーするのに足掛け3日とか • リグレッションテストの結果を確認するの が難しい。（開発環境が微妙に異なるので ） – 安定化させるのに2~3ヶ月かかることも。 19
- 20. インターネット以前のソフトウ ェア開発 • 大規模分散開発だったのだけど、 – 社内ネットワークの帯域は細かった – コミュニケーションは、メール、電子掲示板（VAX Notes） • 最終的には、本社に乗り込んで、ソースコードをマ ージした（1990年ごろ） • DECはOS（VMS）、ハードウェア(VAX)、ミドルウ ェア(Rdb)、コンパイラ、ツール、その他すべて内 製品。垂直統合型企業 • SQA (Software Quality Assurance)という部隊があっ た。 – OS/HW/ミドル：各レイヤーの互換性をリグレッションテ ストで確認 20
- 21. 学んだこと • 米国本社のエンジニアと一緒に働いた • すごいエンジニアがいっぱいいた •ソフトウェア国際化のあるべき姿につ いてとことん議論できた • 大規模広域分散ソフトウェア開発のイ メージが持てた 21
- 22. 日本語COBOLの場合 • 非力なマシンでのソフトウェア開発 • コード管理システム、モジュール管理 システム、テスト管理システムなどの お話 • バグ管理 • エンジニアのイロハを教えてもらった • 学んだこと 22
- 23. プロジェクト概要 • 日本語COBOLの開発 – 1984年～ – 3人（自分は新卒プログラマ） – 開発環境、VAX/VMS – 言語：BLISS、SCAN（独自の言語） • コード管理システム、モジュール管理 システム、コンパイラ、テスト管理シ ステム、バグ管理システム、すべて自 社製 23
- 24. • 夜中の0時に、ビルドのバッチが動き出し、 その後テストを実行する。 – チェックインしたファイルのdiffをメールするよ うにした。 – 見よう見まねで、makeファイルを書いた。 – テストスクリプトもテスト管理システムを利用 して書いた。テスト結果もメールした。 • チェックインの数、発見したバグの数、修 正したバグの数などをグラフにすると、週 単位での進捗が見えた。 24
- 25. バグ管理 • テストプログラムは、自分以外が実装 した分について書いた。(他人のコー ドをテストする） • 発見したすべてのバグはバグデータベ ース（自作）に登録した。 – 110件くらいバグを発見したと思う。 – バグの分析などもした。3割くらいが未実 装。 25
- 26. エンジニアのイロハを教えても らった • マニュアルを読むこと • テストを書くこと • デバッグの仕方 • 質問の仕方 26
- 27. 学んだこと • 社内にはすごい人がいっぱいいる • 自分もそうなりたい • ソフトウェア開発プロセスのイロハ • 大規模分散開発のイメージ（未来像） • ソフトウェア国際化のイメージ（未来 像） 27
- 28. Samba3.0国際化対応の場合 • オープンソースとコミュニティの対応 • 新参者がコミュニティに入るには • プロジェクトの流れ • オープンソースの都市伝説 • プログラマの日常 • リズム • 学んだこと 28
- 29. Samba3.0国際化 • プロジェクト概要 –Samba2.xは日本人コミュニティが開発した日本 語パッチがあったが、Samba3.0になって、内部 コードがUnicodeになったため当該パッチが利用 できなくなりShiftJIS関連の問題が発生した。 – Unicode対応、テストの追加など – 2003年ごろ – http://www.miraclelinux.com/technet/samba30/index.html – http://d.hatena.ne.jp/hyoshiok/20041022 29
- 30. オープンソースとコミュニティ • 高い技術力とdisciplineを持ったハッカーによ って構成されている – 企業の開発者は企業の利益拡大 – 企業の開発者とコミュニティのハッカーの利害 が一致するとは限らない。しばしば相反する。 • パッチを送ったからといって受け入れられ るとは限らない。 – 技術的な問題というより、しばしばコミュニケ ーションの問題だったりする 30
- 31. 新参者がコミュニティに受け入れら れるには • 何の実績もない人が受け入れられるには – 技術の問題ではなくコミュニケーションの問題だと認識し た • Samba-jp（日本のコミュニティ）とSambaのコミュニティの 関係。両方に受け入れられる必要がある。 – テストをどんどん作って、発見した問題をバグデータベー スにどんどん登録した。チームのメンバーは個人名で登録 。 – ついでにパッチなども投稿した。個人名で投稿。 – 直接会って話したり、メール、チャット、電話会議などで 、プロジェクトの紹介などを行った。 – コミュニティにデビューするには、自分たちの技術力を理 解してもらう必要がある。バグフィックスは最初の一歩。 – 大きなパッチをいきなり送るのではなく、小さいバグフィ ックスの積み重ねで、徐々に信頼を得ていく。 31
- 32. プロジェクトの流れ • ディリービルド、リグレッションテストの開発環境を準備し た。 • Sambaのテストフレームワークを利用し – テストケースの作成 – テストコードの作成 – テストの実施 – 不具合をbugzillaに登録 – 修正パッチを投稿 • 機能追加、修正などのパッチを適宜投稿。本家にマージして もらう。 • 英語のホームページ、ドキュメントなども用意した • フェースツーフェースの会議、メール、チャット、電話など 様々な方法をとった 32
- 33. オープンソースの都市伝説 • ハッカーは無法者？ –極めて高い技術力とdiscipline（規律）を 持つ – コミュニティの価値を大切にする – プロフェッショナルである 33
- 34. プログラマの日常 • やることリストの確認 • Bugzillaのチェック • テストの追加 • パッチの作成 – リグレッションが起こっていないことを 確認 – 新機能が実装されていることを確認 • コミュニティへ投稿 – メーリングリスト、電話、チャット、な どなど 34
- 35. リズム • 作成したテスト数が見える • バグの数が既知 – 最初にテストがあるので、そのテストで 発見した数が初期値になる – Samba3.0は今ここにあるが国際化の機能 がない。（バグの数＝実装すべき機能） • バグの数を減らしていくのがリズム 35
- 36. 学んだこと • OSSもテストファーストできた • 何をやりたいかをテストで表現した WHAT • テストを作ることによってオリジナル 製品の挙動を深く理解した • プロジェクトマネージャーとして、プ ロジェクトの進捗が、テストの進捗、 残バグ数によって見える化されている ので、安心。 36
- 37. ちょっとした思い • プロフェッショナルって • 変化を許容すること •プログラマに必要な３つのチカラ 37
- 38. プロフェッショナルについて • ソフトウェアは人が作る –自分がプロフェッショナルになるしかな い… – アスリートが毎日トレーニングしている ようにわれわれはトレーニングをしてい るだろうか 38
- 39. 変化を許容することについて • 環境は変化する • 自分は変化しているだろうか •成長しているだろうか 39
- 40. プログラマに必要な３つのチカ ラ • ソースコードリーディング • テスト • デバッグ • ワークショップや勉強会を開催してい きたい～～～ 40
- 41. 経験則 • テストを書かない プロフェッショナルはいない （プログラマ的な意味で） • テストのないコードは レガシーコードだ。 • 読書会しましょう～ レガシーコード改善ガイド 保守開発のためのリファクタリング、翔 泳社 http://books.rakuten.co.jp/rb/6121689/ 41
- 42. • 公理１：すべてのプログラムは テストをしなければいけない。 • では、どうテストをするか – A：人がやる – B:テストコードを書いて、それを実行す る – 正解：B – 証明：自明。 42
- 43. テストを作ると • システムの振る舞い(WHAT)を 記したことになる – テストを作ることによって、システムの 深い理解を得られる – 安心感を得られる（心の平静を保てる） 43
- 44. テストがあると • 変更の影響が即座にわかる –影響範囲がわからなくて、 塩漬けではなく、 どんどん積極的に変更できる ＞変更容易性、アジリティ向上 – 安心である。（心の平静が保てる） 44
- 45. テストがあると • 機能を確実に実装したことを 確認できる。 – 手作業による確認は、もれやミスが発生 する。コストが高いし、なにより楽しく ない。 – 機械が実行してくれるので、楽である。 – 安心である。 （心の平静が保てる） 45
- 46. テストがあると • 変更容易性があがり、 運用コストが下がる – OSやHWなどシステムを変更したときも 、その影響がすぐにわかる – 安心である。 （心の平静が保てる） 46
- 47. レガシーコード改善ガイド読書 会 • レガシーコード改善ガイドを読む • 世話役：アーキテクトGよしおかひろたか • 日程：木曜日、19時～20時30分ころ • やり方：分担で、説明して、参加者による 議論 • ペース：一回あたり60ページくらい進みた い。7回程度で全部を網羅したい • レガシーコードを改善して楽をしよう ご参加 おまちしてます 47
- 48.
- 49.