Category Archives: software test

DroidDriverのJavaDocを少し観察してみた

DroidDriverのJavaDocをもすこし読んでみた。 io.appium.droiddriverのJavaDocsより 以下、いくつかピックアップして読んでみた。 BaseDroidDriver DroidDriverを使ってテストを記述するとき、通常は BaseDroidDriverTest を継承して使う。 BaseDroidDriverTest は、 D2ActivityInstrumentationTestCase2 を継承している。 D2ActivityInstrumentationTestCase2 は ActivityInstrumentationTestCase2 を継承している。 D2ActivityInstrumentationTestCase2 は ActivityInstrumentationTestCase2 で既知の不具合であるISCよりも小さなバージョンのOSで再現するNullPointerExceptionの修正を含んでいるとのこと。 D2ActivityInstrumentationTestCase2 にある scrubClass の引用 Fixes a bug in ActivityTestCase.scrubClass(java.lang.Class) that causes NullPointerException if your leaf-level test class declares static fields. This is a known bug that has been fixed in ICS Android release. But it still…More

忘れないようにIntentのUnitTestを書いてみた

昨日の記事をちょっと手を動かしておこうと思って、IntentのUnitTestを書いてみた。ついでに、@RunWith(AndroidJUnit4.class)を有効にして。 AndroidJUnit4.classを使うにあたってエラーが出て修正したポイントは2つ。あとおまけで1つ。 injectInstrumentationによるInstrumentationへのinject これしないと、super.setUp()で落ちる InstrumentationRegistry.getInstrumentation().runOnMainSync()によるintentからのActivityの起動 これしないと、startActivityがヌルポで落ちる ContextThemeWrapperを使うことで、R.style.AppThemeをテスト時にレイアウトとして使う レイアウトを独自でカスタマイズしている場合、AppThemeが無いみたいなエラーが出てきました どうやら、ContextThemeWrapperで仮のレイアウトを使うことで回避できるもよう 今回はあくまでもintentの確認なので、まー、よしですかね UIスレッドの話しなんかも、対応を終えたあとはなるほどなーという感じ。 ちょっと記述量を減らしたく、ButterKnifeを使ってみました。おまけ程度。 内容は、 com.example.activityのアクティビティを起動する 表示されるボタンをタップして、別アクティビティ(com.example.activity.Next)を起動する という内容に対して、期待したintentが飛ぶことを確認する、というものです。 ActivityUnitTestCaseなので、その実際が描画されたりはしません。これ、Integrationレベルで確認すると、Espressoを使って描画ベースの存在確認を行いますね。 ふぅ。Intent、いろいろちゃんとしておかないと魔の巣窟になって危なそうですね。サービスが肥大化してくると特に。怖い怖い。 最近、StethoをVolleyに適用しようとしています。単純に適用しようとすると、VolleyのHttpStackを活用してOkHttpStackのようなクラスを作成し、QueueRequestにHttpStackを与えます。 なのですが、今取り組んでいるところはそのような形でさくっとできるような所ではなく、少し手惑い気味。More

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

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

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

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