test – Page 7 – ~ my tech diary ~

UIAutomator2.0がリリースされていた

3月13日、以下の通りAndroidのUIAutomator 2.0がリリースされていたのですね。 https://plus.google.com/+AndroidDevelopers/posts/WCWANrPkRxg uiautomatorは、AndroidのAccessibility機能やその拡張を介して、インストールされた様々なapkを操作するフレームワークでした。そのため、例えばリリース用apkに対してシナリオテストを自動化するときなんかに使います。例えば、AppiumはAndroidに対してはこのuiautomator1.0を利用してテストを実施することをしています。 uiautomatorあらため、UI Automator 2.0の新しいところは、Instruments経由でUiElementsなどを使えるようになったことらしいです。これにより、./gradlew connectedCheck なんかのコマンドでUI Automatorによるテストを実施できるようになったとか。まだASOPには公開されていませんが、Appiumのメンバらも公開されたら良さそうなら統合とかするでしょうし、DroidDriverとももしかすると競合するところがあるのかもしれません。 2014年12月のEspresso2.0のリリースとそれに伴うJUnit4の提供、UI Automatorの更新と、比較的テストツールの充実が図られていて良い感じですね。 Testing Support Libraryが提供する大きな機能 AndroidJUnitRunner: JUnit 4-compatible test runner for Android Espresso: UI testing framework; suitable for functional UI testing within an app UI Automator: UI testing framework; suitable for cross-app functional UI testing across system and installed apps AndroidJUnitRunner Require Android2.2(API Level8)…More

JaSST15 TokyoのBolton氏の資料が公開されたので振り返ってみた

JaSST15 Tokyoに参加、パネリストとして前に立ってきたでも書いたように、基調講演を行ったBolton氏の資料が公開されたので備忘録程度に少しまとめてみる。 JaSST 15 TokyoのBolton氏の資料が公開されていました。資料はこちら => ★ 以前はった、Twitter Bolton氏は、Testingは学びと適合、と表現していました。また、良いテスターとは、何か見つけるとそれは問題か？このままで良いのか？という問いかけや気づきを提供できるもの、といっていました。主な役割は以下。 Bug any problem that threatens the value of the product Issue any problem that threatens the value of the testing, or the project, or the business Coverage how much of the product you have tested based on some model Oracle something that helps you…More

「実践テスト駆動開発」の積読をようやっと読んだ

実践テスト駆動開発テストに導かれてオブジェクト指向ソフトウェアを育てるを読んだ有名どころの良書なのですが、積読で放置してしまっていたものをようやっと読みました。事実が変わったときは、私は自分の考え方を変えます。あなたはどうしますか？ジョン・メイケード・ケインズ TDDにより設計や実装が洗練されてくる話を丁寧に書いています。また、テストコード自体の役割、良いテストコードに関する言及もあります。時刻や外部システムをモックしたり、それらの責務をどのように切り離すか、という話も書いています。依存性を切り離すこと、テストコードに意味を持たせること、テストコードからテスト対象の関係性を想像できるようにするなど、複数人で開発する上で正しく開発するためのテストに関して言及しています。テストコードを少なからず書く人は必読な位置付けですね。早い段階で読んだ方が良い感じです。今の段階で読んで、テストコードに意図や実装コードの説明を載せていくとか、そこまで考えることが重要だと改めて感じました。例えば、処理の順序が大事でないなら、@Afterやexpectationには順序を与えずに独立させて複数メソッドを書き、実行させるとか。setUp()を1つですべての初期化を書くのではなく。可読性の高いテストコード何をテストしているのかを理解しやすいタイトル、内容テストコードの合理化何を確認しているか(どうやって、よりも、何を) 少ないテストケースで密度の濃いテストが実施できているか複数のFeatureを1つのテストに含めすぎるのではなく、1つのFeatureのテストを少ないテスト数に凝縮していく、という感じとかとか。最後のあたりでは、テストをよりよくするためにDBが絡むテストや、非同期、揺らぎのあるテストの話なんかがありました。依存性注入(dependency injection)をぼんやりとしかわかっていないので、次はそこを学ぼうかな。そういえば、テストの話でよくテスト自動化を促進するなら、どこから実施しますか？と聞かれることがあります。その時、テスト自動化のしやすさとか、そういう話はありますが私はずっと境界となる箇所から始めると答えています。これは、テスト対象の境界が壊れたら、その対象に関係する全てが壊れる可能性があるからです。昨今、Microservicesと叫ばれたり、Webhooks、Web APIを使って複数サービスを1つの大きなサービスに見立てるという風潮があります。その場合は特に、その境界となる動作が壊れるとすぐさまシステムは壊れることは想像しやすいと思います。そのため、私は境界となるところのテスト自動化から手をつける、と伝えてます。その考えがこの本でも早い段階で書かれていて、とても共感できました。ちなみに、GUIを持つアプリだと、人との境目でまずは用意する方がよいかなという立場です。過度な量は無いことは前提です。10分かからないくらい範囲でとか。そのあと、高速なUnit test、Integration test、としていく、という感じでしょうか。SOAやMicroservices的な組織構造を持つチームであれば、Integration testの持つ責任が大きくなるでしょうので、そこは大変だけれど誰かが増やさないといけないですね。Androidだとespressoとかがその位置付けになれると感じています。 iOSはどうだろうか。More

iOSのplistを黒魔術で操作しているところで文字化けしてた(Appiumの使っているライブラリの話)

現在のAppium(Appium1.3.6)は、Non-ASCII文字列をタイトルに持つアプリケーションは文字化けして表示されます。通常、iOSアプリはplist内のデータを読み込んで、そのメタ情報をアプリ名などとしてシミュレータ/実機上で表示します。なのですが、Non-ASCIIをファイル名に持つアプリで、Appiumを使ってインストールしたアプリではアプリ名が文字化けするという現象にでくわしていました。原因を把握するためにAppiumのコードを読んでみましょう。 iOSアプリ起動の下準備 Appiumのコードを追っていると、以下でiOSデバイスに対する下準備を行っていると分かります。 appium/lib/devices/ios/ios.js この中で、以下箇所で何やらplistを生成している模様。plistはbinaryとxmlがあるのですが、今回問題になっている文字化けはbinaryのplist。なので、bplistCreated(obj)が怪しそう。このpblistCreatedはどのライブラリで処理されているのか？というと、以下の模様。 bplistCreator.js from: https://github.com/joeferner/node-bplist-creator/ この中で、Stringを書き込んでいる箇所が。ここを覗いて、writeIntHeaderに渡している0x6と0x5が何かにおいます。 http://opensource.apple.com/source/CF/CF-855.17/ForFoundationOnly.h によると、らしい。なるほど。UTF-16として処理されなければいけない所を、ASCIIとして処理するようにしてしまっていたので、再現していたのですね。この問題に対する修正は過去に既にマージさえていていたのだけれど、nodeに公開されていなかった模様。同僚が公開してくれると嬉しいな〜ってコメントしたら、昨日のうちに0.0.5を公開された。めでたい。無事、0.0.5が公開されたので、このPRがマージされれば次回公開版からは修正されるでしょう。 https://github.com/appium/appium/pull/4714 binaryファイルを葬る黒魔術に出会ったわけでした。蛇足以下を見てみると、find_element(:accessibility_id ‘なにか’)とかで渡す要素が、何を受けつけられるのか見えますね。今はxpath、id、name、class nameの他、ネイティブアプリに対してはuiautomationやuiautomator、accessibilityを、Webアプリに対してはlink text、css selector、tag name、partial link textが与えることができる模様。 appium/lib/devices/common.js なるほど。More

システムテスト自動化標準ガイドを読んだ

この土日は積読の消化をしようと、システムテスト自動化標準ガイドともう1冊読みました。ここではシステムテスト自動化の本を残します。このTweetの通り、内容はシステムテストに限りませんでした。個人的にはシステムは入れなくても良かったのでは・・・と思いました。実際に自動化に取り組んでいたり、代表的なテストの書籍を読んでいるとそうだよな、という感じで納得できる内容が丁寧にまとまっている感じでしょうか。特に、キャプチャ&リプレイの話だったり、保守しやすい形、自動比較の話なんか。今、第4章の自動比較、検証が個人的に今悩んでいます。特に、モバイルアプリではViewに対する評価を、単なる表示される要素の確認以上しようとすると画像比較以外できません。その画像比較は最終的には人の目に頼らざるおえないので、時折漏れが発生します。そのため、人目で見ることを前提に、気づきを得られるような施策を打つことはしますがそれ以上どこまでできるか考えます。これ読んでて思ったのですが、なんだかんだで私はデータ駆動、キーワード駆動のテストまで実装していたのですね。More

ActionSheet()ではなくaccessibility_idでアクションシートの要素を操作する

UIAutomationで、actionSheetの取得は正常に実施できないので、accessibility_idによる要素取得にしたほうが良さそうだ。 alertは問題ないので、alert viewに関してはそこまで考えなくても良さそう。例えば、以下のようにactionSheetを取得しようとすると、UIAElementNilが取得される。むむむ。。。 info: [debug] Got result from instruments: {“status”:17,”value”:”Cannot perform action on invalid element: UIAElementNil from target.frontMostApp().actionSheet().buttons()[\”キャンセル\”]”} info: [debug] Responding to client with error: {“status”:17,”value”:{“message”:”An error occurred while executing user supplied JavaScript.”,”origValue”:”Cannot perform action on invalid element: UIAElementNil from target.frontMostApp().actionSheet().buttons()[\”キャンセル\”]”},”sessionId”:”b412bcd4-d867-43df-9e3e-cafe2672ca05″}More

テストカメレオン

ふと、購読中の配信情報見てみると、テストカメレオンなるテストサービスを見つけました。 TestChameleon !! 変幻自裁なアーキテクチャを持ってるのかな？とか、多様なサービス持っているのかな？と思いざっと読んでみました。機能自体は、SauceLabsやBrowserStackみたいなものですが、そのテスト実行環境のアーキテクチャが貼られていたところが個人的に面白かったです。以下、画像は以下URLから引張てきています。おもしろそうだと感じた方は一読してみると良いかもしれません。 http://www.ministryoftesting.com/2015/03/automated-testing-cloud-testchameleon/ Architecture Selenium Hub使っているのですね。最近だと、iOSが絡むところ以外がEC2上などにブラウザ環境を構築できるようになってきたので、こういうテストサービス自体の価格や自動化の障壁も下がってきましたね。嬉しいことです。 Dashboard Documents https://dashboard.testchameleon.com/media/tech-docs/_build/html/ APIs https://dashboard.testchameleon.com/media/tech-docs/_build/html/technical_doc.html 所管提供されるテストの記述がJavaの例だったのですが、Groovyやらでかけるようなラッパー用意すれば使いやすそう。RubyやGroovy、Pythonのような感じの、少ない記述でテストかける方が私は嬉しいな。 SauceLabsやTesetDroidのように、モバイルアプリ/モバイルWebのテスト環境が整っているサービスはやはりまだ少ない模様。一方、Web Browserの環境を提供するものは増えてきて価格競争に突入しそうな雰囲気がひしひしと伝わってきますね。競争。。。More

モバイルアプリにおけるE2Eテストの自動化に関して少しまとめる

少し前に、雑にモバイルアプリのリリースサイクル毎で行っているテストの流れという記事を書きました。考え方が少し変わったりしているのですが、そこからE2Eテストという枠を抜き出して、さらにはテスト自動化という文脈で少し話を整理してみようと思います。ここでは、効率的なコード、失敗時の解析の容易さなどに対する言及は致しません。また、サーバ側に対するテストの話にはちゃんとは触れません。 E2Eテストに含まれる目的モバイルアプリにおけるE2Eテストという言葉には、恐らく以下の目的(と雑なテストタイプ)が含まれていることが多いと思います。アプリのGUIから操作した (もしくは表示される要素に対して直接操作した)という文脈を持ったうえでの、シナリオテスト想定したStoryやFeatureを含んだシナリオを用意し、そのシナリオを達成できるかを検証したい機能テスト(システム全体) サーバ側機能を含んだ、モバイルアプリのGUIから操作して意図した通りに機能が単体で振る舞うかを検証したいシナリオとして複数機能をまたがって何かする、という所までは見ない統合テストサーバからの応答をえた上で、モバイルアプリのGUI上で描画される要素を検証したいサーバはモック/スタブサーバでも特に限定しない。モバイルアプリ自体を構成する機能を統合させた上で正しく動作するかを見るもの。 GUIテスト画面の表示、ボタンは位置などのレイアウトに対するGUIのレイアウト崩れ、描画される要素の過不足を検証したい画面サイズ、解像度、フォントサイズ、アクセシビリティなどを考慮なお、4に関しては端末のガイドラインに準拠しているかといった内容や、ユーザビリティに対する話は含まれません。自動化する時に検証する方法目的4以外のものに関しては、多くはGUIからの操作なので入力に対する出力を得て、その出力に対してアサーションをとることで検証を行うことでしょう。 4のGUIテストに関しては、モバイルアプリの場合は必ずスクリーンショットをとる必要が出てくるでしょう。描画される要素の有無であれば不要ですが、レイアウトが期待通りか、という所まで検証しようとすると、要素が描画された上で確認しなければ正しい/正しくないの判断ができないためです。例えば、画面サイズや解像度の多様性により表示がおかしくなるというのはAndroid/iOSともに多く有ります。どこまで検証するか GUIから操作するという文脈を持つテストの場合、多くは実行に時間を要します。そのため、どこまで、何を確認するかということで神経を使う必要があります。そこで、アプリをどこまで確認するか、というところで少し雑にまとめてみます。なお、ここの分け方は検証したいことと、その環境で雑に区分しています。 1. シナリオテストユーザが実際に操作する内容をシナリオに落とし込んで、期待されるシナリオを完遂できるか検証するユーザの操作が変わるパターンはなるべく用意するモック/スタブサーバは利用しない外部システムとの連携、端末の設定に依存する箇所も含む 2. 機能テスト(システム全体) サーバ側からの応答によりモバイルアプリケーションの振る舞いが変わる場合、それは可能な限り網羅する GUIからすると同じ表示でも、その裏側(サーバからの応答)が異なる場合も含む機能として仕様に定義した範囲モック/スタブサーバは利用しない外部システムとの連携、端末の設定に依存する箇所も含む 3. 統合テストサーバ側からの応答によりモバイルアプリケーションの振る舞いが変わる場合、それは可能な限り網羅する GUIからすると同じ表示でも、その裏側(サーバからの応答)が異なる場合も含むモック/スタブサーバを用意してでも、サーバからの通信結果をもとに、アプリが期待通り動作することを検証することが目的端末の設定に依存する箇所を含む 4. GUIテストレイアウトパターンはなるべく網羅する同一レイアウトの使い回しに関しては、不要なものは実施しないツールとテストモバイルアプリでは、Headless browserのようなGUIの無い高速な確認手段は存在しません。また、espressoや、Debug用にSDKとしてハックしたライブラリを使う以外は、システムが提供するアニメーションなど含めてそれらを許容した上で各種テストを回す必要があります。そのため、基本的にGUIから操作した上で確認を行う必要があるため実行速度はWebアプリほど速度を出すことが難しいです。一方、espressoなどのように限定した使い方であれば安定して高速に確認する手段もそろってきたので、そこらへんも解消する日が来るかもしれません。シナリオテストやGUIテストを目的としたE2Eのテストを行う場合、基本的にAppiumのようなGUI越しに操作するツールを使うことになるでしょう。そこでは実行速度と安定性がやはりトレードオフになります。一方で、現在のモバイルアプリを検証するツールとしてはこれ以上の手段は殆どないです。機能テストや統合テストを目的としたE2Eのテストを行うときの多くもAppiumのようなGUI越しに操作するツールが基本になると思います。ただ、espressoのような高速にView単体を確認できる手段も選択肢としてでてきました。そのため、単なる表示のバリエーションなんかはAppiumのようなもので実施するよりも、遥かに高速に実施できる環境として利用できるようになってきました。ここで話している文脈における自動化されたテストは、手動テストによる回帰テストを減らすことが目的で使うことが多いと思います。なので、互いに補完関係になるように、プロジェクトとして十分な目的を選んでいきたいですね。…More

Appiumのテストを1台の計算機上で並列して実行させる

Appiumでテストを実行していると複数台の計算機でテストを並列して実行したい、と思う方もいるでしょう。 Appium自体はサーバなので、1台の計算機上で複数起動させ、テストを並列して実行させることができます。これを行えば、独立したテストケースを分散させて、それぞれのテストを実行、結果を収集するという簡単なテストケースの実行並列化もできます。Selenium Gridよりもかなり手軽にテストを実行できる環境になるでしょう。設定する点は以下 Appiumサーバに必要な引数を与えて起動するテストケース側のcapabilityに対象となるAppiumサーバの待ち受けポートを指定する例えば、appium_libを使っている人だとcapabilitiesのportに値を設定する必要があります。例 Appiumサーバの起動 ※appiumコマンド箇所は、適切にnode .などに置き換えてください capabilityの指定例えば、appium_libを使っていると、appium.textの[appium_lib]にportを指定する方法があったり( ★ )、以下のように直接メソッドに値を与えるならserver_capsに対して要素を指定する方法があります。いずれにせよ、これによりシナリオをAppiumサーバに渡すことができるようになります。並列実行 Step1 Step2 以下2種類でそれぞれ起動注意点 iOSではiOS Simulatorの制限上、複数Simulatorを同時に起動させることができません。そのため、iOSは並列実行するには物理的に複数のMacマシンが必要です。 ref: https://github.com/appium/appium/blob/master/docs/en/appium-setup/parallel_tests.md ref: https://github.com/appium/appium/blob/master/docs/en/writing-running-appium/server-args.mdMore

JaSST15 Tokyoに参加、パネリストとして前に立ってきた

JaSST 15 Tokyoに参加してきました。また、JaSST 15 Tokyoの企画セッションの1つである「Web.JaSST ～ウェブ開発のテスト～」で登壇してきました。 ※諸事情により、参加したのは2月20日だけです。参加したセッション How To Get What You Want From Testing(for Testers, Developers, and Managers) テストプロセスの評価と改善聞いた以外で面白そうだったセッションテストコードクリニック How To Get What You Want From Testing(for Testers, Developers, and Managers) Michael Bolton氏による発表です。以下Twitterで簡単にまとめられていました。同氏は、テスターがTestingの中心であると述べていました。そこに対して、TestingとCheckingの違いから、明らかな機能的な不具合の他に”おかしいと感じる”ことも重視してTestingするという話しを混ぜていました。例えば、人は以下のような感情を受けます。これらは良くないものもあり、良くないと感じたらそこは不具合が存在する可能性が高い。それは今のところ機械では見つけられないTestingによって得られるフィードバック、ととれます。 Impatience Frustration Fear Suprise Confustion Annoyance Boredom Tiredness Anxiety これらの感情は、以下のような問題へと繋がります。 Capability Scalability Reliability Usability…More