メルカリの自動化＆品質保証グループ（Automation & QA Group：通称AQA）の 根本 征 です。

私は普段、テスト自動化・CI / CD 改善・その他社内の生産性を上げるための自動化を行っています。

今回は社内で HeadSpinというサービスをトライアルしてみたので、サービス自体やその感想についてご紹介したいと思います。

• 
  HeadSpinとは

• モチベーション
• HeadSpinの主な機能
  • デバイスファーム
  • 自動テスト実行環境
  • パフォーマンスモニタリング
• 感想
  • SDKを入れる必要がない安心感
  • iOSのデバイスファーム・テスト実行環境・パフォーマンスツールとしての独自性
  • テスト実行環境をある程度任せられる
  • 何をモニタリングし、どのエンジニアにフィードバックするか
• まとめ

HeadSpinとは

HeadSpinはモバイルアプリのパフォーマンスをモニタリングする環境として、デバイスファーム・自動テスト実行環境・モニタリングをノンストップで提供しているサービスです。

多様なネットワーク、ロケーション、デバイスを使い、お客さまが使う状況に近い形でパフォーマンスのテストを行うことができます。

www.headspin.io

jp.techcrunch.com

モチベーション

メルカリでは、iOS / AndroidのUIテスト自動化を行なっています。

これらのテストは本番環境に対してではなく、検証環境に対して行なっています。

そのため、本番環境に対するテスト(主にリリース前 / 後)は現状手動で行なっています。

将来的にはこの本番環境に対するテストも自動化していきたいというモチベーションがあり、HeadSpinを使うことによってこれらを簡単に、かつお客さまが使う状況に近い形でテストできるのではないかと考えました。

具体的には

• 実機を利用する
• 4Gなどのネットワークを利用する
• 東京などのロケーションで利用する

またHeadSpinを使うと、本番環境でのパフォーマンスモニタリングもできるため、それらを活用したエンジニアへのフィードバックもできるのではと考えました。

HeadSpinの主な機能

デバイスファーム

HeadSpinでは様々なロケーション・ネットワークの端末がデバイスファームとして用意されており、それらをWebUI上でコントロールすることができます。

AndroidはOSSツールの Open STF をベースに作られており、同じ操作性でコントロールすることができます。

またHeadSpinはiOSにも対応しているところが特徴的で、画面操作やアプリインストール、スクリーンショット撮影や画面回転などがWebUI上から可能です。

自動テスト実行環境

HeadSpinでは上記のデバイスに対して簡単に自動テストを実行させることができます。

Appium / Espresso / XCTest / EarlGray などのテストフレームワークがサポートされています(詳細はこちら)

今回のトライアルでは、iOS/ Android どちらともAppiumを利用しました。

Appiumの場合には、HeadSpin上に表示されるWeb Driver URLとCapabilitiesを指定することで、指定のデバイスでテストを実行させることができます。

# Rubyでのサンプルコード
def desired_caps
{
caps: {
platformName: 'iOS',
deviceName: 'iPhone',
automationName: 'XCUITest',
udid: ENV['HEADSPIN_UDID'],
bundleId: ENV['BUNDLE_ID'],
},
appium_lib: {
server_url: ENV['HEADSPIN_URL']
}
}
end
Capybara.register_driver(:appium) do |app|
Appium::Capybara::Driver.new app, desired_caps
end

またAppiumの場合、AppiumサーバーはHeadSpin側で提供されています。

そのため、Appiumをローカル環境やCI環境でインストールする必要がありません。

それによって、今回の場合はRubyの実行環境のみ必要になったので、CircleCIを使って定期的にテスト実行できる環境を簡単に作ることができました。

version: 2.1
orbs:
ruby-orbs: sue445/ruby-orbs@volatile
jobs:
test:
docker:
- image: circleci/ruby:2.5.3
steps:
- checkout
- ruby-orbs/bundle-install
- run: bundle exec rspec
workflows:
version: 2.1
hourly_test:
triggers:
- schedule:
cron: "0 * * * *"
filters:
branches:
only:
- master
jobs:
- test

また、AppiumのGUIツールであるAppium Desktopでも、HeadSpinのデバイスと簡単に接続することができます。

パフォーマンスモニタリング

WebUI上でのデバイス操作や、自動テスト実行によるパフォーマンスは、Sessionとして記録することができます。

それぞれのSessionのUIでは、フレームレートやCPUなどのデバイスのパフォーマンスと、APIやCDNへのレスポンスタイムなどを見ることができます。

Sessionに記録しているタイミングで動画も記録されているため、具体的にどの部分・操作でそのパフォーマンスが出ているかは直感的に見つけることができます。

また、これらのデータをHeadSpin側で提供されているDBに格納することができます。

このDBをGrafanaやLookerなどのBIツールと連携することによって、継続的にモニタリングすることができます。

感想

ここからは実際のトライアルを元にした私の感想です。

SDKを入れる必要がない安心感

HeadSpinを使うに当たっては、アプリケーションに別途SDKなどを入れる必要はありません。

SDKを入れたことによる思わぬ不具合やパフォーマンス低下などを心配する必要がないのは、導入するに当たってハードルが低く感じました。

iOSのデバイスファーム・テスト実行環境・パフォーマンスツールとしての独自性

先ほども書いた通り、AndroidにはOSSツールとしてOpen STFがありますが、iOS版はありませんでした。

HeadSpinではiOSのデバイスファームとしてだけではなく、テスト実行環境・パフォーマンスツールまでノンストップで提供されています。

テスト実行環境をある程度任せられる

先ほども書いた通り、Appiumなどのテスト実行環境などをHeadSpinに任せることができるため、自分たちがメンテナンスしないといけない部分はかなり少ないと感じました。

また、デバイスを操作するためのadb・ideviceコマンドもHeadSpinのAPI経由で呼び出すことができるため、柔軟性が高い印象を受けました。

何をモニタリングし、どのエンジニアにフィードバックするか

これは私たちの中でも悩んだ部分でした。

当初はパフォーマンスに関しては主にモバイルエンジニア(iOS / Android)向けにフィードバックする想定でした。

しかしHeadSpinでは、外側からネットワークなども含めたパフォーマンスを測るため、モバイルアプリケーションのコードレベルでフィードバックできるものではありません。

モバイルアプリケーションのみのフィードバックをしたい場合には、一工夫したり別のツールと組み合わせる必要が出て来るかと思います。

逆に言うと、HeadSpinではお客さまが実際に使う状況で、APIやCDNへのレスポンスタイムを含めたトータルのパフォーマンスを計測することができます。

これによって、モバイルエンジニアだけでなくバックエンドエンジニア・SREエンジニアなどに価値ある情報・フィードバックを提供できるかもしれません。

まとめ

メルカリだと、特にJP版はサービスとしての規模も大きくなり、様々なお客さまが快適に使ってもらう重要性は高くなっていると考えています。

その中で、実際にお客さまが使う状況でアプリケーションがどのようなパフォーマンスへの影響が出ているのかは重要な情報です。

すぐに効果が出るものではありませんが、HeadSpinで得られた情報・フィードバックを元にお客さま体験を向上させるためのアクションが取れていければと思います。