[Lesson Test Automation. Day 06] Test Automation Code Design vol.03

5281 ワード
automation development test test テキストリンク

Outline

本コンテンツは、これからテスト自動化を始める人向けに作成するコンテンツ。
筆者のこれまでの経験を元に作成しているので、教科書と異なる場合があります。

今回は、テスト自動化の実装にあたって、どのようにプログラムを組むとよいかの設計に関することを記載する。
尚、開発言語に依存しないレイヤーである、概念について記述する。

前回に引き続き、テスト自動化設計に関して執筆する

Test automation design view point

1.Data driven
2.Data normalization
3.Keyword driven
4.Robust & Sensitive
5.Scenario independency
6.Scenario size
7.Setup & Teardown
8.Analyzable report
9.Repeatability
10.Break flaky
11.Flexible trap

7. Setup & Teardown

Setupとは、テスト実行前に行う処理
Teardownとは、テスト実行後に行う処理

Setup
テスト実行時には環境が整わなければならない。
例えば、以下のような処理である

  • ブラウザ起動（WEBテスト）
  • アプリ起動（NativeAppテスト）
  • ブラウザの不要なポップアップをクローズ
  • クッキーをクリア、もしくは関係するクッキーを削除
  • データのデフォルト設定

ブラウザの不要なポップアップとは、下図のようなもの。
chromeの場合、様々なポップアップが出る時がある。
これが表示されていると、RanorexやUFTなどは、マウスカーソル処理でその下に隠れているメニューを押そうとしても押せずに、自動化が失敗してしまう。
そのため、ブラウザが正常の状態にすることをsetupで行うと、自動化は安定する。

クッキーに関しては、結構重要。
ブラウザ起動時にクッキーを全部クリアにする方法があるが、ABテストでクッキーを見て処理しているもの等がある場合、最低限のものをクリアにする必要がある。

クッキーでよくあるのがログイン状態。
ひとつ前のテスト自動化終了後、ログアウトせずに終了　もしくは途中でテストがエラーになり中断した場合などで起きうる。
そのため、最初の処理でログインを行おうとしてログインボタンを探すが、ログイン状態であった場合失敗する。
回避策として、ログアウトを最初に行うのが望ましい。ただし、ログアウトのボタン押してといった処理にすると、ログアウトされている状態の時、ログアウトボタンが存在しない。
条件分岐で自動化を組むのが考えられるが、ログアウトのページをダイレクトに飛ばすのも一つのやり方である。

データのデフォルト設定は、クッキーのクリアに似たものがある。
serverサイドにデータがある場合である。
例えば、楽天市場であれば、お買い物かごである。
前のテストの状態が不明である前提で、テストを開始することを考える必要がある。
かごの情報がクッキーではなく、serverサイドのデータベースに保存している場合、クッキーのクリアでは解決しない。
そのため、かごを空にする処理を含める必要がある。（場合によっては、条件処理で組み込む必要がある）

このほかのデータクリアの例として以下のようなものがある。

  • メンバーシップサービスから退会処理（入会処理のテスト）
  • お気に入りの削除（お気に入り追加のテスト）

Teardown
テスト終了後に環境をクリアにする処理である。
尚、テストが途中でエラーになり中断したとしても、このteardownは必ず実行させるようにすべきである。

例えば以下のような処理である

  • データの初期化
  • ブラウザを終了する（複数のタブがOPENしている場合、すべてをクローズする）
  • アプリを終了する

次のテスト自動化を実施するときに、影響を与えないようにテスト実行前の状態に戻すべきである。

データの初期化としてはsetupと重複するものがある。
テスト開始前に行うか、終了後（成功・失敗問わず）に行うか、実装のしやすさ等から組み込む必要がある。

以上、テスト自動化の実行では「どんな状態から始まるかわからない前提」であり、テスト自動化終了時には「元通りに戻す」ことを心掛けることである。

8.Analyzable report

これは、実行結果のレポートが、特にエラーになったときに分析しやすい情報を含んでいることを意味する。
RanorexやUFT等、商用ツールはデフォルトで十分なレポート機能を含んでいる。
ただ、これらツールでも自分でC#等でコードを記述するときは自分で適切なログを抽出する必要がある。

どのようなものがレポートに含まれていることが望ましいか

  • テスト実行ステップ
  • 使用したテストデータ
  • 失敗した時、どこでどんな理由で失敗したかが明確
  • 失敗した時のスクリーンショット
  • 失敗した時の動画
  • テストデータが変数で変化した場合、それをトレースできる
  • 実行時間（トータル、処理step毎）

エラーが発生した時、なぜ失敗したかを分析する必要がある。
テスト実施中目視していたのならば不要かもしれないが、基本的にテスト自動化実行中見ていない。
そのため、失敗レポートから原因を特定できるようにしないと、最悪なケースとして、担当者が再度実行し、失敗するまで目視する必要が発生する。
当然、そのテストケースが失敗するまで時間がかかる。

また、実行時間も重要な情報である。
CI/CDとしてテスト自動化を常に動かすとき、Quick Feedback を果たすために、テストの実行時間を気にする必要がある。
各処理ステップで実行時間が大きく要するところは、なるべく減らしていく運用はしていくことが望ましい。

Finaly

次は7月10日（金）頃配信予定です。
引き続き、Code Design vol.04 を予定しています

reference

back number