ベストプラクティス | テストケース | 試運転

ExecutionLists でテストを実行し始める前に、まずスクラッチブックでテストケースの試運転を数回実施することを推奨します。

ScratchBookは結果を永久保存できないため、テストで不安定になりそうな箇所を見つけて修正するのに最適です。たとえば、識別の問題、依存コントロールの待機時間の欠落、テストフローの設計時には考慮していなかったポップアップダイアログなどが考えられます。

TestCaseを可能な限り安定的で信頼できるものにしましょう。テスト実行フェーズに入ったら、結果が失敗になった原因がアプリケーションの欠陥にあるのか、テストの欠陥にあるのかを究明することに貴重な時間を割くことは避けたいはずです。加えて、ExecutionListは結果を永久保存してしまいます。あらゆるテスト結果の記録を残す必要がある厳格な環境では、ExecutionListでTestCaseのテストランを行うと結果の記録がごちゃ混ぜになってしまいます。

このトピックは、テストについて次の各方法を説明します。

  • 結果の分析を楽にする方法

  • テストの問題に対処する方法

結果の分析を楽にする

結果の分析が非常に楽になるヒントをいくつか紹介します。

  • LogInfo 列に複数の行を表示するには、結果ビューを変更し、「複数行のログの表示する」を有効にします。

スクラッチブックの結果：デフォルトビュー → 「複数行のログを表示する」が有効になっている

テストの問題に対処する

テストケースが失敗した場合は、失敗したテストステップを展開して、「 LogInfo 」列で詳しい情報を確認します。

制御に問題がある?

Toscaが画面やコントロールをみつけられない場合は、使用中のアプリケーションを確認してください。または、「失敗したテストステップでスクリーンショットを作成する」設定を有効にしている場合は、スクリーンショットを確認します。

  • テストの特定の時点で画面が予想どおりに表示されますか?

    モジュール、特に画面または制御用に選択した識別子を確認してください。モジュールを更新する必要があるかもしれません。たとえば、適切な識別情報（Identifier）を選択できるようにモジュールを再スキャンしてみましょう。あるいは、アプリケーションでコードを変更した後で識別情報（Identifier）を更新してみましょう。

  • 想定外の要素が画面に表示されていませんか?

    ユーザーインターフェースをブロックする確認ダイアログやポップアップなど、テストの設計段階で見落としてしまった動作がないか確認しましょう。このような動作を処理できるようにTestCaseを調整するのが理想的です。このような動作が散発的に発生する場合は、代わりに回復手順を設定する必要があるかもしれません。

検証に問題がある?

予想されていた結果と、 LogInfo 列の実際の結果を比較します。また、「失敗したテストステップでスクリーンショットを作成する」設定を有効にしている場合は、スクリーンショットを確認してください。

  • 正しいコントロールを検証していますか?

    正しいコントロールを検証しているか、TestCaseで確認してください。これは、間違ったセルを誤って定義してしまう可能性のあるテーブルの場合に特に当てはまります。場合によっては、TestCaseを更新する必要もあるでしょう。

  • 検証の他に問題があるのでは?要するに、正しいコントロールを検証しているにもかかわらずTestCaseとアプリケーションに差がある、ということです。

    TestCaseとアプリケーションの両方を確認して、間違っている方を特定します。問題の原因を見つけるには、両方で1つひとつ確認することになるでしょう。

検証の問題がアプリケーションのバグから発生している場合は、必ずエラー処理を設定してください。エラー処理であってもToscaは検証失敗としてレポートします。心配しないでください。バグがあれば必ず見つかるはずです。エラー処理はテストランを軌道に戻すだけです。それでも ExecutionList の残りの部分については、有意義な結果が得られます。

次のように仮定しましょう。TestCaseでオンラインショップのカートに商品を5つ追加した。ScratchBookでテストランを実行し、Toscaは合計金額に問題があるとレポートした。調べてみると、1つの商品にバグがあることが判明した。アプリケーションは1回目から常に正しい税率で計算するわけではなかった。この場合、カートから商品を削除して再度追加する回復シナリオを作成できます。

実行結果へのさらなる洞察の作成に関するサポートが必要でしょうか？Tosca Copilotがサポートいたします。詳細については、きます）をご覧ください。

タイムアウトの問題では?

Toscaで画面やコントロールがタイムアウトする場合、アプリケーションを確認します。または、「失敗したテストステップでスクリーンショットを作成する」設定を有効にしている場合は、スクリーンショットを確認します。

  • テストの特定の時点で、想定したコントロールがすべてアクティブになっていますか?

    コントロール間で依存がないか、アプリケーションを確認してください。特定のコントロールが使用可能になるまでToscaが待機するように、動的な待機時間を追加する必要があるかもしれません。たとえば、「次へ」ボタンが有効になる前に、プログレスバーが100%に到達する必要がある場合などです。

  • アプリケーションは読み込みに思いのほか時間がかかりましたか?

    QAチームに連絡してください。画面やコントロールの読み込みにそれほど時間がかからなければ、TestCaseには手を加えません。アプリケーションを修正するまでエラーが表示されます。

    開発の初期段階でアプリケーションの動きが遅いと感じた場合は、TestCaseを調整します。Toscaがすべての画面とコントロールを待機するように規定値の時間を長くすることができます。あるいは、特定のコントロールやTestCaseに対して待機時間を追加できます。そうすれば、予期されたタイムアウトでテストが失敗することがなくなります。

待ち時間や重要な考慮事項に関する詳細情報については、 "ベストプラクティス｜テストケース｜待ち時間" をご覧ください。

次の記事

まだご覧になっていない場合は、他のベストプラクティスの記事をご覧ください。