動的セキュリティテスト向けUIコールカバレッジをリリース

この夏、Ostorlabチームは精力的に開発に取り組んできました。今後数週間にわたり、さまざまな新しい能力や機能に関する一連の発表を始められることをうれしく思います。その第一弾が、UI call coverageのリリースと、当社のMonkey Testerの新しい強化版です。

新たに追加されたこの機能は、動的解析中に実行されたUIフローを表示します。また、アプリケーションのカバレッジを検証し、重要なユースケースが確実にカバーされていることを確認するための簡単な手段も提供します。

今回のリリースでは、モンキーテスターのロジックにも数多くの改良が加えられています。UIコンポーネントをより深く理解し、アプリケーションのロジックを高いカバレッジで網羅できる意味のあるイベントを生成できるようになりました。

モンキーテストとUI操作の自動化

モンキーテストは、テスト実行者がアプリケーションのさまざまな箇所に入力を注入し、クリックやイベントを実行することで、クラッシュやエラーの発見、パフォーマンスの追跡、セキュリティ問題など、アプリケーションのさまざまな側面をテストする自動テスト手法です。

動的解析では、Ostorlabのスキャナーは実機を使用し、モンキーテスターが一連のイベントを生成してアプリケーションを操作します。入力には、スワイプ、ボタンのクリック、テキストフィールドへの入力といったユーザーによる直接の操作と、Wifi接続、Bluetooth、GPSのオン/オフの切り替えやIPCの送信といったシステムによる操作があります。

当社の技術はAndroidとiOSの両プラットフォームに対応しており、ネイティブアプリケーションだけでなく、Xamarin、Cordova、Ionic、Flutterといったマルチプラットフォームのフレームワークもカバーしています。

UIテストの自動化のためのオープンソースツールはいくつかありますが、それらには次のような課題がありました。

• 単一のプラットフォームに特化しており、テストを実行または記述するための共通の方法がない
• 一般的なプラットフォームやフレームワークの多くへの対応が不十分。特にXamarinやFlutterのように、UIコンポーネントの作成方法がきわめて独特なフレームワークもある。
• ポリシーへの同意を伴う登録や、チェックアウトメニューへの入力といった、主要な利用パターンのカバレッジが不十分

こうした課題を克服し、すべてのプラットフォームでアプリケーションのカバレッジを最大化するために、当社は3つの探索戦略を利用しています。

• ランダムベースの戦略
• ルールベースの戦略
• 進化ベースの戦略

探索戦略

同様の戦略を用いているのはOstorlabだけではありません。いくつかのオープンソースプロジェクトや研究論文でも同様の戦略が実装されています。最も注目すべきものは、FacebookのSapienzです。オープンソース版はメンテナンスされていませんが、Facebookは社内版に加えた改良についていくつも発表を行っています。

こうした実装の多くと比べた、設計上の重要な違いの一つ目は、これらの戦略が個別に実行されるのではなく、それらを組み合わせるアンサンブル戦略の一部として実行される点です。これにより、性能の低い複数の戦略を、一つの強力な戦略へと変えることができます。

二つ目の重要な違いは、これらの戦略が、適用できるかどうかわからない固定的なテストケースを生成するわけではない点です。テストの再現性は保証されないことが多いためです。代わりに、これらの戦略はtest minionsを生成します。test minionsはパラメーターのセットを持ち、それによってアプリケーションとのやり取りの仕方や、どの種類のアクションや操作の流れを優先するかが変わります。

ランダムベース

Random-based strategyは、アプリケーションを操作するための最も基本的な手法です。ランダムな一連のイベントを生成するもので、複数の独立したコンポーネントを持つビューに適しています。たとえば、さまざまなクリック可能な要素、テキスト記事、動画を含むビューなどです。

ランダム戦略の仕組みを説明し、その効率を測定するために、6つのUIコンポーネントを持つシンプルなビューを例に取ります。この動画では、モンキーテスターが生成するさまざまなイベントと、それらをどのように実行するかを確認できます。

4種類のイベント（スワイプ、クリック、タッチ、チェック）を使うランダム戦略では、6つの異なるUIコンポーネントを操作するのに平均30回のイベントが必要です。 Fill Textbox + Enable Checkbox + Click button 2のように特定の順序で操作するには、平均95回のイベントが必要です。

ランダムベースの戦略はシンプルですが、複雑な論理パターンをカバーするには非常に長い時間がかかる（あるいはまったくカバーできない）ことがあります。

ルールベース

Rule-based strategyは、ユーザーの操作とアプリケーションのUIコンポーネントを関連付けます。探索メカニズムを使って特定の種類のコンポーネントを識別し、それらのコンポーネントに高度なロジックを適用できます。 この手法は、コンポーネントの種類に基づいてアクションを予測できるビューに適しています。たとえば、入力用のテキストフィールド、複数のチェックボックス、クリック可能なボタンを持つフォームのビューなどです。

以下は、ユーザー名、パスワード、ログインボタンを持つシンプルなログインビューの例です。

この例では、ルールが現在のビューにパスワードフィールドがあるかどうかをチェックしています。より高度なチェックであれば、クレジットカードや地図のコンポーネントを識別することもできます。

モンキーテスターはまず、すべてのルールを順に確認して現在のビューに一致するものを特定し、その中から一つをランダムに選択します。 上の例では、モンキーテスターはまず複数のテキストフィールドがあることを特定し、ランダム戦略による操作の一環としてすべてのテキストフィールドにダミーの値を入力し始めました。その後、ユーザー名とパスワードを入力してログインボタンをクリックする、ログイン用のルールを適用しました。

進化ベース

Search-based strategyは、遺伝的アルゴリズムを活用したメタヒューリスティックな探索アルゴリズムを使用します。

遺伝的アルゴリズムは、カバレッジを最大化するようにtest minionの設定を最適化するために使われます。この戦略は、入力とアプリケーションのカバレッジを追跡します。 イテレーションごとに設定を変異させてカバレッジを高め、性能の低いminionを破棄します。

この戦略は、ユーザーの入力によって異なるビューへと分岐するアプリケーションに適しています。たとえば、回答内容によって異なるビューに進むアンケートなどです。

まとめ

各戦略は特定の種類のビューでは良好なカバレッジを示しましたが、1000を超えるモバイルアプリケーションでテストしたところ、個々の戦略単独での全体のカバレッジは比較的低いものでした。

達成された最高の平均カバレッジは、ランダム戦略で35%、ルールベースの戦略で27%、探索ベースの戦略で38%でした。 一方、これらすべてを組み合わせたアンサンブル戦略としてまとめると、より短い時間で52%という大幅に高いカバレッジが得られました。

全体として、刷新されたモンキーテスターと新しいテストケースのカバレッジの可視化により、より高いカバレッジが得られるとともに、舞台裏で何が行われたのかを可視化し理解しやすくなります。