UZABASE Tech Blog

株式会社ユーザベースの技術チームブログです。 主に週次の持ち回りLTやセミナー・イベント情報について書きます。

GaugeのParameterを使いこなす

こんにちは! SPEEDA日本事業部でテストエンジニアをやっている工藤です。

Gaugeシリーズの第三回目です 第二回目の記事はこちらから

今回はGaugeの「Parameter」について書きます。 ParameterはGaugeでテストを書くにあたり、基礎的かつ重要な機能です。

Parameterとは

GaugeのStepはパラメータを受け取ることができます。 Parameterを使いこなすと、Stepの再利用性をさらに高めることができます。

GaugeのParameterの機能はかなり充実していて、主に下記のようなParameterがあります。

  • Simple Parameters
  • Dynamic Parameters
  • Table Parameters
  • Special Parameters

今回はSimple ParametersとDynamic Parametersについて書きます。

Simple Parameter

Simple Parameterはその名の通り一番シンプルで、Stepに渡したい値をダブルクォーテーションで囲みます。
* Go to "Top" page

例えば、下記のようなSpecファイルがあります。
login.spec

## 日本ユーザーとしてログイン
* ログインフォームに日本ユーザーのログイン名を入力
* ログインフォームに日本ユーザーのパスワードを入力

## 中国ユーザーとしてログイン
* ログインフォームに中国ユーザーのログイン名を入力
* ログインフォームに中国ユーザーのパスワードを入力

テストコードでは4つのStepに対応したメソッドを記述する必要があります。
login.kt

class login {
  @Step("ログインフォームに日本ユーザーのログイン名を入力")
  fun fillInJpnUserName() =
        `$`(".username").sendKeys("jpn_user")

  @Step("ログインフォームに日本ユーザーのパスワードを入力")
  fun fillInJpnUserPassword() =
        `$`(".password").sendKeys("passwprd_jpn")

  @Step("ログインフォームに中国ユーザーのログイン名を入力")
  fun fillInForeignUserName()  =
        `$`(".username").sendKeys("chn_user")

  @Step("ログインフォームに中国ユーザーのパスワードを入力")
  fun fillInForeignUserPassword() =
        `$`(".password").sendKeys("passwprd_chn")
}

※SPEEDA開発チームではSelenide × kotlinでテストコードを書いています。

そこで以下のようにパラメータを使えば同じStepを使いまわすことができます。
login.spec

## 日本ユーザーとしてログイン
* ログインフォームにユーザーのログイン名"jpn_user"を入力
* ログインフォームにユーザーのパスワード"passwprd_jpn"を入力

## 中国ユーザーとしてログイン
* ログインフォームにユーザーのログイン名"chn_user"を入力
* ログインフォームにユーザーのパスワード"passwprd_chn"を入力

そうするとテストコード側のStepの記述も減ります。
login.kt

class login {
  @Step("ログインフォームにユーザーのログイン名<userName>を入力")
  fillInUserName(userName: String) =
        `$`(".username").sendKeys(userName)

  @Step("ログインフォームにユーザーのパスワード<password>を入力")
  fillInUserPassword(password: String) =
        `$`(".password").sendKeys(password)
}

上記の例で示したようにParameterなしだとユーザー毎にStepを作成しなければいけません。 しかしParameterを利用することでステップの再利用性が上がり、結果としてテストコードの記述量も減らせます。

Dynamic Parameters

Simple Parametersと同じくらい多用するのが、Dynamic Parametersです。 Dynamic Parametersには主に下記二つの用途があります。

  1. Conceptに値を渡す
  2. Data Driven Executionをする際に、テーブルの値を参照する

Conceptに値を渡す

まずはこちらの用途から見ていきます。
Dynamic ParameterとConceptを使うと、Specファイルの可読性を上げることができます。 ConceptファイルでDynamic Parameterを利用してConceptを定義します。
<>内で指定したフィールド名を使うと、Concept下のStepでもその値を利用することができます。
login.cpt

# ユーザー<userName>とパスワード<password>でログインする
* ログインフォームにユーザーのログイン名<userName>を入力
* ログインフォームにユーザーのパスワード<password>を入力
* ログインボタンをクリック

Specファイルでは通常通りConceptを呼び出すのですが、その際に値を渡してあげます。
値の渡し方はSimple Parameterと変わらず、渡したい値をダブルクォーテーションで囲みます。
login.spec

## 日本ユーザーでログインする
* ユーザー"jpn_user"とパスワード"password"でログインする

## 海外ユーザーでログインする
* ユーザー"foreign_user"とパスワード"password"でログインする

SPEEDA開発でもDynamic ParametersとConceptを併用することで、よりSpecファイルのテストシナリオを仕様書のような記述になるようにしています。

Data Driven Execution

Data Driven Executionで、テーブルの値を参照する際にもDynamic Parameterを利用します。
Data Driven Executionを利用することで、同じようなStepを繰り返し記述する必要がなくなり、Specファイルの記述量をさらに減らすことができます。
例えば、下記のようなSpecファイルがあったとします。

# Simple Parameterのみを利用したログイン確認

## 日本ユーザーでログイン確認
* ユーザー"jpn_user"と"pass_jpn"でログインする

## 中国ユーザーでログイン確認
* ユーザー"chn_user"と"pass_chn"でログインする

## シンガポールユーザーでログイン確認
* ユーザー"sgp_user"と"pass_sgp"でログインする

Simple Parameterを利用してStepを再利用できていますが、全く同じようなテストシナリオが複数記述されていて冗長な感じがあります。 このようなケースではDynamic Parameterを使ってData Driven Executionにすることで、記述がスッキリします。

# Data driven executionを使ったログイン確認

     |id|userName |password|
     |--|---------|--------|
     |1 |jpn_user |pass_jpn|
     |2 |chn_user |pass_chn|
     |3 |sgp_user |pass_sgp|

## 各ユーザー毎にログイン確認
* ユーザー<userName><password>でログインする

上記の例だと、## 各ユーザー毎にログイン確認というテストシナリオが3回実施されます。
その際に、下記のテーブルで定義されているuserNamepasswordの値が行ごとに代入されて実行されます。
Data Driven Executionを使わない場合、テストシナリオの数が必要以上に多くなってしまい読む人にもストレスを与えてしまいます。
Data Driven Executionを利用した二つ目のSpecファイルの方が記述量が少なく、変数となるパラメータもテーブルにまとめられているので読みやすくなっています。

まとめ

  • ParameterでStepに値を渡すことができ、Stepの再利用性を高められる
  • ConceptとParameterを使えば、より可読性が高いテストシナリオを書くことが可能
  • Conceptに値を渡すときにDynamic Parameterを利用する
  • Dynamic Parameterを利用することで、Data Driven Executionをすることができる

Gauge正式バージョンがリリースされました!

Gaugeがβ版を終えて、正式バージョンの1.0がリリースされました!

GaugeのConceptを用いてテストシナリオをより仕様書のように記述する

こんにちは!
SPEEDA日本事業部でテストエンジニアをやっている工藤です。

前回の記事から、大分時間が経ってしまいましたがGaugeシリーズの第二回目です。
第一回目の記事はこちらから

今回はGaugeの「Concept」について書きます。 Conceptsを利用することで「実行可能なドキュメント(executable documentation)」という考え方をより実現しやすくなります。

Conceptとは

Conceptとは、Gaugeが提供する複数のStepをまとめて1つのStepとして記述することができる機能です。
ビジネス上使用する言語を複数のStepを使用して表現することができます。
例えば「ログイン」と一概に言っても、自動テストのStepで表現しようとすると下記のようになります。

  1. ログインページにアクセスする
  2. ログインIDを入力する
  3. パスワードを入力する
  4. ログインボタンをクリックする

Conceptを利用すると、上記4Stepを下記の1Stepにまとめることができます。
Specファイルの見た目上は1Stepになりますが、裏側では上記の4Stepが実行されます。

  • ログインする

Conceptの使い方

Conceptの定義の仕方ですが、まず .cpt ファイルをspecsディレクトリに作成します。
Conceptの定義に必要な記述は以下の2つになります。

  • Concept header
  • Step

Concept headerは以下のように文頭に # をつけて表現します。
# This is a concept header
Stepの記述方法は通常のテストシナリオと同じです。

以下に具体的な使用例を挙げます。
login.cptにConceptを定義します。

# Login as user A and go to page B // Concept header
* Login as user "user_a" and password "password" // Step1
* Navigate to page "B" // Step2

上記で定義したConceptはどのSpecファイルからでも利用することができ、通常のStepのように利用することができます。Conceptを利用するときは、cptファイルに定義したConcept headerで呼び出すことができます。

pageNaviagetion.spec

# Page Navigation Specification
## users can go to page B
* Login as user A and go to page B // Concept headerで呼び出す

特にStepを再利用可能なように細かい単位で書いている場合、Stepだけだと手順を羅列しているだけになってしまい仕様書のような形にするのが難しいです。
そんなときにConceptを利用することで、Step単体の再利用性を損なわずにSpecファイルの可読性を上げることができます。
例えば、下記のようなStepのみで記述されたシナリオがあったとします
login.spec

## 日本ユーザでログインした場合、TOP画面が日本語で表示される
* ログインIDに"japan_user"を入力する
* パスワードに"password"を入力する
* ログインボタンをクリックする
* TOP画面が表示される
* 言語で日本語が選択されている
* TOP画面の表記が日本語になっている

これだと手順の羅列のようになっていて、仕様書のような記述になっていません。 そこでConceptを下記のように定義します。
loginStep.cpt

# 日本語ユーザでログインすると
* ログインIDに"japan_user"を入力する
* パスワードに"password"を入力する
* ログインボタンをクリックする

# TOP画面が日本語で表示される
* TOP画面が表示される
* 言語で日本語が選択されている
* TOP画面の表記が日本語になっている

上記のConceptを利用すると、Specファイルを下記のように書き換えることができます。 より仕様のようになり、可読性も上がりました。
login.spec

## 日本ユーザでログインした場合、TOP画面が日本語で表示される
* 日本語ユーザでログインすると
* TOP画面が日本語で表示される

以下のようにConceptの中でConceptを使うこともできます。

# 日本語ユーザでログインすると、TOP画面が日本語で表示される
* 日本ユーザでログインすると
* TOP画面が日本語で表示される

HTMLレポート上のConceptの表示のされかた

Conceptを紹介するとよく聞かれるのが、下記のような質問です。

  • HTMLで出力されるレポートにはどう表示されるのか?
  • Conceptの定義(実際に実行しているStep)をHTMLレポート上で見れるのか?

上記のような点もGaugeのHTMLレポートはちゃんと考えられていて、下記画像のようにConceptは展開することができて、どんな手順が実行されているか確認することができます。

HTMLレポ―トの表示(Conceptが閉じた状態) f:id:kudogen:20180605115845p:plain

Conceptを展開したときの表示 f:id:kudogen:20180605115854p:plain

Conceptまとめ

  • 複数のStepをまとめて1つのStepとして扱える
  • Conceptを使用すると、SpecファイルでのStepの記述量が減らせる
  • SPEEDA開発ではテストシナリオの記述をより仕様書のようにし、可読性をあげるためにConceptを利用している

さいごに

SPEEDA開発チームでは現在テストエンジニアを絶賛募集中です。 少しでもご興味のある方は、こちらからご連絡ください。

モンスト、スマニュー、Wi2の運用秘話多数! 「SRE Lounge #3」レポート

株式会社ユーザベースのSPEEDA Japan Company、Site Reliability Engineering (SRE) Teamの川口です。 先日、「SRE Lounge #3」という勉強会を開催しました。 発表企業4社のみ参加の非公開な会でしたが、ここでしか聞けないようなディープな話題が満載でした。

目的

「SRE Lounge」は、

  • 各社SREチームの取り組み事例の共有(情報交換・発信)
  • SREそのものについて議論し、知見を深める

といったことを目指して行われている勉強会です。

開催の背景や、そもそもSREとは何かについては、「SRE Lounge #1」の記事を参照してください。

開催日時

2018年5月17日(木) 午後7時30分 開始

会場

今回は、ミクシィ様本社のコラボレーションスペースをお借りしました。 広くておしゃれなカフェのような雰囲気で、窓からの眺めも良く、渋谷の夜景がきれいでした。 ランチや社内の打ち合わせだけでなく、今回のようなセミナーやイベントにも使用されているということです。

f:id:uzabase:20180522233522j:plain
会場のミクシィ様本社コラボレーションスペース

参加企業

※発表順

発表内容

当日のスケジュールは以下の通りです。

  • 各社の取り組み事例等の発表と質疑応答(各社20分程度)
  • 発表を踏まえた意見交換会(30分程度)

ピザやお酒を取りながら、終始和やかな雰囲気で行いました。

f:id:uzabase:20180522234242j:plain
スマートニュース様の発表を真剣に聞く皆様

ユーザベース 

企業・業界情報プラットフォーム「SPEEDA」のシステム構成の変遷を紹介しました。

サービスの成長に伴い、プロダクトチーム(dev)とSREチーム(ops)のやり取りでのオーバーヘッドが多くなったため、 開発チームだけでCI/CDまで完結出来る環境を構築しました。 具体的には、Kubernetes+Rancherの構成となっています。 クラスタレベルロギングアーキテクチャを採用し、各APから出力されたJSON形式のログを、fluentd経由でバックエンドのBigQueryに格納していることも特長です。

質疑応答では、アラート発生時の一次調査担当や、システム環境の統制などが多く挙がり、どの企業でも苦労されているようです。

当日発表資料:SRE Lounge#3 UZABASE

ワイヤ・アンド・ワイヤレス様

「Wi2」などのWi-Fiサービスを提供されるワイヤ・アンド・ワイヤレス様には、 サービス提供環境のオンプレミス環境からクラウド環境移行への歩みについて、詳しく紹介いただきました。

オートスケーリングやコスト削減を期待してクラウドを導入したものの、なかなか思惑通りにいかず苦労されたそう。 しかし、少しずつ安定し、知識も得られてきたということで、サーバレス化やAWSの新しいサービスの利用も進めているとのことです。

Wi-Fiサービスならではの苦労も少なくない中、今後もアグレッシブに挑戦していきたいそうです。

当日発表資料:Sre wi2 20180517

f:id:uzabase:20180522234647j:plain
ワイヤ・アンド・ワイヤレス様発表中

スマートニュース様

ニュースアプリを提供されるスマートニュース様には、SREチームで担当されている膨大な業務範囲から、「モニタリング」「障害振り返り」の2つを紹介いただきました。

モニタリングでは、各リソースに適した様々なシステムを駆使しての監視を行っているということで、各社で参考になる部分も多かったと思います。

障害振り返りでは、障害発生時のインシデントレポート作成や、事後のインシデントレビューを行っており、再発防止策のトラッキングも工夫されているようです。 また、インシデントレビューの読書会も検討されているそうで、この辺りはまた詳しく聞いてみたいです。

質疑応答では、ニュースアプリならではの話題として、プッシュ通知時のアクセス集中対策の話が盛り上がりました。

当日発表資料:SRE at SmartNews

ミクシィ様

最後に、ミクシィ様のXFLAGスタジオから、「モンスターストライク」(モンスト)用に構築されているマルチクラウド環境について紹介いただきました。

「モンスト」のようなソーシャルゲームでは、例えばイベント期間だけ爆発的にアクセスが増えるため、サーバを短期間だけ増強する必要があります。 元々はオンプレミス環境で運用していましたが、最適な構成を模索するうちに、複数のクラウド環境を併用するに至ったそうです。 そのためのネットワーク構成や管理面での工夫や、各クラウドごとの癖についての話もありました。

SNSからの大規模サービス構築・運用ノウハウのあるミクシィ様ならではの内容で、当社とはスケールの違う話にワクワクしました。

当日発表資料:モンストのマルチクラウドについて / sre-lounge-at-xflag

発表を終えて

各企業のサービス内容やSREチームの守備範囲、SREに対する考え方など、これまでのSRE Lounge以上にバラエティーに富んでいて、とても興味深かったです。 また、各社の発表内容がディープで、質疑応答や意見交換会も大変活発でした。 当初予定していた時間を大幅に超えてしまいましたが、皆様多くのものを得られたのではないかと思います。ありがとうございました。

「SRE Lounge」は、今後も開催していく予定です。 興味を持たれた方や、発表してみたいという企業の方は sre@uzabase.com までメールにてご連絡ください。 また、Facebookの「SRE community」でも情報共有、交流を行っています。非公開グループですが、お気軽にご参加いただければ幸いです。

f:id:uzabase:20180522231824j:plain
今回参加いただいた各社の皆様

仲間募集!!

ユーザベースのSPEEDA SREチームは、 「No Challenge, No SRE, No SPEEDA」 を掲げて業務に取り組んでいます。

「挑戦しなければ、SREではないし、SREがなければ、SPEEDAもない」という意識の元、ユーザベースのミッションである 「経済情報で、世界をかえる」 の実現に向けて、日々邁進しています。

少しでも興味を持ってくださった方はこちらまで!