SeleniumBuilderでテストを実施したら分かるんですが、実施項目に緑・赤がついて、赤になるとその場でテストが止まります。
完全自動化を目指すと、この仕様のせいで夜回していたテストが終わってない、という事もあります。

これを回避する運用案について、気付いたところをまとめました。

前提条件

• SeleniumBuilder
  • 使ったことがある
  • テストツールとしての導入を考えている
• SeleniumServer
  • 運用している
  • ターミナル系のコマンドが分かる

SeleniumBuilderでのテストの挙動と課題

バージョンは2.3.5/3.0.9です。過去の投稿を参考にしてください。

• Frame系
  • 画面に出力されるエラーログからでは原因を特定することが難しい
• Capture系
  • 根本的にパスが間違っている場合のリカバリをSeleniumBuilder以外から確認する必要がある
  • そのため、SeleniumBuilder側に固有の変数を持たせるべきではない。CSVなどで管理する
  • ただし、複数のファイルから変数を与えることは仕様上出来ない。
• テストシートの挙動
  • テストシートに連続したテストケースを入れる場合、前段のテストが正常終了だろうが異常終了だろうが気にしないで実施する
  • これを回避する場合、テストシートのshareStateをfalseにして、都度開きなおすのが良い

結論

完全自動化を目的にするなら、現時点ではBuilderは使わないほうが良いでしょう。
ある程度運用を決めて、その上でボトルネックになっている部分を解決していくのが理想的です。

現行システムを改修する

では、その上で動いているシステムをなるべく半自動化ぐらいには寄せよう、というのが今回の課題です。
やりたいことは「テストがすべて成功で完了できたのか判定する」という観点で解説します。

対応 SeleniumBuilder側

それぞれのテストケースの正しい完了条件を設定して、画像に意味のないスクリーンキャプチャを取ります。
ここでやりたいのはファイルを置く事なので、要件さえ満たせればスクリーンキャプチャの必要はありません。
SeleniumBuilderが用意しているファイル出力の仕組みがこれしかなかったので代用しています。

  "steps": [
（中略）
    {
      "type": "assertTitle",
      "title": "ここに条件"
    },
    {
      "type": "saveScreenshot",
      "file": "ここにファイルパス"
    }
（中略）
  ],

対応 サーバー側

こちらは簡単ですね。
SeleniumBuilderが実施した内容が正常であることをsaveScreenshotのファイルから判定します。
ここは事前に打ち合わせるなりの運用対処が求められます。
わりかし安全なのはSeleniumBuilderが呼べる変数ファイルにパスを書いておいて、サーバーで対応する場所に読み替える事です。

#（中略）
if [ ! -e "${saveScreenshot_path}" ] then;
  echo "no Complate"
  exit 1
else
  exec("${next_step}")
fi
#（中略）

未解決課題

Captureが失敗する可能性を考慮していない設計です。
実際問題として、Captureは失敗する可能性がありますので、その際もnoComplateとして扱います。

読了後いいね！をお願いします。

どれだけの方に読んでもらっているか知りたいので、お手数をおかけしますがご協力いただけると嬉しいです。