Background
Autifyが現在のテスト自動化より効率的かを検証してみた。
proxy (private) のテスト環境
自分のテスト環境は、社内に限られ、proxyで接続してのみ利用可能である。
Autifyはテスト実行はAutifyのcloud環境で行われる。
Helpにある通り、実行環境と連携してテスト実施は可能ではあるが、ハードルが高い。
senario edit
編集したいステップまでテストを進めることは可能。
だが、手動で1 step毎に進めることができないのが不便
ほしい機能
- 一時的に一部STEPを無効にする（SKIP)機能。削除しかないので、戻したいとき再編集が必要
- if 文でSTEPを分岐・条件を満たすときのみSTEP・ステップグループの追加する機能
- 一部のSTEP・ステップグループをデータ駆動でループする機能。シナリオ全体のループは可能だが。
データ駆動
シナリオ単位でデータ駆動が可能
まず、データ駆動するためのデータソースをuploadする
次にシナリオの値を入力するSTEPで、先ほどのデータの変数名に変更する
楽にデータ駆動の設定ができた。Ranorexと同様なやりかた。
Mablはjsスニペットで実現するので、Autifyは易しい。
要素の特定
capture & reply型なので、操作したときの要素を毎回選択し、クリック等が行われる。
今回、楽天競馬で ”ある競馬場の11Rの投票をクリックする” ステップを考える。
なお、この投票リンクの表は毎日変わる（対象の競馬場が異なる。レース数が異なる。（最大12レース））
作成後、シナリオを確認した時が、以下のとおりである。
先ほどのように、表の中に数多くの”投票リンク”があるなかで、クリックする場所がどういった基準で選ばれているのかが不明である。
- 姫路の11R
- ３番目の競馬場の11R
- 姫路でクリック可能な投票リンク６番目
という風に、いろいろな解釈ができる。
実際に、毎日実施してみると、クリックする競馬場は異なっている。
そこで、locatorを明示することで、その不明確さをなくすこともできる
なお、xpathを取得する方法はhelpに記載されている
ただ、今回のようにテーブルの特定の行・列を指定するとき単純にdeveloper toolでは取得できなかった。コツがいる。
reporting (failur)
テストを失敗したときのレポートの例
- 各ステップの処理時間が明確
- どのステップで失敗し、原因が明確
- 動画で確認可能
- 失敗したステップから編集可能