テストの整理
以下の計画のヒントは、Eggplant Functionalをより効果的に使うのに役立ちます。
計画を立てる
テストスクリプトの開発を始めるときには、すでにテスト対象のアプリケーションに精通していて、具体的に何をテストするつもりかを知っている必要があります。簡単に言えば、テスト計画が必要です。
以前にソフトウェアの手動テストを実施したことがある場合は、手動テストスクリプトを開発したことがあるかもしれません。これは、システムの特定の部分が正しく機能していることを確認するために、人が実行できる手順の書面による手順です。Eggplant Functionalは、ソフトウェアとまさに人が行うように対話するので、これらの手動テストスクリプトは、自動テストスクリプトを開発するための理想的な出発点です。
すでに正式なテストが存在しない場合は、どこから始めればいいのか疑問に思うかもしれません。一部の人々は、アプリケーション全体をモデル化し、それを網羅的に実行する戦略を立てることを選択します。また、システムの最もリスクの高い領域に焦点を当てることを選択する人もいます。最もリスクが高いとは、失敗の潜在的なコストが最も大きいこと、またはバグが含まれている可能性が最も高いことを意味します。
どのようなアプローチを取ろうとも、最も生産的な方法は、小さなスタートから始め、簡単なテストを機能させ、進行するにつれてより大きく、より野心的なテストを構築することです。自動化の少ない分がすでにないよりは良いことを覚えておきましょう。そして、小さくて管理しや すいステップが、最終的な目標に近づけてくれます。
エンドユーザー機能の観点で考える
Eggplant Functionalは、テスト対象のシステム（SUT）と「仮想ユーザー」として対話するため、ユーザーレベルの機能をテストするのに理想的です。ソフトウェアでユーザーが実行する高レベルのタスクの観点で考えてください：製品から価値を得るために、エンドユーザーにとってどの主要な機能が動作している必要がありますか？これらの機能をどのようにテストできますか？時間がある場合は、レベルを下げて、このプロセスを繰り返します。
ケント・ベックは、彼の著書Extreme Programming Explained（Addison Wesley Longman、2000）で、このテストの概念を非常にうまく説明しています。多くの人々は、テストカバレッジをアプリケーションのパーセンテージに関連付けたいと考えています。ベックは、測定できない目標を設定しないことを提案しています。彼らがアプリケーションの80％をテストすると言うとき、彼らは具体的に何を数えているのでしょうか？100％のテストは、すべての有効および無効なデータケースがテストされたことを意味しますか？それとも、システムオプションとアプリケーションオプションのすべての順列がテストされたことを意味しますか？より意義のある目標は、アプリケーションのすべての基本機能をテストすることです。
可視インターフェイスに注意する
Eggplant Functionalによる自動化されたテストでは、実際のユーザーがどのようにテストしたい手順を実行するかを常に意識する必要があります。ユーザーが画面上で実際に表示されているものを見て、どのように操作するかを常に考慮しなければなりません。
例えば、次の操作をテストするとします。
- アイコンをダブルクリックしてウェブブラウザを起動します。
- アドレスフィールドにURLを入力します。
- Returnキーを押してページを読み込みます。
これらの操作が早すぎると、テキストが入力される前にブラウザが開かない可能性があります。人間のユーザーは、URLを入力する前にブラウザが開くのを待つことがわかっているので、スクリプトもそれを知る必要があります。WaitFor "Address field"コマンドがこれを解決します。
一貫したインターフェイスを確立する
ほとんどのオペレーティングシステムでは、インターフェイスをある程度カスタマイズできます。これは非常にユーザーフレンドリーですが、画像ベースのテストにはそうではありません。例えば、Macでは、現在選択されているメニューアイテムを示す色を選択できます。青でハイライトされたメニューアイテムの画像をキャプチャしてから、ハイライトの色を灰色に変更すると、Eggplant Functionalは 青を探し続け、おそらく失敗します。
SUTが制御するコンピュータであることが最善です。これにより、テストサイクルの間に他のユーザーによってカスタマイズされることはありません。そうでない場合は、使用するSUTのすべてに対して標準的な視覚設定を確立しようとしてください。設定をチェックし、標準と異なる設定を元に戻すスクリプトを作成することもできます。
ほとんどのオペレーティングシステムでは、デフォルトの設定が最適です。これにより、新しいSUTがすぐに使用できるようになり、使用されているSUTでもデフォルトの設定が多く使用される可能性があります。
Macの場合、System Preferences > Generalで以下の設定を見つけます：
- 外観:
青またはグラファイト,（外観で） - 利用可能な場合にLCSフォントの滑らかさを使用する（外観で）
- スクロールバーの表示（外観で）
- カラー（ディスプレイで）
- 固定のデスクトップカラー（デスクトップ＆スクリーンセーバーで）
Microsoft Windowsシステムでは、表示プロパティコントロールパネルで以下の設定を見つけます：
- "画面のフォントのエッジを滑らかにするために次の方法を使用する":
オフ - タスクバーとスタートメニューのプロパティコントロールパネルのすべての設定
- フォルダオプションコントロールパネルのすべての設定。
テストしているオペレーティングシステムに関係なく、そのタイプのすべてのSUTで実行するカラーデプスを標準化します。古いコンピュータの中には32ビットカラー（"数百万色"）を表示できないものもあり、24ビットカラーを表示できる場合でも、VNC経由で送信される色は32ビットシステムに表示されるものと非常に異なることがあります。
これらの色の違いのいくつかは、検索タイプの許容範囲内にあるかもしれませんが、他のものは32ビットシステムで生成されたスクリプトが24ビットシステムで失敗する原因となります。異なる最大カラーデプスのSUTがある場合は、すべてのSUTで低いカラーデプスを使用するか、一致しない場合は追加の画像セットをキャプチャするかを決定する必要があります。
最後に、ソリッドなデスクトップの背景は、画像やパターンよりも使いやすいことに注意してください。背景に画像の一部が含まれる画像をキャプチャすると、Eggplant Functionalはデスクトップの別の場所でそれを認識できないことがあります。
注意：画面サイズと解像度は画像の一致に影響しません。
システム状態の記録
複数のSUTでテストする利点の1つは、アプリケーションがさまざまなシステムセットアップにどのように対応するかを観察する能力です。以下はいくつかの考慮事項です：
- SUTで実行されているオペレーティングシステムは何ですか？
- メモリはどれくらいありますか？
- システム環境設定はSUT間でどのように異なりますか？
これらと同様のデータを文書化することで、アプリケーションに対するその影響を検証するテストで各構成を対処できます。
画像の整理
この記事では、画像の整理と自分 自身の画像検索時間の削減に役立つ実用的なアドバイスを提供します。
画像コレクション
画像コレクションは、基本画像のすべての許容されるバージョンを含む関連画像のフォルダです。たとえば、画像コレクションには、ボタンの「通常」画像、選択されたバージョン、無効なバージョンが含まれる場合があります。アプリケーションのウィンドウやパネルごとに別々の画像コレクションを持つなど、テーマを持っていると便利です。
スイート内の任意の画像フォルダを画像コレクションとして使用できますが、Eggplant Functionalは画像コレクション内のすべての画像を探しますので、非常に大きなフォルダはスクリプトの実行を遅くさせ、Eggplant Functionalが興味のない一致を見つける原因となることがあります。
命名規則
命名規則は、画像を識別するのがかなり簡単になり、much同僚の画像を識別するのがかなり簡単になります。以下の表は、1つのQAチームの画像命名規則を示しています。これは、独自のガイドラインを作成する際の参考になるかもしれません。
| 画像属性 | 表示方法... |
|---|---|
Highlighted | _hending |
Disabled | _d ending |
Normal | No ending |
Menu | m_ prefix |
Menu item | mi_ prefix |
Checkbox | cb_prefix |
Radio button | rb_prefix |
List box | lb_ prefix |
Text box | tb_ prefix |
Group box | gb_ prefix |
Slider | sl_ prefix |
Button | bt_ prefix |
Pull-down menu | pd_ prefix |
Selected pull-down menu item | pds_prefix |
Tab menu image | tm_ prefix |
Dialog title | t_ prefix |
Screen capture | sc_ image |
テスト管理ツールの使用
テスト管理ツールは、チームが整理された状態を維持し、テストの単一の制御ポイントを提供するのに役立ちます。これは、テストインフラストラクチャが拡大し、テストの自動化が進むにつれて考慮すべき重要な点です。
Eggplantマネージャー
Eggplantは、Eggplant Managerと呼ばれるテスト管理ツールを提供しており、既存 のEggplant Functionalテストからさまざまなテストを構築し、テストの実行をスケジュールし、結果を収集して分析できます。これは、複数のEggplant Functionalテストやテストのインスタンスを同時に実行する最plaintext 簡単で最善の方法です。
Eggplant Managerについて詳しくは、Eggplant Managerドキュメントを参照してください。
Eggplantの統合
Eggplantは、Eggplant Integrationsを使用して、任意の継続的インテグレーション（CI）ソフトウェアやアプリケーションライフサイクル管理（ALM）ツールに統合する機能も提供しています。これらの統合の詳細については、Eggplant Integrationsドキュメントを参照してください。
SUTを覚醒させる
テストに熱中しているときに、SUT 画面が非アクティブになったために突然スクリーン セーバーが起動し、テストが失敗してしまうことほどイライラすることはありません。幸いなことに、このような事態を防ぐ方法があります。
この問題を解決するために使用できるオプションの 1 つは、さまざまな SUT で機能し、テスト スクリプトで処理することです。たとえば、SenseTalk スクリプトに、SUT の非アクティブ状態を引き起こす可能性のある長い wait コマンドまたは waitfor コマンドがある場合は、次に示すように、repeat 句を追加して、それらの非アクティブ期間を処理し、SUT を起動したままにすることができます。
repeat until clause
moveto [1,1]
wait 10
moveto remotescreensize()
wait 10
end repeat
Mac and Windows SUTs Desktop SUTS
MacOS および Windows デスクトップ システムで SUT がスリープ状態になる問題を解決するには、オペレーティング システムの設定を変更してこの問題に対処できる可能性があります。
Windows の場合: 電源とスリープ 設定で、画面 と スリープ のバッテリーとエネルギー (「電源に接続」) 設定を なし に設定できます。
macOS の場合: ロック画面 設定で、非アクティブ時にバッテリーでディスプレイをオフにする と 非アクティブ時に電源アダプタでディスプレイをオフにする の設定を しない に設定できます。
モバイルSUT
一部のモバイルデバイスには、ユーザーが使用していない場合でもデバイスがスリープしないように設定できるオプションがあります。このオプションを設定する手順は、デバイスによって異なります。適切な手順に従ってください。
iOSデバイス
- デバイスの設定に移動します。
- 画面表示と輝度をタップします。
- 自動ロックをタップします。
- しないをタップします。
Android向け
Some Android devices allow the display to never turn off, while others do not. This is a device-specific option. If your Android SUT does not have this option, you can use the SenseTalk PressHomeButton command to wake the screen up.