2015年5月26日火曜日

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(非開発者)が入っていく

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

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

振り返り(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

2015年5月14日木曜日

JAWS-UG初心者支部【第1回】に参加してきました

JAWS-UG初心者支部【第1回】に参加してきました。
https://jawsug-beginner.doorkeeper.jp/events/22161

AWSの勉強会を探してみてて、できればレベル低めのがいいなと思ってたところ、
今回の勉強会をdoorkeeperで見つけました。
登録したときはキャンセル待ち50人以上だったけど、無事に参加できました。
隣の人と3分間ずつ話すという出会い系ワークショップがあったりしておもしろかったですw
そしてAWSは目的を決めて、あとは自分でやってみてナンボだなと改めて思いました。

今回メモったことをつらつらと載せていきます。


■オープニング+JAWS-UGの紹介 :青木 由佳 さん(株式会社パソナテック)@yuka_jyotei
・JAWS-UG = Japan AWS User Group
読み方はじょーずゆーじー

・AWS関連のイベントいっぱいある
JAWS DAYS https://jaws-days.doorkeeper.jp/
JAWS Festa
AWS Summit Tokyo 2015
re:Invent @ラスベガス

■「社内情シス インフラ運用担当のAWS初心者がJAWS-UG初心者支部で言いたい10のこと(仮)」:伊藤勇気さん(本田技研工業株式会社)@mogutan1978
・初心者がどう思ってるか話してってことで登壇
1.主催者のみなさまありがとう
2.自己紹介
3.今はAWS抜きにはクラウド語れないよねぇ、以外語れない
4.オンプレ依存症が完治していない
5.OSS/各種サービス利用に抵抗を持っていたりする(優しい顔して近づいてくるw)
6.社内IT運用に辟易している
7.でも変えてやりたいと思っている
8.じゃあ何したいわけ → VPCをしっかり勉強することがいいのではと考えている
9と10.なかった

■インフラに苦手意識を持つ女子新入社員がAWSに触れてちょっとありかなと思った話(仮):橋本さん(株式会社内田洋行)
社会人歴:1年1ヶ月
AWS歴:半年

・インフラに配属
インフラのイメージ
 広い知識がないとやっていけなそう
 アプリより地味
 絶対一度は作業中にサーバー壊す

・仕事とAWS
担当クラウドサービスのインフラをAWSに移行

・半年間のAWS勉強内容
とにかくやってみる
気が済むまでやってみる

参考書1冊やってみた
 さわって学ぶクラウドインフラ Amazon Web Services基礎からのネットワーク&サーバー構築
 http://www.amazon.co.jp/dp/4822262960
ネットで公式や先人の知恵を活用する
 クラスメソッド社のブログで内容・手順確認
 自分のAWS環境で実際に検証
 さらに必要であれば公式で確認

・心境の変化
敷居高くない
サーバーだけじゃなくやることたくさんあってむしろ熱い
サーバー使い捨てできて失敗がいくらでもできる環境ってありがたい
椅子に座ってるだけで仕事できる(DCとか行かない的な意味)

■AWS初心者に贈る〜AWS関連コンテンツを使い倒そう〜:ただあゆみさん (くまモン好き) @applebear_ayu
・AWS Samurai 2014受賞

・好きなAWSサービス
EC2(HPCインスタンス) IAM,AWS Config
AWSの勉強会では自分の好きなAWSサービスを言うのが定番らしい

・新しいことを勉強する上で大切な2つのこと
何のために勉強するのか?本質目標は?
 「AWSを勉強すること」だと行き詰まってしまう
机上で何かをするのではなく、とにかく飛び込む
 現場、現物、現実が大事

・初心者が抑えたいAWSコンテンツ
無料枠の活用
→とにかく自分の手を動かして経験を積む
 1年間の無料枠を有効に使おう
 新しいアカウント作っても古いやつと一括請求すると無料枠剥奪されるので注意
 $25の無料利用クーポンが今ならゲットできる
 http://aws.amazon.com/jp/campaigns/2015console/

セルフペースラボ
 AWSをオンデマンドで実践的に学習できるサービス

AWSの公式Webiner(オンラインセミナー)
 初心者向けオンラインセミナー
  非エンジニアにもおすすめ
 Black Belt Tech Webiner(旧マイスターシリーズ)
  経験者・エンジニア向け
  過去資料もたくさんあるが、サービスの変化が激しいので可能な限り新しいのを探した方が良い

・書籍を活用しよう
Amazonのクラウドエンジニアが選ぶ技術書35選
http://www.amazon.co.jp/b?node=3517238051

・Blogなど優良なサイトの情報を活用しましょう
Google先生に尋ねるときに足したいキーワード
 AWS blog(またはAWS ブログ)
  AWSの公式ブログ

 AWS blog SA
  AWS Solution Architectブログ
  AWS パートナーSAブログ
  日本オリジナルの記事が数多くある

 Developers.IO(または classmethod)
  クラスメソッドのブログ

・Qiitaを活用しよう
AWSの場合はサービス名でしかタグをつけていない人もいるので要注意

・資料共有サイトを活用しよう
slideshareとかspeakerdock

・SNSを活用しよう
AWS界隈の人は有用な情報をハッシュタグ #jawsugをつけてよくつぶやく

今すぐフォローすべきAWS界隈の素晴らしきエンジニア達【2014年版】
http://dev.classmethod.jp/cloud/aws/lets-follow-aws-engineers-now-2014/

・JAWSの他支部の勉強会に参加しよう
全国で50くらいある

■re:Inventへ行こう! :榎本さん(株式会社エイチ・アイ・エス)
・re:Inventってなに?
世界最大のAWSグローバルカンファレンス
 キーノート
 技術セッション
 ワークショップ

・技術の勉強だけで行くともったいない
スライドや動画はすぐ公開される
センセーショナルな発表は日本メディアでの扱いも大きい
情報のキャッチアップはこれだけで十分

・技術の勉強以外の目的
人との出会い
会場の熱気や雰囲気を感じる

・出会いのキッカケ
会場にいる人はAWSに興味しんしんで、全員仲間ですよ
ツアー参加するとキッカケが多くなる
ぶっちゃけ喫煙者の方が有利

・出会いのキッカケの後
AWSという共通の話題がある
SNSでつながりを作る
仲間になる
re:InventもJAWS-UGも同じ

・re:Inventの2つの参加方法
ツアーで行く
個人で行く

・FAQ
稟議が取れません
→上司説得テンプレートがあります
http://yoshidashingo.hatenablog.com/entry/2014/09/01/191310

嫁の許可が取れません
→一緒に行けばいいじゃん
 セッション中はシルク・ドゥ・ソレイユやブルーマンとか見ていてもらう

■AWS書籍活用術(仮) :佐々木さん(NRIネットコム)
http://www.slideshare.net/takurosasaki/jawsug-beginnersbook

AWS歴9年
ブログ : http://blog.takuros.net/

・媒体としての書籍の特徴
AWS本各種
 テーマ・読者層を設定し、網羅率が高い
 最初から読むと、ひと通り通りでマスターできるはず
雑誌 WEB+DB PRESSとか
 特定のテーマに特化して、高度な内容も多い
公式サイト
 すべての情報が乗っているが、検索しずらい
Developers.IO
 AWSでググると必ず引っかかる

・AWS本の定番3冊 日経BP社
クラウドデザインパターン 設計ガイド
http://www.amazon.co.jp/dp/4822211967
 クラウド・ネィティブな設計をする際におすすめ
 改訂版がもうすぐ出るので今すぐ買わないほうがよい
クラウドデザインパターン 実装ガイド
http://www.amazon.co.jp/dp/4822211983
 画面キャプチャ付きの操作ガイドもある
基礎からのネットワーク&サーバー構築
http://www.amazon.co.jp/dp/4822262960
 AWSを使ってネットワーク&サーバー構築の勉強
 AWS全体を学ぶには不向き

・情シス向けの2冊
Amazon Web Services入門 企業システムへの導入障壁を徹底解消
http://www.amazon.co.jp/dp/4844336479
 導入時に突っ込まれやすい内容についての解説
情シス・マネジャーのための早わかりAWS入門
http://www.amazon.co.jp/dp/4822275337
 そのままズバリのタイトル

・概要を理解するのに最適な1冊
Amazon Web Services 徹底活用ガイド(日経BPムック)
http://www.amazon.co.jp/dp/482226999X
 AWSの概要説明と導入企業の事例紹介

・一番分厚いAWS本
Amazon Web Services パターン別構築・運用ガイド(著書)
http://www.amazon.co.jp/dp/4797382570

ある程度AWSを理解した上で、
もう一歩レベルが上げられるような内容を目指しています

AWS初心者にAutoScalingについてヒアリングすると
9割 聞いたことがある
8割 使えるようになりたい
1割 使ったことがある
なりたいからあるへのギャップが大きい


・技術書の読み方(自己流)
目標設定が命
 失敗 「AWSを使えるようになりたい」
 →ゴールが不明確で、何を持って目標達成か測定不能
 成功 「負荷に応じて、自動でサーバーが増減するシステムを作りたい」
 →ゴールが明確で達成度がわかりやすい

読み方
 目次を読む
 15-30分くらいかけて、ぱらぱらとめくる
 必要そうなところだけ読む
 手を動かして、実際に試す
 全部読まない

・余談
書籍について
→1ページ書くのに3-4時間

AWS本が少ない理由
→ユーザーが少ない
→書いているうちに内容が変わっていくので大変

執筆すると儲かる?
→割にあわない

本を出版するには?
→ブログ書いてたら出版社から声かかった

amazonレビュー
→書いてください

書評ブログ
→書いてくれたら嬉しい

書いている間にもAWSがどんどん進化する
→本の増刷が決まったが、マネジメントコンソールが日本語化されたのでキャプチャ取り直してるそうです


■「セルフペースラボで気軽に始めるAWS」 :にへいさちこさん(あそびにん)
あそびにん=特定の職業についていない

・今回の補足資料
http://bit.ly/1Ef7p01

・セルフペースラボ
https://run.qwiklab.com/?locale=ja
演習問題+演習環境のセットを時間で利用可能
リソース消し忘れの心配不要
16個の無料ラボあり
無料ラボだけならクレカ不要
無料ラボは利用可能時間が短めなので、手順をしっかり読んでから開始したほうがよい