Tag Archives: appium

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

Appiumを使った文字入力とcontext switch

Appiumに関して、以下の2点に関してメモがてら。 文字入力 WebView(Hybrid view) 以下、Appium1.3.4の時の話です。 文字入力 iOSでは、Appium(というか、Selenium)が提供するキー入力にsendKeysが存在します。また、UIAutomationでは、setValueが提供されています。 iOSでは、マルチバイト文字入力含め、setValueによる文字入力のほうが安定しています。ですが、全てのテキストフィールドにそれを使うことができるわけではありません。SecureTextFieldに関しては、sendKeysを使わなければ正常に文字入力ができませんでした。 そのため、安定したテストを書くためには、TextFieldにはsetValueを、SecureTextFieldのみはsendKeysを使いましょう。 Rubyのライブラリの話をすると、appium_libのこの行を参考にすると、以下の通り type で定義されているメソッドに内包されています。 また、同様にソースを見ると、このメソッドはAndroidではsend_keysとして扱われています。 そのため、以下のようなルールを設けて実施すると良いでしょう。 SecureTextFieldを対象にしている場合はsend_key ↑以外の場合はsetValue こんな感じで内包することになるでしょうか。 WebView Hybridアプリの場合、contextを変更することでネイティブ、WebViewのそれぞれを操作対象として変更することができます。 なのですが、iOSアプリの一部WebViewで操作する必要のある画面をiOS Simulatorで実行していた時の話です。contextでWebViewに設定しても期待通りに動作しませんでした。むしろ、正常に要素すら取得できていなかったです。逆に、Nativeで実施すると正しく動作した。 AndroidやiOS real deviceの話までは詳しく追ってはないのですが、context switchはいらないのか…??More

Appium1.3.6released

https://github.com/appium/appium/releases/tag/v1.3.6 AndroidのXPath、ChromeDriver向けの修正のようですね。 確かに、私の実施するXPath指定のテストも正常に動作しなくなってましたので、これで直るかも。 ただ、XPathではなく、UiSelectorを使う形に修正したのであまり関係しなさそう？ …. ちょっと確認してみた感じでは、修正されたわけではなさそう。。。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

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

Appium 1.3.5 released

Appium 1.3.5 がリリースされましたね。 リリースノート https://github.com/appium/appium/releases/tag/v1.3.5 ここまでのバージョンになると、開発量も少し落ち着いてきたように見えます。 iOS8.x系に関しても、iOS7=>iOS8のような大きな変更がシミュレータにも入るわけではないので。 driver.get()でpageを取得できなかったところなんかの修正が入っています。あとはiOS8.2。 iOS8.3もbetaで入手できるようになりましたが、iOS8.3からは OS X 10.10以降がRequirementになります。 なので、メンテナンスされるメインストリームもOS X 10.10に移り変わる流れになりそうな予感。 Androidに関しては以下の修正が入っているので、1.3.4使っている人は更新したほうが良さそう。もとより、私の環境では1.3.4があまりちゃんと動かなかったので、masterブランチや1.3.5betaを使っていましたが、ここでnpmから入手できる正式版が使えるようになった。 add workaround for issue where UiAUtomator fails to find visible elements. fixed undefined member error for the release object.More

UiSelectorを使うようにしたほうが良さそうだ

過去いったんまとめた、Appiumを使ってiOS/Androidの要素を取得する方法の数々に追記した。 Appiumの1.3.3まではできていて、1.3.5betaからできなくなったことに以下による要素の特定がある。 これは、以下のようにUiSelectorを使えば問題はないみたいだ。 UiSelectorはこちらから確認することができる。Uixxxxxシリーズは、uiautomatorの要素として提供されているものなので、UiSelectorをちゃんと使っていくという方がAndroidでは正しそう。 心無しか、AppiumもUiSelector使って安定したようにみえる。 Appiumで行うレベルのテストはテスト環境で影響される要素が多いので、地道にFlakyなテストを減らして安定したテストを回したい。。。More

Appium 1.3.5 beta released!!

Appiumの1.3.5がリリースされていた。 1.3.4では、環境によってはadbコマンドかinstrumentsへのコマンドが正しく動作しないことがあったのでmasterブランチを追ってましたが、これでnpmの世界で過ごせる!     比較的大きなものとしては、iOS8.2の対応とかでしょうか。とはいえ、対応バージョンの追加などの比較的細かな所になりますが。  あと、Androidに関してはUiAutomatorあたりでworkaroundが入っていたりとするので、AndroidでUiAutomor使っている人には良いのでは。 何も問題なければ、多分1.3.5はこのままリリースされるはず。 https://discuss.appium.io/t/appium-1-3-5-beta-released/2511 iOSアプリで要素を取得するとき、Appium.app経由だと取得できる要素が、コマンドラインから起動したAppiumサーバ経由だと取得できないものに出くわしたのですよね。 ？？と思って、コマンドラインのAppiumサーバ経由で起動したあと、inspector経由でアクセスすると、確かに見えない。 これは何だ。。。と疑問に思って調査しようとおもってはいるのですが、致命的というわけではないのでんーという感じでうやむやに。 そろそろ、コード書いて、コードを読む量を増やしたい機運。More

Appium x Androidの要素指定の手段にtext要素による指定を追加した

Appiumを使ってiOS/Androidの要素を取得する方法の数々に以下のAndroidによる要素の取得方法を追加しました。 Androidでは、Android SDKに同封される uiautomatorviewer コマンドで要素を表示確認します。そのツールで text 要素に表示される文言からその要素を特定する場合、上記のようにXPathの記述で要素を特定することが可能です。 利点 contentDescription指定が不要 表示されている文言ベースで要素を指定可能 比較的手軽 欠点 TextViewやButtonなど、表示される要素が異なると使い分けを行う必要がある 共通でresorceIDやcontentDescriptionで指定可能であれば、そのような使い分けはしなくてもよくなる テキストが表示されない要素を特定することは不可能 UIの表示文言にテストの安定性が左右される システムの言語設定に依存したり… ここまで揃えば、iOS/Android共に多くのシナリオを比較的容易に自然言語でシナリオ自動化できそう。More