Testing Casual Talks #2 @deme0607 大規模 Web サービスのブラウザテスト自動化・並列化

suzuki @suzuki

不適切な実行計画。並列の分散方法が違っていると片方が遊んでしまう場合もある。過去のテスト結果から、均等に終わるような実行計画になるように分散している。 #testingcasual

らんさぶ @gluelan2013

テスト結果の集計はもっとできるようになるべき #testingcasual

kaneko.y @spikeolaf

過去のtestケースの時間集計して、どう並列するか決めるのいいな #testingcasual

usadamasa @usadamasa

マシンリソースが余るのを防ぐために、過去のテスト実行計画を集計して均等に分散させる対応。 #testingcasual

suzuki @suzuki

今後の課題。データ作成APIの充実。分散ノードを動的に増やす仕組み。今は社内サーバ。クラウド化するとか考えている。 並列実行計画の改善・最適化 #testingcasual

broccoli @nihonbuson

不安定なテストを解析するという視点は興味深かった！ #testingcasual

usadamasa @usadamasa

テストの分散実行計画てどうやって振り分けてるんだろう。 #testingcasual

Wataru MIYAGUNI @gongoZ

似たような内容ですが、札束で召喚した Docker Host 上で並列実行して90分→9分にできたもの。どのコンテナにも同じテストデータ挿入したり、実行計画は test-queue に任せて無駄ない感じに #testingcasual slideshare.net/gongoZ/contain…

Naoki Umehara @numeha

SWETチームに入るにはいかさまさんに言うのが一番の近道 #testingcasual

クズ肉 @junkmeat

勉強になるなあ　#testingcasual

wataru kubota @wkubota

テストの自動化、並列化の話は同じことをみんな悩むんだなぁと。 自分はしょぼいアプリしか作ってないけど、同じ悩みを大規模サービスでも抱えているところに親近感湧いたり。 #testingcasual

みーつ⚡️ @qtkmz

テスト結果をきちんと分析している話が聞けてよかったなー。まずはテスト環境がそれなりにできていることが前提だと思うけれど #testingcasual

broccoli @nihonbuson

前に、他のイベントでは、実行時間の長い順に実行する方法が発表されてました。最後に長いテストを1台だけがやってる間、他のサーバーが待機する状況が無くせます "@usadamasa: テストの分散実行計画てどうやって振り分けてるんだろう。 #testingcasual"

broccoli @nihonbuson

テストエンジニアって、プログラミング能力と共に、分析・解析する力が必要になってくると思うんだ ただただテストするだけだと、モンキーテストと変わらない #testingcasual

kei @moikei

jenkinsのEC2plugin使ってspotインスタンスでslave機作ってる wiki.jenkins-ci.org/display/JENKIN… #testingcasual

みーつ⚡️ @qtkmz

テストデータを API で作れるのはいいな。テストデータを UI から作るものばかりだと辛いか・・・ #testingcasual

miyata @miyajan

APIが充実してくると、サーバー側が原因のバグのリグレッションテストはAPIテスト書けばいいなってなるのでおすすめ。 APIテストのほうがブラウザテストより圧倒的に高速で安定します。 #testingcasual

らんさぶ @gluelan2013

テスト自動化並列化は規模によらず同じ様な問題にぶつかっている その解決策は結局同じ様な所にそれぞれ落ち着いているのだろうか #testingcasual