Testing Casual Talks #2に参加してきました

Testing Casual Talks #2に参加してきました。
https://atnd.org/events/66159

他の会社やプロジェクトがどういう風にテストやってるのかすごく気になっていたので聞いてきました。
ユニットテストやServerspecでのインフラのテストだけでなく、
E2Eだったり、ミドルウエアの設定についてのテストや、
脆弱性テストまで行うようになっていたりしていて、
どんどんテストが自動化されていっているのだなぁと感じました。
OWASP ZAPやvaddyは試してみたいなと思いました。

発表聞きながらつらつらとメモってたことを載せていきます。


・mruby のテスト方法についての試行錯誤
@hsbtさん
GMOペパボ
http://www.slideshare.net/hsbt/20150525-testing-casualtalks

ミドルウエアに組み込むことができる
ngx_mruby
nginxの中でrubyが動く

nginxだけでも設定できるが、テストができない

Middleware as a Codeといってもいい

モチベーション
productionにngx_mruby使っている
→動いてるコードはテストしたい

ngx_mrubyとして組み込んだ時のnginxの挙動をするダミーをrubyで書いた
ダミーに対して値をセットして、production用コードのテストを行う

rubyのテストはできているけど、mrubyやngx_mrubyのテストはできてないってのがもやもや

mrubyのテストライブラリを探したところ
mruby-mtestがあった。
ngx_mrubyで動かす時にはmruby-mtestは組み込まれない。

今後やりたいこと
mruby-mtestを組み込んだmrubyとngx_mrubyのmrubyは異なるものになるので、そこの差をなくしたい
CIを回したい。環境別のクロスコンパイルをしたい
積極的にテストのあるmrubyのコードにnginx.confを置き換えていきたい


・スクラム開発において、テストメンバー(非開発者)の関わり方を模索してみた
境野高義 (@sakaimo)さん

ガイアックスの伝統サポーターズでの話
https://www.den-suppo.jp/

プロジェクトのチャレンジ
　スクラムのプラクティスを取り入れた開発プロセス（社内で2例目）
QAのチャレンジ
　このプロセスの中にQA(非開発者)が入っていく

狙い１　要件定義の充実
　QAがジョインする
　→仕様の考慮漏れが事前に指摘できた
　→ストーリー間の整合性を事前に取ることができた

狙い２　スプリントごとにテスト
　→スプリント内にテストが収まらなかった

振り返り(KPT)
keep
　要件ヒアリングの際に指摘できる
　まとめてテストよりも細かくテストする方が早く不具合みつけられる
problem
　スプリント内にテストが収まらなかった
　テスト項目の想定が読み切れてなかった
　ストーリー単位ではなく機能単位でのテストになってしまった
try
　テストのやり方、内容を変える
　　より異常系をやる
　ストーリーごとにテストする
　　フィードバックを早くしていく

まとめ
　スプリントごとにテスト→フィードバックができるのはメリット
　POも交えて軌道修正していける（スクラムのメリット）
　作られたものをテストではなく、一緒にサービスを作っていく感じがよかった


・大規模 Web サービスのブラウザテスト自動化・並列化
@deme0607さん
DeNA

mission
　ゲームプラットフォームの品質保証・向上
　開発生産性の向上

ブラウザ自動テストの構築
　selenium webdriver
　rspec/capybara
　jenkins

自動テスト拡充の利点
効率的なリグレッションテスト
　基本的なテストケースは完全自動化
　リリースサイクルの高速化

　自動テストではカバーできないところに工数を集中させられる
　(UI/レイアウト検証とか)

　問題点
　　テスト実行時間の増加

テスト並列化による高速化
　必要なこと
　　並列実行しているテストの処理が互いに衝突しないようにする
　アプローチ
　　サービス実行環境の独立
　　テスト実行ノードごとに専用の環境を用意する
　問題点
　　環境構築コストが大きい
　　環境依存の問題にテストで気づけない

　テスト専用データの作成
　　テストごとに専用のテストデータを作成
　　→仕様変更に追従しづらくメンテナンスコスト高い
　　→実環境のDBをテストから操作するリスク高い

　テストデータを作成できるAPIを提供
　　テストごとにAPIでデータ生成

　　問題点
　　　サービスも同じAPIを利用してデータを作成
　　　サービスの開発工数かかる

　テスト実行時に作成できないデータは事前に準備
　　UI経由でユーザを事前作成
　　　webdriverで自動化
　　　UI経由のデータ作成は実行時間がかかる

　　事前作成データ利用
　　　テストの後処理に注意

並列化したテストの運用・改善
　新たに顕在化した問題
　　テストが不安定
　　テスト失敗に慣れてしまうと、ほんとの不具合に気づかない

　解決策
　　地道にテストを修正していく

　テスト結果の集計APIを作成
　　失敗しやすいテストの分析を行っている
　　突然不安定になったテストケースをslackに通知

　不適切な実行計画
　　マシンリソースがあまらないように
　　過去のテスト結果の集計結果から、実行計画を作成する

今後の課題
　データ作成APIの充実
　分散実行ノードを動的に増やす仕組み
　並列実行計画の改善


・ECサービスの負荷テストの裏側
@kenchanさん
GMOペパボ
　Gatlingのレポートでは不足していたものの拡充
　データの収集と分析の仕組みづくり

　レポートから見えるもの
　　分布を詳しく見たい
　　　実際のばらつき
　　　ノイズがないか
　　時系列のデータが見たい
　　　リクエスト開始時と処理時間の相関
　　　Min,Maxの傾向がないか

　simukation.log(tsv)に生ログあった
　　google docsにインポート
　　1万行くらいならもっさりするけど行ける


・継続的Webセキュリティテスト
@cakephper / @ichikawayさん
http://www.slideshare.net/ichikaway/web-testing-casual-talks2
webセキュリティテスト
　ホワイトボックス
　ブラックボックス

owasp zap

セキュリティテスト現状の問題点
　リリース直前に大量の脆弱性発見

継続的なセキュリティテストが必要

既存のツールを使う場合
　CIに載せるのが大変

vaddy
　saas型
　CI連携を前提
　テストサーバー必要


・casualにインラフテストへ入門した話
yudoufuさん
https://speakerdeck.com/yudoufu/casualniinhuratesutoheru-men-sitahua

テスト導入以前
　すべてchef
　→チェック作業が手作業でつらい

手元でテストしよう
　test-kitchen
　serverspec

テスト環境構築
　両方chefに含まれてる

実行
　.kitchen.ymlを環境にあわせる

自動テスト化して得たもの
　確認作業が軽減された
　グリーン気持ちいい

その後
　面倒な設定変更が舞い込む
　　複雑な設定は動作確認が増える
　　→振る舞いテストやる

infrataster
基本サーバーの外部から使うツールだがtest-kitchen使う方法がissueにあった

振る舞いテストによってえたもの
　挙動のテストが書ける
　デグレを未然に防ぎやすくなった
　グリーンがさらに気持ちよくなった


・カジュアルなテスト&仕様書としてJSON+node requestのご提案
kawamoto.minoruさん
@k12uさん
https://speakerdeck.com/k12u/kaziyuarunatesuto-and-shi-yang-shu-tosite-json-plus-node-requestfalsegoti-an

面倒でもやらなきゃいけない仕事
　仕様書
　フロントエンドとの連携（外部仕様作りながらAPI開発）

JSON APIの応答をチェックする
仕様もJSONで書く
requestとresponseのjsonを用意

タイトルの元ネタ
WebAPIリクエスト仕様書としてcurlコマンドのご提案
http://qiita.com/Hiraku/items/dfda2f8a5353b0742271