MasaoApril's Library.

Software Testingなネタを書いてみた。

システムテスト自動化カンファレンス2014(3)「GUI自動テストの保守性を高めるには」

Conference STAC2014 TestAutomation

　2014/12/14(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2014で聴講したセッションから数回に分け、まとめたものを紹介しています。

セッション(再掲)

1.オープニング：1時間で分かるSTA　/鈴木 一裕　→<資料>
2.テスト自動化のパターンと実践　/.reviewrc　→<資料1>/<資料2>/<資料3>
3.GUI自動テストの保守性を高めるには　/伊藤 望　→<資料>
4.状態遷移テストにおけるテスト設計と実行の自動化　/きょん　→<資料>
5.ビルドプロセスとCI　/長谷川 孝二　→<資料>
6.社内スマホアプリのビルド配信ツールによる自動化事例 /赤根 稔朗(Yahoo! JAPAN)
7.Test Automation Patterns 2014 冬コレ！/松木 晋祐　→<資料>

　前回は「2.テスト自動化のパターンと実践」でしたが、今回は「3.GUI自動テストの保守性を高めるには」について紹介します。

3.GUI自動テストの保守性を高めるには　/伊藤 望

[1]GUI(画面)自動化のコスト

　作成のコストには目を向けがちだが、保守コストについては考慮されていないことが多い。また、保守コストが高いのでどのようにコストを減らすかが課題。

[2]よく利用されるパターン

(1)キャプチャーリプレイ

　キャプチャーリプレイは、テスト自動化では無い。

"Selenium IDE"
<メリット>
<デメリット>
"Selenium Web diriver"
<メリット>
  • 共通化の技法を駆使し、保守コストを減らせる。
  • ifなどの分岐処理のコーディングが記述しやすい。
<デメリット>
  • プログラムの読み書きするスキルが必要。

(2)プログラミング言語で記述

　様々なオープンソースやクラウドサービスと親和性が高い。

(3)Excelからスクリプト生成

　ExcelからSelenium IDEやWebdriverのコードを生成する。

<メリット>
  • プログラムの読み書きする必要が無い
<デメリット>

(4)[2]のまとめ

　「Selenium IDEを記録したスクリプトをそのまま動かすのはやめよう！」

[3]グリーンに保つ3ステップ

(1)できるだけ失敗しない

(a)テストは何故失敗するのか？
"テストツールのバグ"
  • 画面操作の実行エンジンは、実装難易度が高いためバグはつきもの。
  • 対策としては、実績のあるエンジン(Selenium Webdriver)を選び、リスクを軽減すること。
"システム対象のバグ"
"テスト対象システムの仕様変更"
  • 対策として、id属性を付与する。
"不安定テスト"
  • 原因は、不安定なネットワーク。
  • 対策として、ウェイトを入れたり、リトライを入れること。
"環境準備失敗"
  • 原因は、コンパイル＆デプロイ作業手順のミス。
  • 対策として、コンパイルなどの手作業を排除し、不安定なところは地道に改善すること。また、テスト用サーバの再起動失敗した場合、環境準備チェックテストを入れ、失敗したら停止するように工夫すること。
"DB定義変更作業ミス"
  • 原因は、SQL適用やコンパイル、サーバ再起動の時間差で発生。
  • 対策として、手作業を排除する仕組み(バッチ処理)を検討すること。
"テストデータ不整合"
  • 原因は、手動テスト用に設定を変更。
    • (例)テスト失敗の原因調査に流したテストでゴミデータが作成。

  • 対策として、テスト環境を毎回クリーンなものを使用すること。

    • (例)前回のゴミデータを削除する。

  • 注意

    • ヒューマンエラーの場合、「次回から気をつけましょう」で終わることもありテンションが下がるため、失敗しないための仕組みを検討すること。

(b)バグ以外の原因でテストが失敗すると...

  • 自動化のやる気が減退する。
  • バグじゃないということで、調査が後回しされる。

(2)失敗したら原因を突き詰める

(a)テスト結果に誰でも簡単にアクセスできる

　チームでテスト結果を共有し、テスト失敗の関心を高める。

(b)画面キャプチャやサーバーログなど、エラー調査に必要なデータを残す
(c)エラーになったテストだけ手元に流して確認できる
  • 短く、独立したテストを多数作る。 →長時間のテストを全部流さないと結果確認ができないのは調査が大変
  • テストスクリプトはバージョン管理して、誰でも手元に取得できるようにする。

(3)原因が分かったら修正

[4]テストスクリプトの共通化

・DRY(Don't Repeat Yorself)の原則はテストスクリプトの場合でも同じ

・ページオブジェクトデザインパターン

Selenium界でよくやっているのは、ページオブジェクトのメソッドは、画面のUI構成に依存しないようにする。

　例：日付入力

<メリット>

　HTML要素を隠蔽できる。

<デメリット>

　直接スクリプトを書くより大変。

・データ駆動テストも有効な手段。

[5]Sahagin

　伊藤さんが作成したSeleniumのテスト結果を見やすくするツール(※オープンソース)。下記URLで公開されている。

https://github.com/SahaginOrg

　伊藤さんのblog(「品質向上ブログ」)にSahaginの解説記事が2015/01/05に公開されました。


所感

　"[3]グリーンに保つ3ステップ (1)できるだけ失敗しない (a)テストは何故失敗するのか？"で挙げられた内容は、他開発ドメインのテスト自動化ツール(UWSCなど)にも当てはまるところがありますので、自テストチームで時々稼働しているテスト自動化システムで「テストの目的と自動化処理」が繋がっているか否か、メンバーと考えていこうと思います。また、様々な開発ドメインでのテスト自動化でつまづいた点や解決に至った過程の知見が自社他社問わず共有できるような時代をみんなで作り上げることも大切だなと思いました。