【DevLOVE現場甲子園2013】Software Engineer in Test @ 楽天の検索基盤の現場
•
3 likes•1,555 views
DevLOVE現場甲子園で発表したスライドです
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 【DevLOVE現場甲子園2013】Software Engineer in Test @ 楽天の検索基盤の現場
Similar to 【DevLOVE現場甲子園2013】Software Engineer in Test @ 楽天の検索基盤の現場 (20)
【DevLOVE現場甲子園2013】Software Engineer in Test @ 楽天の検索基盤の現場
- 1. DevLOVE現場甲子園 2013 現場甲子園 Software Engineer in Test @ 楽天の検索基盤開発の現場 Nov/09/2013 恒太郎, アビジート, 荻野 恒太郎 パランデ アビジート 松本 幹, 鵜飼 大志 Search Platform Group, Search Section, Big Data Department, Rakuten Inc. http://www.rakuten.co.jp/
- 2. プロジェクト紹介 名称 Global Search Platform 目的 楽天の次世代サーチエンジンの開発 - 大規模&分散 - 検索結果の改善 チーム - 日本 16 エンジニア （外国籍 ８） - フランス 7 エンジニア - ウォーターフォールではない何か 開発手法 2
- 4. 開発チーム内の役割 ・機能の開発 ・単体~コンポーネントテスト 開発者 ・テストの自動化 ・結合テスト~システムテスト Software Engineer in Test → テスト自動化のための ソフトウェア開発者専門部隊 4
- 5. 開発チーム Component Developer Software Engineer in Test Search Indexer Storage Admin 5
- 6. 開発チーム Component Developer Software Engineer in Test Search Indexer Storage Admin コンポーネントの結合 6
- 8. プロダクト Global Search Platform - 大規模 分散 複雑 コンポーネントの結合 = システムテスト バランサ システム１ Admin システム2 自動閉塞 データの一貫性 8
- 15. Three walls 15
- 16. Three walls ① 再現性 ② スモークテスト ③透過性 16
- 17. 1st wall ① 再現性 ② スモークテスト ③透過性 17
- 27. ①テスト結果の再現性 問題： - 異常系のテストがゴミを残したり (pidファイル、ゾンビプロセスとか) - Timing issue （コンポーネント間の通信、リトライ） 解決策： - OSのインストール → インストール - アンインストール → インストール 27
- 28. ①テスト結果の再現性 28
- 29. 1st wall ① 再現性 ② スモークテスト ③透過性 29
- 30. 2nd wall ① 再現性 ② スモークテスト ③透過性 30
- 32. ②スモークテスト STGでのシステムテストを並列に実行していた．．． Integration and System Test Smoke Test Search Crash UT&Build A Large Data Jenkins 32
- 36. ②解決策 Integration and System Test - スモークテストを パスしたバージョン のみ以降のテスト を実行するように 変更 - Jenkinsによって 自動化 No No Pass Pass Yes Smoke Test Search Crash A Large Data Version UT&Build Build Yes Jenkins 36
- 37. ②スモークテストの意味の変化 解決前 - End to End での最低限の機能を検証 → デプロイの確認 解決後 - コンポーネントの結合を最低限保障 → テストレディである事を確認 → コミットレディである事を確認 37
- 38. 2nd wall ① 再現性 ② スモークテスト ③透過性 38
- 39. 3rd wall ① 再現性 ② スモークテスト ③透過性 39
- 40. ③透過性 もともとの動機： STGで失敗したテストをローカルの開発ＰＣでも 再現させたい よくよく考えてみると ： ＴＤＤは以下の事が単体テストで可能な事を 前提としている （xUnit, CI Tool, SCM） - 開発PCでテストを実装 - 開発PCで機能の実装 - 開発ＰＣでテストを実行 - コミット - 共有環境でのビルド 40
- 43. ③透過性 - Vagrantで共通の開発＆テスト環境 を配布 - Ngauto (テストフレームワーク)が 環境差異を吸収してテストシナリオを実行 スモークテストの実行 $ vagrant up $ sh SMOKE.sh 43
- 45. 3rd wall ① 再現性 ② スモークテスト ③透過性 45
- 46. 開発プロセス 46
- 47. Development Process developer dev SET Local Dev Integration and System Test Implement No UT No Yes Pass Pass Yes Crash Search Smoke Test Smoke Test Search Crash Pass merge GIT clone Version UT&Build Build Jenkins A Large Data Manual System Test
- 48. Q&A形式 形式 小噺 48
- 50. A Space for Software Features 自動化再帰テスト → バグフリーエリアの確保 50
- 51. A Space for Software Features 自動化再帰テスト → バグフリーエリアの確保 探索的テストの自動化 → バグフリーエリアの拡大 51
- 56. The Second Wall 第二の壁=SmokeTestが 突破されるとホントにヤバイ → 他のテストが失敗する → フレームワークの開発がとまる → テストの追加がとまる 56
- 57. The Second Wall Smoke Testによる バージョンの管理は 時間稼ぎにも有効 →時間稼ぎ中に修正 Integration and System Test No No Smoke Test Search Crash A Large Data Version UT&Build Build Yes Pass Pass Yes Jenkins 57
- 59. The Second Wall Smoke Testを長期間壊すような 極悪なバグの場合壁の強化が必要 59
- 60. The Second Wall Smoke Test Testのテストケースに 明示的に追加し成仏してもらう もともと - データの投入・検索 後から追加 - 日本語処理・平行性 60
- 61. The Second Wall Smoke Testは実行時間と カバレッジのバランスが大事 テスト実行時間 バグ発見数/ テスト実行時間 61
- 62. 座標って何？ 62
- 64. 秘密です 64
- 68. まとめ 68
- 69. Development Process developer dev SET Local Dev Integration and System Test Implement No UT No Yes Pass Pass Yes Crash Search Smoke Test Smoke Test Search Crash Pass merge GIT clone Version UT&Build Build Jenkins A Large Data Manual System Test
- 70. まとめ 大規模分散システムの開発 システムテスト自動化＝コンポーネントの結合 テクニック - テスト結果の再現性 - スモークテスト - シナリオ実行の透過性 今後： 探索的テストにチャレンジ 70