テスト自動化について考えてみる

前の部署の最後の仕事と今の部署の最初の仕事がテスト自動化な件について

ぐぐったらTest Automatorってかなり人数少ないらしいから先駆者になりやすいらしいんで僕もがんばります

明日、世間のPMやらPLに向けたテスト自動化ハウツーセミナーとか言う物に23歳の若造が参加することになったので、参加する前に予習がてら考えをまとめておきます。

 

テスト自動化ってなんだ

文字通りテストを自動化する事だと思う

具体的になんのテスト?って聞かれると、俺今までリグレッションテストしか自動化してねーわ...とか思ってたら、wiki的にはリグレッションテストが一番自動化の話題に上がるらしい

http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88

 

そもそも自動化する一つのメリットとして、テストの工数を減らすっていうものがあって、繰り返し頻繁に使われる、使えるリグレッションテストが適しているっていうのはもうごもっとも過ぎて、ぐうの音も出ません。

 

リグレッションテストって何?って方はぐぐってください。簡単に言うとある部分変更したら、他にも影響でることあるじゃないですか。あのデグレを検知するためのテストです。

 

どうやって自動化するの?

有名なのはjenkins先生ですね。CIって呼ばれてて、継続的にテストを行ってくれる奴です。前の部署では12時間に1回。今の部署ではリリースバージョンへのコミットのタイミングで起動するようにトリガーをセットしてあります(たしか

jenkinsはプラグインが充実しててxUnit系はもちろんSeleniumなんかにも対応出来ます。

 

前の部署ではmodel部分をphpUnitでテストを結構書いてた時期もあったのですが、あまりにも人によってコード品質が違い過ぎて常時jenkinsさんは怒っていましたが。

(ここには数字しかこないから大丈夫なの!とか言ってた先輩いたんだけど、Controllerカオスすぎんよ。あとis_numericで数字かどうか判断するのやめて、まじで。小数点おっけーだからあれ。)

 

知ってる知識まとめ

webアプリケーションのリグレッションテストを対象としてます。

Selenium+jenkins環境です(一応behatも)

 

・最初から最後まで完璧に自動化を目指さない

ROIがひどいことになる。特にコストすごい払ってテストシナリオ作ったのに、軽微なソース修正がテストシナリオの大規模な修正を呼ぶ。

とりあえず最初に作るべきシナリオは「最低限の動作を保証するもの」。これだけは絶対に動かないとまずいって所を用意しておいてからの、込み入った処理のシナリオは別途用意する。スイートにしてまとめられれば最高

 

・せっかく作ったテストは頻繁に使う

なんかの記事で自動化したテストは4回実行すれば元がとれるとか読んだ気がする。せっかく作ったので、いっぱい使おう。

いっぱいやると元が取れるだけじゃなくて、テスト自体の品質にもこだわれるようになる。上で言った事と相反するっぽいけど、あまりにも制約の弱いテスト流すとそれはそれで意味が無い事ですので。洗練するきっかけにもなりますってことで。

 

・テストもちゃんと修正して行く

「以前、●●を修正したからここで止まるよなー。でもちゃんと動いてるっぽいからおk」とかやってるとテストが形骸化してまじで使い物にならなくなるので注意。

(以前の部署の時につくった俺のテストがまさに形骸化してた。泣いた。)

一回作ったら何度も使い回せるけど、ある程度の時間をおいたらメンテナンスは絶対に必要。それも含めてのテスト自動化

 

・何度も使えるようなテストにする

とはいえ、やっぱりメンテのコストを減らすのも重要な観点。

例えば、申し込みフォームのテストで名前がDB上でUKになってたとして、あらかじめ決められた値を入力しようとすると、当たり前ですが二回目で止まります。

自動化()

なのでランダムで名前決めてやるってのもよかったのですが、基本的に日付を良く使いました。同じ日は二度と来ないという熱いメッセージをこめて。

 

・Waitまじで重要

Seleniumのヘビーユーザーなら分かると思いますが、たまたまブラウザのレスポンスが遅いだけでテストが終了してしまう事がざらにあります。っていうかSelenium妥協する人の一番の原因じゃないかこれ。

そこでClickAndWaitとかWait(1000)とか重い処理の前に入れるのすごい重要です。

とはいえ、1秒はだめで2秒はいいのかよ!とか言う問題になるので、

while(処理が終わる | ●●が表示される):

wait(1000)

っていう小技が俺の中で革命的でした。ただタイムアウト起こされるともう知りません。10秒とか条件つけた方が良いかも

 

・session管理も重要

皆さんほどの天才エンジニアならhttp/1.1の同時接続数の上限なんて余裕ですよね。

ええ、ブラウザとその設定によって変わります。

ついでにいうと同時接続数だけじゃなくて、最大接続時間なんていうものもあります。

複数のシナリオを一度に複数のブラウザ立ち上げるとNo buffer spaceやらなんやらがでてきます。

sessionをunsetやdestoryするなり、接続時間を延ばすなりしないと意味不明にとまったりしてすごいはまります。現に俺は二日かけたよ

 

 

 

こんな感じかな。あとは明日のセミナーで収穫して来たことをまとめてからのTest Automator名乗ります。

お堅い企業だと品質管理部門とかついててかっこいい。

 

 

 

※追記

16人限定(16人来るとは言っていない

的な感じですごい人少なかったです。前回は管理職向けのテスト自動化の導入の話だったらしいのですが、今回は導入を検討している人へのセミナーって感じでした。

手動で行うテストのうち、自動化して意味があるのはスモークテストとリグレッションテストで、そのうち2-3割くらいを自動化できたらテスト自動化は成功!っていう雰囲気が、海外のTest Automatorにはあるようです。

 

なんで全部自動化しないの?ってなるとROIの関係だそうです。

あんまりにも仕様がコロコロ変わる箇所だったり、全然使われない機能のテストを自動化してもメンテナンス、管理のコストがかかるだけでうまみがないとのこと。

じゃあどこを自動化するの?って言う時の観点は、それをそっくりひっくり返した、

1.頻繁に使われる主要機能

2.単調で機械的な入力、計算を行う箇所

3.ヒューマンエラー(操作ミス)が発生しやすいところ

っていうところを集中的に作るのが良いとの事。

 

あとはちゃんとみんなでテストを管理しようねっていうお話

一人だけめちゃくちゃ出来ても、引き継ぎとかコストかかってテスト自動化やめちゃう

とかざらにあるらしいので、みんなで管理しよう。みんなが使えるようになろう

それに付随して、PM,PLも学習コスト管理コストをちゃんと受け入れてあげてね。っていうお話

 

最後に「テスト」と「テスト自動化」の2つは結構違うからテストをきちんと設計する人とテスト自動化をコーディングする人は分けた方が良いよ。って言うお話。

個人的にはこれが一番ためになるかなーと思いました。

なんとなくこんな感じの奴つくって、と言われてテストも自動化も同時に並行して行ったけど、はなはだ怪しいところだと思った。

Behat上ではシナリオ(Feature)を書く人と処理(Context)を実装する人で分けたら確かにすっきりするんだろうな。って思った。

 

全体的に「テスト自動化する、その前に。」っていう話が大半を占めてた気がする。

今、テストを行う理由は何か?

その中でテストの自動化を推進する目的(理由)は何か?

どこまでできたら成功と定義する?

テスト自動化は銀の弾丸ではないから、あくまでツールとして考えてね。でもいいことたくさんあるよ。って言うお話。

成功事例はすげーあやふやで吹いた。

 

留意点は上にあげたようなもので、そこに注意して自動化ができればテスト工数は最大で45%カット出来るよ!嬉しいね!っていう結末でした。

 

最後にSilkTestっていうツールを紹介されたんですけど、あれよさそうでした。

自動化コーディングはまじでデバッグが面倒なんだけど、実際に処理と平行してブラウザをチェック出来てて、あーこれ便利だな。って思いました。高そうだったけど。

 

Seleniumの他にもqtbなんて物があると知ったのでちょいと調べてみやす。

想像以上に収穫少なくてやばいけど、これはもう仕方ない。

 

以上。