radioc@?

レディオキャットハテナ

【勉強会メモ】Osaka Venture Today Meetup #3 - テスト自動化

kansai-venture.connpass.com

  • 日時:2018/03/05(月) 19:00 〜 21:00
  • 場所:サイボウズ株式会社 大阪オフィス

大阪のベンチャー企業でエンジニア界隈を盛り上げようという趣旨で開催されている勉強会で別名Oventoとのこと。過去2回は参加できなかったので今回が初めての参加でした。テーマは テスト自動化 ということで各社様々な工夫をされていてとても参考になりました。ユニットテストとかE2Eテストとかはもはや当たり前で、性能系、セキュリティ系も自動化が進み、複雑なドメインのキャッチアップのために社労士さんにデータをインプットしてもらう工夫なども行われているようでした。そしてどの会社もまだまだ課題はある、やりたいことがあると言われていたのも印象的で、知恵と技術を駆使して粘り強く取り組んでいるからこそ、ここまでの自動化ができているのだろうと感じました。

kintoneをとりまく自動テストと新しい仲間を追加した話

鈴木 亜耶さん

www.slideshare.net

kintoneの自動テスト

kintoneのリリース

  • 1ヶ月1回のリリース
  • 開発期間+試験期間
  • 開発はスクラムで実行
  • 社内はタスクごとにデリバリ
  • 社外へは1ヶ月単位にリリース

自動テストのタイミング

  • GitHub Flowで開発
    • ローカルからリモートのtopicブランチへPush⇒devlopにマージ
    • topicブランチへのPushとdevelopのマージで自動テスト
  • 手動でも実行可能
  • Jenkinsのジョブをパイプライン化
  • テストが通らないとマージ不可
  • カバレッジ:74〜88

自動テストの種類

その他

ユニットテスト

APIテスト

  • JUnitを使用したE2E
  • HTTPリクエストを送ってレスポンスを検証

ブラウザテスト

APIパフォーマンステスト

APIテストを性能検証に転用

従来の性能検証

  • QAが主に性能検証(必須)
    • 試験期間に実施する
  • 開発期間中に個々のタスクごとに性能検証することもある

負荷テスト

⇒より狭い範囲で開発期間にできる性能検証がほしい(APIごとに叩くなど)

API単位で性能検証

  • not負荷テスト but パフォーマンステスト
  • レスポンスタイムを見る
  • 毎日まわせる

⇒遅くなっているAPIがあったらJenkinsがチャットへ通知

苦労したこと・工夫

環境面

  • 毎日VMを作り直す
  • VMは他用途では使用しない

測定方法

  • テストを並列実行しない
  • ひとつのAPIで数十〜数百回測定
  • inputはバラす(キャッシュに乗るのを避ける)
  • 中央値で集計…外れ値につよい(平均だと外れ値があるとブレる)

性能劣化の検知ロジック

  • 当初:どのAPIも過去の中央値よりN%遅かったら通知
    • 中央値が小さいほど外れやすくなる
    • Kenkins先生が毎日怒っている
  • 改善:APIごとにしきい値を設定
    • 今までの実施値より決定
    • ⇒その日だけ偶然遅かったというのがまあまあある
  • 現在:3日連続で遅かったら通知

メモ

Q)パフォーマンステストにかかる時間

  • 5時間
    • 従来は数日かかっていた

株式会社ロックオン自動テストへの道

奥 清隆さん

EC-CUBE

  • テストコードもOSS
  • CIもOSS

ユニットテスト

E2Eテスト

脆弱性検査

www.slideshare.net

ベンチマーク

  • Apache Benchによる測定結果をSlackにポスト
  • Node.jsで書いている
  • 既存と新機能のベンチマークを相対的に見る

隣のとあるプロジェクト

  • CIやりたい
  • テストは昔書いてた

CIサーバを立てる

  • Jenkinsを採用

github.com

  • Jenkinsfileをローカルで実行できるツール
    • 編集したあとでいちいちリモートのJenkinsで事項しなくても良い

Docker

  • 開発環境/CI環境/ステージング/本番をコンテナ化

JenkinsfileとDockerfile

  • ローカルでも試せる
  • 他のプロジェクトへも展開しやすい

増えないテストコード

  • レガシーなコードはテスタビリティが低い
  • 動いているコードに手を加えたくない
  • 教科書通りには進まない
  • でもやる気はある
    • 毎週決まった時間を確保して改善中

参考:Paypalの事例

⇒デリバリーまでのリードタイム

  • 1ヶ月⇒最初の頃
  • 1日⇒現在
  • 5分⇒将来

メモ

Q)VAddyの効果について

  • 脆弱性が見つかったことはない
  • 手軽に使える
  • 日々チェックされていることの安心感

複雑なドメインと自動テスト

増原 賢秀さん

人事労務freee

  • 書類がPDFで出力
  • リスク
    • 社員が入社日にいないとやばい
    • PDF書類が出力されないとまずい

給与明細・賞与明細

  • 従業員はモバイルアプリでも確認
  • リスク
    • 給与計算が正しく行われまい
    • 権限まわりがデグレするとヤバイ
      • (他人の給与が見れる、管理者と同じ物が見える)

勤怠管理・勤怠打刻

  • モバイルアプリから打刻可能
  • リスク
    • 打刻データが勤怠データに入らない

  • 書類出力機能
  • 会計freeeと連携機能
  • マイナンバーfreee

自動テストの紹介

デプロイフロー

  • PRコミット
  • Circle CIでまわる
  • RubocopやEsLintなど静的解析
  • Stagingにデプロイ
  • E2Eテスト実行

RSpec

  • PR単位

APIテスト

  • PR単位

Integration

  • ユースケースの正しさ
  • PR単位で実行
  • ドメインのキャッチアップとしてまずここから書く
  • inputとoutputをCSVでマスタデータ化
    • テストコードを書けない社労士さんも確認、修正が可能
    • エンジニアはドメイン部分の正しさが担保できる

ブラウザを使ったE2E

  • Staging環境でデプロイ時に自動実行
  • ChatOpsで開発者も実行可能
  • 特定のパターンでユーザーが業務を完遂できることを担保
  • SeleniumChromeで実行
    • Rspecでテストを書く

E2Eテストが活きること

  • フロントエンド周りのアーキテクチャ変更の対応漏れ検知
  • サインアップや課金給与計算等のサービスとしてクリティカルな部分のデグレ
  • お客様の業務が止まらない
  • 課金部分(テストが難しい)
  • サービス間連携のデグレ
  • freee外の部分の動作確認

課題

Integration

  • ドメイン部分の新ルールのキャッチアップが不可欠
    • 社労士任せきりにしない⇒自分たちで情報を拾いに行く
  • 毎週国税庁や年金機構のホームページをチェックする
    • 十数人でサイトを見に行く

E2E

  • ステージングに上げて初めて不具合がわかる
    • デプロイは1日1回
    • 16並列で全部通るのが10分
  • 課金ツールの検証環境が突然メンテ
  • e-Gov電子政府の総合窓口)が突然メンテに入る
  • マルチブラウザ対応
  • コードのメンテがQAだけ
  • プロダクトコードと別リポジトリ
  • PDF書類のデグレチェックが無い

最近の取り組み

webdriver.ioへの移行中

webdriver.io

  • Node.jsのE2E
  • PageObject
  • デフォルトで並列実行
  • 公式ドキュメントが豊富
  • VISUAL REGRESSION SERVICEによる画像diff

QAチームの発信

  • テスト勉強会を3ヶ月実施中
    • テストに関する用語を開発者と認識合わせ
  • scrapbox でテストがよく落ちる箇所を共有
  • Slack通知