Testing Casual Talks #2 @deme0607 大規模 Web サービスのブラウザテスト自動化・並列化
-
- いいね！0
Naruhiko Ogasawara
@naru0ga
遅いからってテストケースを削減すると回帰テストとして意味がないよね＞並列実行 #testingcasual
2015-05-25 20:19:58
suzuki
@suzuki
並列実行に必要なこと。並列実行している処理が互いに衝突しないようにする。片方でインストールしていて、片方でアンインストールするとか。 #testingcasual
2015-05-25 20:20:48
suzuki
@suzuki
テスト実行ノードごとに専用のサービス実行環境を用意。Docker / Vagrant をつかうとか。 #testingcasual
2015-05-25 20:21:24
Naruhiko Ogasawara
@naru0ga
並列においてはテストケース間の衝突が起こらないようにするための工夫が大事！ですよね！！ #testingcasual
2015-05-25 20:21:25
joker1007 (アルフォートおじさん)
@joker1007
ブラウザテストを並列させるのって札束でノードを増やすしか無いよねえ。VM/コンテナをガンガンつくって潰すという手段もあるけど。 #testingcasual
2015-05-25 20:21:59
suzuki
@suzuki
この問題点。環境構築コストが大きい。環境依存の問題に気付けない。ロードバランサとかドメインとか。本番データでしか発生しない問題など。 #testingcasual
2015-05-25 20:22:26
Naruhiko Ogasawara
@naru0ga
テスト間で環境を分けるってのがすぐに思いつく解だけど、それは結局実環境でテストしてないってそれ最初のトークと同じテーマだ #testingcasual
2015-05-25 20:22:37
suzuki
@suzuki
並列化のアプローチ。専用データの用意。テスト毎に各テスト専用のデータを用意。テスト実行ノードは複数あり、DBはひとつ、のような構成。 #testingcasual
2015-05-25 20:23:26
suzuki
@suzuki
NBPF のテスト並列化。全データソースの API 化はできていない。DB 操作はリスクが大きい。サービスの UI 経由でユーザを事前作成。WebDriver を利用。UI 経由だと時間がかかってしまうデメリット。。 #testingcasual
2015-05-25 20:27:12
suzuki
@suzuki
データが分かれているので、バッティングしないのだが、仕様変更に弱い。実環境にテスト用データを用意するのは良いが、これをメンテするときが怖い。 #testingcasual
2015-05-25 20:24:18
Naruhiko Ogasawara
@naru0ga
DB触ってテスト用にそれぞれのノード用のデータを作るアプローチ。実環境のDB触るのはいろいろ怖い #testingcasual
2015-05-25 20:25:27
suzuki
@suzuki
テスト毎に API で専用データを作る方法。DB を直接触る形ではないので怖さは減る。サービスとテストで同じ API を使うべき。ただ、そのAPI がない場合は導入コストが高い。 #testingcasual
2015-05-25 20:25:39
Naruhiko Ogasawara
@naru0ga
APIを使うのが筋がいいけど既存サービスにAPI生やすの却ってコストになるしなあというあるあるな話 #testingcasual
2015-05-25 20:27:22