ほとんどの種類のソフトウェアテストでは、カバレッジを確保するために慎重に定義されたテスト計画を使用する。 しかし、これらのパラメータは、ソフトウェアを使用する上で起こりうることの多くをカバーしていますが、アプリケーションに慣れておらず、単に探索的な方法でインタラクションしようとしているユーザの行動を模倣するとは限りません：モンキーテストの登場です。
この記事では、モンキーテストのソフトウェア、プロセス、種類、アプローチなど、モンキーテスト全般についてご紹介します。
モンキーテストとは何か？
モンキーテストは、ソフトウェアのテスト手法として人気が高まっている。 これは、アプリケーションにランダムな入力を送ることで、ユーザーインターフェイスのインタラクションの予測不可能性をシミュレートするものである。
その目的は、あらかじめ定義されたテストケースでは検出が難しいバグやクラッシュを見つけることだ。 モンキーテストは、アプリケーションの経験も知識もない人が、ランダムにソフトウェアを探索する方法を模倣する。
このテクニックは
ロード
と
ストレステスト
アプリケーションを使用する。 事実上、テストは、アプリケーションを壊そうとして、連続的なランダム入力を提供する。
モンキーテストとアドホックテストには多くの類似点がある。
アドホックテスト
特に、そのランダム性とテスト計画への依存度の低さである。 しかし、両者の間には、別個のアプローチと考えるに十分な違いがある。
開発者の中には、モンキーテストはアドホックテストの一種であると指摘する人もいますが、2つの大きな違いの1つ は、モンキーテストはアプリケーションの知識がなくても実施できるということです。
モンキーテストとは、テスト計画を持たないことである。 ソフトウェアをクラッシュさせる目的でランダムな入力を与えることだ。
なぜモンキーテストと呼ばれるのか？
なぜこの手法がモンキーテストと呼ばれるのかについては、コンセンサスが得られていない。 しかし、この名前にはいくつかの有力な説がある。
理論1：無限猿の定理
最初の説によれば、この名前は統計的確率を論じる際に使われる比喩である無限猿定理に関係しているという。 要するに、猿がタイプライターの前に座り、ランダムなキーを無限に押し続けると、ある時点でウィリアム・シェイクスピアの全集が出来上がるというものだ。
ここでの考え方は、モンキーテストは、このようなランダムなキーの衝突をシミュレートし、十分な時間をかければ、アプリケーションが本番で直面するあらゆる事態をカバーできるというものだ。
理論2：マッキントッシュの “ザ・モンキー”
もうひとつの説は、1983年にリリースされたMacOSのアプリケーション “The Monkey “に由来するというものだ。 要するに、最初のマッキントッシュ・コンピュータを開発していたチームは、自分たちのマシンをストレステストする方法を探していたのだ。
彼らは、サルに必死にキーを叩かせ、マウスを動かしてもらえば、コンピューターの回復力をテストするのに役立つだろうと考えた。 生きたサルが手元になかったので、彼らはこのような使い方をシミュレートできるアプリケーションを作り、それを『ザ・モンキー』と名付けた。
なぜモンキーテストが重要なのか？
モンキーテストが重要な大きな理由は、チームがアプリ内のエッジケースや予期せぬ動作を発見するのに役立つからだ。 このアイデアは、開発者がモンキーテストを従来の方法と並行して使用することで、アプリが実際にどのように受け止められるかをより正確に把握できるというものだ。
製品の包括的なテストでさえ、長期間にわたってアプリケーションに関わる数万人以上のユーザーには太刀打ちできない。 このようなケースのごく一部で、ユーザーはアプリケーションに予期せぬことを要求する。 テストケースによってこれらのシナリオをすべて明らかにすることは、ほとんど不可能である。
モンキーテストは、こうしたランダムに近いシナリオをカバーしようとするものだ。 開発者がテストケースを作成する場合、アプリを熟知している傾向がある。 彼らはユーザーのゴールを理解し、アプリ内で何かを達成するために最適なインタラクションの順序を知っている。
これらの入力をランダムにするということは、開発者が考慮しなかった方法でアプリケーションがテストされることを意味する。 全体として、これはソフトウェアの全体的な回復力と耐久性を強化し、クラッシュすることなく、社会に出て、幅広いユーザーの予測不可能な事態に直面できることを保証する。
どのような場合にモンキーテストを使うべきか？
モンキーテストは優れた補助的なテスト手法である。 その最大の利点は、従来のソフトウェアテスト手法では発見できなかったような予期せぬバグを発見できる点にある。 そのため、次のような方法と併用するのがベストだ：
通常、開発者はテスト工程の初期段階でモンキーテストを採用する。 特に、事前に定義されたテスト計画がない場合に有効である。
モンキーテストはどのように行われるのですか？
そう遠くない昔、モンキーテストは手作業で行われていた。 テスターは、ボタンを押す、テキストを入力する、オブジェクトを選択するなど、型破りな入力に対してシステムがどのように耐えるかを確認するために採用された。 ここには明らかな問題がある。 まず、かなり時間がかかる。 第二に、これらの措置があらゆる事態をカバーできるという保証はほとんどない。
手動モンキーテストの例
手動のモンキーテストがどのように行われるかの例をいくつか紹介しよう。 また、自動化されたモンキーテストが何をシミュレートしようとしているのかを知ることもできる。
- テスターは、ランダムにリンクをクリックしてウェブサイトをナビゲートし、アプリケーションがクラッシュしたり、予期しないページに誘導されたりしないかどうかを確認する。
- テスターがフォームフィールドにランダムなテキストを入力し、アプリケーションがどのように反応するかを確認する。
- テスターはアイコンやオブジェクトをドラッグ＆ドロップし、それらが期待通りに動作するか、あるいは望ましくない結果をもたらすかを確認する。
様々な種類のモンキーテスト
開発者がアプリケーションの回復力に関する明確な情報を発見するために使用するモンキーテストには、主に3つのタイプがある。
1.ダムモンキーテスト
ダムモンキーテストとは、テスターがテスト対象のアプリケーションについて何も知らないアプローチを指す。 その代わり、テスターはワークフローにまったく気づかず、ボタンを押したり、テキストを入力したりと、あちこちを探し回るよう求められる。 このテクニックは、開発者が気づいていない重大な欠陥を発見するのに役立つ。
2.スマートモンキーテスト
スマートモンキーテストでは、テスターはアプリケーションとその目的について少し知っており、それがどのように機能するかについての詳細な情報さえ持っている。 このプロセスでは、アプリケーションを特定の限界以上に押し上げるように設計された、より集中的なタイプのランダム入力も使用する。 この方法は、ストレステストと負荷テストの両方に適している。
3.ブリリアントモンキーテスト
ブリリアントモンキーテストは、スマートモンキーテストの次のレベルである。 テスターは、アプリケーションに関する強力かつ包括的な知識を持っており、その知識に基づいて選ばれます。 テスターはユーザーの視点から製品を理解する必要があるため、この見落としは多くのバグを発見するのに役立つ。
モンキーテストの長所と短所
モンキーテスト技法の使用を決定する前に、その長所と短所を理解する必要がある。
モンキーテストの利点
1.珍しいバグや隠れたバグを見つける
おそらく、モンキーテストの最も魅力的な利点は、この手法によって、他の方法では発見されないかもしれないバグや欠陥、動作を発見できることだろう。 このようなエッジケースを見つけることは、従来のテスト技法では困難です。そのため、モンキーテストは、クラッシュ、データ破損、その他アプリケーションの安定性を脅かすあらゆるものをテストする堅実な方法です。
2.堅牢性を確保
モンキーテストは、アプリケーションが実際の使用時に直面する予測不可能な条件に対して、どのように反応するかを確認するために設計されています。 アプリケーションがユーザーの手に渡るとき、開発者が予測できないさまざまな入力が行われる。 モンキーテストはそのような状況を模倣し、より信頼性の高いビルドへと導く。
3.費用対効果
他の種類の検査に比べ、モンキーテストは非常に費用対効果が高い。 これにはいくつかの理由がある。 まず、アプリのユースケースの設計に多くの時間を費やす必要はない。 次に、モンキーのテスト・ソフトウェア・ツールは、大部分が自動化されているため、開発者の時間を他の作業に割くことができ、コストを削減できる。
4.多用途性
モンキーテストが優れている点は、技術的なバックグラウンドを持たない人でもテストを実施できることだ。 実際、場合によっては、完全にグリーンな人がいる方が望ましいこともある。 さらに、これらのテストはセットアップが非常に簡単なので、熟練エンジニアへの依存度を下げることができる。
5.バグの早期発見
開発ライフサイクルの早い段階でバグを発見し、解決することで、その後の時間を節約できる。 モンキーテストは、テストにランダム性のレベルを導入することで、修正しやすいうちにコードの欠陥を見つけるのに役立つ。
モンキーテストのデメリット
1.適用範囲
モンキーテストはテストカバレッジの向上につながるが、他のテストタイプのように計画的かつ戦略的な徹底性を欠く。 事実上、ランダムな入力をアプリにぶつけているため、バグを見つけるにはカオスに翻弄されることになる。 すべてを見つけられないとは言わないが、明確で事前に定義された戦略がなければ、すべてが捕捉されたと100％確信することはできない。
2.アプリケーションの制限
モンキーテストは、あらゆるタイプのアプリケーションに適しているわけではない。 多くの異なる特徴や機能を持つ複雑なアプリに最適で、最も重要なのは、予期せぬユーザーとのインタラクションの可能性があることだ。 より厳格で予測可能な機能を提供するプログラムは、これらのテストの恩恵を受けにくい。
3.時間がかかる
手動のモンキーテストは非常に時間がかかる。 モジュールやソフトウエアと何度もやりとりする必要があり、そのたびにバグが発見される保証はない。 勿論、プロセスを自動化すれば、時間とリソースを大幅に節約できる。
4.偽陽性
モンキーテストは無秩序またはランダムな性質を持つため、いくつかの入力は、製品の実際の使用中には起こらないシナリオをシミュレートすることができる。 このような状況は、偽陽性の発生を招き、コーダーに必要のない問題を修正させる可能性がある。
カオスモンキー・テストとは？
カオステストは、システムを混乱させる（さらには障害を誘発する）ように設計された制御された意図的な実験を用いて、システムの回復力と回復能力を評価するソフトウェア工学の手法である。
弾力性を確保するために意図的にシステムを壊すという考え方は、ソフトウェア開発の分野ではかなり一般的であり、このような手法の結果、エンジニアが支持できるビルドになるのが普通である。
2008年、人気ストリーミング・サービスのネットフリックスは、3日間にわたるデータベースの破損を経験した後、アマゾン・ウェブ・サービス（AWS）への移行を決定した。 その目的は、単一障害点を回避し、サービス拡大に伴うスケーラビリティの問題を軽減することだった。
チームは、AWSインフラストラクチャ上のパブリック向けインスタンスをテストするために、カオスモンキーテストを実施した。 メリットは2つあった：
- その過程で、ネットフリックスのエンジニアが修正できる弱点が明らかになった。
- このことがきっかけとなり、チームはサービスの自動復旧メカニズムを構築することになった。
カオス・モンキー・テストはカオス・エンジニアリングの一部である。 これは、システムの耐障害性や、個々のコンポーネントが予期せず故障した場合でも安定性と性能を維持する能力をテストするために使用される。
モンキーテストと関連はあるが、別の技術である。
モンキーテスト vs ゴリラテスト
ソフトウェア開発におけるゴリラ・テストという概念についても聞いたことがあるかもしれない。 どちらも霊長類の名前を持つ技術だが、多くの類似点と相違点がある。 ゴリラ・テストとは何か、どこで使えるのかを探ってみよう。
ゴリラ・テストは、モンキー・テストをより構造化したものと考えられている。 それに比べ、モンキーテストは、正式なテストケースがないテストの初期段階で使われることが多い。 一方、ゴリラテストは、自動化されたツールやスクリプトを使って、ソフトウェアアプリケーションのランダムな入力を生成する。
ゴリラ・テストは迅速で、手動のモンキー・テストよりもはるかに効率的だ。 広い範囲をカバーし、解決すべきクラッシュを見つける優れた方法だ。 しかし、境界線が明確なアプリケーションや、特定のモジュールを徹底的にテストする場合に使用するのがベストだ。
モンキーテストとゴリラテストはどちらも、現代のソフトウェア開発テストにおいてその役割を担っている。 それらを理解することは、適切なスペースで適切なアプローチを用いるための鍵となる。
最高のモンキーテストツールとは？
モンキーテスト・ソフトウェアは、現代の開発者のツールキットの不可欠な一部となっている。 しかし、そこにはいくつかの選択肢がある。 では、最高のモンキーテストツールはどれだろうか？ ここでは、いくつか知っておくべきことを紹介しよう。
1.ザップテスト
ZAPTESTは強力な
ソフトウェアテスト自動化ツールです。
これは、モンキーテストを含む幅広いテスト自動化技術をサポートする。 モンキーテストに役立つZAPTESTの機能には、以下のようなものがある：
- ノーコードのスクリプト記録： チームはユーザーのインタラクションを記録し、テストコードに変換することができます。
- 入力生成：ZAPTESTは、モンキーテストの中核要素であるランダムな入力生成を容易にします。
- 強力なレポート機能： ZAPTEST は、テストの文書化を支援する強力なレポート機能を提供します。
もちろん、これらの機能は、モンキーテストを含む広範なテスト技術に対するZAPTESTの能力の表面をかすめたに過ぎない。 WebDriverの統合、AI機能、ZAPTEST CoPilotにより、チームはソフトウェアテストの未来を一度に体験することができます。
さらに、ZAPTEST Enterprise ユーザーは、専任の ZAP エキスパートと無制限のライセンスを利用でき、すべて予測可能な固定費用で済みます。
2.アピウム
Appiumはオープンソースのツールだ。 AndroidでもiOSでも使える。 モバイル・アプリケーションのインタラクションを自動化し、モンキー・テスト機能を備えている。 開発者は、テキスト入力、クリック、タップ、スクロールなど、幅広いユーザーインターフェースの反応を模倣することができる。
Appiumはモバイル開発者にとっては素晴らしいツールだが、デスクトップやウェブのテストには機能が不足している。
3.モンキーテスト
Monkey Test Itは、モンキーテストを含むさまざまなテスト機能を備えたクラウドベースのテストプラットフォームです。 モンキー・テスト・イットは非常にユーザーフレンドリーだが、ライバルツールのようなパワーには欠けるかもしれない。
その他の欠点は、見た目がもっとスマートであることと、ドキュメントがもっと充実していることだ。 さらに、一部のユーザーからは、検査結果が不正確であるとの苦情も寄せられている。 とはいえ、低価格のシンプルなプログラムなので、世界に期待することはできない。
4.モンキーテストJS
MonkeyTestJSは、オープンソースのオーストラリア製JavaScriptベースのツールで、ウェブアプリケーション専用に作られています。 かなり基本的なものだが、仕事をこなす能力は十二分にある。 このツールにより、開発者はクリック、フォーム送信、キーボード入力など、ユーザーとウェブアプリケーションのインタラクションをシミュレートすることができます。
明らかに、このツールの欠点は、ウェブアプリケーションにしか使えないことだ。 しかし、ツールボックスに入れておく価値はある。
最高のAndroidモンキーテスト専用ツールとは？
Androidアプリケーションのテストにちょっとした混乱をもたらしたい開発者にとって、良い選択肢がいくつかある。 2つ見てみよう。
1.UI/アプリケーション演習モンキー for Android
UI/Application Exerciser Monkey for Androidは、開発者がAndroidデバイスとエミュレーションの両方に擬似ランダム入力やイベントを送信できるコマンドラインツールです。 このツールはAndroid Debug Bridgeシェルで実行されます。
2.Android用モンキーランナー
MonkeyRunner for Androidは、人気のAndroidモンキーテストツールです。 このソフトウェアは、開発者がアンドロイド端末をエミュレートしたり制御したりするプログラムを書くためのAPIである。 また、機能テストと単体テストの両方に適している。
これらのアプリケーションはどちらも良い選択肢だ。 ただし、かなりテクニカルなので、すべてのチームに合うわけではない。
モンキーテストは自動化されるべきか？
手作業によるモンキーテストの最大の問題点は、時間がかかることだ。 もう1つ注意すべきことは、数人のテスターが、幅広いユーザーが特定のアプリケーションで行うであろう様々なインタラクションを本当にシミュレートするのは難しいということです。
そこで、すぐに目につく欠点が3つある。 手動のモンキーテストである：
- 時間がかかる
- 高い
- カバレッジ不足の可能性
自動モンキーテストツールは、これらの問題をすべて解決してくれる。
ZAPTESTはあなたのモンキーテストのニーズに合っていますか？
モンキーテストは、特に複雑なアプリケーションを設計する場合、テストのレパートリーとして持っておくと良いテクニックです。 しかし、モンキーテスト専用のソフトを買うのは高い。
ZAPTEST
は柔軟で強力な
フルスタックテスト自動化ツールです。
高度なカスタマイズが可能で、開発者と技術者でないチームの両方が、モンキーテストを含む無限のソフトウェアテスト技法を構築し、設計することができます。
モンキー・テストは、他の種類のテストと併用することで、素晴らしい選択肢となる。 ZAPTESTは、1つ屋根の下ですべてを提供し、さらに以下を加える。 高品質のRPAツール
最終的な感想
モンキーテストソフトウェアは、開発者にアプリケーションをテストする型破りな方法を提供します。 このテクニックの強みは、ユーザーがソフトウェアの一部と関わる際の、予測不可能な無数の方法をシミュレートできる点にある。 つまり、モンキーテストは、テスト計画では達成困難なカバレッジを提供する。
