DevLOVE現場甲子園 2013
現場甲子園
Software Engineer in Test
@ 楽天の検索基盤開発の現場
Nov/09/2013
恒太郎,
アビジート,
荻野 恒太郎 パランデ アビジート 松本 幹, 鵜飼 大志
Search Platform Group, Search Section, Big Data Department, Rakuten Inc.
http://www.rakuten.co.jp/
プロジェクト紹介

名称

Global Search Platform

目的

楽天の次世代サーチエンジンの開発
- 大規模&分散
- 検索結果の改善

チーム

- 日本
16 エンジニア
(外国籍 8)
- フランス 7 エンジニア
- ウォーターフォールではない何か

開発手法

2
開発チーム内の役割

・機能の開発
・単体~コンポーネントテスト
開発者

・テストの自動化
・結合テスト~システムテスト
Software Engineer
in Test

3
開発チーム内の役割

・機能の開発
・単体~コンポーネントテスト
開発者

・テストの自動化
・結合テスト~システムテスト
Software Engineer
in Test

→ テスト自動化のための
ソフトウェア開発者専門部隊
4
開発チーム
Component

Developer

Software Engineer in Test

Search
Indexer
Storage
Admin

5
開発チーム
Component

Developer

Software Engineer in Test

Search
Indexer
Storage
Admin
コンポーネントの結合
6
プロダクト

Global Search Platform
-

大規模
分散
複雑
バランサ

システム1

Admin

システム2

自動閉塞

データの一貫性
7
プロダクト

Global Search Platform
-

大規模
分散
複雑

コンポーネントの結合
= システムテスト

バランサ

システム1

Admin

システム2

自動閉塞

データの一貫性
8
システムテスト
自動化の
現場
by SET
9
ソフトウェア機能の世界
ソフトウェア機能の世界

10
ソフトウェア機能の世界

品質保証
11
ソフトウェア機能の世界

品質保証
12
ソフトウェア機能の世界

バグフリー

13
バグフリー
エリア
獲得の物語
14
Three walls

15
Three walls

① 再現性
② スモークテスト
③透過性
16
1st wall

① 再現性
② スモークテスト
③透過性
17
①テスト結果の再現性に問題があると
①テスト結果の再現性に問題があると
結果

18
①テスト結果の再現性に問題があると

①ある日テストが失敗

19
①テスト結果の再現性に問題があると

①ある日テストが失敗

②次の日成功
20
①テスト結果の再現性に問題があると

①ある日テストが失敗

③その次の日も成功

②次の日成功
21
①テスト結果の再現性に問題があると

④テストが失敗しても
気にならなくなる

③その次の日も成功

①ある日テストが失敗

②次の日成功
22
①テスト結果の再現性に問題があると

④テストが失敗しても
気にならなくなる

①ある日テストが失敗

Trust Dying Development

③その次の日も成功

②次の日成功
23
①テスト結果の再現性に問題があると

気にならなくなると数週間で当然
24
①テスト結果の再現性
①テスト結果の再現性
結果

・単体テスト

・システムテスト

フレームワーク

フレームワーク

Component

Component

Component

Component

Component

Component

Component

Component

Component

Component

25
①テスト結果の再現性
①テスト結果の再現性
結果

・単体テスト

・システムテスト

フレームワーク

フレームワーク

システムの状態管理
コンポーネントの初期化
状態遷移
Component

Component

Component

Component

Component

Component

Component

Component

Component

Component

26
①テスト結果の再現性

問題:
- 異常系のテストがゴミを残したり
(pidファイル、ゾンビプロセスとか)
- Timing issue
(コンポーネント間の通信、リトライ)
解決策:
- OSのインストール → インストール
- アンインストール → インストール
27
①テスト結果の再現性

28
1st wall

① 再現性
② スモークテスト
③透過性
29
2nd wall

① 再現性
② スモークテスト
③透過性
30
②スモークテストって?

もともとは
QAに入る前にQAチームが
開発チームからコードを受け取るかを
判断するためのテスト
自動化システムテストにおいては
最低限の機能 (データの投入、検索)のテスト
→ デプロイの確認

31
②スモークテスト

STGでのシステムテストを並列に実行していた...
Integration and System Test

Smoke
Test

Search

Crash

UT&Build

A Large
Data

Jenkins
32
②スモークテストを並列に実行する事によって生じた問題

機能がコンポーネント間で
複雑に依存している

ストレージ

インデクサー

API

サーチ
エンジン

アドミン

33
②スモークテストを並列に実行する事によって生じた問題

機能がコンポーネント間で
複雑に依存している

API

インデキシング機能

ストレージ

インデクサー

データ保存機能

サーチ
エンジン
検索機能

アドミン
デプロイ機能

34
②スモークテストを並列に実行する事によって生じた問題

機能がコンポーネント間で
複雑に依存している

API

インデキシング機能

ストレージ

インデクサー

データ保存機能

サーチ
エンジン
検索機能

アドミン
検索機能のテストが、
ストレージのバグで失敗

デプロイ機能

低レイヤのバグは
すべてのテストに影響

35
②解決策
Integration and System Test

- スモークテストを
パスしたバージョン
のみ以降のテスト
を実行するように
変更
- Jenkinsによって
自動化

No

No
Pass

Pass
Yes

Smoke
Test

Search

Crash

A Large
Data

Version

UT&Build

Build

Yes

Jenkins
36
②スモークテストの意味の変化

解決前
- End to End での最低限の機能を検証
→ デプロイの確認
解決後
- コンポーネントの結合を最低限保障
→ テストレディである事を確認
→ コミットレディである事を確認

37
2nd wall

① 再現性
② スモークテスト
③透過性
38
3rd wall

① 再現性
② スモークテスト
③透過性
39
③透過性

もともとの動機:
STGで失敗したテストをローカルの開発PCでも
再現させたい
よくよく考えてみると :
TDDは以下の事が単体テストで可能な事を
前提としている (xUnit, CI Tool, SCM)
- 開発PCでテストを実装
- 開発PCで機能の実装
- 開発PCでテストを実行
- コミット
- 共有環境でのビルド
40
③透過性
developer

dev

Local
Implement

UT

開発者
ローカルの開発マシンで開発
単体テストを実行
コードのコミット

Pass

merge
GIT

41
③透過性
developer

dev

Local
Implement

Implement

UT
UT

Crash

Search

Smoke
Test
Pass

Pass

merge

merge

GIT

GIT

開発PCでもすべての
テストシナリオを実行可能に!

42
③透過性

- Vagrantで共通の開発&テスト環境
を配布
- Ngauto (テストフレームワーク)が
環境差異を吸収してテストシナリオを実行
スモークテストの実行

$ vagrant up
$ sh SMOKE.sh
43
③透過性

TDD
システムテストレベルで!!
44
3rd wall

① 再現性
② スモークテスト
③透過性
45
開発プロセス
46
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
Q&A形式
形式
小噺
48
一回頑健な壁を
築けたら
もうやる事ないね

49
A Space for Software Features

自動化再帰テスト
→ バグフリーエリアの確保

50
A Space for Software Features

自動化再帰テスト
→ バグフリーエリアの確保
探索的テストの自動化
→ バグフリーエリアの拡大
51
壁が破壊される事って
ないの??
ないの??

52
Break the Walls

Refactoring
やるぜ!!

53
The First Wall

コミットの前に開発
マシンでテストする
というのは紳士協定なので
ものすごく簡単に
第一の壁は突破される 笑

54
The First Wall

テストシナリオは透過的に
実行可能なので、
1人が壊したら、
ローカルPC、STG問わず
テストが壊れる

55
The Second Wall

第二の壁=SmokeTestが
突破されるとホントにヤバイ
→ 他のテストが失敗する
→ フレームワークの開発がとまる
→ テストの追加がとまる

56
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
破壊された壁の
強化ってするの?

58
The Second Wall

Smoke Testを長期間壊すような
極悪なバグの場合壁の強化が必要

59
The Second Wall

Smoke Test
Testのテストケースに
明示的に追加し成仏してもらう
もともと
- データの投入・検索
後から追加
- 日本語処理・平行性

60
The Second Wall

Smoke Testは実行時間と
カバレッジのバランスが大事

テスト実行時間

バグ発見数/ テスト実行時間

61
座標って何?

62
Break the Walls

座標??
63
秘密です

64
SETは壁破壊する事
は壁破壊する事
ないの?

65
Break the Walls

フレームワークの
拡張やるよ

66
Break the Walls

結局のところ自動化のみで
問題を解決していくのは困難
→開発文化も高めないとね
“コミットする前にテストを実行!”

67
まとめ
68
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
Automation

you
71

【DevLOVE現場甲子園2013】Software Engineer in Test @ 楽天の検索基盤の現場