雑文発散
2015-05-25 [長年日記]
▼ [雑] Testing Casual Talks #2 へ参加してきた
Testing Casual Talks #2 へ参加してきた。前回（初回）は2年前くらいに開催されていたそうだ。その時は行っていないので、気付かなかったんかなー。
mruby のテスト方法についての試行錯誤
GMO ペパボで ngx_mruby の記述をテストするために実行してきた内容のお話。
まだ自分では Nginx の config が複雑怪奇になるところまでは書いていないのだけど、設定を mruby で書いて、しかもそれをテストできるという状態はとても気持ち良さそう。
いまやサーバ構築はテストできるし、アプリケーションももちろんテストできる。ただ、その間にあるミドルウェアに関しては、テストすることがうまくできていないという言葉を聞いて、そういう視点では考えたことなかったなーと、目からウロコ。
最近また少し自分でも Chef のレシピを書くようになった（Elasticsearch とか！）けど、そこで作ったサーバの動作テストは、たしかにポチポチと手動でやっているなぁ。curl -X 'http://localhost:9200/_cat/nodes' とか cat API を叩いたりして。
LTの「Casualにインフラテストへ入門した話」でもその辺の話題は出てきていて、Infrataster で振る舞いテストする話があった。
サーバ構築、アプリケーション開発でのテストについては知識も経験も多少はあるので、今度はミドルウェア領域のテストも試してみたい気持ちになった。
あと、GMO ペパボでは各種エンジニアを募集しているそうだ。
スクラム開発において、テストメンバー(非開発者)の関わり方を模索してみた
スクラムチームに QA が入るという話。以前の職場では、同じように開発段階から QA チームが入る体制を作った経験があったので興味深かった（ただし、そのときはスクラムで動いていたわけじゃない）。
8週間のプロジェクトをプロダクトオーナーが1名、スクラムマスターが1名、開発エンジニアが3名、QA エンジニアが1名というチームでスクラムを回したそうだ。社内でのスクラム事例2つ目で、スクラムマスター以外は初めてのスクラムということで、だいぶチャレンジングな様子。でも、そういう活動をしていくのは良いよなぁ。
さらにこのスクラムでチャレンジしたのが、開発チームの中に QA エンジニアを組み込んだことで、従来のウォーターフォール的 QA ではなく、アジャイル的 QA を実施してみたそうだ。その結果、仕様策定時の考慮漏れや矛盾点が QA から指摘することができ、早い段階での問題解決に繋がったメリットがあったとか。
一方でうまく行かなかった点として、スプリントで完了させる予定の機能のテストが、そのスプリント内に収まらない（終わらない）状態になってしまったそうだ。開発エンジニア3名の進行と、QA エンジニア1名の進行だと、そのスピードに差異が出てくることまでうまく考慮しきれていなかった可能性を言っていた気がする。
KPT での良かったところは、やはりスプリント内に QA プロセスが入ることで早期の問題解決ができるのが良かったとのこと。うまくいかなかったところは、先ほどの期間的な問題もあり、正常系テストが中心になり、異常系テストまで辿り着かなかった点があったそうだ。あとは、この機能とこの機能は一緒にやった方がいいみたいな待ちが発生してしまったりだとか。
今後は、テストのやり方を改善し、ユーザーストーリーごとのテストで待ちを解消したり、問題点のフィードバックを更に早くすることを試してみたいと言っていた。
前職で QA チーム作ったり、現職でスクラム初心者をしてたりするので、なんか親近感の湧くお話だった。
あと、ガイアックスでは、QA エンジニアを募集しているそうだ。
大規模 Web サービスのブラウザテスト自動化・並列化
ブラウザテストなので、Selenium の話かな？と思ったら Selenium の話だった。
DeNA には SWET (SoftWare Engineer in Test) というチームがあり、ゲームプラットフォームの品質保証や向上、また、開発のテスト環境の向上などを行なっているそうだ。今回は、その SWET が NBPF (Next Browser PlatForm) という次世代ブラウザゲームプラットフォームへのブラウザ自動テスト環境を構築・運用してきた話。
Selenium WebDriver と Ruby / RSpec / Capybara、そして Jenkins を組み合わせて自動テスト環境を構築したそうだ。
ブラウザ自動テストを作成することで、基本的なテストケースは自動化し、人間がやならなければならないテストに工数を割くことができるようになる。そこが大きなメリット。従来の機能は自動テストで済ませ、新機能や UI/UX などの検証に注力できる。
ただし、ブラウザ自動テストは遅い。遅いからと言って、テストの削減をするのは本末転倒なので、並列化によるスピードアップを図るという話。
並列化のパターンとしていくつかあげていた。
- テスト実行ノードごとに専用のアプリ稼働サーバのを立てる
- 実環境にテスト実行ノードごとのテスト専用データを（手で？）入れてそれを使う
- 実環境にテスト実行ノードごとのテスト専用データをデータ投入用のAPIを使ってそれを使う
- ユーザーが実際に使う UI を操作して、テストデータを作る
1 だと完全に環境が分けられるので並列化は楽なのだが、環境依存の問題に気が付きにくいのだとか。例えばロードバランサの有無による動作の違いとか、ドメイン名、本番データでしか発生しない何か、など。
2 の場合は、環境の違いは発生しないメリットがあるし、データをテスト実行ノードごとに分けているので、並列化もしやすい。ただ、このやり方は仕様変更に弱いとか。仕様変更の度に手作業でテストデータを追従させないといけない。また、本番環境を手で触るのも怖い。
3 の場合は、環境の違いも仕様変更への追従も問題が無いのだけど、大規模なサービスなので、そういった API が存在しないシステムもあり、「そのシステムへ API を作成する」となると、それはそれで工数がかかってしまい、なかなか進まない。
ということで、現状は（API がない場合には？） 4 を選択しているそうだ。ユーザーが使う UI を Selenium WebDriver で操作して、例えばアカウントを作ったりしているそうだ。テスト実行ノードごとにこれを行えば、それぞれ別のアカウントになるので、並列化によるバッティングも起きない。
これらの方法を使ってブラウザ自動テストを 8 並列とし、これまで 2.5 時間かかっていたテストが 0.5 時間で終わるようになったそうだ。
とはいえ、ブラウザ自動テストはテストが不安定なので、地道に改善しているそうだ。「いつもテストが落ちている」状態だと本当にヤバイ問題で落ちた時に気付かなくなるおそれがあるため。
また、そういう状態を避けるために「不安定なテスト」を把握する工夫をしているそうだ。テスト結果を収集する API を作り、「よく落ちるテスト」や「突然落ちるようになったテスト」などを検出し、その検出結果を Slack へ流している。「この通知が来たらヤバイ」という文化を作って対応されているとのこと。
また、各ノード・各テストの実行時間もプロットしていて、テスト実行計画の最適化にも取り組んでいるのだそうだ。あるノードは実行時間が長く、別のノードはさっさと終わっているという状態だと、遊んでいるノードがもったいない。そういう場合は、各ノードで行うテストケースの割り当てを変更し、「最も短い時間で全テストが終了する」という状態へ持っていくそうだ。
今後の課題としては、そういう「テスト実行計画の最適化の自動化」を目指したり、先ほどの 3 にあった API の拡充なども考えているとのこと。
Selenium 1 のころの大変さは知っているので、Selenium 2 (WebDriver) でもそこは変わらんのだなという思いもあれば、こういうやり方ができるのは良いなぁと思った。
あと、DeNA では各種エンジニアを募集しているそうだ。
LT
ECサービスの負荷テストの裏側
負荷テストのツール「Gatling」を使ってみて、足りなかった機能を自分たちで作ってみた、という話。
負荷テストはできるものの、そのレポートには自分たちが欲しかった機能が足りなかったそうだ。Gatling のレポートにはリクエストの成否や最大・最小・平均などの数値がでるが、自分たちとしては、データのばらつきやノイズなども見たかったし、時系列データが見たかった。リクエストの開始時間と処理時間の相関なども。
どうしたかというと、Gatling のログに simulation.log というのがあるのを発見し、そのログをパースして Google Spreadsheet へブチ込んでグラフ化したとのこと。1万行くらいのデータをブチ込んでも、遅くはなるものの、しっかり動作するので大丈夫だとか（笑）
そうやってグラフかすることで、リクエストの最小値が出ているのは、実は負荷テスト終了間際で、サーバへの負荷が減ってきたからその数値が出ているんだということが分かったそうだ。つまり、本当の意味での最小値かどうかは疑わしい結果だったということか。
こういう視点は重要だなぁ。
継続的Webセキュリティテスト
オレの中ではお馴染みの VAddy の紹介とか。
Web アプリケーションの動作テストは行うけど、忘れがちなのが Web セキュリティテスト。それを解消するには、例えば OWASP ZAP を使ってみると良い。こういうことをやらずにリリース直前の脆弱性診断で問題が見つかったりすると、阿鼻叫喚の世界になるので避けたい。
理想としては、開発段階から継続的にセキュリティテストができると良いはず。ただ、既存のツールだと CI のフローに載せるのが大変だったりするので、VAddy を作ったという話。
CI 連携できるように WebAPI を作ってあり、リポジトリに push すれば自動的にセキュリティテストが走る。
その検査エンジンは独自開発をしており、例えば「これが CSRF トークンだろう」などと自動で発見するような仕組みを加えているそうだ。
こういうの組み込んでいきたいけどなー。クローズド環境が大好きな会社だと、なかなか外のサービスを使えないというジレンマがある。
Casualにインフラテストへ入門した話
Chef で環境構築をしていたが、割と変更もあって、VM を作りなおしたりしていると大変な世界になってきたので、Test Kitchen と Serverspec を使ったテスト環境を用意したという話。
最新の Chef Development Kit を使えば、Test Kitchen も Serverspec も同時に入るので便利になったそうだ。（というか、オレもこれを聞いてインストールした）
これで手元でのテストがやりやすくなり、改善のスピードがアップ。
さらに Infrataster を使って、サーバ構築後の動作テストも利用し始めた。今までは、例えば nginx の設定をしたあとでブラウザを手動でポチポチやってテストしていたところの自動化をしたとか。
これで動作テストまでローカル環境でできるようになったので、設定変更によるデグレ防止ができ、安心感が増したそうだ。なので、みんな使おうよ、という話。
オレも使ってみたいので、今度教えてもらおう（同僚だとこういうところが便利）
カジュアルなテスト&仕様書として JSON+node requestのご提案
API の開発において、JSON でテスト 兼 仕様を記載することで、楽をしちゃおうという話。node の request モジュールの仕様で書くことにより、こういうデータを送信したらこういうレスポンスが返るというのを記述するそうだ。
複数の JSON ファイルを作り、それぞれにリクエスト／レスポンスを記載し、そのファイル群をテストランナーが回していく感じ。
そういうファイルを機能追加の pull request に含めたり、バグ報告の Issue に JSON ファイルを含めることで開発時のやりとりも楽になる。
これは外部仕様に関するテストなので、テスト書き過ぎ問題は避けられるという話だけど、世の中でテスト書き過ぎな状態ってどのくらいあるのかなーという疑問も湧いたりした。
でも、確かにカジュアルな開発（特に API 開発）だと、こういうやり方はアリだなーと思った。
ということで、ひさびさにまともにイベントのまとめというか感想みたいなものを書いた。いや、いろんな方面の「テスト」が含まれていて多様性のある面白いイベントでした。みなさんありがとうございました。