フラッターアプリケーションのテスト：ツール、利点、課題

こんにちは！私の名前はMariaLeshchinskayaです。SurfのQAスペシャリストです。当社は2011年からネイティブアプリケーションを開発しており、2018年からはFlutter用にも開発を行っています。



この記事では、ネイティブアプリケーションとクロスプラットフォームアプリケーションのテスト機能を比較します。Flutterを使用したときの感想を共有し、テスト時にSurfで使用するツール、Flutterが便利な理由、発生した問題について説明します。

Flutterのテスト機能は、ネイティブのテスト機能と同等です。

企業が開発へのアプローチを変更したり、新しいテクノロジーが出現したりした場合、テスト機能に深刻な影響を与えないことが重要です。理想的には、新しい言語またはフレームワークを使用する場合、QAスペシャリストは、最良の方法で実証された使い慣れたツールとテクノロジーのスタックを引き続き使用します。



ネイティブアプリをテストするとき、Surfでは自動テストを使用し、パッケージを読み取って置き換えます。自動テストがなければ、特に回帰があり、プロキシの助けがなければ、アプリケーションの変動性と多くのケースのカバレッジが減少します。 



Flutterアプリケーションをテストするときは、使い慣れた機能を維持することが重要でした。



自動テスト



Surfは、CalabashおよびRubyフレームワークと連携して、ネイティブアプリを自動テストします。 Flutterが登場したとき、私たちが最初に疑問に思ったのは、Calabashを使用しないことは可能であると同時に、私たちが慣れている方法で、またはさらにクールな方法で自動テストを完全に機能させることです。 



それは可能であるだけでなく、サードパーティのサービスがなくても可能であることが判明しました。Flutterでは、統合テストとコンソールでのウィジェットのテストをすぐに利用できます。 Flutterの開発者は、Flutterの自動テストに関する記事でこれについて詳しく説明しています。



Flutterの自動テストは、クロスプラットフォームであると同時にネイティブでもあります。アプリケーションプロジェクト内でテストを作成でき、両方のプラットフォームで機能します。プロジェクト全体が目の前にある場合は、不足しているid-schnickを追加したり、バグを見つけて修正したりできます。これは、アプリケーションの品質を向上させるもう1つの機会です。



Flutterは、Behavior Driven Development（BDD）アプローチもサポートしています。 UIテストに使用します。言語としてGherkinを選択しました。機能ファイルを使用したり、英語とロシア語でスクリプトを記述したりできます。それは理解できます、それはそれらの中にまたはそれらと一緒に追加の引数なしでスクリプトステップの実装、自動テストの起動をカスタマイズする機能を持っています：例えば、タグによっていくつかのスクリプトを実行し、全体としてすべての書かれたテストではありません。 



FlutterアプリケーションをテストするときにGherkinを使用するために、flutter_gherkinオープンソースフレームワークを接続しました。 



Flutterに自動テストがあることに気付いたとき、CalabashとDart + Gherkinのテクノロジーの違いは何でしょうか。どちらのアプローチが優れているのでしょうか。それらを一緒に比較してみましょう。



1.機能ファイルは両方のアプローチで完全に同一です。



たとえば、ピンコードによる認証用のスクリプトは、Calabashを使用してDartとRubyの両方で正しく解釈されます。

:        ( )
       
          
         
        

どちらのテクノロジーも、ロシア語、英語、その他の言語をサポートしています。



2.手順は実装が異なります。これはどちらが便利かということではありません。特定のテクノロジー内の構造は変わらず、これは良いことです。 



3. Flutterは、追加の.dartファイルを使用して、テストを構成および操作します。 Calabashでは、そのような単一のファイルは存在しません。



私たちの意見では、これがFlutterまたはCalabash内のフラッターであるとは言えません。これは、特定のツールやテクノロジーを使用する際の詳細にすぎません。



4.4。アプリケーションで要素を操作するのに便利なように、各要素には独自のIDが必要です。Calabashで自動テストを行う場合は、テストするアプリケーションで両方のプラットフォームにIDが含まれていることに事前に注意する必要があります。Dartでは、iOSアプリケーションとAndroidアプリケーションのファイルを個別にリロードせずに、自動テストを作成するプロセスでIDを追加できます。これは便利で時間を節約できます。 



私たちの結論：Dartでの自動テストは、Calabashフレームワークを使用した自動テストより劣っていません。

 

プロキシ



ケースごとにアプリケーションのカバレッジを拡大するために、Surfは、Charlesなどのトラフィックを読み取ってスプーフィングするプログラムを使用します。クライアントとサーバーの相互作用の分析により、次のことが可能になります。

1. バックエンドと実際に相互作用しているかどうかを判断します。
2. 問題がどちら側にあるかを調べます：クライアントまたはサーバー。
3. , .
4. : , , . Charles , , , .

Dartには、ネットワークを操作するための独自のクライアントがあります。すべてのリクエストはそれを通過するため、プロキシを操作するために必要な設定をアプリケーション内に入力する必要があります。テスターの便宜のために、必要なすべての設定は別の画面に配置されます。Surfでは、独自に開発したデバッグ画面を使用します。



デバッグ画面は、デバッグビルドからのみ使用できる追加の設定画面であり、テストに役立ちます。その中で、必要なサーバーを選択したり、アプリケーションでhttpリクエストの読み取りと保存を使用したり、デバイスのfcmトークンを表示したりできます。テストする機会はたくさんあります。 



デバッグ画面はカスタムです。開発者は、テスターの要求に応じて要素を追加します。たとえば、アプリケーションからプロキシを構成するためのフィールドです。したがって、Charlesと連携する十分な機会があります。アプリケーションを再起動せずにプロキシサーバーをDebugScreenに接続できます。



ご覧のとおり、Flutterアプリケーションをテストする可能性は制限されていません。ネイティブが便利で使いやすいときに私たちが使用することに慣れているすべてのもの。これは良い知らせです。

問題：フレームワークのバグ、サードパーティライブラリの欠陥、予想されるネイティブ動作

Flutterアプリケーションをテストするときに直面する問題もネイティブです。これらがFlutterの特定の欠点であるとは言えません。どのテクノロジーでも、問題解決は必ずしも明白で単純であるとは限りません。 



Flutterアプリケーションをテストするときに何を探すべきかを教えてください。事前警告は事前に警告されています。



フラッターフレームワークのバグ



テスト中に、iOSでのフォントの表示とフォーマットで問題が発生しました。つまり、iOSプラットフォームの文字間隔がAndroidよりも著しく広くなっています。これにより、多くの視覚的なバグが発生しました。 



問題はフレームワーク自体にあることが判明しました。私たちのモバイルアプリ開発者がFlutterフレームワーク開発者コミュニティの人々にそのような不快なバグを修正するように依頼したとき、フレームワークはすぐに更新され、iOSでのテキスト表示が修正されました。



きっとそのような状況が繰り返されるでしょう。しかし、これは大きな問題とは言えません。Flutterコミュニティのメンバーは、問題に迅速に対応し、フレームワークをサポートおよび開発します。



サードパーティライブラリの



欠陥iOSバージョン10および11では、サードパーティライブラリで実装上の欠陥が発生しました。たとえば、技術仕様と設計で計画されているように、通知へのアクセス許可がボタンではなく、アプリケーションの起動時にすぐにポップアップするバグを修正しました。



このような問題は、クロスプラットフォームとネイティブの両方で発生する可能性があります。これらは、プロジェクト内の修正によって、またはライブラリ開発者と一緒に解決されます。



予想されるネイティブ動作への対処



iOSおよびAndroidでのネイティブアプリケーションの長期使用とテストにより、さまざまなアプリケーション動作からのユーザーの期待を簡単に予測できます。したがって、たとえば、iOSでバックワイプを使用して戻るのは標準的なジェスチャーです。そしてAndroidでは、それは必要ありません。



両方のプラットフォームのシステムダイアログは異なります。iOSでは、通知にアクセスするためのアクセス許可を要求する必要があり、Androidでは、このアクセスはデフォルトで与えられます。 



多くの場合、手動で終了する必要があるのは、OS固有のこれらの部分です。また、バックワイプの場合のように、iOSプラットフォームで予想される動作が突然Androidに移行した場合は、削減することもあります。



ネイティブアプリケーションでは、画面の更新、不適切なアプリケーションの最小化、現在のOSで異常なアプリケーション操作などの問題はまれです。特定のプラットフォーム用のアプリケーションを開発するためのツールとテクノロジは、特定のシステムのすべてのバージョンと機能をカバーすることを目的としています。 

Flutterアプリケーションの1つをテストしたとき、興味深い状況に直面しました。画面を更新する機能は、iPhoneX以降のiOSデバイスでは利用できませんでした。同時に、強打のないiOSデバイスとAndroidは正しく機能しました。 



Androidバージョン6で別のバグが発生しました。最小化すると、アプリケーションがメモリから完全にアンロードされました。



このようなバグは、プロジェクト内の開発者によって修正されました。

iOSは、デバイスとシステム、新しいバージョンのOSでリリースするチップ、以前のバージョンでは機能しなくなるチップ、同じSwiftを更新するときに何に焦点を合わせるかを完全に認識しています。Androidは、多数のデバイスと完全に異なる画面サイズをターゲットにする必要があることを理解しており、その詳細も知っています。 



クロスプラットフォームに、ネイティブ開発からの実装のすべての微妙な点を含めたいと思います。もちろん、Flutterを使用する場合、いくつかの欠点がありますが、これは問題ではありません。クロスプラットフォームへの独自のアプローチが必要なだけです。

利点：1つのコードベース、1つの開発チーム

単一のコードベースにより、テスト時間が短縮されます。



バグの原因としては、技術仕様のあいまいさ、デザインのレンダリング状態の欠如、バックエンドの更新時の下位互換性などがあります。半分の数のタスクを作成する必要があるため、このようなバグを作成する方が簡単です。これにより、すでに時間を節約できます。 



1つのプラットフォームでバグを検索して機能を確認できます。高い確率で、両方のプラットフォームで繰り返されます。結局のところ、実装は1つです。 



同じコードが記述されているため、両方のプラットフォームの新機能のロジックも同じです。アプリケーション内の複雑なプロセスのテストは、あるプラットフォームでのテストと別のプラットフォームでの確認に帰着します。 1つのプラットフォームでアクティビティの完全なサイクルを実行します。探索的テスト、機能の実行、煙/正気/完全、フィードバックの分析を行います。その後、別のプラットフォームでの探索的テストによって品質を確認するだけです。このアプローチにより、ロジックテストの時間が約1.3倍節約されます。

, , , : , . , .



, (, iOS), , (Android), event .

両方のプラットフォームのアセンブリを同じ日に顧客に納品する必要があり、それらが同時に出て、プロジェクトにQAエンジニアが1人しかいない場合、ネイティブ開発で検証するための十分な時間がない可能性があります。テストサイクルは両方のプラットフォームで別々に実行する必要があります。クロスプラットフォームアプリケーションをテストすることで時間を節約します。両方のプラットフォームの回帰テストが単一のサイクル内で実行されます。 



2つの類似したプロジェクト（1つはネイティブAndroidとiOS、もう1つはFlutter）のテストを大まかに評価し、それらを頂点で比較しました。 



分析とテストは、1つのiOSデバイスと1つのAndroidプラットフォームデバイスで実行されました。実際に見ることができるように、Flutterは、2回ではありませんが、実際に時間の増加をもたらします。これは理解できます。2つのプラットフォームのいずれかでテストを完全に削除することはできません。何と言っても、それらは異なる特異性を持ち、ユーザーに焦点を合わせています。



オペレーティングシステムの詳細に完全には影響せず、プラットフォームごとに個別にカスタム作成されていない既製の機能をテストする場合、両方のプラットフォームでFlutterアプリケーションをチェックする時間が約1.3〜1.5倍短縮されます。たとえば、異なるプラットフォームで特定の動作を行わない認証およびパスワード回復機能により、Flutterバージョンのテスト時間が1.3分の1に短縮されます。



各プラットフォームからのカスタム動作を必要とする機能については、時間の短縮を期待するべきではありません。 iOSとAndroidの動作は異なると予想されます。つまり、両方のプラットフォームを完全に個別にテストする必要があります。たとえば、ユーザーの通常の通知作業を維持するために、権限の違い、通知接続の操作、iOSとAndroidで通知を送信するためのプッシャー設定、およびその他の実装の微妙さのために、両方のプラットフォームでプッシュ通知をフルサイクルでテストする必要があることがよくあります。 TKとデザインが尊重されました。



チーム内のコミュニケーションを整理する方が簡単です



プロジェクトに多くの人がいる場合、小さな微妙な点でも通過しないようにプロセスを整理することは困難です。特に、多くの改善が先にある場合は、新機能の実装と一般的な変更。問題のほとんどは、開発チームが1人の場合に解決されます。 



まず、2つのプラットフォームで2つの異なる実装を操作するよりも、1つのコマンドを実装してアプリケーションをテストする方が簡単です。もちろん、品質保証の専門家は、iOSプラットフォームとAndroidプラットフォームの両方で、アプリケーションのステータスに関する完全な情報を入手することに関心があります。 Flutterを使用する方が簡単です。



第二に、ネイティブ開発には重要なポイントがあります。一方のプラットフォームが学習して受け入れた変更については、もう一方のプラットフォームに通知する必要があります。これは、大規模で集中的な変更の過程で忘れられたり失われたりすることがあります。Flutterアプリケーションを開発する場合、このような問題はありません。チームは1つだけです。つまり、改訂のための1つのタスクが両方のプラットフォームに適用されます。

Flutterアプリのテストが大好きです 

クールなコミュニティの一員である



こと私たちにとって、新しいフレームワークはプラスです。非標準の問題を解決することで、視野を広げます。アプリケーションをテストするときにスキルと機能を開発する、多くの興味深いユニークなバグを見つけました。



同時に、Flutter-frameworkコミュニティの開発者は、特定された問題について迅速にフィードバックを提供し、ライブラリを改善して、プロジェクトに貢献できるようにします。私たちは一緒に前進しており、それは素晴らしいことです。 



スペシャリストになる



クロスプラットフォームアプリケーションを使用する場合は、オペレーティングシステムの違いに留意し、プラットフォームの特異性に焦点を合わせることを忘れないことが重要です。理論的には最小限にすべき違いを探して見て、これまでに遭遇したことのないことを学びます。そのような作業はプロ意識を高めます。 

ネイティブアプリを開発およびテストする場合、AndroidStudioやVisualStudioCodeなどからiOSアプリを構築することはできません。Flutterを使用する場合、IDEはAndroidとiOSの両方で同じです。カッコいい。

独立



するFlutterを使用する場合、Surfでは、eコマースからバンキングまで非常に異なるプロジェクトに直面します。実践により、QAエンジニアは両方のプラットフォームを片手でテストできることが示されています。作業のペースが速くなり、タスクを完了する時間がなくなったときに、リリースの近くでのみ別のスペシャリストを接続する必要があります。 

フラッター-一歩前進

クロスプラットフォームアプリのテストは難しくありません。ネイティブのものを使用するよりもさらに高速で便利な場合があります。直面する可能性のあるすべての困難は、利便性と利点に重なるものではありません。



Flutterアプリケーションの開発とテストの経験から、Surfはこのフレームワークが大きな前進であることを示しています。