モバイルアプリやWebアプリをテストする上で、それらの構成要素を知ることは非常に大事です。また、モバイル通信環境ではネットワークを考慮した環境への配慮の必要性がさらに大事です。そこで、ハイパフォーマンスブラウザネットワーキングを読みました。その中で、重要と感じたところをメモがてら残しておきます。 ハイパフォーマンスブラウザネットワーキング 始めに 大学や職場では、電波や光の変調技術や伝搬遅延などの基礎、TCPのセッション確立、その上側のHTTP通信の話しまでは知っていたのですが、物理層の端末側状態遷移までは知らなかったです。また、モバイルネットワークでも、基地局や3G/LTE/WiFiなどの切り替えや特性が存在することは知っていましたが、それらが物理層でどういう状態で待機状態になっているか?など知らなかったです。この本では、そこらへんを含めたネットワーキングを全体的に知ることできたことが一番の収穫です。 というのも、モバイルアプリのテストって、PCよりも通信状態によるパケットの損失など、環境に依存する箇所が大きいとつくづく感じているのですよね。そこら辺をある程度ざっくりとテストしはするのですが、不具合解析やよりユーザの利用状況を考えたテストまで踏み込むと、厳密に通信がどのような状態か、まで考慮できた方が良いです。なので、個人的にここはすごく良かったです。 以下、いくつかモバイル通信環境に焦点を当てた上で、個人的に重要だと感じたところをピックアップ。 RRCレイテンシの存在 RRC(Radio Resource Controller)は、モバイル端末が基地局との通信を物理層で制御する機能です。モバイル通信(3G/4Gなど)では、モバイル端末が基地局との通信を物理層で確立した後、TCPの確立などに進みます。それらすべてには遅延が生じるのですが、その一番始めに存在し、モバイル通信固有の機能になります。 このRRCレイテンシは、LTE/3Gでは以下のようなレイテンシが発生するようです。 LTE: 10~100ms 3G: 最大で2秒 なので、モバイルネットワークの場合、HTTPリクエストの到達までにかかる遅延要素は以下になるのですね。 RRCネゴシエーション=>DNSルックアップ=>TCPハンドシェイク=>TLSハンドシェイク=>HTTPリクエスト この遅延を考慮した上で、端末上で動作するネイティブ/ブラウザアプリを設計・実装していく必要が現実世界ではあるのですね。モバイルアプリにおけるテストでは、OS側の責務だからと3G/LTE/WiFiと通信方式が異なる環境下でテスト(というか、動作確認)されることが少なくない気がします。一方で、こういう所はユーザビリティという視点でもアプリの快適さに大きな影響を与えるので、気に留めた方が良いです。 ハンドオーバー LTEでは、基地局から基地局のハンドオーバーに100ms以内の時間かかるそうです。一方、3Gなどでは、数秒かかることも多いそうです。日常的にこういう遅延が発生しているのですね。 ジッタ モバイルアプリケーションの通信では、ジッタと呼ばれる変動的なパケットの遅延が発生するらしいです。ここは知らなかったです。 AT&Tの各種ネットワークにおける、モバイル端末がRRCを行いDNSルックアップに到達するまでの、平均的なレイテンシは以下のようです。 LTE: 40~50ms HSPA+: 100~200ms HSPA: 150~400ms モバイル通信における、実世界で考慮されるトレードオフ バッテリー消費とネットワークパフォーマンス スループットをユーザ個別に最適化するか、ネットワーク全体に最適化するか レイテンシとジッタの考慮 コストとフィージビリティ 国や地域 他の基準 モバイルネットワークへの最適化 バッテリー消費を抑える 無線通信は、ディスプレイに次いで2番目に電力を消費するそうです。また、無線のエネルギー消費量とデータ転送量は比例する訳ではないそうです。 AT&TのApplication Resource Optimizerを使うことで、AndroidやiOSにおけるバッテリー消費量の概算を出せるそうです。やってみよう。 非効率な定期データの送受信を排除する プッシュ通信の活用、データをなるべくまとめる、重要度の低い通信は端末がアクティブになったときにのみ通信する、などを実施する。 ネットワークコミュニケーションとユーザインタラクションを切り離す 変化するネットワークインタフェース状態に対応するデザイン 無線の回線品質は、基地局との距離、混雑度、干渉などにより刻々と変化する 到達不能なホスト 突然のスループット低下やレイテンシの上昇 突然の圏外 エンドツーエンドの通信に置ける帯域幅などの予測は、モバイルネットワークの話しになると有線状態の倍以上の難しさになる バースト的に送受信し、アイドル状態に戻る モバイル端末のインタフェースはバースト的な送受信に最適化されている 多くのリクエストを集約し、できるだけ多くのデータをできるだけ早くダウンロードした上で、通信をアイドル状態にすることが望ましい バッチ処理や、プリフェッチで多くの情報を取得しておくことが大事…More
Author Archives: KazuCocoa
Spring Cloud Netflixを読んだ
Springが、Netflixが公開している彼らのOSS群を説明している記事を読みました。ちょっと、記憶に止めておきたい内容を探っているのでそのメモがてら。 記事: http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html これは、Netflixのmicroservicesを構成するツール群を説明していました。 Service Discovery Eureka Clients Circuit Breaker Hystrix Intelligent Routing Zuul Client Side Load Balancing Ribbon Service Discovery: Eureka Clients Service Discoveryはmicsoservicesベースのアーキテクチャとして大事な要素 Circuit Breaker Hystrix Clients Netflixは、CircuitBreakerを実装したもの。Microservicesでは、複数のサービスコールのレイヤを持っている。 低レベルのサービス障害が発生すると、障害がユーザまで伝っていくので、障害のあったサービスをフォールバックすることで障害の伝搬を抑制することが目的 ↑の状態になるサービスは、例えば /health の応答として “CIRCUIT_OPEN”というstatusを返す Dashboard circuitがOpenかCloseかを知ったり、応答速度を監視するためのダッシュボードですね Turbin すべての /hystrix.stream エンドポイントを、Dashboardの /turbin.streadm エンドポイントに統合するアプリケーション。アプリのインスタンスはEurekaにある。 Declarative REST Client Feign Feignは、Web serviceクライアント この記事では、Spring frameworkとして使える方法も紹介してました。 Client Side Load Balancer…More
Testing Strategies in a Microservice Architectureを読んだ
2014年11月18日に公開された、Testing Strategies in a Microservice Architectureを読んでみました。Microservicesに対するテスト戦略に関する大まかな方針を書いています。想像した通りだったのですが、理解しやすく、例も記載しているので取り組む人はいったん読んでおいたほうが良さそうです。 http://martinfowler.com/articles/microservice-testing/ 目次 Some Definitions What is a microservice ? Anatomy: a loook inside a microservice Architecture: choreographing service then the Testing Strategies… Unit: mockist vs classic Integration: datastores and eternal services Component: in or our of process ? Contract: ensureing consistency across boundaries End-to-end: tips and tricks the some…More
iOS向けBDD Toolsをいくつか使ってみた
OBJC #15 TESTINGを読んでで並べられていたBDD Toolsを使ってみました。今更感あるものもありますが、そこは復習込みで、という感じで。 Swiftで書かれたものに関してはGitHubにサンプルを作りました。Objective-Cのものは確認程度。あとはXcode 6 Beta時代のTDDチュートリアルを行ってみました。Xcode6.1.1環境で私は実施したので、いろいろAPI変わってて辛かった… Objective-C時代のBDDフレームワーク Cedar Kiwi Specta Pure Swiftで開発されているフレームワーク Quick https://github.com/KazuCocoa/sampleQuickSpecs Sleipnir https://github.com/KazuCocoa/sampleSleipnirSpecs あと、ついでにBDDのチュートリアル。 https://github.com/KazuCocoa/sampleTddInSwift XCTestを使った例 サンプルを使ってみたところと、ざっと見た感じ、Quickは良さそう。Sleipnirは、最近はさっぱり開発が止まっている様子。黒魔術な気がしたSleipnirも、XCTestを使っていないという点で面白そうでした。 Onjective-Cも、知名度も合わせてKiwiを使っていたのですが、Spectaを使ったほうがよかったかもなと感じました… ただ、SpectaはQuickの開発に本腰入れている感じがするので、今からならSpectaよりもQuickのほうが良さそう。 あと、やはりモバイルアプリはコードレベルでテストを充実できるのはModel、頑張ってControlerレベルですね。Viewははやり実際に描画させないといけないので、AppiumとかCalabashとかが必要そう。More
Appium x Androidの要素指定の手段にtext要素による指定を追加した
Appiumを使ってiOS/Androidの要素を取得する方法の数々に以下のAndroidによる要素の取得方法を追加しました。 Androidでは、Android SDKに同封される uiautomatorviewer コマンドで要素を表示確認します。そのツールで text 要素に表示される文言からその要素を特定する場合、上記のようにXPathの記述で要素を特定することが可能です。 利点 contentDescription指定が不要 表示されている文言ベースで要素を指定可能 比較的手軽 欠点 TextViewやButtonなど、表示される要素が異なると使い分けを行う必要がある 共通でresorceIDやcontentDescriptionで指定可能であれば、そのような使い分けはしなくてもよくなる テキストが表示されない要素を特定することは不可能 UIの表示文言にテストの安定性が左右される システムの言語設定に依存したり… ここまで揃えば、iOS/Android共に多くのシナリオを比較的容易に自然言語でシナリオ自動化できそう。More
「イシューからはじめよ」を読んだ
イシューからはじめよ ― 知的生産の「シンプルな本質」 [Kindle版]を読んだ ある方からオススメされたので読んでみた。 知的労働者として価値のある仕事を行うために行う問題解決の一連の流れを載せている。問題(issue)の見つけ方、仮説、ストーリー、アプトプットへの変換など。私の読んだことのある問題解決系の本などにくらべて、技法のような話よりも”アウトプット”として誰かに共有、報告するまで全体を書いているところが価値のあるところだと思う。 知れば知るほど知恵が湧くより、知り過ぎるとバカになる という言葉が出てくるが、大学時代の教授の言葉を思い出した。書籍などに載っている既存知識を吸収することは大事だが、一定の基礎を学んだ以降は読みすぎないほうが良い。すでに存在する発想にとらわれ、自分で考えた自分の発想を大きく阻害するから、というものだ。 カナヅチを持っていればすべてのものがクギに見える という、マズローの有名な言葉にもあるように。 メッセージに納得して、行動に移してもらう。いくつかアウトプットの目的をあげていたが、私が常に意識しなければいけないアウトプットの目的が見事にこれだった。最近、外部で発表する機会も増えてきて、資料を作ることがある。その中で、ここでも書かれているようなストーリー性であったり、伝えたいことを絞れなどはよく言われているので、書籍としてまとめて読むことができることは、私には価値があった。頭に常に入れておきたい。 書籍のはじめに、「悩む」と「考える」という2つの言葉を、答えの有無で説明している箇所があった。私の思っていたことに似ていて共感を持てた。答えを見つけるために「考える」のと、答えを見つけるわけでもなく、思考を発散させたり単に思考を巡らせるだけの「悩む」。仕事を行う上での価値の有無は書籍に任せるとして、私はどちらも人なので必要だなと感じた。 何か課題を見つけ、考え、アウトプットへ落とし込む方法をざっと頭に入れておきたい人にはオススメの本。細かな技法を知りたいという人には、他を当たった方が良さそうな内容。 自己啓発とか、課題解決の思考云々の書籍はあまり読まないが、これは文章や発表資料を作成するときは時折読みたいと感じた書籍だった。More
モバイルアプリのCIサービスが増えてたのでいくつか使ってみた
iOS/AndroidのCIサービスがまた増えてきたようなので、少し触れてみました。安定性はやはり以前からあるものが良さそうですが、今年は選択肢の多様化と価格競争も進みそうですね。あとは対Enterprise向けサービスも今はTravisだけですが他の選択肢も出てきそう。 今まで触れたことのあるCI環境 Travis CI, Travis CI Enterprise Wercker CloudBees Hosted CI 新たに触ってみたもの GreenhouseCI Ship.io Circle CI 試したことは、適当なサンプルプロジェクトを、GitHubのPushなどを契機にビルドするということです。それぞれのサービスの制限(ディクス容量や、時間制限など)までは確認していません。 GreenhouseCI ビルド対象はRepository URLの直接指定で行います。Publicなものであればそのままビルドすれば良いのですが、username & passでのログインやSSHの利用が提供されているので、private repositoryも対象にすることができます。 ビルド設定すると、Cloneしてきて、Android/iOSを識別、いったんビルドを試します。その後、スキャンしたビルドオプションをプルダウン形式で選ぶことができるので、そこで次回以降実施するものを選ぶことができます。 GitHubのWebhookに所定のURLを設定したら、GitHubへのイベントをきっかけにCIを回すことができるところまでサポートされている模様。 Ship.io GitHubに接続し、リポジトリを指定してビルドを開始します。こちらはまだBeta版らしく、動作が重たいです。 重たかったので、ちゃんと試せていないです… Circle CI Android、iOS共にビルドできそうだったけれど、iOSをビルドしようとすると以下のような文言が表示されました。まだBetaなので、気長に待つことが必要そう。 Warning: Sorry! Your build didn’t run because we are still adding capacity to the iOS beta and haven’t enabled your organization yet. We know…More
2014年もあとわずかですが振り返る
ギリギリですが、2014年を振り返ります。 今年1年で一番大きかったのは、転職です。 中途、しかも社内では1人目の専門職ということで、その専門性を持つエンジニアとして成果をどれだけ出せるかがガチな問題でした。そのため、社内で成果を出すことに一番力を注いだ年だったと思います。 やったこと 仕事 転職しました。年明けて少したったらちょど1年 同僚らにまだ入社して1年満たないことに驚かれるほどには馴染んだ模様 モバイルアプリ開発関連のテストエンジニアとして成果を出せた気がする 少なくとも、組織として安定したリリースサイクルを回せるようになった 外部活動 JaSST 14 Hokkaidoで発表しました 第2回 日本Seleniumユーザーコミュニティ勉強会で登壇しました WACATE 2014 冬に参加しました 専門性 テストエンジニアとして、100%力を注ぎ込む環境に身を置くことができました 今まで読んできた書籍などが血肉になった プライベート ブログ、年間で100投稿超えました 文字としてアウトプットすることを私の中で気軽なものにするために取り組んでみましたが、思いの外続けることができました 次はブログの質に気を配りたい 技術書など含め、平均して月に2〜3冊は読めた気がする 小説、漫画などはのぞく やりたいこと 仕事 Rails(Ruby)、iOS、Androidのそれぞれのテストコード読んでレビューできるようになりたい モバイルアプリで使っているツールをほかの人も手軽に使えるように、広める段階に持っていきたい テストの考え方を社内でアプトプットしていきたい 外部活動 JaSST 15 Tokyoのパネリストとしての役割を果たしたい Appiumなどの、モバイルアプリ開発に関わるテスト関連の知識を共有するコミュニティを促進したい 自動化研究会にお声掛け頂けたので、日程あえば足を運んでみたい 専門性 書籍の量は落として、写経などのテストコードと遊びたい(質をあげたい) Android or iOS or Web Appで何かちゃんとゼロから開発してみよう サンプルコード触ってみました、操作してみました、ではなく プライベート コンサートやミュージカルなどにいきたい 旅行(海外?)行こうと言われているのでいきたい 締め 最近、忘年会などで同僚から聞かれるようになりました。 なんでサービス開発側ではなくテストエンジニアとして活動しているの? 普段の活動の中で、コード読んだり、書いたりしています。Productivity向上を専門とするエンジニアと言われるような領域の活動とも重なっている領域の活動もしています。そういうことを行うテストエンジニアとの交流が同僚の経験上少ないらしく、こういう質問を聞かれているようです。 就職時は将来のキャリアを考えたり、転職時も同じように考えていました。一方で、転職してからはキャリア以外のところでもテストエンジニアとして活動するところで良さを感じました。アプリ開発などを行ってもテストエンジニアから完全に外れることはないかなと思います。…More
WACATE 2014 冬に参加してきた
最近常々思うのですが、テストエンジニアも役割が細分化されて、役割が再定義される時代がすぐそこそうですね。開発者が、xxx(特定の言語)エンジニア、サービス開発エンジニア、インフラエンジニアなどのように区分して呼ばれるように。例えば、最近、テスト自動化エンジニアと呼ばれる人たちが出てきましたが、それもその一つだと思います。 さて、話題は変わり、12/6、12/7の2日間で開催されたWACATE 2014 冬に参加してきたのでその話をまとめます。1ヶ月くらい経ちましたが、ようやっとブログポストになります。。。Twitterにおけるハッシュタグは #wacate だそうです。 WACATEとは WACATEは「Workshop for Accelerating CApable Testing Engineers」の略で、「内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ」という意味です。 前々から日程が合えば参加してみたいと思っていたのですが、日程が合わず今回初参加。初参加ながらも、分科会をさせていただきました。 ここでふと疑問に思うのが、若手の定義です。こちらのCIAの資料によると、日本の平均年齢は46.1歳のようです。そこから考えると、30代までが若者といっても良さそうな範囲ですね。 なお、WACATEとはによると 35歳以下 だそうです。More
デザイニング・マルチデバイス・エクスペリエンスを読んで
「われわれはまったく新しい状況に直面すると、つねに、もっとも近い過去の事物とか特色に執着しがちである。われわれはバックミラーを通して現代を見ている。われわれは未来に向かって、後ろ向きに進んでゆく by Marshall McLuhan, “The Medium Is the Massage” 最近発売された、デザイニング・マルチデバイス・エクスペリエンス ―デバイスの枠を超えるUXデザインの探求を読みました。モバイルアプリを含む、サービス開発に関わっている人におすすめできる本です。自分たちでマルチデバイスを対象にサービスを開発、世に提供している人たちは、昨今の端末の多様性に対する話の整理とユーザ体験の整理ができると思います。実例が非常に豊富で、マルチデバイス環境下における自分たちのサービス/アプリを考えさせられると思います。 今勤めている企業と私の今の役割からいうと、社内のモバイルアプリに横断的に関わっていて、それらをリリース前に少なからず触れるという立ち位置にいます。もしかすると、社内では機能的に一番多くのモバイルアプリに触れているかもしれないです。今まではそのプラットフォームに対してや、デザイナさん、プロジェクトの人が持つ芯に沿って関わっていましたが、そこから一歩進んで関わることができるかも。機能的なテストで終われないですよね。 いろいろ書かれていたのですが、何が重要か?に関しては、よく聞くけれど以下をしっかり考え取り組むことが重要だと言っています。 ユーザのニーズやゴールは何か? メインフロー、及び利用のコンテキストは何か? デザインアプローチは最適か? 使用されるデバイスは何か? コンテキストを満足できるか? 以下、かいつまんでまとめを。この本は事例が豊富なところがとても良いので、ざっと読んでみることをお勧めします。1日ないし、半日あれば読み終わることできます。More