私が働いている会社は、AndroidおよびiOSベースのモバイルアプリケーションを含むカスタムソフトウェアを開発しています。 この市場セグメントでの競争は非常に激しいため、テスターは最終製品がクライアントの仕様と期待に準拠する責任があるだけでなく、予算とテスト条件の厳しい枠組みに置かれています。 これにより、テストコストを削減し、製品の品質を向上させる新しいツールと方法を模索することができます。



Imagriumは、これらの研究の1つの結果です。 技術的には、これは当社が作成した画像認識を使用したモバイルAndroid / iOSアプリケーションのクロスプラットフォームテスト用のJythonフレームワークです。 これは、実際のP​​yDevプロジェクトとして提示されます。ニーズに合わせて変更できます。 コードはMITライセンスの下で配布され、Github で入手できます 。 この記事では、フレームワークの原理とその構造について説明します。

動作原理

このフレームワークは2年間使用されており、その間に成長して開発され、戦闘プロジェクトでのアプリケーションの経験を取り入れました。 同時に、おそらく基本的な原則はあまり変わっていません。 それらは次のとおりです。



異なるプラットフォームで同じテストを使用する



通常、お客様はいくつかのプラットフォーム、ほとんどの場合AndroidとiOS向けにアプリケーションをすぐに注文します。 仕様は1つだけで、機能テストは同じであるため、私たちの観点から最も効果的なのは、異なるプラットフォームに1つのテストベースを持つことです。 つまり、異なるプラットフォームで同じテストに合格する必要があります。



ロジックからリソースを分離する



クロスプラットフォームテストを可能にするツールは、2つのタイプに分類できます。

• 共通のAPIと、共通の呼び出しを軸固有の呼び出し（MonkeyTalk、Appium、Robotium）に変換するサービス仲介を提供します。
• パターン認識方法を使用する（Borland Silk Mobile、eggPlant）。

私たちは最初のアプローチの大ファンですが、その時点ではツールの一部がまだ存在せず、他のツールは非常に安定して動作していなかったため、代替の作成を試みる必要がありました。 同時に、別の記録再生ツールは必要ありませんでした。そのようなツールで作成されたテストは、すぐに維持するのが非常に難しくなるためです。 なんで？ なぜなら、それらのリソースは仕事の論理に関係しているからです。 たとえば、何らかの基本的な操作を変更する場合、すべてのテキストの画像を転送するだけでなく、必要なテストの必要な手順も変更する必要があります。 人気のあるPageObjectパターンを使用して、このような無意味で費用のかかる作業を避けたいと思いました。



継続的な統合と簡単なデバッグをサポート



すべてのプロジェクトはJenkinsによって自動的に収集されるため、このフレームワークのコードの最初の行から、アプリケーションのテストも自動的に起動できるようにします。 最初は、それほど簡単ではありませんでした。イメージを操作するために、Sikuli（最も人気のある文書化された無料のソリューション）を使用することにしました。ちなみに、jsonのサポートはまだありませんでした（はい）、unittestにはたくさんのおいしい機能（たとえば、自動検出テスト）がありませんでした。 しかし、時間が経つにつれて、これらの困難は克服され、テスト結果はjUnit形式で利用できるようになり、Antはそれらを統計のある美しいページにします。



2番目のポイントによると、Sikuli IDEをご覧になった方は、10行のアプリケーションよりも少し深刻なことをするのは苦痛だと理解しています。 デバッガがないためだけの場合。 PyDev Eclipseの使用に切り替えるにはこれで十分でした。PyDevEclipseはプログラマーに馴染みがあり、開発を高速化するための多くの補助機能を備えています。



すべてのテストで同じ初期システム状態を確保する



私たちはjUnitからテストの相互独立性のアイデアを借りました これにより、テストを並行して実行したり、スポットチェックを実行したりできます。 私たちをこれに追い込んだ別のタスクは、実行中のテストの崩壊です。 あるテストの失敗が他のテストの実行に影響を与えないシステムが必要でした。 その結果、Androidではエミュレーターのスナップショット（スナップショット）を使用し、iOSではシミュレーターのリセット機能を使用することにしました。



エミュレーターのダウンロードと応答は、テストの実行を決定的に遅らせるべきではありません



箱入りのAndroidエミュレーターとは言えないiOSシミュレーターの速度が本当に気に入りました。 Intelが提供するHAXMおよびx86イメージに期待がありましたが、問題は、バージョン4.4より前のこれらのイメージには、ほとんどのアプリケーションで使用されているGoogle APIが含まれていないことです（つまり、アプリケーションは単にこれらのイメージを配置しませんでした）。 次に、このAPIを含む4.4イメージは不安定になりました（たとえば、アプリケーションを再インストールするとクラッシュする場合があります）。 そのため、スナップショットの作成と管理にGenymotionとVirtualBoxを選択しました 。



これらの原則を共有し、ある種のテストフレームワークを考えている場合、私たちの選択肢の1つとして検討することをお勧めします。

環境要件

Imagriumは、Java 7 x64とWindows 7 x64（ winリポジトリブランチ）またはMacOS 10.9（ iosリポジトリブランチ）で正常に実行されます。

歴史的に、WindowsではAndroidのみ、MacOSではiOSのみがそれぞれテストされました。

作業実演

Imagriumでテストを作成するためのルールを簡単に説明する前に、フレームワークの機能を備えたビデオ（英語の吹き出し）を見せたいと思います。 このビデオは、iOSおよびAndroidでのHopHopアプリのテストを示しています。

テストの書き方

Imagriumで記述されたコードは、 ページとテストの 2つのブロックに分割できます。 このグループ化では、テストは異なるページで実行される一連の操作と、ページ間の遷移です。 例：

authPage = AuthPage.load(AppLauncher.box, self.settings) fbAuthPage = authPage.signUpFb() fbAuthPage.fillEmail(self.settings.get("Facebook", "email")) fbAuthPage.fillPassword(self.settings.get("Facebook", "password")) fbConfirmPage = fbAuthPage.login() lobbyPage = fbConfirmPage.confirm()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードから推測できるように、最初にテストはAuthPageページをロードし、次にそこからfbAuthPageに進み、必要なデータを入力してフォームを送信し、ユーザーを確認してlobbyPageに送信します。 言い換えると、テストはページをウォークスルーして、理解できるように実行します。 操作テスター。ページ内に操作の実装を残します。 つまり テストは非常に単純なグループであり、テストの書き方を学ぶためには、ページの書き方を学ぶ必要があります。 これも非常に簡単です。

ページを書く

ページは、アプリケーションの画面/アクティビティ/ページのJython表現です。 技術的には、これはこれらのフィールドを制御するフィールドとメソッドを持つクラスです。 最も難しいケースでは、次のようになります。

 class FbAuthPage(Page): email = ResourceLoader([Resource.fbEmailFieldiOS, Resource.fbEmailFieldiOS_ru]) password = ResourceLoader([Resource.fbPasswordFieldiOS, Resource.fbPasswordFieldiOS_ru]) actionLogin = ResourceLoader([Resource.fbLoginBtniOS, Resource.fbLoginBtniOS_ru]) def __init__(self, box, settings): super(FbAuthPage, self).__init__(box, settings) self.email = self.box self.password = self.box self.actionLogin = self.box self.settings = settings self.waitPageLoad() self.checkIfLoaded(['email', 'password']) def fillEmail(self, text): self.email.click() self.waitPageLoad() self.inputText(text)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このスニペットは、Imagriumの利点のほとんどを使用しているため、このスニペットについて詳しく説明します。 フレームワークの機能。

フィールド定義とローカリゼーション

この行から始めましょう：

  email = ResourceLoader([Resource.fbEmailFieldiOS, Resource.fbEmailFieldiOS_ru])
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このスニペットは、 電子メールページフィールドをグラフィックリソース（画像または行）に接続します 。 この場合、フィールドを2つのリソースに一度に関連付けます（英語とロシア語のロケールの場合）。 ページが電子メールフィールドを要求すると、システムはこれらの画像の1つを見つけようとし、最初に見つかった画像に関連付けられた領域を返します。



契約に従って、グラフィックリソースをresディレクトリに保存します。 リソースを指定するには、次のように、リソースへのパスまたはResourceLoaderにテキストを渡す必要があります。

  email = ResourceLoader("res/pages/ios/fb_auth/fbEmailFieldiOS.png", "Password")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、コードの内容の柔軟性と利便性のために、リソースへのパスをsrc.core.r.Resourceオブジェクトの変数に保存します。



合計 ：グラフィックまたは行を管理するには、対応するページにResourceLoader宣言を追加する必要があります。

ページの初期化とフィールド検証

フィールド宣言は、必要な接続のみを設定します。それを使用するには、フィールドを参照する必要があります。 このような呼び出しは、フィールドで何らかの操作（ドラッグやクリックなど）を使用するとき、またはページが初期化されるときに発生します。 最後の操作は非常に重要です。最初に、フィールドの検索領域を設定し（通常はエミュレータの境界に絞りたい）、目的のページにいることを確認できるためです。 したがって、 FbAuthPageの例を使用して、ページ初期化コードで何が起こるかを詳しく見てみましょう。



まず、常にsrc.core.page.Pageクラスからページを継承する必要があります。

 class FbAuthPage(Page):
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、たとえば、ページ全体の読み込みを待つ方法など、一般的なページ管理方法にアクセスできます。 また、ページが初期化されるときに親コンストラクターを実行する必要があります。

  def __init__(self, box, settings): super(FbAuthPage, self).__init__(box, settings)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

初期化の最後の機能は、フィールドの検索領域を設定する機能です。通常、これはエミュレータが占有する領域であり、その中でのみ検索するために、次のように記述します。

  self.email = self.box self.password = self.box
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

boxパラメーターは、エミュレーターのスナップショットを取得した後、最初にアプリケーションを起動する前に最初に考慮され、ページからページに渡されます。 より詳細には、例えばres / pages / android / hdpi / coreから2行（エミュレーターでは垂直および水平）が取られ、システムはそれらをページ上で検出し、それらからエミュレーター領域を構築します。 フィールドに何も割り当てない場合、システムは画面全体でechを検索します（通常、検索の品質に影響します）。これは、たとえばエミュレータのハードウェアボタンを押すなど、何らかのエキゾチックな場合に必要になることがあります。



通常、ページを初期化するとき、必要なフィールドがページ上にあることを確認し、次のようにします。

 self.checkIfLoaded(['email', 'password'])
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一部のフィールドは初期化中に表示されない場合があり、表示されるフィールドのみを指定します。 ページでフィールドが見つからない場合、 AssertionError例外がスローされ 、テストが失敗し、詳細が標準出力に報告されます。



合計 ：システムにエミュレーター内のフィールドを検索させたい場合は、 self.boxを割り当てます。 self.checkIfLoaded（）でページマージンチェックを使用します。

フィールドでできること

FbAuthPageのコード例では、 メールフィールドでclick（）メソッドを使用しました。

 self.email.click()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各フィールドは実際にはSikuliのMatchオブジェクトで表されるため、対応する仕様（ドラッグ、クリック、ピンチ、リリース、テキストの入力など）で記述されているすべてのことを実行できます。

構成アクセス

構成は、テストの実行の非常に重要な部分です。 具体的には、テストを実行するプラットフォーム、テスト、アプリケーションを決定します。 また、構成に変数を登録して、テストまたはページコードで使用することもできます。



FbAuthPageクラスの例では、次の行を見ることができます。

 self.settings = settings
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、 設定属性は、現在の構成ファイルに関連付けられているConfigParserサンプルです。したがって、作業するときに公式仕様のすべてのメソッドを使用できます。 Imagriumは各テストに設定を追加するため、テストで構成を直接使用できます。



構成の使用例：

 self.settings.get("Facebook", "email")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OS依存のメソッド

たとえば、戻るボタン（Android専用）を押すか、テキストを入力する必要がある場合があります（Sikuliは単にテキストを非同期的に入力するため、これを行うことができません。通常、一部の文字には追加する時間がありません）。 これらの機能を提供するために、ページにOS固有の機能を提供するクラスが導入されました。



実際には、次のようになります（多重継承！）：

 class FbAuthPageiOS(FbAuthPage, iOSPage):
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または：

 class FbAuthPageAndroidHdpi(FbAuthPage, AndroidPage):
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

合計： OS固有の機能が必要な場合は、目的のクラスから継承します。

ページの構成

前のセクションでは、最初にFbAuthPageについて説明し 、次にFbAuthPageiOSおよびFbAuthPageAndroidHdpiにジャンプしました 。 このセクションでは、これらのクラスとは何か、なぜ必要なのか、そしてFbAuthPageにどのように関係するのかについて説明します。



最初に、異なるプラットフォームで同じテストを実行したいと述べましたが、1つのプラットフォームのフレームワーク内でさえ、グラフィックリソースの表示に重大な違いが生じる可能性があります。 たとえば、hdpiのリソースはxhdpiと異なる場合があり、iOSのリソースはAndroidのリソースと異なる場合があります。 この場合、リソースのみが異なり 、それらを操作する方法は同じままです（またはガイドラインに合わせて調整されます）。 異なるプラットフォームのリソースを再定義するためのソリューションを考え出す必要があり、標準の継承を使用しました。 つまり、ページは一般レベルとプラットフォーム固有レベルの2つのレベルに分けることができます。

1. 一般ページには、ページ上のリソースを操作する一般的なロジックが含まれています。 この例では、これはFbAuthPageです。 これらのメソッドは、iOSとAndroidの両方で同じことを行います。
2. プラットフォーム依存のページには通常、ページ全体のリソースをオーバーライドする必要があるリソースのみが含まれます。 これらは次のようになります。
   
   

    class FbAuthPageAndroidHdpi(FbAuthPage, AndroidPage): email = ResourceLoader([Resource.fbEmailFieldAndroidHdpi, Resource.fbEmailFieldAndroidHdpi_ru])
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   

このようなさまざまなページでは、テストまたはページ自体がロードするページを決定することは望ましくありません。 Imagriumでは、ページがload（）メソッドを呼び出したときに構成を読み取り、必要なページをロードするのはシステムの責任です。 システムが正しいクラスをロードするには、これらのクラスに明確な名前を付ける必要があります。 詳細：

• iOSページは[共有ページ] + "iOS"と呼ばれる必要があります（例： FbAuthPageiOS） 。 さらに、このページはFbAuthPageの子孫である必要があります 。
  
  
• Androidページにはさらにオプションがあります-これはOSバージョンと密度です。 最初に、システムはクラス[一般ページ] + "_" + "[メジャーバージョン]" + "_" + "[マイナーバージョン]" + "_" + "Android" + "[密度]"をロードしようとします。 例： FbAuthPage_4_2_AndroidHdpi 。 彼女がそのようなクラスを見つけられなかった場合、彼女はダウンロードしようとします： [一般ページ] + "Android" + "[密度]" 。 例： FbAuthPageAndroidHdpi 。
  
  

それでもクラスが見つからない場合、システムは対応する説明とともにAssertionErrorをスローし、テストに失敗します。



実際には、次のようになります。



テストでは

 fbAuthPage = authPage.signUpFb()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AuthPage一般ページにメソッドがあります：

 def signUpFb(self): self.actionAgreeTermsBtniOS.click() self.actionSignUpFb.click() return FbAuthPage.load(self.box, self.settings)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このメソッドは、 load（）メソッドを呼び出します。このメソッドでは、呼び出すページを決定します（たとえば、 FbAuthPageiOSまたはFbAuthPageAndroidHdpi ）。



合計 ：ページの一般的なロジックを実装し、別の密度/プラットフォームで必要な場合は、変更されたリソースを対応するページクラスに追加します。 構成システムは、適切な場合に呼び出すページを決定します。

テストの実行方法

Githubでプロジェクトのクローンを作成し、EclipseでPyDevを開き、不要なものをすべて削除し、必要なものをすべて追加してから、テストすることを想定しています。 テストを行うには、フレームワークが機能するために必要なものをすべてインストールし（インストール手順を参照）、プロジェクトルートから実行する必要があります。

 ant
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もう少し詳しく説明すると、この呼び出しは、特定の構成ファイルを唯一の入力パラメーターとして（たとえば、 conf / android_settings.conf ） run.pyを起動し、PATH変数とCLASSPATH変数への必要なパスを指定してから、テスト結果のページを作成します。



一般に、テスト時にエミュレータが起動し、アプリケーションがエミュレータに再インストールされた後、エミュレータのスナップショットが作成されます。 次に、テストごとに同じスナップショットが起動され、次のテストに合格します。

おわりに

一度に複数のプラットフォームをテストする必要がある場合や、GUI要素のロケーターを追加するアプリケーションコードに簡単にアクセスできない場合は、Imagriumを使用することをお勧めします。 フレームワークを習得する最も速い方法は、Pythonでプログラミングした人向けです。ただし、言語の構文が単純であるため、ツールを使用するための迅速な学習に貢献できます。 この記事では、Imagriumでの作業の基本のみを説明しました。この記事がコミュニティの関心を引く場合は、フレームワークの構成とその機能（マルチユーザースクリプトなど）について詳しく説明します。 Githubプロジェクトページの公式ドキュメントを読んで、 このHello、Worldの例を参照することもできます。