Category Archives: test automation

こんばんは。Selenium/Appium Advent Calendar 2017の15日目の記事です。 多くのエンジニアの方々は、テスト失敗時の問題修正に時間を使っていることかと思います。それはテストコードの問題なのか、製品コードの問題なのか、はたまた別な問題なのか。 そのため、例えばテスト失敗時のエラー情報から、再度テストを実行することなく、どのように修正すれば治るのか、どうなおせば良いのかを教えてくれるとその時間を減らすことができますね。（これに似た話は色々と目にしますね） 今回は、Appiumを使った時の、そんな修正を便利にするちょっとしたアプリを共有します。 リポジトリはこちら => https://github.com/KazuCocoa/appium-source-viewer テスト失敗時に取得する情報は何を取得する？ 多くの場合、Appiumのようなツールを使う人はテスト失敗時にテスト対象のスクリーンショットを取得するかと思います。また、人によっては動画を取得する場合もあるでしょう。Appiumに限らず、GUIが関係する場合は特に、そのような情報を失敗時の情報として取得するでしょう。 では、テストを修正する人はその情報を見ただけでどのように修正すればテストがOKになるか判断することができますか？ 表示されている文字だけを見ているのであれば修正できる可能性はあるでしょう。ただ、例えばAndroidだと resource-id 、iOSだと accessibility identifier を使うことが普通になっている場合は、スクリーンショットを取得したとしても該当しそうな箇所をその表示のみから追うのはキツいのではないでしょうか。ソースコードを確認し、再度繰り返し実行し、調整していくことも多いのではないでしょうか。 とても時間が勿体無いですね。 どこが失敗 し、 どう修正すべきか を教えてくれるテスト結果であれば、この時間は短縮でき、楽に問題を修正することができるでしょう。 Sourceも取得する どこが失敗 し、 どう修正すべきか を知る手段として、テスト失敗時の情報として page_source の情報は1つの役立ち情報でしょう。例えば以下な感じのXMLです。 GoogleのEspressoやEarlGreyはテスト失敗時にそのように画面のヒエラルキー情報を出力してくれますね。そのおかげで、修正者は要素がそもそもないのか、ある場合はどのような情報を付与するとそれを特定できるのか、はたまた別な要素である必要があるのかを判断することができます。(XCUITest自体は残念ながら取得できないです(できなかったですよね…?)) スクリーンショット x source sourceだけの場合、そのXML情報を想像できなければ結局は表示内容を確認することになるでしょう。 そこで役立つのがスクリーンショット。ただ、sourceとスクリーンショットを自分の目で照らし合わせることはそれはそれで慣れが必要です。 そんな時、例えばAppium-Desktopのようなツールを利用できたらどうでしょう？ 視覚的にスクリーンショットから該当するsourceの要素を確認できる ようになり、だいぶ問題を見つけることが楽になるのではないでしょうか。 オフライン x スクシーンショット x source 便利だろうということで作って見ました。Appium Desktopを参考に、オフラインで使える形にしてみました。 sourceのXMLを読み込み、任意の要素をクリックすると、該当する要素がハイライトされます。逆に、スクショの任意の要素をクリックすると、該当するsourceのXML要素がハイライトされます。 再度、リポジトリはこちら => https://github.com/KazuCocoa/appium-source-viewer これを用いると、 例えばAndroidだと resource-id 、iOSだと…More